Four Ways to Explain SOA

Share it on Twitter  
Share it on Facebook  
Share it on Linked in  

Last week, I wrote about Anne Thomas Manes' claim that SOA is failing at many of the companies with which she's engaged as a Burton Group consultant. You may have missed this, since I put it at the end of a longer post on defining a service.


Of course, I wasn't the only one who noted Manes' rather gloomy remarks about service-oriented architecture. Joe McKendrick at ZDNet wrote a post about it Sunday, focusing on Manes' remarks about how SOA is still siloed within IT.


It's an interesting observation, and one that speaks again to the question of whether you need to talk about SOA with the business. McKendrick, a SOA advocate, says it's time to educate the business about SOA and tie some key performance indicators to its results. The problem is SOA may not pay off for some time, and, as McKendrick points out, its benefits are often soft and fuzzy, which can be problems as key performance indicators.


His post attracted some interesting comments, too. While most seem to agree IT needs to educate the business on SOA, one reader called SOA a "flash in the pan," noting:

"Most companies don't want to wait years for their investment to bear fruit. To many things can happen in that length of time. This is why SOA will never be as good in practice as it is in theory ... NO investment is worth making if it doesn't increase the bottom line."

You may disagree with his premise, but you still need to consider: Will business leaders share his sentiment?


While it is true that the business may not appreciate the technical aspects of SOA -- or even want you to introduce another IT abbreviation into their lexicon -- SOA is reaching a point where you need to find a way to explain it to business people and, yes, even "sell" them on the concept. Because, apparently, they aren't buying it, and in this economy, you may not be able to afford SOA based on an argument that amounts to "It's too technical for you. Just trust us."


I've found four resources to help.


Mike Kavis shared his ideas on explaining SOA's value in a recent IT Toolbox post. He mentions business process management, sometimes called the "killer app for SOA."


He also discusses service reuse, which he explains with the well-known Lego metaphor. Although integration and SOA expert David Linthicum and others contend service reuse isn't a primary value proposition for SOA, it does at least have the advantage of a good metaphor.


And, as this 2007 Tech Target article explains, the Lego metaphor can be used to explain other aspects of services.


I'm also fond of the fast-food metaphor, which I found on IT Toolbox. It does a better job explaining the various components of SOA than the Legos metaphor.


You could also just try using a business metaphor. This is the approach David Sprout, a founding member of the CBDI Forum, advocated long, long ago -- like in 2006 -- because he believed the Legos metaphor was fundamentally flawed. Instead, he suggested you explain SOA by comparing it to service contracts.


But perhaps what's needed isn't so much a metaphor for SOA as a straight-forward explanation of SOA's benefits. For that, check out Harriet Fryman's Seven Principles of SOA, which is what the senior director of product marketing for Cognos uses to explain SOA to Cognos' clients.