Issue link: http://cp.revolio.com/i/833286
16 | THE DATA CENTER JOURNAL www.datacenterjournal.com s LAs define what compa- nies can expect from their IT-service providers and, therefore, what they can (normally) count on to help them in turn produce goods or services for their customers. ese agreements also protect providers by clearly specifying what they must do to honor their commit- ments and avoid disputes with customers. But that doesn't mean SLAs are universally adored. Rumors even suggest SLAs are dead (i.e., on the way out). Does that mean companies that work with IT-service providers can expect to say goodbye to these agreements, or are SLAs here to stay? wHat SlaS do Service-level agreements are con- tracts that define the obligations of the provider and, to a lesser extent, the cus- tomer. ey are common throughout the industry. According to Joe Deney, Execu- tive VP of Customer Operations for Peak 10, SLAs typically cover "almost 100% of the services that we provide. Again, that's fairly a common and standard process. e services include but aren't limited to data center uptime, cloud uptime, network latency, and data-protection availability and success." Unlike some contracts, however, SLAs should be clear and understandable to the customer. e danger in contracts for some types of agreements is that words are oen defined strangely, the language is complex and difficult to follow, and the length makes comprehension a chal- lenge (think, for example, of the "terms of service" in a typical soware package). Deney notes, however, that SLAs should be comprehensible. "Our SLA language is very 'common sense' based. It doesn't take a lawyer to analyze and look for 'gotchas.' For example, regarding uptime, the service is working/available or it isn't." He adds that the industry's best interest includes avoiding complex legal language ("legalese"), citing two practical reasons: "First, legalese slows things down during prospect-business negotiations. Second, in our competitive industry, there's a 'race' for higher levels of achievement and common-sense contractual language. Our highly technical industry is moving to 'simplicity.' It's critical for business agility." Naturally, then, SLAs that seem overly complicated or difficult to understand should be a warning sign for customers, as they indicate a provider that's bucking industry trends. Naturally, the fundamental aspect of the SLA relates to whether the customer can access the service. "Some of the most important keywords customers should consider are uptime and availability of the service," said Deney. (Note that these two terms are interchangeable.) "is is absolutely the most crucial element of all of our SLAs. If you're a customer and have a production workload using our services, uptime is crucial or your employees would be unable to do their work." If everything in the world ran smoothly and as expected, contracts would be unnecessary. But in an imper- fect world, even a conscientious service provider can occasionally run into circumstances that lead to a service out- age—particularly since not every aspect of the infrastructure between the provider and the customer is necessarily under the provider's control. What will the pro- vider do, should such a situation occur? Deney notes that the SLA should specify how customers are to be compensated if an SLA breach occurs, and that this compensation is mainly monetary and in accordance with how much the customer is paying for the service. wHat SlaS doN't do An SLA isn't a guarantee that the customer's business or even IT implemen- tations will succeed. It's also no guarantee that the provider will supply the highest service level it can—unless the contract says as much. By its nature, an SLA defines the minimum requirements that a provider (and perhaps customer) must meet to avoid the specified penalties. But there's always someone who wants to declare, rightly or wrongly, that some aspect of IT is dead. SLAs aren't immune. For instance, a CIO article from May 2016 is audaciously titled "Why Service Level Agreements Are Dead." It cited an IT executive who complained that service providers were only meeting the service levels that the SLA specifies. e author even griped that the tendency is for providers to do so at a minimum cost. To be fair, the focus was on an absence of adaptability rather than the absurd idea that service providers are doing something wrong if they only meet their obligations. An SLA—or any contract—is designed precisely not to vary (except as specified in the agreement). at invari- ability is what protects both the customer and the provider from changing expec- tations. SLAs need not be permanent fixtures, though. "SLAs should require an annual review," said Deney. "We want to stay competitive with our industry and, more importantly, meet our customer's needs and requirements. Any SLA that doesn't meet a customer's business requirements is worthless and will need to be modified." He thus identifies the im- portance of providing service that's suited to a customer's business by periodically updating SLAs. Yet within the term of a given agree- ment, a deal is a deal. Faulting one party for "merely" doing what both sides agreed to is absurd. "Within a contractual period, we don't apply changes to SLAs that will reduce or diminish the benefit to the customer," said Deney. If the customer's business necessitates a change, a review of the SLA may be appropriate; that doesn't mean SLAs are dead, however. SLAs also don't guarantee that no system will ever fail. Yet some companies offer 100%-uptime contracts. Deney said, "100%-uptime SLAs are reasonable but are highly dependent on the design of the specific services. All physical components of the IT infrastructure will fail, without exception. e important strategy is to 'design for failure.' If one assumes the physical elements of IT infrastructure won't fail, they won't meet 100% uptime."