Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Book Excerpt and Interview: Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide

Book Excerpt and Interview: Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide

A new book by David Linthicum, Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide, describes how to get the enterprise ready for cloud computing by carefully modeling enterprise data, information services and processes in a service oriented manner to make the transition to providing and consuming cloud services easier.

The book is a high level prescriptive guidance on the approaches to moving enterprise services and business processes to the cloud. David starts the discussion of his book with the “why?” of moving to the cloud and he goes on to define the cloud computing and the various components that make up cloud solutions, i.e. Storage-as-a-Service, Database-as-a-Service, Information-as-a-Service, Application-as-a-Service etc. and examines the need and business drivers for moving such services to the cloud.

In his book, David suggests a bottom-up approach starting from modeling the data, then the services that move the information to achieve business activities and finally the process that tie these activities together. He advocates modeling the governance of these services and processes and a plan to test these processes in the cloud.

Addison-Wesley / Prentice Hall provided Infoq readers with the excerpt describing techniques modeling the data and services for the cloud. The excerpt is a condensed version of the following chapters from the book.

  • Chapter 5: Working from Your Data to the Clouds
  • Chapter 6: Working from Your Services to the Clouds

InfoQ spoke with David Linthicum to learn the motivations behind the book and learn from his experience in moving service orientated enterprises to the cloud:

InfoQ: A year ago this time, we saw an article that sent ripples through the SOA community; Specifically it asked the question, "Is SOA Dead?" This brought out a lot of conversations on SOA adoption, its interpretation and specifically how a successful SOA needs to be implemented. What are the kinds of changes you are seeing that in your opinion are lessons learned from those conversations?

DL: SOA is a complex distributed architecture that many organizations struggled with, which drove Anne to make that provocative statement.  Keep in mind the article was actually titled “SOA is Dead…Long Live Services,” the notion being that SOA was complex and difficult to do, but the use of services, on-premise and cloud-delivered, continued to be a focus.

SOA is not dead.  Indeed, the emerging cloud computing space makes SOA more popular than ever as an approach to leverage cloud computing, as I covered in my book.  Lessons learned would include: Don’t take on the entire enterprise your first time; instead take an incremental approach to SOA.  Also, it’s not a best practice to toss technology at a SOA, such as ESBs, design time governance, and other technologies that simply provide bits and pieces of the solution, and not the solution itself.  Finally, leverage cloud computing-based systems as the first generation of your SOA, get that right, and incorporate those patterns into your internal architecture.

InfoQ: The “SOA is Dead… Long live services” meme surfaced a lack of consensus on what's involved in successfully implementing a SOA and its common belief that tool vendors aren’t really helping shape that discussion in a tool agnostic fashion. How is this impacting SOA adoption and consequently cloud adoption in the enterprise, if at all?

DL: SOA is an architectural pattern, as I stated above.  Thus there will be different ways in which those patterns get implemented.   To address your point, indeed, the issues around SOA were and are around the lack of consensus as to what a SOA is.  Many people service-enable their systems, and call it SOA.  They end up with JBOWS, or just a bunch of Web services.  Moreover, the SOA technology vendors have further confused the issue, promising the world but delivering reasonable results. You should promise reasonable results, and thus achieve reasonable results.  

In my book I look at SOA as an approach to architecture, and a better way to leverage cloud computing resources.  The concept is to view cloud computing within the context of architecture, as an architectural option.  Other options would be to approach cloud computing as a tactical or one-off solution, which is what most people do today.  The fact of the matter is that you need a larger plan to bring true efficiency to your enterprise, and the use of cloud computing should be part of that plan.   

InfoQ: The cloud is inherently a platform for the Web and as such much of the play in the cloud computing space is on RESTful systems that leverage the properties/characteristics of the web. How do you view concepts such as WOA in relation to SOA, and their play in the cloud platforms?

DL: WOA is a concept that came out of the use of cloud computing as an architectural concept that typically considers the rise of SaaS and other enterprise applications that can be delivered out of the cloud.  Indeed, most of those patterns are outlined in my book.  SOA plus cloud computing is really WOA, as most understand it. 

InfoQ: Your book is about the convergence of two concepts, SOA and Cloud Computing. SOA enjoys credibility and adoption in the enterprise because of evolution of the practice over the years and capabilities and maturity in terms of governance, tools etc. The web/cloud on the other hand is all about ad-hoc integration via Mashups, social networking, API’s etc. i.e. engineering by the masses; where the maturity of tools and platforms are very different. How do you see SOA bridge the two paradigms of the Enterprise and the Cloud?

DL: SOA has never been an enterprise-only concept.  Cloud computing goes well beyond mashups and social networking with the appearance of major cloud computing players such as AWS that provide many of the things you’ll find in a traditional data center.  SOA and cloud computing is all about extending your architecture outside of your firewall to take advantage of these resources.  However, the innovative nature of the Web is going to lead to exciting opportunities with cloud computing, such as mixing and matching things such as unstructured Web data, social networking APIs, etc.  The Web is a living, breathing, fast moving thing, and the emerging cloud computing provider will take advantage of them.    

InfoQ: All cloud providers offer a certain level of governance. In the book, when you refer to cloud computing needing governance solutions what did you mean? Would you say cloud solutions require different levels of governance under the broad umbrella of design/runtime governance?

DL: Cloud computing involves sets of services, and thus how those services are leveraged really needs to have a well thought-out governance plan, and technology, to make sure those services are not leveraged or changed without some type of centralized control.  Thus we have the need for service governance.

The type of governance technology you need is dependent upon the type of problem domain you’re working with, and there are varying levels of governance you’ll require.   For instance, most systems that leverage cloud-delivered services, such as APIs, should implement a service governance plan, and then select the right service governance technology, such as AmberPoint (recently aquired) and Layer 7.  This technology allows you to create policies that control access to those services. Governance planning and modeling is outlined in the book, including steps to determine the right governance technology you’ll need to leverage.  Within cloud computing, this typically means runtime governance with well-integrated security. 

InfoQ: The guidance you provide in your book for governance is via defining/designing and implementing policies. Now some of these policies and the enforcement of them are provided by the cloud providers. How would you advise enterprises to go about defining strategies creating domain policies? Are there solution/ products available that work with solution domain policies?

DL: Cloud providers furnish some governance, but typically it’s only around their own service.  Thus, you need a set of technologies that span cloud providers, as well as on-premise services.  This is usually provided by run-time governance providers that exist in a centralized location, often on-premise, and enforce polices for cloud-delivered and on-premise services. 

I would suggest that you do the following:

First, create a governance model that defines your governance strategy for your organization.  This means cataloging all of the services within your problem domain, and how those services should be leveraged.  Make sure to consider security.

Second, select the right runtime governance technology that’s right for your problem domain. I’ve list a few examples above. Again, these are systems that allow you to create and enforce polices around services.  

Finally, you’re going to need to monitor the governance of these services, making adjustments as required.    

Moving forward, I suspect more and more of this service governance will come out of the cloud, perhaps from clouds that just provide governance, or governance-as-a-service. 

InfoQ: The chapter on defining the information model goes in good depth as to how one can produce an information model using the data-first approach to service modeling. How do you approach the notion that a given data model in a catalog can have multiple representations in different systems? For example, a customer in a CRM system might be very different than the customer in a SCM system. What advice would you give readers on consolidation and representation of different "views" on a domain model?

DL: Great point.  This is why it’s so important to get the data model correct before building services so it works with all types of service representations.  Moreover, I also recommend leveraging an abstract data services layer to remap schemas, if needed, so they best represent the view of the data required to support a particular service.  Using these approaches and technology, your data model will support any number of services, now and into the future.

What are your recommended strategies in thinking about versioning of various components in the cloud solutions:

- Information Model

- Service Model

- Process Model

The information, service, and process should all be under a single governance framework, including the use of data and service governance technologies.  As part of the governance model and solution, there will be a version tracking component that will persist across instances of the information, service, and process model, at a specific period of time.  Along with a well thought out release management approach, which is well integrated with the governance technology, you should also be able to track changes to the architecture as they occur.

InfoQ: In your book you briefly touch upon risks on moving the enterprises to the cloud. In particular, there is always the danger that a provider might be vulnerable either financially or natural disasters. How can an enterprise protect its investment and mitigate the risk of moving to the cloud? For example, the provider shuts off access in response to a billing dispute or a more recent phenomenon similar to Google pulling out of China, etc.

DL: When using cloud computing resources, I recommend that you always consider the worst case scenario, and take reasonable steps to protect the enterprise.  Things to consider, include:

Make sure to have an up-to-date copy of the data on-premise, if that’s possible.  In case of things going hugely wrong, you can at least get access to the information you need to run the business until you find another cloud provider or on-premise solution.

Make sure you know who you’re getting into bed with.  Vet the cloud computing provider.  Make sure they don’t have a history of withholding access, outages, and are strong financially. 

Never, ever leverage cloud computing systems that leverage proprietary database and programming approaches.  You’ll have nowhere to take the code and the data, if the company goes south. 

Plan for these issues ahead of time.  I tell my clients to have an emergency plan in case of outages, provider issues, and natural disasters.  What will you do?   What’s plan A, B, and C?

InfoQ: Finally, "Cloud computing using SOA" OR "SOA using cloud computing" Why?

DL: It’s SOA using cloud computing.  SOA is the guiding principle of the architecture.  Cloud computing is just an architectural option of leveraging systems that reside outside of the firewall.  SOA is about the holistic use of IT resources in ways that are most efficient, and changeable in support of architectural agility.  Cloud computing is just a way of leveraging those resources. 

Rate this Article