I was just catching up on my RSS feeds when I ran across Dana Gardner's latest post, "WOA may soon eclipse SOA as most impactful business transformation agent" which evoked an odd sense of anxiety and the need to immediately jot down some of my SOA thoughts.  In short, Service-Oriented Architecture is a software design principle which attempts to break apart monolithic applications into loosely coupled systems, usually based around business processes.  SOA has been up in our grills for a few years now, and as Gardner suggests the adoption is relatively low for the hype.  I've not checked, but I imagine SOA is in the "trough of disillusionment" on Gartner's hype cycle.  I believe I have some insight into the slow or non-adoption of SOA in the enterprise.

First, as some buzzword compliant IT analysts and IT directors might refer to it, SOA is not a technology.  It's an idea.  You can't rack-and-power it and get warm fuzzies from its blinking LEDs.  It's more like democracy or capitalism.

Secondly, SOA is not a reason.  If an IT director or CIO ever comes to you and says "we're going to rewrite our systems so we can be service-oriented" chuck your mouse at him.  No one should ever set out to intentionally adopt SOA.  Real architects know this and that's probably why the adoption is low.  SOA, like Object Orientation, Web Services, AJAX, etc. are just tools in your toolbox.  They can be used with great affect to solve the right problem.  To be service-oriented for the sake of SOA, or to be buzzword compliant or whatever is to spell certain death.  An SOA strategy is a waste of everyone's time.

SOA is not an efficient method of computing.  The overhead involved in developing applications that are SOA pure is not acceptable in most enterprise applications.  Serialization and de-serialization, network latency and database and storage bottlenecks create very clunky applications for most user-centric software.  Never mind the usually unnecessary hoops a service-oriented architecture forces your developers to jump through to accomplish very simplistic tasks.

Finally, like its second cousin, Object-Orientation, it's actually a modest realization that massive, tightly integrated applications are incredibly difficult to maintain over time.  And once in a while, you write some cool bits of code that would be nice to reuse in other systems.  When you identify those bits, you pull them out for reuse and find a way to expose the code to other applications (sometimes outside the network) and transport data back-and-forth.  And SOA wiggles out of the swamp and breathes air for the first time.  It's evolution.  Most developers have archives of code and designs that are service-oriented long before a term was assigned to the idea.

While properly executed SOAs can present many benefits, such as more manageable code, simplified troubleshooting, easier recovery from failure points, it should be used to solve very specific business problems.  If you need to exchange data or logic between multiple applications and external partners, SOA is self-selecting.  If you have long persistent business processes or workflows, SOA is a great way to partition your workflows into distinct modules.

To close this out, and no offense to tech writers or analysts, SOA is a figment of the collective IT-onlooker imagination.  It's a term we can use to categorize a technique and that's where we should let it be.  In all my architecture sessions, I've never heard the phrase "what we're going to do here is employ a service-oriented architecture."  It doesn't happen like that.  We don't use those that term in practice, only theory.