Cloud-o-gram

When I first saw Brenda Michelson's post Cloud-o-gram, I couldn't help think about sneaking downstairs after my parents went to sleep to watching Saturday Night Live. One episode they had was this land-shark that would try to get into people's houses or apartments by pretending to be a candy-gram delivery. But unlike the delivery of the most cleverest of all sharks, this cloud-o-gram reference architecture seems to be the real deal.

One of the fundamental problems facing things that allow ecosystems to develop on it is how do you segment it into areas so that you can focus your attention? When you do, what lines do you draw so that your segmentation isn't arbitrary? When I look at the cloud and start to talk about it to people (and sometimes just to myself) I fluctuate between customer POV, Provider POV, Ecosystem POV, Machine POV and land-shark POV. And when you add recursion that a provider of a service is really reselling a service that is consuming yet another service which that same physical service might actually be sold by yet another provider! Oy Vey!

My read is that Brenda has nicely separated out what is sold (offerings) from the mechanisms that provide what is sold (cloud computing environment) from the sales management of what is being sold (For the/About the cloud) from the agreement to sell (SLA). Genius!

This reference architecture will be the organizing mindset behind the Elemental Link's research (and I suspect a book or two). What I am unsure of at this point is does the reference architecture allow for multiple points of view? As with most services, the veil of encapsulation allows the consumer to "ignore the man behind the curtain", but to their own detriment in many cases. The power of abstraction hides complexity (as it should) but also increases fear of the unknown or un-understood. This is why what Brenda is offering is important for consumers and providers alike. To dispel the magic to allow rational decisions to be made.

As much as I am glad that she is taking on this important work, I feel that there is a significant area missing: customer reasoning. As with most services, this model also has a boundary as to the interactions between the customer and the provider. I would imagine inside this would be not just interaction with the service, but with management reports showing how the SLAs are meet. Cost analysis would be dealt with along side a good semantic interrupter to translate from one community of interest to another. But why a company should invest in a particular service or ecosystem of services seems to be missing. Beyond the technical reasoning, how does a company decide what should be kept and what should be leveraged.

One of my clients and I were talking about a particular service that they could either build, buy a license and host themselves or totally put it out in the cloud. His answer confirmed my thoughts. "I can't hire someone for that amount of money and get the service level agreement I need." However, another service was "too critical for the strategic advantage of this organization" to trust to another. Jack Welch quote in Straight from the Gut "Let your back-office be someone else's front office!" comes to mind. This becomes hard for IT managers to get since their jobs may be on the line. However, I believe that decision is the success difference maker and is part of what us who call ourselves enterprise architects should consider carefully.

As Brenda develops her research, advice and books (I hope) I believe she needs to consider with this model, some example cloud use cases to be able to test against. An example would be a sales tax generator that will calculate the appropriate sales tax for any geographic location in the world. Some situations that should be considered to make sure the model meets the needs are:

• Provider has all of the data, computing power, interfaces and sales force needed.
• Provider uses other providers for some of the resources needed but generally is a contained offering
• Provider only sells the services that others create
• Multiple providers sell the same service and compete on a variety of dimensions
• Multiple providers sell the same commodity service and compete mainly on cost per transaction
• Multiple providers sell the same service and dynamically providers come in to and out of the picture but the ecosystem has a static syntax and semantic definitions
• Multiple providers sell the same service and dynamically providers come in to and out of the picture but the ecosystem has a dynamic syntax and semantic definitions capability.

Again, I am ecstatic that a person of Brenda's caliber is taking on this challenge. I believe, slightly augmented, this model will serve her and her clients very well.

Bravo, my friend, Bravo! I, for one, am looking forwards to what comes next.

Contract-First Development of Services

Contract-First development of services will help companies move towards a service oriented architecture (SOA). When you can abstract code into services, it makes it easier to use those services as pieces and plug them into where ever they might be needed. By first building the service's contract, it provides the structure to define and make those pieces work together.

However, what IS a service? Some might say "it's a web service" or "It is creating modular, reusable code." It is true that the web service standards are important and re-usability is an important attribute. However, by taking the view that a service in an SOA is more similar to a lawn service than a web service helps debunk the notion that services are simply code that can be easily called from anywhere (Modularity). Instead, it allows us to consider that a service as a stand alone piece of functionality.

When you hire a traditional service such as a lawn service, the first thing that occurs is an agreement as to what will be done. The elements of this agreement include the name of what will be done, what the customer has to provide and what the end result will be. The agreement will also include performance and response time criteria. In the end, as a consumer, I don't generally care if my lawn care provider cuts my grass with a 20k dollar mower or a push power or a pair of scissors. The implementation is up to the provider, SO LONG as it is implemented meeting the agreement. We call this agreement a contract.

Services found in an SOA also need this type of agreement. A service contract includes both functional and non-functional requirements. The functional requirements include what the service does, the service interface and the means of invocation. the non-functional requirements include service level agreement, security and quality of service, transactional constraints, process and semantic definitions.

You might ask, "Why do I need this contract? What does it provide for me? Can't I just use the interface?" The reason you need it is to give the service it's own scope of responsibility. A basic tenet of SOA is that a service is an autonomous unit of functionality. Also, it provides a definitive scope of what that service need to provide. A contract increases visibility and provides a neat package of functionality that can be used as a component in our application infrastructure.

Another advantage in knowing the functional requirements is that before the code is even created, test cases can be developed to determine if the services performs the required functionality within the constraints of the contract. Some call this test-driven development.

Stability of the system is critical when you create a SOA. This stability is improved by the versioning of ontracts. Once a contract is established, it can not be changed and it must be supported as long as consumers exist for it. However, new versions can be cloned and modified. By having both versions of the contract supported, new functionality can be built and made available to early adopters while the old contract is still supporting other applications. This allows a company to be agile in reacting to business changes while not breaking existing applications.

Lastly, the contract should state ownership and responsibility matrix. This is in the form of who is involved as well as who is responsible for the evolution of the service. The RACI is a great starting place to show these stakeholders. RACI stands for Responsible, Accountable, Consulted and Informed. I have always had an issue between Responsible and Accountable. They seem very similar. So lets do the easy ones first.

Consulted represents the set of people who have input in to the contract. They are typically the main consumers or business subject matter experts. The important part is that this is a two way communication. Informed are the set of people who need to know about changes or the development of the contract, but do not have a voice in its creation. This is a one-way communcation.

Now for the difference between Responsible and Accountable. Responsible to me is the person who owns the problem or, hopefully, owns the vision. Accountable seems to be the person who has to approve it. One variation that I like more for the 'A' is assists. Who assists the Reponsible (Visionary/Owner) in making the vision a reality.