This Blog
Syndication
Recent Posts
Tags
Calendar
Archives
Iterating on IT Service
June 2007 - Posts
-
CMDB Federation of the Planets
Last week, the CMDBf gathered in Redmond and successfully ran its first interoperability tests. The atmosphere was collegial with everyone in the room on a first name basis. The sign Microsoft facilities had placed on the door read “CMDB Federation of the Planets.” Interesting place, Redmond. Next door, preparations were in full swing for an Xbox tournament, complete with balloons and a truckload of pizza.
To give you some background on the testing, back in February, the group published a white paper entitled “The Federated CMDB Vision” describing its vision of CMDB federation—one in which a federated CMDB pulls CI data from other data sources, called Management Data Repositories (MDRs), via a standardized interface. The federated CMDB then can reconcile the CI data, that is, determine whether a CI is new to the federation, or the same as an existing CI already in the federation. Alternatively, an MDR may push CI data to the federated CMDB. In the push model, the federating CMDB retains a list of reconciled CIs. When a push federated CMDB is queried, it can go to the MDRs for data that has not been cached in the federating CMDB, but the reconciliation is already done. This white paper became the basis of the interop test scenarios.
The interop testing was done on the interface between federated CMDBs and the MDRs that supply the data. The API consists of a WSDL (Web Services Description Language) interface spec and a specialized query language. Both push and pull models were tested. The results were posted on a grid displayed on the overhead projector. The prototypes were all implemented on laptops. For connectivity, Greg Goodman from CA brought along a home wireless router.
One by one the combinations were called off and tested. “CA to IBM?” “HP to Fujitsu?” Each was checked off on the grid. As the grid filled in, it was quickly apparent that the tests were uniformly successful, with only a little last minute tinkering required.
Success was not surprising. Most of us had implementations outside our firewalls and we had all run tests on each other’s systems for a couple of weeks. The interop test was an anti-climax. The real challenge was the run-up that transformed a theoretical spec into something that worked in practice.
I have been involved with several standards efforts. The CMDBf is different because it comes so close to affecting shipping products. XPath 2.0, for example, is an important standard. It affects the way many products will be written in the future. Nevertheless, as important as it is, I doubt that any vendor will have to abandon a product feature because something appears or does not appear in the XPath standard.
But we run that risk every time the CMDBf convenes. Federation is a market requirement for a commercial CMDB. We have all implemented federation in our own ways and we often compete on the strength of our federations. When the standard is published, some of those implementations will have to change.
You would expect this to generate heat, but, perhaps surprisingly, it has not been a problem. I think everyone recognizes that the nature of IT management is changing. Before ITIL®, you could build an IT management application any old way you pleased. If it had any ROI for the customer, you had a product. Customers look at IT more holistically now. An application must not only have ROI in its own right, it must also add value to the whole system, not just an isolated part. And the system is almost always made of parts from a variety of vendors. The vendor who works with the most other players has the advantage.
And what is the easiest way to accomplish this? With a standard, of course. So the CMDBf team meets twice a week, every week. We all bury the competitive hatchet and work together. We discuss the fine points of a query language one meeting, the subtleties of marrying incompatible inheritance systems the next. Arguing passionately. Agreeing inevitably, because that’s our job. The interop testing last week was just another step on the way to achieving a federation standard.
-
Winning the Whack-A-Mole Support Game
Even the best service support system can sometimes behave like a whack-a-mole arcade game with issues popping up like moles from their holes. Whack one mole down with the big mallet and more appear. Solve one problem and two new problems pop up. Solve the new problems and, well, you get the picture. To win the whack-a-mole support game you need the best mallet you can find—I recommend the ITIL best practices framework.
The way the ITIL best practices mallet is swung has been changing. For a long time, incident management was the first ITIL practice implemented at a site, often in parallel with problem management. Recently, I’m seeing that many sites opt to establish a change management practice before problem management.
Starting with incidents aligns with many maturity models, where the first stage is "reactive" and "proactive" comes later. Incident management is reactive. After an interruption or degradation of the service, the incident manager reacts to the incident and acts to return to business as usual. Problem management is proactive. Problems are identified and fixed in order to prevent future incidents.
Still, it’s surprising that sites are implementing incident management, bypassing problem management, and implementing change management. With the expectation of simultaneous implementation, incident and problem management are seldom talked about separately. Service desk vendors usually sell incident and problem management as part of a single package.
Prior to the rise of ITIL, most sites combined elements of both incident and problem management in a single process. Service desk managers would seek out and fix root causes when they had the time and resources. Consequently, most non-ITIL (or perhaps pre-ITIL) service desks have some problem management skills.
If ITIL problem management is not being implemented, is ITIL problem management broken?
I don’t think so. There are practical reasons for deferring—but not skipping—implementation of problem management practice, especially if a site can jump on change management.
It’s all about ROI. Incident management has a high and quick ROI because it is relatively easy to implement and touches on all support issues. From my experience, the primary benefit from incident management comes from the razor sharp focus it places on impact analysis and service restoration.
A service desk responding to an incident faces two questions: 1) How important is this? 2) How do I fix it? But service desks tend to make mistakes if they combine the two questions. The importance of the incident must determine the urgency and resources that are applied to the resolution.
Frequently, the technician will confuse the technical and business significance of an issue. He or she might assign a high priority to an incident that affects a big piece of equipment but fail to gauge the immediate consequences for business. In other words, they are lead astray by thinking about what has to be fixed before they have decided on the relative importance.
For example, the failure of a large backup storage unit is important, but the probabilities are good that it can be down for a day or two without any business consequences. At the same time, a minor situation that has major business impact may not receive the attention it deserves. For example, a routine printer problem that is holding up publication of an audit probably should take precedence over the storage unit. In this case, if the team starts on the big fix to the storage unit, instead of the big business problem, after hours of effort the service desk team gets whacked by an angry executive demanding his or her audit report.
Good incident management is the mallet that hits the right mole. Resolve the incidents first that affect your business most. That is the first step in winning the whack-a-mole support game.
-
Anticipating the CMDBf Interoperability Tests
In a few weeks, we’ll have the results of the CMDB Federation (CMDBf) interoperability tests. These tests will be conducted by the CMDBf technical committee on prototype federated CMDBs from HP, Fujitsu, IBM, BMC, Microsoft and CA. The results will let us know if the proposed standard is, in fact, a practical one.
CMDB federation is crucial to the IT industry. IT organizations need to be able to integrate asset data from across the enterprise and make it available to their various enterprise management tools. So—whether this initial test is an unqualified success or shows we have to go back to the drawing board—the Federation’s working group will have to get the job done.
BMC, CA, Fujitsu, HP, IBM and Microsoft have been running their prototypes together for weeks in advance of the official test. Some things worked right away. Others needed fixing. That’s why God created engineers. Having worked on a lot of very complex integrations, I know this stuff is never easy. In fact, some people have expressed a bit of skepticism about what we are undertaking. Others are simply impatient. But the big wins in this industry have never been achieved by either the skeptical or the impatient. They’re achieved by those who work through problems and remain persistent. I believe the skill and persistence of the CMDBf team will benefit everyone—even, in the end, those who aren’t that sure about what we’re doing.
Print
Email
Rate