Chronicles of a Wandering Mind

Service management is the essential enabling paradigm for today’s IT organizations. Putting the tools and the jargon aside, every organizational unit needs to identify the following:

• what are the services they deliver

• who their customers are (internal or external)

• who their (service) providers are

• what internal/external dependencies the services have

• how they can measure the availability, performance and quality of the services they provide

• expose the service information both in human and machine consumable formats

Fundamentally, that’s all there is to it. The rest is all about how to get there.

“Business Service Management is an enabling technology at the intersection of business and IT alignment”. The final layer that provides the interface to business in terms that is meaningful to the business.

BSM implementers face a tough challenge. On one hand, BSM solutions are required to have a simple and abstract facade that hides complexities of the IT infrastructure and provide information to business users in their own language. Yet on the other hand, to be more than a pretty face with no brains, BSM is required to be very sophisticated under the hood in order to be able to model, discover and instrument services and the dependent IT infrastructure components.

In many implementations, modeling and instrumenting this complex environment (referred as BSM Heavy approach) forces BSM projects to become very large and expensive projects where IT silos are often forced to replace tools they are using, in addition to going through a religious conversion. As a result this approach has a low success rate.

An alternative approach is to go around the IT silos by implementing tools in parallel for small number of critical business services vertically. This approach (referred as BSM Light) attempts to avoid organizational obstacles and can be implemented in shorter time frames, making it possible to demonstrate progress quicker.

I’ve always thought that success of BSM projects depends more on how well organizational challenges are handled than how good the tools are from a technical stand point. But what type of organizational change the tools dictate is something beyond technical abilities of the tools. The tools that enable companies to implement solutions without dramatic organizational shifts as a prerequisite have a much better chance to actually achieve the organizational change.

An alternative approach recently articulated by Robin Harwani has great potential to minimize some of the organizational obstacles.

Instead of forcing IT silos to replace tools or implementing tools in parallel, BSM projects can define interfaces (APIs) for the management information to be exposed. Various IT departments can use their own tools as long as they expose the information using defined interfaces enabling BSM tools to focus on using the provided information to model business services in a higher level. ( There is another three letter acronym I’m avoiding here as the term  introduces more questions than it answers).

The most important advantage of this approach is that it minimizes the required organizational change and participation/buy-in. It provides IT groups freedom to use whatever tools they see fit as long as they embrace the service management paradigm described above and expose management information through agreed upon interfaces to be used by BSM systems.

This approach can reduce the scope of the BSM project, divide the work into more manageable chunk and increase likelyhood of a successful completion.

Final thought: Change cannot be a prerequisite for the success of a project. The project teams must consider instigating the change and removing organizational resistance as a key constraint that has to be addressed. The processes, the tools, the players all have a role to play on this.