He feels there must be a change of attitude towards the subject before it's too late.
Maintenance is broadly the continuing work carried out on an information system after it has been installed and handed over to the customer and it comprises four main activities:
- Corrective. Sorting out software bugs which are (always) still present after hand-over.
- Preventative. Standard procedures such as weekly back-ups or data integrity checks to keep the system secure and fully operational.
- Perfective. Providing added functionality or 'bells and whistles' defined by the customer which was outside the scope of the original system specification.
- Adaptive. Modifying the system to cope with on-going changes in the environment, such as adding suitable reporting capabilities to satisfy new compliance requirements.
This report seeks to highlight the differences that appear to exist between the strategic demands of maintenance and the way in which it is currently handled professionally in the software industry.
Costs
Most traditional estimates from the 1970s and 1980s suggested that maintenance would take about 60 per cent of the overall time and effort spent on the development of an information system.
However, each year more and more lines of software code are added to the maintenance inventory as additional legacy systems are introduced and continue to remain in service.
In a collection of published data, Jussi Koskinen (Further Reading, below) establishes that a more modern figure could well be in the order of 90 per cent of the total system outlay.
Regardless of any specific conditions, today the cost of maintenance clearly exceeds the sum total of all other costs in the development cycle. And the situation, year on year, must be getting progressively worse.
Other sources provided by Koskinen quote actual spend figures. For example, in the 1990s the outlay in the US on software maintenance is estimated to have been more than $70 billion per annum.
In short, this is not a trivial problem and it would seem that maintenance is the most critical part of any software development program and increasingly warrants a comprehensive strategic approach.
Investment
Given the above statistics, how does the information industry handle system maintenance? The answer would seem to be, with only limited focus or interest.
I took some data from the public domain with the idea here is to compare maintenance with other key activities, principally design, and to use this approach to establish the importance of one activity relative to the others in the development process.
While the sources are all different, the overall shapes of the results are remarkably similar and nearly all point in the same general direction: here, unlike the costs, maintenance is handled as if it were about one tenth the importance of design.
Articles on Google. If the number of articles published correlate with what is considered important (or what is fundable for research, or what companies actually do business in) then the overall figures given are a fair reflection of current industrial research attitudes, perceptions and needs. That design is more important.
BCS professional exams. Here I looked at the word count in an exam syllabus document in order to reflect the relative importance of the different topics mentioned in the syllabus.
It's not a highly accurate pointer, but the general picture does indicate the priorities of a current student study programme. Once more the emphasis points towards design over maintenance.
Job opportunities. Again, taking a count of positions available for given areas of expertise, the same picture emerges. In this case, the employment situation simply mirrors the demand pressure from developers and users of information systems.
In passing, on the basis of these figures, one could hardly recommend anyone today to seek to become an IT system maintainer, there must be so much more money and jobs available in design.
Teaching/reference material. Finally, on different data, the same pattern emerges from counting pages in well-established textbooks. It's noteworthy that, for example, the first book allocates 15 pages out of about 700 to a topic which it admits is the most important activity in system development (50%+).
And all this compared to design which get nearly 10 times the coverage. Most books appear to give about four chapters to design, with only a few pages passing reference to maintenance.
However, the last book is unusual in that there's more discussion on maintenance than on design. Perhaps this is a more realistic approach and recognises the need for a rebalancing of priorities.
Analysis
One set of figures pointing in the wrong direction could be considered an aberration. However, four sets of figures taken from completely unconnected sources all providing a similar outline, now that's beyond the likelihood of a coincidence.
The problem is not new and this situation has continued largely unchanged over the last few decades. For example, in 1982 (with a follow-up second edition in 1988 – see 'further reading' below) G.Parikh raised the same problem of maintenance investment with much the same incomprehension as to how this situation could continue to be ignored by software professionals.
The only logical explanation is that the problem is cultural rather than technical or political. In other words, people continue to do what they do, however irrationally, because it's familiar and change is uncertain and threatening.
Compare the situation here with, perhaps, smoking or global warming. In these cases, the related facts were well known and reproducible, but it still took, is taking, one to two decades for public opinion to be ready to accept the facts and actually change the habit patterns of the majority.
So the problem here becomes, how to introduce a series of measures to enable maintenance to be properly handled in ten to fifteen years time.
Culture shift
Basically, all the required tools are in place, it's only the will to apply them that is in question.
Strategy: This has to be the overriding item. Senior management will have to understand that maintenance is a potential profit centre, not the currently perceived cost centre and that competitive advantage will accrue from a serious attention to maintenance procedures.
Maintainability: To apply effective maintenance, the design phases must generate a complete and functional documentation record. This will involve documentation standards, configuration control and archiving and the training of designers to provide these records.
Bottom up: Maintaining must be made attractive (financially), worthy of respect (professional membership) and intellectually challenging (formal qualifications).
Top down: To obtain the full benefit of reduced maintenance costs, initial investment will have to be made in providing dedicated facilities and professional staff (technical + management).
Maintenance continues to be a high-cost, low-interest activity and no-one seems to care.
To effect a change in current attitudes will require long term planning and stamina and this could, perhaps, start with teaching the new intake technicians and managers a more thorough approach to the subject. So, as a test, will the BCS review its exam syllabus? We shall have to see.
In a nutshell
- Maintenance is an important part of IT system development activity
- Various estimates put the relative cost of maintenance at about 60 per cent of the total system cost (i.e. it is strategic)
- Current prioritisation suggests that maintenance is allocated about 5% to 10 per cent of the total funding, training and effort (i.e. it's non-strategic)
- Tools are available to address these issues, but their application will require a significant shift in corporate culture
