Market Analysis: Business Service Management

The difference is that functionality and implementation have subtly, but significantly, shifted. BSM vendors take services as a starting point, where framework vendors started with the infrastructure. IT led framework initiatives, while BSM is a collaboration with business units. Instead of dry throughput or server uptime metrics, good application response times and the ability to meet business metrics now guide IT priorities.

IT must work with business owners to map their goals to the underlying infrastructure. BSM tools must record IT's quantification of good response and required availability, then map metrics like page load times and 24/7 response onto specific infrastructure and operational practices. For example, which servers, services and network devices are key to providing Web customers with fast page views? What will it take to maintain fast response times? How will the outage of a particular server impact widget sales?

Creating a common, service-oriented lingua franca between IT and business groups is the most important challenge--and benefit--of a BSM initiative. Business owners and management don't want more granular detail. They don't want to hear what IT must do to meet the desired metrics. They want to talk about meeting customer needs and business goals.

But beware: All this teamwork sounds warm and fuzzy, and mapping server response times and availability seems straightforward. But the hard truth for IT groups accustomed to laying down the law is that, for BSM to work, serving end users and customers trumps IT management edicts.

No one said it would be simple. Service interruptions and cost overruns common with management frameworks have fostered resistance to central IT control, leading business units to adopt parochial applications, hardware and management systems. On the flip side, IT ROI must be quick and clear-cut. We must build management around existing systems while enhancing service delivery.

If your organization is large enough to consider BSM, assume that no single management framework can overlay all your service-delivery needs. Our tests of last-generation frameworks showed they're not as monolithic as marketed. Rather, they comprise a diverse set of scripts, APIs, technologies and products requiring IT person-hours to implement and maintain. Our tests of application-dependency mapping products show that this situation persists. And it's no longer organizationally or technically acceptable to forklift existing systems to reach your management goals. Rather, legacy systems must be incorporated wherever possible and with minimal disturbance.

You can and should demand that your management vendors provide integration, but process stability and best practices are IT's responsibility. This is why ITIL must be included in a total BSM implementation. At the heart of this practical reality exists a repository to keep IT system configuration straight: the CMDB (configuration management database).The CMDB is defined by ITIL as a repository where configuration, metadata, status and even performance data, and their relationships to one another, are tracked to support such processes as incident and change management (Click here for more on ITIL).

ITIL's rise helped spawn the BSM movement. It's the underpinning of IT service delivery, and its infrastructure management processes and workflows provide BSM vendors with their service management approaches. Specifically, the CMDB promises to hold onto everything that happens to your IT infrastructure, making it the new IT management ideal.

Like any good standard or new technology, however, there's some religion involved. This particular holy war is over the choice to federate or centralize. A centralized CMDB is an integrated data store, provided by a single management vendor, while a federated CMDB is a distributed set of data stores provided by multiple vendors, stitched together by a third-party application.

Think vendors prefer the centralized approach? Nope. Management vendors like to have as many intersecting relationships as possible so that they're perceived as at the center of the management universe. Therefore, they prefer a federated approach. As for our framework sellers, they have as many relationships with value-add vendors as the small guys do, plus they have some of their own glue. This is especially true of IBM, HP and BMC, which have worked hard to integrate their diverse management offerings. BMC and HP now span almost every area of management, including service desk. The only place they have to look outside is for network device configuration.

It's common for IT to have multiple management products with different data stores, so going federated avoids a big integration project. But out-of-the-box integration of all your data stores isn't likely because there are no standards for how CMDB data is stored or integrated and best practices vary by shop. ITIL specifies that a CMDB have some basic naming fields and a single ID attached to each asset, which may make it seem that CMDBs are open or interoperable, but they're not. Vendors may tout APIs that will let you integrate with their CMDB, but when you think federated, think professional services.Even if you get all your data stores to chat happily, integration depth will vary. For example, it's great to open a ticket automatically in a service-desk product from a third-party status monitoring app, but when the status changes, is the ticket closed automatically? Can the third-party configuration-management application receive a request to apply a configuration change triggered by a change-control ticket, then tack on a change-audit record and update the ticket as closed? It's possible with professional services, but not a given, so ask. Deeper integration also is becoming available from vendors that have specific device and systems knowledge, such as OpsWare and BladeLogic for device configuration, Optier for automated real-time systems QoS and Integrien for performance management.

Think through the kinds of data included in your CMDB. Configuration and change-management records should be in sync. This is the stuff of service-desk vendors. But what about status? What about system performance over time? Are configuration records accurate? In a shop large enough to justify a CMDB, some percentage of devices and systems will vary from what is in the CMDB.

Configuration data is a starting point for answering the question at the heart of BSM: What has changed? In simple cases, a changed parameter will be the root cause of a failure. More difficult to diagnose are problems that degrade performance, where a configuration parameter, like the amount of shared swap space, is underspecified for a production load. Where preproduction tests show no problem, a configuration audit would not flag one, but performance monitoring of the application could recognize unusual behavior. A configuration trail can provide a place to begin looking, but it's no guarantee that you'll know what's wrong.

BSM initiatives involve adding performance and availability status to the CMDB over time. The current central repository definition of static asset/inventory data must expand, lest the CMDB become just another IT silo. These types of records are not what management vendors propose when hawking CMDB products, but some, like Managed Objects and ProactiveNet, do. For example, Managed Objects links diverse data sources through a unique field, like MAC (Media Access Control) address. In this way, configuration, change and status data can live wherever and be viewed in context for a single system or group of systems.

BSM is not a destination. Like all growth, it's a process, and an expensive one at that, with costs not just in new software but in business and IT person-hours to define acceptable levels. As a rule of thumb, a BSM initiative isn't warranted until you're managing 100 servers. At this minimum level, justification relies on hard costs being associated with service disruptions. It won't be enough to deliver consistent subsecond response times if failing to do so doesn't cost your business money. Still, like all automation, BSM done right will result in less downtime and reduced manpower needs.Unfortunately, unlike other management disciplines such as monitoring, helpdesk and desktop support, outsourcing isn't letting midsize businesses implement costly BSM products. Dollars--hundreds of thousands--are required before BSM can take flight in your world.

BSM has been around for a few years, but adoption is only now becoming widespread among large enterprises. Forrester lists the important characteristics gained through maturation:

First-generation BSM:

The second generation of BSM goes much further, adding:

Source: Forrester Research

Framework vendors have jumped on the BSM bandwagon with service suites, but boutique vendors also are marching in the BSM parade. Their technologies span configuration, service, performance, change and event management for networks, servers, systems, services and applications.

Most management vendors cast BSM in a light that features their products at centerstage. For example, service-desk vendors see all problems resolved with better change and problem management. Configuration vendors point to stopping drifting configurations as the key to gaining the upper hand. Performance- and event-management vendors will save IT people cycles by finding fires quickly or avoiding them altogether. The exception to this narcissism is the application topology mapping vendors we review in "Map Quest".Here are a few of the vendors that have BSM pitches. This is by no means an exhaustive list, but all of these proclaim--and some even deliver--the BSM goods.

BSM has been hyped to within an inch of its life, but don't hold that against it. Done right, business service management is a big step toward the alliance of technological and organizational goals. When IT can pinpoint what's causing a drop in online widget sales--and fix the problem--we should be done with all this talk of IT not being integral to business success.

In "The Network Effect," we discuss how IT can build management around existing systems by enhancing service delivery. ITIL (IT Infrastructure Library) is key, along with a willingness to stop handing down edicts, but rather implement, monitor and report on performance goals and set IT priorities, chargebacks and budgets according to declared organizational priorities.

In "Map Quest," we review application-dependency products, asking each to discover and document applications running on our NWC Inc. business applications lab network. We tested BMC Software's BMC Topology Discovery 1.2, Cendura Corp.'s Cohesion 3.5, Collation's Confignia 3.1, nLayers' InSight 4.0 and Relicore's Clarity 4.1, which took our Editor's Choice award, thanks to its granularity. That it accomplished its magic by planting agents on every server may give some organizations pause, but we found the results worth the effort.