A company that employs 50,000 employees almost certainly has more than a thousand separate and distinct "communities of interest" within it. Those responsible for administering the centralized IT governance function can't begin to understand even who all of these communities of interest are, let alone what sorts of opportunities for business improvement that information technology might be able to provide. If they tried, their heads would explode.
And even if they could manage it, big companies centralize IT in order to achieve economies of scale; it's a cost-saving tactic. They want to treat their developers as a pool of resources that can be mixed, matched, deployed, and redeployed in response to changing demands for their services.
Well and good, and it has a consequence: Where a small embedded IT group understands how the community of interest operates, its unwritten rules, personalities, and preferences -- and as a result can immediately get to work taking care of a need -- central IT will begin by "defining the requirements," which really means, "Please educate us so we don't code from ignorance."
Everything about embedded IT is more efficient, with two exceptions.
The first: It tends to fragment the architecture, because the embedded IT groups have their own preferences and generally chafe at any restrictions imposed by central IT. Add to that the absolutely standard dynamic that exists between these two groups: Each considers itself "us" and the other "them" with neither trust nor love lost between them, and the embedded IT groups aren't going to (for example) write all of their Web applications in Microsoft ExpressionWeb when they know CodeWeaver is the superior tool.
And the second: Embedded IT groups frequently duplicate each others' efforts, because they have no way of knowing who each other are, let alone what each other are up to.
These are solvable problems, so long as the CIO wants to solve them and considers them important enough to solve. The short version: It takes leadership, time, attention, and an understanding that central IT should consider one of its most important roles to be coordinating and encouraging these groups. The long version is lengthy enough that it can't be addressed here -- it's the stuff of serious consulting engagements.
[ That was a hint. Check out Bob's consulting company, IT Catalysts, if you'd like to know more about what it has to offer. ]
Sadly, the CIO's usual response is quite different: a reorganization that absorbs the embedded IT groups into central IT to "get control of the situation." Not long after that, the local communities of interest reconstitute new embedded IT groups, and nothing has changed, other than the increase in central IT's size and increased cynicism on the part of the communities of interest.