It is important not to lose sight of the fact that a configuration management tool is designed to manage physical configuration items and to automate a manual configuration management process.
It is therefore vital that one is able to identify the configuration items that will be managed and the processes that will be automated before the configuration management tool is procured and implemented.
Identifying the configuration management items will enable one to establish the percentage of the technical platform that will be covered by the configuration management tools being selected. This is an important consideration as items and platforms that are not covered by the selected tool will have to be managed using manual processes. This will reduce the final benefits of procuring the tool and may even complicate the configuration management system due to the need to develop manual processes that have to interface with the processes that are mandated by the tool selected.
Identifying the configuration management processes is essential as this will enable one to identify the tools that will support these processes and the level of requirement matching, i.e. what percentage of the process requirements are matched by the selected tool. It is important to avoid the selection of tools prior to defining the configuration management process. This is necessary for the following reasons:
· Many configuration management processes are very complex and their full definition can only be fully understood after the processes have been developed and evaluated in detail.
· Whilst many tools can be configured to support different processes these tools are generally complex and expensive.
· It is generally very difficult to reconfigure a tool to support a new configuration process once it has been used supporting a different process.
Defining the exact configuration process prior to the selection of the tools will also facilitate the process of tool evaluations. Instead of evaluating several tools, one may be able to narrow down the available tool set by identifying the level of matching between the tool and the process. This would enable one to eliminate potential tools that do not provide sufficient support to the process and hence release vital resources to perform a full and thorough evaluation of the remaining tools.
The process definition can be used as a statement of requirements for the tool to be used and can act as an important aid to the supplier of the configuration management tool by enabling the vendor to provide consultancy support and more accurate estimates of the potential customisation cost. The cost of consultancy to configure a configuration tool can very easily exceed the cost of procuring the tool. It is therefore essential to make sure that the these costs are identified up front instead of after the tool has been produced.
The first step in implementing a configuration management system must involve the identification of the technical platform within which the configuration management tool will be deployed. The technical platform includes the following:
· The hardware platforms.
· The operating systems.
· The network(s).
· The physical separation between sites.
· The inter-connectivity between sites, hardware platforms and operating system.
· The relationships between the various sites, platforms and operating systems.
· Development tools being used.
· Types of configuration items generated by tools.
· The architecture of applications being developed.
The review of the technical platform should enable one to identify the diversity of development platforms and configuration item types. The review should also identify the relationships between the disparate platforms, operating systems and development tools.
An environment that does not span, sites, platforms, operating systems or development tools is much easier to configuration manage than one where a single application may span several platforms and development tools.
Having surveyed the technical platforms one should be able to identify the feasibility of implementing a configuration management system that employs a single tool from one vendor, several tools from one vendor or several tools from several vendors.
Where tools from a single vendor are available then there is a strong likelihood that these will integrate together to provide a cross platform configuration management solution. Where several tools from several vendors are required then it is highly unlikely that these will integrate to provide an integrated configuration management system.
Integrating tools from different vendors can be a very expensive and time-consuming process. It is also worth noting that integrating tools that are rich in functionality is also more complex than integrating some of the smaller and simpler tools.
It is important to identify the hardware platforms that are being used within the development and production environment. These in turn determine the operating systems that are in use and hence the available tools.
Many tool vendors provide products that operate on several platforms, it is therefore not difficult to find a short list of vendors who cover most of the platforms that are in use. Whilst many vendors support several platforms, most vendors have a limited number of platforms on which their offerings are strong and reliable. Most vendors concentrate on single platform, mainframes, UNIX or PC. UNIX vendors tend to provide extensive coverage across the various UNIX platforms.
Whilst one may be tempted to procure a single tool that covers all the platforms, it is important to remember that that the different platforms provide radically different development environments that may negate the benefits of having a single tool that covers all the platforms. It may be wiser to procure an established UNIX tool for the UNIX platform and an established PC tool for the PC platform.
Networks facilitate interconnection between different platforms and also represent the main media for transferring configuration items between the various development machines. Whilst network bandwidth has increased significantly over the past few years, certain configuration management tools are still able to provide sufficient loading to significantly degrade the network performance.
Avoid establishing large centralised repositories for the complete organisations. Whilst such a configuration may minimise the administrative overheads, the network loading may be severely degraded due to the need to provide users access across gateways and bridges.
When assessing the network, try to establish the feasibility of sharing disc resource between different platforms, using a UNIX disc as a server for a PC network. In certain situations it is possible to employ a configuration management tool to manage objects created on one platform using a tool on a different platform. Such sharing can introduce significant cost savings by reducing the number of different platform licences or by enabling one to manage code on a platform with cheaper tools. Where a UNIX server is used to serve a PC network, it is quite feasible to make use of a UNIX configuration management tool to manage some or all of the PC configuration items. A leading Building Society was able to make a cost saving of over 100% by managing objects, which normally reside on a mainframe, using a PC configuration management tool.
Separate development activities at different sites represent no problems as each site can be managed on its own. Projects that require concurrent development across several sites may be faced with some serious configuration management challenges.
It is always better to avoid splitting development across several sites. Where such development is necessary then it is best to break up the work such that each site is able to progress work on a separate part of the system at any one time.
Where parallel related development work is necessary then networking between the sites is required. Once a network is established one has the option of providing a real time link between the two sites, where the different sites have access to a pool of libraries, or provide a batch update link to synchronise the different sites at set intervals.
Providing a real time link between different sites is quite feasible, however one must make sure that the tool being used is able to cope with the time delays that are introduced by the need to connect to remote libraries across a wide area network. Such time delay problems are not uncommon and may prove to be absolute show stoppers.
Batch synchronisation tools can be procured to synchronise the libraries across sites. Such tools are able to compare files across the sites, identify the files that can be transferred without any conflict, i.e. files that have been modified at either of the sites, and those files that represent conflict, i.e. files that have been modified at both sites. Resolving conflicts can be difficult and should be avoided, especially if 4GL tools are being used.
It is essential to identify all the tools being used, as this will determine the types of objects that are being created. An environment that employs 3GL tools should have little problems identifying suitable tools; one that uses a mix of 3GLs and 4GLs is likely to find it more difficult to find a single tool that covers all the development tools.
As a rule, the usability and benefits of the configuration management tool is determined by object coverage that it provides. There is really no sense in making a significant investment in a tool that only covers 50% or 60% of the development tools being used.
The second step in implementing a configuration management system must involve the identification and configuration management process. This process will be used to manage physical configuration items and will be applied by staff who may belong to one or more departments within the organisation.
Avoid the green fields’ approach to defining a configuration management system. There is always a temptation to ignore existing processes and to start from new. Where a decision is made to start from new, then one must clarify the following:
· Weaknesses and strengths of current processes, regardless of how fragmented and undocumented they may be.
· The infrastructure that is in place to support the current processes. Existing processes may have evolved to accommodate organisational structure and communication lines that may support a new idealised configuration management solution.
· The impact on current projects of introducing a new configuration management system. It is highly improbable that one can switch from one configuration system to another without affecting current projects.
One of the main principles of configuration management relates to the ability to manage change. It is therefore essential to manage the changes necessary to implement a new configuration management system. It is always a good idea to address the following when specifying a new configuration management system:
· Review current processes.
· Review the infrastructure that supports the current processes.
· Review the strengths and weakness of the current process.
· Identify why current processes have evolved into their current state.
· Define an improvement plan.
· Manage the change.
Avoid the temptation of procuring a system and then trying to develop the processes that are necessary to support it. Instead define the process and then procure a tool to support it.
A configuration management process, regardless of how automated it may be, will require the participation of staff. It is vital that one is able to identify the:
· Benefactors.
· Users.
· Operators.
The benefactors are those who will benefit from the configuration management system, i.e. programmers, developers and designers. Do not forget the business users. Many changes are triggered by the need to implement end user requirements. An end user who is not involved in the configuration management process may find it difficult to appreciate why a particular change can be implemented with ease, and why a different change may be impossible to implement. Users will and must be involved in the configuration management process and should therefore be involved in developing the configuration management system.
The users of the configuration management systems are the programmers, the team leaders, and the project managers. They are the ones who will use the tool, the process and the forms on a daily basis. A solution that does not take the users requirements into account will certainly not survive the test of time.
The operators are the staff who will maintain the various configuration management tools and will be involved in the day to day running of the various processes.
Do not confuse involvement on developing a configuration management system with training. The aim should be to develop a system that is suited to the organisation that it will be deployed within.
It is important to identify the development process that is being used by the organisation. The configuration management process must interface with the development process, i.e. the various configuration management processes must be compatible with the development process being used.
The features of the configuration management system will be determined by the stages of the development process. A structured, staged development process is the easiest to support. A cyclic, incremental development process is the most difficult to support.
The requirement of a RAD development process are different from a traditional life cycle where one goes through set stages from initial analysis to final acceptance.
Before starting the tool selection and procurement process it is important to establish the suitability of the processes that have been defined. This can be performed by selecting one or more pilot projects and applying the new process.
Piloting the processes will enable one to provide a level of assurance that the processes will support the development methods and the technical platform being used. This will also highlight any cultural problems that are likely to be encountered once the configuration management system is fully rolled out.
A further benefit of piloting the processes is that the organisation will start to benefit from the new processes at an earlier stage when compared with an approach where the pilot is started after the tool selection process. This can provide considerable benefits since the roll out of some configuration management tools may span several months. It is important that the organisation is employing effective configuration management processes whilst the tool selection and implementation process is progressing.
Organisations that have established processes or those who are currently employing a configuration management tool will benefit from this stage by enabling them to migrate their processes from the current way of working to the new process. This will undoubtedly identify any problems in the new process and the training requirements to ensure that the staff are able to employ the new process easily.
A government organisation with an IT department of about 60 staff were in the middle of implementing a major update to their main IT system running on a UNIX platform. The IT systems were implemented using a 4GL with some supporting 3GL code written in C.
The IT department had experienced problems managing the development process that involved maintaining and supporting the current live systems whilst developing the next version of these systems. The main problem encountered by the developers was the difficulty in segregating the maintenance and development work and the IT department had a number of incidents where development code had been accidentally released to the production systems when they should have released maintenance code.
The department had a limited budget and limited timescale to implement the configuration management system. It was important that tangible benefits were reported within a short period of time.
An implementation team was established which was made up of a single representative from each of the areas within the IT department. The membership included a representative from:
· Management.
· The analysis team.
· The design team.
· The 3GL development team.
· The 4GL development team.
· The data administration group.
· Live support.
Each representative was responsible for communicating the requirements of his/her area to the implementation team and for overseeing the roll out of the processes into his area.
A configuration management consultant was employed to provide guidance and advice.
The team met on a weekly basis to review progress during the previous period and to agree tasks for the following period. Progress reports were forwarded to the IT and operations directors.
Review technical platform
A short review of the technical platform was conducted to identify the likely technical challenges. The department was employing a client server architecture using UNIX servers and Novell and DOS clients interconnected using NFS.
Development work was conducted on the PC platform and the system was deployed on the PC and UNIX platform.
The review highlighted that the teams were making limited use of the standard UNIX source and build management tool, SCCS and MAKE. The review also confirmed the feasibility of employing SCCS to control all the configuration items that were produced by the 4GL, 3GL and the database being used.
An early decision was made to employ SCCS and MAKE to automate the source control and build processes. This solution was referred to as the interim configuration management system.
This stage of implementation represented an investment of less than 5 man-days.
Review current processes
This review highlighted that the IT department were employing a development method that included a number of configuration management processes, namely change and problem management, however it was obvious that these processes were not being applied across the development cycle.
The review also highlighted that whilst the developers made use of SCCS and MAKE, the process underlying this usage was undefined. The tools were not delivering an effective source control and build management process.
The review of the development life cycle highlighted the absence of key control points within the development process. Whilst stages were clearly defined to facilitate the project management process, these were unsuitable to identify the life cycle of individual configuration items and the control processes that govern this life cycle.
Define required process
A number of workshops were arranged to define the outline configuration management process. The aim of these workshops was to produce a series of flowcharts that defined the various configuration management processes. These workshops were also targeted at ensuring compatibility with existing development procedures.
Outline process flowcharts were produced and an implementation plan agreed. The priorities for the process were as follows:
· Change and problem management.
· Source and version control.
· Library and environment management.
· Release management.
· Build management.
Implement processes
Change and problem management was initiated first as the group already had such a process to manage change to the live system. This process was updated to enable the IT group to manage change in the development environment. It was felt that change control would increase the visibility of the level of change and also enable management and users to participate in the change process. This process included impact assessment tasks, not previously documented. This task was aimed at classifying changes to identify their scope to help highlight those changes that affected the live systems and those that affected development. The change process also mandated that affected products be identified and itemised on the impact assessment reports.
Implementation of change control highlighted the need to control the configuration items. Several problems were encountered where developers had implemented changes to items before the changes were formally authorised by the change board. Staff were working on the assumption that all changes were necessary and therefore work to implement the changes was started even before formal authorisation was granted. Formal source and version control was implemented next to address this problem.
All configuration items were migrated into the source and version control tool. These were secured so that items could be read without restrictions, to enable developers to investigate changes, however developers were unable to modify such items. This restriction met with initial resistance that highlighted the level of code change that was not previously being monitored.
Linkage between change and source control was established using a manual process:
· The change manager was responsible for noting all authorised changes, the affected configuration items and the person assigned the development task.
· The change manager was responsible for adding the assigned developers to the access lists of the affected items. This would enable these developers to modify the items for which change had been authorised.
· The change manager would forward authorised changes to the assigned developers.
· Developers would implement the change and return the items into the source control library. A cross reference was entered manually into the change description to identify the changes for which the items were modified
The combination of source and change control enabled the IT department to control all changes to physical items and link this to formal change control. This provided visibility of all changes, traceability between requirements and modified items and a full audit trail of changes.
The next process to implement was the environment control process. This was reasonably easy to implement. The source control tool provided a secure mechanism for controlling access to the master libraries. The organisation of the IT department provided an effective mechanism for controlling the various development, test and production environments. PC support were responsible for maintaining all the platforms to make sure that all changes to the architecture were managed through change control. The test teams owned the system test areas and code could not be migrated into these without their authorisation. The operations group owned the production areas and code could not be migrated into these without their authorisation. UNIX security settings were audited to ensure that code movement could not be performed without following the correct procedures, i.e. a developer did not have access to system test or production environments.
The above processes provided adequate control for most releases, however a number of problems were encountered that related to ineffective synchronisation in the release process. Certain changes affected configuration items that were maintained by two or more groups within the IT department and in some cases the release process failed due to changes being applied in an incorrect order. The release process was formalised to enable the configuration manager to identify the required tasks before a release could take place. In essence, the impact assessment report was extended to identify tasks that should accompany a change. Most such tasks related to the need to update the databases on the target system before certain code changes were released. This ensured that the code changes were not implemented until the databases were updated.
The above system was in operation for about 12 months when problem patterns were identified. Several releases resulted in the introduction of problems that had previously been solved. Investigation of these problems highlighted that some changes were being applied to code for which the incorrect source was returned to the master libraries. Given that the run time was released, it was difficult to ensure that all releases were made up using items that were already stored in the master library. This problem was addressed by formalising the build process:
· Developers would obtain authorisation to change items via change control.
· The change control process would grant the developer access to the required items.
· The developer checks out the required items, implements and tests the change and then returns the items back into the master library.
· The developer would request a release by identifying the modified items and their version number.
· The configuration manager would generate a new build by extracting the modified items from the master library, generating the run time and then releasing it.
The above process guaranteed that all released code had the appropriate source in the master library.
Costs
The approach employed most of the existing processes and tools and hence required minimal investment to evaluate, procure or implement the new tools.
The implementation was phased in as the process was being developed. Change and problem management was implemented within the first two months, formal build management was rolled out 12 months later.
The investment in the new system was spread across the complete implementation programme. There were no up front investments in tools or consultancy. This was of considerable benefit as the IT department had an urgent need for a configuration management system but did not have sufficient funding.
The gradual implementation provided metrics as the roll out progressed. Management had immediate visibility of:
· Volume of changes.
· Number of affected products.
· Effort to fix problems and implement changes.
· Number of failed builds.
· Volume of releases.
· Number of failed releases.
· Additional work to implement the change management system.
Given that most of the processes were manual, with the exception of source and version control and build management, it was reasonably easy to qualify the total effort spent per week operating the system.
Of the implemented processes, change control required most effort. The IT group held weekly change control meetings. These spanned about an hour and required attendance from several groups. The actual work required to maintain the change logs was insignificant when compared with the work needed to perform impact assessment and attend the change boards.
Securing the master libraries required 2 to three hours per week. The change control administrators performed the task.
Source and version control required less than 1 additional hour per week.
Build and release management required about 1 day per week.
The effort required to support and maintain the configuration management tools was insignificant.
Benefits
The most important benefit of configuration management system was the improved reporting and the increased visibility that this provided to the managers. It was not possible to identify the level of change and level of corrective action required to service the live and development systems.
The configuration management system also help reduce the level of failed releases into production by a factor of five.