Business Service Management practices have the greatest chance of success when:

• The solution provides several different views of the same data. The technical team needs a few different views (top down, bottom up, inside out), the end users of the systems (internal or external customers) want to see the services they are using along with the health (email, payroll, etc), management wants to see impacts to the business, revenue related metrics (trade volume).

• Granular security control is needed to control the depth that end users are allowed to drill in as well as controlling which users are able to perform actions such as Acknowledging an alarm.  While the BSM solution must be able to represent the service from end to end, there rarely is a reason to have an executive drill down and look at the performance metrics of a network card on some obscure server.   Showing that a single node of a cluster is down is important to some users, this is useless data to others.

• The solution fully understands health of the Service. Integrating with the JUST the top management tool may provide ‘all’ of the alerts within the environment, it won’t provide easy drill down into the underlying tool reporting the failure in order to get at additional details or command and control, it won’t tell you to fix Service A over Service B, it won’t tell you that if you do not reboot server123 in the next 10 minutes you will breach a critical Service Level.

• Root cause is more than determining the router being down is the root cause of the server being unaccessible. While this is useful information, this type of root cause does not always map to why a Service is down.   Don’t get me wrong, it is very important and needed information.   The team responsible for resolving outages need quick answers, they need to be able to to quickly see within the sea or red alerts that this particular server being down is the reason that payroll is down.  Between this server and the 15 other outages, they might want to work on this server first… it’s payday.

• The end users of the implementation are consulted with to understand their requirements. Just because you can set up the view one way doesn’t mean that it provides value to the end users.  They need easy access to the data, they need quick access to other internal tools (knowledge base, help desk, etc).  The solution needs to make their lives easier.

• Start with an important Business Service, or a single important application or one that keeps the CTO up at night worrying about it.   If you start with mapping the one service end to end (as best as possible without getting stuck in a rabbit hole), get an internal win, ROI, etc., it helps map out the next Services, rally other teams to get involved, etc.   Trying to do every service end to end completely automated, etc is trying to boil the ocean, it’s not going to work.   Sometimes a partial view is better than no view.  Stating small and working out from there is key.

One other reason that I purposely omitted is management buy-in.   I feel that it is important, but to get started, it may not require complete management buy-in.   What I mean is, sometimes management buy in is only needed within your own group or department, other management buy-in is sometimes needed in order to expand the footprint or get additional details.   I’ve seen that come along as the BSM team gets wins under their belt.

Okay, don’t be shy, what are some reasons that Business Service Management worked for your organization (or you think you need for your planned BSM implementation to be successful)?   Dashboards, HA/DR, CMDB, Discovery, ITIL projects…

– Tobin