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?"