DevOps certainly looks like being the next `big thing’, but it does come with dangers. An important one is the potential for businesses to stall because some minor error in a complex environment of collaborating applications is preventing the normal flow of business. Quick ways of identifying the applications causing those errors, and what type of errors are in play, will therefore be essential. This is one of the roles that nJAMS can now provide to busy IT departments.

One in three user businesses we work with have reported to us that they have suffered exactly this type of scenario. They tell us that they have burned their hands in the past by improper deployment of new business logic which has then broken the system. Their big issue is that it has taken them time, maybe a week, to figure out what has happened before they could even start on trying to fix it. This can mean they may even have lost several days of the ability to trade at all.

Growing complexity, speedy deployments

As the complexities of full-on DevOps environments start to become the mainstream option, the ability to identify a problem, the application causing it and its operational impact, in near-to-real time, is likely to play a major role in keeping the wheels of business turning. And in environments where many small application components may be deployed increasingly fast – some US online services vendors claim to hit rates of over 300 deployments a day – ensuring that they all have the outcome they were designed to provide is currently a long-winded process.

And if the only indication of a problem is that the KPI dashboard indicates that a sector of the business – for the sake of argument, `Sales’ – is now diving into the red, then tracking down the cause becomes a major imperative. By that time, real damage could already have been done to the business.

Know your processes – before and after new deployments

nJAMS is Integration Matters' answer to Business Activity Monitoring in the world of process management. It provides tools that can be deployed to monitor specific applications and services, rather than the traditional approach requiring a complete, end-to-end deployment of a `total’ monitoring solution. It allows users to build reports that show the ripple-down effect of code deployment issues, because they can identify exactly when the sub-process has been updated and what are the performance changes after that.

Most management tools will tell you how you got to the point of deployment, or what the release cycle was. But they cannot tell you anything about how the process worked both before and after the deployment.

Tell me when the problem occurred, and I tell you why

The nJAMS technology provides IT management and DevOps teams with a range of monitoring services that sets process performance and deployed sub-processes against a timeline. That way, it becomes possible to track the impact of any code problem, which shows itself via a change in the performance of the application or sub-process.

Knowing what application components are part of a sub-process or service, at any point in time, is crucial, and can have dangers if the administration gets even the slightest bit out of step. So what nJAMS does is mark the deployment of every piece of business logic on the time-line which can then be compared with the other performance indicators generated by nJAMS.

Resolve the issue before it hurts your business

It captures the content of all messages flowing between applications to the database of events and timings allowing a chain of events for each process to be built up. That way, failing processes and the applications running them can be quickly identified at the time the problem emerges. Remedial action can then be started as soon as possible, with the knowledge that it is `this’ application demonstrating `that’ problem.

This gets round the issue of most other monitoring systems taking time to detect that there are performance issues to resolve. The danger with DevOps is that other applications and components, some of which may even interact with the suspect deployment, can be deployed before most systems are able to observe and indicate that there is a problem.

That is when the IT teams will have the job of unravelling several deployments at the same time in order to find the culprit. 

Get the whole picture – here and now

nJAMS also has a `backwards’ capability where it can find those old, undocumented patches in legacy applications that were created by Ops Teams – often urgently – when applications stopped running for whatever reason. These got the applications working again at the time, but can subsequently cause real problems with later updates or API-linked collaborations with other applications, and be very difficult to find.

These are a good example of the `nobody knew’ problem, as the patches are often undocumented, and the operator that wrote them has often moved on. It also versions the applications that are running at any point in time, since it is not uncommon for different versions of the same application to run different aspects of a process, and it can be important to know that this is happening.

In order to build up a comprehensive picture of the processes, nJAMS allows users to classify processes, for example as a new use case or as a variation of an existing use case. It is also possible to identify all the processes involved in what a user might consider a single process, as many of them are made up of many smaller sub-processes.

About the Author: Hendrik Siegeln is co-founder and Managing Director of Integration Matters.

X