One method of reducing the impact is to design, develop and maintain a system in ways that will facilitate change and reduce the impact of individual changes.
This process is known as change isolation. Methods available to designers range from code level construction of objects, to business level purchase of commercial off the shelf products.
Using change isolation can:
- Reduce maintenance costs.
- Produce a modular design that is easier to understand.
- Reduce structural decay.
- Extend system lifespan.
- Defer system replacement.
- Enable re-use of modules or components.
In the past systems have been constructed in an ad-hoc way, with individual developments having no common strategy to enable best use of support resources.
A strategy, which focuses on the long-term support of systems rather than purely rapid development, is a worthwhile design goal from an architectural and financial viewpoint.
Software characteristics
Software is an intangible element of a computer system and has characteristics that are different to the physical hardware that is runs on. Some of the more notable characteristics are that:
- Software is developed - not manufactured.
- Software does not physically wear out.
- Software is custom built - not using pre-made components. Even today's commercial packages are initially 'custom built' and suffer
the same problems during their development and maintenance.
Clearly using this combination of everlasting bespoke components change is inevitable over a period of years.
A historical perspective
In the past software maintenance has not been emphasised as an important criteria in the production or acceptance processes. Yet the software maintenance task is the most expensive part of the life cycle (Foster [1993]).
Business systems written 15-20 years ago are still in service and have undergone many generations of changes. These systems are now virtually unmaintainable due to the constant application of changes and the loss of original designers in the workforce.
Many legacy systems require an extensive overhaul to remain competitive, however these applications are still fulfilling the business function. For this reason many managers are unwilling to commit the time and resources required to bring the systems up to date.
On ageing systems, modification takes additional research time because relevant documentation is incomplete. The unfamiliar construction also makes the understanding and reverse engineering time consuming.
Even the smallest change can cause the entire system to fail as it may 'unbalance' the previous generations of changes that have been applied.
In summary, legacy systems that power large corporations are often costly to maintain. They restrict corporate development because they cannot respond quickly to changes in requirements.
Costs in maintaining systems
The IEEE Standard for Software Maintenance (STD 1219-1993) defines maintenance as:
Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.
This definition states that the execution of maintenance starts after delivery, but this does not prevent software from being prepared for maintenance prior to delivery.
Previous research illustrates that the largest costs of software production occur after the 'development phase' is complete - contributing up to 75 per cent of the total.
It could be said that this costly maintenance is a result of poor requirement gathering and design. Assume it is possible to produce a perfect system, matching its requirements, 'right first time'. Would using today’s best practices reduce maintenance cost?
We know change is inevitable, some reasons are:
- Political decisions (e.g. introduction of a new tax).
- Hardware related changes.
- Operating system upgrades over time.
- Competition - new features to be added.
With the changeability of software, even if a system was developed 'right first time', it would require modification as it would need to change following its first use. The system is almost instantly complying to outdated requirements.
This proves that the maintenance cost is not only a function of poor design, but also a function of the changing customer or environmental requirements and the manner in which the system was constructed
Construction therefore may not affect function, but greatly affects future maintainability. In other words, there are good methods and bad methods that can be used to build systems if change isolation is a design goal.
The process of change
As modifications are made to a system the design will change. This can be a small design drift away from the initial concepts, or it can be perfective maintenance. Even if stringent project and process guidelines are adopted, the design will drift from its initial concept.
This effect is described as structural decay. The system may still meet its intended requirements, but it is no longer doing so in a manner intended by the system's initial specification. It will be using less efficient mechanisms than the original designers would have selected.
If structural decay is allowed to continue unchecked without procedures, documentation and a design that supports change, software will become uneconomic to maintain. It is at this point that a decision is often made to replace a system.
To ensure success, the replacement will receive:
- Fresh requirements gathering,
- Application of the latest tools,
- The latest design methodologies and best practices.
Today's legacy systems underwent similar processes during their development, however the downside of replacing a system is often not assessed.
There are invisible costs that, if unconsidered, may make the replacement system unexpectedly expensive. Here are some examples:
- Forgotten processes. The system becomes the process. Initial designs have been amended through generations of change and there is no other documentation to support the business processes.
- Problematic reverse engineering. Though there are tools and processes to obtain the system's function the result does not always represent today's requirements - but an approximation of earlier requirements
- Hidden investment. Since the initial development, the support team may have invested many man-years in fine tuning the system to provide improved functionality, performance and features.
- System refinement. The new system will have to evolve from the first delivery. This process is incremental and can take several years to complete.
Clearly it would be beneficial if systems were 'designed for change' at the outset, using methods that allowed modifications to be applied in a controlled manner.
Structural decay would then be limited, maintenance costs reduced and systems would simply last longer.
Carl Allen CEng MBCS CITP
