We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Implicit service contract may be more important than the service interface

Vote 0 Votes

On 21 April, Amazon Web Services went down for hours torpedoing many Web Sites and companies at once.

Amazon Web Services had a great reputation as one of "the largest, most secure and most trusted Web services in the world". CIO started to put a faith "in Amazon's cloud because there was no reason to think that it would falter. One of cloud computing's key tenants is reliability through redundancy of both servers and data centers". Well, people accustom to good things too quickly while nobody has deflated the Murphy's laws yet.

Chris Preimesberger believes that Amazon EC2 Outage will not negatively affect attitudes toward cloud. Well,it depends on what people consider "negative". In any case, this sad event has awaken many CIO and reminded that there is no such thing as a "silver bullet" and that "nobody is perfect".

However, the most interesting aspect of this story, outlined by Lydia Leong of Gartner Research, is that Amazon EC2 didn't violate its service-level agreement when the outage occurred because its SLA promises 99.95 per cent availability. How many of us knew about or put attention on this simple sequence of figures? Not many and this is because Amazon EC2 has offered an implicit service contract to us. None of us needed to negotiate the service contract with the service provider - Amazon EC2 in this case.

How many times you've seen a serious business that operates with another business based on an implicit contract with regard to its mission critical functionality? I have not seen many (any) of them. Even a Mail Service has several categories of service with different SLA constructed with the contracts that become almost explicit when they are signed. That is, the client and the provider learn all details in the contract about the service offered and, if there is a potential gap, cautious consumer arranges for the mitigation. Why CIO have not mitigated 0.05 per cent availability while their own systems required 99.99 per cent availability? Is this a negligence or immaturity to 'be in the business' of services?

Another not less interesting aspect noted by Lydia: "...Their SLA defines unavailability as a lack of external connectivity to EC2 instances, coupled with the inability to provision working instances. In this case, EC2 was just fine by that definition. It was Elastic Block Store [EBS] and Relational Database Service [RDS] which weren't, and neither of those services have SLAs." In my opinion, this is classical 'unfair trade' if we look at it from the SOA ecosystem perspective. In the SOA ecosystem, implicit and explicit service contracts should not expose any internal elements to the consumers but only the delivery of the service as the whole. No consumers do or have to care about those details (otherwise it is not a service but a traditional application-centric meteor from the past). Why so?

Here you are: if you show such contract to any lawyer, you can expect one of two requests: a) list all elements your service depends on and write SLA/contract against each of them; b) remove all your internal elements from the contract because we do not know if you have something else you are not telling us about that might affect our contract. But this is the explicit contract...

So, being in the business of service in SOA ecosystem, watch for the service contract, be a business-focused person; technologists know how to connect SOAP to messaging, you can count on this, but they do not know what to do when it appears soap and washes into the sink. Implicit service contract may be more important than the service interface in some cases.


Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives