Roger Clarke's Change Control 1990

The recent enthusiastic discussions about the importance of IT as a strategic and competitive weapon have tended to concentrate on the development of new application software. But all significant corporations and government agencies are heavily dependent on large inventories of existing application software which support their ongoing operations. It is critical to the survival of organisations, and of their IS Managers, that the value of this software investment be maintained and exploited.

Software maintenance must therefore be undertaken and managed at least as professionally as software development. In the 1990s, however, reference to the 'maintenance' of the application software 'inventory' is too negative and reactive. It is essential that IS Managers stress the value of the corporation's investment in software, and encourage their staff to think of 'exploitation' of the application software 'portfolio'.

This paper provides an overview of the conventional concepts and practices of incident reporting and change control, and of the more advanced technique called 'configuration management'. These techniques are not merely reactive mechanisms used to control the efficiency of resource usage, but can be used proactively, to ensure the prompt delivery of systems changes necessary to the business strategy. IS Managers who realise their potential will gain a competitive advantage over their corporation's competitors and their own.

1. Information Technology Applications in the 1990s

During the early years of computing in business and government, the objective was the automation of existing systems, and the motivation was efficiency in clerical activities. As application software technology developed, the emphasis changed toward integration and rationalisation. Existing systems were interfaced, then multiple sub-systems were replaced with a single integrated application. At the same time, computing became a change agent, as organisations recognised opportunities to modify manual procedures and organisational processes and structures. Although efficiency and productivity remain a motivation, software quality and organisational effectiveness have become increasingly important.

Meanwhile there has been a significant increase in the risks to employees and the public inherent in Information Technology (IT) applications, and a consequential increase in the likelihood of the organisation being sued for harm arising from malfunctions in computer-based systems. As a result, software quality assurance has loomed as a much more important consideration.

In recent years, it has been claimed that the manner in which businesses compete with one another, and the way in which not-for-profit organisations, especially government agencies, implement their strategies, is through the creative application of IT (e.g. Parsons 1983, McFarlan 1984, Benjamin et al 1984, Ives & Learmonth 1984, EDP Analyzer 1984a, 1984d, 1986a, 1986b, Cash & Konsynski 1985, Porter & Millar 1985). Examples which have been put forward as demonstrating this thesis include airline reservations systems (particularly American Airlines' Sabre and United Airlines' Apollo) which since the late 1960s have become a vital factor in the profitability of airlines' operations; banking and funds management; and sales order processing (usually quoting American Hospital Supplies' innovative system). To this list can be added a wide variety of government agencies, including the Health Insurance Commission with its Medicare system of the early 1980s, the Department of Social Security with its StratPlan of the late 1980s, and the Australian Tax Office with its current Modernisation Programme (Carmody, 1989). The crux of the argument has been that to focus on efficiency and effectiveness motivations is too limiting, and that in 1990s flexibility and adaptability are vital motivations for an organisation in its application of IT.

A related development, which commenced during the 1980s and will continue apace throughout the 1990s, is the emergence of multi-organisational systems. In such systems, data flows directly between applications in computers installed in different organisations. Some multi-organisational systems are a form of competitive application, in that they cement an alliance between corporations, to the detriment of those organisations' competitors (Johnston & Vitale 1988, Wiseman 1988). In many cases, however, any competitive advantage which may be gained by an alliance is unsustainable against reaction by competitors, particular by all competitors in concert (Clemons & Row, 1987). Most commonly the long-lived multi-organisational systems are cooperative schemes involving all players in the market. This has been particularly marked in inter-bank EFTS (which has assisted banks to resist the intrusion of non-bank financial institutions into their marketplace), and in EDI (Swatman & Swatman 1989). Other collaborative schemes include the electronic trading of equities, options, commodities and livestock; and the worldwide aircraft components inventory system.

In routine administrative and accounting systems, efficiency and effectiveness considerations continue to be important. It is increasingly recognised, however, that organisational survival in a competitive world is dependent on key IT applications being flexible and adaptable, not only reactively to externally and internally imposed change, but also proactively in order to support the organisation's competitive and strategic objectives. Hence, in key systems, efficiency and effectiveness are constraints rather than objectives.

2. The Application Software Portfolio

Throughout the history of commercial and administrative computing, there has been a tendency to concentrate on the development of new systems. Initially this was of course unavoidable. What is surprising is that, as the inventory of existing applications has grown, the culture within application software organisations has remained stagnant. The glamour in the application software profession continues to be associated with the development of new systems; with analytical techniques such as Information Engineering, Entity-Relationship Modelling, NIAM and normalisation techniques; and with development tools such as 4GLs, CASE, expert system shells and object-oriented programming. The 1980s movement in strategic, competitive and multi-organisational systems has further accentuated this tendency, by concentrating on the development of new systems.

Yet the majority of large organisations recognise that 80% of the productive time of their professional staff is committed to the maintenance of existing systems. Moreover, most professionals and far too many managers make this admission ruefully, and talk of maintenance work in disparaging terms. The fact is that organisations are heavily dependent on the applications which already exist, and priority should be accorded to their maintenance, not only in the sense of 'dropping everything' in order to fix a problem in an operational system, but also in terms of rewarding staff more highly for maintenance than for development efforts. The time has long since arrived when the professionalism of application software staff must be measured in terms of their ability to service the users of existing applications (Clarke, 1987).

In the 1990s, 'maintenance' of the application software 'inventory' is too negative and reactive in tone. It is essential that IS Managers stress the value of the corporation's investment in software, and encourage their staff to think of 'exploitation' of the application software 'portfolio'.

In most industries the business product is dependent on application software to support quick and effective design, procurement, manufacture and delivery. In the information industries, such as finance and insurance, the role of IT is even more central, because the business product does just depend on application software; to a large extent it is application software. Businesses compete through the adaptability of their business products, and the pace of change does not leave time to write entirely new applications. The successful companies of the 1990s will be those which can exploit their existing application software to deliver new products and services before their competitors.

3. Exploitation Of Application Software

In order to take full advantage of the organisation's existing software, the IS Manager must be closely integrated into the organisation's executive management. He must closely monitor changes in the organisation's corporate strategy, and in the critical success factors of the organisation's enterprises and programmes. He must appreciate which of the organisation's existing applications are the most important for corporate strategy. In regard to each of the key applications, he must know the extent to which the software is flexible and adaptable. Using this knowledge, the IS Manager must judge when to be proactive, and invest in preventative maintenance such that he can answer the calls of management for fast change in key applications.

In order to achieve these ends, the IS Manager must ensure that a range of techniques and skills are effectively implemented within his organisation. Professionalism in software exploitation involves program debugging, rehabilitation and re-structuring skills, and it is likely that many staff will need schooling in these techniques. It is also essential that the 'meta-database' of information concerning application software is maintained and accessible. Internal information systems are likely to need attention, to ensure that problem-programs can be identified and attacked. Considerable effort must be made to ensure that communications between users, user managers, and support staff is facilitated, to ensure quick, reliable and enthusiastic transmission of profit-making ideas from initiator to implementor.

The existing software maintenance literature (e.g. Lientz & Swanson 1980, Glass & Noiseux 1981, EDP Analyzer 1981, 1983, 1984b and 1984c, Martin & McClure 1983, Vessey & Weber 1983, Couger & Colter 1985, Parikh 1986) contains much of value, but is inappropriately oriented for the needs of the 1990s. For most organisations, the agenda proposed in this paper represents major change, and requires management initiative, not merely to instigate the necessary changes, but also to ensure that they are carried through. The evolution of a 'software development department' into an 'application software department' involves more than changes to job-titles. Re-organisation (e.g. from predominantly functional or project-based, toward operational division or dispersed structures) may successfully signal to staff the new order of things. But deeper factors, such as the education and training of staff, their professional orientation, their motivations, and their rewards mechanisms, must be progressively revised and refined.

This paper focusses on a cluster of techniques, commonly referred to as incident reporting, change control, and configuration management, which have great potential as means whereby application software portfolios can be exploited. They are well-known, yet, on the basis of research into the activities of corporations and government agencies (Bottle 1988), appear to be far too little used.

4. Incident Reporting

The most basic requirement for flexible and adaptive IT applications is clear and quick communications between end-users and support staff. Such a system is reactive, addresses problems rather than opportunities, and is concerned with applications' existing functions rather than with new ideas. Nonetheless, a great deal of the benefit of any strategic application is the service which it provides to employees and clients, and it requires effort to insure the existing investment.

Incident Reporting is initiated by an end-user who detects some performance of the system which he regards as in some sense 'wrong' or 'unhelpful'. There are many possible reasons for the person's feeling of discomfort. In addition to program error or inefficiency, and hardware malfunction at any point in the network, there may be design errors or misunderstandings involved, poor mapping of a package onto a particular division's requirements, poor documentation (on-screen or in the procedures manual), or inadequate training of end-users or support staff.

It is important to the system's effectiveness that communication be encouraged, since it is not the internal efficiency of the IS Department which is of greatest concern, but rather the overall organisational efficiency and effectiveness. For this reason it is highly desirable that a neutral term such as 'incident reporting' be used rather than a pejorative one such as 'fault reporting'. IS staff need to look on an Incident Report as an opportunity to refine and improve the service, rather than as an assault on their professional dignity, to be sternly resisted.

There are a variety of ways in which incident reporting can be implemented. Hard-copy has been conventional, and may well be quite sufficient in the case of relatively obscure incidents (where speed of response is not critical) and complex problems (where investigation depends on more than a couple of sentences of oral description). Hard-copy may of course be expedited using facsimile-transmission.

Soft-copy is increasingly tenable, and many applications now include one or more screens for the notification of problems. These are valuable for relatively routine and structured problems (e.g. terminal and printer problems, slow response times), but are less effective in more complex circumstances, particularly where the user needs to transmit the contents of a screen or printout, or include a copy of an external document such as a customer order. Drop-in or telephone support may be offered. Help-desks or Information/User Support Centres provide fast response, although at the risk of failing to impose on the user the discipline of thinking through the problem before seeking support.

Critical aspects of any incident reporting system are the registration of reports; frequent periodic reporting on report processing; the provision of feedback; and the provision of feedback in constructive form (i.e. positive, or gentle negative). Feedback should be not only to individual users on the outcome of their own reports (to provide the solution, or to indicate the nature of the fix being implemented), but also to the user community in general (to confirm to them the importance of clear and well-documented reports, and of the incident reporting system as a whole).

In the context of clerical automation in the 1970s and systems integration in the early 1980s, incident reporting was a means of asset protection and control. In the competitive applications era of the 1990s, it must be recognised as a means of ensuring the quality and effectiveness of key applications, through the recognition of software errors and inefficiencies, and of 'soft spots' in manual procedures, documentation, and staff training.

5. Change Control

Change Control is a technique for the management of modifications to existing application software. Compared with the reactiveness of Incident Reporting, Change Control recognises the need for adaptation to externally imposed change, and looks for opportunities for internally instigated change. It is concerned not only with adaptation of an application's existing functions, but also with its extension to include new functions.

Exhibit 1 shows the procedures involved in a Change Control system. A Change Control Request is originated by any appropriate person. It is circulated among the interested parties, and progressively expanded. When all parties consider it to be complete, it is considered for implementation, and either scheduled, withheld to a later date, or perhaps rejected. In most organisations pragmatism rules, and change requests which are unlikely to be approved attract little attention, and are either withdrawn or rejected without a great deal of effort having been invested on them. A special case arises where a request's resource implications are recognised from the outset to be relatively large. Circulation and expansion of such requests requires prior approval-in-principle. Factors which must be considered in reaching a decision on implementation include:

the benefits which will result from the change;
the resources required to implement it;
the relative importance of the request compared to others; and
the inter-dependency of change requests.

A Change Control system requires infrastructure. A Panel must be defined which represents all interests involved, typically the various user groups, the designers, the programmers, the integration-and-testing team if one exists, and computer operations. This Panel must meet 'in the mind' continually, through the comments written on Requests, and 'in the flesh' periodically (say fortnightly) to make formal decisions about particular requests whose documentation has been fully completed.

It is essential that a set of 'controlled documents' be defined. As a minimum this must be the program, database and I/O specifications, and the user and operator procedures manuals, but may also include such documents as the requirements definition, the functional specification, the system specification, and the testing specification. The Change Request is complete and ready for the Panel's consideration only when all necessary changes in every such document have been prepared, checked and signed-off by each Panel-member. This further implies that for every such controlled document, one Panel-member must be designated as the person responsible for drafting the necessary changes to that document, and another as the primary person responsible for checking that person's draft. To ensure quality of product, however, it is desirable that the approval by the Panel of a Change Request be regarded as constituting joint responsibility for its contents.

Exhibit 1

In any significant application, it is not economically feasible to undertake a continuous stream of modifications. One reason is that the testing necessary to provide a satisfactory level of quality assurance takes so long, and costs so much, that continual test-runs are economically infeasible. Another reason is that dependencies exist among change requests, requiring some to be implemented in conjunction with others. Yet another is that clients cannot be subjected to continuous change, but must be provided with new versions reasonably infrequently. In addition, new versions must be released in a planned manner, preceded by information about differences between the old and new versions, especially where changes in manual procedures must be coordinated with the software changes. A further aspect of change control is therefore the assembly of change requests into packages.

In the contexts of automation and of integration, change control was a means of prolonging the life of an application, and initiators were generally users at the operational and supervisory level. In the context of strategic and competitive applications of IT, change control must be increasingly a proactive measure, driven by business needs, and initiated by functional managers.

6. Configuration Management

Because of the significantly increased complexity of contemporary applications, it is now much more difficult to manage the components of an application, and ensure that they are all compatible. One source of the additional complexity is the number of different internal libraries through which a critical application passes, including a production library, a development library, a library for urgent (e.g. overnight) fixes, a testing/Quality Assurance library, and perhaps an acceptance testing library. It is vital to ensure that changes are undertaken on the appropriate library/ies. For example a fix, or an urgent modification, may leap-frog a change package. A means is needed to ensure that such fixes are also incorporated into the change package, otherwise the future release will take the user 'two steps forward, one step back'.

A further source of complexity in large organisations is the existence of multiple variants of the same software. This arises variously because different branches or regions run different variants of the same application on different machines or under different operating systems; or because different clients have customised variants of the application; or because some users have not yet upgraded to the latest 'release'. Hence corporate headquarters might be using the MVS version at level 6.0, while Brisbane is on VSE version at level 6.0 and Perth on the VSE version at level 5.0 with patches 5.11 and 5.12.

Most suppliers provide at least rudimentary source-code management as part of their systems software. However standard products generally do not provide a complete environment for managing source-code, object-code, and associated files and documentation. To provide the necessary discipline, a technique called configuration management has been co-opted from electronic products engineering (Bersoff et al 1980, Buckle 1982, Bersoff 1984, Edwards 1984, 1985, Babich 1986). A configuration is the defined set of objects which comprise the product. These objects include all components of the application, their inter-relationships, and how they are to be used. The types of components involved are not only the more obvious ones (e.g. source, object and executable files), but also the JCL/Procedures/Scripts used to generate, compile and link the programs, and also to execute them; any application-specific copy libraries (in a COBOL environment), macros and subroutine libraries; data schema definitions; technical documentation; manual procedures; and standard macros, system libraries and systems software used by the application.

Configuration Management is the identification and maintenance of the configuration of a software product, throughout the product's life, and including both successive and parallel product versions, for the purpose of systematically controlling changes and thereby maintaining the product's integrity and traceability. Concepts fundamental to it include:

the 'component' (discussed above);
the 'form' of a component (in particular a program may exist in a variety of forms, including source, object and executable; and in some environments so too may the data schema and I/O specifications); and
the 'version' of a component, which enables successive variants of each component to exist.

A 'baseline' is a set of versions of components which make up a version of the product as a whole. An 'update' is a set of later versions of components which can be superimposed over a 'baseline' in order to produce a revised valid version of the product as a whole. Forms which an 'update' may take include a 'fix' which is distributed to user sites by tape, diskette or telecommunications link, and telephoned or written instructions on how to make an urgent 'patch' into a running system. Updates are generally issued in order to provide fixes for errors, whereas new baselines are usually issued in order to deliver additional or changed functionality and, in the process, fix less urgent errors. Clearly, it is imperative that a new baseline incorporate all modifications which have been made by way of intermediate updates.

A small number of specialised products are available to support Configuration Management, and have been used in defence and industrial applications for some time. To date they have been relatively little used in the management of commercial and administrative systems. From the viewpoint of automation and integration, it is a means of ensuring control and quality, and avoiding lawsuits. In the context of strategic and competitive applications of IT, configuration management is a means of ensuring the deliverability of changes necessary to the business strategy. IS Managers who realise the potential of configuration management will steal an advantage over their competitors.

7. Conclusions

This is an era of strategic and competitive applications of IT, many of them extending across the boundaries of organisations. Because of the unavoidably long lead times involved in the development of complex new application software, it is essential that corporations exploit to the full their existing applications portfolio. This requires a much more positive and proactive approach to the use of incident reporting, change control management and configuration management than has been evident in the past.

Bibliography

Babich W.A. (1986) 'Software Configuration Management' Addison-Wesley, 1986

Benjamin R.I., Rockart J.F., Morton M.S. & Wyman J. (1984) 'Information Technology: A Strategic Opportunity' Sloan Mgt Rev. 25,3 (Spring, 1984)

Bersoff E.H., Henderson V.D. & Siegel S.G. (1980) 'Software Configuration Management' Prentice-Hall, 1980

Bersoff E.H. (1984) 'Elements of Software Configuration Management' IEEE Trans. on Software Eng. SE-10,1 (Jan 1984) 79-87

Bottle R. (1988) 'Software Change Control: The Australian Experience' Working Paper, Department of Commerce, Aust. Nat'l Uni. (November 1988)

Buckle J.K. (1982) 'Software Configuration Management' Macmillan, 1982

Carmody M.J. (1989) 'Modernisation: The Australian Taxation Office Approach to Introducing New Technology' Proc. SOST'89 (Eds. Clarke R. & Cameron J.), Aust. Comp. Soc., May 1989

Cash J.I. & Konsynski B.R. (1985) 'IS Redraws Competitive Boundaries' Harv. Bus. Rev. (Mar/Apr 1985) 134-42

Clarke R.A. (1987) 'Software Maintenance' Series in Computing Australia, September 1987

Clemons E.K. & Row M. (1987) 'Structural Differences Among Firms: A Potential Source of Competitive Advantage in the Application of Information Technology' Proc. Int'l Conf. on Info. Sys., Pittsburgh, December 1987

Couger D.J. & Colter M.A. (1985) 'Motivation of the Maintenance Programmer' Prentice-Hall, 1985

EDP Analyzer (1981) 'Easing the Software Maintenance Burden' 19, 8 (August 1981)

EDP Analyzer (1983) 'Replacing Old Applications' 21, 3 (March 1983)

EDP Analyzer (1984a) 'Information Systems' New Strategic Role' 22,1 (January 1984)

EDP Analyzer (1984b) 'Rejuvenate Your Old Systems' 22, 3 (March 1984)

EDP Analyzer (1984c) 'Tools to Rejuvenate Your Old Systems' 22, 4 (April 1984)

EDP Analyzer (1984d) 'Developing Strategic Information Systems' 22,5 (May 1984)

EDP Analyzer (1986a) 'Getting Ready for Strategic Systems' 24,9 (September 1986)

EDP Analyzer (1986b) 'Uncovering Strategic Systems' 24,10 (October 1986)

Edwards L.E. (1984) 'Configuration Management: An Overview' 33-10-10 (1984) in Auerbach I. (Ed.) 'Systems Development Management' Auerbach, 1985

Edwards L.E. (1985) 'Configuration Management: Implementation' 33-10-20 (1985) in Auerbach I. (Ed.) 'Systems Development Management' Auerbach, 1985

Glass R.L. & Noiseux R.A. (1981) 'Software Maintenance Guidebook' Prentice-Hall, 1981

Ives B. & Learmonth G.P. (1984) 'The Information System as a Competitive Weapon' Comm. ACM 27,12 (Dec 1984) 1193-1201

Johnston H.R. & Vitale M.R. (1988) 'Creating Competitive Advantage with Interorganisational Information Systems' MIS Qtly 12,2 (June 1988) 153-65

Lientz B.P. & Swanson E.B. (1980) 'Software Maintenance Management' Addison-Wesley, 1980

McFarlan F.W. (1984) 'Information Technology changes the way you compete' Harv. Bus. Rev. (1984) 98-103

Martin J. & McClure C. (1983) 'Software Maintenance: The Problem and Its Solutions' Prentice-Hall, 1983

Parikh G. (1986) 'Handbook of Software Maintenance' Wiley, 1986

Parsons G.L. (1983) 'Information Technology: A New Competitive Weapon' Sloan Mgt Rev. 25,1 (Fall, 1983)

Porter M.E. & Millar V.E. (1985) 'How Information Gives You Competitive Advantage' Harv. Bus. Rev. 63,4 (Jul/Aug 1985) 149-160

Swatman P.M.C. & Swatman P.A. (1991) 'Electronic Data Interchange - Implications for Industry' Proc. SOST'89 (Eds. Clarke R. & Cameron J.), Aust. Comp. Soc., May 1989

Vessey I. & Weber R. (1983) 'Some Factors Affecting Program Repair Maintenance' Comm ACM 26,2 February 1983, pp.128-134

Wiseman C. (1988) 'Strategic Information Systems' Irwin, 1988

Personalia Photographs
Presentations
Videos Access
Statistics

The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 65 million in early 2021.

Sponsored by the Gallery, Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer

Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 10 July 1998 - Last Amended: 10 July 1998 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/SOS/ChgeCtl90.html
Mail to Webmaster - © Xamax Consultancy Pty Ltd, 1995-2022 - Privacy Policy