« October 2005 | Main | February 2006 »

December 25, 2005

Best Practices for Service Catalog Design

Boris By Boris Pevzner

Most IT executive I talk to nowadays have a clear goal to “run IT like a business” (or some variant thereof), and they realize that “IT productization” around a common Service Catalog is an essential first step toward achieving this goal.  So the question I’ve been getting the most lately is not “Why do I need the Service Catalog?” but “Where do I start?”… closely followed by more detailed implementation questions: "How many layers should a hierarchical service catalog have?  Who owns each layer?  What is the relationship between the Service Catalog and the CMDB?"

Until recently, my response has been very much classic-consultative: “Here is a general hierarchical service model (like the one below), here are some examples for how we have applied this model to help IT shops like yours to put together their service catalogs; let’s spend some time together and figure out which one fits you best and use it as a starting point.”


However, in the last few months, as our Service Catalog practice continues to mature (and as the number of the Global 1000 service catalogs we’ve seen and/or helped develop has grown to a few dozen), I realized that we now have enough data to start shifting from the “consultative” service catalog design informed by industry best practices to the “normative” service catalog design based on the industry best practices.

At the high level, this “normative” service catalog design pattern that we are starting to use maps to the following three layers in the service hierarchy:

  1. IT Service Offerings (such as role-based employee bundles, application hosting services, etc.) – these are orderable IT services that an end user in a specific role (employee, partner, developer, etc.) will actually order – either through an IT liaison or directly through a self-service portal.
  2. IT Technology Products (such as specific business applications, email and messaging services, managed database service, “utility computing farm” service, etc.) – these are component services that are not directly orderable, but (a) provide building blocks for the orderable Service Offerings, and (b) directly map to the IT organization’s delivery/support capabilities (the “IT Factory”).
  3. IT Assets (such as servers, networks, facilities, personnel participating in service fulfillment, etc.) – these are grouped into technology-centric silos, which are essentially the individual “work benches” on the IT Factory “floor.”

The hierarchical relationships among these three layers fits well with Charlie Betz’s evolving “ERP for IT” data model, which represents this relationship thus:


Each of these three layers has its own set of organizational owners, key attributes, and use cases; and it is defined and maintained in a specific system of record within the overall IT ecosystem.  Here is a (very abbreviated) table summarizing this information:


Over the last few months, we’ve had good success getting clients to buy into this high-level model.  This has made our engagements more repeatable, as all of our service catalog projects are starting to converge to a common structure, which we believe truly represents current best practices among the Global 1000 IT organizations.

Watch this space as our Service Catalog model further matures and evolves… in the meantime, comments and ideas are most welcome!

Posted on December 25, 2005 | Permalink | Comments (0) | TrackBack

December 4, 2005

IT Governance Demystified

Boris By Boris Pevzner

In my experience, "IT Governance" is the most popular IT buzzword among corporate IT executives and company boards nowadays. But like many buzzwords, this one is far easier to recite than it is to understand, let alone apply.  And it certainly doesn’t help that (as it is often the case with buzzwords), there exists a curious dichotomy between what this term actually means and how it is being used by IT vendors trying to latch on to it to increase the appeal of their wares.

Given that the “signal-to-noise” ratio on this topic is so low, I thought I’d take a few minutes to explain what IT Governance is, how the term is used and abused by IT organizations and vendors today, and what are the key issues in implementing a useful IT Governance framework.

What is IT Governance?

A straightforward definition of IT Governance comes from the Board Briefing on IT Governance publication (pdf) produced by the IT Governance Institute:

IT governance is the responsibility of the board of directors and executive management. It is an integral part of enterprise governance and consists of the leadership and organizational structures and processes that ensure that the organization’s IT sustains and extends the organization’s strategies and objectives.

At the next level, this breaks down into the following five IT Governance areas:

  1. Business-IT Strategic alignment, with focus on aligning with the business and collaborative solutions.
  2. Value delivery, concentrating on optimizing expenses and proving the value of IT.
  3. Risk management, addressing the safeguarding of IT assets, disaster recovery and continuity of operations, and risks associated with regulatory compliance.
  4. Resource management, optimizing knowledge and IT infrastructure.
  5. Performance measurement, tracking project delivery and monitoring IT services, which provides feedback to the governing body and enables decision making, objective setting, and policy adjustment.

What complicates the picture is that there is no single IT Governance “standard.”  Rather, the topic of IT Governance falls at the intersection of three popular frameworks, which are contemporary buzzwords extraordinaire in their own right: ITIL (from the IT delivery and support point of view), CobiT (from the financial auditing and control point of view), and SOX (from the US regulatory compliance point of view).

For a high-level - yet rather thorough - treatment of the IT Governance topic, you may want to check out the book by Peter Weill and Jeanne Ross, from the Harvard Business School Press.

IT Governance – State of the art

HBS and other theory aside, the predominant reality today, as I have observed it over the last few years, is that IT Governance is not an actively designed CxO-driven initiative but a collection of loosely connected “governance silos.”  The most common kinds of such uncoordinated silos that I most often encounter are “project governance,” “outsourcing governance,” “architecture governance,” “data security and access governance,” and “governance around change.”  In most cases, these governance silos get created as a reactive mechanism to address a particular need (for example, architecture problems or overspending or duplication).

Patching up problems as they arise is a defensive tactic that limits opportunities for strategic impact from IT. Instead, management should actively design IT governance around the enterprise's objectives and performance goals, across the five dimensions of IT Governance outlined above.

IT Governance – What the vendors are saying

Given the complexity of the IT Governance juggernaut, and the fact that much of its success is dependent on the company’s organizational discipline and maturity, it’s obvious that no single vendor can “enable IT governance.”  Yet you’d never guess this from reading their glossies.  Project management solution vendors like Kintana (now Mercury IT Governance Center), Changepoint (now part of Compuware), Niku (recently acquired by CA), PlanView, and PacificEdge have all been repositioning their products as more trendy “IT Governance” solutions.  Many IT asset management vendors have done the same.  And most recently, the venerable Systems Management suite vendors like HP OpenView have also jumped on the IT Governance bandwagon.

There is no doubt that all these vendors provide useful solution pieces that contribute to solving the overall IT Governance jigsaw puzzle.  But it’s hard to make sense of the pieces unless you can see the front of the puzzle box – what the completed jigsaw will look like once the pieces are in place. So what does a successful IT Governance framework look like?

Key issues in implementing a successful IT Governance framework

Every successful IT Governance framework that I’ve seen includes an organizational component and a technology component.  The organizational aspects are neatly summarized by Weill and Ross as “Ten Principles of IT Governance”: involve senior managers, ensure clear exception-handling, provide the right incentives, assign ownership and accountability, provide transparency and education, etc.

At the technology level, the key question is: What are the concepts that need to be defined to enable effective IT Governance, and how to implement the processes and tools that make these concepts actionable?

The answer is guided by the old maxim – Define. Manage. Measure. Improve. – because…

  • What is not defined cannot be managed.
  • What is not managed cannot be measured.
  • What is not measured cannot be improved.

Over the last two years, most IT organizations have gone through the painstaking exercise to define the services they are delivering (through the IT Service Catalog) and the projects they are working on (through IT Project Portfolios), implementing systems to manage the delivery of these services (through Service Delivery Management) and projects (through Project Management), developing metrics and key performance indicators (KPIs) to measure the quality and cost of delivering these services and projects, and using this information to improve their delivery processes.

Those who implemented this framework successfully (along with the organizational and policy best practices), have seen dramatic improvements along all the key dimensions of IT Governance: business-IT strategic alignment (by focusing on the services and projects with the highest business impact), value delivery (by realizing operational efficiencies through process and infrastructure automation), risk management (by formalizing business continuity provisions as well-defined IT services and by addressing regulatory compliance requirements through increased process definition and transparency), and resource management (by tying their service delivery systems directly into human, infrastructure, and knowledge resource repositories).

Following these key principles, supported by the appropriate tools, companies can ensure that “IT Governance” becomes more than just a buzzword, but an actionable methodology to most effectively harness the awesome power of information technology in the interests of the business enterprise.

Posted on December 4, 2005 | Permalink | Comments (5) | TrackBack