Business Resiliency

Key Steps to Creating a Winning SLA

David Edborg By David Edborg Portfolio Manager, Business Resiliency January 20, 2015

This is the fourth blog in a series supporting EMC’s Business Resiliency eBookUse the menu to the right to explore the rest of the series. 

Whether I like it or not, I am a child of science and, to a fault, it’s guided my thinking in more ways than I care to even articulate.  So, when I say corporate IT will go the way of the dodo bird in the very near future, I’m not saying it because I see some crazy change to IT, as IT isn’t going to drastically change in the near term.  The economics, however, are and will continue to change extremely rapidly.  Before you challenge me, answer one question: if you have problems with your existing television, do you buy a new one or have the old one fixed?

Yes, commoditization, mass consumption and the utility function make for some crazy business models.  For corporate America and the IT function, those models are increasingly looking like a service broker model for virtually everything IT.  This leaves me asking:  If IT is starting to look like a utility and can be delivered like a utility, then maybe it is a utility?

busresiliency1For anyone who’s dealt with a utility provider, the relationship is always predicated on some ongoing expectation of service fulfillment.  The parameters of the relationship are spelled out in the service contract and the two parties reference that contract as the basis for meeting their respective obligations. This arrangement, in overly simplified terms, is a Service Level Agreement (SLA), which is one of the better ways to manage a utility-based, exchange of services, relationship.  SLA’s, in practice, are designed to define and manage the productivity and service quality associated with IT outsourcing arrangements.  They establish the expectations of the parties, set operating parameters and define the success requirements (measures) of the relationship.  Good SLA’s help drive the parties in meeting business and technology service fulfillment levels.  Legal mumbo jumbo aside, the SLA represents the primary means of managing the future IT service brokerage model.  It’s also, shockingly, a vehicle that is not well managed by many who currently rely on it.  In fact, it’s the basis for lots of confusion regarding service fulfillment obligations and we’re going to use this entry to sort some of that out.

Requirements / Performance Measures

The over-arching objective of the SLA is to bring accountability to vendor-client relationships, so there needs to be a healthy focus on making sure the T’s & C’s crisply and simply define the success requirements in the relationship, including measuring the status of the overall effort and quantifying the effectiveness of the performance of the vendor using easily understood metrics.  At a granular level, the SLA needs to identify, define and establish a mechanism for the ongoing management of critical base-level performance definitions – including line-item costs, productivity indictors, skill and capacity measures, and service quality fulfillment.  As a business agreement, the SLA should also address a range of business processes that are important to the ongoing relationship, but should be founded on operational and technology expertise that is seen in the actual performance of the vendor.  In simple terms, did they meet the metrics that were agreed to in the SLA?  Did the vendor meet capacity demands during peak periods?

it’s important to note that the SLA memorializes the objectives of the business arrangement and, by extension, it needs to define not just how success is measured, but how the specific activities that are critical part of the exchange are executed.

SLA Structure

The structure of the SLA is developed through a multi-step process engaging both sides to the agreement.  Structure is always driven by the need to identify, define and manage ongoing business objectives between the vendor and client, so collaboration is critical in the effort to assess the existing applications, initiatives, processes, and service level fulfillment requirements.  The structure will also drive the strategy and the means that will be utilized to achieve said strategy, so It should support the detailed view of the given resource / capacity requirements associated with the effort.  In practice, the structure of the SLA tends to act as the means of outlining / organizing the cost / benefit tradeoffs that are followed via the life of the relationship as defined in that specific agreement.  In simple terms, the structure should act as a functional roadmap for the entirety of the relationship.  The end objective, especially when considering the structure, is that business objectives have been identified, defined, agreed to and a method for managing issues has been established.  Most importantly, there must be a clear and easily understood means of repeating the processes and achievement of milestones.  It’s important to note that the SLA memorializes the objectives of the business arrangement and, by extension, it needs to define not just how success is measured, but how the specific activities that are critical part of the exchange are executed.  In other words, the structure should tell both parties how to behave in an ongoing form.

Get The A-Team

The structure, measures and parameters for the operation of the SLA are all well and good until they’re put into production and we move from what we “say” to what we “do.”  Since what we do is ALWAYS about people, begin with the end in mind – identify and field a team that both develops the SLA AND manages it going forward. The team should have true cross-functional representation (legal, finance, HR, IT, business unit leaders) and should form a cohesive structure that drives the governance of the effort going forward.  Additionally, it  should be composed of resources from both parties to the agreement and should have clear incentive in assuring that the relationship fulfills the performance requirements defined therein.  Finally, the team should also be the source of committee members that serve on the monitoring & maintenance, performance reporting and dispute resolution committees.

Like any good business relationship, SLA based-relationships require constant discussion, management, tweaking and renegotiation as the needs of the businesses change.


After all the relevant parties have signed off on the SLA, the format, structure, and frequency of reporting should be complete.  The provider then recommends methodology for the automation of data capture and reporting.  There should be an established output / performance reporting format and a regular process to review and react to it.  The process should identify both where the terms of the SLA are and are not achieved.  Next it  establishes reasons, root cause analysis (where appropriate) and recommend corrective measures and then should report the results back to a designated committee from the A-Team for improvements.

Ongoing SLA Management

Like any good business relationship, SLA based-relationships require constant discussion, management, tweaking and renegotiation as the needs of the businesses change.  Without ongoing management, SLA’s tend to provide the users with a false sense of security about the level(s), type(s) and quality of service being provided and, more often than not, become the source of heavily contested debate when something goes wrong (and, YES, something ALWAYS goes wrong).  There’s a bunch of examples of unmanaged SLA’s acting as the source of serious business problems for both parties when left ineffectively managed.  Rather than recap the examples, the point needs to be driven home – the effectiveness of an SLA is only as good as the ongoing attention it gets by the parties to the agreement.  Remember, it’s the agreement that the two parties will reference to explain all the details associated with a specific part of both parties businesses, don’t view it as a one-dimensional legal contract.

Enabling Tools and Odds and Ends

busresiliency2Using tools to enable an efficient measuring and reporting process will reduce cost and the probability of errors and conflicts.  With enabling tools and techniques, the SLA management processes should be used to ensure clear communication throughout the entire relationship.  The ability to efficiently and effectively address service level issues is accomplished via:

    • Clearly defined ownership and responsibilities of all resources
    • Establishing ultimate accountability and naming executives and management
    • Detailing all definitions and quantifiable commitments
    • Detailed documentation of escalation procedures
    • Stand-up and ongoing program and project management requirements
    • Regularly scheduled and ad hoc communication requirements

Once the relationship is established and the effort begins, monthly activity reviews and quarterly performance review meetings should be conducted between the parties to review the extent to which the effort is adequately resourced, levels of effort are appropriate and the mix of future activities will meet requirements.  During this stage of the effort, both parties need to consider:

    • If the activities related to workload priorities is appropriate
    • The extent to which there are opportunities to improve the exchange
    • The collection, analysis and reporting of all the measurable performance requirements in the contract
    • The adjustments that, if made, would result in a notable or material improvement in the relationship

For those that believe that a vehicle like an SLA should deliver binary outcomes for the respective parties, you should not be a part of this effort.  In fact, you shouldn’t be allowed anywhere near it.  There should never be “winners” and “losers” in these arrangements.  The best SLA’s, without exception, are the agreements that both parties achieve they’re objectives with.  To that end, the above guidelines are intended to help achieve that objective.

David Edborg

About David Edborg

Portfolio Manager, Business Resiliency

David originally joined EMC (now Dell EMC) in 2005 and is currently the Portfolio Manager for Dell EMC Business Resiliency Services. Over his career at Dell EMC, David has served as a Global Practice Manager for Availability Technologies, as an Availability Services Solutions Principal, and as the Chief Architect for EMC’s Continuous Availability Services Line.

David has over thirty years in the computer security and disaster recovery industries. Out of college David worked as an IBM Assembler coder and wrote operating system mods for ACF2/VM; the first ever security product for IBM’s Virtual Machine OS. He has worked with other vendors and partners in the DR industry, including supporting recoveries from the 9/11 event. David has also worked in the packaged software industry as Director of Development and Support for a computer security product.

Read More

Share this Story
Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

Your email address will not be published. Required fields are marked *