Picking a game wrong in your bracket can greatly impact your ability to win your bet or office pool. A similar situation plays out daily in IT in regards to business critical applications. Hundreds of alerts indicate a service degradation and looming failure. But in the case of IT, where does one look to assess the impact? From a Business Service Management (BSM) perspective, the answer is the service dependency map. This article will compare the NCAA Men’s Basketball Tournament with BSM challenges that are met by Business Transaction Management (BTM).

The annual NCAA Men’s Basketball Tournament is currently underway. It is better known as “March Madness”. In 1981, CBS bought the rights to the air the tournament for an average of $16M per year. According to an ESPN Outside the Lines report, in 1999, CBS inked a new contract for an average of $545M per year, which is an increase of ~3300%. According to a TNS Media Intelligence article, the ad revenue for the NCAA Tournament in 2007 was $520M, second only to pro football for post-season ad revenue for US sports. Bottom-line, this is big business. But why does the NCAA Tournament create so much interest and passion? In large part it is due to the way people can analyze, bet on and track the tourney using the bracket.

The tournament is composed of 64 teams broken down into 4 geographic regions of 16 teams each. This year’s starting bracket was as follows:

There are 63 games with two outcomes each (team A or team B wins), which yields 263 combinations of potential outcomes, which is more than 9 quintillion (9,000,000,000,000,000,000). (See more on this calculation at The Math Forum @ Drexel, “NCAA Tournament Possibilities”).

With so many combinations, you never know what can happen, hence the madness. However, there is a map to guide you through the madness – the bracket itself. You can track the outcome of each game and your status (winning/losing) at any point in the tournament. The bracket is living entity for the duration of the tournament and contains only the most important high-level information – who won the game and perhaps the score. (Noticeably absent are lower level metrics such as Possessions, Field Goal %, Fouls, Turnovers, etc.)

In the word of information technology, there are many potential paths a transaction can take in even a (grossly) simplified application topology such as this:

In this example, if you assume all transactions start at the first logical tier, there are 32 (2*4*2*2) possible transaction paths. That doesn’t seem so bad at first, but then consider that each transaction must be considered individually as well. If an application handles 100,000 transaction per day (many applications handle that many per minute) then there are now 3.2M combinations of transaction and path. Even a simple example represents a daunting challenge. This challenge arises precisely by adding the transaction dimension to the application topology. BTM answers this challenge.

BTM adds the transactional dimension to BSM (which is absent from configuration management databases (CMDBs)). It also provides high level metrics (transaction response time, transaction chattiness and transaction specific resource consumption) that combine with the living topology to provide the map view akin to the bracket for the NCAA tournament. This transaction map can be used in real-time to make sense of the madness – which makes it the backbone of outage avoidance and problem isolation capabilities. Additionally, BTM enables proactive capacity planning and performance optimization efforts. Together with the more detailed, domain-specific data and statistics captured as part of BSM, BTM enables better service level management, change and configuration management and more.

When investigating and evaluating BTM solutions customers often focus their investigation on how transactions are tracked (and thus how the living topology is generated). While the methods of transaction tracking are of paramount importance, of equal importance is how the data and complexity are processed, analyzed and managed server-side. The combination of capturing the right data in a transaction context and being able to analyze that data across multiple dimensions defines BTM as an evolutionary step in BSM – one at the center of BSM itself.

Millions will enjoy “March Madness” for the few weeks it dominates the American sports landscape. For IT professionals, every day year round brings new and dynamic challenges. BTM provides the map and analysis to bring sanity to the madness.

Before the trip my Dad would consult maps, plan the route and stops.  The worst feature of the wagon was the frequent overheating.  A dubious trait of its operator was, planning be damned, a penchant for getting lost. The “highlight” of these trips was the often hours spent in stopped traffic due to construction or on the side of the road, radiator spewing.  I have very fond memories of these trips.

Today cars have power everything:  A/C, satellite radio, GPS, Bluetooth, DVD players and TV’s!  How different is a similar summer trip today?  Cars are much more reliable.  GPS navigation shouldn’t replace trip planning, but it certainly lessens the stress of remembering every turn (being a route “expert”) and most importantly can put you back on track quickly when a problem occurs (i.e. detour, missed turn).

So where are we now as computer users or professionals in IT?  Many of us still end up “on the side of the road with the hood up” trying to address a computer problem, transaction problem or system wide outage.  We are still at the point where we are not sure exactly what will happen when “Submit” gets hit.

But just like automotive technology, monitoring and management technology has improved over the years. However, many monitoring suites still have the feel of that same old wood paneled station wagon trying to pass as cutting edge by bolting on after-market modules. At some point, upgrading the next generation solution is the best way to go – a solution that was built from the ground up to include all “standard” enhancements as well as the most recent breakthroughs.

Imagine as an IT professional being able to view each user’s transactions – when they started, how long they took (or are taking), where they went or are going, and if there is a problem, being able to quickly localize the problem and get the transaction back on track. This enables a shift from worrying about whether a transaction will complete or have drastic variations in the time it takes, to managing cost, assuring security and delivering superior user experience. One day all of these capabilities will be delivered “standard.”

Business Transaction Management (BTM) is a big step forward in this area.  BTM allows IT to provide users a better trip and to deliver more value to the business – all this without one having to be one part planner and architect and one part master mechanic.  That doesn’t mean we won’t look back and remember the days of “all hands” calls with nostalgia.

1. Who does  BTM compete against?
2. How does BTM compare to [Insert APM/BSM Vendor Name]?
3. Can’t I do the same thing with [Insert Deep Dive Product Name]?

It has been a challenge to answer these questions in a succinct and compelling way, but I feel that I’ve finally come upon the best answers (with a lot of help from prospects, customers and colleagues) that  help crystallize the benefits of BTM compared with traditional monitoring solutions.

Part of the reason people ask these questions is largely due to the fact that “the first five slides of every presentation are the same” and “everyone comes in and says the same thing.”  This leads us to the answer to question #1 – “Who does BTM compete against?” The best answer to this is “the marketing departments of other monitoring companies.”

The second question is particularly challenging.  APM and BSM vendors have broad and feature-rich solutions suites.  They have many capabilities and strengths.  Most often they are an integrated combination of products that additionally can be used standalone.  For example, a typical APM suite is comprised of end user monitors (synthetic and real user),  application deep dive solutions (for J2EE, .NET, databases, etc), system and infrastructure monitors, a CMDB, a dashboard, a rules engine and so on.  Therefore when someone asks:  “How does BTM compare to [Insert APM/BSM Vendor Name],” I give the following descriptive answer.  “Look at what the product was designed to do from version 1.0.”

If you look at what version 1.0 of a product was designed to do, it is a good bet that the “v1″ strengths and differentiators remain the same to this day.   In other words, if something was built to do end user monitoring in version 1.0, it is an end user monitor.  If it was built to be a CMDB, it is a CMDB, even if it got renamed to a PMDB.  If was a deep dive solution, it’s, you guessed it, a deep dive solution.  The point here is that to do BTM, you need a product that was designed and built from the ground up to do BTM.  This means it must be able to track all transactions all the time in production and capture their business context, topology, performance (roundtrip and segmented) and resource usage.  If a solution wasn’t designed to do BTM from day one, it won’t get there – at least not anytime soon.

This brings us to our last question – “Can’t I do the same thing with [Insert Deep Dive Product Name]?” The best answer I heard to this came from a new BTM customer.  In short the answer is a resounding “No” and here’s why.  This (new) BTM customer had at one point asked this very same question. After seeing the transformative effects of BTM on his team and organization, he mentioned he had “finally seen the light” and the difference at a high level was that “BTM is on the wall in the NOC and is used in communication with application owners and the line of business.  Deep dive data is never used that way.”

Three common questions, seemingly simple, highlight the differences between BTM and other types of monitoring.  I now look forward to hearing these questions as it gives me the opportunity to educate about BTM – a class of monitoring that delivers game-changing value to customers.

The aha moment occurs when a prospect or customer first sees the auto-discovered topology of their own business transactions.  They now have visibility they never had before.  They know where the transactions went.   They understand fully what is meant by “transaction tracing.”  They can see the overall topology – all business applications and transactions, or a specific transaction such as “Policy approval,” as well as see individual transaction instances.

This new visibility is powerful for the information it provides, but the aha moment wouldn’t happen if it required transaction modeling or data definitions to generate the views.  The fact that the transaction topologies are discovered automatically is key to the epiphany. The additional value of capturing the business context of each transaction, the roundtrip and segmented response times, as well as resource consumption finally leads to the statements: “Wow, now I get it – this is BTM.  There’s no way I can get this information today. This is the view I really need.”

So why do prospects need to see BTM working live before fully appreciating it?  I think this is due to the fact that most people in IT have heard the transaction tracing story before.  Either they’ve tried to do it themselves via a coordinated development effort or they have tried to integrate a suite of products together – none of which was designed to do BTM.  So now they’re skeptical and gun shy.  Seeing the automatic discovery of transaction topology and flow changes this.

For now this initial challenge will remain.  It may be a while until there is a better answer to the questions and doubts than: “Please trust me.  Let me show you how BTM works with your own transactions.  Seeing is believing.”