Archive for June, 2009
Awe and Disbelief
Common reactions to Business Transaction Management: How is it even possible? Can it really do what it says on the box?
Continue Reading June 30, 2009 at 9:38 pm Assaf Amit 1 comment
Simplicity is Good, Complexity is Evil.
For those of you who read my blog you may perceive me as just another product manager of an IT company. One of my interests outside of work is motorsport and generally driving a car as fast as is physically possible. I’m not the type of guy who drives to work cruising on the motorway in 6th gear doing 50mph (no offense meant for people who do this btw). For me its about getting from point A to point B as quickly as possible whilst maintaining strict adherence to government speed limits…or something along those lines.
Anyway, I was thinking the other day just how complex a car is underneath the glossy paint and metal shell that most people perceive a car to be. You’ve got the engine for starters (literally), then you’ve got things like air filters, radiators, oil tank, fuel tank, catalytic converters, spark plugs, exhausts, gearbox, clutch and so on (I won’t bore you with the other 1842 parts). The car also has hundreds of sensors to detect failure, tolerance levels of components and even stupid people who don’t wear their seatbelts (again no offense intended for people who don’t wear seatbelts). It’s actually an engineering miracle that so many pieces can work together without failure for so long (unless you happen to own a TVR of course). And the great thing is that when something does go wrong your car dashboard lights up like a Christmas tree and tells you what’s wrong – how cool is that?. The monitoring and operation of all those car components is simplified through a lovely glowing dashboard. The oil light comes on when you need more oil, the tyre light comes on when you need new tyres or more pressure. If you drive a BMW then the onboard computer even tells you that your not driving close enough to the car in front like other BMW drivers. In the unfortunate case of an engine light, the problem normally involves a trip to your car garage where some guy in white overalls plugs in a computer to your cars ECU. Usually within 2 minutes he’s detected that your car is broken and needs £2000 worth of work to fix it. Needless to say 95% of issues can be fixed in no more than a few hours (which is why Audi, Mercedes and BMW garages charge £150 per hour labour) 
.
Simple to drive but Complex to engineer
My point with the car is that it’s a simple bit of kit to use and monitor despite its hidden complexities. Car manufacturers have done a stellar job of simplifying complexity so that our cars don’t have 101 dashboards to report status or issues. You turn the key to start, turn the wheel to steer and plant your foot firmly to the floor to go fast. Your car’s dashboard does all the rest to inform you of what you need to know. When the car needs an update the garage simply remaps the car’s ECU at the next service rather than letting than the owner do it himself with a laptop, OBC connection and a hotfix off the internet.
If monitoring cars can be so simple then why can’t monitoring applications? Applications have just as many components and complexity, they are even built by engineers who use keyboards rather than spanners. They even have a nice pretty appearance (unless they’ve been built in the 1990′s with visual basic or something). I know what your thinking “Applications are more complex, nothing can be as complex as coding an EJB or writing some complex SQL”. Try telling that to the folks at Ferrari or Porsche that spend millions each year optimising their traction control and stability systems that stop people like me from ending up in a hedge.
As a product manager working for a software company in the monitoring space I feel a sense of responsibility for putting an end to this complexity of monitoring business transactions, applications, SOA environments, end users, networks, JVM’s, databases, servers, enterprises buses and pretty much everything else that requires several million products, agents , appliances, dashboards and user interfaces. Software vendors should do what car manufacturers have been doing for the last 20 years. They should provide simple usable solutions that abstract over all complexity and make it as straight forward as possible to manage business transactions and the IT infrastructure with which they flow.
The “Aha” Moment of Business Transaction Management (BTM)
When I am presenting BTM to a new audience, they commonly ask “How is this different than all of the monitoring tools that we already own?” Some say “We can already do some of this today with our existing tools.” Many prospects still remain skeptical after value based presentations, demos, use cases and ROI statements. However, there is one moment when the lights come on, when prospects clearly see the power and uniqueness of BTM. This is what I call the “Aha” moment of BTM. What is this aha moment? When does it happen and why?
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.”
New business transaction management research announced
On June 16th, OpTier announced that it had interviewed 2,000 UK IT decision makers at businesses of 1,000+ employees across a range of industries, including retail, government, finance, telecoms and manufacturing. The results were significant, finding that two-thirds of IT managers are blinded by complexity of management tools and, as a result, are costing large businesses more than £4.5million annually.
The startling insight was picked up across the UK and brought business transaction management to the forefront of IT news in the UK.
Head over to the press release on OpTier.com to learn more about the research.
Why BTM Complements APM Solutions
Something that has become clear in my mind over the last year is that Business Transaction Management (BTM) is very different to the popular Application Performance Management (APM) solutions we’ve typically seen in the market place over the last 5 years. I base my opinion solely on an important group of people we’ve come to know over the years as “customers”.
My father once taught me an important lesson whilst he was arguing with a waiter in a restaurant, something along the lines of “The customer is always right”. In fact, it was only recently I used the exact same phrase whilst interacting with the security staff at EL AL airport check-in. After a few puzzled looks, baggage checks, several questions and two stickers I was on my way. Anyway, my point is that customers are generally a good indication as to whether something is good, bad, useful, different or valuable.
In the last year I’ve sat with several Fortune 500 customers who have ALL told me that BTM is changing the way they utilise their APM investments. In fact, two of these customers actually shared with me their IT service delivery and support processes so I could see with my own eyes where BTM and APM were playing a key role towards the common objectives of improving end user service levels, performance and availability. Simply put, BTM was used to identify, alert, prioritise (understand business impact) and isolate issues whereas APM was then used to understand root cause and resolution of these issues.
For example, in real-time BTM could detect a user specific transaction that breached in the application, it could then provide an immediate latency breakdown across all tiers where that problematic transaction traversed. Once the latency is isolated to a specific tier the customer can then focus their APM solutions to that tier and understand the root cause and apply a fix. The net result of all of this is that Mean Time To Resolution (MTTR) or Recovery (take your pick) is significantly reduced. One BTM customer dropped MTTR from 2 hours to under 15 minutes using both BTM and APM effectively together.
User’s experience transactions, its therefore important that BTM provides you with visibility of every transaction from every user across every tier so you can focus your APM solutions in seconds to the tiers that are causing issues. When your application spans tens or hundreds of tiers you need to isolate the right haystack before you start looking for that needle.
OpTier
Assaf Amit
Andy Wetzel
Russell Rothstein
Motti Tal
Linh C. Ho
Diego Lomanto
