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.

Other types of functionality... where does it go on the cloud

I have been curious of how will the cloud evolve.  We have picked basic functionality to start the cloud.  Queuing, Storage, instruction processing, network are the blocks that the rest of IT is built upon.  As an industry, those blocks have been/are being solidified.  What I would like to know is what is next to be built or perhaps next after that.  As usual, I have an opinion, but it will, also as usual, require a bit of context.  I hope the conclusion will be worth it!

My contention is this: "The cloud" is a mechanism to enable services of commodity functionality  [Which is another name for work] and as such, a well understood taxonomy or organization of these commodity functionality will need to be developed in order for higher level functionality to prosper in the cloud.  

To understand this, understand that functionality can be described as: Core (value adding), Unique (necessary, but no provider we trust), Commodity (necessary and providers we trust)  and Extraneous (not necessary).  Core competencies (functionality), as described by Jack Welch, is work that a company focuses on being the best at to set itself apart from its competitors.  Unique is work that is needed to be done but it doesn't set us apart directly and there aren't providers that we can trust to do the work.  Commodity is work that is needed to be done that doesn't provide differentiation but there are providers who can do the work.  Extraneous are waste in the lean six-sigma sense.

In real-world products, we have seen business outsource accounting, payroll, manufacturing, sales, IT.  Following Jack Welch's advice of focus on core competencies and allow others to offer a service which encapsulates the work that isn't core to your value proposition.  This makes sense. It leads a company to only, for the most part, focus on things that matter to its bottom line.  However, a company will still need to do unique functionality because no one else can.  Our goal should be to convert, as much as advisable in terms of security, functionality from unique to commodity.  Even potentially creating new industries to provide that functionality.  Stated differently all work that is necessary for a business to operate should be provided by an entity whose core competency is doing that particular work.

So applying this to information technology, there are algorithms that are core, unique, commodity and waste.  If we follow the same advice, our efforts should be focused on our IT's core competency.  Work that is unique we should plan how to make it commoditized.  Commodity should be being done by others and waste should be eliminated.  But how do we make this happen?  

With the advent of services and well-understood interfaces, it has become operationally easier to separate out the core from the commodity services.  The cloud starting from the ground up, with storage, database, computing power, networking.  Functionality that all systems share and because they have stable, mature, well-understood interfaces.  This is not really due to the efforts of the cloud community for they stood on the shoulder of giants. Rather it was the efforts of IT Vendors and standards groups that standardized the interface allowing the creation of their products.  Remember these standards allowed the syntactic ambiguity and also, to the extent possible, the semantic ambiguity to disappear.  However, this canonization effort is expensive, time-consuming and potentially a pre-ripe standard may stifled innovation to soon.

High level functionality such as business rules, calculation, decision logic may indeed be capable of being a commodity.  However, trust, the ecosystem of providers, the organization of functionality and the interfaces standards for the functionality are immature.  Thus it traps potential commodity functionality as unique.  Or it requires that business purchases a large package that stands in for the undeveloped ecosystem which can hinder your IT organization from being enabling business differentiation which should be its primary objective.

SAP and other large package vendors will tell you that they are opening up to allow highly customized processes and manipulation of data.  They will even allow you to call a web service from an external (to SAP) provider (probably will be you!) and use the response in your process.  So, in essence SAP (and all the other ones too) has turned into a platform that provides a rich array of functionality and process to accelerate your mapping of your emulated business to your real business.  This platform can become the focal point of your business.  Is this new?  no.  Is this bad? no.  But the ecosystem needs to extend out.  Potentially even replacing parts of the rich array of functionality or perhaps replacing the platform.  A business using a package should ask itself, what is the core competency of our large package software and map that answer to the previous goal: all work that is necessary for a business to operate should be provided by an entity whose core competency is doing that particular work.  No vendor can provide all functionality to all types of parties as part of their core competency.  At least not to the determent of some of the functionality.  So, how do we build an ecosystem that will allow best of breed augmentation using external functionality?  How will we know who has what?  And how difficult will it be to have multiple providers or to switch providers?  Asked another way, how do we abstract out the functionality from the provider?

These, I believe, are the core questions to prompting us to make high order functionality available on the cloud.  We tried UDDI, but there wasn't a good taxonomy developed to describe where the functionality fit.  As well, there wasn't a good semantic ontology developed to describe the interfaces.  Nothing helped us be agnostic to the physical interface.

So my solution:

Imagine in a folks-onomy way a provider builds a version of their functional taxonomy.  This would include the semantics of what the functionality does.  As well, the semantics of the interface.

This world would also includes a more generic taxonomy built with help of linguists, computer scientists that is semantically accurate.  These taxonomies will be built, probably, along industry segments lines.  The company accomplishing this intellectual property, will work with individual providers to help them map their own taxonomy to the more generic taxonomies potentially across industry boundaries.  Where holes appear, the company will modify the generic taxonomies to make it a more complete and living entity.

The beauty of this is when a company wants to consume commodity functionality.  They search the functional taxonomy to find what they need.  Their platform/package provider will jump start their own taxonomy and the individual consumer will modify it to match their particular implementation.  The individual company will a more specialized functionality for its business than its package provider provides.  Because providers publish what functionality they provide and a match can be found at run-time.  Also, because the interface is semantically tagged, the consumer can provide the correct information based on its data's association with the generic taxonomy at run-time and convert the response to its own format.  

Therefore, the physical interface doesn't need to be well-understood, just semantically understood.  Which has been a huge problem all along.  We don't semantically tag our information (as a general rule) to an authoritative source .  In the same vein, we could do the same for describing nouns, processes and events.  It is in organizing our functionality (work) and our information that will allow our trapped unique functionality to become commoditized and therefore meet our goal.  

I think a company that can build and maintain the taxonomy so that semantic accuracy can be a first order principle in software design would be an awesome place to work.  As the cloud grows and encapsulates higher order functionality, semantics will be foremost!  Well, until it itself is commoditized.  

Anyone want to help me build this company?