GRC
HR
SCM
CRM
BI


Article

 

Align Your SLAs with Your Business Processes

by Evan J. Albright

August 11, 2009

Is the service-level agreement (SLA) worth anything after the ink dries? Its ultimate objective is to improve efficiency, eliminate waste, and promote accountability. But how do you create an SLA built around business processes, instead of a single system? Explore the world of the SLA and learn how to bring it up-to-date.
 

The demarcation line between IT and its customers is portrayed by the service-level agreement (SLA). It spells out what the business expects from technology and what IT says it can deliver. This is a contract, drawn in the blood of business transactions, that is typically outdated as soon as the ink dries.

In this brave, new world of enterprise applications, SLAs take on a whole new importance, and a whole new set of complexities. Applications once the realm of business analysts now extend from the executive suite to the shop floor; projects that once took years to implement are now done in weeks; and databases, once restricted to a very few employees, are now available outside the firewall, to partners and vendors. While these technical obstacles are solvable, the institutional obstacles may prove to be more than an organization can handle.

In big companies, those responsible for SAP systems often operate separately from the rest of IT — sometimes even in their own department. In an enterprise service-oriented architecture (SOA) environment, those artificial barriers must be broken down, as IT systems are made available throughout the company and to partners, customers, and suppliers. The tipping point is the SLA.

In this contract, a customer provides IT with its requirements, and IT, in turn, establishes how it will provide that level of service using metrics based on performance, security, and uptime. The SLA usually contains some promise as to how soon service outages will be restored. Any gap between what the business needs and what IT is able to provide within the constraints of its staffing, budget, and capital infrastructure, is escalated to management for resolution. The SLA usually contains language about how the business and IT will communicate or escalate issues and resolutions.

 

Lies, Damned Lies, and Statistics

Not long ago, when SAP R/3 was a self-contained system with a self-contained user base, an SLA was a relatively straightforward affair, promising a certain level of uptime, responsiveness, and time to restore. With the advent of SAP NetWeaver and Enterprise SOA, the playing field has simultaneously broadened and widened. In the past IT was responsible for a back-office system, but in an enterprise SOA world IT is responsible for an entire business process. SLAs need to reflect that change, and the old model of promising performance based upon on a specific system is no longer satisfactory (see "The History of SLAs," below). Why?

The History of SLAs

SLAs evolved some 20 years ago purely as a measure of performance within a specific system. “SLA is a very abused term,” says David Reichman, vice president of products, business solutions for Mercury, which develops software to monitor enterprise systems. “In the beginning it was used by systems-management guys, who took all these CPU measurements, put them into a spreadsheet, and presented them to management as their SLA. We found nobody is using that.”

In the early part of this decade, there was a renewed interest among IT professionals in SLAs, a movement that coincided with an interest in the “balanced scorecard” for business. For IT, however, the SLA became an exercise in survival and with it came a degree of self-preservation. After Y2K, IT departments, under fire from the business for failing to deliver and facing ever-shrinking budgets, developed a series of metrics to demonstrate value and performance. These metrics are the basis of SLAs today.

SLAs of old came with a dirty little secret. An IT department was never as good as it said it was. Mercury Interactive Corporation uses the graphic below to demonstrate the comparison between perceived SLA compliance and actual performance. For a typical IT organization it shows the various systems employed by a single business process, for example, claims processing: IBM MVS, Unix, Microsoft Windows NT, a network, middleware, the Web, and one or more databases.

IT operations not aligned with the business

Each of these systems has an SLA that promises 99 percent uptime, one that according to the graphic is met — individually. However, when you gather the performance numbers of all these systems together as they interconnect for the claims-processing business process, the actual uptime over the course of the reporting period is much different.

While the IT organization can boast about meeting its service levels on each of these systems, from the customer’s perspective the actual service level is a dismal 82 percent. In other words, when the customer pressed Enter, almost one time in five the system did not work. (The graphic above uses only those systems internal to a company, but today, some systems may be outside the company, at a partner’s or an outsource provider’s location.)

Overcoming the Technical Hurdles

Other factors in an enterprise SOA make the technical challenges of monitoring SLAs even more difficult:

  • SLAs no longer just measure systems; they measure business processes and more, requiring a level of granularity that was unnecessary in the past. “Your monitoring tool needs to be able to monitor individual transactions, background tasks, dialup tasks, NQ tasks, update tasks, and so on, and build upon them,” says Roberto Brunel, product manager of application management solutions at BMC Software, a monitoring-tools vendor.

  • Wider and wider audiences use applications and tools, both inside and outside the organization. “The mere presence of an SAP NetWeaver application means that end-user touches will increase dramatically,” says chief technology officer Ernst Ambichl of Segue Software, now part of Borland Software.

  • Change management becomes more crucial: A change to the system in one place may affect performance in another. Therefore, change management requires a monitoring system that troubleshoots based on the changes made to the system.

  • Root-causal analysis across multiple systems, applications, and databases becomes more difficult.

  • User interfaces are becoming more diverse: There is no longer only one GUI with which to access an SAP system. Users can now use mobile devices, browsers in remote locations, and more, each of which presents its own obstacles. “Look at Duet, which integrates SAP components into the email system,” says Segue’s Ambichl. “It becomes even more important to check for components being available.”

While the technical challenges may seem more imposing, technology has more than kept up with the enterprise SOA revolution. SAP has provided a basic tool to monitor and manage SLAs across an enterprise; that tool is SAP Solution Manager.

SAP Solution Manager

The technology exists to monitor systems on the business-transaction level. SAP Solution Manager, combined with third-party tools, can slice and dice your technology landscape however you want it, aligning service-level monitoring by business process, system, or interface (see the timeline, below).

Timeline for the use of SAP Solution Manager

Using SAP Solution Manager, a company can select the business processes at greatest risk, separate them into their individual components, and monitor them continuously. Should one or more of the components threaten a service-level requirement, SAP Solution Manager can send escalation alerts and even recommend mitigating steps to be taken to prevent disrupting the business process. SAP Solution Manager also provides tools to effectively perform root-causal analysis when problems crop up.

With SAP Solution Manager and a wide assortment of third-party solutions, the technological ability exists to monitor your landscape. The question is, do you want to?

Organizational Challenges

While the challenge of monitoring diverse systems is one that technology can overcome, it is not so easy to craft an agreement between IT and its customers promising a particular level of service. Mercury, for example, offers a wide variety of tools that work with SAP Solution Manager to enable customers to monitor their systems down to the individual transaction, across diverse systems.

But once the source of the issue is identified, it needs to be resolved, and that’s where it becomes sticky. “How can we facilitate a discussion that nobody wants to have?” asks Mercury’s Reichman. “I’ve seen so many customers stuck in their [data] silos,” Reichman continues. “They don’t even have the communication channels to the business. For a successful organization, we define a 10-step approach, because you can’t change an organization in one day. If you don’t align with the business, you’ll never have a successful SLA.”

Who Is Responsible?

Third-party vendors and SAP agree that SLAs must be approached from the customer’s viewpoint. What makes this particularly challenging is that the customer doesn’t know that while the office may be in New York, the application servers could be in New Jersey, the databases outsourced in Texas, and the Internet services provider in India. All the customer knows is that the SAP system doesn’t work, and the SLA calls for 99 percent uptime.

“We had one customer who outsourced a system, and they put an SLA into the contract with the outsourcer,” says Mercury’s Reichman. “Every month the outsourcer sent a report with exactly the same uptime according to what appeared in the contract.” Mercury was called in to provide monitoring from the customer side, but ended up brokering a deal between the two parties to ensure the letter of the SLA was being monitored and observed. It’s not a role Reichman says he finds comfortable. “We don’t want to be cops, we want to be advisers,” he says.

All the monitoring tools in the world will not ensure that an SLA is met. You don’t want the only people truly committed to meeting an SLA to be the individuals who signed the contract. Despite the tools and technology of today, there is no shortage of passing the buck. “It takes commitment, starting at the top,” according to Reichman.

The Evolution of Tomorrow

The pressure upon an organization’s structure will only increase in the future. And today’s SLA will be forced to further evolve.

Faster development: SAP is promising a world of faster development and innovation. SAP is also looking at creating more collaborative cross applications (xApps), applications that cross multiple systems. An SLA becomes outdated the moment the ink dries. The negotiation process will become too cumbersome for an organization, particularly as applications cross multiple systems with multiple layers of responsibility. In addition, many organizations swap management teams as often as seasonal wardrobes, and the need for quick, efficient, SLA negotiation and approval becomes not only critical, but also essential.

The solution may be to come up with a standardized SLA, such as a guarantee of “99 percent uptime,” and put it into the requirements gathered for all applications. Or, make sure that the SLA is determined before one line of code is written.

Expanding measurement to the business: With many SLAs there has been an expectation of the end user to keep up that part of the bargain. But this has been limited to users agreeing to maintain their equipment by, for example, keeping virus protection up-to-date or performing updates. Users also agree not to download executable files or perform other dangerous activities.

But turnabout is fair play. The same technology used to measure technology’s response to SLAs can be used to measure how well the business is actually using the technology. Imagine the following scenario: An internal customer of IT believes that he or she can increase lead generation by 25 percent with a particular new tool. The IT organization runs the numbers, and determines that it can implement such a tool at a specific cost. Once the ROI is figured, the tool will show a net gain. Finance approves the expenditure, and IT implements it. During quality assurance, IT deconstructs the business process served by the tool and identifies the response times determined by the requirements. IT builds the perfect solution, the business signs off on it, and it is rolled out.

Imagine that during development, IT not only measures response times between applications and servers and across networks, but it also measures the amount of time a user needs to work an application. That way, it can measure a business process from beginning to end, say, from the time an external customer places an order on a Web site to when the product is delivered, and can generate a report on all intervals between the various actions.

“Passive monitoring — that’s a really challenging new question. How can we measure service levels on a higher level, on a business-process level, to include the business’s use of the tool,” says Segue’s Ambichl. In such a world, IT would not only measure the performance of its own systems, but also the performance of the customers using the tools. These results could be combined with data in mySAP ERP to determine whether the promised ROI is realized.

Measure Twice, Cut Once

“If you can’t measure it, you can’t fix it,” or so the axiom goes. The technology to measure an IT system, even complex SOA systems such as SAP NetWeaver’s Enterprise SOA platform and tools, is available and will only get better and more precise in the future. But just because you can measure it doesn’t mean you can change it.

The eventual objective of SLAs and other evaluation tools is a noble one: to improve efficiency, eliminate waste, and promote accountability. SLAs today need to be built around business processes, and in an SAP NetWeaver world, this means extensive coordination, often with resources from another department, another time zone, and possibly even another company. For an SLA to be effective, all parties involved must be committed to meeting it. The technology is there to identify the problems; it falls to the particular organization and the people behind it to make the SLA meaningful.

The demarcation line between IT and its customers is portrayed by the service-level agreement (SLA). It spells out what the business expects from technology and what IT says it can deliver. This is a contract, drawn in the blood of business transactions, that is typically outdated as soon as the ink dries.

In this brave, new world of enterprise applications, SLAs take on a whole new importance, and a whole new set of complexities. Applications once the realm of business analysts now extend from the executive suite to the shop floor; projects that once took years to implement are now done in weeks; and databases, once restricted to a very few employees, are now available outside the firewall, to partners and vendors. While these technical obstacles are solvable, the institutional obstacles may prove to be more than an organization can handle.

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ