IT departments are now pretty good at providing a continuous, reliable service to end-users. This success is due largely to the number of years IT departments have spent measuring, monitoring and managing their set-ups, from both an end-user viewpoint and a technical one.
This activity has usually been enabled by a substantial investment in tools. In addition, servers have often been consolidated and WANs optimised, with consequent cost trimmings. While there is no room for complacency, day-to-day IT operations in many organisations are now a matter for justifiable pride.
Where CIOs are much less happy is with regard to current development projects.
Recent (released in 2004) BMI-TechKnowledge research revealed that in SA, over 80% of companies develop software to fit their company needs. In fact, around half of these companies regard customised software solutions as their primary software acquisition strategy. Despite this, the goal of consistent delivery of software applications on time and to budget remains challenging, and the reasons projects go off track are very often the same old problems that have always beset the IT world: poor planning, unforeseen risks, sub-standard code that has to be re-written and acceptance tests that are failed.
Developing an enterprise-class J2EE application is a complex exercise from both a project management and technical perspective, and there are many pitfalls. Even when development projects manage to avoid these pitfalls, deployment of new applications in today`s complex, highly interdependent computing environment can have an unforeseen impact on infrastructure. Expensive upgrades may then be necessary in order to achieve the desired performance without deterioration of existing services.
Today, many organisations are writing new applications - especially their most sophisticated ones - in J2EE. There are many sound reasons for this choice: rigorous processes exist for J2EE applications deployment - a big advantage if they are destined for many thousands of users; being `platform-agnostic`, they can be scaled to accommodate an even larger user population later on in the application`s life-cycle; they lend themselves well to integration with legacy systems; they can be built and deployed to satisfy today`s security requirements more than adequately.
In addition, J2EE addresses some of the problems that traditionally contribute to project overruns. For example, improved levels of code quality, consistency and productivity can be achieved through the use of pattern-based development `best practices`, at both design and coding level.
However, despite its many important advantages, adoption of J2EE can potentially increase business risk. Organisations rarely have the skills and experience that are needed to manage new J2EE applications once deployed into production, and so they have to bridge the gap in the short-term through relying on extended support from their application development specialists, while they engage in re-skilling of IT operations staff.
Other risks arise not so much from the technology as from the enterprise-wide nature of the applications under development. These often very large systems need to integrate harmoniously with existing applications and infrastructures. If they compromise the organisation`s carefully-tuned production environment, the result can be either failure of a high-profile project or, even worse, disruption of the systems that have been reliably sustaining `business as usual`.
There are several ways in which a new J2EE application can undermine the performance of existing systems, but many of them can be traced to a small set of issues. The first is failure to anticipate the amount of computing power that will be needed, either within the associated application server or by other integrated systems. A second hazard is underestimating the amount of network capacity that the new application will require. Finally, many organisations either fail to test the right blend of planned production load, or neglect to do so with the thoroughness and accuracy necessary to uncover application resource and scalability issues.
If, for any of these reasons, a newly deployed application consumes more than its fair share of resources, something has to give - and that something may well be an established system.
It may be possible to rectify the situation by adding more WAN bandwidth, or by upgrading server or desktop machines. However, these unbudgeted costs could undermine the original case for the new application. One client saw its WAN costs - already over lb50 million per annum - unexpectedly escalate by 15% in a single year, owing to new bandwidth-hungry applications. And that was in the UK, where bandwidth is considerably less expensive than in SA.
To ensure new J2EE applications (or, indeed, any new enterprise applications) are deployed smoothly, it is imperative to obtain insight into the application and particularly into its back-end. Until now, the Java machine has tended to be perceived as a black box, yet it is only by obtaining visibility of the detailed workings of the software that deployment problems can be pre-empted. For example, if you can identify the Java methods that are called most frequently, you can focus tuning effort where it will deliver most benefit. The tuning process itself can be made much easier by the collection of `forensic`, or low-level, data about performance.
The best time to get visibility of the workings of the application is well ahead of deployment, while there is still an opportunity to take corrective action. With the latest monitoring tools, load testing can provide an ideal opportunity. If the application fails to deliver the targeted performance, appropriate tools can help you to construct a detailed explanation, for example, they can provide a trace of all the methods that were being called when the problem occurred. Obviously however, it is important to choose tools that can record what is happening without impacting on performance.
If production issues are addressed well before the application is due to go live, it becomes possible to make decisions that will ensure smooth implementation. Some of these may involve adjustments to the infrastructure, but if those adjustments are identified in good time, they can be budgeted for. In other cases it may be possible to avoid the need for upgrades by making appropriate changes to the application code, for example, by tuning frequently invoked methods that are found to be under-performing.
Perhaps the biggest benefit of adopting the right pre-production tactics on J2EE projects is that these preparations tell the organisation exactly what effect the new application is going to have on the status quo. Armed with this information, executives can make the right decision about whether and when the application should go live. In fact, astute organisations have built into their `quality gates` a requirement to demonstrate, before a new application is deployed, that it is not only functional but also tuned to run optimally in the organisation`s actual production environment.
The same approach that has given early warning of problems can profitably be carried through into production. By continuously monitoring the black box - still with negligible performance overhead - suitable tools can provide the operations team with early warning of impending problems, together with detailed supporting information. In this way, performance issues can be resolved with maximum speed and minimum risk, often before users even notice that there is a problem.
Granted, the planning and preparation will cost money, but not nearly as much as it will save. When organisations spend so much on managing their IT operations, doesn`t it make sense to devote a little of the same care to the new applications in the pipeline?
Share