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.  

Aspect

SOA / ESB

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)

 

Network

 

Low latency, trusted

High latency, untrusted (mobile)

 

Developer Audience

 

Internal, methodical

Varied

 

Development Style

 

Deliberate, structured and governed by process

Rapid, Iterative

 

Platform 

 

Enterprise grade IT, Servers & Storage

Any connected device, M2M

 

Contract

 

Formal, strict

Flexible, dynamic

 

Data Format

 

XML, JMS, SOAP, EDI and others

JSON, XML

 

Communication 

 

TCP, MQ, HTTP and others

HTTP

 

Authentication

 

LDAP (AD), Internal

OAuth, Internet standard

 

Analytics 

 

Limited

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 weather.com 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