CIO's Nicholas Petreley takes SOA pundits to task for fussing over all the definitions for SOA that we've been toying with, from business processes to Web Oriented Architecture.
In his most recent post, he suggests this "definitive definition" of service oriented architecture:
"SOA is a networked subroutine."
I can see what Nicholas is getting at -- after all, SOA is built exposing selected portions of applications to the network. And this is proving to be a very effective methodology for moving to a more online, agile organization. As he put it:
"SOA benefits from the experience we have gained from all that preceded it. SOA is growing in popularity now because the tools to create SOA are now available and easier to use than ever. Average programmers now have enough experience under their belts to be able to understand SOA and code it, and that is why SOA is increasing in popularity. We could have reaped the benefits of SOA ages ago, but fewer people knew how to get there, then.
When you get down to it, all SOA really amounts to is extracting something you would normally program into a monolithic application and running it as a service that two or more applications can access over a network. That, my friends, is a networked subroutine."
Again, I can see Nicholas's point, but I don't think his concise definition covers the "A" in SOA, which is "architecture." An architecture is not a subroutine. SOA is an approach to solving a business problem (or scientific problem, as Nicholas suggests.)
Perhaps the best short definition of SOA is in the term itself: SOA is an architecture of services. (My two cents.)
For a more detailed definition of SOA, check this write-up here at JavaWorld, written back in 2005. (Thanks to reader Joe Martin for surfacing.)
"Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services' underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language."
There are definitely simpler ways to say this, but the definition hits upon the key points.
Another important point, as reader and contributor Rob Eamon frequently points out: the architectural aspect of SOA is something many lose sight of. "SOA is about architecture, not programmers. It is a concern of architects, not programmers. It is a style of architecture, not programming."