Quality of service: Seven steps to success

The only constant in today's world of IT is change. This is true for not only technological advances, but the business demand as well. In the daily battle to push out applications, add new functionality, and rush to fix the glitches of the day, IT managers are often forced to be continuously reacting and constantly putting out performance fires rather than being able to proactively focus on quality of service management. And it's all too easy to lose sight of what this technological infrastructure is all about: delivering the transactions that make the business go.

Attaining exceptional transaction quality of service takes diligence, careful planning, a rock solid architecture, appropriate performance monitoring, and management toolsets, and the right management processes. The Seven Critical Criteria of Success for Transaction Quality of Service below are designed to help IT departments move away from reacting to performance problems, such as over-provisioning resources to attain a higher level of transaction management, to proactively ensure that transactional service levels are met.

1. Transaction focus
When help-desk lines light up, when employees, business partners, and customers report technical problems, they're almost always talking about availability. They're trying to conduct a business transaction. And that transaction capability, whether it be an account query or a financial trade, is either not available or the user is getting too slow a response. It all begins when business units request new functionalities, translated by IT into increased transactional capability.

During application development, developers keenly focus on the transactions that the new or enhanced application will deliver. They’ll detail what the transaction will provide; they’ll test its functionality and performance. But after it’s sent into production, too many organizations lose that critical transaction focus. To effectively assure quality of service, organizations must continue to proactively focus on the transaction, and how it actually maps and performs in the IT infrastructure, throughout production.

That requires continuous feedback in your IT systems. Organizations need to ensure that every bit of architecture used to support the organization’s service level agreement (SLA) is visible from the transaction perspective across development, testing, implementation and production.

2. Accuracy and granularity
To be able to leverage transaction focused visibility--it’s critical that the availability and performance data be both granular and accurate. For exceptional Quality of service, underlying data must be precise, and service profile metrics and control points need to be defined throughout the infrastructure. These are essential to rapidly and proactively deal with issues and to preempt problems before they arise.

This sounds simple, but a granular focus is required because transactions requested from the same systems often are different types of transactions. For instance, a customer who holds many accounts on your system, and is conducting an account inquiry, may create altogether different levels of stress in different ways than an individual with only one account. Simply knowing how many customers are accessing accounts is not enough. Granular insight into who those customers are, and what infrastructure components support those transactions, is what is required. Only then can organizations manage their infrastructure to appropriately support their key customers and make sure their core services get the Quality of service they need.

Accuracy is critical because the entire architecture is meant to support an effective process for managing transaction-level performance, so transaction paths can’t be guessed. Neither can transaction response times.

That’s why it’s important to move away from performance monitoring and management toolsets that provide correlated "guesswork." The architecture must be designed to provide accurate information about where transactions actually move, what IT components they relied upon, and when. Only then, when services might fail, can the angst of having IT managers dash off to fix the least critical problems before the most urgent be alleviated.

3. Business-driven management
With accurate and granular information about transactions and their IT dependencies, the next criterion is to apply business-driven management to analyze and apply business-driven rules to achieve quality of service goals. The key to this criterion is establishing quality of service rules that are driven and defined by business needs, not IT terminology and constraints. Rules that state that IT should be notified when a database query exceeds two seconds are technically-driven rules, not business-driven, and they don’t directly relate to the service. Rule sets need be specific to real business needs, such as when a financial trade transaction exceeds three seconds.

Better yet would be rules stating that order transactions from top-tier clients that exceed one second should trigger corrective action. Business-driven rules ensure not only getting the most from available capacity, but that capacity is first available to the highest priority transactions.

4. In-line business control
Once business-driven rules are in place, they need to be consistently measured and enforced. While reactive alerts when systems fail are a good start, more businesses going forward will be turning to performance management tools that adjust system performance, in real-time, to prevent the most important business transactions from failing. Most solutions today address only half of the picture; they address SLA monitoring, but they don’t address the capability to exercise the IT controls needed to reach quality of service objectives.

To affect the greatest level of environmental optimization, IT controls, like transaction focus, must be business-driven. For instance, optimizing the fuel efficiency of a car about to drive uphill provides a good analogy for the first four criteria. The notion of placing a screw on the throttle of a car to make it consume less gasoline going uphill is a technical control. The business focus of the transaction is fuel efficiency. For this transaction to be successful, it needs accurate and granular data regarding the angle of the hill and how far the screw must be turned for optimal fuel consumption. However, this technical control is of no practical use because the driver would need to stop the automobile, compute the angle of the hill, and know how far to turn the screw—including actually turning it—every time a hill is encountered. That’s why the enforcement of the throttle needs to be in-line if the business goal of optimal fuel conservation is to be reached. The same is true for business technology systems: the enforcement of business-driven IT rules is what is needed to reach transactional quality of service goals.

The first four criteria are the functional criteria for optimizing quality of service. The following three criteria detail the best implementation practices needed for transactional quality of service. Today, despite the best of intentions, too many architectures become too costly and cumbersome to be effectively managed. The next three criteria are just as important as the first four, and they detail how to avoid common quality os service pitfalls.

5. Minimize infrastructure and application change
Deploy quality of service tools that require minimal change to infrastructure and applications. And design and guide existing infrastructure to be as open and standardized as possible. Be wary of tools that are proprietary and limited in their ability to monitor and manage current and future architectures. This forces application and infrastructure change. One of the biggest roadblocks to quality of service is overly stringent application monitoring and control techniques. This is a primary cause of initiatives that both under-perform and go over budget.

The more open and standardized the architecture, the easier it’s going to be to find tools capable of adapting to that environment—and the easier it becomes to integrate new capabilities. Tools that require change are costly. Tools that require all network traffic be rerouted to another point on the network create both added cost and a potential logjam or failure point. Tools that require the configuration of databases to be changed add cost. Having to tweak applications to fit monitoring and management tools doesn’t make sense, and often fails. Experience shows that monitoring and management techniques that require too much change for application development do not last. They are quality of service initiative killers.

6. Managing quality of service despite infrastructure hodgepodge
IT infrastructures today are a mind-bogglingly complex integration of various architectures and legacy mainframes to modern Web service and Service-Oriented Architectures (SOAs). Any transaction is likely to grab data from a mainframe database, require a query from an additional client/server database, and package and return the required information through a Web service object. That’s why it’s so important that quality of service management tools be able to attain visibility throughout the complex borders of multiple generations of technological platforms.

The new IT management paradigm is SOA. And vendors are bringing to market new management solutions designed for managing SOA. Organizations need to be leery of investing in SOA-specific management solutions because they are, by definition, only a partial solution. To do so is to violate the first criterion of transaction focus. Quality of service solutions that focus on a specific environment, whether for IBM, Microsoft, or any other platform, are nearly antiquated. Modern quality of service solutions must help organizations monitor and manage the entire transaction life cycle across mainframes installed in 1984 to SOA deployments underway today.

7. Production efficiencies
When all of the criteria are combined, production efficiencies are what it’s all about. And the monitoring and management must be continuous throughout production.

For that reason, it’s also critical that the quality of service management infrastructure require minimal overhead to operate in production. The challenge here is to be able to look at the infrastructure holistically, even in the face of constant change. This management also needs to be transparent to the application and the infrastructure.

Part of the problem is that the tools, such as debuggers, that are used to get applications production-ready aren’t useful for a transaction-focused approach. While applications live in production, it’s important that management tools collect both the correct information and the right amount of information on their performance. Code-level information for every activity within every system in every part of an environment is not achievable, useful, or relevant. This level of information is paralyzing.

The ability to deliver all of these criteria in a production environment is not kids' play, or something that can be taken for granted. It’s an ongoing management battle, and requires that all of the criteria be consistently met. But by starting with a focus on transactions, defining performance based on business need, and then deploying the quality of service infrastructure to enforce those needs in production throughout the architecture, organizations will find that they can move away from constant firefighting to more proactive transaction quality of service management.

biography
Amir Alon is chief technology officer for OpTier.