09.25.07

Something in one of my recent posts ( SOA versus ESB — conflict or collaboration ) struck a chord with Dan Foody over at Progress Software, and his post about understanding your organization before you architect has now gotten me thinking.

The Chief Architect of the GXS Trading Grid is a guy named Jeff Barton, and he has a favorite phrase on this, “architecture by org chart”.  This is somewhat different from Dan’s blog entry, as Jeff’s point is the tendency of development teams to be more Ptolemaic than Copernican (basically, teams make the rest of thew world revolve around themselves).  As I looked up the wikipedia entries on the Ptolemaic system, I realized just how apt this metaphor was — since it requires gigantic planets in space to spin, perform loops and rotate around Earth to make the math work!

The widespread implementation of SOA requires coordination across multiple teams, who must “do work” on current projects that is — in the short run — exclusively of benefit to other teams!  Over time, and not even that long in GXS’s experience, benefits boomerang as other teams do the same — but this is a leap of faith, and many IT people are not into leaping.  This same challenge is also faced by the proponents of RFID deployments (we’re for that, but that is another entry….).

This is where the influence of CTOs, Chief Architects, and senior developers is make or break. 

Dan references the very real challenges of balancing the power of IT/non-IT groups, but in my experience even balancing amongst different IT teams can be a monstrous challenge.  One technique I have seen work with some success is to deploy mandatory common infrastructure, with some degree of enforcement.  I have seen a few models of this:

1. preferred vendors:  one ESB, database, ERP, etc.  There might still be multiple instances (better be, in the case of databases!), but at least there is a single skillset and technical support connection.  You still have versioning issues, but at least you’re on the right track.  Easiest to enforce if you have centralized purchasing, as they can flag orders for anything “off the list”
2. common services:  you have to go to the “insert capability here” team (ESB, message queueing, database).  Much more amenable to a unified structure, but requires incredible commitment from the teams providing services, and lots of enforcement from above.  The first time a project misses because of an external dependency (”they wouldn’t configure the ESB for us!”), it starts to unravel.  Particularly challenging because the “core teams” are not directly connected to revenue, which can cause issues when budgets are allocated.  This is probably not an option for teams in organizations where IT is not in control — or at least on par — of resource allocation for IT projects
3. outside service providers:  Like #2 above, but using an outside service provider or SaaS vendor.  I admit this is somewhat self-serving, but the difference is that you do not have to deal with internal rivalries, and for-profit service providers tend to have more capacity when you go to them, which is really just a function of scale.  We have many managed services customers who require their divisions to use us for certain functions, and that achieve both standardization and integration (we are already integrated to their back ends).  Easier than #2, but only works for certain problem domains

I’m sure there are other models, and would love if people would add some comments about how it works in their shops.  As much as I would like to say there is a solution to “architecture by org chart”, I think the best we can do is get the architecture to reflect the view from higher up in the org chart (c-level), so that it ends up including the entire organization and its needs.