Digital Business and SOA - how do they relate?

Posted by Christian Franklin

Find me on:

10/29/13 6:18 AM

I recently wrote about the merits of having a digital business strategy. Subsequent conversations with a client about service oriented architectures, enterprise service bus and messaging highlighted the overlap between Service Oriented Architecture (SOA) and the 'API Economy.'  I realized that the overlap and subtle differences can make this subject confusing so I thought putting fingers to keyboard would be a good exercise.

Service Oriented Architecture Basics

SOA was really conceived as a means for interconnecting discrete information systems or components modeled as services, which are accessible over the network via well defined, standard protocols and data formats.  These standard protocols are HTTP, MQ and TCP, with the most common data formats being XML, SOAP and JSON.

The primary goal of the architecture is to promote re-use of software systems or information services within an enterprise using inter-system communication - often referred to as the 'enterprise service bus' (ESB).  The premise is to provide flexibility to manage discrete business functions by having defined network interfaces or 'contracts' over which disparate systems can connect.  This notion supports independent development and evolution of cooperating systems by removing the tight coupling of systems that can make for ridiculous complexity.

Note: In the early 2000's quite a bit of 'integration' was done using tools of convenience such as FTP and, as anyone who has had to deal with the vagaries of these types of integrations will attest, they are less than optimal.  If this is what your 'digital business strategy' looks like it's time to expand your horizons and put basic message queuing in place to replace those FTP puts and gets - it's a pretty straight forward transition and you get benefits right out of the gate.  It's amazing how little things like 'at most once delivery' can dramatically improve your data quality and service levels.

What makes Apps & APIs different?

At a coarse level of inspection SOA+ESB and APP+API are philosophically similar; they are both focused on interconnectivity but there are differences as well.  One of the main differences is that SOA+ESB participants are long-lived and purposefully slow to change with application development correspondingly deliberate due to formal data models and rigorous governance.

In the APP+API world the key differentiator is that you are primarily interacting with a device and the language of choice is JSON instead of SOAP.  



Apps / API


Core Goal


Enabling developers and systems to interconnect while adhering to standards

Enable developers to build nifty, compelling apps that users can run (at scale)




Low latency, trusted

High latency, untrusted (mobile)


Developer Audience


Internal, methodical



Development Style


Deliberate, structured and governed by process

Rapid, Iterative




Enterprise grade IT, Servers & Storage

Any connected device, M2M




Formal, strict

Flexible, dynamic


Data Format


XML, JMS, SOAP, EDI and others





TCP, MQ, HTTP and others





LDAP (AD), Internal

OAuth, Internet standard





Key component


By definition the connection is handled via APIs which implies different data models and looser, more dynamic data formats with very different security requirements.  A crude example: 'If you send an HTTP GET message to with the URL path: /weather/5day/94901, I will send you an XML document with the 5 day weather outlook for San Rafael, CA.

This is different from the traditional definition of API which typically referred to a formalized way of talking to an application but still might infer fairly tight binding.

Many of the companies offering ESB solutions are rapidly adjusting to this paradigm by incorporating API management capabilities into their offerings.


Topics: Optimization, Information Integration