Cloud Computing is concerned with deployment, but introduction of Cloud Services cannot be a purely technical deployment matter. There are numerous considerations that may impact on all the Stakeholder Views. In this report, we show how the CBDI-SAE approach can be used and extended to architect for Cloud Services. We extend our current guidance 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.
The interest in Cloud Computing and the provision of Cloud Services has grown significantly. However, terms such as "Software as a Service" or "Public Cloud" can still be a bit misleading and vague. What exactly is the type of capability being offered by a Service? Who is actually providing it? After all, aren't all Services provided by software?
In CBDI-SAE we have defined a structured approach to identifying Services and in particular classifying them into different types with relevant policies and rules guiding the development of the Service Architecture. Moreover, our Service Portfolio Planning (SPP) process guides the traceability between the architecture Views from Business, Specification, through Implementation, to Deployment, providing a business centric architecture on which to make decisions about provisioning the Services in the portfolio, and their implementation.
In this report we set out to establish how our SPP and Service Architecture approach provides a framework for better understanding of the role of Cloud Services and decision making for their use.
What are Cloud Services? Simply put, they are Services provided where:
The core concept of a Service is that it hides from the Service Consumer the complexity of how the capability is implemented by the Service Provider. Hence the focus in SOA is primarily on what capability the Service provides, and not on how it is provided.
The Service can virtualize the capability. With appropriate technology it can even be transparent to the Service Consumer where the resources are located or whose resources are used. By removing the constraints of tightly coupled resources, Service Providers and Service Consumers have greater agility to use alternative resources as long as the Service Specification continues to be met.
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. Figure 1 for example was published back in 2001. Even prior to that some 15 years ago in our early CBD research we presented the notion of application solutions assembled from a 'cloud of services' provided by software components implemented in different technologies, though the notions of the infrastructure provided by a public cloud were not developed then.
At the time, there was a fair amount of skepticism from any audience we presented this to as to whether this would ever become reality, or at least widespread. Cloud computing is only now becoming mainstream because the industry and its customers have by and large achieved a basic maturity in SOA that enables this more sophisticated architecture.
Whilst the premise of cloud computing and the use of services provided by external entities is now more widely accepted, many of the concerns raised then still remain – including security, risk, and worry of dependency on external entities.
Continued in PDF...
In this report, we show how the CBDI-SAE approach can be used and extended to architect for Cloud Services. We extend our current SOA guidance with new and refined classification systems, diagrams, policy types and techniques.
File Size: 535KB
Published: 9 Sep 2010 00:00