Data center management is all about managing the business services that run within the data center – be it the trading application, the on-line ticketing service or the call center. At the same time, it is not about the servers, storage and network that comprise the data center.
No one cares if a server is down. Everybody cares when the trading system is down.

But the monitoring tools today seem to be focused on the infrastructure level. There are so many tools out there that tell you everything about the health of the network, storage, and servers. It is all very accurate and detailed information but totally unrelated to what matters – the business.

Application Performance Management (APM) tools attempt to provide information about the health of the business service or more precisely about the application level. This is of course much more useful.

But there is still a need to connect this “higher level” information to the “lower level” information coming from the monitoring tools that know what elements are failing or responding slowly. To enable that – a real time mapping of how IT components, either on-premise or in the cloud, are configured to deliver a business service – is warranted.

This mapping, referred to as Business Service Mapping is essential for both efficient root cause analysis and for impact analysis. Business Service Management tools rely on this service mapping to deliver intelligent IT monitoring information that is tied to the topology of the business service. With this info, isolation the location or a problem becomes easier and the mean time to repair a problem (MTTR) is shortened with root-cause analysis becoming far more efficient.

Let’s be honest. Business Service Management (BSM) projects haven’t had the greatest reputation. Long implementation times and inaccurate dependency mappings are just some of the reasons mentioned. (For more interesting facts and numbers, see our BSM survey.)

A managed service model for BSM eliminates these obstacles and offers a much more efficient, less painful and less risky path to success.

But wait a second. What is, exactly, “BSM as a service”? How does it work? And how is it different from the ‘traditional’ business service management model? Here are 5 key points you should know about BSM as a service.

1. Minimalistic setup

Like other SaaS-based offerings, BSM as a service eliminates the overhead of setup, configuration and maintenance. All that’s needed is a minimal, 10-minute install of a ‘collector’ application inside the data center, which communicates with the ServiceWatch NOC and carries out the interaction with the local data center resources.

You manage your business services and IT infrastructure from the web dashboard – add new business services, view dependencies between configuration items (CIs), perform impact analysis and analyze IT change effects.

2. Deep application knowledge not required

In the ‘traditional’ BSM world, the discovery/mapping process requires a deep know-how of the applications’ architectures: what are the application components, which components run where, what are the dependencies and what is the configuration are only some of the questions that need to be answered. The folks who can provide the answers are highly sought after in most organizations and are generally quite busy.

With the BSM as a service model, there is no need for any of this. Why? Because this deep knowledge is delivered as part of the service by a dedicated team of domain experts and best practices that are implemented into the offering.

3. Top-down discovery & dependency mapping

In the conventional discovery methods, the network is automatically scanned to create a huge repository of the local configuration items (CIs), which is usually kept in a CMDB. In our SaaS model, discovery and mapping uses a streamlined, top-down approach. You provide an entry point for the business service (such as a URL or an IP/port) and the discovery process automatically identifying only the related IT components. This creates a focused repository that lets you immediately understand the link between a business service and its supporting CIs. Read more about bottom up vs top-down discovery and dependency mapping.

4. One business service at a time

With Neebula’s managed service BSM model, you can start with a single business service, and then add additional critical business services any time you like. No need for a full-blown, 12-month implementation till you see any results. You’re up an running within days.

5. Pay as you go

Instead of paying for technology, you pay for value. Pricing is based on the the number/scope of business services you manage, so that you really pay for what you get. No hidden costs related to training, consulting, hardware or maintenance.

But, seeing is believing, right? So why not try out our live online BSM system to see for yourself.

Discovery and dependency mapping involves many misconceptions. Automation, for instance, is a common theme when discussing application discovery, but then – are all solutions the same? Let’s begin first with defining the objective.

With the growing complexity of IT systems, virtualization, cloud and the like — there’s an obvious need for accurate up-to-date data. Whether the goal is change management, impact analysis, handling of critical events, allocation of resources, or all of these — there’s an obvious need to discover all Configuration Items (CIs),  identify their interconnections,  and understand the link between the underlying IT infrastructure and business services.

So what are your alternatives for discovery and dependency mapping?

The common method – bottom up

Considering the scope of IT systems, it is obviously impractical to use manual discovery methods. Automation, therefore, is a must.

Indeed, most discovery and dependency mapping solutions automatically scan the network, discover all CIs and build a large CMDB repository. We call this a bottom-up approach.

What’s the problem with bottom-up discovery and mapping? The first is TMI – too much information. The final result of such a discovery is a huge repository with tens of thousands of elements, but no meaningful categorization that relates the data to business services. Such a repository will include many irrelevant components (e.g., any virtual server that was temporarily used for testing a year ago). Each CI has a large amount of data associated with it- most of which is unnecessary and detracts from your ability to sift the meaningful data.

The second issue is the repository update. According to our recent Business Service Management survey, over half the organizations report 11 to 100 IT changes on a weekly basis. Bottom-up auto discovery methods do not offer a path for an automatic update of the data. Instead, the system has to be re-scanned in order to remain accurate.

Probably the most problematic issue is that the bottom-up approach requires you to manually filter the huge repository and map CIs to business services. So, for instance, if an application server has many connections, you’ll still have to decide which of the connections relate to a specific business service. Naturally, by the time you are done with such manual mapping, it will most probably no longer be accurate anymore.

The bottom line is that in order to successfully map a service, you must actually know its structure, components and application map. So in a sense you really need to  know the mapping to do the mapping… What’s missing is a process that uses the business service context and enables the mapping to be done automatically.

Top-down discovery and dependency mapping

The key to automating the business service mapping process is to use some simple means to identify the service, and then derive from it all the components and structure. This is where the top-down discovery approach steps in, making the business service itself the anchor point of the discovery process.

The top-down approach uses the only possible business service identification key – the point at which the business service is consumed. The user

provides an entry point for the business service – for example, a URL for a web-based application, or an IP, port and server for a fat client application. The discovery process then advances tier after tier to identify the IT components related to the business service. This results in a much smaller repository, and a 100% focused service map that lets you immediately understand the link between a business service and its CIs.

Moreover, the process keeps the business service context, and is therefore able to follow any dependencies which are part of the particular business service. Isolating only the relevant dependencies is also key in mapping the business service to the underlying network and storage IT components which always serve multiple business services. This enables a true holistic cross-domain mapping and impact management solution which is simply not possible otherwise.

To further complement the top-down approach, Neebula’s automated discovery process also builds an abstraction of the business service structure which is independent of the actual real-time model. We call this abstraction a Skeleton. The skeleton is used to define business service policies and rules on the generic application structure and makes sure that the actual business service structure is always up-to-date. For example, there are certain parts of the business service which are more prone to changes, such as the members of a web server farm behind a load balancer (these can change overtime to adapt to the changing demand, especially in dynamic cloud environments). Such load balancers would therefore be scanned more frequently than other entities, such as databases, which are less likely to change.”

This bottom line is a much more effective discovery process, yielding a focused dependency map that is always up to date. Want to see this in action? Take a look at our BSM demo.