|
Published date: 11 Feb 2008
The Mainstream -- February 2008 -- Issue 28
By John Knutson, System z Product Marketing Manager, Application and Integration Middleware Software
 Performance engineering is a critical part of any IT operational and development process. Even in these days of Service Oriented Architecture (SOA), when so much is designed to mask complexity and speed up development, performance analysis plays just as vital a role. This article explores how IT processes need to evolve to meet modern business demands, and the impact that shift has on the enterprise view of performance.
The forces of change
Two opposing pressures are bearing down on the modern enterprise. First, there is the need to do more to support business growth, whether it’s delivering more business applications, selling more product or producing more marketing collateral. The second pressure is financial, from those who ensure that the business is profitable and without cost overruns. So the business needs to grow in new markets, and the financial officer says “reduce cost.” This gives IT more to do and fewer resources with which to do it. Previously, the only thing that could give way under these conditions was quality – meaning less testing of performance, capacity planning – leaving IT with the hope that the system would meet business needs.
Now, a third pressure is present in the form of governance and compliance requirements. Some of these are defined by industry groups and national governments, such as Sarbanes-Oxley in the U.S., HIPAA regulations, the Basel II regulations for banking and finance. On top of that are the rules that grew out of compliance fears that are increasingly laid down within a business, and within departments to ensure that everything is working well. It’s no longer possible to simply not perform a task, or do it with lowered quality standards. You have to do it well, or you risk severe penalties.
There is another consideration as well: IT skills. While most financial services businesses and commerce relies on System z processing, a relatively small number of people work in System z, compared with those working outside of it. The skills are not as widely available as they were 10 or 20 years ago when System z, or MVS, was the dominant operating system and mainframes were the only major computing platform. Today, not only do you have to do more, because you have to build things like SOA and Web services applications around System z, you likely have fewer resources, and the resources available may not have the same depth or experience that you once had, because older workers are retiring. IBM is working with universities in an innovative academic initiative to promote the System z curriculum, and new graduates are already moving into the workforce. But proportionate to other technologies, the skill is shrinking.
If you continue doing the same thing, you’ll get the same results
If IT needs to do more with less financial resources, with fewer skilled people, and adhere to compliance and governance regulations … what is the path forward? How do we move beyond these challenges?
To achieve a different outcome, you’ve got to do something different. In IT, that means moving away from IT being a craft industry where everybody creates their own rules, processes and holds the knowledge individually. This worked well enough in the past, but it’s not going to work well in the future. Today, the enterprise requires an agreed upon, formal process, ideally defined by some external body. One such process is the IT Infrastructure Library (ITIL), which originated with many industry experts, including IBM Global Services. These experts have worked to define IT service management, which IBM takes a step further as the IBM Service Management approach.
The purpose of Service Management is to make sure that every staff member is doing the right thing, that people know what to produce and when, and that new staff can tap into the process and understand what needs to be done. It lets staff know who to work with, and who needs their input and output.
Having a set of processes helps both the operations and the development side of IT. The Rational Unified Process is a good example of a process that gathers requirements through development, and testing to deployment. It includes a handover from the Rational Unified Process and the ITIL service management process. This frees IT because it creates something that can be used again and again as a repeatable process. It also addresses compliance regulations around being able to demonstrate that you are following a process.
The elements of a good process
Service Management is about making things happen. Governance is about making sure that the right things happen, and that the right people decide what that should be. Governance creates a hierarchy within the enterprise and outside of the enterprise, through the different compliance or governance regulations that are applied along the way. It prevents anyone from backing out, or circumventing the process.
IBM and Tivoli have enriched the ITIL guidelines with IBM Global Services expertise and experience working with customers over the years, documenting the processes, user roles, deliverables and tools in a freely downloadable tool - IBM Tivoli Unified Process or ITUP - that enables customers to take ITIL from theory to practice. Key parts of these processes have been encapsulated in workflow in the form of IBM process manager products for release management, change management, and performance and capacity management.
The IBM capacity management process provides the overall generic guidance as to how customers should manage their IT organizations or manage capacity planning. It also provides a set of tools, workflows and standard forms so the process is ready to use immediately.
Tools are important in taking some of the burden off the user. The process manager defines what should be done at a certain point in time, identifies the key applications, monitoring them and collecting important data from them, as well as the timeframe for doing this, and tracking that it has done. The process manager provides templates and forms so that IT has a structure in place for pulling its data into the process manager. The tools collect the data and store it, and the process manager helps the customer make the right inferences from the data.
Taking a broader view of application performance
Every development team recognizes that occasionally applications don’t perform well and performance diagnostics must be run on them, usually using monitoring and analysis tools. What is less common is an understanding that the sooner you do performance evaluation in the application lifecycle – and get rid of the defects – the better. It has been estimated that at the design stage, defects can be anywhere from 10 to 1,000 times less expensive to fix than they are when the application is built. The costs are even greater once an application has been deployed. This applies as much to performance issues as it does to functional defects, or other errors.
In one way, SOA makes it easier to stumble over performance problems. Let’s say someone builds a service for a local department to perform a function 50 times an hour. Someone else decides to use this functionality for a new service, but this time, it’s for a worldwide sales online order entry system that is being opened to customers. Suddenly, something that was designed for one set of use cases and one set of performance requirements is being reused through SOA for something vastly different.
If the necessary performance engineering is not done to evaluate performance, such as load testing for the new scale of use, it could spell disaster. Imagine that hundreds of thousands of users are trying to use it 1,000 a times a second rather than 50 times an hour. It wasn’t designed to perform at that level.
One common performance problem is due to the frequency of calling a particular service. For example, if you have a service where you can pass in a multi-record request saying “process the 1000 records,” normally that’s going to perform a lot faster than processing one record at a time, 1000 times. Let’s take the automobile, for example. If you’re trying to price in an automobile by requesting all of the parts and feature, one at a time, you’re making hundreds of thousands of requests, and each one has overhead. Part of managing the performance of these calls is minimizing the overhead.
There are other important performance decisions to be made. A development or an architectural best practice might advise you to do one thing, but performance best practices advise you to do something else. By following performance, you might end up with a solution that isn’t quite as elegant or as architecturally abstract as the architects want it to be. But you sometimes have to take a different route so that it performs well. And keep in mind that if it doesn’t perform, it’s never truly elegant.
So SOA can make it harder to manage performance because it’s easier to deploy applications that don’t perform. In the rush to meet deadlines, the functional aspect of the quality of an application may be the only criterion considered.
Performance and application transformation
Application transformation refers to the reuse of older, legacy applications, typically written for use by internal employees using 3270 displays and emulators. Over the years, or, in some cases even decades, it may have been enhanced with an interface for business partners, or other users who understood its complexities. But it also includes many inconsistencies, and because it’s valuable to the business, it must be transformed. Sometimes that means taking low-level code, extracting it and wrapping it as a discrete Web service. Sometimes, in order to create something that delivers a “service,” it requires pieces of several types of its transactions. Using a product such as the IBM Host Application Transformation Server (HATS), or the Service Flow Feature built into CICS 3.2, IT can develop a script for what’s needed. The script is then wrappered with either a Web page or a Web service. The Web service is presented as a simplified, unified way of getting at that business function. It may be updating several files or several databases possibly using different transaction types, or even bringing in transactions from different suites. Its value is that it performs a specific business service that can be made available to customers.
The original application has been refactored, but it still requires performance engineering. Having done the necessary performance analysis to ensure that these internal bits of code perform well individually, when linked together in this broader view … are they going to perform as expected?
Is the entire script working as planned? Will performance service levels be met?
Conclusion
When you change something that used to work well, even if you have not changed the underlying code, you need to consider performance - it’s a key ingredient of Service Management. If you changed the way the code is used, the volume of users and their patterns of use, it will impact performance. It goes back to the idea of outcomes: The only time you can do things the way you used to, is if you’re happy with the previous outcome.
Most of the changes described in this article are driven by the business, which makes strategic investment decisions as to what it wants to do. If you don’t ensure the performance of this investment, and validate performance early in the lifecycle, the omission can have a much more devastating and far-reaching impact than it would have had in the past, simply because of the use of Web services and reusable components. It’s a risk of unknown proportions that is not worth taking.
|
|
|
