A Vision of the Future Evolution of Information Technology & its Management Article 8: Is it easier to manage three systems software environments or two? Farmer Brown, Falls Creek, OZ Late in the Southern Winter of 2002

Information Technology Management (of an RDBMS site) represents a sophisticated and advanced form of juggling. Specifically, this act of juggling involves the constant consideration of the dynamics of three separate computer software systems environments. This has been a matter of necessity now for some decades.

These three software systems environments were introduced earlier in this series of articles in this format:

At large in the world today (19xx to 2002), at the top layer:


The Third Environment:
RDBMS Application Software Environment:


• the vendor specific database application software Product A;
  
• the vendor specific database application software Product B;
  
• the vendor specific database application software Product C,D,E,F, etc as req'd
  
• the organisational users;
  
• the organisational management, executive, steering committees;
  
• other non-DBMS specific elements in the environment (eg: WP, Spreadsheets, image manipulation, etc)
  
• the etc's belonging to all combinations and permutations of the above.
  
• specific organisational IT resource staff (eg: Applications/Development HelpDesk)

  
  In the middle (1980 to 2002) layer:

  The Second Environment:
  RDBMS Environment:
  

• the vendor specific RDBMS;
  
• the organisational database(s) (ie: the data) and its integrity;
  
• specific organisational IT resource staff (eg: DBA)

  
  At the foundation (19xx to 2002) layer:

  The First Environment:
  (R)DBMS OS Software Support Environment:
  Hardware, machine OS and machine network OS Software:
  

• the vendor specific computer core hardware (processor(s), memory, DASD);
  
• the vendor specific operating system;
  
• the vendor specific hardware peripheral devices (and device managers);
  
• specific organisational IT resource staff (eg: Operations HelpDesk)
  
  

Examining the above again, from a systems perspective, we narrow the list. In this view we remove the components which are not part of the computer software systems environment, and are left with the following restatement:
At the top layer

The Third Environment:
RDBMS Application Software Environment:


• the vendor specific database application software Product A;
  
• the vendor specific database application software Product B;
  
• the vendor specific database application software Product C,D,E,F, etc as req'd
  

  In the middle layer:

  The Second Environment:
  RDBMS Environment:
  

• the vendor specific RDBMS;
  
• the organisational database(s) (ie: the data) and its integrity;
  

  At the foundational layer:

  The First Environment:
  RDBMS OS Software Support Environment:
  Hardware, machine OS and machine network OS Software:
  

• the vendor specific computer core hardware (processor(s), memory, DASD);
  
• the vendor specific operating system;
  
• the vendor specific hardware peripheral devices (and device managers);


These are the three separate yet heavily interwoven computer system software environments that are at the heart of practically every large organisational endeavour on the planet. These are the three objects that IT Managers, and the resources available to them, must successfully juggle.

The objects one and two are of the generic kind of circus juggling balls, you can buy them at most 24 hour petrol stations. They are often robust, stock-standard wheel in and wheel out components. There are but a few worldwide combinations of these two objects.

On the other hand, object three is a massively dynamic flaming elephant which is (naturally) constantly hungry and thirsty and requires much attention of varying philosophies and teams of handlers, publicity agents, elephant doctors, elephant psychoanalysts, peanut butter vendors and assorted hangers on.

We will now examine the reason why a method must be found and implemented whereby the massively dynamic flaming elephant can be lead to water and pasture and retired from the arena of IT.

In the following section it may be clearly seen that the management of three separate subsystem environments of computer software is considerably more complex and costly and resource depleting than the management of two such systems.

Managing 3 things as compared to 2 Things

From a systems perspective, dealing with the dynamic integration of two very well behaved environments is far easier than having to deal with the dynamic integration of three. Especially when the additional third environment itself is so fraught with problematics. As an integration exercise, things are far simpler with the dynamics of two interactive systems environments, than any number greater than two, such as three.

There is a classic example of this from the history of the scientific program. Examine the evolution of analytical mathematics in its ability to describe the dynamics of objects under the force of gravity. The generalised form between two bodies was delivered to the planet by Newton, but hundreds of years later, the generalised form for three bodies was still not solved.

It was, and still is, referred to as an unsolved problem in Celestial Dynamics, and it is known simply as The Three Body Problem". In fact, it was shown by Poincare in 1900 that this general problem is indeed not able to be solved in any general analytical sense.

As an aside, the workaround to performing calculations which enabled the trajectories of the three bodies of the Earth and the Moon and the Eagle [1969] to be determined in advance, was by applying the simpler two body calculations (of Newton) on an iterative basis. Assisted by the earliest computers. the dynamics of the interaction of three mutually gravitating (celestial) bodies were gauged in a simulated manner. Namely, that the problem of three bodies under gravity was reduced to the consideration of evolving sets of two-body interactions.


In the following diagram in red is the Third Systems environment.
It has served its usefulness in the evolution of computing.

Like a booster rocket being ejected after fuel consumption,
future history will see the applications software environment
falling away from the outbound trajectory of IT management
and its command modules of the 1st and 2nd Environments:

Here at Falls Creek, in New South Wales, Australia, we have constructed such a mechanism for the Microsoft SQL Server RDBMS product. This mechanism consists of small portal program driven exclusively by TSQL Stored procedures.

The simplicity of the design and operation are startling at first, and it is usual to question the versatility of the product. But its versatility and sophistication are surprising when put to the test.

We are able to deliver applications as a database.

More information about the product, and the company can be found here.

Index/Intro | Article 1 | Article 2 | Article 3 | Article 4 | Article 5 | Article 6 | Article 7 | Article 8 | E-Mail

A Brief History of Modern RDBMS IT Management