Business Transaction Management Blog

by Stephen Burton, 2nd November 2009.

I have yet to meet a satisfied customer with a CMDB. It’s not like I go looking everyday but somehow the subject always seems to arise and people tend to get quite touchy on the subject. It wasn’t so long ago I worked for a company who spent a fortune acquiring an application discovery and mapping solution. It promised auto-discovery in real-time and all those wonderful things yet it seemed to die a cold death months after the acquisition closed. I listened to the sales pitches around “When applications go down the first question asked is ‘What changed’?” and the famous “75% of application outages are related to change”. To me that’s like stating the bloody obvious, of course something changed, if nothing changed the application would be still running.

The problem these early discovery & mapping solutions lacked is business context. They were inherently built to track IT interactions from server to server and technology to technology. They’d scan server ports, executables and protocols to try and piece together the relationships between IT assets within a data centre. Or they’d do it by listening to the actual interactions. They’d paint pretty little diagrams like the London Tube Map and then give you all the technology, versions and patch levels these assets were running. Some solutions were priced per cpu which can be highly lucrative when vendors told customers to put an agent on every server in their data centre. Unfortunately the one thing they didn’t discover or understand was the business services that ran across these IT assets. Applications and Business Services these days don’t just relate to 4 apache web servers, 8 weblogic servers and 1 Oracle database. The pervasiveness of SOA and mashups these days means a single IT asset can serve one or more business services. Applications and IT Assets no longer have a 1 to many relationship, an application isn’t simply a collection of segmented IT assets.

I did a search on Wikipedia for CMDB and found the quote “A key success factor in implementing a CMDB is the ability to automatically discover information about the CIs (auto-discovery) and track changes as they happen.”. If a business service is a CI then that’s a pretty tough proposition to auto-discover and track change on. How do you discover business context from IT assets? For starters you can stop looking at the IT assets for answers, you’ll get your versions and patch levels of Linux but you won’t get a description of your business services that flow through them.

I’ll put my head on a lance and state that Business Transaction Management (BTM) can add significant value to any CMDB project. When you start to monitor business transactions you start to acquire lots of key intelligence on how your business runs and maps to IT. You auto-discover transaction flows and the IT assets they interact with, all in real-time. It also gets better, you can store all this data historically so that you can report and compare business services and their CI’s before and after a change. You can even visualise how the business and IT asset dependencies change over time using transaction flow/topology diagrams as key evidence. When a change occurs on an IT asset you can instantly report whether this change had a positive or negative impact on your business services or transactions by reviewing related latency and SLA. I’m not claiming BTM is the answer to all CMDB pain but it solves some of the most basic and common challenges:

1. Auto-discovers business services and their IT dependencies in real-time
2. Stores information historically so you can track, report and quantify change when it occurs

Maybe BTM is the pain relief CMDB projects need right now.

Follow me on Twitter