Iterating on IT Service

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.