IT organizations considering moving to BSM expect to establish a view of the IT infrastructure that spans technology silos such as server, network and application and portray appropriate combinations of those technology components as end-to-end services. And the business that the IT organization is supporting expects to have a view of how those IT services are contributing to the business. A central idea of BSM is it enables a translation from the bits and bytes of the IT infrastructure components into the business metrics of cost, value, availability and risk.

The example of an e-commerce website for a retail business illustrates the BSM approach to IT management. The business cares only indirectly about server utilization rates and network capacity. What the retail business managers really want to know are things like: How much do I have to fund IT to provide the e-commerce service? How much revenue is it generating? Is it available for my customers to place orders? Are my customers having a satisfying experience with the site? Etc.

So, to support BSM, IT needs to both manage complex technology and offer it to the business in tidy packages called “services”. To most CIOs and IT leaders that sounds like more than a meal. And with good reason. Many BSM practitioners—software vendors, systems integrators, consultants and, yes, we analysts—talk about an enormous number of BSM “requirements” that include products such as service catalogs, configuration management databases (CMDB), monitoring tools, and dashboards. They also talk about process changes, best practice adoption and cultural shifts. Just considering all these BSM “requirements” can be overwhelming.

However, what brings some sanity back to the BSM adoption story is that all of this should not be attempted at once. These BSM requirements are really most suited for just the segment of BSM adopters that was first identified, the buffet group. They see BSM as a menu of enabling technologies that, by the way, bring value above and beyond BSM. And even they realize that trying to assimilate all of the components too quickly would cry out for Alka-Seltzer. Yet understanding the full buffet menu is quite handy for planning an all encompassing, multi-year, big-budget BSM adoption.

Salad

With that bit of clarity on buffet style BSM adopters, the salad style adopters need some illumination. This group tends to look for a healthy meal at a reasonable price. In IT organization terms this translates to pragmatic shops that are spending most of their energy, time and budget meeting their current objectives. However, they often encounter a compelling event—possibly an upcoming roll out of a new application that could overwhelm IT with requests—that is not initially recognized as something that could be solved with BSM-like capabilities.

They understand the BSM concept but tend to feel it is too much to tackle, too expensive, too long term and too distracting from current commitments. Keep in mind that there is no inherent judgment implied for the BSM salad eaters versus the BSM buffet eaters. Their situations are simply different.

In the current early stages of the overall BSM technology adoption lifecycle, the salad group contains the majority of IT organizations. If your IT organization aligns here, you probably need to understand some of the individual steps that can be taken toward BSM adoption. If your IT organization is in the buffet category, you too may benefit from understanding some of the ways in which the salad group can approach BSM.

Just keep in mind that, if your organization truly is in the buffet category, you will also need to consider and balance your selections with your long-term needs. For example, CMDB may be the logical first step for a broad BSM adoption since it is a foundational enabler for so many BSM components.

Two reasonable salad-sized steps toward BSM come to mind: a basic service catalog and service monitoring. Either of these could be implemented relatively quickly and cost effectively, without significantly restructuring the existing IT organization and associated IT management processes. And both address key aspects of BSM. They introduce the service concept to IT and represent those services in meaningful ways to the business.

A service catalog lists and describes the services offered by IT. It also lists service attributes such as cost of the service, commitments related to quality and availability, and also which business users are entitled to order the service. By automating the fulfillment of requests for one or two services that may be customer facing or revenue generating or central to operational competitiveness, the IT organization moves toward a service provider model. And the service catalog provides clear communication of IT’s value to the business. By displaying cost information, the business also gains a better understanding of what they receive in return for their IT investments.

Service monitoring products can leverage traditional monitoring tools that are each focused on single technology domains such as applications or the network. By aggregating and intelligently relating the data from each domain-focused tool, end to end services can be monitored. IT retains silo specific data for detailed troubleshooting and gains a services view to begin the shift toward a service management philosophy. By connecting business metrics like revenue generation to the monitored services, the business gains continual insight to business health and the related contribution of IT services.

If your IT organization is interested in realizing some of the benefits of BSM and needs tangible results in a reduced time frame, consider a light meal of a basic service catalog or service monitoring solution.

Paul Burns is a senior analyst with Boulder, Colorado-based Enterprise Management Associates (www.emausa.com), an industry research firm focused on IT management. Paul can be reached at pburns@enterprisemanagement.com.