Frustrated with SOA? You're not alone - and ThoughtWorks Application Architect Neal Ford knows why: It's because you're confusing the marketing image of SOA with the reality of SOA.
Fortunately, Ford came up with great metaphor to show you exactly how silly it is to strive for this overperfect image of SOA.
Ford offers what he calls "My Horse Scale of SOA." In this scale, the ideal of SOA - the hyped version of what it "should be" - is a unicorn. As Ford points out, if you were an alien from outer space looking at children's stories, you'd think the earth is just full of unicorns, when, obviously, they don't really exist. It's the same with the marketed version of SOA: It doesn't exist. Never did and never will.
On the other end of the continuum is enterprise architecture, which in most cases resembles a "broken-down donkey," Ford writes. You don't see a lot of pictures of old donkeys, but the earth is just littered with them. When you decide to implement a SOA, you're attempting to see how close you'll get to a unicorn. You'll probably wind up with something closer to a Shetland pony or old gray mare, but you might just find you've got a racing thoroughbred, he writes.
It's a great metaphor. And one to keep it in mind when reading this excellent article discussing how business intelligence, data delivery and SOA are converging.
Why would I say such a thing? Because this article from b eye network identifies a fascinating problem and promising trend, but it's clear there will be a whole bunch of donkeys involved along the way.
Writer Richard Skriletz sees a natural synergy between the growing demand for real-time, enterprise-wide business intelligence and the push to build more agile applications through service-oriented architecture. Inevitably, these two trends will converge and support one another, he contends -- but first, you have to resolve the tension between SOA and BI.
Skriletz points out that you can see the conflict coming just by asking an SOA architect and a BI and data delivery architect to draw a conceptual diagram. The SOA architect will show data at or near the bottom; the BI and data delivery architect will draw the applications at or near the bottom.
As Skriletz sees it, the two are at odds because SOA is disintegrative in terms of how it handles data, while BI is integrative. His model of resolving this tension relies in part on building enterprise transaction data stores.
There's not a lot written about this topic, and Skriletz does a great job of explaining why this is a problem and how it might be resolved. But one thing he doesn't address is the fact that companies deal with data very differently. You may want one data store, but the business model might restrict that, as Nick Malik explored in a recent series on how different business models can affect your SOA. So, read Skriletz's article, but keep in mind at this point, he may be hunting unicorns.