donderdag 2 februari 2012

The NIST Cloud ecosystem needs a few improvements

On Januari 23, Peter van Eijk wrote in his blog : “Cloud architecture: there are no brokers

The NIST cloud definition, see NIST SP500-292 Cloud Computing Reference Architecture  indeed identifies 5 roles for parties acting in the cloud ecosystem: the provider, the the consumer, the auditor, the broker and the carrier.
Peter argues that the delivery chain can fundamentally involve only providers and consumers since any party that is responsible for the service level is a provider, and any party that does not have such as responsibility cannot be part of the delivery chain. Hence the Broker cannot have a service delivery responsibility and cannot be a provider.

I agree with Peter that the NIST definitions are not entirely flawless.  The NIST definition if a broker suggests a VAR or aggregator relationship. Such an aggregator or value-added reseller, regardless of the fact that they do- or don’t  have direct control over elements in the stack, is indeed a service provider.

Even though they are not providers I still think that it is smart to keep these “non-delivery” parties in the Cloud ecosystem model.  Without these additions the model would be incomplete, and consumers would still be in the dark about the precise role and responsibilities of parties that provide services that pertain to the cloud. As is the case for the Auditor. Although not in the delivery chain the auditor is vital for managing trust and safeguarding the responsibilities in the delivery chain, and cannot be omitted from the ecosystem
The same is true for the broker, that is, the broker according to my definition.  My “cloud broker” is a party that provides additional services to the cloud provider. The broker services supporting the cloud service can be optional to, or are even essential  for that service.
Examples of broker services are brokering in the true sense, providers of business support services, security services, etcetera.

Lets for example consider a party that sells and supports office365. The service relationship is with Msoft, but from the user’s point of view the broker IS involved. They close the deal, subscribe the customer on O365, migrate and support the customer. We agree: without such a broker many customers would be lost in space. Other examples are providers of rating and billing or monitoring.  They belong to the ecosystem.

So if we agree that non-chain providers of additional services must be in the ecosystem picture, how would that affect the NIST model?

First of all the definition of broker needs to change.  It is a supporting provider, and is not present in the direct chain. I challenge NIST to figure out the precise wording for this.. Or will if they pay me to do so.. J
Next, there needs to be some refinement of the Service provider definition. The provider can be 1 of three: A) provider of 1 or more of the layers Physical and  “X”aaS , B) an aggregator, combining services, or C) a VAR ; who has no direct control over any of the layers but is in the chain.

Last but not least: there should be more emphasis and better explanation in the model of the fact that cloud consumers of anything other than the top of the stack, i.e. Saas, or aggregators or VARs of Saas, are also providers. The recursive nature of the model is an abstraction that is not very obvious and often difficult to explain.

1 opmerking:

  1. Your mention of the "service relationship" is interesting. I wrote an article (http://recursivedigressions.blogspot.com/2012/03/cloud-broker-overload.html) where I break things down according to "business relationships" (who has a contract with who) and "functional relationships" (who sends messages to who). In any multi-party scenario it is possible for the consumer to have a functional relationship, a business relationship, both, or neither. Trying to use a single term (broker) to describe this complexity is futile.

    BeantwoordenVerwijderen