Developing and implementing a good configuration management system can be a difficult and complex process. Many challenges complicate the implementation process and these include the following:
· Cultural challenges.
· Organisational challenges.
· Technical challenges.
Figure 3-1: Main implementation challenges
Until recently, configuration management was an obscure and poorly understood process. With the introduction of quality management systems, based on ISO9000 and similar standards, awareness of configuration management and its importance has improved. There are still major challenges however.
Before one commits huge investment in procuring tools and consultancy, it is important to ensure that the culture within the organisation is ready for change. The expectations of people must be influenced to increase awareness of configuration management and why it is needed. It is not necessary to “convert” all to the ways of configuration management but it is important to ensure that all realise the changes that are likely to be brought about when a configuration management system is implemented. This preliminary education should enable one to identify the main cultural challenges that are likely to be encountered within the organisation.
It is important to identify the following at an early stage with the aim of allocating effort and work to address any likely problems:
User perceptions: What are the current user perceptions and what are their expectations? Are users currently involved in the change, release and approval processes? Are they interested in participating in such processes? It is important that users are made aware of the formal and structured processes that will come into operation after the introduction of the configuration management system and it is important they are aware of the impact of such processes on the development process! Users are an integral part of the configuration management system and their participation is vital. Users may shun participation in configuration management under the assumption that the process is technical and does not involve non-technical users. It is important to highlight the fact that users have a key role to play in.
Management perceptions: Do managers view configuration management as an essential support process? Are they prepared to provide guidance, support and funding? What priority are they likely to associate with configuration management? Do they realise and appreciate the level of investment required to implement a configuration management system? Managers must be aware of the additional costs and the impact on timescales that arise once a configuration management system is employed. It is also important that they appreciate the long term benefits and returns.
Developer perceptions: Have developers used a configuration management system before? Do developers view configuration management as an essential process or do they view it as a bureaucratic system that is designed to slow down development? It is important that developers are made aware of the additional controls that will be introduced and the additional formality that will be required once a configuration management system is introduced.
When assessing the likely cultural challenges it is important to base one’s judgement on past performance as well as on current responses. Some users, managers and developers are inclined to support and agree to a concept, but are likely to be less enthusiastic when this concept affects their day to day working practices. It is important to assess what people currently do and compare this with what they are likely to do once the configuration management system is implemented. The wider the gap, the higher the challenge.
Cultural challenges manifest themselves in different forms and at different stages of development.
Change control: change control is an integral part of configuration management and users are the most likely sources of requests for change. Users must participate in the change assessment and authorisation process. Also users must be aware of the complications that arise due to frequent changes in requirements, especially those that come in the later system life cycle of a project.
Approval and baseline production: establishing a baseline from which development is progressed is a key configuration management requirement and users are the major authority for approving and agreeing such baselines. Users must be aware that they must participate in the process of reviewing and approving certain configuration items, requirements and high level design for example, and must be aware of the importance of such approval.
Release planning: establishing the release and delivery schedule for a system is of key importance to the users. This is also a key factor in determining the complexity of the configuration management process. A user that insists on having multiple variants of a system, all in operation concurrently is imposing significant overheads on the configuration management process. Users must be aware of the need for effective release planning and for the need to ensure that each release has a well-defined scope that is effectively controlled.
Many managers view their role in configuration management as being restricted to providing the mandate and the funding. Whilst this support is essential and necessary, other very important commitments are required to ensure that a configuration management system is effective. These commitments may introduce conflicts between the need to deliver a system quickly and the need to maintain full traceability of changes and requirements across the life cycle. The main risks in this area relate to the temptation to abandon configuration management with the false assumption that this will speed the delivery of the system and that configuration management can be bolted on once the system has gone live.
Some developers support the configuration management process until they realise that it applies to them and from an early stage of the project. “I have developed for the past ten years and I have never needed to do this?” “Why do we need this bureaucracy?” “This restricts our creativity?” “We are employed to produce code and not to produce paperwork?” are common responses of some developers when faced with a full configuration management system.
The issues highlighted above represent problems arising due to peoples’ reluctance to participate in or accept the process. In certain organisations problems may arise due to excessive eagerness. I never cease to be amazed by those organisations that appear to “want it all and want it now” even though they have managed without it for the past one or two decades. This over eagerness can pose a major problem when it is coupled with expectations of high short-term returns. It is important to note that developing and rolling out a configuration management system is quite different from implementing and benefiting from it.
The importance of the cultural challenges should not be underestimated. Many of the configuration management processes rely on the participation of developers, managers and users and their successful implementation is determined by the willingness and enthusiasm of the people involved. It is also important to acknowledge the fact that whilst configuration management tools can be procured to simplify and facilitate the various configuration management procedures, these tools will still rely on the participation of individuals. The roll out of a configuration management system should be phased over several months or even years where there is likely to be considerable cultural changes following the implementation.
Companies are organised into divisions and departments to facilitate management, control and reporting. These divisions create “Chinese Walls” between the various parts of the organisation and hence hinder communication and the exchange of knowledge and information. Whilst many organisations introduce systems to minimise the effect of these Chinese Walls, these generally do not address the requirements of configuration management.
When one views the configuration of a system one should make sure that this includes all the components that are necessary to develop, deliver and operate the system. This includes:
· Development platform.
· Development tools.
· Software components, in-house, bespoke and package.
· Documentation.
Given that configuration management applies to all the stages of the life cycle of a system and given that different departments may be involved in the roll out of an IT system, it is important that the configuration management process is applied across the various organisational boundaries. Any barriers between the various departments are likely to have an adverse impact on the configuration management system.
Organisational barriers may arise due to the growth of a successful organisation. A company that has grown through mergers and acquisitions may evolve a structure that is designed to support the various systems that have been acquired over the years. Particular attention should be given to organisations that have dedicated departments each aimed at supporting different platforms acquired through the company’s growth. Such departments may have differing development working practices that reflect the parent company’s working practices rather than the working practices of the current company. These working practices may also be designed to meet the requirement of the particular platforms within the department and may be radically different from those adopted by other departments.
Within a complex and large organisation, it is important that all follow the same high level configuration management process. It is probably less important that all departments are following the same working instructions and using the same tools!
Of all the software development methods and disciplines, configuration management is probably the most affected by technical considerations. Whilst the fundamental configuration management principles are common regardless of technical platform and considerations, the actual implementation of the processes is intimately related to the technical platform, tools and methods.
A configuration management system should apply to all platforms and all development tools and methods. It should therefore:
· Support development on mainframes, servers and clients.
· Support development within CASE, 3GL, and 4GL environments.
· Support development of bespoke, in-house, out-sourced, COTS and integration projects.
· Support development within projects that utilise a traditional life cycle, rapid application development, object oriented and prototyping methodologies.
· Provide a mechanism for the control of client and server software on different platforms.
Does one roll out different implementations of the configuration management system or should one roll out a single system and attempt to make this compatible with all the technical platforms, tools and methods?
An important consideration to take into account is that developers may work across several platforms, tools and methods. Should these be expected to adopt a single configuration management method or should they be expected to adopt different methods, each targeted at the technical platform being used?
Whilst some of the configuration management processes are independent of the technical platform being used, change control for example, most are intimately related to the technical platform. One must have a clear view of what physical items will need to be controlled and should have a clear appreciation of the challenges imposed by each type.
Technical challenges determine the precise nature of each of the configuration management processes. For example, applying source control to a 4GL environment is radically different from a 3GL. Also technical challenges may make it necessary to employ several configuration management tools rather than being able to employ a single tool.
It is also important to review the current development procedures and how they can be interfaced with the configuration management system. An organisation that employs different development methods will require additional attention when compared with one that has a single consistent development method. Also structured methods are much easier to interface than those that rely on prototyping and rapid application development.
A financial institution was embarking on a large development programme aimed at re-implementing its systems on a PC based client server architecture. Senior management identified the need for formal configuration management at the early stages of the development process and initiated a project to identify the needs and implement a suitable configuration management system.
The project to implement the configuration management process was broken up into three stages:
· Review of current working practices.
· Review of available configuration management tools.
· Roll out and training.
Figure 3-2: Life cycle for implementing CM
The project to implement configuration management was managed as a sub-project within a quality improvement programme that aimed to develop a new development approach and a quality management system based on the ISO9000 model. The quality improvement programme was being run in parallel with the development programme. The first two stages of the project were short, of the order of 20 days each, and also represented minimal investment.
The review of current working practices highlighted several major issues. A decision was made to define a high level definition of the various configuration management procedures. This definition would be platform and development tool independent. This was necessary due to the diversity in tools, methods and perceptions within the organisation.
The main issues identified are listed below.
Organisation issues:
The organisation was divided into a number of departments. These reflected the platform being used which in turn reflected previous acquisitions by the company. The IT department made use of ICL, UNISYS and IBM mainframes and each was supported by its own development staff, tools and procedures. The new development programme was going to be based on PC and UNISYS platforms.
The work on the client server programme was performed by the following three main groups:
· Database design team.
· Central services team.
· Branch services team.
The database design team was responsible for maintaining the corporate data model that underpinned the new client server architecture.
The central services team developed the portion of the application that was being deployed on the UNISYS platform. LDAIII was used for this implementation.
The branch services team developed the portion of the application that was being deployed on PC clients. Visual Basic, C++ and Power Builder was used for this implementation.
The architecture being developed was of a two-tier client server type. This introduced the need to develop an intermediate set of servers. Development work on these servers made use of C++, Visual Basic, Power Builder and SQL Server.
Cultural issues:
Most staff were not very familiar with the essential concepts of configuration management and were therefore unable to fully appreciate the impact of such a process on their day to day working practice.
Users were not involved in the development cycle and their involvement with the configuration management process would have been very difficult.
Staff from different departments had radically different approaches to development.
The rate of change within the IT department was very high with changes on the following fronts:
· Development platform.
· Development tools.
· Development procedures.
· Configuration management procedures.
Managers were subjected to several objectives, most of which imposed significant resource strains. These objectives included:
· Deliver the new system on time and within budget.
· Develop and apply the quality management system.
· Develop and apply the configuration management system.
Technical issues:
Change and release procedures were in place. These were managed and operated by the operations department. Change control within individual projects was not evident. Configuration management was viewed as a process that comes into effect once the system is rolled out to the production platform.
Different naming conventions were in use within the IT department. These were tool specific. Given that different platforms employed different tools, there were few common features between the various naming conventions.
Source and build management tools were not being used. Most development staff had never used a source or build management tool.
Development procedures within the new development programme were being updated to reflect the needs of a client server development process. These procedures were different from current procedures that were designed to support development on a mainframe platform.
The review of the new development platform identified that several development tools were being used. These included;
· C++,
· Visual Basic,
· SQL Server,
· Power Builder,
· LDAIII
Visual Basic and C++ are 3GL tools. Power Builder and LDAIII are 4GL tools. The complete development suite produced over 20 types of configuration items, some were stored in proprietary repositories and some as operating system files.
Most staff had limited knowledge of the tools being used on the PC platform. Whilst training was being provided, most developers were still not aware of the main technical challenges imposed by each tool.
The development platform was under constant change. Tools were being upgraded and enhanced, the operating systems were being migrated from 16 bit to 32 bit versions.
The PC development network was expanding as the programme size increased. This introduced many network and interconnection type problems and issues.
The bulk of this activity was managed through a TickIt based quality management system, however additional education was required to increase awareness of configuration management. This took the form of short presentations on configuration management. Three types of presentations were prepared:
· High level presentations aimed at senior management and project controllers. These presentations were short and largely non-technical. Most aimed at defining the various processes, the main technical and cultural challenge. These seminars became more technical as the implementation progressed. This was mainly due to the need to make senior management aware of certain technical issues and how they could be tackled.
· Detailed presentations to project managers. These were detailed presentations describing how the various processes integrated together.
· Detailed presentation to developers. These were very technical and aimed at addressing questions and issues arising from the technical challenges imposed by the technical tools being used.
The education programme was eventually rolled into the training programme. Projects were provided with a training course that covered the high level requirements of configuration management followed by a detailed description of how the development and configuration management tool were to be used.
A short review of the development platform highlighted the absence of a single tool that could bridge the complete technical architecture. This review also highlighted the importance of the current mainframe based help desk and inventory management system that was well established. Any new system had to accommodate this package despite the fact that interfacing third party tools with this package was difficult and expensive.
The review of the development network identified an opportunity for using the PC LAN and a PC server as the central library for all development tools. This also highlighted the feasibility of controlling mainframe based configuration items on the PC LAN.
Several mainframe based configuration management tools were identified. These were not reviewed but their cost and impact on system capacity was assessed. It was apparent that this represented a high cost route and was eliminated in the early stages of the evaluation.
The review identified a source control tool that could support all the PC LAN development. This was selected on the basis of cost and ease of implementation and support.
Build management tools were not suitable for two main reasons:
· The 3GL tools came with their own build management features.
· The 4GL tools could not be used with third party build tools.
No tools could be found to support the configuration management process within the data management team. The CASE tool being used did not interface with any third party configuration management tools. A decision was made to implement configuration management using manual procedures only for their team.
The quality improvement programme managed the development of the detailed work instructions. The development support group managed the roll out of the necessary tools. These two groups had diverging priorities:
· The quality improvement programme had a tight deadline based on the need to secure external accreditation within the shortest possible timescale.
· The development support group could not roll out the tool until its stability and integration with the rest of the development platform was established.
The configuration management procedures were rolled out across the organisation. Projects satisfied the requirements of these procedures using manual procedures. The roll out of the configuration management tools followed later.
All projects were subject to pressure to deliver to tight deadlines. Most projects opted for a manual configuration management process as this represented minimal risk to the project.
Documentation Structure
The configuration management documentation was rolled into the documentation for the quality management system.
The overall structure of documentation was as follows:
· High level statement of what to do for configuration management. This was referred to as the configuration management standard.
· Project specific configuration management plans.
· Detailed configuration management work instructions.
The configuration management standard was common across all platforms and projects. This represented the main objectives of the configuration management system and what it should consist of.
The configuration management plan was project specific and identified the aspects of configuration management that were project specific. This enabled each project to describe how configuration management was to be applied within the confines of the project. The configuration management plan contained sections that were platform, to address the platform requirements of the project, and tool specific.
Detailed configuration management work instructions. Some of these were project specific and some were common across projects.
Roll out
The configuration management system was rolled out on a project by project basis. At the initiation of a project a review was conducted of its specific needs. These were documented in the configuration management plan and determined how the configuration management system was to be applied.
A central configuration management team conducted the review of project requirements. The main aim of this team was to enable projects to adopt processes that were most suited to the project but without compromising the consistency of application across the IT department.
All projects made use of the same configuration management tool. Project specific working instructions were written where such instructions did not exist or could not be reused from other projects.
A short training programme was provided to each project. This covered the configuration management plan, the low-level work instructions, the features of the development tools being used and the usage of the configuration management tool.
The complete roll out cycle took under 10 elapsed days.
Application of procedures
The roll out of the configuration management standard was relatively easy. This document was very generic and only specified what was required rather than how it should be applied. There were some problems due to loose interpretation of certain requirements. The most notable related to the point at which approval took place and hence the point at which formal configuration management was applied. A number of projects applied configuration management from the point at which the individual configuration items were produced and unit tested. Others insisted that configuration management could not be applied until the system entered system testing. A substantial minority insisted that configuration management should not be applied until the system was ready to go into production.
Naming conventions
Attempts to introduce a unified naming convention met with considerable resistance. The main determining factor was diversity in the capabilities of the development tools. A number of tools were able to support object names of up to 32 characters, others could only support 8 character names and a few imposed restrictions that prevent object names from exceeding 5 characters. A uniform naming convention would have restricted all developers to use names that were based on the lowest common denominator, i.e. 5 characters, this was unacceptable to developers who had grown accustomed to using long description names.
Adoption of tools
A number of developers and managers were reluctant to employ the available configuration management tools and preferred to satisfy the requirements of the configuration management standard using manual processes. It was interesting to note that developers and managers who had previous experience using configuration management tools were very happy to take on the new tool whilst those who had never used a configuration management tool viewed them as a risk to the project.