How Does Software Development Fit in with ITIL's Configuration Management Database?
Many organizations or groups who develop software consider themselves outside the scope of ITIL, considering it something that is only relevant to IT operations and support groups. This was perhaps understandable with ITIL V2, and yet we believe it is no longer the case with ITIL V3. We shall address this in more detail below. This article focuses on a subset of ITIL processes and in particular the CMDB/CMS.
Misunderstandings and Evolution of the Term CMDB
In ITIL V2, the term CMDB was often misunderstood. Its definition: “A database that contains all relevant details of each CI and details of the important relationships between CIs”. This lead many people to think of it as a single database in which everything should be stored that related to Configuration Items.
It was never the intention of the ITIL authors that the CMDB should be defined as a single physical thing. It is a logical concept that is implemented via a number of physical systems (that in many cases already existed) that could be termed “CMDBs”.
Many vendors should share in the blame, in that they saw a tremendous market opportunity, and rather over hyped the particular capabilities of their CMDB solution(s).
One of the key problems with defining a usable CMDB is being very clear as to what results you want to get out of it. What information do you actually need to be able to better plan and manage the services your organization provides?
Network discovery tools can discover reams of information about objects on your network, including PCs, laptops, routers, servers etc. For each item discovered, you can also get details down to which versions or patch level of operating systems and applications are installed.
The problem is, most of that information is not relevant to managing a service where you may need the answer to the question “the power to rack X in the data center has gone down: which services are affected?” If you put all that unnecessary information into a CMDB, which some organizations did, you make it more complicated and larger than it needs to be, more difficult to navigate etc.
There also needs to confidence in the data within the repository, that it reflects the real world.
This resulted in some rather large and expensive projects to define, collect and feed data into their CMDBs. It brings to mind Audrey II in Little Shop of Horrors: “Feed me, Seymour, feed me!” The problem with the result is that the monster CMDBs consumed vast amounts of data and gave back outdated, inconsistent and partial results back (if they gave any at all) and, thus, quickly fell into disuse.
What Changed with ITIL V3?
Quite a lot! ITIL V3 focuses a lot on delivering value and business outcomes. It focuses on ensuring that all service assets (including applications) optimize the value of a service and its service performance. This clarifies and strengthens the link between best practice and the business benefits.
As David Norfolk writes in The Register in [an article on Service Design]: http://www.theregister.co.uk/2007/10/10/itil_service_design/ Sharon Taylor , ITIL's chief architect, summarizes the aims of service design rather well in the foreword to this volume: "In the past, the IT world has been viewed in two parts - the development world and the operational world. A lack of synergy between these worlds often produces a serious side effect - the business objectives are not met."
From the point of view of the CMDB, it is now defined as, “A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores attributes of CIs, and relationships with other CIs.”
ITIL v3 defines the CMS as “a set of tools and databases that are used to manage an IT Service Provider's Configuration data. The CMS also includes information about incidents, problems, known errors, changes and releases.”
In a way, the new CMS covers what was intended to be the old CMDB, but it is more explicit about what that means.
Other processes are renamed/reorganized, and (as mentioned in this article):
In the ITIL world, a CI is under the control of two important processes:
- Service asset and configuration management (SACM): Ensures that the organization has a policy for identifying CIs and insures that an auditing process is in place to validate the correctness of the data. This is accomplished using automated discovery tools or old-fashioned manual audits.
- Change management: Controls changes as they occur and insures that changes to CIs are recorded in the CMDB.
This combination embeds the maintenance of the configuration metadata deeply into the organizations processes, thus insuring its accuracy and timeliness.
So Where Does Software Development Fit in?
This focus on the CMDB and service management is all very well, but where does software fit in to this?
Traditionally, software developers have always seen themselves as off doing their own thing and doing it very well thank you. There’s no need to get involved with the problems and issues of IT operations!
Managing Their Own Lifecycles (ALM) From Requirements through to Release
In the V model (waterfall), the phases include planning, requirements, design, coding, integration and testing, with a final release to a grateful customer!
Figure 2 – Development Lifecycle. Development Projects think the job is done when they finish and the application is released.
The problem with this traditional model is that it doesn’t necessarily fit in very well with what the rest of the organization is doing, particularly if you are developing applications which are part of the ongoing estate of your organization.
In many traditional development shops, the most important stuff is considered to happen during development. At some point the application is signed off or accepted, it is thrown over the wall into production and the development team sails off into the sunset, with the satisfaction of another job well done!
Typically applications spend perhaps only 20-30% of their overall life in development. The majority of the life cycle is spent in production with regular changes being made to that application.
Smaller changes or bug fixes might follow a rather different life cycle than a full blown change. Larger changes may merit a new project to be setup which goes through the lifecycle again, but this time starting with an already existing application.
Applications are often modified for a new project in parallel to small bug fixes and enhancements being made and released. You need to ensure that a major new release of an application also includes all the little bug fixes that were made to the previous version and are already in production.
With the end to end service focus of ITIL V3, the importance of applications to the user experience and importance of usability across a set of applications that make up an end to end service has also increased.
So if your organization 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.
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, then 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 organizations 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 organizations 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 and review
· Build and release management
It is not difficult in principle to link sound software development practices and tools into an existing CMDB, as part of the inputs and the outputs from the software development process.
You may believe that all your organization does is release applications and that you have been doing it successfully for years. We encourage you to think of that as providing an application service and then being able to benefit from the excellent work and best practices that are documented in ITIL V3. It will lead to a more seamless and joined up organization, providing more value to the business.
ITIL is a registered trademark of the UK Government's Office of Government Commerce (usually known as the OGC).
