This is obviously a very leading question, as several more questions will flow from it:
- • How is it refreshed / kept up-to-date? Is it a manual process or done automatically; if done automatically, are there multiple tools required or only one?
- • Assuming it is up to date, what use do you get out of it, i.e. is it integrated in Service Management processes like Incident Management, Change Management?
- • Does it integrate into your DevOps approach (where applicable)? – and:
- • How do you define “up to date”?
In our experience the Configuration Management Database (=CMDB) is one of the most neglected components of any IT department. It does take significant effort to define, create and maintain, and its benefits can be quite difficult to quantify. Why is the state of configuration management within IT still immature?
Consider some – not perfect – analogies:
- • Would any airline company fly planes until there are no longer spare parts available?
- • Would a food retailer store items in their warehouse without knowing best-before dates?
- • Would a manufacturing company only order parts once they have run out of them?
In a similar way is it really economical for an IT department to run old servers (that generally have less capacity, consume more power and generate more heat?) – just because all the IT department is using is an asset register, which provides purchase date, but does not provide additional details that link devices into the data centre.
How is it possible that companies are still using obsolete software (e.g. Windows Server 2003, which has been out of support for more than one year? Or on a related note: build new Windows Server 2008 environments, which are past mainstream support and will cease to be supported in 2020.)?
Or why is it common for support staff to first confirm the details of the environment with any new incident instead of having this information readily available within the CMDB?
It usually comes down to the fact that the CMDB does not contain any information or linkage to recent upgrades (e.g. added additional memory at some point?), disk and storage information, installed tools & software. All too often the CMDB is also being infrequently updated.
The CMDB has been an integral part of IT Service Management (e.g. ITIL) for a long time, as it can provide rapid information about the existing environment and can highlight connections and dependencies that otherwise may be easy to miss. In this way it will assist in resolving any issues quickly (incident and problem management) and even more importantly can avoid experiencing issues in the first place: performed as part of change management, where it is possible to gauge the impact of a change on the whole environment.
Unfortunately, the value of the CMDB does not decrease with new approaches to the development and management of IT infrastructure, but rather the opposite is true. A DevOps approach relies heavily on the use of (near-)identical environments for development. One way to assist this is by using a well-defined and well-maintained CMDB.
The challenge is – and has been for some time – to maintain the information within the CMDB in an efficient manner. This starts with:
- • A clear definition of what information and level of detail should be held within the CMDB.
- • And a decision how this information is best maintained
- Is it necessary to include minor detail for components: e.g. ‘Provider A’ 5m LAN cable, ‘Provider B’ 5m LAN cable; ‘Company C part-no of a 2 TB internal 7200rpm SATA disk’ or
- Is it sufficient to have a high-level summary in the style of: x86 server with 256 GB RAM, 2 CPUs with 24 cores?
The answer will depend on the complexity of the environment, the maturity of IT Service Management, the aim and type of IT department and – last, but not least – the available tools.
Many components within the IT organisation will depend on a combination of people, tools and processes; however, keeping the CMDB up-to-date is easiest to achieve with a well-integrated tool that automatically discovers any changes and is tightly integrated with a service management platform.
One of the challenges will be to include the cost for the required tools (and the additional people and processes that will still be required to manage the CMDB and Service Management) that need to be included in any TCO calculation for any new hardware, software or service.
It has been said that IT has to be a part of the business. Coming back to the first example of airlines, several major carriers in the U.S. suffered serious outages this year. Although probably not all could have been prevented with a better CMDB and Service Management, there is some indication that the extended outages were due to ignorance of the exact impact of planned changes. This also highlighted the close relationship between the Business and IT.
Can you in light of this really afford not having your CMDB up to date?
Diaxion recommends an approach of:
- • Discovery of the current state and the desired outcome;
- • Analysis of the current CMDB state and requirements;
- • Recommendations;
- • Remediation and/or implementation.
