04/17/2008 by Peter Helfenstein
Continuously growing system complexity
Nowadays, existing IT systems cover more or less the complete business processes. In most cases, strategic decisions to buy commercial software – instead of making software – are in place. New developments of complete business systems are the exception to the rule. Against the background of this situation, a new concept of developing applications is required: It is no longer build-centric, but rather change-centric, also see item #4 in the Blog written by Niel Roberston, CTO at ALM-vendor Newmerix.
Whereas the development of new systems used to be a creative, innovative challenge, the requirement now is to make a varying number of minor or major changes in existing systems or to customize them. The systems are completely built up, they are in use, they are linked to several technical and productive entities or between one another, often via complex mechanisms, and they are localized – covering all system levels from small program components and local customizing up to selected business functions and entire business processes.
In addition, modern systems are more and more composed from reusable components. Service-oriented architectures allow a clear separation between business processes and functional system components. A prospective design would also offer the possibility to protect services against negative effects caused by partial changes of the system. But obviously, new dependencies have arisen in such a landscape of reusability. Functional components are used by different business processes, and changes made within one business process or one business function may have an effect on various parts of the system.
System consolidations contribute to this problem. In order to save hardware and software costs, business processes and functional components are locally or globally consolidated on the same system. This implies that changes which result from local requirements must always be seen in the context of the whole consolidated system.
Impact on the system and on changes
So before making changes, these interdependencies must be well understood to avoid unpleasant surprises. Experience has shown that in general there are several types of effects on the system which must be recognized and got under control.
Which components are integrated parts of the system across all levels and must be changed? It is crucial to not only look at components used to run the system but also at all descriptive or organizational objects used during the project. Which other components, that seem to be independent parts of the systems, will be influenced? What is the effect of the change on planned or running parallel projects?
Another point should be taken into account: In how far will the change add to the existing complexity? Sooner or later, you can make any system too complex to be maintained.
Finally, the degree of complexity of the existing system must be considered under the aspect of the planned changes. Possibly, a system analysis would bring forward that the system is too complex for even a minor change to be undertaken. An analysis is the only method to get to a realistic estimate of the “environmental tolerance” of a change.
However, far-sighted concepts of system design or the protection of components such as company templates could be targeted as preventive measures to create a system landscape which minimizes the effects of changes or identifies undesired changes and blocks them.
IT Impact Management means IT Impact Analysis & IT Environment Protection
In this scenario, IT Impact Analysis and IT Environment Protection become core disciplines of system development. For commercial software, there are first approaches to this task. Informatics organisations, however, which follow a defined concept of integrating Impact Analysis and Environment Protection into IT processes, are still rare. Instead, enterprises usually make an unnecessary effort all across the application lifecycle at a high price: The projects get too complex and beyond control, dependencies are not recognized, thus tests are not run and errors are discovered not before the system is run.
However, there are ways out of this dilemma: Impact studies would help judging projects correctly. Even in situations, when parallel projects plan to implement changes of the same components, the process can be understood and controlled. Implementing changes in the context of different projects could even be a commonly targeted action. This would imply that the effort of understanding the component needs to be made just once. Since by an impact analysis the parts and aspects of the system, which will be affected by the change, are made visible, the right things can be tested and the quality of the system before roll-out into production can be tremendously improved. Installations of large commercial solutions can be adapted more flexibly to business requirements and be maintained and used for a longer period of time.
Stringently applied Impact Management, including Business and IT Change Impact Analysis and Environment Protection are rapidly gaining in importance. The use of commercial or newly developed software systems requires a new look on system building – every new requirement primarily leads to a change of the existing system.
Service architectures and business process management allow re-use, but at the same time the effects of changes are multiplied.
Change Impact Management, including Impact Analysis and Environment Protection, consistently integrated into the method of system development and supported by suitable tools, allows the systems to be changed across the lifecycle – in spite of a high complexity and with reasonable effort – and helps to avoid even more complexity with every change.
The benefit of effective Impact Analysis and Environment Protection can be immense. Commercial software installations and service architecture systems can be further developed with reasonable effort and at a high quality level. The systems remain flexible for business and IT and the response times for changes can be shortened. They can endure longer lifecycles without having to be substituted at an early stage because they have become too complex.