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.
