Service-Oriented Architecture (SOA) is a software architecture in which all operations are encapsulated in small but independent units of functionality (services). These services are defined using a description language and have exposed interfaces that are called by services to perform business processes. These services should be platform-independent.

SOA is not Web Services. Web Services are a set of technologies (including SOAP, XML, UDDI, and others) that can provide a standard data transport and invocation mechanism. By contrast, Service-Oriented Architecture is a design paradigm that is independent of any specific technologies. So it is possible to have SOA without Web Services, and it is also possible to have Web Services without a Service-Oriented Architecture.

In other words, Service-Oriented Architecture is used to design independent building blocks that know how to perform a set of related tasks. Each block can be referenced by other blocks to provide a specific context for operation. In this way, disparate business needs can often be addressed simply by re-arranging these blocks of encapsulated functionality.

SOA is best suited for applications that sit at the core of a business, where modular services are defined and shared across different business domains.

Should you adopt a Service-Oriented Architecture in smaller development efforts? The decision, specific to every organization, should be made by balancing the added functionality and longer life a Service-Oriented Architecture provides against the added cost and development time.

It is my opinion that the decision should not be based on the size of the project, but rather on a forecast of the future use of the functionality provided by the application. If the application implements functionality that intersects different business domains, it is a perfect candidate for a Service-Oriented Architecture.

Today, most enterprise applications are designed and built around usability. Most functionality is based on the different use cases of the application. This typically results in a monolithic application layer that provides the required supporting functionality to every interface involved.

Service-Oriented Architecture takes a different approach. It requires taking a step back and looking at the big picture instead of concentrating on just a single application. When designing an application, you should think about how it will affect other processes, manual or automatic, within your organization. Will it fully or partially replicate functionality of an existing system? Is the functionality shared across different business domains? Does the functionality have a different context in each of them?

By following this approach, you will solve your current business problems while being prepared to face any future challenges. This extends the life of your application, which translates to a better short- and long-term return on your investment.

This new level of abstraction also promotes code reuse. Given that an application was developed following industry best practices, standards, and well-defined patterns, maintenance nightmares become a thing of the past.