Dear Bob ...
I work for an enterprise that sports more than 50,000 employees, with a large technology group serving the users' needs. It has your typical project prioritization process, which takes at least a six-month heads-up on new projects and requires that all projects have thorough requirements before considering the project for development.
[ Also on InfoWorld: "How to balance centralized and decentralized planning" | Get sage advice on IT careers and management from Bob Lewis in InfoWorld's Advice Line newsletter. ]
I personally work for a specific business line in said bank, in an operation center of 400 employees with a broad array of job functions. My role is a software development for just our operation center. I'm part of a team of six people, and we've existed for 10 years.
More and more, we are finding other pockets of embedded development groups within business lines and business areas to provide applications quicker than our corporate technology group can. We write applications ranging from small-batch job processing to larger workflow systems; projects take from days to months in our group versus months to years in the corporate technology group.
It seems we are finding more of these embedded development groups as the corporate technology resources are taken up by high-impact projects and the constantly changing landscape of the business environment. Could you speak to this particular arrangement? Is this typical of large corporate technology groups? What typically happens to these embedded technology groups?
I don't have a particular problem to solve. And I'd like to keep it that way.
Dear Embedded ...
To answer the question you asked, yes, it's typical. Big companies have something in common with national economies. In both cases, centralized planning and economic management break down in at least two related places: fine-tuning the balance between supply and demand; and taking care of small communities of interest.
Countries that tried to manage everything centrally, like the Soviet Union, suffered chronic shortages and oversupplies of goods and services. The localized planning that results from a free-market system still suffers shortages and oversupplies, but by comparison they are minor in size and scope.
And scattered throughout the United States are people who love (for example) klezmer music. In a free market but not a centrally planned economy, someone will figure there's a way to make money by taking care of this small constituency.
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.