http://developer.bmc.com/communities/blogs/loosecoupling
Thanks for reading - I look forward to a continuing dialog! My latest post deals with CMDB Federation (as is usually the case) and comments about a purely federated approach to Configuration Management System.
Best wishes!
Van
_____I can state my opinions about what is going on in the CMDBf workgroup, including giving some insight about what I am thinking in the meetings, but I cannot really say what the workgroup has decided or is considering. Therefore, please note that whatever I say about this workgroup is my personal opinion and is subject to change or different interpretation from other members of the workgroup.
OK, disclaimers aside - things have changed slightly since we started the CMDBf workgroup at DMTF (as you would expect unless we are just wasting our time!)
In a previous posting about modeling CIM_VirtualComputerSystem I indicated that the best way to expose a sub-classed model in CMDBf is to associate an item with records of each class in the inheritance hierarchy. This would still work (and may suit your purposes), but an MDR is also allowed to return an item with a record that has the properties of the requested recordType even though the recordType has a different name.
Ah - let me clarify with an example. Let's assume (contrary to my last post on this subject) that the MDR implementation models CIM_VirtualComputerSystem as one big record with CIM_ComputerSystem and all other parent-class attributes. The CMDBf client issues a query for items with CIM_ComputerSystem records and certain propertyValue constraints. It is legitimate for the GraphQuery operation to return these items with:
If I were implementing a CMDBf Query service I would choose the latter approach because the client will not need knowledge of the inheritance model to understand why the operation returned CIM_VirtualComputerSystem in response to its CIM_ComputerSystem query. There is also the possibility that this knowledge could be conveyed in the XML schema or other mechanism, but this places a pretty big burden on clients who don't understand my data model.
One more note on the subject of CIM_VirtualComputerSystem - its usage is apparently being deprecated by CIM (see http://www.dmtf.org/standards/cim/cim_schema_v219/cim_schema_2.19.0Experimental-MOFs.zip) in favor of simply using CIM_ComputerSystem with a CIM_HostedDependency relationship to another CIM_ComputerSystem. What? This is presumably because so many management systems have a hard time distinguishing between virtual and physical systems.
There's also an issue of how a Query service interprets a request if the MDR has something like BMC_ComputerSystem when the client asks for CIM_ComputerSystem. The GraphQuery operation may return these items with:
Again I would choose the latter approach, but I can't really factor out any properties from BMC_ComputerSystem because BMC_ComputerSystem is not formally derived from CIM_ComputerSystem and does not have an identical set of properties. It's just another record which the client may choose to use or ignore. If the client just wants CIM_ComputerSystem records, it can use the contentSelector/selectedRecordType to screen out the BMC_ComputerSystem noise.
I hope this gives you some more perspective and clarity. Things are a lot more clear for me, but that is mostly because I just cleaned my glasses!
_____
Basically his answer can be summarized as: (a) Some authoritative group like the CMDBf workgroup defines a convention for mapping CIM association roles to CMDBf source and target, and/or (b) CMDBf workgroup provides an ontology language that allows records to be related to each other (e.g. RDF/OWL semantics.)
While I like his proposal about a naming convention for relationship records (such as CIM_Dependency_from_Antecedent_to_Dependent), it would allow any implementation to model the source/target direction either way. At least it would be definitive about the role of source and target for that relationship. I also like the idea of having an ontology language to describe the record types more thoroughly, but I would not want to force MDRs and consumers to read and understand the ontology in order to use the interface.
I guess in a perfect world everyone would model it the same way, so if we said "source is always the first role and target is always the second role" we would at least have a simple match most of the time, and the naming convention would confirm the roles of source and target.
Note that an ontology language or some embeded mapping of data models allows an MDR to return records it considers to match your query, even if the record type has a different name. Here's an example.
Assume I could have this i1 -r1-> i2 <-r2- i3 graph in a CIMOM where:
So in English I have an organization which depends on a cluster of computer systems.
Now I want to see what computer systems support this organization. I can invert r2 as CIM_ConcreteDependency_from_Antecedent_to_Dependent (vr2) and have this: i1 -r1-> i2 -vr2-> i3. Now I can query i1 to i3 via CIM_Dependency_from_Antecedent_to_Dependent with depthLimit 2 or more and find this graph. Great! But I made a couple of assumptions that the casual observer might not have noticed:
Reversing direction in the underlying data store query could be challenging, but that’s why we hire geniuses (well maybe we need a few more).
_____
So we have this question about how to expose an existing CIM association as a relationship using the CMDBf metamodel. Take CIM_Dependency for example. It seems that about half of all CIM associations are based on CIM_Dependency so answering this question may be generally useful.
CMDBf would require the MDR to represent a CIM_Dependency association as a relationship between two items, where the relationship has a record of type CIM_Dependency (and maybe other records too). So far, so good (a no-brainer if you have been following my blog or other CMDBf activities).
Now - how do you represent the Antecedent and Dependent properties of this record? The first part of the answer is not too hard - a concatenation of the existing Key properties of each CIM instance will work within a CIM Object Manager. But how do you relate Antecedent and Dependent to CMDBf source and target in the relationship metamodel? That's the tricky part (and very important for an MDR, I might add). In the picture below, can you tell whether Computer System depends on Person (like server depends on administrator) or Person depends on Computer System (like I depend on my laptop)?
If your MDR implementation decides that the Antecedent role maps to the relationship target and my MDR implementation decides that Antecedent maps to source, we won't have interoperability even though we are both using the same data model (!!) In other words, our MDRs may not reconcile or respond to a query with predictable results. A graph traveral from one MDR to the other may get stuck in between.
It would be a lot easier if every Association in CIM had a sense of direction, like "depends on" for example; then it would be grammatically obvious (at least to someone who understands English) - source depends on target. I suspect it's a bit late for that wish to come true.
There may be a couple of ways out of this modeling conundrum. The CMDBf workgroup at DMTF could define how to map these basic CIM association REFs to source and target and ask every MDR implementation that supports CIM to follow these conventions. That's a real possibility and easy to implement if we catch every MDR before they go with their own instincts.
I had another way out, but got lost in the maze. Help! I'm waiting for someone else in the workgroup or in my little blog world to make a better suggestion.
_____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!
_____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.
_____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.
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!
_____That's a relief - it's public!
_____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.
_____I've been asked to summarize the changes from the 0.95 spec. Here's a little guidance to understanding what changed:
<contentSelector> ?
<instanceIdConstraint> ?
<recordConstraint> *
or:
<xpathExpression> *
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!
_____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.
_____If my wife can understand process optimization, it must not be technical. I had found a common vocabulary related to my work! Then I realized that this is the challenge of IT - understanding the processes that make money for their respective companies, and then figuring out how IT can improve these processes. It may be simply a better technical solution for a key activity, or it may be the application of new technology that the process owners didn't know about.
So, how do you as an IT person become aware of your company's business processes? There's really two answers: first, the business has to document these processes (methodically). Second, you have to find this documentation and put it to use. If your company has a business process management or enterprise architecture practice, that's the best place to start. If not, maybe they need someone like you to "bridge the gap"?
_____