Much has been written about the latest buzzword to emanate out of the cubicles of IT shops and, surprise surprise, it's another acronym. SOA stands for Service-Oriented Architecture, and has been around for many years. In recent months it has taken off, with vendors, professional service firms, webzines, and my plumber Jim all providing their own definition and explanation, pro and con. In the vendor space, IBM is now packaging 13 (not a typo) websphere and Tivoli products around SOA. However, finding a common understanding, let along simple definition of SOA is not easy.

So what is all the buzz about? Wickepedia defines SOA as such:

In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, nodes on a network[1] make resources available to other participants in the network as independent services that the participants access in a standardized way. Most definitions of SOA identify the use of Web services (i.e., using SOAP or REST) in its implementation. However, one can implement SOA using any service-based technology.

And the definition goes on and on like this, smelling very much like the latest brew to come pouring out of the IT department down in the bowels of the company's basement.

As the technical architect on a project that is on the SOA path, considerable effort has been spent trying to determine what SOA truly means to a project, and to the company's strategy and growth plans.

As my current project evolves I plan to keep an active journal detailing what goes right, and not so right related to SOA. For this first post, here's a quick summary of what SOA means to me, and how it most relates to the success or failure of the engagement:

SOA is not so much an architectural framework, or a set of architectural best practices, or a specific vendor solution, as it is a guiding principal or philosophy around the purpose a software project or packaged vendor solution lives for. Those people controlling the purse strings in an organization are very concerned about the real ROI a project is forcasted to bring back. What SOA brings to the table, more than anything else, is the opportunity for greatly expanded returns the investment in the project required. This is accomplished through the extensibility and ubiquity. An example might help to best describe this.

If I did everything correct as the software architect on a project to custom build a solution.. everything "by the book", and created course-grained, stateless interfaces that abstracted the complexity away from the consumer, and incorporated other best practices into its design.. BUT, I used a .NET remoting solution as the transport protocol because it offers higher performing working software, the central tenet of SOA has just been violated.

That is, my solution may be solid in every way, except I just forced my new partner, or the latest company merger to move away from their Sun/Java shop.. and the huge costs associated with it, and instead, to spend lots of money and resources purchasing Windows, and .NET, because the "perfect solution" you created requires .NET on both the client and server. The reach of the service interfaces created, and extending them to my business partner just got more expensive.

Forcing the consumers of your services into one particular vendor's technology in order to be used might be a perfectly valid solution.. perhaps the best solution, but it's not SOA.

By utilizing XML, web services, SOAP, and other vendor-neutral technologies, your services just became available to a far larger pool of consumers. By creating a framework that is consumable by whomever.. or whatever platform is the preferred flavor of your organization, an investment in a long term growth strategy can be more easily realized.