09.25.07

A very interesting post on “Paying for SOA” by Nick Malik over at Microsoft (he is in the Enterprise Architecture group).  He applies a taxonomy based on tax policy — which is surprisingly apt (or at least I felt so after reading his post…)

For me, the core challenge is that two truths are in conflict:

1. Centrally providing services at scale is usually more efficient
2. Small, independent teams will outperform large dependent teams (I wish I could phrase this better)

Did I say these are in conflict?  I made a mistake, a mistake many people make, because I equated efficiency, productivity, and speed.

In the traditional IT world, I would propose these definitions:

• efficiency:  total cost of ownership to the entire organization, which may mean “sub-optimizing” a given team
• productivity:  the efficiency of a person or team on a given project, but not necessarily the whole organization
• speed:  time to benefit for a given solution

“Big SOA” can be considered to be good for efficiency.  In this world you build things only once, reuse like crazy, and standardize as much as possible.  The theory is that you will get some speed benefits, later…   The problem here is that we turn the world inside out, and make the engine room the entire purpose, rather than just a big infrastructure to move the cruise ship from island to island.  Big-time architecture programs often disappoint because they get so enmeshed in infrastructure that they forget why they were started (to make it easier to do things).  I believe some large outsourcing arrangements (where entire IT groups are consumed by mammoth firms) succumb to this as well, though not all.

Total independence, on the other hand, makes no sense either.  If every team is using a completely different philosophy and technology stack, you never get any scale and spend lots of time integrating stuff.  This is almost never a conscious decision, and is mostly observed in acquisitions (hey, nobody told the IT groups that would be one big happy family one day) — but on a smaller scale it is not uncommon to see different teams “agree to disagree” on key points like middleware.  Independence and free choice will initially drive productivity, but as systems need to be linked, you pay it back with interest.

So what is the answer?  I think it is somewhere in-between.  Our own GXS Trading Grid applications are a mixture of mandated shared services (like identity, translation, messaging), and independent application functionality.  The balance is difficult to achieve, but Nick Malik’s piece is some nice thinking on at least one model of achieving it….