John Reynolds's Blog

SOA: Real Meat, and Potatoes too

The answer probably requires a change of perspective. Jame's falls into the same trap that I fell in... SOA isn't really about a programming paradigm, it's about a product paradigm.

Let me rush to explain....

To programmers SOA looks a lot like OOP (especially a lot like OOP as promoted by the SmallTalk language). Clearly defined interfaces, message oriented invocation, etc. What's the difference?

To product managers SOA looks only vaguely like OOP. SOA is about composing solutions from mostly pre-existing business services (Pay attention to the business services part).

SOA is about Meat and Potatoes programming (programming to pay the bills). It's not really sexy, and it's not really about anything new.

Most companies already have a lot of legacy assets. They are not very interested in developing a wonderful new object hierarchy. They are very interested in squeezing every last bit of value out of a system that they've already paid for. To a product manager, SOA is the lure that a magic "connector" between a legacy asset and a new-fangled ESB (Enterprise Service Bus) will let the company squeeze five more years out of that old COBOL application.

It's the connectors that make the immediate business case for SOA.

Nobody (well, almost nobody) is creating SOA solutions from scratch. Instead, we're figuring our how to duct tape a snazzy JBI connector onto our 20th century legacy code.

I can't blame you if you're still confused. The sometimes mundane reality isn't much like the hype.

Not wishing to end on a down note, I've got to say that once the messy SOA-enabling slogging of today is behind us, SOA should actually be fun to work with. I just hope that I live that long ;-)

Comments

• I found that a very enlightening description John. I just wish the buzzword marketeers hadn't tried to make it sound like a new design methodology. I think that is what really causes most of the misunderstandings. It makes it attract the wrong audience, who in turn leave feeling swindled.

  This is best suited for an ROI pitch to IT management. You know developers; most would love to scrap a legacy IT system, and take advantage of some of the recent advances in computer technology since the 1960's. ;-)

  I think a better name for it would have been: Salvage Oriented Patchwork.

  At least then developers would understand immediately; when the boss says: "We're gonna use SOP to fix this problem!"

  Posted by: cajo on October 05, 2005 at 02:25 PM

• I'm glad that you suggested SOP instead of SOL ;-)

  I really do think that SOA can be a very valuable paradigm for business... it always has been. Loosely coupled services should be much easier to maintain and extend then monolithic applications.

  Perhaps with open standards (this time around) it will catch on and make a more significant difference for the business and IT folks.

  --JohnR.

  Posted by: johnreynolds on October 05, 2005 at 07:23 PM

• Great explanation!

  However, as a developer, I wonder where that leaves room for quality programming when building components for a business's SOA.

  If my brand spanking new component (that can take advantage of whichever whooshy frameworks I fancy) still has to talk to some age-old component using a badly designed database, and make that data available to another age-old component, (with a badly designed importer), what chance do we have for good design?

  Or is that just where enterprise computing is going, and there's nothing we can do about it, I wonder... All patch and no design makes Jack a dull boy.

  Posted by: lee_ on October 06, 2005 at 02:14 AM

• Lee_on,Don't overgeneralize. Many of the COBOL programs out there are very well designed and are built on top of database schemas that have years of tuning and tweaking behind them.Then again, some of the old stuff is crap, but so is some of the new stuff ;-)
  The opportunity that SOA gives us is the ability to wall off all of these modules, and then (over time) replace those that it makes business sense to replace.

  Still, I have to admit that it's a lot more fun to throw everything away and start over ;-)

  --JohnR

  Posted by: johnreynolds on October 06, 2005 at 05:52 AM

• II certainly agree on the squeezing part. But IMHO there's more to the concept than just integrating the legacy part. It's about reusing code and abstracting the interfaces - a fundamental concept that should have been implemented in the earlier days.
  SOA makes companies think over their business processes and focusing on the necessary ones. Business-driven process analysis can really augment the IT landscape on the long run by defining reusable components/process patterns. Once defined many projects can use same functionality without the need to implement them anew.

  Unfortunately in reality SOA is easily misunderstood and talked about as a brand-new technology that has never existed before, people tend to think that patching interfaces will fix all their problems in one swish. Re-painting a building doesn't mean that the substance and fundaments will last longer. It's just about selling the same product in a different package ;) And that's definitely not what SOA should be at all...

  
  

  Posted by: tanses on October 12, 2005 at 07:03 AM

• I agree with you Tanses,
  "SOA makes companies think over their business processes and focusing on the necessary ones. "
  That's the point I wanted to make to James and others... If you try to limit this discussion to a programming paradigm, then you will just confuse yourself. You have to look at SOA in terms of how a business delivers services, and then it begins to make sense. It's more about the business processes (some of which utilize legacy assets) and how they map to the implementation then it is about technology.

  --JohnR

  Posted by: johnreynolds on October 12, 2005 at 11:00 AM

• IBM's SOA product architecture:
  I found a really thorough article by D.F. Ferguson and M.L. Stockton that explains IBM's Service-oriented architecture: Programming model and product architecture

  --JohnR

  Posted by: johnreynolds on October 24, 2005 at 06:08 AM

This work is licensed under a Creative Commons License.