Today’s businesses demand extraordinarily complex applications.
A business process may start with a presentation of information on a web page; and allow a user to browse a range of product offerings, creating lists of configured items in a shopping cart, that they may review and change before making a purchase decision. And then the process of purchasing requires collecting personal information along with payment credentials which need to be both secured and validated through a payment processing third-party. Then the items selected must be identified and prepared for shipping, which may entail many other processes to be invoked. Once all of this has been validated a receipt must be prepared and provided to the customer, while all of the financial records must be updated for each department involved. There may even me a need to provide information to regulatory bodies and a third-party logistics provider may be engaged to aggregate all the ordered items into a single location for final consolidation, packing and shipping.
I know I’ve simplified this business process, and the real process will contain thousands of individual steps that any order must go through, with logic to deal with the multitude of different situations that could occur.
What I do know is that many of these steps will happen in parallel, while others must wait for earlier steps to complete, and the final completed order cannot be confirmed until everything has aligned.
With thousands of steps involved in each business transaction, and potentially millions of transactions happening within any time period, keeping track of everything is a very important task.
Most companies use middleware to manage the flow of messages between the individual parts of business transactions, and by using queues of messages the complexity of these processes can be orchestrated.
When things work as planned things can be beautiful, but there are times when things do not go as planned.
With thousands of systems sending millions of messages around a business, there will be many alerts that are not important. These alerts will in-fact be the vast majority and are often called “false-positives”. Only a small fraction of alerts need action. But the issue can be identifying the danger signs in the sea of false-positives.
Many companies rely on application performance monitoring (APM) to measure the time it takes for code to execute, and they may also look at criteria such as memory usage. When the time is longer than expected or the amount of memory being used exceeds a defined threshold, an alert will be issued.
But knowing that a process is taking longer than expected or using more memory than expected, may not provide enough information to truly know if there is issue, and where the issue is.
For example, if application responds with an error message, it may do so very quickly, so no alert is issued. But the fact that the business process responded with an error is another kind of issue, one that is more likely going to cause a problem.
Looking at the contents of messages as well as the time and resource usage that message required is critical.
What is amazing, is that many APM solutions don’t see this as important, relying on system issued metrics of performance and not of the actual transaction being processed.
At Nastel we take a very different approach. We believe what’s important is providing the most detail possible on every step of a business transaction. We monitor every part of the application stack, including the hardware, software, infrastructure and especially the middleware.
We provide a view of every transaction through every component of the system being used. When a step in a business process slows down for any reason, we can show you the impact on every transaction. And we allow the operators of the whole business process a shared view of the potential impact of every situation. This holistic, detailed view of the business in action allows unprecedented command and control.
This level of visibility allows potential problems to be forecast, identified and remediated before users are affected.
While the classic APM thinking is to form a war-room to have everyone discuss and debate the causes of an issue, the Nastel model is to present the root-cause to the whole team and implement changes to the configuration before SLA’s (service level agreements) are breached.
If these issues sound like your business, we’re here to help.
Please contact us today www.nastel.com