Moving the SOA Goalposts

Posted by Boris Lublinsky on Oct 18, 2008

Sections

Enterprise Architecture

Topics

Enterprise Architecture ,

SOA

Tags

Buzzwords ,

SOA Adoption

In one of his latest post, John Evdemon is showing industry's attempt to define, redefine and contradict itself regarding SOA. The definitions went in all possible directions with no consistency

First it was about loose coupling in general:

With the advent of Web services and SOA, we've been seeking to create architectures and systems that are more loosely coupled. Loosely coupled systems provide many advantages including support for late or dynamically binding to other components while running, and can mediate the difference in the component's structure, security model, protocols, and semantics, thus abstracting volatility.

Then reuse took the center stage:

Software reuse is not new in as much as the core idea is to get more value from what has originally been built. Prior to SOA, a lack of centralized control and communication between business units within organizations caused same solutions to be reinvented over and over again. To ensure that duplicate services are not created across the business units in an organization, SOA stakeholders such as business analysts and architects should be able to find existing business services and evaluate their usefulness for reuse in a well-known and systematic way.

Until it was discovered that true reuse is way too complex and is not always achievable:

Creating services that can be reused requires predicting the future... how can a service’s creators accurately guess what future applications will need? The "If-you-build-it-they-will-come" approach is tough to turn into real reuse. Plus, there are few, if any, organizational incentives to build a component that can be reused by other groups.

Then it became about loose coupling of business processes :

Hard wiring processes should be a sin, let’s do away with it once and for all... loose coupling will force us to rethink all aspects of business activity... It will have profound impact on the way we manage business operations. The thick process manual remains a testament to our hard-wired approach to business operations. Specify all activities in great detail in advance and then carefully monitor all activities to wipe out any variations from standard. Tighten operations as much as possible. Loosely coupled business processes operate in a very different way.

At some point SOA became not sufficient, Event Driven Architecture (EDA) became (a more popular) SOA replacement.:

EDA delivers the loose coupling that is only promised - but not delivered - by SOA. It is not a synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa; components are loosely coupled in the sense that they only share the semantics of the message.

Then it was about Business/IT alignment:

From its humble origins in object-oriented design and component-based software development methodologies, SOA has moved into a rarefied realm of expectations. SOA, the story goes, isn’t merely designed to remake IT; it’s going to be a magic bullet to transform the businesses that IT serves too.

And finally it was discovered that SOA has nothing to do with technology:

It’s amazing; SOA seems to be the first technology that doesn’t require technology. The big vendors say it doesn’t really matter [what] you do in technology terms, so long as you follow the road of SOA-based architectures.

This remarkable inconsistency of definitions seems to stem from several major factors:

• As any architecture, SOA as fairly complex and has multiple concerns. As SOA implementation experience grows, both architects and developers discover more things they need to start considering as part of these implementation. This is not really moving the goalposts, but rather realizing the true size of the "playing field".
• People are often more concerned with being "fashionable" rather then correctly defining what exactly they are doing. Considering current SOA popularity, many things are being artificially brought into SOA not because they belong there, but rather because the term got CEO/CIO attention. This is not really moving goalposts, but rather using popular terminology to get more attention from the management.
• People tend to be constantly mixing SOA architecture with SOA platforms/implementations. While SOA architecture does not change, the goalposts for platforms/implementations should be constantly moved to better support customer’s requirements.

1. Back to top

   SOA as an Architecture Style

   by Mark Richards

   I think the last point in this posting pretty much sums up the problems in the industry with regards to SOA:
   
   "People tend to be constantly mixing SOA architecture with SOA platforms/implementations. While SOA architecture does not change, the goal posts for platforms/implementations should be constantly moved to better support customer’s requirements"
   
   We all too often think of SOA in terms of the technologies, implementation strategies, and products, and ignore the true underpinnings of SOA - that it is an architectural pattern. Great message to get out there - thanks!

   Reply

2. Back to top

   RE: Moving the SOA Goalposts

   by Robert Morschel

   Its not that the goalposts have moved. Its the fact that SOA has descended to earth and people are realing that the hype doesn't always meet the reality. I sometimes think the subtext on SOA should be "Mything in action".
   
   To me, SOA is much more about organisational mindset than technology. The technology is hard, sure, but getting the business to pay for it, whilst sacrificing tactical agility at the expense of strategic responsibility - that's the challenge.
   
   Robert
   soaprobe.blogpsot.com

   Reply

3. Back to top

   Re: RE: Moving the SOA Goalposts

   by Jeff Goers

   Right - SOA is not a technology in itself, rather it is an approach and mindset to building systems and business processes.

   Reply

• Older >