Thursday, 29 April 2010

Service Portfolio Planning and Architecture for Cloud Services

The concept that Services are provided ‘somewhere in the cloud’ has always been central to our vision of SOA and we often used the cloud metaphor to illustrate this. Some 15 years ago in our early CBD research at Texas Instruments Software we presented the notion of application solutions assembled from a ‘cloud of services’ though this was positioned more as a way to achieve technology independence as the notions of a public infrastructure provided in the cloud were not well developed then.

The arrival of Web Services at the turn of the millennium provided a standardized mechanism by which location independence could be added and at that time we began presenting ideas like this, entitled "Does it matter where Services are Located?" - though in 2001 we will admit the audience was often more than slightly skeptical about the idea!

Does it matter where Services are Located?


Whilst there is now a high level of convergance throughout the industry on classification of Cloud Services as Software as a Service (SaaS) or Infrastructure as a Service (IaaS), as concepts such as Public, Private or Community Clouds, these generalized terms can be a bit misleading and vague when it comes to producing a more exact model of the Service Architecture. What exactly is the type of capability being offered by a Service? Who exactly is playing what role in the Service Supply Chain?

So, in the free report I have published in our CBDI Journal this month, I set out to show how our CBDI-SAE approach can be used and extended to architect for Cloud Services. The current guidance has been extended with new and refined classification systems, diagrams, policy types and techniques designed to promote visibility and good governance over Service Portfolio Planning activities and Cloud Services provisioning.  (see also the slideshare following the 'read more...')


Service Porfolio Planning (SPP) is an overarching process encompassing the identification of Services, arranging them and associated artifacts in the Service architecture views,  and making planning and policy level decisions about their provision, deployment and usage based on business and IT strategy and requirements.

To some extent, the portfolio planning decisions as to whether to use a Cloud Service or capability should be little different to that for other Services. However, the introduction of Cloud Services will often be a deviation from current standard practices for many organizations, and consequently they may need to apply more rigor to their decision making processes and place greater consideration over factors that today may normally just be accepted as a given, or the de facto state in their organization.
In the report I
  • provide a set of criteria for making planning decisions on the use of Cloud Services - based on Financial, Agility, Risk, and Capability factors
  • outline a set of policies for each Service Architecture view that should be set in order to ensure governance over Cloud Service provision and usage.
  • a mapping of Cloud Service classificiation to the more precise classification of Services used in CBDI-SAE
  • detail guidance and considerations for modeling Cloud Services in each of the Service Architecture Views (business, specification, implementation, deployment)
  • show a worked example demonstrating how different types of Cloud Services (including some of the Services from Amazon) are classified and placed in the Service Architectures.
The following SlideShare gives a brief view of some of the Service Architecture views showing the classification of public, private and community usage (see the notes for explanation). The report itself extends to 20 pages and contrains several more diagrams that explain how and why the architectures are arranged as they are.

Service architecture for cloud services
View more presentations from LawrenceWilkes.

Service Portfolio Planning and Architecture for Cloud Services - See CBDI Journal Report (free on registration)

No comments:

Post a Comment