Promises are not enough when doing business in the Cloud!
Get started with SLALOM practical, understandable, and safe and fair Cloud SLA Baseline Documents... take a look at SLALOM outcomes: a technical SLA specification and a legal reference.
There is no doubt that cloud computing has emerged as the preferred model for today’s IT infrastructure for doing business. The simple vision we might all have is that cloud is about accessing and sharing files using services like Dropbox, using a web service like Gmail, or sharing photos using Flickr. However, the cloud goes way beyond those, especially for businesses. Companies use various applications supporting line of business and operative processes providing services to functional departments for marketing, sales, support, logistics, finance, software development, HR, etc. And Cloud services provide, in principle, business agility and flexibility, cost reductions and variable expenditures, and responsiveness among other factors. However, cloud computing comes with the price of a new scenario in which organizations have to start learning to protect their businesses. There is no doubt that the game has changed. Third party providers are now responsible of part of our business models’ core processes. If we care about our business, we should now spend some time to depict our relationship with these new business partners. This means paying enough attention to several aspects: business, technical and more importantly, legal to establish what it’s called Service Level Agreement (SLA) for your cloud services.
The Cloud Standards Customer Council (CSCC) practical guide to cloud computing did a good job analysing what needs to be done in order to evaluate Cloud SLAs. CSCC advises that before evaluating any cloud SLA, consumers must first develop a strong business case, with business level policies and requirements, and a strategy for their cloud computing environment. This means identifying specific services that will be deployed in the cloud along with a clear understanding of the criticalness of these services to the business. Only after this strategic analysis has been completed, and only then, can the consumer effectively evaluate, compare and negotiate SLAs from different providers.
SLAs should not be taken lightly. The obligations and penalties included in an SLA can save companies if well addressed when bad things happen, or they can terminate your business if badly, or not addressed at all.
Some cloud providers, like the global leading service provider Heroku, do not specify any SLA in any manner than the cloud adopter can get specific assurance for the Service Terms when they hire their services. What is even better is that they instead provide a “Customer Promises page” that states a set of good intentions referred to the Service Provision. They provide a great number of services and good one-of-the-best services on the net, especially in the startup context.
Is this the kind of “commitment” you need for your business model? Is it enough? Does your organization need more than promises to assure your business model? If the answer to this last question is yes, you need Cloud SLAs!
What are SLAs?
Before we dive into details, what are Service Level Agreements (SLAs)? SLAs are legal documents (which therefore require the participation of legal experts and lawyers) that define both business (which requires participation of managers and accountants) and technical (engineers) aspects of the services. Thus, SLAs can be extremely complex to address to new comers and for large organizations as well. Also new cloud providers new advice for how to create their own SLAs according to their offering.
In this context, SLALOM team counts with experts of both legal and technical fields. These experts have created a set of documents that will help you address the problem of approaching your first SLA.
But what are SLAs in practice? Simply put, an SLA is nothing more than a type of contract between two parties, the Cloud Consumer and the Cloud Provider, where SLAs dictate the quality and type of service that will be provided to the client for a price. In general, SLAs are important due to their setting of the tone for the relationship between the parties and will govern if and when things break down.
In the end, SLAs contracts should answer basic questions about the delivery of a service required after organizations carry out the initial strategic assessment to go to the cloud:
- What services will be used? and what is an acceptable level of service for each one? Always the same service level? Can they be changed? How? Under what circumstances? By whom?
- What metrics will be used to determine whether that level is being achieved? How can they be measured and monitored? What reporting mechanisms will be used?
- What happens if the requirements are not met? What penalties are defined for such cases? How are they reported?
- How are security, privacy and data protection managed? What are the implications covered and assured by the provider or its subcontractors if possible? Do they provide all necessary means to deal and assure business and personal data? Is there any process for Business Continuity?
- What liabilities do providers have? What are the possible limitations to such liability? Are there any “force majeure” circumstances in which the terms do not apply?
Then, cloud consumer and cloud provider should begin to structure the agreement in a document by effectively working together. This document will state in fancy contract language all technical and business requirements from both sides. Therefore, the best SLAs are those that look after the interests of both parties, a balance between being thorough, fair and clear on the one side, while not being overly onerous on the service provider on the other side. In this regards, SLALOM is based on common ground and best practice for both sides of the equation.
You will find next a brief summary of SLALOM’s approach and documents that will get you started with Cloud SLAs.
Comparing the incomparable with SLALOM Cloud SLA Baseline Documents
As already said, the process of putting all these aspects in a well-structured and complete, yet clear and practical document is a complex task, in which adopters need assistance.
SLALOM team has put a tremendous amount of effort on creating a set of practical documents that serve as baseline for addressing SLAs negotiation process. These documents take into account and embrace state of the art, standards and best practices from the technical and legal fields; recommendations received from Cloud Providers and Cloud Adopters during our first assessment of the current cloud market, and our current consensus phase in which we are focused on reaching broad consensus of all stakeholders that the terms are fair, legally tight, balanced and sufficiently broad.
SLALOM proposes a workflow in which the main contractual relationship is managed by the Master Service Agreement (MSA) comprised by a number of attachment documents that define technical and legal aspects of SLA. This legal document specifically addresses business and technical aspects with the intention to provide an answer to all aspects that SLALOM experts have considered relevant according to our positioning. You can learn more about SLALOM positioning in the document “SLALOM Positioning Paper”.
SLALOM work is aligned with the principles given by the European Commission, and its European Cloud Computing Strategy guidelines on the standardization of SLAs for Cloud Service Providers issued in June 2014. SLALOM work is aligned with aspects such as technology and business model neutrality; the need for world-wide applicability; completeness and unambiguous definitions.
SLALOM proposes an initial baseline to address Cloud SLAs, specifying the structure of what the SLA should have, providing an initial wording of legal terms and providing a technical specification (metrics, parameters, rules and dependencies) that uses standardized terminology, concepts, metrics, vocabulary and state-of-the-art capabilities of the cloud industry with the intention to provide sufficient information about how providers will measure cloud services. This will allow comparing heterogeneous services and SLAs from various providers.
In addition, one of the most relevant aspects of SLALOM to provide confidence is that our baseline documents are built on top of ISO Standards in a practical way. ISO will tell you WHAT. But SLALOM will help you with HOW, turning theory into practice. Therefore, SLALOM provides assurance for the uptake of cloud services with its SLA model legal clauses and technical specifications, using a trustworthy base, which is practical, fair, and understandable, while saving time and resources.
Master Service Agreement (MSA)
As mentioned before, there are many aspects to cover in the SLA. Thus, in order to structure every aspect, a main document is needed to serve as umbrella of all concepts and business objectives, stated in terms of legal terms and technical definitions.
SLALOM proposes the Master Service Agreement (MSA) as the main document providing the terms and conditions of the contractual relationship between the Provider and the Adopter in relation to the provision of the cloud services. You can download the latest version of the document (still in the middle of the consensus phase) here.
After the SLALOM positioning paper, the current version identifies possible different interests, positions and perspectives of the two parties involved, Cloud Providers and Cloud Adopters. However, SLALOM takes a stand according to our vision and objective to present a practical baseline for simplifying SLAs and closes the gap. SLALOM experts have then created a document with the purpose to provide legal inputs for codifying fair terms and conditions of the cloud services and to provide a first draft to share with all stakeholders, which is expected to evolve and improve the results.
It is also important to highlight that the contractual provisions are also being also drafted taking into consideration the possible applicable laws and regulation relating to the relevant points in Italy, Germany, UK, France and Greece.
The MSA is structured in a way that provides a main umbrella for common things and it delegates the specifics to annexes in which concrete aspects are detailed. This approach facilitates adopting changes in relevant aspects such as technical aspects covered by the SLALOM technical SLA specification, the detailed description of services involved, penalties, and other specificities like concrete security policies, data protection policies, business continuity policies, among other. Read SLALOM legal model document.
Service Level Agreement (SLA) Specification
When dealing with technology services, organizations must work with a detailed description of the objectives and the way they will be measured for a number of different categories of the business cloud strategy. In order to have all technical aspects well covered to assure the required service levels, organizations need to establish a list of areas to assess in the technical specification of the SLA. These include, but are not limited to:
- Performance & Availability: Availability, Response Time, Capacity, Elasticity, Speed, Connectivity and Accessibility,
- Security: Service Reliability, Authentication & Authorization, Cryptography, Security Incident management and reporting, Logging and Monitoring, Auditing and security verification, Vulnerability Management, Backup, Recovery plans
- Personal Data Protection: Codes of conduct, standards and certification mechanisms, Purpose specification, Data minimization, Use, retention and disclosure limitation, Openness, transparency and notice, Accountability, Geographical location of cloud adopter data, and intervenability
- Data Management: Data classification, Cloud Service Customer Data Mirroring, Backup & Restore, Data Lifecycle, and Data Portability
- Governance and Support Services: Governance, Service methods, availability, and costs, Capability Indicators, Support, Reversibility, Modification and the Termination Process
Having this in mind and considering the results of the first positioning paper, the technical team designed an initial technical specification to bridge the gap between providers and adopters by providing a “core” SLA specification. The SLALOM SLA technical specification allows the definition of parameters & terms through a well-defined set of metrics. It contains specific key metrics & terms (used to assess a property of the SLA), parameters (used for the expression of a metric), rules (used for further possible constraints of a metric), and dependencies (used for specifying the dependencies between the different metrics) that have to be followed by the CSPs, which will be described in the following subsections.
The proposed “core” metrics of the SLALOM SLA specification are separated into four different types of groups: highly-important, medium-important, important, and less-important. This idea that the metrics have to consistently represent the information, be comparable, flexible and adaptable and the fact that the SLAs must be enforceable and state specific remedies that apply when they are not met.
Read SLALOM technical SLA Specifications document. This document is a first version and is also in the middle of the consensus phase. One should keep in mind that the suggested “core” SLA specification may contain some changes as for its content according to each provider’s requirements, but it is mandatory for both the providers and the customers to obey and follow the provided structure, definitions and rules.
In conclusion, if you think that Cloud SLAs are too complex, you are right. However, SLALOM shares the results of its work in the form of a reference model, a number of structured documents with, legal terms and technical specifications that provide organizations guidance and facilitate the process of doing business in the cloud in a safe way.
SLALOM has worked hard to help you adopt practical, understandable and safe & fair Cloud SLAs. Visit SLALOM download section and don't forget that our legal and technical teams would love to hear from your needs and your priorities. Contact us here