Proxima is the maker of Proxima Centauri, a Service Level Management tool with interesting capabilities, specially in the way they aggregate key performance indicators into business service metrics.

Proxima has also a unique way to combine Six Sigma methodology and ITIL, to, for example, normalize the events generated by the monitoring of KPIs into Defects Per Millions of Opportunities, rolling them up into service metrics as Sigma numbers.

I don’t know how Compuware is going to use this technology, but one issue with the Proxima approach is that the service impact relationships, defining how IT components are contributing to a service, is defined within Centauri, using rules instead of model relationships .

Without a tight integration with a CMDB, SLM/BSM tools are required to duplicate the CMDB items and relationships, sometimes using two different models, providing a weak synchronization.

As a comparison, BMC Service Impact Manager is using the BMC Atrium CMDB as the model repository, adding service impact relationships on top of the exiting items, making sure that there is a tight synchronization between assets and business services. And since Compuware does not have a real CMDB, or a discovery solution (they use the Collation/IBM solution), it’s unlikely that they will be able to provide this level of integration.

• The model used seems to be developed in house, without any link to DMTF CIM : Why re-invent a model which already exists elsewhere ?
• The reconciliation of discovered data with existing data seems not existent.
• The security model seems inexistent (or I did not find it): no role based access.

I don’t want to be too harsh, but one thing I discovered when I joined BMC is that a CMDB is more than just a persistence store for an object model. It’s actually very complex, specifically the reconciliation and federation of various information sources. The CMDB is a virtually centralized repository for information residing in many, many different locations.

Another key ITIL recommendation for the CMDB, is that all modifications of the CMDB should be performed under change management control. Therefore, configuration management and change management are really tied at the hip.

I’ll try to play with this open source CMDB and explain in a bit more details the need for reconciliation, and integration with change management in some upcoming posts.

Anyway, thanks to Lokomo for releasing their sources under GPL.

I was going to just go to the test, but BMC Business School has an ITIL foundation training which includes the EXIN exam at the end.

I must say that I was surprised by the quality of the class, specifically the airport simulation. Within the 3 days class, there is one day dedicated to a simulation game applying “experiential learning” techniques:

In the simulation the airport has grown rapidly requiring the addition of numerous business services. With an increasingly complex IT infrastructure, a “Service Desk” has been introduced to support the business, along with a “Technical Specialist” team to maintain the infrastructure and resolve any issues that may arise. A supplier function is also included to provide additional infrastructure and consultancy. All students play a role in this, whether in the business or in the IT team ensuring SLA’s with the business are met.

Really not a boring way to learn ITIL (I’m sure that you CAN find really boring ITIL classes, this is definitely not one). If you are interested by the class, here is the link in the catalog. and you can even watch a video of the simulation.

]]> http://www.jcmartin.org/itil-foundation-certification-38-airport-simulation/feed/ 0 http://www.jcmartin.org/definitive-hardware-store/ http://www.jcmartin.org/definitive-hardware-store/#comments Thu, 12 Oct 2006 02:53:38 +0000 jc http://www.jcmartin.org/2006/10/11/1160621618603.html Today, I was corrected by one of my new coworker because I had the impression that all hardware within a given environment would be in the Definitive Hardware Store (DHS), while in fact ITIL defines it as :

An area should be set aside for the secure storage of definitive hardware spares. These are spare components and assemblies that are maintained at the same level as the comparative systems within the live environment. Details of these components and their respective builds and contents should be comprehensively recorded in the CMDB. These can then be used in a controlled manner when needed for additional systems or in the recovery from major Incidents. Once their (temporary) use has ended, they should be returned to the DHS or replacements obtained.

This basically means that it’s a set of standby systems used for failing over services in case of incidents. It seems that more practically, the systems in the DHS should be ready to be re-purposed on demand to solve any upcoming capacity or availability issue (instead of being pre-configured to match all possible systems in the environment).

Also, with new technologies like virtualization would this mean that virtual server images in standby could be stored in the DHS ? Is a virtual machine image closer to an hardware component or to a software package ? Any comment ?

By providing a common view of relationships and dependencies across the enterprise, CA CMDB simplifies and automates IT change and configuration management and ensures the availability of critical business processes. It delivers fast time-to-value by providing more than 70 relationship types, 140 pre-defined CI classes and 200 reports and queries out-of-the-box. With CA CMDB at the core, enterprise IT organizations can automate and integrate both ITIL Service Delivery and ITIL Service Support.

Interesting to see how it compares to other CMDBs.

It was named CMDB leader in a recent Forrester CMDB wave report, even though I don’t think that they really qualify as a CMDB. nLayers insight has the following features :

• Discover and Map
• Change Tracking
• visualize and analyze

Which indicate that their configuration database is populated from the discovered configuration, and not from approved change requests. It is therefore impossible to know if what is observed is the correct configuration, or is the result of an out of band modification. The nLayers solution is complementary to a real CMDB, under change control, if it is interfaced with a correlation engine, and an audit process which drive either :

• reverting the observed state to comply with the CMDB state
• update the CMDB state after creation of a change request.

Also, it is likely that because the information is discovered, the information about the CI cannot be changed to include user defined fields, or define custom relationships between CIs (which could not map to any discovered relation).

For example, nLayers Insight could not meet the mandatory criteria required for certification by Pink Elephant for Configuration Management (and they are not in the certified toolset list)

Lets look at the current state of affairs in that space :

It might look a bit like an alphabet soup, so here is the explanation :

• Sun has a product called N1 Service Provisioning System, which, while not really being a CMDB is able to model applications and associated artifacts in a language called CRML (CenterRun Markup Language). N1 SPS is more like a release management product coupled with a DSL, a Definitive Software Library. This markup language is expressed in XML using XML-Schema.
• Opsware has a CMDB in their Asset Tracking Edition. Opsware is a co-founder of the, now, OASIS TC defining the DCML, the Data Center Markup Language. DCML is based on RDF, the Resource Description Framework. RDF allow the definition of a taxonomy of data center objects and their relationships. DCML was not designed from its inception as a CMDB description model, and is trying to play catchup now.
• BMC is providing a CMDB, Atrium, built on top of a DMTF CIM model. This model could be exported using the WebService / CIM mapping: WS-CIM (now part of the WBEM Infrastructure and Protocols WG).
• CA seem to also use DMTF CIM in their CMDB.

That’s for the part about the CMDB vendors. Now, as for the modeling and the repository :

• UML, the Unified Modeling Language could be use to model and specify relationships used in the CMDB. UML is defined by the Object Management Group.
• UML can be exported using XMI, the XML Metadata Interchange format, also defined by the OMG.
• MOF, the MetaObject Facility, defined by the OMG can be rendered by using XMI (Not to confused with the CIM’s MOF, which is the Managed Object Format).
• The OMG MOF is a way to export models, and store them, in, for example MDR, the Metadata Repository. This repository can be accessed using JMI, the Java Metadata Interface.
• ebXML registry is an XML repository that can be used to store XML Schemas, this registry is specified under the control of an OASIS TC. ebXML registries can be accessed using JAXR, the Java API for XML Registries. There is some research work going on right now to add RDF/OWL support on top of ebXML.

It will be interesting to see where the new initiative will land in term of technology and standard body.