 |
|
|---|---|
A Brief History | |
|
|
|
|
|---|---|
A Brief History | |
|
|
6) The Generic Change Management Cycle |
Whereas the cycles of change within the 1st and 2nd level software environments are usually of long period (eg: an upgrade to these environments may occur once every few years), the cycle of change management within the applications environment is often of substantially smaller duration (eg: a few times each year, and more in rapidly developing applications environments).
The following schematic outlines these eleven phases or steps that characterise the cyclic nature of change management in the applications software environment. At the center of the flowchart, depicted as a number of large sets of boxes, is shown the atomic nature of the actual program objects physically loaded into this environment.
These program objects A1 to An, B1 to Bn, etc, are the constituent program code for the packages A, B, etc. As mentioned earlier in this series of articles, a few decades ago these objects would have been largely Cobol programs. In todays world, these program objects could have been developed by any one of a large number of modern program development tools.
While the applications software environment may already have been rewritten any number of times in various new technologies of program development tools, the fact remains that its physical and theoretical nature has not substantially changed over the decades. The objects amassed in the center of the flowchart below might change their form and their inner language and expressionisms, but in terms of acting as an interface between the people of the organsation and the RDBMS, nothing much has altered, as the following diagram will clearly show:
Change requests can often be handled internally by the organisation if there is adequate support in whatever may need to be altered. More often, however, it is the case that organisations have selected a specific data applications software to do its record keeping, and this is maintained by another party.
The flowchart above shows the different steps that are necessary in order for both small and large scale database applications software changes. It is the management of this change described in the flowchart that is one of the more time consuming tasks with each and every organisations IT section.
Each of the steps outlined in the following review of the nature of change management within the RDBMS applications software environment is associated with resources, time and cost. However while the bulk of the organisations intelligence is literally sown into these multitude of program objects, and their dealings with the database, their change must be managed with exceeding care and forethought.
The nature of the change is two-fold in general:
The specifications of change include analysis of changes to the database structure (ie: schema) and corresponding conversions of associated data, or population of new data elements by some means. These database changes need to be tightly coordinated with the corresponding changes to the database application software.
(2) there is change to the applications software.
The specifications of change in the software generally attempt to exhaustively specify which x of the n objects are in need of change, and in every instance, what that change actually entails.
If not the IT Manager, then there is someone within the organisation who is responsible to oversee the process of change specifications, and to evaluate the proposed nature of the implementation of change according to these specifications prepared.
The change specifications might not have covered every little element of detail, or they might be too detailed when in this instance a general change might be effected in a simpler manner, or the proposed changes might be adequately catered for in the design.
If the specifications of change are OK, then approval is granted for the database software developer to proceed as specified. If they are not OK, they are sent back to the drawing board until agreement is reached.
Program development can be costly, and the provision of quotations for substantial modification and development is often standard procedure. Remember that the primary target of change here, in terms of the bulk of the cost/time/effort, is the changes to these x out of n database applications objects.
Again, it is usually the IT Manager, or some delegated Applications Development Manager who will give this go ahead.
If the costs are excessive, they may need to be approved by some expenditure committee within the organisation.
In this instance, alternate avenues of change might be explored. Such options are often a luxury when an organisation has already made substantial investment in a specific database applications package A, or packages A, B, C, etc.
Use of an RDBMS usually signifies high volume or large scale data processing, and thus often the change management issues are certainly not entered into without as much forethought as resources will permit.
The program developer works though the change specifications from the first program to the last of the x program modifications required.
This phase of the standard database software development and modification methodology is often just as expensive and time consuming as the prior stage of specification.
The specifications are usually prepared by a very experienced programmer, while the programming changes are usually based on a greatly reduced rate. However, the time for the program modifications can often exceed the specification time by many factors, especially if the changes are complex, and the existing database application product is complex.
At the end of this process, a decision will be made by software developer whether to release just the x objects changed, or indeed whether the scale of the changes warrants a full release of the n objects.
A draft release is prepared of all change. Documentation for the change, as well as replacement global application level application may also be required.
The quality assurance phase of development and modification is designed to identify any program faults or bugs introduced as a result of the given modifications to the code. This phase is quite necessary. Often contract or junior programmers are employed to perform certain sections of the development work, and their work needs to be checked and ruled off.
Time and costs incurred in this phase of the standard database software development method are increased when errors are identified. In such instances the unsatisfactory program objects are returned to the programmer for correction.
Here further development time and expense is incurred until an adequate functionality is QA’d. Once the entire development and/or modification project is quality assured, it is then generally pssed on to an account manager within the software developer, for imminent release to the end client.
If the development is being undertaken exclusively in-house then this approval is granted by the internal IT Development Project manager responsible for the delivery of the new functionality.
In any event, the change specifications that are incorporated into the newly devised code structures of these n objects (constituting the product suite) are given a final review at high level.
During this phase of the database application software change management some of the changes might already require change of their own, and other urgent modifications might need to be incorporated into the new release.
Change management involves many threads of change which need gathering at certain critical points of implementation. It involves coordination of many people and processes.
The issue of a new release of database applications software is usually a time of great activity.
When the new Release package is prepared at the Software House, or within the internal Project Development group, it typically consists of either a partial release or a full release of the software.
A full release is simply a package (eg: CD) that contains the entire n objects of the newly upgraded product suite.
A partial release is a package that contains only those x of n program objects that needed to be changed.
The footprint of the package is a term used to provide information about how much space the total number n of object program files uses.
All large scale database application software packages running on contemporary RDBMS usually have a very large footprint, and a very large n.
Often, the establishment of proper testing environments is a challenging project in itself to an organisation. QA of all newly received software is usually mandatory before it is installed into day-to-day production use.
The time and resources required to adequately perform QA on mission critical software components are usually proportional to the scale of data integrity issues that could conceivably be introduced (unintentionally).
Database application software products often go through various longer term development phases themselves, and at times they may appear mature and reliable, but at other time of change they may appear more susceptible to a range of problems.
The end-client QA phase is often important.
The implementation of change needs to be coordinated between a number of areas within the organisation. It is usually the IT Manager who coordinates various parties in the process of implementation.
There are two seats of change. The first is the database and the second is the desktop database applications software environment.
Generally it is the responsibility of the DBA to attend to the changes internal to the RDBMS, while the operations group are responsible for the deployment of the x or n objects to the client desktop or to application servers.
Analysis of the implementation of this packaged change needs to consider minimal disruption to the day-to-day production concerns of the organisation.
Implementing minor changes may require little or no coordination while the implementation of major change may require massive coordination. The scale of the organisation (large or small) is another parameter to be considered at this phase.
In the first instance, the DBA needs a timeframe within which specific database changes need to be made. For minor implementations these database changes can effectively be enacted at any time, and may be independent of normal day-to-day operations. Major implementations of change often require the database or databases to be under the minimal standard production use, and this is often out of standard hours of operation.
In the second instance, the operations group or whoever is responsible for the physical deployment need to physically substitute the redundant set of x or n program objects with the newly delivered series of x (partial suite) or n (full suite) objects. Again, if inconsequential, this substitution can be effected at any time. However for major releases such deployment is generally reserved as an out-of-hours activity.
In the third instance, the software provider often needs to be on-hand or available in the event that there are unforseen problems in the functionality of the delivered software, or in the functionality of the database conversions.
In the fourth instance the IT Manager may need to be available in order to either approve the implementation, or to roll it back in the event of insurmountable problems.
1) Phase 3 back to Phase 1: Inappropriate change specifications.
2) Phase 6 back to Phase 5: Inappropriate program modifications.
3) Phase 9 back to Phase 6: Inappropriate program modifications.
It always pays to be watchful of any actual slippages at these points, and to determine their cause.
Recently there have been many different methods of program development utilised to create and maintain the planet’s stock of RDBMS application software.
When the database software is in a rapid development phase (for example when it is ported from one technology to another following historical developments in the technologies of database software programming) its changing nature is often more difficult, more resource consuming, and excessively costly to manage.
On the other hand, when the database software is stable and has been running in production for long periods then its change is easier, less resource consuming but still almost as costly to manage.
Change management demands are usually handled at the IT Management level by means of priority queues. Teamwork and communication within the IT group is often absolutely essential, and mandatory for complex change management issues.
It is change management of the RDBMS Applications Software environment which represents the excessive cost and excessive pain associated with IT Management. This has been the case for a number of decades. No change in these features of change is expected. The situation looks grim for IT Management and for the organisational IT Budget.
It looks to be a situation only retrievable by a specialist who is skilled in impossible tasks. I have such skills by experience and by trade, but before I present an alternative plan to do away with the thrashing about in the RDBMS Applications Software environment, I thought it prudent to scout about and determine what some of the database experts are looking towards, and what their expectations are of any form of future solution, given the outline of the problems associated with IT Management in the past and in the present day.