Earlier this year, service-orientated architecture (SOA) was pronounced dead by Burton Group analyst Anne Thomas Manes.
Manes' provocative “ obituary ” generated a lot of attention and sparked much-needed debate , but most commentators missed the point. While the title 'SOA is dead' certainly grabbed the most attention, it’s important to remember Manes' position: The approach of service-orientation is still needed, but the three letter acronym S-O-A has become associated with particular technology choices, project failure and unmet IT expectations. That is, says Manes, the acronym S-O-A should die and new approaches and commitment to service-orientation should be embraced.
The people that are burying SOA today are often the same who promoted it a few years ago when J2E was “dying”. How quickly people burn the idols they have created only to idolise another!
All new ideas need time to become accepted. But the global economic downturn may have tightened the vise, so-to-speak, and increased pressure for immediate return on investment, which leaves no time for service-orientation to mature.
Do we ever get something right in the first attempt? In other words, while initial attempts at SOA may fail, that doesn’t prove the principles behind the technology are wrong or without merit.
So what’s wrong with how we’ve been adopting SOA to date?
SOA has been more complicated than expected
Remember, the “S” in SOAP means simple! SOA was supposed to be easier than CORBA and J2E. But why did we expect SOA to be any less complicated than its predecessors?
When you want to design non-trivial business applications by assembling and deploying distributed components, you will likely have to deal with complexity.
Using HTTP / SOAP instead of IIOP and WSDL instead of IDL does not fundamentally change this. The problem is still intrinsically complex.
SOA has been too process-centric
Initial SOA projects have tended to focus on implementing business services in support of high-level business processes or system-to-system integration.
These problems are inherently process-centric. And once again, it was the same with CORBA and J2E. A process-centric approach to SOA adoption might seem a logical place to start, but the result is a veneer of service orientation that degenerates into a business service API with somewhat lower levels of coupling.
Clearly, this is not embracing service-orientation change as Manes calls for.
SOA has failed to increase re-usability
As mentioned above, initial SOA adoption has focused on process consumption of high-level business services.
As a consequence, the depth of service-orientation is “shallow” and limited to portions of the architecture with low levels of reuse. Integration points may now have lower levels of coupling but without foundational reuse, medium-term promises of lower costs have not materialised.
So, with that diagnosis, can we resuscitate service-orientation? I believe the answer is yes and in his blog post responding to Manes, David Linthicum points us in the right direction with "So, if SOA is Dead, Should We Focus more on the Data" where he extols SOA adopters to go “back to the basics” by focusing on data.
Data is fundamental to every business and focusing service-orientation on the problems of accessing, integrating, and consuming diverse, high-quality data via services offers real benefits and opportunities to organisations.
Manes calls for a “commitment to change” for real service-oriented success and data services are just such a commitment.
But what are they? Data services are a design pattern that calls for decoupling data access and integration logic from inside sources and applications and exposing it as a service producing a logical, consumer friendly data object for consumption by many. Data services provide a critical strategy for addressing the inherent quality and fragmentation problems associated with data.
But does the data service approach help address the terminal diagnosis for SOA? Yes!
Data services are a service-oriented pattern independent of technology.
Certainly there are standards such as service data objects and technologies such as data service platforms that offer value, but the key point is that a focus on the pattern of applying service-orientation to the problem of access, integrating, and consuming data can yield significant value regardless of implementation technology. For those who do seek technology to help construct data services, look for solutions that support multiple service-orientation “styles” – web services, REST, mashups, etc. Several exist.
Data services sit at the heart of an architecture
Adopting data services gets to the heart of Manes’s call to return to focusing on architecture and not technology. Data services offer an important transformational architectural pattern to solve critical business problems such as data integration and data quality.
Data services offer significant levels of reuse
Adopting data services offers real opportunity for long-term cost savings from reuse due to the more fundamental nature of data. Maximising reuse, of course, means spending time modeling your data in ways that anticipate reuse across applications and domains, but the effort will be returned multiple times over in the long-term.
Consider that many organisations have existing domain-focused data models that were never implemented or acted on. These models can immediately bootstrap a data services effort. And don’t forget to think about data services reuse at varying levels from fine-grained to coarse grained. Don’t fall for the same trap as before and focus just on data service reuse at the business service or integration boundary.
Manes concludes: “Incremental integration projects will not lead to significantly reduced costs and increased agility. If you want spectacular gains, then you need to make spectacular commitment to change.”
Service-oriented success depends on our renewed commitment to architecture and data services offer a vehicle for that commitment. SOA as integration veneer is dead! Long live SOA as architecture and data services as a fundamental mechanism for applying service-orientation to critical business problems.
Brad Wright is a senior product marketing manager for DataDirect Technologies, a comprehensive provider of software for connecting disparate crucial business applications to data and services. He can be reached at [email protected]