Is SOA Passé?

Bob Ivkovic, Principal of IT Architects

February 2, 2019

A client recently asked me if Service-Oriented Architecture (SOA) is still relevant.  I explained that SOA is still relevant as ever, although Application Programming Interface (API) is all the buzz at the moment.  This is really a technical discussion but I’ll try to explain it in business lingo.  From my point of view as an architect, the difference is really in the implementation. Conceptually, both SOA and API serve the same purpose – they abstract the implementations of the provider and the consumer “service”.  SOA is associated with XML and SOAP, while API is implemented using REST/JSON.  However, like most technologies, SOA (SOAP and XML) technology is being replaced with API (REST and JSON). The key reasons are ease of use and performance.  And we all know that business adores both of those things.  So, if people like me argue that SOA is still relevant, then it has to be from an architectural perspective, as the integration patterns are basically the same.  Developers may argue with me because they rarely look at an architectural perspective, but rather at the implementation approach.  And if it’s not the “latest and greatest”, then they’re ready to accuse us architects of going down the wrong path.  It’s a pity that architects can’t program.

Let’s face it, most SaaS solutions support both SOAP and REST services.  It’s all about the money, not to mention that solution providers support integration standards – both old and new.  With that said, I would suggest that if there are no legacy SOAP web services around, then just go with REST services, especially if you’re integrating with other cloud-based applications like Salesforce.  This result in a longer solution life span until some genius comes up with the next integration technology to replace REST.  Anything can happen in this supersonic evolution of technology.  When I started this business, we used archaic data extracts and loads to transfer data between systems.  I’m glad those days are over.

Although APIs are the new wave integration building blocks, they share essentially all of the basic architectural principals as SOA.  When it really comes down to it, they both support business through linked services.  The only difference is that APIs are more open, easily consumable, and support human-readable formats (JSON). APIs are also gaining popularity among sophisticated integration software companies, which have a requirement to integrate with external entities.  This has resulted in branding and marketing of a more “open” and “easy-to-use” middleware integration technology.  Software companies like MuleSoft provide an integration platform-as-a-service (iPaaS) software for connecting applications, data, and devices of all complexities.  Their success is based on providing software that makes it easier and faster for companies to integrate legacy systems, ERPs, COTS systems of differentiation, home-grown applications, and anything else that requires integration and communication.  And this has all been made possible by offering APIs that are more open, easily consumable, mobile friendly, and more business oriented.  However, from an infrastructure, manageability and governance perspective, APIs are not much different from SOA. 

I make my stand that SOA is still relevant from an architecture perspective, and the real differences come to bear from an implementation perspective.  If we consider this SOA vs API debate from an architecture perspective, they both do the job as integration solution contenders.  The critical success factor comes down to “governance”.  In either case, we need governance to enforce the right level of operational and policy controls, and provide effective monitoring, analysis, and improvement processes.  It’s really too bad that the word “governance” often scares away developers.  At the end of the day, it is critical that organizations build services to meet their business requirements, ensure that these services meet the security and compliance standards set by industry, and that changes in their infrastructure do not break the integration landscape comprised of hundreds or thousands of apps that count on these APIs to allow them to communicate with each other. 

The following are five design considerations when assessing SOA versus API platforms:

1. 1. SOA is more mature as an architectural best practice for building de-coupled applications and promoting service re-use, and for this reason, it has allowed organizations to mature its governance processes. Although API is not as mature, it has allowed organizations to be nimble in creating services and making them available in an open fashion without the governance maturity.  Thus, there is a trade-off between governance and technology advancement.
   2. APIs can be used for both external and internal use-cases. APIs are also more open, well documented and self-provisioning in nature, requiring little or no guidance.  They are better suited for mass  consumption by clients – both developers and partners.  SOA, on the other hand, is predominantly used for internal use-cases, though they are prevalent in a number of B2B use cases.  Thus, if external integration is a priority, APIs may be more technically viable and strategic.
   3. It is important for API providers to future proof (and past-proof with SOA support) their deployment with an unified infrastructure, rather than introducing yet another tier. The last thing organizations need is another tiered infrastructure when another protocol surfaces.  It’s only a matter of time that REST and JSON are replaced with more advanced technological breakthroughs.
   4. Regardless of whether we’re talking about SOA services and APIs, the “bang for the buck” is getting them secured, monitored, orchestrated, mediated and audited. Remember, the operational advantages of SOA services and APIs don’t necessarily pertain to their message protocols, but are characteristics of the specific business service or operation they represent – otherwise known as the “policies” that enforce a certain quality of service in meeting business requirements.
   5. API and SOA are service platforms that depend on other applications and services, which are often managed by other developers, organizations, and providers. The architectural principles driving security, compliance, policy management, monitoring and analytics should be applied across the entire application service landscape in order to minimize impact to the organization’s API for SOA services.  Furthermore, both SOA services and APIs have a lifecycle, which should be managed as part of the organization’s System Development Life Cycle (SDLC) and Application Portfolio Management (APM) responsibilities.

SOA is not passé.  It is as relevant today as ever.  SOA and APIs are not architecturally at odds, although they have their own unique characteristics from a technical or implementation standpoint.  Thus, it only makes sense that organization’s use a common infrastructure to manage and govern the commonalities between them, rather than deploying redundant or “tiered” infrastructure.  Otherwise, you’ll be stuck with two refrigerators in the same kitchen – both being different brands of course.