Here's an example that will illustrate how multiple records are used to represent a configuration item in CMDBf notation.

Let's assume I have an MDR that has information about VMWare guest systems. The question for CMDBf is - how will I expose this information to a federating CMDB or other CMDBf query client? One really good way is to map the information to the Common Information Model (I'll use version 2.16 for this example).

CIM_VirtualComputerSystem in CIM 2.16 is a subclass of CIM_ComputerSystem, which is a subclass of CIM_System, which is a subclass of CIM_EnabledLogicalElement, ...

In CMDBf parlance, there is an item representing this virtual machine (virtual "lump of plastic and steel" as some in the committee call it.) Then there are records describing this item.

Now, I could take all the inherited attributes from those CIM classes and make one big CIM_VirtualComputerSystem record. This would be really easy to process, but it leaves out some important functionality. What if I want to query for all Computer Systems or all Systems in general? This could only be done with a very complex query searching for all possible subclass record types.

Alternatively (and recommended), I can model the VM as an item with a CIM_VirtualComputerSystem record plus a CIM_ComputerSystem record, plus a CIM_System record, all the way to a CIM_ManagedElement record. This will allow maximum flexibility for the query client to find exactly the items it needs to query.

Now a more difficult question - if I want to use the Registration service of CMDBf and mass-register all my VMs, should I register each item with all these records? That could be a lot of network and parsing overhead. Plus, I wouldn't expect the federating CMDB to replicate and store all this information.

Probably the best answer is to associate another record with the item that provides just enough information to identify the item. This record should indicate that the item is a virtual computer system with a certain name and other identifying properties, possibly combining attributes from multiple superclasses. There is no standard schema for these identifying records today - this is an open question for the community to answer. Your feedback is welcome!

_____
tags: CMDBf |  Federation

I just got a "blast from the past" question about applications that are packaged with process models and monitoring (see http://talk.bmc.com/blogs/blog-wiles/van-wiles/PROCESSDOC1).

The new wave of applications are things like Oracle Fusion Applications (http://www.oracle.com/applications/fusion.html), the next generation of SAP Business Suite built on NetWeaver ESOA (http://www.sap.com/usa/solutions/business-suite/index.epx), and even the latest BMC Remedy IT Service Management built on the Remedy Service Process Management platform( http://www.bmc.com/products/products_services_detail/0,,0_0_0_1805,00.html).

The trend then and now (since it’s been almost a year since I posted that) is to build the business logic and rules using tools that business people can understand, then use this business logic to generate the technical implementation required to execute and monitor the processes.  Since I wrote that, many of these companies have acquired additional SOA technology through M&A and partnerships, including the BMC acquisition of RealOps for IT service automation.

Note: for SAP, Oracle and some other packaged business applications, you can get higher-level process models that are application-independent from IDS Scheer AG (http://www.ids-scheer.com).  For business rules, many of these vendors use Corticon (http://www.corticon.com/Partners/Software-Partners.php) or similar Business Rules Engines.

_____
tags: BPM |  Business Process Management |  IDS Scheer |  Oracle |  SAP |  SOA

Here are a few ways the CMDBf 1.0 spec (not a standard yet) can be implemented.

First - it is important to understand that the spec describes web services.  These services can be written and delivered by anyone, not just the vendor of a particular CMDB or MDR.  So let's say there are three scenarios (there may be more):

1. Each CMDB and MDR vendor produces its own CMDBf services for its own product lines
2. Third-party software vendors produce CMDBf services for popular CMDB and MDR products and market these adapters independently
3. Consulting service providers produce CMDBf services for custom applications to be used with other CMDBf implementations

I will guess that these are all viable options and could very well come to market in the reverse order from above (custom implementations first).

Second, the spec can be implemented in many ways - "push-mode", "pull-mode" or both, varying levels of query support, varying record types, etc.

Now comes a tricky question - can you market these adapters without a common data model, or an exponentially-expanding set of data-mapping objects?  The point here is that some maturity will be required before this is really plug-and-play.

So, leaving the modeling/mapping question aside for now, let's see how a third-party could produce adapters for a pair of MDR's.  I'll start with a picture.

In the picture above, all the CMDBf services and processes are provided by a third-party (call it Lavender Software.) Lavender has adapters for each MDR proprietary interface, plus transformers to register items and relationships from Vendor A to Vendor B CMDB, and a User Interface to query the registered CMDBf Query Services.

This picture could change if one or both vendors produce their own CMDBf services and the customer wants to switch.  In this case, Lavender Software might provide a way to switch services to another vendor.  In this case, you can imagine that it would be much less painful to exchange information between CMDBf services in a common format, at least in the case of registration.  Additionally, it would be really helpful to the query UI if items of like-kind had common type-names (like Incident or Computer System for example).

In the final picture, vendors A and B have provided XML schemas and registration processes for their services, and a contract integrator has been hired to connect the services.  All that is required is for the contractor to use the registered services and provide a query client interface for the customer.

Final note: open standards and open source go together like shoes and socks (except that standards smell better with age.)  There is an open source project giving some very interesting insight on a CMDBf implementation over SML/CML starting here: http://wiki.eclipse.org/Leveraging_CMDBf.  This is part of the Eclipse COSMOS project which is sponsored by some of the original consortium companies.  It should be a useful starting point if you are interested in implementing CMDBf.

_____
tags: CMDBf |  Eclipse Cosmos |  Federation |  Open Source |  Open Standards |  SML |  federated CMDB

I haven't posted lately - if you subscribe to this blog, I'm still here!

The CMDBf consortium work has wrapped up - I plan to be actively participating in the DMTF committee to support CMDB federation now.  I'm working on another post about CMDBf records in the meantime, while the DMTF committee is getting ready to launch.

In other areas, I'll be supporting development efforts to integrate with BMC Atrium technology.  I expect this technology to expand well beyond CMDB this year, so remember that "BMC Atrium" is not synonymous with "CMDB".  As always this will involve a lot of learning for new releases and features.  It will also require some leadership as we develop a methodology for validating and certifying interoperability.

Anyway - I wish you a safe and prosperous New Year wherever you are!

_____
tags: CMDB |  CMDBf |  Service-Oriented Architecture |  Standards |  federated CMDB

It's official - continuing work on CMDBf specification will be done within the context of a new DMTF working group.  Here's the press release:

http://www.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20071127005236&newsLang=en

That's a relief - it's public!

_____
tags: CMDB |  CMDBf |  Federation |  ITIL |  Open Standards |  Standards

I bought a new driver a couple of months ago, and just got a chance to try it on the golf course.  On the driving range I found that I got about 50 more yards of distance.  On the course I got the Rest of the Story.  That last 50 yards was usually on the wrong trajectory, leaving me in deep trouble most of the time.  But it sure is fun to use on the driving range!

I heard a similar story from a customer that makes Formula 1 race cars.  The problem to be solved in Formula 1 racing is not speed, but control - keeping the car on the track.

This same principle applies to IT process automation.  The fun part of automation is making things work.  The important part of automation is approval and auditing.  Make sure that approvals can be automated and that any automated changes can be tracked to a change request, audited, and backed out.  Automate the backout process too - ahead of time!

I guess this is obvious if you are an ITIL guru, but I thought the analogies would be interesting.

_____
tags: Automation |  Business Process Management |  Change Management |  ITIL |  ITIL Process

The concept of a record in the CMDBf spec is simple and powerful.  Like ITIL version 3, the CMDBf committee separated the notion of an item from the notion of a record.  (In case you didn't notice, ITIL v3 uses "configuration item" to refer to the actual thing under management, and "configuration record" to refer to a structured information record about that actual thing.)

Like many simple and powerful things, records could be used the wrong way, leaving a so-called "hole in your foot".  Thus I am offering a bit of explanation.

An item can be "associated" with many records.  This may be implemented as some sort of join by property on the item ID, or a set of unexposed relationships.  The important thing to remember is that a query for an item may return a mixed bag of records, some of the same record format (record type), and some of different formats.

The first thing to know about records is that they could give you a clue what the item actually is.  (If you hadn't noticed this, items and relationships don't have a "type".)  So if your item has a "ComputerSystem" record, it's probably some sort of computer system.  If it has a "ComputerSystem" record and a "Switch" record, well - I hope you get the picture.  The committee chose this approach to allow maximum flexibility that supports but does not require a hierarchical or object-oriented data model.

The specification does not differentiate between an "is-a" association and a "has-a" association.  For example, if an item has a "ComputerSystem" record and a "SupportContract" record, is the item a computer system or a contract?  That could be the first "hole in your foot".  There are two ways to deal with this.  You could decide that in your world a support contract could be associated with any item and will never be a separately managed item.  Thus you may structure your items as I just described. 

The problem comes up when this type of MDR is federated with another MDR that manages support contracts as separate items.  In that federation, a query for contracts may yield more items than the client expects. The other way to deal with this is to create a separate item with a "SupportContract" record and create a relationship with a "SupportedBy" record, where the relationship source is the item with the "ComputerSystem" record and the target is the item with the "SupportContract" record. 

This is a better way to model this, because in the most likely scenario, one MDR may have all the support contracts and know very little about the supported configuration items.

Think carefully about whether a record represents something that could be managed, or whether it is simply a collection of properties that could be associated with any item or relationship.

I guess I'll post more entries on this subject since there are several other tips to be considered.




_____
tags: CMDB |  CMDBf |  Federated |  ITIL |  Open Standards

These things always take longer than I wish they would, but the CMDB Federation 1.0 spec is really now available for review on http://cmdbf.org.  It will stay there for an indefinite period of time, at least until it becomes an approved standard (a not-so-big assumption I hope).

I've been asked to summarize the changes from the 0.95 spec.  Here's a little guidance to understanding what changed:

• The metaphor of selection was changed to align more with SQL.  The new metaphor is, for each template, select what you want in the results, and then apply constraints on the records and properties.  This is roughly comparable to "select column-names from table where value constraints apply".  In XML the structure in a template is either:

   <contentSelector> ?

   <instanceIdConstraint> ?

   <recordConstraint> *

or:

   <xpathExpression> *

• The instanceId constraint was changed to allow a template to match multiple instances by instanceId.
• A new <depthLimit> element was added to <relationshipTemplate> to allow variable depth on graph traversal.
• New common properties of records, such as lastModified, were added to a <recordMetadata> element as the second child of each <record> element.
• The <propertyValue> constraint may now be directed to <recordMetadata> properties using the @recordMetadata attribute.
• The <record> @recordId attribute was moved to a child element of <recordMetadata> to allow for query on recordId.
• The <xpathSelector> was replaced with <xpathExpression> child of itemTemplate and relationshipTemplate.  This allows greater control of XPath profiles and results.
• The <propertySubsetDirective> element was replaced with <contentSelector> with <selectedRecordType> and <selectedProperty> children.
• The <contentSelector> @matchedRecords attribute can now control whether all selected records are returned, or only the records that matched (the default).
• The <propertyValue> record constraint may now be limited to selected record types.
• The <dropDirective> element was replaced by @suppressFromResult attribute on itemTemplate and relationshipTemplate.  The functionality is the same.
• The relationship is now considered a type of item.  This means two things - the "item" part of a relationship could be returned in a nodes list if it matches the constraints of an itemTemplate, and a relationship could be the source or target of another relationship.  There are some interesting use cases for this, but I'm not sure how widely implemented this will be.
• "Section 6 - Service Metadata" was added.  This allows an MDR to publish the record types and optional query capabilities that are supported by the Query and/or Registration service.
• "Section 7 - Secure, Reliable, Asynchronous Federation" was expanded to discuss issues and considerations to be addressed by the implementation, that are mostly beyond the scope of the CMDB Federation specification.
• SOAP faults were defined for each operation.

_____
tags: CMDB |  CMDBf |  Federation |  Open Standards

The CMDB Federation V1.0 Spec is ready for review by a standards body now.  The past couple of weeks involved a crescendo of activity getting this finished.

The technical committee will place the updated spec on http://cmdbf.org, and further communications and updates should be handled by this (soon to be named) standards body.

Note that there are some significant changes to the spec - some features that we hadn't finished in the 0.95 spec are there now, and there were some structural changes to improve usability and extensibility.

Probably the most significant change is the addition of a "metadata" schema that allows an MDR to advertise its supported "record types" and "query capabilities".  The spec will recommend that this information be made available through a policy in the Web Services Description Language document for the Registration and Query services.

The technical committee members also plan to create some helper documents to explain intended usage, answer questions, and provide examples to help the implementers.  This may take a couple of months - I think we all need to take a breath and catch up on our "other activities" for a week or two!

_____
tags: CMDB |  CMDBf |  Configuration Management Database |  Configuration Management System |  Federation |  Open Standards

Doug Mueller was with me for one of those meetings, and he has some very practical advice.  CMDB should only contain information needed to support key IT business decisions.  Also, this information should be required for at least 40% of all references to a configuration record (Doug's rule of thumb).  I added (and Doug agreed) that volatile information doesn't belong in CMDB.  A "can run on" relationship is relatively non-volatile, but a "is running on" relationship can be very volatile, especially in load balancing and virtualized environments.

The CMDBf view is that only "identifying properties" should be in CMDB, and other information federated from MDRs.  Further, there seem to be common ways to identify common configuration items, so perhaps these can be recommended as a sort-of reconciliation data model.  Stay tuned on this subject.

So, what is an "identifying property?"  That can vary by population.  Let me give you an example.  If I'm meeting you in a room and you have never seen me, I can tell you I am male, brown eyes, thinning brown hair, etc.  That may be sufficient to identify me in the lobby of my building, but not at a football stadium.  I could plan ahead to wear something that identifies me, or stand in a specific location (probably the best plan), but this is only good for a moment in time.  Of course I could give you my unique identifiers (SSN, driver license, etc.) but obviously this information, while unique and reliable, is difficult to obtain.

These are some of the challenges of reconciliation.  The "system board UUID" may require an on-board agent to obtain.  The name of a business application may only be known to a group of users, or filed away in a spreadsheet or process model.  A good reconciliation process needs to be flexible (in the extreme).  This makes it very difficult to standardize.  CMDBf is making a step or two in this direction by examining the mechanisms required for common configuration items.  However, ultimately the best reconciliation process will be determined by the implementation, and this will serve to differentiate the solutions.

_____
tags: CMDB |  CMDBf |  Federation |  Open Standards |  Reconciliation