 |
|
|---|---|
A Brief History | |
|
|
|
|
|---|---|
A Brief History | |
|
|
5) Change Management & Systems Environments |
It is usually the IT Manager of an organisation who has the responsibility of establishing and maintaining an appropriate schedule of change management. If it is not the IT manager then usually some person either internal or external to the organisation is delegated the task. The task involves unusual analysis skills, and the coordination of sometimes a great number of change threads which are interwoven together due to the nature of the change.
Different changes imply different change management schedules. Small changes might not even be a planned or scheduled event, while large scale change needs to be approached on a far more systematic basis. In the following article we examine the nature of the change management cycle in great depth. In this article we will simply introduce a few definitions of terms, and establish some form of understanding as to what constitutes the generic information technology environment of any given organisation.
In reality there could be literally tens of thousands of the client machines, and possibly hundreds of the database servers in a very large network. It is also quite possible that there will exist other dedicated server machines for the specific purpose of providing computing resources to run the application software. These machines are called application servers, and highlight the extent to which the database applications environment may dominate the resources of an organisation.
At the foundation we have:
In the middle we have:
Second Environment:
RDBMS Environment:
And at the top layer we have:
Third Environment:
RDBMS Application Software Environment:
COROLLARY:
Internal to the Organisation:
The first exception is the IT Operations staff who admin the RDBMS Support environment. The second exception is the Database Administrator (DBA) and delegated equivalents. The third exception is the IT Manager, iff the IT Manager has hands-on experience.
Obviously further exceptions exist when consideration is given to internally driven or externally driven application development environments, but such development environments need really be considered in their own right, and as a separate issue alongside the day-to-day production consideration of managing and automating the living and breathing organisation as it exists today.
Such a classification system also reveals some of the otherwise hidden agendas of change management. So what are these agendas of change management, and what is hidden about them?
To answer this question we need to see first hand some samples of the kinds of change management issues, how such issues are met and resolved, and how other issues seem to re-occur at certain routine intervals, and can in fact be planned for months in advance.
Change management issues in the Operational software layer have not really substantially changed except perhaps in the frequency of changes. In prior decades there was certainly change of operating system software, new releases of terminal and peripheral microcode and other system utilities used in support of the DBMS. However in these current times the cycle of replacement processors and memory and DASD and motherboard are far less dependent upon one another, with multiple competing vendors.
However, to be fair, the quality of the delivered technology has also been improving dramatically through the decades, and consequently the device failure statistics are in good shape, all things considered. As a result, it is becoming rare that operational stability is compromised at all in this foundational environment of the computer systems software, except at the time of scheduled upgrades, which can be coordinated out of hours.
All the other higher levels (two and three) of (RDBMS related) computer systems software rely on this foundational support level to be working to some specified degree. In this sense it is quite foundational. Also, to a certain extent, change management in this environment is purely a technical issue once certain commitments and decisions have been made.
Equally valid is the view that this entire level of operational software needs to be considered in a redundancy situation to properly appreciate its overall contribution to the management of the ensemble of environments, 1, 2 and 3.
As a summary we may certainly say that there is indeed a constant target of 100% system availability driving this unit amidst three. This is often represented in the dedication of IT staff working in this environment, and to inhouse organisational technical expertise in the environment.
The Second Environment: The second level of computer systems
software as defined in the immediately prior list, is the RDBMS itself.
Here also there is a constant target of 100% RDBMS availability driving
this second unit of three. Here also the innate work ethic aims for operational
stability and minimal, if any, downtime. Generally, however, as with the
first level of software, it is only appropriately delegated IT staff who
are engaged in any change management practice in this environment.
The key player here is the Database Administrator (DBA) for the organisation. The DBA is instrumental in effecting all change management schedules against the production database(s). It should also be noted clearly that in today's world, the actual forms of software performing 1st and 2nd environment functions are heavily supported concerns, whereas this is certainly not always the case for the 3rd environment.
The Third Environment: The third level of computer systems
software as defined in the immediately prior list, is the RDBMS Applications
Software environment. Here also there is a constant target of 100% availability
driving this third unit of three. However, there is a big difference with
the type of software found roaming around this third environment.
For a start, as mentioned above, database application software is a far more specific commodity than software classified in the earlier two levels. Typical RDBMS installations are based on a small set of Level 1 and Level 2 software combinations. For example, Windows, UNIX, DB at Level 1 combines with SQLServer, DB2 and Oracle at Level 2 (Let's say a dozen varieties) to probably cover 85% of all planetary RDBMS establishments.
In comparison, when we examine the nature of software resident in this third of the systems environments, we immediately find evidence of huge and chaotic diversity from organisation to organisation. The simple reason for this is that different organisations have different needs in the applications software environment, level three, whereas at the earlier two levels, despite perhaps being totally different organisational types, the first and second environment software might easily be exactly the same.
As may have been mentioned beforehand, it is this third environment that represents the entire organisation's interface to the RDBMS, and change management in this environment is in everyone's face, so to speak.
In order to better appreciate the complexities attendant with this third eminently visible environment, we need to examine in greater depth the constituent atomic parts of typical applications software packages A, B and C for example. The following diagram provides a mechanism to visualise what might be described as the atomic units of the applications software environment, the individual program modules A1, A2, A3, ...An etc. The diagram also shows the direct relationship of this third environment (RDBMS application) software to the second environmental software layer, that of the RDBMS itself.
Additionally represented in the diagram are the RDBMS database tables and stored procedures, both of which are routinely referenced by way of mapping the individual program modules A1, A2, A3, ..., An ... etc to each RDBMS object, and vice versa ...
The detailed change management considerations need to extend to this atomic level of the applications software environment not by choice, but by necessity. This is the way history has brought the path of IT Management of production RDBMS establishments. The organisational intelligence is still more or less completely resident in the same place it started out --- in the application software code.
Each of the objects deals with one or more of the database tables, and between all of the objects A1 to An, all data tables contained within the database A are maintained (INSERT, UPDATE, DELETE).
Product B might typically represent some financial record keeping activity that the organisation is obliged to maintain, and as seen in the diagram, it has its own series of program building blocks B1, B2, B3, ..., Bn ... etc. Likewise these are mapped against the RDBMS database B, specific for Product B, table by table, and column by column, as was the case with Product A.
Product C might typically represent some subsiduary organisational data, and the same design as applies to A and B applies to C.
In the case where the vendors of such products A, B, C might agglomerate all constituent programs into one super program, then the diagram above is representative of the sub-modules of the agglomerate, which would require separate resolution and maintenance anyway, at the source code level, by the vendor.
Sufficient to conclude this article with a quick summary of new information presented or emphasised here:
From the IT Management perspective, it is useful in examining a specific view of the production environment whereby there are separated three distinct environments of computer systems software. These are:
The first two environments are comparitively easy to manage and are likely to be some generic standard, whereas the third environment is often complex and more difficult to manage. The first two environments are invisible to the organisation, but the third environment is the organisation's interface to the data.
In the following article we will examine in depth the process of change management within the 3rd Environment, and see just why it is one of the more difficult tasks of IT Management. In this next article we will introduce the notion of IT Related costs into the equation.