service-oriented architecture (SOA)

This definition is part of our Essential Guide: Essential Guide: The latest on enterprise architecture strategy
Contributor(s): David Linthicum and Maxine Giza

Service-oriented architecture (SOA) is an approach used to create an architecture based upon the use of services. Services (such as RESTful Web services) carry out some small function, such as producing data, validating a customer, or providing simple analytical services.

In addition to building and exposing services, SOA has the ability to leverage these services over and over again within applications (known as composite applications). SOA binds these services to orchestration, or individually leverages these services. Thus, SOA is really about fixing existing architectures by addressing most of the major systems as services, and abstracting those services into a single domain where they are formed into solutions.

One of the keys to SOA architecture is that interactions occur with loosely coupled services that operate independently. SOA architecture allows for service reuse, making it unnecessary to start from scratch when upgrades and other modifications are needed. This is a benefit to businesses that seek ways to save time and money.

SOA is known to provide both time-to-market advantages, as well as business agility. The use of orchestration engines, or leveraging development environments that leverage services and SOA, allow those who build applications to do so quickly, since the services provide much of what the application requires. This provides the time-to-market advantage.

Placing volatility into a domain (such as an orchestration engine) allows SOA-built applications to quickly adapt around changing business requirements. In many instances, it's just a matter of re-sequencing the services invoked, or reconfiguring the orchestrations to alter the application.

Simple in concept, SOA is also a best practice to fix broken architectures. With the wide use of standards such as Web services, SOA is being promoted as the best way to bring architectural agility to your enterprise, that is, if you do SOA correctly. The problem has been that the ways that enterprises leverage SOA as an architectural pattern varies greatly from enterprise-to-enterprise. Thus, the ROI from moving to SOA has ranged from great successes, to outright failures.

SOA is a valid approach to solve many of the architectural problems that enterprises face today. However, those who implement SOA typically look at it as something you buy, not something you do. Thus, many SOA projects are about purchasing some technology that is sold as 'SOA-in-a-box.' You get something-in-a-box, but not SOA, and that only adds to the problems.

SOA, as the "A" implies, is architecture. And thus it is the orderly arrangement of systems that best serve the needs of the business. Taken in its literal context, enterprise IT can succeed with SOA. However, most do not succeed and much of that failure is due to the fact that the SOA implementers view SOA as something other than architecture, and most often those implementers are not architects.

While SOA enjoyed varying success in the past, the movement to cloud computing provides some renewed value to SOA. Clouds are typically API- or service-driven, and thus are service-oriented. As cloud computing becomes more popular, more enterprises will rethink the use of SOA, which includes the use of service directories, service governance, orchestration, and other technologies related to SOA.

To explore how SOA is used in the enterprise, here are some additional resources:

The principles of service orientation: SOA guru Thomas Erl explains the fundamentals of service-oriented architecture, including loose coupling, service abstraction and statelessness.

How do SOAP and REST stack up as Web services? REST and SOAP each have their own benefits. Learn when it makes to use one over the other.

Get back to the basics of service-oriented architecture with this SOA Overview: Learn about implementation, registry and repository, governance and management of SOA.

Learn about the different components of service oriented architecture: Take a look at a short list of they key pieces of SOA architecture.

A guide to using SOAP for Web services: Learn about the SOAP standard and when it's best to use it.

This was last updated in December 2014

Next Steps

Enterprises can manage applications using Talend ESB and its open source version, Open Studio for ESB.

Continue Reading About service-oriented architecture (SOA)



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Does your organization use SOAP for Web services, or an alternative?
SOAP and REST are probably the two most complete web services. I have to admit that the challenge of choosing between the two was not an easy one.

However, we picked SOAP for one reason – less coding. We have a lot of work to do so we didn’t want to spend additional time on transaction, security, and address codes.Over time, we’ve also learned that SOAP is much better at handling asynchronous processing and invocation.
Thanks for your input, Abby. It sounds like the REST versus SOAP debate is an ongoing one. 
Earlier in the evolutionary timeline of our SOA environment, we had a pretty even mix of both SOAP and ReST services. As the environment evolved SOAP began to gain prominence, and today is the primary choice for our web services, with legacy ReST services being refactored to use SOAP.
Mccorum, what do you like the best about SOAP?


File Extensions and File Formats