Skip to main content

Why you should care about SOA again

Developers and software architects are rediscovering the value of service-oriented architecture (SOA), a hot topic 10 years ago, as an approach to modular development and deployment strategies.

Ten years ago, service-oriented architecture (SOA) forced a shift in focus for the development of large-scale IT systems. It might be a stretch to assert that SOA fundamentally transformed programming. But it’s fair to say that it changed the way many of us look at software development. The architecture-centric design made us consider what goes on outside machines, instead of fixating exclusively on what goes on inside them.

And it’s become relevant yet again. SOA’s principles apply to modern development and DevOps initiatives, including microservices, virtualization, business-oriented APIs, and open software architectures.

From a SOA perspective, software development isn’t just about objects and components (as in “object-oriented” and “component-oriented”); it’s also about web services and APIs. It isn’t that services and APIs are better or more useful than objects and components. But they are different, which requires developers and software architects to view the world through a different lens.

SOA basics

“SOA is mostly about the integration of heterogeneous platforms and systems across the enterprise, system abstraction, and the sharing of coarse-grained services across the enterprise,” says Mark Richards, a software architect and author of the book, Microservices vs. Service-Oriented Architecture.

Like microservices, SOA is predicated on a distributed architecture that's more scalable and flexible than traditional monolithic architectures. Most important, perhaps, is that distributed architectures such as SOA are more hospitable to the kinds of modular applications that make life easier for agile developers.

How the right infrastructure can prepare your data center for business disruptors

“I like to think of architectural modularity as providing organizations with increased competitive advantages (i.e., delivering new features, products, and functionality faster than your competitors),” says Richards. At a minimum, he says, modularity improves four of the major elements for remaining competitive in the marketplace: agility, testability, deployability, and scalability.

In praise of modularity

Back when SOA was new, modularity was a big selling point. The implication was that you didn’t have to reinvent the wheel every time you sat down to write code. Not surprisingly, SOA’s ability to deliver modularity is still prized today.

“SOA can help in reducing the complexity of monolithic applications by breaking them into multiple simpler and independent services that can interact with each other through predefined APIs,” says Suman Jana, an assistant professor in the computer science department at Columbia University. “Such clean separation allows the developer to independently update and maintain independent services while keeping API interfaces unchanged. Also, each service can be tuned independently for better performance.”

Reusability was also a key buzzword when SOA took the spotlight. “Twenty years ago, there was a lot of talk about software reuse,” says Arthur Hicken, chief evangelist at Parasoft, a software testing company.

“At the time, reuse meant either consuming a library or more likely cut-and-paste coding,” says Hicken. That creates fragile, unmaintainable code. “When you need to update, fix, or extend an application, the pasted code must be tracked down and updated and everything around them fixed to work again.”

SOA created an environment that encouraged applications calling external APIs. “This means that we are truly independent of the reusable code; it’s a black box to us,” explains Hicken. “Updates always work everywhere because we don’t track down every possible place in the code. It’s just a call to an external function that got updated.”

So what happened to SOA?

Richards hopes that proponents of microservices will avoid the mistakes made by their SOA predecessors. For example, many companies lacked the skills or patience to take advantage of SOA or adopt reusability in a meaningful manner. That led to disillusionment.

“Don't ignore the complications and issues associated with data and databases,” says Richards. “It's one thing to refactor code to create reusable services, but it's another thing to refactor data. In most cases, users won't mind application consolidation or expansion, but they do mind when you start tearing apart or combining databases and playing around with the data.”

As Richards suggests, the brief history of SOA serves as a cautionary tale. After enjoying its moment of fame, SOA was abandoned by many developers—or so it seemed.

“I don't think that SOA ever became irrelevant, but rather the adoption of that pattern grew to a level where it was presumably table stakes,” says Mike D. Kail, co-founder and chief technology officer at Cybric, a security-as-a-service company. (Before joining Cybric, he served in senior executive roles at Netflix and Yahoo.) “I view microservices architecture as SOA 2.0. Let's take the lessons learned and apply them to a new architectural pattern.”

SOA 2.0: Microservices

While the linear relationship between microservices and SOA is open to debate, it’s hard to ignore their similarities.

“Microservices are a particular instance of SOA where each application is broken into multiple fine-grained micro-services that interact over the network,” says Columbia University's Jana. “Maintaining complex software is a major problem. It is not only expensive, but it also affects the quality of the software in the long run by often leading to the inadvertent introduction of buggy code.”

Since SOA components interact through fixed APIs, they can be updated and tuned independently. As a result, maintenance costs can be reduced and failure recoveries are easier with SOA, says Jana.

It’s also easier to update systems and introduce efficiencies that can lead to competitive advantages. Kail recalls how Netflix used service-oriented architecture to migrate successfully from Oracle EBS to Workday Financials, augmented by various integrations through SnapLogic. “Those integrations were all service-oriented and allowed updates and enhancements to occur without affecting the entire monolithic system,” he says.

Richards agrees that by promoting the loose coupling of systems, SOA can reduce the pain of enterprise transformation projects. “I've had success leveraging service-oriented architecture through layers of abstraction (anti-corruption layers) that help isolate change when transforming systems across the enterprise,” he says. “Case in point, I leveraged SOA on a large enterprise transformation project to provide abstraction layers between major systems, allowing for controlled incremental change with minimal impact to afferent and efferent systems to those being transformed.”

It appears unlikely that SOA will be relegated to the dustbin of history. Complex and continually evolving web services like Netflix and Amazon require levels of flexibility and scalability that monolithic architectures are hard pressed to provide.

Whether SOA is technically the grandparent of microservices or merely its cousin is immaterial. What counts is that service-based architectures are here to stay, and that SOA was a crucial step forward in the evolution of modern software architecture.

Rediscovering SOA: Lessons for leaders

  • SOA taught us the value of reusable code components. Those principles apply even more to today's development and DevOps initiatives.
  • Among its virtues, SOA development projects worked to connect previously unrelated silos and speed communication between systems. Those are useful attitudes to adopt for current projects too.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.