Introduction

Everything changes and grows quickly in the software world. I remember when I first started coding back in the early 80's, version control was all totally manual and far less formal if done at all. We would just manage files in copies of directories, rather like a series of incremental backups. Later in the early 90's when the ability to check files in and out from within development environment appeared, we thought it was such a great idea. It was so much simpler than the manual methods or scripts we had used before then. I for one thought that it couldn't get a lot better than the version control we had then.

Simple view of Version Control management

So what is a simple explanation of Version Control? It would be the ability to :

• Easily add a file item to the source control repository so that it can be revision managed and versioned controlled.

• Check files out, work on them and check them in again. Either one file or many at a time.

• Do the same for directories, but this is beginning to get into configuration management.

• Manage the issue of multiple people contending for changing the same file at the same time.

• Keep sets of files each at a particular version. A version in the large of a collection of file versions. Attaching a label to show a baseline.

• Pull out a set of files for release that are all part of one specific labeled set or baseline.

• Save multiple baselines at different release versions in the repository simultaneously.

The complex problem of parallel development simply appeared too difficult and intractable to tackle. How wrong I was. We carried on using MS Visual Source Safe as we had been for ages and didn't really explore other tools, probably because the need within the projects I was working on was not that great. In reality it was more likely because I didn't realise how much better it could get. It's a case of once you've seen it working properly, then you appreciate the control and benefits that can be derived.

Making the jump up

Then on a project during the .com era in the late 90's, I was told that we could get a lot more control over our software development and release management, than what we were doing then. At the time we were in the midst of implementing a whole raft of new tools and processes; Requirement management tools, learning Use Cases, UML modelling tools, Testing tools and Defect tracking tools. My logic at the time was; we already have too much change on our plates and how much more could this other Configuration management tool bring than the version control tool were already had? I suspiciously thought it was a ploy to simply sell more tools. I'm sure many have that thought as their first reaction. Having since seen the full potential of the integrated concept of Configuration management with Change Control, I now know better and would have changed my attitude then with what I know now. If only someone could have explained it to me. I'd like to try and impart some of that experience.

So what is Integrated Configuration Management?

After more and more time working with these concepts, it appears to me that there is no one simple definition of Configuration management. I believe the true benefit comes from the integration between Change Control management and Configuration management** as shown in the diagram below, with the supporting common elements they both require. **It must be said there are other integrations that also add huge benefit, such as integration to Project Control and Requirements Management, Continuous testing, etc. but for the purposes of this paper we will not go there.

In the UML diagram on the left, I have tried to show two main groups of concepts that make up Configuration Management (blue) and Change Control management (yellow), with a third group being the Common management elements (green) they both share. It is possible to implement Change Control Management as a set of processes and tools in a stand alone mode, because while you will get some big benefits over controlling Issues, Risks, Change requests and Defects, in a silo. I do not believe it should be implemented like this for any period of time, because the major benefits are derived from the Integration of the Configuration and Change Control Management all sharing the common aspects. To my mind, the overall concept could also be given the title of Configuration and Change Control and is a discipline that stands on its own in software development.

The red package in the figure on the left shows the Version Control component out of the full integrated Configuration Management solution. This gives you an idea of the scale of what we are trying to represent here. Also this Version management includes the ability to do parallel development, work in isolated streams, automatic merging, and a lot more.

So what is Configuration Management?

Version Control has expanded and grown over time into a larger conceptual part of Configuration Management as a whole. Build management and Release management also fall into the Configuration Management conceptual group. They are conceptual areas that have undergone great change in the last decade and enhanced Configuration management tremendously. I think of things like Ant, Maven, CruiseControl and even the Unit test tools. Configuration management now includes many more features like the ability to:

• Do parallel development. Many teams each developing a sub-system, each member of the team working on different functionality.

• Branch and merge files and groups of directories and files,

• Work in isolated workspaces, streams, etc.

• Only have views of the version of the release the particular developer find relevant to what he or she is involved in

• Control the workflow of the developer by permissions and access control

• Control the workflow of the developer by tracking actions performed

• Assign changes in code to actions to releases, giving the ability to know exactly what fixes and new enhancements are in a release

• Audit and truly know what exists where and when it was put there.

• Track changes to code against work items which are units of required functionality within the business (integration to Change Control)

Some of the terms above are rather technical terms and for developers and the technical minded; suffice to say the end results offer huge technical and business benefits by changing to these better approaches, which we will explore in the next section. The business benefits of this are that developers can all work each on their own specific bit of functionality. All this happens in far more of a parallel manner than it used to before. In many cases this parallel development happens on common files, which are then merged, continuously tested and integrated to highlight problems early. Overall these functional changes or additions come out far quicker than they would have before. They are more closely related to the business prioritization because only the units of functionality that the business wants. It does depend upon which Phase your project is in at the time, but in general the further into the project the team are, the quicker the turn-around time for new changes and defect fixing. In the early stages and particularly on green-field projects, the focus is more on getting the overall Architecture de-risked and sound, but the Configuration management is critical to the success of this as well.

Automation as a major enhancement

Another major enhancement in all of these configuration management and related tools is the ability to automate and thereby streamline many of the workflow and other processes. The immediate benefits of this are that is makes development tidier, more predictable, quicker, removes the likelihood of manual error and allows for the concept of continuous improvement and thereby giving the ability to measure real progress from reality rather than a perceived progress against a list of activities on a plan. This gives rise to the ability to constantly display progress metrics and detect problems as soon as they occur.

Service Oriented Architectures (SOA) makes CM mandator

Another excellent reason for implementing configuration management, is if your company is using or going to use Service Oriented Architectures (SOA). In fact I would go so far as to say, do NOT try and implement an SOA in an enterprise without some serious form of Configuration management. In the past simple version control of individual silo based application systems could be implemented and work reasonably well. Why? Because there was usually a rough and general mapping between one development project and one application running in the enterprise. Whatever this team released, they were in control of and even though it integrated in a point-to-point manner to other systems, some testing would generally resolve most of the issues. With SOA, all that will change because different teams will be dependent upon a common set of central services. They won't need to build a set of unique point-to-point interfaces with each application. This is one of the benefits of SOA. The central services will also be enhanced and releases made. In certain cases these releases will have to cater for different versions of services operating live at the same time. i.e. the "Create Customer service" will have a version 1.1 and version 1.2, because the an original application (say Debtors) called service v1.1 but a newer application (say CRM) needs a more advanced interface with an extra feature and calls service v1.2 when creating a customer. All this is going to require application testing against the Services while the services are changing. Releases of the services may also not coincide with releases of enhancements to older or newer applications. All configuration items are going to have to be very well managed. To me this alone will require the business to justify Configuration management solutions, otherwise chaos and serious down time in live applications could potentially ensue.

Configuration items

A Configuration Item is a managed software component that is delivered live. It could also be a piece of software source file that builds up to a software component that is delivered live. We manage assets naturally for hardware components. Why? Mainly because hardware assets are more tangible and we can see them. So imagine for a moment of these software components as a hardware component such as a PC, router, modem or printer. It makes sense to manage the hardware assets of a company, but somehow software assets seem a less obvious thing to manage. As an analogy, imagine if a critical printer in a Customer Sales area broke down. It would be replaced immediately because of the impact on the business. We would know about it, its asset number, cost, supplier, etc. Software items are not always as visible. What are the direct and indirect dependencies or impacts of say the Ordering System going down? Can we tell immediately? Or will it be a major surprise a while later? Which exact components will be impacted? Which exact business functionality will be stopped? How much will it cost the business? Etc. From this we can derive the importance of a configuration management system, especially in the area of new software development when integrating new systems into existing application systems. It affects existing operational applications as well as software development in the business.

Business benefits of Configuration Management

So what are the benefits, of all of this then? There are many and they are wide-spread. Let's look at the technical benefits and work them to their logical business benefit in the bullets below:

• Reduce errors by automation --> Takes away manual processes that are slow and error prone --> Save time and money, faster time to market.--> More competitive and responsive to business change.

• Improved communication amongst all team members --> Automated workflow, email communication, fewer bottlenecks, Less rework, less misunderstanding --> Save time and money, faster time to market. --> More competitive and responsive to business change.

• Ability to manage dependencies --> One of the points of Configuration management. --> Better and quicker impact analysis --> Better business control --> Save time and money, faster time to market. --> More competitive and responsive to business change.

• Protection of shared resources --> Automated and managed branching and merging, rebasing and delivering; tracks any problems early so they can be fixed early; avoids errors occurring without developer awareness --> Avoids problems which saves time and money, faster time to market. Responsive to business change.

• Manage the lifecycle of a Configuration Item --> Ability to assess the impact of new changes, allows making quicker enhancements, Save time and money, faster time to market. --> More competitive and responsive to business change.

• Ability to track and audit software development and indeed live systems --> Ability to fix problems quickly; Better and quicker impact analysis. --> Save time and money, faster time to market. --> More competitive and responsive to business change.

• Enhances development workflow --> Ability to prioritise functionality to be developed; to track the development teams are actually executing these priorities as expected by looking at reports; --> Gives feedback on development turnaround times --> better estimation for time and costs --> realistic development with less failure and budgets are easier to manage. Save time and money, faster time to market. --> More competitive and responsive to business change.

• Saves time --> quicker development; faster time to market; revenue generation earlier; beat the competition

• Reduced defects introduced to development --> Many of the defects are usually introduced by misunderstanding; poor control over the files; poor direction in terms of priorities; manual overwriting; lack of regression and unit testing. --> Save time and money, faster time to market. --> More competitive and responsive to business change.

• Reduced costs and time to fix defects that are introduced --> Mixture of severity rating on defects; also other concepts such as continuous test and integration bring the time down between the problem being generated and being fixed, while the developers memories of the code are still current and they remember that particular area of code. --> Save time and money, faster time to market. --> More competitive and responsive to business change.

• Reduced Maintenance Costs --> Particularly for web based systems, Configuration management systems store all accumulated version until the latest one. Often it is necessary to be able to go back to some previous version. --> This speeds up changes and reduces maintenance costs.

• Improved Productivity of Development team --> Because all have visibility of the overall project progress and state --> Improved Productivity --> Reduction in cost expenditure and time --> Faster time to market.

• Accurate information on Configuration Items and related documentation --> One of the points of Configuration management. --> Better and quicker impact analysis --> Better business control --> Save time and money, faster time to market. --> More competitive and responsive to business change.

• Helps with financial and expenditure planning --> Allowing the organization to perform impact analysis and schedule Changes safely, efficiently and effectively --> Quicker project estimation and prediction --> Save time and money, faster time to market. --> More competitive and responsive to business change.

• Making software Changes visible --> One of the reasons of Configuration management. --> Better and well understood systems, taking information out of a few experts heads --> Better business control --> Save time and money, faster time to market. --> More competitive and responsive to business change.

• Contributing to contingency planning --> Better and well understood systems plan contingencies more accurately --> Better business control --> Save time and money. --> More responsive to disaster. --> retain competitive advantage though adverse conditions.

• Supporting and improving Release Management --> One of the points of Configuration management. --> Better and quicker releases live --> Better business control --> Save time and money, faster time to market. --> More competitive and responsive to business change.

• Improved security --> By controlled versions of Configuration Items in use --> Better business control --> More secure business systems.

Secondary Business benefits

As if the list above wasn't enough, there are secondary benefits the business derives:

• Better corporate image of being in control of their systems

• Improved team morale. The developers feel all their efforts are being supported.

• Facilitating adherence to legal obligations.

• Less overtime and weekends --> translates directly to reduced overtime expenses

• Less overtime and weekends --> makes developers more productive being well rested during the week.

• More competitive stance in the marketplace

• Increased Customer satisfaction

• Overall communication improvements at all levels

Conclusion

In hind sight, if I could do that .com project from the late 90's all over again with what I know now, I would have implemented the Configuration Management tools much earlier as a "sound foundation" and a "must have"; then built and integrated the other tools around it, rather than seen it a "nice to have" which we could fit in if time near the end of the project. All this however does require that the development team is very disciplined. They should manage and use it correctly for the benefits to become evident. The beauty of the integration of the Configuration Management and Change Control management aspects means that the overall solution undergoes a synergy, whereby the whole is not simply the sum of its parts, but greater than the sum of it parts, giving huge business benefit to any software development team. There are certainly multiple business benefits over simple Version control.

References

• http://www.iterativementor.com

• http://ant.jacarta.org/

• http://maven.jacarta.org/

• http://cruisecontrol.sourceforge.net/

• http://www.junit.org/

• http://msdn.microsoft.com/vstudio/previous/ssafe/

• http://www-306.ibm.com/software/awdtools/clearcase/

• http://www.intranetjournal.com/features/bayles/extranets_ch6-03.shtml

• http://www.synergex.com/pdf/Benefits_SCM.pdf

• http://www.abacus-systems.com/PI-CfgMgmt.htm

• http://www.configurationkit.com/justification.htm

 TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed