Thursday, June 2, 2011

Industry Cloud models are all very hazy!

I am currently working on extending the CBDI-SAE meta model for Cloud. I started this exercise by making some specific assumptions:
1. I am interested in the larger enterprise perspective; enterprises probably need more knowledge of the underlying capabilities than SMEs if for no other reason than good governance
2. For similar reasons I am exploring primarily the SaaS and PaaS layers because most enterprises will usually outsource the infrastructure, even if its private.
3. And in defining the meta classes for these layers I am interested in supporting an application modernization process and life cycle because, again, that's where most enterprises are at in their Cloud efforts.

In looking at some of the excellent work that has been published already on Cloud, particularly by NIST, I was struck by the Provider centric focus of all the deliverables. I suppose I shouldn't be so surprised because most of the work is being supported by service provider based people. Yet, in context with my assumptions above, I am finding the models not as helpful as they might be. The NIST Reference Architecture is mostly Actor centric, yet the Provider capabilities are expanded, whereas the Consumer, Broker and Auditor are either not expanded at all or at a very superficial level. Well it's all superficial, but nevertheless it presents a very unbalanced picture.

So pretty soon I decided that (at least) my initial model would be a Consumer View - because that's the primary requirement of enterprises. And of course I find a high level of overlap with the SAE model because the Cloud from the Consumer perspective is all about services. But there are some interesting alterations and extensions that I will be detailing in due course.

If anyone is working on meta models in this area I would be very interested to hear from them.
Posted by David Sprott at 6:44 AM
Labels: ,

6 comments:

  1. Hi David,

    you can view my slide at:
    http://www.slideshare.net/kindramesh/cloud-meta-model-8195550

    I look forward to good debate.

    regards,
    K V Ramesh

    ReplyDelete

  2. Hi KV, I like the idea of a high level model – it forces us to ask and answer difficult questions before diving into detail. First I think we are in strong agreement on a number of points.
    1. Architecture driven;
    2. Asset managed (to coordinate cloud and non cloud, multiple clouds etc);
    3. Consumer oriented (as discussed in my blog post).

    Some points for debate.
    4. The Cloud is a Service Oriented environment. Consider service (not just SLA) at the heart of the model. SLA is then one form of specification of the contract.
    5. In your model should Component be Service?

    Consider other important concepts that could be surfaced at this L1 view (in no particular order).
    Service and Service Specification
    Service Dependency
    Business Capability
    Cloud Integrity Unit (set of services for procurement, test, deployment . . . )
    Actor (NIST) and Service Participant (SoaML) (to allow us to differentiate various relationships between Service and Cloud Provider, Consumer, Broker etc)
    Security Domain (equally important as permissions)
    Service Layer and Layer Rule (applicability to Cloud and SOA layers)
    Policy (show governance requirements)

    Best Regards, David

    ReplyDelete

  3. David,

    Thanks for your comments.

    4. I view service definition (SOA) to be part of the EA. Hence, the definition will flow through.

    5. Component is a super-type and the elements inside are the sub-types. Again, the definition will be in the EA.

    I view that the EA encompasses all the definitions and driver for implementation. The EA definitions will be populated in the CMDB to drive the implementation. The reason for including EA in this schema is to accommodate multi-tenancy (from a cloud provider perspective).

    regards,

    KV

    ReplyDelete

  4. Hi David,

    In the mean time, I have a question for you. Should Technical Architecture be part of the EA in a cloud environment?

    regards,
    KV

    ReplyDelete

  5. Hi KV, Really good question. First we need to get terminology straight. In SAE we separate out Deployment and Technology into different Views. This is in contrast to say TOGAF, where the Technology View encompasses both concerns. So we need to talk about both DA and TA. Second I am assuming we are talking about Public Cloud. For Private Cloud the TA will clearly be required.

    Using the SAE Views will make this easier to explain. The answer to your question is DA and TA will be required for the foreseeable future because most if not all enterprises will be using hybrid solutions. However for Cloud only deployments the DA is still required almost in its entirety, excepting INTERNAL LOCATION and SERVICE INSTANCE. For the TA the virtual resources are the responsibility of the Provider, and should be fully encapsulated as far as the Consumer is concerned. But the EXECUTION ENVIRONMENT TYPE and STANDARDS AND PROTOCOLS will still need to be understood by the Consumer Enterprise.

    ReplyDelete

  6. Hi David,

    I fully agree with you. My question on TA was for a public cloud. In a private cloud, it is needed. DA is needed independent of public or private cloud. I also agree on the view that deployment and technology should be separated. In the near future, I foresee deployment as a self service or enterprise app store.

    In my view the governance and the enterprise architecture management should also be managed with self service or enterprise app store way. This would give the boot strap effect on services deployment.

    regards,
    KV

    ReplyDelete

Subscribe to: Post Comments (Atom)