Do not invest too much in building your CMDB now!

Interesting enough a few days ago a new version of the CMDB federation Whitepaper has been posted. The list of participants is impressive as we find every key players in ITSM including Microsoft…CA, IBM, BMC, Fujitsu, HP and Microsoft have worked together to propose a standard for federating data from ITIL compliant CMDB repositories. The intention is to submit their achievement to a standard body sometimes this year. For the time being, this is a draft which is reviewed by the main IT Service Management actors.

In this current version, there are explanations how to push or pull information from/to various CMDBs into a main CMDB. These “other CMDBs” are named: MDR, Management Data Repositories. Exchange mechanisms and technologies used to access these MDRs will be based on the SOA stack (HTTP, SOAP, WSDL, XML).

What does that mean concretely?

· In a few months (years?) vendors could sell Service Management solutions with a different metamodel
· Instead of using autodiscovery tools, vendors could provide these push pull mechanisms for companies which already have in place other platforms such as Asset Management systems, or system management platforms, or other inventory systems
· It becomes maybe un-necessary to build proprietary bridges with systems which contain important information to build a CMDB. This could be postponed.
· Vendors which actually come with tactical scenarios such as HP-Mercury with their UCMDB could change their strategy sooner than expected!
· Companies in a CMDB project may have to “migrate” in the future to another approach, based probably on a hub and spoke architecture
· Taxonomy being a key challenge for such a project may impact existing CMDB implementation

Companies which started to build a CMDB should measure the impact of that initiative in the long term with their vendors as the CMDB landscape could change dramatically in the next months.

Service Level Management and SOA. more confusion?

Service Level management in an ITSM context

Everyone into ITSM may use the Service Level Management process to maintain and improve IT Service quality through a constant cycle of agreeing, monitoring and reporting to meet the customer’s business objectives.

Service Level Management is the name given to the processes of planning, coordinating, drafting, agreeing, monitoring and reporting on SLAs, and on the on-going review of service achievements to ensure that the required and cost-justifiable service quality is maintained and gradually improved.

One of the activities related to that process, is the creation of a Service Catalogue which was subject to another post: “Service Catalog, what do you exactly mean?” where I tried to distinguish the different types of catalogues when we refer to either an ITSM or an SOA environment.

Most of the time companies which have implemented a service desk have a SLM module which allows defining different kinds of level agreements:

• Service Level Agreement (SLA): Which are written agreement between an IT service provider and the IT customer. SLAs are normally used for internal customers
  
• Operational Level Agreement (OLA): Which are agreement between two internal IT areas/departments e.g. Network Management and Operations
  
• Underpinning contract: Which are contract between an external supplier providing services to an IT department
  

Many vendors have dedicated modules which manage the SLM lifecycle with requirements collections, monitoring, escalation, and various dashboards. These modules are obviously linked to other ITIL processes and information is kept in the CMDB. Among various solutions we have different SLM modules from HP-Mercury, HP-Peregrine ServiceCenter, CA Unicenter Service Assure, BMC Service Level Management, Assyst for Service Level management, Expertdesk.

These solutions allow managing the end to end SLM process in an efficient manner through an ITSM view and sometimes the content is routed to a Business Service Management solution or specific modules managing SLAs in dedicated dashboards such as Tivoli Service Level Advisor among other system management solutions.

Service Level management in a SOA context

In a previous post I was referring to one of the intersection between ITSM and SOA. “Amberpoint proposes a module to manage web services, their performance and availability. It can monitor failures, send alerts, display useful information related to problematic web services, automate performance and so on.

HP Mercury Systinet 2 has a module title Contract/Consumer Management which promotes trust between consumers and providers by facilitating service-level agreements and other terms and conditions that bind these two key stakeholders.

Progress Actional Looking Glass provides dashboard and reports which define, sort and prioritize by business or IT metrics (customer, transaction or service type). SLAs are also monitored, managed, measured and alerts are generated. We can also easily monitor and report on SLA's for a specific customer or class of customer such as gold, silver, etc.

For some consistency we should differentiates SLAs in an ITSM framework from SLAs in a SOA. For these reasons a good thing would be to create a new acronym: WSLA for Web Service Level Agreement!!

A WSLA could either be attached to a specific service or to a composite service. WSLAs should then be linked to SLAs. An end user does not have to know what the underlying architecture of his applications is. The Service Level Manager (if such a position exists…) has to negotiate with the customer SLAs. If an IT service is based on various technologies including SOA, he should take into considerations OLAs, Underpinning contracts and WSLAs!!!

WSLAs could also be attached to Underpinning Contracts is web services are either 2rd party services or hosted externally.

Most of the SLM activities remain the same however some of them may differ:

The Service Level Requirement activity will have to be taken into consideration the definition of the WSLAs. It will not be necessary to specify to the customer the underlying technology.

The building of the Web Service Catalogue is different from the Service Catalogue and probably the responsibility should be shared between the SLM manager and the SOA experts.

The SLAs creation and review taking into consideration OLAs and UCs should also consider WSLAs. If possible a hierarchy should be built.

Monitoring should be done at two levels:

• At the SOA level (eventually in SOA center of excellence or an operation dedicated team


• At the ITSM Level (the Service Manager should have a global view on all IT services)

Coming back to Service Level Management and solutions available in the Service Desk arena, companies should be able to only deliver one and only one SLA per service and monitor it. IT and business dashboards should aggregate all underlying categories of SLAs. In other words SOA Governance vendors should be able to provides APIs to upload data related to WSLAs into any IT Service Desk/System Management solution covering the SLM process.

"The CMDB Initiative..”, but where is the evolution?

Late April, a group of system and service management vendors decided to propose a standard related to a repository for IT assets, and their configurations items change over time.

In other words, BMC, Fujitsu, IBM and HP decided to create a model for a CMDB which would allow storing information such as desktop and laptop client images or configurations, servers, storage pools or networks and so on.

Very often information is spread among various sources and no standards exist on how to exchange meta data from all these potential sources of CMDB information. Today, the CMDB interfaces that exist are all proprietary, which is the problem that this group wants to tackle.
This working group will issue a white paper within the next month that will spell out their initial goals in more detail. And by the end of the year, they hope to have a draft specification proposal, at which point they hope to formalize the process by choosing a standards body.

But is that enough?

Focusing on data exchange is fine but shouldn’t they also consider the CMDB Meta data and propose a common model eventually re-usable by third parties?

All vendors’ CMDB have their own Meta model and as from now I have never seen from any vendor a roadmap related to the repository. As an example, with the acquisition of both Mercury and Peregrine, HP initially announced the migration from the HP Openview Service Desk, to Service Center, and now has announced that next CMDB would be the one from Mercury, which is in fact…Appilog… (An acquisition from Mercury). So what!

There is a need for a “next generation CMDB” for the following reasons:

- BPM based on a SOA architecture invoque IT components (software on hardware…) and we should have a link between a Business Process and the underlying Cis. A CMDB should also be process based.
- Relation is important that’s for sure but dependencies is another key topic. How does infratructure relates one to the other, how information relates one to the other, how physically components relates one to the other, how does application code relates (Cendura acquired by CA is maybe one of the only company which deleivred that capability) etc… A CMDB should be also able to add dependencies on the top of relationships.

This initiative will help the concept of federated CMDB and information exchange but will not really look at today’s requirements… A unified Meta model could be an interesting initiative for these vendors as this would create a new generation of unified Service management/Business Process management solutions.

Will Service Management solutions become SOA Governance platforms?

As a starting point, let’s re-define what a Configuration Management Database (CMDB) is… A CMDB is a database that holds a complete record of all configuration items (CIs) associated with the IT Infrastructure, software, hardware, including information about servers, storage devices, networks, middleware, applications and data, i.e. versions, location, documentation, components and the relationships between them.

Configuration Management which is one of the main ITIL processes requires the use of support tools, which include a CMDB. Physical and electronic libraries should be set up parallel to the CMDB to hold definitive copies of software and documentation.

Until now, several vendors have provided through their Service Desk offering, and out of the box CMDB which in some case could be altered. Among these vendors we can find, BMC-Remedy, HP, Peregrine (now HP…), Axios systems, Computer Associates, Mercury (now HP…), IBM, and many others.

Last April, some vendors like CA, BMC, IBM, and Fujitsu announced they would work toward developing "an industry standard for federating and accessing IT information" that would ideally integrate communication between disparate configuration management databases.

CMDBs have become one of central elements of enterprise IT management, so a standards-based approach to this critical functionality is necessary and valuable.

Looking at SOA and the way we define composite applications and services, we definitely need to build the latest on the top of existing IT Infrastructure, software and hardware. In other words, a CMDB could also be used to manage the catalogue of SOA Services!

I would be tempted to think that in the next 2 years, a CMDB will be a modular component, usable by either Service Management solutions, and/or SOA Governance products. A CMDB could become a sort of “plugin” available from various vendors with sets of APIs, and why not web services.

SOAs are distributed computing plans where companies often situate Web services and reuse code and other assets to create efficiencies. Vendors like IBM, Microsoft, BEA, Oracle, and Mercury are creating SOA infrastructure platforms to speed information exchange between different computing machines. A few months ago, prior to HP acquisition, Mercury acquired a SOA company named Systinet. This acquisition strengthened Mercury's position in the high growth SOA (Service-Oriented Architecture) market by giving the company leading SOA governance and lifecycle management products.

An integration point should be between the SOA metadata repositories and a configuration management database (CMDB) to manage the lifecycle through to operations. If HP considers the range of acquisition they recently did with Peregrine, Mercury...and Systinet…there would be a high probability, this integration occurs!

Another observation on this future integration is potentially visible with IBM. IBM released recently a CMDB titled Tivoli CCMDB, and also launched a management and security solutions for managing SOA based applications, IBM launched last April IT Service Management platform.

The IBM IT Service Management platform manages SOA based composite applications. It is supposed to offer an approach to defining a framework and solutions for IT service management, including extending self-managing autonomic computing to IT services.

“Tivoli CCMDB uses a Federated model that allows it to be implemented on top of an existing sources of IT data, and serves as an authoritative source of data for configuration items, their relationships, so that when a change needs to be made to any of the IT components, one can understand the impact of that change on other related components. IBM's ITSM platform along with, IBM Tivoli security and compliance products like Tivoli Access Manager and Tivoli Federated Identity Manager delivers a complete end-to-end solution for the "manage", "secure" and "compliance" of distributed SOA applications.”

IBM and HP are two companies which will probably compete in both IT Service Management and SOA. They probably understood the synergy between the two worlds, and we can predict a future new generation of CMDBs, modular, accessible from web services, and used for several companies needs: Service Management and SOA Governance.