Downsides of SOA

Gerhard Poul makes some good points about SOA.

He mentions several things to be aware of (referential integrity, availability, governance, etc, etc).

His first two points are worth emphasising.

SOA allows powerful composite applications to be created: combining new logic with functionality provided by other systems is a compelling proposition.

But, as I've stressed to several clients, there are also challenges you need to address.

The first is availability: the availability window of a composite application is the intersection of the availabilities of the systems upon which it is critically dependent. Crucially, the intersection is not the union and it is not the average.  Take note.

The second challenge is related to Data.  Gerhard talks about referential integrity but you need to think about more than just this.

The simplest example of what you need to think about is: "how do you do a join across two web services?"

Example problem: you have one table in a database that contains all customers' account balances and another contains their addresses. How do you produce a list of all customers in London with a balance of $1000 or more?

Joining across two tables is easy in a relational database

Products like WebSphere Information Integrator let you join across different data sources (neat!)

But, if you naively "do SOA" by providing a "get customer addresses" service and a "get customer balance" service (and nothing else), you'll have a tough time solving the problem.

The consequence of this is nothing surprising: you need to expose reusable services at a suitable granularity, you need to use the right tool for the right jobs and, most importantly, you need to remember that SOA is not a magic wand that magically makes the last forty years of computer science irrelevant... all the benefits the marketing folks talk about are real but there is still a need for thoughtful architects and designers!