Posted by Stefan Negritoiu, Program Manager
Perhaps the most tangible benefit of both the upcoming System Center "Service Desk" and System Center Operations Manager 2007 products is that they make end-to-end service management a reality and, through ease-of-use, accessible to IT departments without requiring a Ph.D. degree in Computer Science. A less visible achievement of the OpsMgr 2007 product is that it has been completely re-architected around what we call model-based management. I want to share with you the details of this vision and to talk about our plans for a CMDB which is the next step in our effort to model the IT environment and to make this innovation available to all management disciplines.
Let me start by explaining what I mean by CMDB (with all the loose definitions flying around you can never be too clear :-)). Depending on what management literature you read you may conclude that the CMDB is the pixie dust answer to all data management inefficiencies. On one dimension, opinions range from a static collection of replicated data to a dynamic “real-time” view that ties together the organization’s data pockets. On another dimension some folks see this database strictly in support of IT management functions others see it as _the_ database in support of all business processes whether ERP or IT management.
As diverse as these definitions are, the industry is converging on a few key aspects. Organizations have pockets of data and to make sense of it all we need a database not only to create an inventory of those things which matter to us, but also to relate them together. We need a unified view across all the disparate data sources in an organization. Curiously, many definitions lack a clear “why” to the whole solution. Sure, there seems to be this fuzzy feeling around having all data in one place but what specifically do we want to do with this data once we squish it in one place? Report on it seems reasonable, but I’d like to reach further and to use it for automating IT processes like change and incident management (reporting too, but I think the real efficiency gains come from automation).
My job is to build products so I approach the CMDB vision with a sense of pragmatism and, for now, confine the scope of the database to IT management. Besides, before asking a customer to spend lots of money ripping out core business systems it’s good to know you’ve solved the problem on a “smaller” scale. Between our learnings and those of our colleagues in the Business Solutions division and in the Identity Management group, great times are awaiting.
Ok, so maybe I’m not saying anything new and this may be obvious to many of you, but you’d be surprised to see that some vendors and IT organizations approach the CMDB as an end into itself rather than a means to an end. There are some short-term benefits to implementing the CMDB as a form of a data warehouse like to ability to create reports that present disparate data together relatively quickly, but long-term it’s fraught with cost and complexity. Most importantly, by making it an add-on product you underutilize the capabilities of a CMDB. A unified view of the IT environment is not only useful to humans as reports, but also to automated processes as a form of machine-readable knowledge.
In my team we believe in building the CMDB right into the fabric of the System Center suite of products because we see the CMDB as an enabler to efficient IT automation. I see specialized management solutions slowly evolving from vertically self-sufficient products to horizontal implementations that focus more on adding customer value. There’s a pattern to every management solution. Each has a discovery mechanism, a database for storing the details of those discovered entities managed by (i.e. hardware or software assets), a database for storing “operational” data specific to the management discipline (events and performance measurements for a monitoring solution or the definitive software library for a software deployment solution, etc), and the actual implementation/automation of the IT process (root-cause analysis, software deployment, etc) which is usually what the user experiences.
What adds customer value and brings us closer to efficient IT automation and a dynamic IT infrastructure is focusing on the actual automation portion. So, for us, investing in a CMDB is not just about gathering all management data in one place. It’s about building a management platform that abstracts the data gathering infrastructure to allow solution builders to focus on what’s important. An invaluable benefit is that we unlock data pockets to enable even more automation. When looked at broadly, change or incident management need data that normally spans multiple data stores. Building consoles or views that bring together information which previously required multiple products becomes the natural thing to do.
Let me also focus on the second part of our vision: model-based management. In order to build intelligent IT automation we need to store management data in a way that allows solutions to be aware, understand, and infer semantics and intent. The goal is two-fold. First, we want to allow decoupling of the data discovery process from the actual IT automation solution. It should be possible for one person to add new data sources to the CMDB and for another person to dream up new IT process automations independently. Second, we want to allow connecting distinct yet related data sets or, reconciling overlapping data sets. A unified view of a person in the IT system may be made up of Active Directory data, HR data, and custom user fields. These originate separately and sometime provide overlapping information. We need to express data in such a way that software can reliably compose a complete user profile and understand where data overlaps.
What we need is a data type system that gives us strongly-typed management data with the ability of adding semantic hints through meta-data. For those of you familiar with programming, our model-based management is innovating in the management space in a similar manner in which strongly typed programming languages innovated in the application development space. A very useful ability when programming in a .NET Framework environment is the ability to use reflection to understand semantics of any given object your code is dealing with. The object author or even 3rd parties can add meta-data to communicate semantics and intent.
Whether we realize it or not, every time we store data we make use, implicitly or explicitly, of a mechanism for describing that data. But some data modeling methods are created more equal than others. Management data for instance in usually stored in a relational database or is expressed according to CIM. None of these methods however provide sufficient mechanisms to express the richness of semantics needed to describe the complexity of an IT environment or to allow for the kind of decoupling we are shooting for with a federated CMDB.
Enter Service Modeling Language (SML) and the Common Model Library (CML). The former is an XSD-based domain neutral modeling language (or meta-model) that satisfies the requirements stated above. It has been in development for several years inside Microsoft and it first showed up in Visual Studio 2005 and Operations Manager 2007. With this experience built up, last year it was opened up to the industry for further refinement and standardization (the version being standardized is an evolution from what ships with OpsMgr 2007 and will show up in "Service Desk"). See more details at http://serviceml.org/.
SML sets the minimal baseline for describing data that we wish to bring together in a federated CMDB. However, SML is necessary but not sufficient. We also need to put forth some common models that various data sources can map into to indicate semantic equivalency. The CML (final name is still TBD) is trying to do exactly that. We don’t believe full compliance with the common models is necessary for data to be part of the federated CMDB, but a minimum sub-set is required to allow for federation and reconciliation. These operations fundamentally require the ability to tell CI instances apart or, even more important, to tell if two CI instances represent the same managed entity.
In a world without SML and CML every time new kinds of data come up (CIs or configuration items in CMDB parlance) the logic around how to federate and reconcile it into the CMDB must be manually crafted using costly IT knowledge expressed in code. Over time this adds up to a lot of code complexity as data sources expand and organizations become more demanding over the reconciliation rules. We don’t believe in asking customers to go through costly customizations every time they want to take advantage of an additional data source. Rather, we and our partners invest and do the work up-front to build models that ship with the management solutions or with the managed products themselves. The management platform simply does the right thing by taking advantage of the power of models.
In parallel, to bring our CMDB efforts to fruition, starting with last fall, we are involved in the CMDBF industry standard working group. Together with my esteemed counterparts from the other companies, we are looking at enabling federated CMDBs that would have direct access to any data source from standard-compliant vendors. For more details see http://cmdbf.org/ and most importantly this recent whitepaper.
--
Stefan has worked as a Program Manager in the Enterprise Management Division for just under 5 years. He was responsible for core monitoring features in MOM 2000 SP1 and MOM 2005, for the Web Sites and Services Management Pack, and for Web Application monitoring features and the overall synthetic transaction strategy in OpsMgr 2007. More recently, Stefan has been working on "Service Desk" specifically on the CMDB and the workflow infrastructure which used for run-book automation.
