Robert Laird, Colorado Springs, Colorado

Executive Architect, SOA Governance & SOA Policy, IBM Software Group

I recently co-authored a book with Thomas Erl and other colleagues on SOA Governance.¹ One of the items we started to address in the book is how SOA Governance can assist with cloud computing. This article discusses those thoughts and further delves into this subject matter with a look at SOA and cloud computing, and how SOA Governance can help enterprises harness the promise of the cloud.

Service Oriented Architecture (SOA) presents a compelling value proposition by addressing a distinct set of business challenges that enterprises are faced with today. The fundamental tenet of SOA is that it demands as much commitment from the business imperative as it expects from the IT department using service design principles.

SOA states that in order for a business to be agile and adaptive, the business needs to represent its core business processes through flexible business models, and then expose its IT infrastructure and application capabilities through a set of shared and reusable services so that each such service can participate in the implementation of the flexible business models. By building flexibility into the business models, through their representation as a set of participating services, enterprises can integrate third-party services into their core business processes, reducing the cycle time and cost of integration with external businesses.

Speaking of being flexible, cloud computing is a specialized type of distributed computing for the usage of remote and measured IT resources. The National Institute of Standards and Technology (NIST) states: “Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”²

The benefit of cloud computing that most people associate with the term is its ability to reduce or eliminate capital investment and support a proportional measured usage model. In other words, cloud consumers have access to IT resources by renting instead of purchasing. When that resource is a software program, it must support multi-tenancy, that is, access for different consumers who are isolated from each other.

A second benefit is the potential for better ubiquitous access, with resources accessible anywhere from many different form factors, and availability and reliability, where cloud environments have extensive failover support. The key word in the previous statement is potential. Googling “salesforce outage” produces 341K results with information on a number of outages inconsistent with a 5 9’s environment (Note: “5 9’s” means 99.999% availability, or less than 6 minutes of down time per year).

Last, but most important, is cloud’s ability to be elastic, where resources can be acquired as needed from the cloud to scale to the needs of the business and IT. In particular, this saves time, and as the old saying goes “time is money.” The organization is no longer waiting, or that provisioning process is reduced from months/weeks/days to hours/minutes/seconds.

A question I am often asked is, “If one is taking an SOA approach, does that help or hurt with cloud computing?” Let’s answer that question by exploring the three main cloud computing service delivery models:

1. Software as a Service (SaaS)

• SaaS is a cloud service model that allows the consumer to use the provider’s applications running on a cloud infrastructure. The applications are accessible via an interface such as a web browser. The provider is responsible for managing the software, and provides upgrades and shares resources within the cloud infrastructure. Cloud computing enables new users of the software to be provisioned quickly.
• SaaS will obviously work well when there is a single, stand-alone function that is being used. A legacy system typically intertwines and combines multiple functions, database access and customer interfaces. Isolating and integrating the SaaS functionality with what already exists would be difficult, if not impossible. On the other hand, separation of concerns is a key SOA principle, which provides for a layered approach of separating out customer presentation / interface, business processes, feature functionality, and data access. It’s much easier to take a SOA implementation and identify the service or set of services that make sense to replace with a SaaS service or to make that SOA service into a SaaS service itself. This allows users to combine and reuse the SOA and SaaS services in a manner that allows the business and IT to mix, match and extend those services when needed.
• Therefore, some manner of legacy re-factoring that follows SOA principles, as shown in Figure 1, would help set the stage for cloud.

Figure 1. Using SOA to re-factor a legacy application

2. Platform as a Service (PaaS)

• PaaS is a cloud service model that allows the consumer to provision and deploy onto the cloud infrastructure new or additional copies of a hardware architecture and software framework on an as-needed basis. As new users manifest or existing users have increased provisioning needs, the PaaS is able to provide the underlying platform quickly and cheaply.
• SOA is well designed to leverage PaaS given its principle of separation of concerns. As increased load occurs, not only must additional service endpoints be created on a server, but this will also sometimes require the replication of the underlying hardware architecture and software framework on a new server. For SOA, the service bearing the load and its underlying platform need replication, not the entire suite of applications, presentation layer, data layer, etc. SOA is much more efficient, therefore, in using PaaS.

3. Infrastructure as a Service (IaaS)

• IaaS is a cloud service model that allows the consumer to provision various resources. This includes, but is not limited to, processing, storage, and networks where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The provider is responsible for managing these resources and can provision new resources as needed quickly.
• The argument for SOA with IaaS is similar to the one for PaaS above. As SOA breaks down the legacy application into its “separation as a concern” component portions, the need to provision the underlying infrastructure will only be for the component part (e.g., the function endpoint, or the data service or the presentation layer) as opposed to the entire application.

So, my argument in the above description of main service delivery models nets out to a ringing endorsement of the statement that “SOA helps position the organization better for cloud computing.” Of course, saying that SOA can help pave the way for cloud computing and actually getting there are two different things. Being organized the right way. Having the right roles and responsibilities. Doing real application optimization so that you’re best positioned to take advantage of the benefits of cloud computing. SOA can provide these potential benefits to your organization, but the ability to do so as quickly as you’d like can be facilitated by SOA Governance.

As shown previously, a service-enabled organization is going to be in a much better position to leverage the full benefits of the cloud. Successful adoption of SOA invariably requires changes to development processes and individual roles and responsibilities. It requires everyone involved in IT development to take a cross-project, cross-line-of-business enterprise approach to defining common requirements and development priorities. This means applying SOA Governance.

Although there is no single "one size fits all," perfect SOA organizational structure to enable such a transformation, we have found that establishing a small group dedicated entirely to achieving the success of SOA works well in practice. Depending on the individual organization, such a group may be called a SOA Center of Excellence or SOA Enablement Team; alternatively, SOA enablement may be treated as a program and be managed under the Program Management Office or a team under the control of the Enterprise Architecture Board. The name and reporting structure are far less important than the skills used and the analysis, design, development, testing, and operational processes used.

It is absolutely critical that the SOA enablement team include both senior technical and senior business leaders who are sufficiently empowered to help ensure that business and IT interests are fully aligned. The team also needs to have the necessary authority to make and enforce new standards and working practices. Depending on the style of the organization, these new standards and working practices may have to be endorsed by an authority such as an Enterprise Architecture Board or Program Management Office.

An organizational structure to enable services for an organization might, therefore, look something like this:

Figure 2. Organizing for services (click to enlarge)

With cloud, some additional roles and responsibilities are articulated in the Erl et al SOA Governance book that should be considered for addition to Figure 2 or an equivalent organizational chart. A high-level summary is listed here.

Cloud Resource Administrator – one who administrates the cloud service and is “proficient with cloud computing technologies and mechanisms and will typically begin their involvement with the initial deployment of a service.” ³
Cloud Technology Professional – one who is “required to build, deploy, or work with cloud-based services” and “needs to be proficient with the core technologies, technical mechanisms, and fundamental security concerns ... of a cloud environment.” ⁴
Cloud Architect – this specialist is an expert on “cloud-based technology architecture, design patterns, mechanisms” and can author “detailed architectural specifications of cloud-based solutions and platforms.” ⁵
Cloud Security Specialist – one who has “expertise specific to security threats ... pertaining to cloud-based services.” ⁶
Cloud governance specialist – this specialist focuses on governance for “mechanisms, technologies, solutions, and IT resources that reside and operate within cloud environments.” ⁷

Specific cloud governance tasks should be identified as part of your overall governance process. For example, service level agreements (SLA’s) may need to be negotiated and monitored with the cloud provider, even if that provider is an internal source. Patterns of usage for cloud can be defined and then codified and enforced in the governance process. Certainly, the security pattern to be used with cloud is something that governance must help to standardize and enforce, which implies that both design time and runtime governance will be affected.

In the final analysis, you need to be as thoughtful and intentional with your cloud resources as you are with any IT resource.

1. “SOA Governance, Governing Shared Services On-Premise and in the Cloud,” Erl et al. Prentice-Hall, April 2011, www.soabooks.com/governance/ (link resides outside of ibm.com)
2. "The NIST Definition of Cloud Computing (Draft)." National Institute of Science and Technology. January, 2011, http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf (PDF, 186KB)
3. “SOA Governance, Governing Shared Services On-Premise and in the Cloud,” Erl et al. Prentice-Hall, April 2011, p.100
4. “SOA Governance, Governing Shared Services On-Premise and in the Cloud,” Erl et al. Prentice-Hall, April 2011, p. 114
5. “SOA Governance, Governing Shared Services On-Premise and in the Cloud,” Erl et al. Prentice-Hall, April 2011, p. 114
6. “SOA Governance, Governing Shared Services On-Premise and in the Cloud,” Erl et al. Prentice-Hall, April 2011, p. 114
7. “SOA Governance, Governing Shared Services On-Premise and in the Cloud,” Erl et al. Prentice-Hall, April 2011, p. 114