Resolving centralization / decentralization tension with SOA?

Robert Swanwick pinged me about a post he wrote contemplating an organization’s struggle to balance the tension of business unit independence and IT consolidation.  At the end of the post, Robert wonders aloud if SOA is an answer:

“However, the autonomous business units lived on. Because they are quite independent, they are constantly seeking to diverge in order to meet the specific needs of their customers. At the same time IT continues to work towards increased centralization. As you can imagine, this is creating some tension.

A service oriented architecture (SOA) with shared web services and appropriate SOA governance might be their salvation. If IT can control the main architecture and help facilitate the sharing of approved web services, this firm may be able to get the centralization they need while allowing for business units to meet their own customer needs.

Is SOA the way that this increasing tension might be relieved in many organizations? I doubt IT is going to give up working towards standardization and cost savings and I know that if business units feel their customers are not being served by what IT is providing, they are going to continue pushing for autonomy. If not SOA, how is this tension going to be resolved?”

Before I give my two-cents, let me issue the standard consultant disclaimer that in the absence of deep context on the particular situation, the best I can offer is educated conjecture.  In other words, “it depends”.

On the IT side, a SOA approach can be used to rationalize application and information portfolios, therefore “centralizing” the software assets that instantiate common business activities and business information actions.  As well, these now common services (business and information) can be composed into interactions specific to each business unit by applying different processes, steps, rules, policies, interfaces, events etc.  So, from a purely technical point of view, yes, it is possible to balance commonalities (centralization) and variations (decentralization) with a SOA approach.

That said, the ability to achieve this outcome hinges on the given organization’s maturity.  And to be clear, I’m referring to the entire organization, not just IT.  Some top-of-mind starter questions to asses organizational maturity:

• Do the various business unit owners recognize they have commonalities with the other business units?
• Is sharing (economy of scale) part of the culture?
• Are the business unit owners willing to collaborate, and able to agree, on standard definitions for those shared activities and information?
• Will the (economy of scale) benefits achieved be reflected in the business unit owner’s performance?  Is there something in it for him/her?
• Is the organization experienced in IT Governance, particularly around the funding and prioritization of shared services?

If you answered “yes” to the majority of the above, then yes, consider a SOA approach to balance the tension of business unit independence and IT consolidation.  If you answered “no” to the majority of the above, understand that a SOA approach while not impossible, will be much much harder.  Read: increased time, money and organizational angst.