How Does Software Development Fit in with ITIL's Configuration Management Database?

usability across a set of applications that make up an end to end service has also increased.

So if your organisation is implementing an ITIL V3 CMS (or has a V2 federated CMDB), then your ALM will be exchanging information via: Problems, Known Errors, Changes and Releases.

No Application is an Island
No application lives in isolation – it depends on a variety of other objects which could be other applications, or objects in the environment the application requires to run. These might include:

• Operating System
  • Software (e.g. Java/Tomcat/.Net)
  • Patch levels/security updates

• Databases
  • Data structures (and changes to these)
  • Configuration tables and data

• Interfaces
  • External Partner systems or services, including news feeds and the like
  • Interfaces to other applications

Linking Software Development and ITIL
All software development projects start with some statement of requirements (however informally defined), and if the project is successful, it delivers a released application or system which produces value for the business.

So there are a set of inputs, and a set of outputs, and we can relate these to ITIL processes and CIs which may be controlled in your CMS/CMDB.

The outputs of software development are known in ITIL as release packages. Their contents are shown below.

Designing your CMDB
If you are designing your CMDB and wondering what you need to do to include software development, an easy first phase is look at the information about which crosses the “software development” boundary.

All successful software development has some form of change, configuration and release management systems in place. It will include defect tracking (both for defects and changes typically) and version control tools. So we classify the software development repositories as a physical CMDB, part of the overall federated CMDB or CMS.

A Change or Problem can be manually linked (via copy and pasted unique ID) to an issue in your defect tracking system. There would then be some traceability from actual code changes through to associated issues, through to a Change or Problem.

Obviously manual approaches to such linking are more effort to maintain, and error prone, so less reliable. However, vendors are increasingly providing automated links between such systems to give more seamless operation.

Maintaining your Development and Test Environments
Another area of interaction between software development operations is that of managing development and test environments. These may or may not feature as CIs in your CMDB (so some organisations only consider production environments to be CIs).

It is important that new releases are tested in environments that most closely resemble the production environment. There are many potential issues in this area (enough for a future article on its own), so we will just highlight some:

• Who is responsible for managing which environment?

• How easy is it to audit and track changes to environments?

• How do you ensure that changes in production are included, as well as the changes that the new release requires?

• How do you manage parallel releases with incompatible requirements competing for the same environments?
• What is the minimum number of environments you need – allowing appropriate parallelism and yet not being too expensive in terms of licenses, hardware, resources to maintain etc?

Summary
While in the past software development has mainly been seen as being independent from ITIL, with the release of ITIL V3, we believe all organisations benefit from reviewing what they do and taking a higher level, service oriented view.

At the level of change, configuration and release management, there is nothing in ITIL that goes against classic configuration management principles:

• Configuration Identification

• Configuration Control

• Status Accounting

• Audit & Review
• Build & Release Management

It is