The Best SOA: Keep It Loose, Very Loose

SOA in Action Blog

« 2007 Will be the Year of the ESB... What's an ESB Again? | Main | To Do SOA Right, Forget About Technology »

January 02, 2007

The Best SOA: Keep It Loose, Very Loose

Is SOA "Same Old Architecture"? It shouldn't be.

Building service-oriented architecture calls for fresh thinking on many levels, often at odds with tried-and-true, familiar IT approaches. Namely, that the successes of SOA often will not immediately be seen and felt by the business; and that applications should not be built for the ages. The goal of SOA is to increase flexibility, through the decoupling of both systems and processes.

Two recent articles cast some light on this new thinking. In a report in Computing Canada, Bruce Johnson, a partner and consultant at Toronto-based ObjectSharp.com, observes that "If done properly, an end user should never know whether SOA is being used or not." The challenge is that for the most part, "SOA may very well be invisible to most of its stakeholders."

Thus, management buy-in becomes a challenge, since SOA isn't tangible, and its results aren't necessarily tangible. "They are likely to say, 'Why did you spend six months on this and not change anything?'" Johnson warns.

Loose coupling is the key, Johnson is quoted as saying. "SOA is more of a philosophy than a technology. It requires a shift in mindset because developers no longer need to know what specific objects will be used for - instead, they need to develop things with a final outcome in mind."

Loose coupling is the goal, and many of today's systems are coupled too tightly, according to a new article in Linux Sys-Con. SOA should reduce such coupling on two levels: Technological coupling, which deals with transport protocols, data encoding schemes, authentication mechanisms, and is often the result of decisions made by system architects; and functional coupling, which deals with interaction and exchanged data, often the result of decisions made by analysts and domain experts.

The problem with tightly coupling systems is that it assumes that applications are systems created to last forever. They shouldn't be, and SOA is all about agility to change on a moment's notice. "The technology is always improved, new data is collected, organizations are restructured, merges occur, and new laws and regulations are passed," the article notes. "High coupling is a trait that complicates systems maintenance and makes it more expensive to manage. Highly coupled solutions are more difficult to modify since changes made in one place cause changes to be made somewhere else."

Posted by joemckendrick in SOA | Digg This | Add to del.icio.us