Iterating on IT Service

Most of the country thinks CSI stands for "Crime Scene Investigation," as popularized on TV. In a convoluted sort of way, the acronym means something similar in ITIL® v3. This is a stretch, but bear with me.   

In v3, CSI stands for Continual Service Improvement and it is the fifth volume of the v3 publication. In the v3 scheme of things, CSI is the culmination of Strategy, Design, Transition, and Operation and is the phase in the service lifecycle that actually is part of all of the previous four phases. But too often, CSI becomes Crime Scene Investigation when we in IT mess up.

On TV, the ensuing activity takes place in Las Vegas, Miami and New York. In this blog, we visit Washington DC...

Recently, the Census Bureau announced that they are abandoning a plan to replace paper and pencil with wireless handheld computers for the 2010 census, a move that will add 3 billion dollars to the cost of conducting the census according to the New York Times in an article entitled "Dust Off the Pencils: Plans for High-Tech Census Collapse." The Washington Post article is entitled Census Back to Pen and Paper. I'm not sure what bothers me more, overlooking industry best practices, the $3 billion, or sharpening all those pencils. 

As a student of ITIL, the phase "crime scene" might come to mind when reading the details. I don't want to point fingers or try to second guess the participants based only on a couple of news items, but this is an example of a failure in service management that ITIL good practices are designed to prevent.

Apparently, the problem began in the strategy phase when the requirements for a projected service are formulated based on the strategic goals. I infer from the news reports that the strategic goal of this service was to increase the accuracy and decrease the cost of the census. The strategic plan was a reasonable, even modest, extension of commonly used inventory technology: use GPS enabled handheld computers to record the exact location of each canvassed household and wirelessly transmit the collected data to regional accumulation centers. According to the reports, the requirements for implementing this plan were not thoroughly understood or communicated to the partner who was to supply the devices. As the project proceeded, more and more requirements were added, under-estimates were revealed, and costs ballooned, eventually resulting in the cancellation of plans to implement the service.

It is not clear whether the service ever got beyond the design phase and into transition where it would have been tested and deployed into the production environment, and it certainly never reached the operation.

In the ITIL v3 service lifecycle, CSI plays a role in every phase. Experience with the service in each phase is collected and analyzed to discover ways to improve the service. In the case of a failed service, this is a lot like Crime Scene Investigation, looking for the mistakes made and tracing flaws so that the service can be improved in the future.

Census takers may still use pen and paper in 2010, but if the Census Bureau applies CSI properly, there is a good chance that the 2020 census will be automated.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

As CMDB experts go, I have a lot of experience, starting with implementations a decade ago when ITIL was almost unknown in North America. Still, a question posed to me at CA's recent customer-focused Development Buddy Summit sent me to the books -- the ITIL® books that is -- hunting for an answer.

In a one-on-one conference, a customer asked me if it was appropriate to use "people CIs" in the CMDB to track subscribers to services.

Hmmm. Technically, the CA CMDB can support such a practice. After all, it has a CI family representing people that can be connected with applications such as HR and LDAP (Lightweight Directory Access Protocol that helps you locate individuals and other resources on the Internet or on an intranet) that specialize in information about people. Theoretically, those "people CIs" could have a "subscribes to" relationship with service CIs. But maintaining these "people CIs" would be a predominantly manual process that would not scale easily throughout an enterprise.

I suggested that CA Service Catalog could be the solution as it is designed to track and manage subscriptions to services.

Though I had provided an answer, the nagging question followed me back to my hotel room and kept me awake that night. When a customer asks for something, I like to examine the need in depth. If one client perceives a need, then others might as well and that could lead to useful product enhancements.

This question sent me to the ITIL v3 library for an answer. If ITIL suggested using people CIs to represent service subscribers, then perhaps we should consider putting more support for it into the CA CMDB.

After hours of research that took me through several ITIL v3 volumes, I concluded that ITIL does not suggest using people CIs in this manner.

The ITIL v3 Service Transition publication does list "people" as potential CIs, but only in two types of CIs. The first type of CI that includes people is the Service Capability CI. This represents the intangible capabilities or expertise that organizations, functions, teams, or people have to design, implement, operate, and maintain services. The second type of CI is the Service Resource CI. Service resources are tangible assets that can be drawn upon for services. A person is a service resource when he or she is employed to design implement, operate, or maintain services.

Subscribers, users or customers of a service are neither service resources nor service capabilities. Rather than contributing to a service, they receive value from a service.

ITIL talks about services as a way for users to assign costs and risks to a service supplier. In other words, service users are seeking to gain the benefits of service capabilities and service resources without taking on the risk of owning these capabilities or resources. Therefore, although ITIL v3 suggests people be included in the CMDB, it does not suggest service subscribers, users or customers should be CIs.

Since ITIL is good practice, not law, I did entertain the notion of including service customers in the CMDB even though this practice was not mentioned by the ITIL authors. Ultimately, I decided against it. SACM (Service Asset and Configuration Management, the processes that own the CMDB) focuses on supporting the implementation of service designs that represent solutions that meet requirements based upon enterprise business strategies. That is a tall order, but it does not include managing the users of services. Loading the CMDB up with subscribers, users and customers is bound to invite confusion and error.

The conclusion I came to after several days of research matched the answer I gave during my client meeting: A service subscription catalog, which is designed to support the customer-to-service relationship, is the right place to house service subscriber, user and customer information.

I don't regret having invested the time. Researching answers is my favorite way to learn. Plus, I'm sleeping soundly once again.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

Last week I spoke with a Hungarian banker about the CMDBf specification. He was broad and burley, with a thick beard, a muscular neck, shoulders like a bear, and a gruff, heavily accented voice. "CMDBf?" he sneered with a toss of his head. "I'll believe it when I see it."

I was dumfounded, though not with his skepticism. After all, although I see widespread adoption of the CMDBf specification as very likely, mine is an insider's view that I don't necessarily expect the rest of the world to share. I know that the federation of management data sources (MDRs) is important because I've seen organization after organization struggle to make sense of the wealth of information and dearth of coherency that characterizes so much of IT. No, what astounded me was that he had heard of CMDB federation and had heard enough to form an opinion. Had he read my blog?   

His organization is embarking on its ITIL journey and he and his Hungarian banker colleagues (all IT professionals) had many questions on where to start and how to maximize and hasten ROI. The fact that this organization, only just beginning to establish consistent IT management practices, recognizes the importance of federation, tells me something about the sophistication of IT practitioners today. It underscores the fact that federating MDRs is not a theoretical problem on the horizon. It's a real problem being faced today around the world--literally.

The Hungarian bankers asked questions about CMDB practices that I have heard many times--questions that anyone who is contemplating installing a CMDB should consider carefully.    

"Where should we start?" I told them that the starting point for a successful CMDB installation is to understand your needs. Every IT organization has its own set of priorities, the things that it does that are most important. That is where you must begin. Identify the most important services you provide, then the infrastructure and subservices that support those critical services. These are your core configuration items (CIs).

"What's next?" I warned about the temptation to skip the next step. Don't. Identify the processes that you use to establish and maintain the base line authorized configurations for those CIs. If they are vague and not well defined, you should take time to tighten them up. Identify the tools and processes you use to discover the as-is configuration of those CIs. Find out who is responsible for operation and maintenance of each of these CIs. Using your knowledge of baselines, as-is configuration, and distribution of responsibility, load your CMDB. Add CI relationships, either through auto-discovery or manually. Add relationships that can be used to trace impacts and root causes from CI to CI. Those are simple instructions for a big and complicated job.

"When will we get value from our CMDB?" In my experience, three areas, all related to the service desk, are usually the first places benefit is seen. First is change impact. Avoiding adverse impacts of planned changes becomes much easier with a CMDB in place. Second is incident impact analysis. A CMDB helps evaluate which incidents affect critical services, which do not, making it possible to allocate resources to quickly resolve the most significant incidents first. The third is root cause analysis. A CMDB helps trouble shoot service impairments down to their causes which speeds remediation.

And finally, "What should we look out for?" I answered that the worst thing to do is to load a CMDB heedless of process. CMDBs were originally conceived of to support ITIL configuration management practice. That is still probably the prevalent way to use a CMDB, although you can certainly derive value from a CMDB using your own practices, and sites may discover effective ways of using their CMDB that have yet to be included in ITIL practice. The key is to understand the CIs you have, how you will use the data you track on them, and how you will maintain the data. You must understand all of this before you begin to populate the CMDB. Sites that neglect these processes seldom do well. The worst messes appear when sites load CI data into their CMDB just because they can--creating a tangle as complicated as the situation they were trying to remediate.

We parted friends--all wiser for the discussion. They received some valuable and practical CMDB advice that, if taken, should pave the way for an expedient CMDB implementation free of heartache. As for me, I learned that IT (that's Information Technology) is a small world--after all.  

In December, I blogged happily that "DMTF Accepts New CMDBf Specification." Since then, the CMDB Federation Work Group of the Distributed Management Task Force (DMTF) has met four times and the CMDBf consortium, which wrote the spec before turning it over to the DMTF, is winding down. We are still working out the preliminaries for the work group--electing co-chairs, getting our charter into final form--administrivia that will go on for a few more meetings.

There are a lot of new faces around the table and some of the same folks who made up the original consortium team. More than twenty companies have signed up to participate in the working group--proof that CMDB federation has the industry's attention.

I had an opportunity to talk with CA customers about CMDB federation a couple weeks ago. There is some real excitement around the fact that CA is implementing the CMDBf web services in our 11.2 release of CA CMDB. And some skepticism about the possibility of vendor-neutral CMDB federation. I heard more than one person say that they will believe it when they see it. I don't think they will have to wait long.

I've been asked several times, "Why risk implementing the consortium specification? Why not wait until the DMTF adds its stamp of approval?" The answer involves several considerations. CA, like all the other consortium members, has already put a lot of work into the specification. We have built test mock-ups and prototypes just as if the CMDBf services were our own services that we were developing internally. Having put that work into the specification, we have a similar level of confidence in Version 1 as we would have in an internally developed Version 1. Given that level of confidence, why not put the spec into a product and offer it to beta sites? The specification is free and public for anyone to implement, so why not us?

The value of the specification rises with every implementation. The more vendors we can entice to join us in implementing the spec, the more value the specification accrues. We hope that every member of the consortium is thinking the same way, and we encourage non-members to look at the spec carefully and try an implementation. The open source implementation by the Eclipse COSMOS group should be a big help.

We are taking a risk by implementing early, but not as great a risk as you might guess. Flaws, if there are any, are more likely to be uncovered in the field, than around the work group table. Putting the spec to use is the quickest way to ferret out any subtleties we may have missed. That is the point of the beta test process and why every development manager loves his beta sites.

Yes, there is always a possibility that the DMTF will find a flaw in the specification and change it substantially. Then we would have to redesign and rebuild and find a way to migrate sites that have already implemented the product with the new spec. That is a risk we take with internally developed services as well as standard services.

With little to lose and much to gain, implementing now makes sense. I hope the IT community-at-large agrees.   

Followers of my blog know that I am sucker for a good standard. I am a shameless idealist. My personal mission is to make IT organizations hum (picture the current VISA commercials) and to ensure that when the inevitable hiccups do occur, the cause is not incompatible solutions from different vendors. While you've seen me blog often about the CMDBf, I've also been working on CML (Common Model Library), another standards initiative that will go a long way towards smoothing the integration bumps that IT organizations may experience.       

The CML (Common Model Library) working group, consisting of BEA Systems, Inc.; BMC Software; CA, Inc.; Cisco Systems, Inc.; Dell Inc.; EMC Corporation; HP; IBM Corporation; Intel Corporation; Microsoft Corporation; and Sun Microsystems, has announced the publication of a white paper that describes its plans for specifying a common library of models for use in IT management.

CML is another piece in the vendor neutral IT management puzzle. (You can read the white paper on the CML web site CML Project - Home.) CML is based on SML (Service Modeling Language), developed by a consortium similar to the CML group. The SML consortium has handed off the spec to the W3C (World Wide Web Consortium), which focuses on interoperable technologies to lead the web to its full potential. The W3C is in the midst of their process that will lead to endorsement of SML as a W3C standard. Microsoft began development of the language, then lead formation of the consortium for further inter-vendor development. Microsoft originated SML as a language for describing data center configuration. SML is based on XML Schema and Schematron and is able express constraints on configurations as well and the configuration itself.

SML documents have two parts. One part is a sort of abstract template. For instance, a very simple server might be modeled as an entity with several attributes, like name, physical memory, and disk size. This first part of an SML document is the model. The second part is instances of the model. An instance of our simple server model could be "name: Shasta; phys mem: 8 GB; disk: 100GB." Another instance could be "name: Rainier; phys mem: 16 GB; disk: 300GB." ... and so on. In SML, both the model and the instance are expressed in XML.

SML provides the language to express these models and instances, but not the models themselves.

CML proposes to provide a core set of models and building blocks. The CML group could provide a basic server model, for example. The existence of a universally acknowledged basic service model has important implications. First, each time a server has to be modeled, the modeler could go to the CML server model instead of inventing a new model on the spot. Second, models from the CML will provide some level of interoperability. If a vendor uses a private model of a server, another vendor may not have access to documentation of the first vendor's model. At the very least, the second vendor has to seek access to the proprietary documentation. At worst, the second vendor may be denied access to the first vendor's model because the first vendor has designated it to be private intellectual property. This can be a real obstacle to interoperability.

Interoperability of IT management systems is the real driver for SML and CML, so that the model of an IT component modeled by one vendor is comprehensible to a system built by a different vendor. CML, like the CMDBf, is an acknowledgement by the major IT management software vendors that interoperability is a serious goal for the industry.

To quote Yogi Berra, "it's déjà vu all over again." I could not shake that feeling after reading an article entitled "Providing a CMDBf Query and Registration Service" that appeared in the Eclipse Wiki on the COSMOS project page. Eclipse is an open source community and COSMOS (Community-driven Systems Management in Open Source) is an Eclipse incubator group for building open source systems management tools. (A number of CA developers contribute code to COSMOS.) The Wiki article includes an open source implementation of the CMDBf Query and Registration services. I believe this implementation will go a long way toward promoting the adoption of the new CMDBf specification for federating CMDBs.

Quicker than you can say "disco ball," I was transported back to the eighties, working with one of the most successful standards I have ever worked with: SNMP (Simple Network Management Protocol). The IETF (Internet Engineering Task Force) published the RFCs (Request For Comment) for SNMPv1 in 1988. Around that time, I was consulting at a large aero-space corporation, writing network management software. Of course, RFC 1065, RFC 1066, and RFC 1067  became hot topics soon after they came out and the "yellow book"--Marshall Rose's The Simple Book: Introduction to Network Management--showed up in every cubical. The best part of SNMP was the sample implementation documented for reference that was available over something new: the Internet. I don't remember who wrote it, but I do remember FTPing the sample code down to my work station, poring over it, compiling it, and finally writing it into the tools I was working on.

Without that reference implementation, SNMP probably would not have made it into our tools. We were under no compulsion to follow any particular standard. We were more worried about SNA than TCP/IP at that time anyway. But SNMP was not only simple, it was easy to implement by following the lead of the sample implementation. If it had not been so easy, we probably could not have justified including it in our tools.

I see a lot of similarity between SNMP twenty years ago and the CMDBf spec today. The CMDBf is a great idea, but no one is holding a gun to anyone's head about implementing it. The success of the spec depends on the bang for the buck. The vendors in the consortium have already put money and IP on the table by writing the spec. It's in their interest to implement it. But the rest of the community has to make up their minds based on the return on their investment.

The return is there. I don't think anyone questions that configuration item (CI) management data must be federated, and that vendor-neutral federation makes tremendous sense. The problem is on the investment side. Until there is a critical mass of implementations working together, there won't be much return on any single implementation of the CMDBf services.

Just like the SNMP reference implementation, an open sample CMDBf implementation reduces the investment required to implement CMDBf services, smoothing the way for acceptance.   

I thought you might enjoy a glimpse of our farm in the snow. Forty years ago, my father raised calves in this small barn that my grandfather built around 1900. It was the first barn built on the farm. He later erected a much larger hay barn, but I don't have a picture I like as well as this one my wife took last winter. Happy Holidays, Marv

I've been watching a battle between two opposing schools of thought in the CMDB world. One says that a CMDB represents the authorized configuration of the IT Service environment. Not the real configuration, not the way the system is working now, but the authorized configuration as determined by the change board and the planning groups. The other school wants a CMDB to be as accurate a reflection as possible of the way the system is configured--right now. Not what it is supposed to be, what it is. Which is correct?

Both schools have good arguments. ITIL v2 emphasized the authorized configuration school. Clearly recording the authorized configuration is the basis for rational configuration management. You can't manage what you can't measure. (The IT Skeptic had an interesting discussion on measurement and key performance indicators (KPIs) a week or so ago: "Great myths of ITIL #1: "You can't manage what you can't measure".) Further, you can't manage what you have no record of.

On the other hand, if I am an analyst on the service desk, the first thing I want to know is how the system is configured now--not the way it is supposed to be configured. The authorized configuration might give me a clue as to why an incident occurred and restoring the authorized configuration might be a perfect resolution, but if I don't know what is actually going on, I am shooting in the dark. And that's dangerous!

Stop arguing already!! ITIL v3 very clearly distinguishes baselines from snapshots. A snapshot is the observed configuration of the IT service environment at a given instant. I like to call snapshots the "as-is" configuration. That is exactly what the poor service desk analyst needs. A baseline is the result of planning and authorized changes. Just what the configuration manager needs to manage. Both can be accommodated in a single CMDB, as long as baselines and snapshots are clearly distinguished.

Too often, I have seen CMDB practices that muddle together baselines and snapshots, trying to meet the needs of both the configuration manager and the service desk. When this happens, the service desk analysts are never quite sure if what they see in the CMDB reflects reality, and the configuration managers are never quite sure what they are managing.

Occasionally, a snapshot can be used to set a baseline. If a system is working as well today as it ever has, the IT organization may make a conscious decision to authorize the snapshot as a new baseline. But this is the exception, not the rule. Most snapshots are not baselines and baselines are not necessarily derived from snapshots.

When deciding what to house in your CMDB, you do not need to choose between snapshots and baselines. The answer is not either-or. Acknowledge that baselines and snapshots are different and serve distinct purposes. A snapshot is for troubleshooting and historical analysis, while baselines come from authorization, not observation.

Both snapshots and baselines have their roles to play and neither can do the whole job. Both sides are right.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

If you've been following the progress of the CMDBf spec through my blog postings, you understand how proud and happy I am at the news that the DMTF (Distributed Management Task Force), the "the industry organization leading the development, adoption and promotion of interoperable management standards and initiatives" announced that it "accepted a draft specification that will facilitate the sharing of information between Configuration Management Databases (CMDBs) and other management data repositories (MDRs). The new spec, which was submitted by the CMDB Federation (CMDBf) working group, aims to enable organizations to federate and access information from complex, multi-vendor IT infrastructures."

As I described in my blog posting "The remarkable tale of the birth of a standard," acceptance by a standards body is the next logical step that a specification takes on its way to providing value as an accepted public standard. You can read the full DMTF press release here.

In an article in CIO entitled "Why IT Needs a Blueprint: The Case for a Unified Service Model," my colleague, Helge Scheil, wrote the following:

"A Unified Service Model provides insight into the service definition--that is, the assets, people and processes that support each service--and key information about each service such as costs, service levels, problems, incidents, events and projects related to the service. A Unified Service Model is typically implemented via a CMDB with significant integration to other management tools that provide deeper insight into service attributes." 

A business example in the article does a good job of demonstrating the real value to be gained from a well-implemented and well-utilized CMDB. As the basis of a Unified Service Model, which in turn is the basis for the IT blueprint that Helge advocates, the importance of the CMDB can not be overstated.      

Like peanut butter and chocolate, service catalog and service desk are quite good alone, but even better together. Always closely related, the products have gone through a curious evolution since I first worked on developing service products--years before those products were entrusted to CA's care.

My first exposure to the two applications came when I was working for Boeing as a development lead engineer in a little internal phone department that provided POTS (Plain Old Telephone Service) to a large multi-site enterprise. My team was tasked with building two applications: a trouble ticketing system (service desk) and a service request system (service catalog). We started on trouble ticketing and the whole team was spun off into a start-up before we got around to finishing the service request system.

And that was kind of the way it went for a long time. It was always clear that the two applications were similar--they were both driven by end users asking for something--and sites were always trying to shoehorn both incidents and service requests into the same service desk application. The service desk team kept trying to supply features that would make service desk work better for handling service requests, but the service request side was always secondary to the main event--incident handling.

But it all came out right in the end. Service catalog has matured greatly and is now a vigorous contender in the marketplace. The recent launch of ITIL® version 3, with its increased emphasis on Service Catalog, can only add to the application's staying power.

Service Catalog and Service Desk now work together to provide the kind of complete and efficient service that the little POTS department could only dream of years ago.

If you are interested in exploring the intermingling of Service Catalog and Service Desk, you may be interested in my recent technical brief and webcast.  Let me know what you think. 

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

I've been involved with the development of two standards recently: the CMDBf standard and Service Modeling Language (SML). Each has followed a similar path, starting as a brainchild of an industry consortium and then moving on to a public standards body. While establishing a standard is an exciting goal in that it moves the IT industry forward, the process to achieve that goal can be tedious. Given the varied interests of the parties involved, the fact that the process works at all is quite remarkable.    

An industry consortium is usually made up of vendors, who work together to put forth a proposal. The group is chartered for a specific purpose and has a limited lifespan. Membership is usually by invitation only. There are six vendors in the CMDBf: CA, IBM, BMC Software, HP, Fujitsu and Microsoft. The charter is a private agreement that is written by lawyers and signed by each of the participants. The agreement is tricky because the intellectual property issues are complex.

Few people understand how risky a consortium like the CMDBf can be. For instance, a participant could put something into a consortium deliverable for which his or her company holds a patent. Five years later, after the standard has been accepted and widely used, the patent owner notices that it could demand royalties. By that time, the patent ownership might even have changed hands so that the owner demanding royalties might not have participated in the consortium.

Lawyers justifiably worry about that sort of thing. As a counter measure, a clause ceding ownership of patented contributions is often included in the charter. This immediately goes under the legal microscope because no one wants to cede ownership of anything he or she doesn't have to. Eventually, it boils down to some courage and trust from all the participants.

After a consortium has taken a draft to a certain point, they can hand the draft over to a public standards body. For example, the SML consortium handed a draft to the W3C (the World Wide Web Consortium). Public standards bodies usually do not have any special governmental standing, but they do have public rules and procedures for endorsing standards that are agreed to by all their members. The more prestigious and numerous the members, and the more rigorous the procedure for endorsing a standard, the higher the standing of the standards body. 

A body like the W3C has strict operating rules on the openness of the vetting process that each of its standards undergoes before acceptance as a standard. For example, the deliberations of the SML standard working group are publicly posted on the W3C web site, SML Working Group, and from there, anyone can post a bug that the working group is obliged to examine. Only after an extensive period of scrutiny will a standard be accepted. That means that almost anyone with an opinion on SML will be heard and given attention. This makes for robust and error-free standards.

The problem with rigorous public vetting is that it is painstakingly slow. Every voice must be heard, and there are many to hear. This is why industry consortiums are so important. The goal is to bring together the most interested parties together, lock them in a series of rooms, and produce something in a limited period of time that will be a good starting point for the public process.

SML has moved on to the public stage, the CMDBf is close to it. All this may be dry stuff compared to building products, but without it, products-and IT as a whole-are held back from becoming all they can be.  

I have been following the reaction to ITIL® v3 with great interest. My own views diverge from most of the public comments I have heard, which is not surprising since I tend to look at IT from a developer's perspective, which differs from that of many ITIL pundits.

The talk is that v3 is on the upward slope of a hype cycle; it is poorly understood but still expected to solve all problems; it is too complicated, so nearly impossible to implement. However, since almost every new IT concept is subjected to these criticisms at some point, I think we need to explore further.

In Crossing the Chasm, Geoffrey Moore points out that there is a great chasm between starry eyed early adopters and the IT pragmatists who actually put technology to work. I place myself in the pragmatist camp. Nevertheless, a developer strives to build products that ride the crest of the hype, but still deliver lasting value to the pragmatic adopters who follow. To accomplish this, you have to study the hype carefully.

Frankly, I have a few scars to show for wrong choices I've made while sifting through the hype to find the golden nuggets--the products that ride the hype crest and go on to deliver lasting value. I once developed a project management application that failed miserably because it relied on a mouse years before mice were standard equipment on PCs. As a result, I am more circumspect about hype and adoption than I was in those days.

Most of what I've read about the reaction to v3 has been concern over its complexity. I do not share that concern. As a matter of fact, one of my personal IT hype warnings is lack of complexity. Whenever I hear someone propose a "simple" solution to IT management, a warning signal fires. While "oversimplification" equals hype, "simplifying" is an admirable goal.  

IT is complex. The challenge is to face that complexity and make it simple to manage. That is what CA means when we say "unify and simplify." To accomplish this, we are leveraging our Unified Service Model. Identifying and managing every aspect of an IT service is the work of many applications interacting in complex ways. Many physical and logical entities, from servers to regulatory documents to technicians all help govern and deliver IT services. To simplify IT enterprise management, we use our IT management technology to tie all those complicated pieces together and present the service clearly and comprehensibly.

Paradoxically, simplifying a complex entity like the IT infrastructure is complicated!

ITIL v3's strength is that it takes a deep look at the complexity of IT and proposes practices that include the entire lifecycle of a service. This lifecycle focus pulls in more moving parts and forces service management practices to become more complex, although the ultimate goal is to simplify managing IT toward favorable business outcomes.

To link the development of an idea for a credit card validation service in a project portfolio with servers in a data center, subscriptions in a service catalog, and incidents at the service desk is a formidable task involving at least a half dozen separate applications. But when all the pieces fit together, the result is creating high value services for the business. The executive who funds a credit card validation project, a technician changing a power supply on a server on which a key validation application runs, and a service catalog recording another subscription to the service are all talking and working from the same service definition.

That is what I call simplicity in complexity and the paradox of ITIL v3.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

Like many of you, I’ve been doing a lot of reading and pondering about ITIL® v3 lately. What is different about v3? Is it an improvement over v2? Is it likely to change the way IT is conducted?

I’ve been particularly intrigued with a statement in the introduction to the ITIL v3 Service Strategy book that says “transaction costs” determine the boundaries of an organization. I wonder how many of my development colleagues are excited by that? Do transaction costs have anything to do with IT? And what are they, anyway?

Transaction costs are actually of vital interest to IT, but not on the level that most of us work. Transaction costs are the costs of performing an economic transaction. For example, the transaction costs of purchasing a house include the fee paid to the real estate agent, the cost of the time spent away from work looking for the right house, the cost of the gas burned driving around looking, and so on. The money paid to the seller is part of the transaction, not a transaction cost.

In fact, most of IT can be analyzed as transaction costs. When a book is sold, the wholesale price of the book is part of the transaction, but the IT cost of selling the book on the Amazon web site is a transaction cost. Keeping the IT share of transaction costs down is vital to IT since IT itself is rarely the commodity traded in business transactions.

In the hierarchy of costs, calling IT a “transaction cost” is a big step up from “overhead,” which is often where much of the IT budget is parked. In executives’ minds, the only good overhead is reduced overhead. Transaction costs, on the other hand, are investments with a return. ITIL v3 equates IT transaction costs with retail cost-of-goods-sold, which is a very respectable place on a balance sheet. However, CEOs and CFOs will not accept IT as a cost-of-goods-sold without evidence to back up the assertion.

Essentially, v3 says that IT should be governed by analyzing IT as a transaction cost. This takes IT best practices beyond v2, which introduced many IT practitioners to the notion that IT provides services to their customers. Now, we are challenged to not only provide services, but to treat the cost of supplying the services as an investment like any other investment in the enterprise.

What does this mean to IT practitioners? Does it change the way we design, deliver, and maintain systems? I believe it does. It means we have to treat IT services more holistically, and there may be a few more pieces in the whole. We will have to begin to pay attention to service models that encompass the entire enterprise. We will begin to use more tools that track investment and return on services throughout their lifecycle. There will be fewer discontinuities between design and execution. There will be more dollar metrics in our reports.

ITIL v2 brought the consumer of IT services to the center stage and made us all begin to favor their needs over the urge to pursue technological perfection. ITIL v3 extends our focus beyond the needs of the IT service consumer to the needs of the enterprise as a whole. For many years, IT got by on sheer technical virtuosity. First the mainframe, then the personal computer and distributed system, were so new, so powerful, that bursts in corporate productivity seemed to come as a matter of course and the IT overhead was easily accepted. As IT matures and figures more strategically into enterprise success, it will progress from being tolerated as overhead to being appreciated as a vital cost of doing business.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

For those of us involved with the CMDBf from the start, the recent media attention on the publication of the Version 0.95 specification has been exciting. It’s as though we’ve finally given birth and we now get to proudly share pictures of the baby.

A joint press release entitled “Technology Leaders Release Specification for Federating and Accessing Multi-Vendor IT Management Data” was issued by the CMDBf member corporations: CA, BMC, Fujitsu, IBM, Microsoft. This resulted in numerous articles in IT pubs. Here are a few you may find of interest:

• Federated CMDB spec proposed
• Management vendors team on configuration spec
• Database Standard Could Align Configuration Management Information
• CMDB Federation releases first specification
• Federation and Management Spec Unveiled

Then there’s the article that reminds us that there’s still much to do:

• Baby Steps Toward CMDB Federation

The 0.95 specification is only the first step. The consortium is continuing to work on it, filling in the gaps and considering comments from readers. I’ll continue to serve on the technical committee and will keep you informed.