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 application (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.