Business transaction management (BTM) has been getting a lot of attention lately: Technology organizations want it and every major vendor in systems and performance management has rushed to claim they do it.
The promise of BTM is to finally be able to manage technology from a business perspective and make sense of the complexity of modern applications broken down in services that run across environments (real and virtual) distributed behind the firewall and in the cloud.
Moreover, business transactions touch many layers of infrastructure and applications across wide networks, with downtime and poor performance directly impacting revenue, brand, and customer loyalty and retention.
Therefore, the need for business technology services that can ensure not only highly reliable transactions and end-user performance across rapid problem diagnosis and resolution, but also support change and capacity planning that ultimately delivers better service, is paramount. Can BTM live up to these expectations?
Having an all-system-lights-green from an technology operations perspective is useless if an online banking customer cannot pay a bill. De-provisioning a low-utilization server will be a disaster if you don't know that your insurance agents' claims processing touches it. Rolling out a new service will be a failure and infuriate customers if it will compete for resources with other applications and cause unacceptable performance.
It used to be fairly simple to manage data centers in a world of monolithic applications and systems, that is, until:
- systems became distributed;
- infrastructure was scattered across n-tiers and is now getting virtualized;
- technology services have been outsourced;and
- applications are broken down in components and Web services.
And with customers plugged directly into these complex systems from the Web, almost everything has become mission critical. To cope with this complexity we have thrown a larger number of monitoring tools at all the different tiers:
- end-user experience;
- proxies;
- networks;
- servers;
- applications;
- message brokers; and
- databases.
Yet companies are still losing millions of dollars for unplanned outages and unacceptable performance. And we are wasting days in war rooms trying to track down critical problems. If it works we do not know why and if it breaks we do not know why.
Instead, what if we could put on the 4-D glasses of BTM and see the connections between the four dimensions of end-users, applications, infrastructure and business processes?
- We would be able to know exactly where in the entire data center topology a transaction was getting stuck (e.g., what is slowing it down, what process it is waiting for, etc...)
- We could monitor in real time the health of all transactions associated with a particular service or line of business (e.g., online banking, claims processing, new accounts, e-commerce, etc...)
- We could trace a run-away database query back to the user who originated it.
- We could see the exact impact on all critical business functions of rerouting transactions to a disaster recovery site.
- We would have a common context and language for business, technology, application development, and operations to work together.
Consider the example of a major investment bank whose online trading application was hanging for several minutes five to six times a day with huge negative repercussions for thousands of users worldwide.
The company's technology experts convened in a war room but were unable to identify the cause of the problem and decided to try a BTM solution. Agents were installed and the BTM solution went to work performing a system wide auto-discovery and aggregating data at the transaction level across all the tiers in the data center.
When the problem showed up again the company was able to see immediately that the bottleneck was in the external database. Zooming into a granular breakdown of the workload for that database, the bank found a specific SQL statement that was accounting for 90 percent of the transaction workload and was affecting the performance of the entire application.
But identifying that SQL statement was not enough to fix the actual problem: The statement could have been sent out as a result of any number user actions or a defect in the application code could have been causing tens of thousands of these statements to be sent out to the database for no real purpose.
But armed with BTM data this investment bank was able to find out which transactions were sending out these SQL statements and the user who was initiating them. It turned out the company had a client who was an independent stock broker. He had two servers and had written his own code to "screen scrape" the bank's application in order to collect market data to improve his trading of stock options. He was doing it in short bursts when there was a good opportunity for him in the market.
Right away, the account was blocked and the application code was fixed in order to prevent this from happening again, thereby resolving the problem.
This example shows how critical a business transaction perspective is to providing the context necessary for understanding what is going on in technology, enabling companies to plan proactively and rapidly resolve even the most challenging of problems.
About the Author
Oren Elias (oren.elias@correlsense.com) is the founder and chief executive officer of Correlsense. He brings more than 14 years of experience in the software industry. Prior to founding Correlsense (www.correlsense.com), Elias founded and managed Internative Solutions, a provider of knowledge management solutions designed to support contact centers through multiple contacts channels. The company was founded in 1997 and sold in 2004. Prior to founding Internative Solutions, he served as an technology expert for Vocaltec Communications. Earlier, while serving in the IDF, Elias participated in the development of knowledge management systems. Mr. Elias is a graduate of the MAMRAM IDF computer academy and has studied Economics and Computer Science in Bar-Ilan University.
Please note that the Viewpoints listed in CRM magazine and appearing on destinationCRM.com represent the perspective of the authors, and not necessarily those of the magazine or its editors. You may leave a public comment regarding this article by clicking on "Comments" at the top.
To contact the editors, please email editor@destinationCRM.com.
To subscribe to CRM magazine, please visit http://www.destinationCRM.com/subscribe/.
If you would like to submit a Viewpoint for consideration on a topic related to customer relationship management, please email viewpoints@destinationCRM.com.
For the rest of the February 2010 issue of CRM magazine please click here.