I posted the following as a response to a blog by Ron Blitstein where he states:

"SOA isn’t a product, technology, or service. It is just a body of useful techniques for designing shareable, reusable, interoperable Web services."

Hi Ron,
I'm a long time software developer/architect who has just recently jumped up from the trenches into Enterprise Architecture. It took me a while to understand SOA as a concept. Then one day, I stepped back and understood. SOA is nothing more than software development best-practices applied at the macro scale, to an enterprise full of applications.

Consider a single application. You would never design an application…

…that required the user to have multiple accounts.
…that required the user to move data from one part to another manually.
…that required the user to manually trigger an event across application modules.

You wouldn't do those things, not just because it would make for a unwieldy application, but because when developing a single application, you don't need to do those things. Software developers have all sorts of tools to send messages from object to object, across the network even, without much work. So software developers don't even think about communicating across modules or sub-systems because they usually just need to make a method call to a library and bam, data moves.

Now with the advent of web services (and more importantly, good working web service standards…) it is becoming easier to move data around between applications. Now enterprise architects need to start thinking like software developers, to learn those fundamental best-practices that have been used by software developers for decades. The enterprise will soon become a large and organic collection of applications, with data moving as easily and readily as it does in a single application.

So my advice to enterprise architects? Start thinking like a software developer. If I'm looking for a library to use when developing an application, I'm pretty sure I would stay away from a library that would require the user to login to separately and copy data manually. So don't purchase a piece of software for your enterprise unless it has standardized hooks, ports, buses, etc.

That email server doesn't support IMAP? How then will you pull email into your portal? Skip it…

That accounting tool doesn't have a web services interface? How then will you connect it to your invoicing system? Skip it…

That invoicing system doesn't support SAML? How will you connect it to your authentication service? Skip it…

No standardized interfaces? Skip it… save your money. Put your money into the companies that create applications that meld into your enterprise, not ones that live on an island or only work with other products from the same vendor. It's really that simple…

As a methodology, SOA is just the completion of a great circle. The best part about a mainframe and monolithic application is that everything is in one place, right there, easily accessible. From the users perspective, that is the ideal model. From the developer's and systems architects perspective, it stunk.

So the developers invented OO to break apart their applications and the systems architects broke apart their enterprises so they could pick and choose best of breed applications. Users lost out and have been miserable ever sense.

Now with SOA everyone can be happy, at least for a while. Developers get fine grained modularity with easy access to external systems through standardized interfaces. Systems architects get a modular infrastructure, with the ability to choose solutions across vendors. User will be happy once again, when everything they need to do is back where it was originally, in one place. At least from their perspective.