SOA (Service-Oriented Architecture)

menu icon

SOA (Service-Oriented Architecture)

Explore SOA (service-oriented architecture), an important stage in the evolution of application development and integration.

What is SOA (service-oriented architecture)?

SOA, or service-oriented architecture, defines a way to make software components reusable via service interfaces. These interfaces utilize common communication standards in such a way that they can be rapidly incorporated into new applications without having to perform deep integration each time.

Each service in an SOA embodies the code and data integrations required to execute a complete, discrete business function (e.g., checking a customer’s credit, calculating a monthly loan payment, or processing a mortgage application). The service interfaces provide loose coupling, meaning they can be called with little or no knowledge of how the integration is implemented underneath. The services are exposed using standard network protocols—such as SOAP (simple object access protocol)/HTTP or JSON/HTTP—to send requests to read or change data. The services are published in a way that enables developers to quickly find them and reuse them to assemble new applications.

These services can be built from scratch but are often created by exposing functions from legacy systems of record as service interfaces.

In this way, SOA represents an important stage in the evolution of application development and integration over the last few decades. Before SOA emerged in the late 1990s, connecting an application to data or functionality housed in another system required complex point-to-point integration—integration that developers had to recreate, in part or whole, for each new development project. Exposing those functions through SOA eliminates the need to recreate the deep integration every time.

Note that although SOA and the more recent microservices architecture share many words in common, they are only loosely related and, in fact, operate at different scopes, as discussed later in this article.

What is an ESB?

An ESB, or enterprise service bus, is a pattern whereby a centralized component performs the integration to the backend systems and then makes those integrations available as service interfaces. It performs translation of data models, deep connectivity, routing, and potentially composition of multiple requests, and it makes these available as a single service interface for reuse by new applications. The ESB pattern is typically implemented using a specially designed integration runtime and tooling that are well-suited to the above capabilities, ensuring the best possible productivity.

In theory, you could implement an SOA without an ESB, but application owners would each have to find their own unique way to expose service interfaces, which is a lot of work (even if the interfaces are eventually reusable) and creates a significant maintenance challenge in the future. In fact, ESBs were, eventually, considered such a de facto element of any SOA implementation that the two terms are sometimes used synonymously, creating confusion.

Learn more about ESBs by reading "Introduction to ESB (Enterprise Service Bus)."

Benefits of SOA

Compared to the architectures that preceded it, SOA offers significant benefits to the enterprise:

  • Greater business agility; faster time to market: The efficiency of assembling applications from reusable service interfaces, rather than rewriting and reintegrating with every new development project, enables developers to build applications much more quickly in response to new business opportunities.
  • Ability to leverage legacy functionality in new markets: A well-crafted SOA enables developers to easily take functionality ‘locked’ in one computing platform or environment and extend it to new environments and markets. For example, many companies have used SOA to expose functionality from mainframe-based financial systems to the web, enabling their customers to serve themselves to processes and information previously accessible only through direct interaction with the company’s employees or business partners.
  • Improved collaboration between business and IT: In an SOA, services can be defined in business terms (e.g., ‘generate insurance quote’ or ‘calculate capital equipment ROI’). This enables business analysts to work more effectively with developers on important insights—such as the scope of a business process defined by a service or the business implications of changing a process—that can lead to a better result.

SOA Examples

By 2010, SOA implementations were going full steam at leading companies in virtually every industry. For example:

  • Delaware Electric turned to SOA to integrate systems that previously did not talk to each other, resulting in development efficiencies that helped the organization stay solvent during a five-year, state-mandated freeze on electric rates.
  • Cisco adopted SOA to make sure its product ordering experience was consistent across all products and channels by exposing ordering processes as services that Cisco’s divisions, acquisitions, and business partners could incorporate into their web sites.
  • Independence Blue Cross (IBC) of Philadelphia implemented an SOA to ensure that the different constituents dealing with patient data—IBC customer service agents, physicians’ offices, IBC web site users—were working with the same data source (a ‘single version of the truth’).

SOA vs. microservices

Experts have filled a few thousand of print and digital pages comparing SOA and microservices and defining the subtleties of their relationship to one another. For the purposes of this article, the chief differences between the two are the coupling of components and scope of use:

  • SOA is an enterprise-wide concept. It enables existing applications to be exposed over loosely-coupled interfaces, each corresponding to a business function, that enables applications in one part of an extended enterprise to reuse functionality in other applications.
  • Microservices architecture is an application-scoped concept. It enables the internals of a single application to be broken up into small pieces that can be independently changed, scaled, and administered. It does not define how applications talk to one another—for that we are back to the enterprise scope of the service interfaces provided by SOA.

Microservices architecture emerged and gained steam with the rises of virtualization, cloud computing, Agile development practices, and DevOps. Most of the advantages of microservices in these contexts arise from the complete decoupling of the components, which simplifies and improves the following:

  • Developer agility and productivity: Microservices enable developers to incorporate new technologies to one part of the application without catching up the rest of the application. Any component can be modified, tested, and deployed independently of the others, which speeds iteration cycles.
  • Scalability: Microservices can take maximum advantage of cloud scalability—any component can be scaled independently of the others for the fastest possible response to workload demands and the most efficient use of computing resources.
  • Resilience: Again, thanks to decoupling, the failure of one microservice does not impact the others. And each microservice can perform to its own availability requirements without staking the other components or the entire application to greatest common availability requirements.

For a deeper dive into the differences between SOA and microservices, see "SOA vs. Microservices: What's the difference?"

In the same way that microservices architecture has the potential to bring improvements in agility, scalability, and resilience to application design, these same techniques can also be applied to integration. This is important because, over time, the heavily centralized ESB pattern and its associated centralized team of integration specialists can become a bottleneck. Borrowing from microservices principles, we can potentially break up the ESB into a more fine-grained, decentralized integrations. This is one of the core premises behind agile integration.

SOA and IBM Cloud

As your company shifts its IT infrastructure toward a hybrid cloud approach, there’s a high likelihood you’ll be transforming a variety of workloads, including those based on SOA, to more lightweight and flexible cloud deployment models. IBM is one of the pioneers of SOA, and IBM Cloud offerings and services can leverage and extend your existing SOA investments to the cloud.

Take the next step:

SOA provides the ability to make services consumable in different channels no matter where the core application or database lives, which helps your organization capitalize on investments as it modernizes applications on the journey to cloud.

Get started with an IBM Cloud account today.