A Brief History
7) Future IT Change Management $trategie$
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.
MTM Problem Resolution Notes
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.
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.
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).
Simply it is this:
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:
-- C.J.Date (Comments on Foundation Matters, BRCommunity.com; October 2001)
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"
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?
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.
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 ...
In the next Article
I will outline such a pathway