A Brief History of Modern RDBMS IT Management Article 7: Future IT Change Management Will it be any different? Farmer Brown, Falls Creek, OZ Late in the Southern Winter of 2002

In the beginning was the code.
It is still here, and still incurring co$t.
What is the problem?

Large scientific, administrative and business organisations all share a common focus in the RDBMS. Today they also share a task in the management and change management of their preferred database application software product or products, running on their preferred RDBMS solution. Costs of such environments are not decreasing, and this concerns executive. Complexity of solutions is not decreasing, and this concerns the IT Manager. Where is change leading information technology?

1) Answer: Not known
2) ETA: Not known (See 1)
3) COST: Not cheap.(See 2)

The problem appears to me clearly to reside in the manner by which change in the RDBMS applications software (code) environment is inordinately dominating available resources. In particular, those resources (people, time and money) invested in the (seemingly) perpetual application software change management cycle, as outlined in detail in the previous article.

The following series of paragraphs outline a potential and permanent workaround the above unknown evolution of Information Technology management in the environment of RDBMS software. We have conceptually covered the period leading up to the existence of the modern RDBMS, and should be well aware of the benefits provided within the RDBMS environment.

Let us now focus our attention on this matter of organisational intelligence that has persisted in its constant need for expression. This indeed may be seen as the very heart and essence of every specific and unique organisation regardless of form and activity.

In the following series of problem resolution notes we examine a potential alternative to the default option of sitting around and doing nothing about how technology appears to be evolving. Instead, we examine the irrefutable dynamics of change itself.

On the matter of the location of organisational intelligence (or Business Rules)

At the present time, just as was the case many decades ago, the asset which contains the investment of the organisational intelligence (OI) is simply the applications software code. Explicitly coded within the suite of program objects A1, A2, A3,...An, of a typical RDBMS Applications Software product A are all the formalised definitions of the specific organisation's activity encompassed by the functionality of product A.

If the orgainsation actually utilises other RDBMS Application Software products B and C and D, then the OI is encompassed in the super-set or union of the suites of program objects A1 to An, B1 to Bn, C1 to Cn, D1 to Dn, etc, as required by the organisation.

In the beginning, it could unequivocably be stated that the location of this organisational intelligence (OI) (or if you prefer, the business rules (BR)) was within the code. However, having just looked around under the bonnet of a modern RDBMS, we notice that there are traces of references to a number of different aspects of OI.

Today it cannot be said that 100% of the OI resides in the applications software environment, because we can see the evidence of some of it clearly resident within the RDBMS. Basic support for integrity constraints exist. Triggers exist which enable automatic transactions to be defined and run on the basis of other RDBMS activity. A myriad of data transformation and automated scheduling services exist.

But perhaps most importantly, emergent with greater functionality in recent years, there are the RDBMS Stored procedures. A stored procedure is essentially a program written in the native RDBMS language, SQL. Stored procedures can be called directly from the application software code, and are run within the RDBMS. There has been an increasing use of this facility.

To provide a general example, we recall a typical RDBMS application software package A might consist of n program objects A1 to An. In addition to these n objects, the package might also deploy and maintain a set of vendor supplied RDBMS stored procedures.




On the observation of the relocation of the OI (or BR)

This to me implies the beginning of a migration and a movement. In the past 100% of the OI (or BR) existed in the applications software environment. Today, due to the features provided by the modern RDBMS this is clearly not the case. Some non-zero quanta of OI has been effectively relocated from the applications environment to the RDBMS environment. We have x% of the OI resident in the RDBMS, and now only (100-x)% of the OI resident in the applications software code.

What else can it be but a shift in balance?
The observation is sound. At the pivot of the dynamics of the three mutually interative computer system software environments (as earlier defined in Article 5) something has moved. And that something is OI - Organisational Intelligence, or Business Rules (if your organisation intelligence has an aspect which is business oriented).




On the management and the dynamics of evolving systems

Let us pursue in thought this subtle change further ...
How might the evolution of such dynamics take form?
What is the limiting endpoint of that shift in the dynamics of things?

Simply it is this:

Perhaps some day there may be a mechanism
for getting the rest of the OI (or BR) out of the applications environment,
and into the internal environment of the RDBMS.

This, from the perspective of IT Management, would be a good thing. It would imply that the management of large scale computer systems software environments could be made dramatically simpler. The RDBMS Applications Software environment could disappear in totality, along with all of its problems and expense and change management. We would be left with only the first and second systems environments, and the third environment would no longer exist. (See Article 5)




Where should the Organisational Intelligence (or BR) dwell?

From the perspective of the organisation, the OI or BR is best resident in a place where it (and its change) can be effectively and efficiently managed. All organsations that we are considering in this series of articles have already made a reasonably large investment in their RDBMS environment and its support. (System Software Environments two and one respectively, from Article 5).

From the theoretical, and academic perspective, such a migration of organisational intelligence out of the applications software environment and into the RDBMS software environment would appear also to be a good thing, but for an entirely different reason ...

"To say it one more time, then:
In an ideal world, business rules would indeed be part of the data model --
there wouldn't be any artificial dividing line between the two --
and they would be supported directly by the DBMS"

-- C.J.Date (Comments on Foundation Matters, BRCommunity.com; October 2001)

Ideals are nice to strive towards, but the question has remained.
How do we set about this migration?

Let us assume that there will be some form of technological breakthrough next week, and this technical method of migration is determined to be feasible. What are the advantages of having everything (data and applications) internal to the RDBMS?

After the migration, in C.J.Date's Ideal World, what have we got?

We have the same First Environment (OS) Software systems in place. We have the same Second Environment (RDBMS) Software in place (with organisational data internal to it). We have migrated objects (containing the OI/BR) from the 3rd Environment (Application Software Code) to some corresponding series of Stored Procedures in the 2nd Environment (RDBMS).

We do a backup of the 2nd Environment (RDBMS) and we have everything (data & applications). The data is held in the same data tables within one or more databases, and the applications are held in a separate application database as stored procedures.

The 3rd Environment (Applications Software) no longer exists. We have no desktop applications software environment except some form of RDBMS Portal Client software which has no Organisational Intelligence coded into itself, and thus requires little or no change management issues. Its function is simply to provide a gateway to the internal services now totally intergrated within the RDBMS.

All development work is within the RDBMS and is by the creation and registration of stored procedures. Applications will be developed and deployed wholly within the RDBMS environment. A typical internalised application A will consist still possibly of n objects A1 to An, but they will be objects within the RDBMS. They will be RDBMS Stored Procedures.

After the migration, in C.J.Date's Ideal World, what of change management?

Change management will be reduced in complexity by a very large factor, as will also be the now mandatory attendant costs. The reason for this is simply because the Information Technology to be managed is now restricted to only two environments.

More importantly this factor of simplicity makes a great impact on what was previously considered as the Eleven Phases of Application Development and Change Management (See Article 6).

The diagram below is the same diagram which today is the blueprint on how program development costs are incurred in every large organisation which runs an RDBMS and associated (external) Application Software products. However, on the diagram below there have been crossed out all those phases of program development which are not internal to the RDBMS ...






Future IT Change Management? Will it be any Different?

To conclude this seventh article in a series of eight,
my hope is that future IT Change Management
will be substantially different,
providing that some form of path is found
whereby the migration so decribed above can take place.

In the next Article
I will outline such a pathway
of internalisation.

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