We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business IT Buzz Blog

Kaitlin Brunsden

Business Transaction Processing: Talking with Nastel Technologies

user-pic
Vote 0 Votes

What follows is my podcast with Charley Rich, Vice President of Marketing and Product Management at Nastel Technologies. We discuss the role BTP plays in proactive IT management. Charley will offer his insight on the importance of putting a transaction monitoring solution in place in order to detect and fix abnormal activity that has the potential to cause cascading high-impact failures within the IT system.

Listen to my 8:43 podcast below:

Download file

KB: Can you please provide us with a brief overview of your company?

CR: Certainly. My firm is Nastel Technologies. We're located in Long Island, New York and we're a software provider of application performance monitoring solutions that do business transaction management and that are for the mid-to-large enterprises. We are installed in a lot of large financial service firms, also in retail, state government, and healthcare.

KB: Today's topic is the role BTP plays in proactive IT management and the importance of putting a transaction monitoring solution in place in order to detect and fix abnormal activities that has the potential to cause cascading high impact failures within the IT system. So Charley, do most enterprises have the visibility they need to rapidly determine exactly where a problem occurred, what to fix, and do it all with minimal business impact?

CR: That's a great question Kaitlin. A lot of firms would answer quite quickly, oh, of course we do; we have lots of tools. What's interesting to note is that is true. Many of them have many tools that overlap. In fact, some of the problem is they have so many and you start to wonder, well, why do they have so many. Well, because they never really address the problem fully so they keep buying more and that ends up being pretty expensive especially not getting the results you want. A lot of the tools are specialist tools for the web farm, app servers, things people use in development. What folks really have not fully implemented and deployed are things that monitor applications and their performance and transactions.

We talk about BTP, business transaction performance, how do I measure that? A lot of the existing tools that firms have from the large systems management vendors, etc. not necessarily integrate it and are very often monitoring the network, servers, virtualization, all important things but very often they leave out one of the key ones and that is how do I measure the performance of my business transactions. How do measure the availability of my applications? So I would say they don't have that visibility they need because they're not getting an end-to-end view that shows what's going in flight, what occurred, and exactly what the state of each application and transaction is.

KB: What does it means to discover transactions and monitor them and what are the challenges?

CR: It's a difficult thing to do. It isn't as if transactions are this thing that are described and it's very clear and all vendors adhere to this; it's more of a concept. Transactions are logical units of work and the way they're implemented are very different for Java, or .NET, or Middleware Messaging, which is WMQ. What the challenges are is in first, is in discovering the applications because transactions are what comprise an application, finding them, finding the transactions, and then observing them without changing them, and looking at the different transitions as they go through Java methods, as they invoke JMS, or create a message, connect up with CICS, etc.

Following those transactions as they transition, if you will, through the different tiers and different parts of your infrastructure is very, very challenging. And then, the important thing is stitching them together because that's how you build a map of transaction topology so you have a view that explains what really happened in your enterprise. A lot of firms build an app, do some testing, it gets out in production and then they discover it doesn't exactly do what we thought it did. And that's an issue that's often quite surprising and not always uncovered in user acceptance testing.

So discovering these logical units of work across different platforms, stitching them together into a meaningful display is what's very, very important. But you have to go a step further because now you've got this understanding of Java, and .NET, and messages, and CICS and all this. But you may not be able to necessarily answer the question when a customer calls and says where's my trade because none of things have anything or say anything to do with a particular trade or trade ID, TID. So you have to go a step further and put a business context around those IT transactions so that you can relate this Java method to a customer's saying where's Trade 0011432, otherwise, you would have a support issue. So the challenges are finding them, stitching them, and then putting them into a context that can be usable and searchable so that you can support your customers when they have issues around those transactions.

KB: Is transaction monitoring enough?

CR: No, it might be provocative because business transaction management is very popular in the web, and the blogs, and a lot of vendors talk about that and it's not enough. It's an important part of the puzzle. The Gardner Group defines transaction profiling as one of the components in application performance monitoring. But if all you're doing is monitoring transaction, then you're seeing at high level what happened but it's really the tip of the iceberg. The real communication that goes on between applications happens at the middleware layer. This could be something like WMQ, WBI, TIPCO, Message Brokers, all those sorts of things.

If you're up just at the Java and .NET level, you miss most of what's going on so your representation of what happened is very much incomplete. Now why does that matter? Well, that visibility you get, this approach here, is used to explain what happened to support an app, to deal with a logic error, to help improve performance, etc. If you're missing most of what happened, then you don't have the visibility what's necessary. You end up as if part of your application went into a black hole. What's going on in the middleware? So I would go so far as to say that without deep middleware introspection, it's impossible to do business transaction management and that has to be beyond the basics.

Folks talk about JMS. Well, that's good but that's just showing you what's going in and going out. If you really want to understand your middleware topology or levels of queues that talk to other queues, etc., you can't see that with JMS. So you really have to go deep native in terms of middleware introspection and then correlate what's going on even within the message package themselves with what's going on at the transaction layer. That will provide what's enough to deliver the visibility to really achieve BTP, business transaction performance.

KB: Can high impact problems be predicted or even prevented?

CR: Yes, they can. And why is that important? Well, it's really important because the longer a problem persists the more it costs, the bigger disruption there is to your business processes, your customers, and the risk you have of a cascading failure. Now, an approach we use at Nastel with our AutoPilot product is to use complex event processing. Complex Event Processing searches for patterns so you can find the early warning. Think of it as an early warning system. You can find the symptoms that show up that a problem's going to occur. Now there may not be a ticket open at the service desk, their users may not be impacted yet, but the symptoms are starting to arrive and this is telling you that you're beginning to veer from business normal to business abnormal.

So what's a good example for that? A good example is with in flight transactions because nothing's failed yet so you have no red lights on. And example might be in a payment system. Its 4:00 p.m., its Friday, you have 40 payments of transactions in flight that have an average duration of ten minutes. Nothing's wrong but you're not going to be able to reconcile the Federal Reserve and that's a big, big issue that has to be done every day. Your company, your bank's in big trouble yet nothing's gone wrong yet so complex event processing as we use it in AutoPilot is searching for those patterns and very often they're with in flight transactions.

So what it does is it understands what normal is for you, something that's constantly changing, how that differs from expectation, and then how that differs from what's actually occurring in flight and this can alert you to deal with an issue before any of the normal alarms have gone off and hopefully avoid a catastrophic issue. So yes, it can be done.

Keep up with what's hot in the world of business and IT integration.

Jayaprakash Kannoth

Jayaprakash Kannoth is Software Engineer at TechTarget. His areas of interest include business process management, enterprise architecture, business intelligence , cloud/infrastructure computing and technology in business.
The opinions expressed herein are my own and do not represent my employer’s views in any way.

Subscribe

 Subscribe in a reader

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT