The increase in deployment of Java applications means that rules for best practice and management are not so clear, but are still essential to prevent downtime, says Roger Andrews
When something goes wrong, the weapon of choice is blame. But surely the blame game should be something children play and grow out of the day they walk through the school gates for the last time?
The key to avoiding the blame game and solving problems quickly is simple - application management and having an understanding of how the system works. But that is where the real issue is - no one knows where the problems lie and who should solve them.
This has become increasingly clear with the popularity of deploying Java applications. Thanks to Java, businesses have been able to bring applications into production far more easily than in the mainframe environment, allowing them to develop new services and products ahead of their competitors.
Unfortunately, this often leads to problems when the application goes live.
Although pre-production stress and performance testing can clearly go a long way in demonstrating the effects of a workload, when it comes to a live environment it is difficult to predict exactly how new applications will be used and how they will behave.
In addition, Java development is quicker than development in mainframe and other legacy environments. The fact that applications can be rapidly modified and fed back into production means that management best practice is thrown out to be replaced by time to market considerations.
Although mainframe applications have well-developed management structures and theories of best practice, this can be difficult with Java applications.
Java is like a black box where no one really knows what is going on inside. It is often complex, with hundreds of connections to other applications and databases. This means that when something goes wrong, everyone points the finger and blames each other, as they do not know where the fault really lies.
By making use of management technology that is capable of being implemented simply and with no effect on already scarce development resources, problems can be isolated more quickly and escalated to the correct person as soon as they have been identified.
This can be done by the first-line IT support staff who can drill down into the fault and pinpoint the source of the problem. By doing so, only the relevant people have to be called in and the finger-pointing ends.
It also allows recurring problems to be resolved and even prevented, as data about circumstances in the run-up to an incident can be replayed to diagnose the root cause.
For example, there may be a situation that occurs three days before a major failure which can act as an early warning of an impending problem. These predictive symptoms would not have been spotted if the system had not been monitored all the time and the data investigated.
It sounds simple to say that problems can be solved and prevented by proper management and monitoring of applications, but with Java applications deployed over the past five years, there has been little in the way of real application management.
As applications have become increasingly complex and business-critical, it is essential that downtime be kept to a minimum. Companies do not have time for finger-pointing.
If an application goes down, they risk losing customers and, more importantly, as your chief financial officer will point out, money.
Yes the blame should stop. But more important is a combination of technology, expertise and processes that companies put in place for managing Java applications and monitoring how they are performing.
In the same way as you would not fly an aeroplane without an altimeter and the rest of the necessary instrumentation, organisations can no longer afford to run applications without knowing what each one is doing all of the time.
Roger Andrews is vice-president EMEA at enterprise application management specialist Wily Technology
Read more on CW500 and IT leadership skills
Amazon S3 outage: A guide to getting over cloud failures
Implementing a custom user registry to consolidate LDAP servers and active directories?
How to bring mainframe testing into the Agile/DevOps world
Mobile integration a bigger development pain-point than social, security and maintenance combined