Mind Your Transactions When Times are Tight

These days, it’s more important than ever to ensure your business systems work like they’re supposed to. For starters, customers are harder to come by. They’re pickier, too, since they’ve got a wide range of bargain-basement options. The slightest glitch in your system and your competitor gets the business, not you. Simply put, you can’t afford to have unreliable systems.

It’s pretty clear how transaction failures affect your bottom line. Shopping carts lose their contents, accounts fail to be provisioned, orders are lost and packages become untraceable. Not good. And remember, it doesn’t matter one bit to your customers why, how or where the error occurred. All they know is they weren’t served well.

Modern application architectures are becoming increasingly brittle. With interconnected, multi-tier applications running in virtualized environments, isolated failures, errors or slowdowns can have a dramatic impact on the overall system. It’s tedious and expensive to locate and repair these issues. Your teams waste countless hours searching through log files or looking at multiple consoles in order to piece together the problem and its root cause.

One of our customers met this issue head on. A Fortune 100 financial services company that’s one of the largest, most complex transaction-oriented organizations in the world. A single business unit within the bank processes 780,000 transactions per day, spread over 3,500 distributed nodes. The Senior Development Manager had this to say:

“The risk for our application is enormous. In our business, with the nervousness of the market, perception is key. Even with 30 minutes of downtime costing 100,000 Euros, our face to the street is much, much more important than transactional dollars.”

This customer was facing a huge challenge in pinpointing application problems because processes and transactions were dispersed across thousands of blade servers throughout the data center.

Business Transaction Management addresses these pain points. Done the right way, it provides visibility into every transaction flowing from start to finish across the environment. It detects slowdowns and failures and notifies you immediately of the problem. And it pinpoints the source of the transaction failure so you can quickly remedy the situation.

For more on this topic, have a look at our analyst report on Business Transaction Management. It gives more information on the Fortune 100 company I described here.

What's in a Name?

We’ve seen a lot of name changes for distributed applications. First it was Web services-based applications and then SOA-based applications. Now there are some question marks associated with the term SOA itself. From our vantage point, services are not only surviving but thriving. As customers modernize their applications, services are used in one form or another. Many use terms like “composite applications,” “connected systems” or even “compositions.”

Does it matter what term we use to call these distributed systems? Perhaps it would suffice to simply call them “applications” and know that in today’s enterprise landscape the de facto application is cobbled together from services developed in-house, or exposed by commercial off the shelf applications, SaaS, legacy systems and so on. Different services may support different lingua franca to enable a conversation. They may use different platforms and programming models for development. However, they are all examples of enterprise services. Furthermore, while most organizations encourage service reuse, some simply do not! With application modernization projects continuing unabated—even in these budget-conscious times—silo’ed applications are increasingly becoming the exception.

Of course, your management solution shouldn’t care what you call the application. Nor should it care what comprises the system. To succeed with loosely-coupled systems, you need visibility and control of the whole enchilada – at the application level. You need to track the transactions end-to-end, no matter the platform, the infrastructure or the transport protocols involved. But I digress.

I’d like to hear from you on the subject of naming. What do you call YOUR distributed systems and new project initiatives? Are you still saying “SOA?” Do you use another term instead? Or is it simply your “claims processing system” or your “procurement application” with no mention of the underlying architecture?

Your comments, please.