Published: June 30 2009, 05:10 PM | 4 Comment(s)
by Eric Feldman

Many companies adopting a Service Catalog are faced with a dilemma. How do they define their services? Actually, there are two components to service definition. One is the processes employed to deliver or enable the service. These can be documented in a process modeling application, or made actionable using a tool, such as CA Workflow or CA IT Process Automation Manager. This is the "behind the scenes" part of a service definition.

While this is important from the Service Definition and Lifecycle perspective, I wanted to focus this time on the specific definition that is published in a catalog. If you think about it, most customers and department managers are concerned with what they are choosing from a catalog, not how it will be delivered to them.

Ever shop online? Many online merchants have setup elaborate systems to help you choose a product or service. There are glowing descriptions, photos, videos, customer testimonials, and rating systems. You may even see a service level listed, representing the time frame where the product will be delivered.

On the other hand, do you see an activity diagram detailing how your credit card will be authorized, how the product will be picked from the warehouse, and how shipper routing decisions will be made? You don't. While this information is important from the provider point of view, it is almost irrelevant from the customer's perspective. They certainly care about receiving their product within a specified or reasonable time. How that product arrives is typically of no concern.

To establish a Service Catalog, you must follow a similar mindset. The process behind the service definition is important, but primarily from the IT or service provider perspective. The backend, if you will. It is the technique and style you use to define the service from the customer or end user's point of view that becomes crucial, especially when acceptance or adoption of the Catalog is of concern.

But how does an IT organization actually describe their offerings? The technique is easy to describe from a high level:  Keep it informative, yet simple to describe. Think outcomes, not components. And use value added language that is meaningful to the appropriate user community. For example, a storage service could be described as “300 Gb logical volume size using SAS hard drives in a Raid 5 array. This description may be suitable for a technical user audience. For many business users, however, this information is inappropriate. A far more meaningful description may be “Reliable and secure data storage."

The Service Catalog is the publishing vehicle where IT does not just define their offerings. It also communicates their value to the business community.

Which brings us back to the original question. "My Cousin Vinny" and "Song Airlines" both can show us examples of how a Service Catalog was deployed. Each illustrates the parameters I described above, in entirely different ways.

In "My Cousin Vinny" the characters played by Joe Pesci and Marisa Tomei go to a diner and are handed a menu. It says simply "Breakfast," "Lunch," and "Dinner."

Song Airlines was a former division of Delta Airlines that featured an "upscale bistro" menu of food for purchase. It detailed elaborate descriptions of offerings more gourmet than geek. Here is an actual description taken from a Song menu: "Asian Chicken Salad. No, you don't have to eat it with chopsticks: Ginger-marinated chicken *** with romaine, napa cabbage, shredded carrots, water chestnuts and mandarin oranges. Served with chow mein noodles for crunch and a sesame-ginger vinaigrette for kick."

So, which method are you using to represent your organization's value? Do you use the "My Cousin Vinny" or the "Song Airlines" technique?

Or to ask this question in a different way, are you using relevant value oriented language in your Service Catalog, or do you get by with just a simple two word description such as "request access?"

Share this post:  Email

Share

Published: June 27 2009, 08:23 PM | 8 Comment(s)
by Peter Doherty

At CA Expo here in Oz I asked the 200 people in my session who thought they were an ITIL V3 shop and probably 20 or so hands went up sheepishly. Maybe the reason for this is that they have seen what happens to people who put their hands up in response to my questions or maybe they were unsure.

Word out of the latest Gartner conference is that lots of IT organisations are adopting V3.  Now for the record, I think they should. But just because I think they should does not mean that they are. So here in Oz, which is a very mature Service Management market, I get mixed feedback about the adoption of V3. When I asked the same question in the Sydney Expo I told some of the people to put their hands down (see what I meant about putting your hand up in my sessions!). So why did I ask them to put their hands down? For the same reason that I do not think there is the ITIL V3 uptake that the analysts are quoting.

And that reason is that if you are just doing Incident, Problem, Change, don’t kid yourself that you are a V3 shop. It is really good that you are doing those things, don’t get me wrong. It is just that IT is so bad at managing expectations and here is another example:

You need to be doing more than the old Service Support processes.

So are the analysts wrong? And if so where are they getting the data? Or are they asking the wrong questions? I think it is a combination of things. I twitter on Service Management (@ITILNinja) and David Ratcliff of Pink Elephant (@pinkerdavid) asked the question about why are we twittering on advanced topics when most people are still crawling? And he is so right.

There are so many shops out there still implementing the SS processes and here I am talking about Service Portfolio Management. If you are struggling with Incident and Change, SPM is fantasyland. But I want people to start thinking about how good fantasyland could be!

And this is how I think you can define yourself as an ITIL V3 shop – you have started to think and plan to eventually get to Peter’s fantasyland and it is a good place!
 
You are an ITIL V3 shop if you have started to embrace some of the new processes and are talking about a Service Lifecycle. Sorry, not just talking about it but it is starting to become part of the culture. When you start appointing Service owners and Business Relationship Managers that actually talk to the business, not just other parts of IT.

So if an analyst asks you whether you are a V3 shop or not, forget about the pressure for you to say yes and ask yourself how you stack up against some of my basic criteria and also ask yourself whether your CIO talks about this as well.

As I always like to do – if you think you are a V3 shop, leave a comment and tell me why.

Share this post:  Email

Share

Published: June 26 2009, 01:18 PM | 3 Comment(s)
by Jeff Foucher

I'm pretty amazed at the seemingly endless discussion and un-evolved thinking around "aligning IT with the business." Various machinations have surfaced ("it's about IT being part of the business" or "it's about aligning IT and business") and at least a dozen vendor-driven acronyms have emerged all purporting to put IT & business on the same page. However, I've yet to see a more detailed, behavioral analysis applied to better understanding the underlying human factors which still make this a relevant discourse and one that still appears to keep executives up at night.

As an IT outsider, it seems that this is no different than any other inter-departmental cultural divide hindered by a general misunderstanding of what one party perceives to be of value, exacerbated by disparate metrics and measures, and undermined by intra-departmental silos of dysfunction.

Finding Common Ground

As with any cultural divide, there are fundamental steps which can be taken to ensure that both parties find mutual benefit and success. And of course, technology can help play a part. Hence, a four part plan for IT:

1. Common Goals: As with any business, this is all about IT getting lean and orienting itself around a value/cost/risk axis. Starting with a firm (documented) understanding of business goals and priorities, IT then can establish a customer-centric beacon upon which all activities are then managed, executed and measured. If it's not on the business agenda, it should never get onto the IT agenda.

2. Common Language: In most areas of business, and certainly all areas of the public domain (government, education, healthcare), the value orientation is predicated upon the services being delivered to customers. Even manufacturing ‘output' can be considered a service since without the underlying orchestration of the supply chain, nothing would ever be built. Likewise, IT should start with the ‘language of business' and ground itself in the management of its own IT service portfolio. This requires a full understanding of IT cost, quality & function packaged in terms of the services being delivered or supported.

3. Common Currency: While business is based upon a service orientation, the way the business operates is actually quite different. Accounting principles require a more detailed view beyond just the ‘cost of the service' - for purposes of depreciation, tax, operating margins and capital expense. A service oriented view of IT "cost" is absolutely needed to establish a common language with the business around value, but the currency of business is more rigorous and requires cost accounting principles applied to asset expenses, labor expenses, application costs, license costs, maintenance on hardware, communications, infrastructure. Similarly, IT Financial Management must be able to plan, actualize and optimize its expense base against these same principles and detail -- whether they are IT assets or projects or telecom expenses or software contracts.

4. Common Knowledge: Underpinning all of this is the ability for organizations to create a shared sense of purpose, allowing them to galvanize against common goals with a unified language and currency system. In IT, this is essential to breaking down the long-standing silos of disconnect which have undermined IT for years. ITIL plays an essential role here, by focusing on processes, which quickly afford one function to realize their own role in the context of the broader organization.

Building A Common Culture

In the end, business may or may not care to engage fruitfully in an ‘alignment' discussion with IT. But they are forever connected to IT as their lifeline to innovation and competitive advantage. But by establishing a common framework for success based on shared goals, a language everyone understands, a single currency system and a shared knowledge base, IT leaders can indeed become business leaders and along the way, improve the way the business itself operates by embracing and driving toward a common culture of success.

How has Technology helped you bridge the divide?

Share this post:  Email

Share

Published: June 24 2009, 04:30 PM | 1 Comment(s)
by Robert Stroud

This week I was in Korea for the joint Korean itSMF and ISACA conference. Understanding the issues surrounding the business climate and the demands on their members' time and finances, these two organizations worked together for a single event instead of their usual independent events. The event was a huge success based on the attendance, attendee comments, press comments and the smiles on the organizers' faces. 

I spoke about Governance for your ITSM environment--more on that next week--and I wanted to share with you my prepared comments to the excellent questions raised by the facilitator of the closing panel session.

Questions: As you may know, we are facing a world economic crisis and many leading firms demand to sustain their businesses. What's your perspective on the role of ITSM and IT governance to sustain our business (in terms of efficiency) in this crisis? What can you suggest based on your global experiences, providing recent case examples? Will ITIL-based ITSM solutions or VAL IT enable us to sustain our businesses during this particular period?

• At the moment, the global focus is clearly on cost reduction. Unfortunately much of this is based on simply cutting people, deferring investments, wholesale removal of a service or introduction of service delays. Instead, focus needs to be on real immediate savings and this needs to be linked to business demands. 
• Frameworks, including ITIL or COBIT, give us the opportunity to deliver efficiencies but only where they are delivered through automation of process with a focus on the reduction in complexity - these must be linked to the demand side and the organization's strategy.
• We must balance supply and demand. 
• One of the real opportunities here is to expose the business to the operational services that are being delivered and the costs associated with their delivery, proactively providing information on how to reduce these costs. 
•  The Service Catalog is an good example of this - where the business consumes services expressed in business terms with business based service levels. IT has to opportunity to associate costs with the various service levels. 
• These services must be reviewed on a regular basis with efficiencies reviewed with the business - not just evaluated by IT.
• One example of this is a power company in the U.S. that is using COBIT for Governance and setting controls for risks and exposures. It also is linking IT strategy to the business strategy.  This organization uses ITIL for Service Management, uses PMBOK for project management and currently is implementing the Investment Management domain within VALIT. 
  
  The company has implemented a Service Catalog that defines business services. It has implemented self help for issue resolution, and the service catalog allows users to consume services acknowledging cost and all investments are linked to business strategy.
• This organization has been dictated a 10% overall cost reduction
• Immediately the investments could be prioritized for relevance to the new strategy of cost reduction. Projects were all reviewed and by slowing down several and completely removing two, a 15% saving was made.
• Operations wrote to all users of services that leveraged consumption-based third parties and advised them of the opportunity to cut costs.
• IT identified that by accelerating the VOIP initiative they could save 3% from the total IT budget in the first partial year of operation after all costs. Because of the near-term cost-savings, this project was accelerated.
• Self-service Catalog automation increased and provided another 2% saving.
• Overall the 11% of real savings were delivered.

What do you think?

Share this post:  Email

Share

Published: June 23 2009, 11:50 AM | no comments
by Marvin Waschke

There are many difficulties involved in CMDB federation that the CMDBf specification helps address.

 When you set out to integrate a CMDB product with another data source, such as another CMDB or a specialized device monitor, there are several steps that you must take and with each step there are choices to make.

Perhaps the most important architectural choice is the level on which to federate. You can choose to federate on a database to database level. That involves a detailed knowledge of the schema of both the target and the source system, and the federation is likely to break if the schema of either system changes. Because the schema is intimately tied to the internal operation of the applications, schema changes occur frequently when either the data source or target changes. Often, schemas are not designed with federation in mind and so data that is not relevant to federation may appear as columns in the same tables as federation data. This can complicate transactions and cause the federation to break when an unrelated feature in the federation source changes. In addition, exchanging schema information can become a thorny intellectual property problem, especially when the source and target are from rival vendors.

Due to the difficulties of database to database integration, APIs are often used instead. Using this strategy two products communicate by each calling the published APIs instead of reading or updating a database. These APIs are usually designed and published to support integration. Consequently, they do not require intimate knowledge of the products that support them and they tend to change less often than database schemas that often change to support new features and efficiencies. And finally, APIs are better documented than schemas.

API to API integrations are a distinct improvement, but they still have problems. For example, they still are subject to breaking if either party changes their API with a product change. Sometimes, good engineering rules are followed and the APIs are backward compatible so that existing integrations do not break, but this is not guaranteed. In addition, as new features are incorporated into products, new APIs are often added and integrations must change in order to take advantage of new capabilities. There is often little incentive to vendors to roll new features into existing APIs, which is often much more difficult than inventing a new API. This means that new releases always threaten the federation and adds an element of unreliability. Not only is there danger of  downtime and recoding costs, remediation for the unreliability also incurs more cost in the form of extended testing and more elaborate transition plans with new releases.

Most seriously, the APIs for every MDR and federating CMDB are all different. That means each integration project has to be designed and engineered individually. Not only is development of this form of federation expensive, each integration must be supported individually by engineers specially trained on the specific federation, which eliminates economies of scale in support.

In a word, API to API federation is expensive to the supplier of the federation and inconvenient to the user of the federation.

The CMDBf is a public specification for API to API integration and addresses two of the substantial problems involved with that type of federation. First, it puts everyone on the same API. Second, by placing changes to the specification in the hands of an organization like the DMTF, the change process is stabilized and the specification undergoes industry-wide scrutiny before it changes. Like code reviews in software development, this scrutiny can eliminate a large share of the problems with federation breakage.

When the specification becomes widely accepted, basically the same integration can be repeated and supported over and over again. The process of building a federation between an MDR and a CMDB requires a thorough understanding of the APIs of both the MDR and the CMDB.  Typically, the developer is only familiar with one of the two and has to fight a learning curve to master the unknown API. Then the federation must be designed, implemented and tested at considerable expense. If standard APIs are used, which apply to both MDRs and federating CMDBs, the expense and risk is not eliminated, but they are both reduced. The learning curve is diminished because the developer is experienced in the standard API, and much of the code will be identical to that used in previous CMDBf-based projects. Although specialized data may be unfamiliar and require some special processing, that is a small part of the entire undertaking. The bulk of the work and risk is eliminated by using the standard interface.

It is hard to over-estimate the importance of these basic improvements that come from standardization. There are other improvements that can be made to CMDB integration, but they all depend upon a well-defined and standardized API.

This is not the whole CMDBf story, but it is an important part. I'll be blogging more on this.

Share this post:  Email

Share