The article “Tension emerges between SOA and mashup camps“makes a very good point about SOA vs. mashup relations.
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 favour 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.”
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 software oriented architecture, just like its predecessor, integration, is a complicated concept that has its own challenges and risks.
Among the challenges SOA presents are:
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 lifecycle 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:
� 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
This article by David Linthicum 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?
Wanna know what awaits service-orienetd architecture in the rest of 2008? Here’s a great article forecasting what’s in store. In short, the author sees a rapid increase in products targetting the SOA market.
In 2008, 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 Web site scale out techniques to increase performance, scalability and reliability.