 How does software development fit with your ITIL CMDB?
As Shirley Lacy (ITIL V3 author) writes in a previous CM Journal article:
ITIL® has long been recognised as the de facto industry standard for IT Service Management and the adoption of ITIL has been growing rapidly across the world. IT Service Management (ITSM) derives enormous benefits from a best practice approach. Change management and configuration management are core practices at the heart of ITIL and ISO/IEC 20000, the auditing standard that is aligned with ITIL. ISO/IEC 20000 requires a service provider to deliver managed services of an acceptable quality for its customers. Many organizations across the world have achieved certification against ISO/IEC 20000.
ITIL V2 came out in 2000/2001, was subsequently “refreshed” and the resulting ITIL V3 published in 2007.
Many organisations 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 organisation provides?
 Figure 1 - What data do you need in your CMDB? Upgrading a server means you need to know all of its interfaces and usages as well. Source: David Cuthbertson, Square Mile Systems
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 centre has gone down – which services are affected?”. If you put all that unnecessary information into a CMDB (which some organisations 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 – confidence that it reflects the real world.
This resulted in some rather large and expensive projects to define, collect and feed data into their CMDBs – rather brings to mind Audrey II in Little Shop of Horrors – “Feed me, Seymour, feed me!”. The problem with the resulting CMDB projects, was that at least Audrey II provided success and romance to Seymour! The monster CMDBs consumed vast amounts of data and gave back out-dated, 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) optimise 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, summarises 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; …”
So 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/reorganised, 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) – insures 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 – 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 organisation is doing, particularly if you are developing applications which are part of the ongoing estate of your organisation.
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 sail off into the sunset, with the satisfaction of another job well done!
Figure 3 – But Application Development is only part of the Application/Service Lifecycle.
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.
You are often modifying the application 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 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 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 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 organisation does is release applications, and 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 organisation, providing more value to the business.
References
http://www.itsmsolutions.com/newsletters/DITYvol3iss24.htm, CMDB 3.0
ITIL is a registered trademark of the UK Government's Office of Government Commerce (usually known as the OGC).
Brad Appleton is an enterprise SCM solution architect for a Fortune 100 technology company. Currently he helps projects and teams adopt and apply agile development & SCM practices. Brad also author's the Agile CM Environments blog, and is co-author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, the "Agile SCM" column in CMCrossroads.com's CM Journal, is a regular contributor to "The Agile Journal", and is a former section editor for The C++ Report. Since 1987, Brad has extensive experience using, developing, and supporting SCM environments for teams of all shapes and sizes. He holds an M.S. in Software Engineering and a B.S. in Computer Science and Mathematics. You can reach Brad by email at brad@bradapp.net
Robert Cowham has been in software development for over 20 years in roles
ranging from programming to project management. He continues his involvement in development projects but spends most of his time on SCM Consultancy and Training for VIZIM Worldwide. He is the Chair of the Configuration Management Specialist Group of the British Computer Society, has a BSc inComputer Science from Edinburgh University and is a Chartered Engineer (CEngMBCS CITP). You can reach him by email at robert@vizim.com
Steve Berczuk is a consultant and developer who works with Agile teams. He has over 20 years experience developing application, often as part of geographically distributed teams. In addition to developing software he helps teams use Software Configuration Management effectively in their development process. Steve is co-author of the book Software Configuration Management Patterns: Effective Teamwork, Practical Integration and a Certified ScrumMaster. He has an M.S. in Operations Research from Stanford University and an S.B. in Electrical Engineering from MIT. You can contact him at steve@berczuk.com
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Subscribe to this comment's feed
