Mitigating SOA Risks

by Alena SemeshkoMay 29, 2008

Being still confused with integration and mashups, service-oriented architecture possesses a couple of challenges to address.

(Featured image credit)

Table of Contents

What’s in store for SOA?

Here’s a great article forecasting what awaits service-oriented architecture (SOA) through 2008. In short, the author sees a rapid increase in products targetting the SOA market.

“A growing number of SOA deployments will start to adopt open source, such as messaging and service enablement SOA products, and investigate one or more of the cloud-based services available. It also seems likely that SOA deployments will start to adopt some of the newer products based on the large website scale out techniques to increase performance, scalability, and reliability.”

With SOA starting to go open-source and cloud-based, companies now have to sharpen their vision and the tools that get into mix.

SOA, not integration

David Linthicum

David Linthicum, a cloud computing expert, suggests that people seem to be confusing integration with SOA these days. The thing is, integration came first and later on, when SOA came to take its place, a lot of vendors simply started calling their integration tools SOA. David notes, “integration, on its own, is not architecture. Thus, just binding systems together is not architecture, thus not SOA.”

However, if SOA is new and, you can’t argue, the idea behind both of these contepts is fairly similar (instead of building new and duplicating old applications and data, the technology should connect the existing vital parts and build up on them)…doesn’t it sound like it’s just another case of a fresh PR for an old, but improved technology?

SOA vs. mashup confusion

Another article, “Tension emerges between SOA and mashup camps,” makes a very good point about SOA vs. mashup relation. Mashups make SOA real to business users—nothing wrong with that.

…you have SOA practitioners on one hand, calling mashups ungovernable and Web 2.0 camp saying “SOA poisons the mashup well”.

Mashups are simple, convenient, and helpful. I don’t see any reason for them not to be popular. If SOA is a complicated concept, how is it not natural for users to favor a nice and sweet shortcut?

SOA is seen as complex, while mashups seen as an easy shortcut to agility.
“…The approach is not a black and white SOA vs. mashups choice for enterprise integration, but rather, use of mashups for the last mile of integration that may, in many cases, utilize data services, feeds, or other sources that more often than not are exposed as Web or RESTful Services.”

So, it’s not the SOA vs. mashups, it’s the SOA crowned with mashups that would be the right solution. With this approach, the corporate world will be able to “see and feel and touch service orientation.”

SOA elements (Image credit)

Addressing the challenges associated with SOA

As companies go on struggling to get a positive return on investment from SOA, we hear more and more about SOA prjects failing. However, what we don’t see is that service-oriented architecture, just like its predecessor, integration, is a complicated concept that has its own challenges and risks.

It’s dynamic. The products, standards, and requirements keep on changing and maturing, and keeping up with the flow might not be the easiest thing. For companies that have adopted SOA early on this dynamic process is twice as hard to follow.

It’s a twist. Adopting SOA requires that global changes are made in your project life cycle management, as SOA has a very specific infrastructure that needs significant scalability capacities, a fully altered and specific work and design pattern, user training, and performance.

These two challenges associated with adopting SOA enterprise-wide can, however, be addressed.
Here are a few of the risk mitigation steps that you could take as suggested by Eric Roch in his recent blog entry on ITtoolbox:

Eric Roch

* Examine the current architectures and methodology in use and adjust for SOA—an agile OOA/OOD approach with specific SOA deliverables and patterns
* Establish a repository and governance policies for reusable artifices such as interface specifications (design deliverables), schemas and interface definitions (WSDL)
* Develop SOA reference architecture based on design patterns, tool usage and best practices that defines the SOA logical and physical architecture
* Establish a training plan for staff competency
* Acquire message based testing tools and develop SOA Quality Assurance policies and procedures
* Involve operations support early and deploy monitoring and management tools for the SOA infrastructure
* Develop a SOA strategy and roadmap based on business value, risk, business process effectiveness, and IT assets to be leveraged
* Transition to SOA iteratively adding services based on business value and utility of function building the services library over time

With these things in mind, one can ensure a more efficient SOA model.