[
Home |
Resume |
Programming |
Engineering Philosophy |
Family
]
Centrality of the IT Function
As an organization grows, whether the IT (Information Technology, i.e.
computers and networks) staff should report to local managers or to a central
authority tends to be a contentious issue.
Having gone through this transition three times personally, and having heard
stories from about a dozen other companies, this is an issue with which I am
all too familiar.
This document presents some compelling reasons both for and against
centralizing the IT function, and offers some practical advice on resolving
the issue.
Advantages of Centralized IT
Amortization of Meta-Infrastructure
Meta-infrastructure is defined as the infrastructure for managing your
infrastructure.
Among other things, it includes:
- Documenting the properties of the system that are sufficient to meet the
needs of the entire user community, such that the system can change without
breaking.
- Developing automated means (e.g. scripts) to support satisfying those
properties.
- Managing vendor relationships.
- Designing and developing internally shared tools and default
environments.
- Supporting the meta-infrastructure over time.
When IT is centralized, the cost of these activities is reduced, because
the diversity of user needs grows more slowly than the number of users.
In other words, the cost of maintaining a single standard for some number of
users is less than that of maintaining two standards, each for half the
number of users.
Resource Utilization
Resource requirements are fundamentally dynamic
and unpredictable.
To make sure sufficient resources are available, one must guard-band the
estimated requirements, such that utilization suffers.
When the pool of users increases, the resource requirements are statistically
more predictable.
Utilization therefore improves, and the same overall goals can be achieved
with fewer overall resources.
Foresight
When a need emerges for the first time within one of the engineering
groups, it is likely that this need has already been experienced by another
group.
If the centralized IT organization is responsive to the needs of its user
community, then it is likely to have already developed a solution for such
a need that is already integrated into the system.
When needs are anticipated in this manner, it is not necessary for development
to be impeded while local the IT staff defines and implements a solution.
Non-Advantages
Some of the purported advantages of centralized IT are not really advantages
at all.
Uniformity
When IT is centralized, one can migrate within the organization without having
to re-learn the IT standards.
While this is true, in my experience migration is too rare for this to be
a compelling advantage.
Furthermore, the cost of adapting to a new IT infrastructure is most likely
small compared to the cost of adapting to new product-specific infrastructure.
Scalability
Assuming that interaction between engineering groups is small compared
to interaction within a group (and in reality it always is), there really
aren't any compelling scalability advantages of working within a common
domain and environment.
In fact, one can argue that the most scalable solution is to change the
number of independent fiefdoms without affecting their size.
The Internet is an existence proof.
Advantages of Decentralized IT
Agility
When IT is decentralized, the scope of proposed changes is reduced.
Therefore, the amount of consultation, planning and risk associated
with changes is reduced.
Therefore, changes necessary to meet local needs can be implemented more
rapidly.
Stability
This is counterintuitive, but having local environments makes each of those
environments more stable.
That's because the changes that are necessary to meet the needs of one group,
and the risks associated with those changes, are not foisted upon the groups
that do not share those needs.
Accountability
Perhaps the most important advantage of decentralized IT is that the IT staff
is accountable to its customers.
One tends to take this for granted when the organization is small.
In the majority of cases, the customer of IT's function is a front-line
(non-managing) engineer, and the provider of the function is a front-line
IT staffer.
If the IT group is purely centralized, then the reporting path
between these two individuals passes through the C.E.O.
In an organization of nontrivial size, losing accountability at some point
along this path is not just a possibility -- it's a virtual certainty.
This problem is sometimes addressed by assigning individuals within the IT
group to "represent" a particular engineering group without having any
local accountability.
Not surprisingly, this doesn't help much.
The problem is also sometimes addressed by using a database to measure the
IT group's effectiveness.
However, the IT group itself usually exerts enough control over the database
contents such that it paints a fraudulently complementary picture.
When the IT staff does not have sufficient accountability to its customers,
not only are unique local needs unlikely to be met, but also the minimum
functionality that one should expect at any engineering facility
tends to be neglected.
|
Even the theoretical advantages of centralizing the IT function are
undermined when the IT group operates without accountability.
|
The Solution
Since neither a purely centralized nor a purely decentralized
IT function makes sense for a large engineering organization, it is not
surprising that the best solution involves a little of each.
Central Planning
In order to realize the beneficial economies of scale associated with a
growing organization, a substantial portion (perhaps 50%) of the IT
resources (including both staff and equipment) should be assigned to
global needs, such as developing and upholding meta-infrastructure,
and absorbing temporary peaks in resource requirements.
Local Empowerment
In order to guarantee that local needs are met, the remainder of the
IT resources should be dedicated and accountable to engineering groups
of fewer than 100 users each.
The majority of maintenance and support is provided by local personnel,
because they do not normally have meta-infrastructure responsibilities.
However, the local resources must conform to the global standard if at
all possible, and central personnel are not excluded from providing service.
If local needs cannot possibly be met economically within the global
standard, then the local personnel should be empowered to operate in
violation of the standard.
(This also provides incentive for the central personnel to maintain the
global standard such that violating it is never justified.)
Central personnel may either incorporate the new method into the
standard, or develop an alternative of equal or greater viability before
mandating that the local system conform.
Transitioning
For some unknown reason, most growing organizations don't appreciate
the need for local IT resources until long after it arises.
Be careful not to fall into that trap.
Invariably, once local IT resources are deployed, the effectiveness of
the system in satisfying user needs improves markedly.
In my experience, the only way to introduce local resources is to grow
into them.
Existing central personnel tend to resist local accountability
and staunchly defend their existing equipment.
Anders Johnson, last modified
$Date: 2002/04/05 $
[
Home |
Resume |
Programming |
Engineering Philosophy |
Family
]