An enterprise administrator is anyone who is actively
involved in identifying, documenting, evolving, protecting, and eventually
retiring corporate IT assets. These assets include corporate data,
corporate development standards/guidelines, and reusable software such as
components, frameworks, and services. The responsibilities of this role
potentially includes, but is not limited to, the responsibilities associated
with traditional roles of data administrators, network administrators, reuse
engineers, and software process specialists. Many organizations,
particularly larger ones, will split these separate roles out, but for
the sake of simplicity I'll simply talk about the general concept of
enterprise administrator. In many ways enterprise
administrators are the “keepers of the corporate gates”, supporting project
teams while at the same time guiding them to ensure that the long-term vision of
the enterprise is fulfilled. An important goal is to guard and improve the
quality of corporate assets, including but not limited to data. Good
enterprise administrators are
generalists with one or more specialties, one of
which could be data administration, who understand a wide range of issues
pertinent to the enterprise.
It is possible for enterprise administrators
to take an evolutionary/agile
approach to development, if they choose to work this way (many unfortunately don't, see
below). Effective enterprise administrators:
Work in a collaborative
manner. They work side by side with people on project teams as
needed. They don't dictate or try to enforce standards or procedures
nor do they try to control the project team. They realize that their
primary goal is to enable teams to effectively work within the bounds of
their organization, and that the most effective way to do this is through
Work in an evolutionary
manner. Enterprise administrators will need to support agile
software development teams, and because these teams work in an evolutionary manner
the enterprise administrators must also work this way. The implication
is that the administrators won’t have complete project artifacts to work
with – e.g you can’t insist that a development team puts a logical data model
in place before you’ll help them to identify potential data sources.
Agile teams take an
agile approach to data modeling and will
database schemas as needed.
Communicate their role.
Agile software development does not take a command-and-control approach to
Agile developers aren’t going to jump through the hoops
of enterprise administrators just because that’s the way things are done,
instead they’ll work with the enterprise administrators when the
administrators actually have value to add to the overall effort.
Therefore not only should enterprise administrators be able to add value
they also need to ensure that their customers perceive that they’re able
to do so. Trying to “impose your will” through onerous processes
or management edicts won’t work very well, instead people will find ways
to either ignore you or go around you. In fact, there is a technique
blocking which works incredibly well in practice.
Mentor agile software
developers in corporate standards and guidelines. The goal is to
support the standards and guidelines, not enforce them. A good rule of
thumb is that if you need to act as the “standards police” then you have
lost the battle. Furthermore this failure is very likely your fault
because you didn’t communicate the standards well, didn’t gain support,
or tried to enforce unrealistic guidelines. If the standards and
guidelines make sense, if they’re written well, if they’re easy to
conform to then data and application developers will be willing to follow
them. However, when the standards and guidelines aren’t appropriate
or place an inordinate burden on projects then enterprise administrators
should expect pushback. Yes, some individuals may chaff at following
standards and guidelines but that’s something that project
coaches/managers will need to deal with. In fact, agile methods such as
include a practice called Coding Standards which insists that XPers agree
and adhere to
common coding guidelines, and Agile Modeling (AM) includes a practice
Apply Modeling Standards which insists that modelers agree and adhere to
common modeling guidelines.
Be willing to actively
address issues. When pushback occurs an enterprise administrator
works with the project team(s) explore and address the problem.
Perhaps a standard isn’t appropriate for a new technology. Perhaps
existing logical data definitions need to be updated to reflect new usage.
Perhaps the network needs to be upgraded to support a new application.
Enterprise administrators must be willing to actively work with project team
members to resolve issues such as this.
Work with the enterprise
architects. Enterprise administrators work closely with
architects to communicate the constraints imposed by the current
environment to the architects. More importantly the enterprise
administrators need to understand the future direction envisioned by the
enterprise architects to ensure that their efforts support the long-term
direction of your organization.
Adopt a lean approach to
data governance. Traditional, command-and-control approaches to
data governance appear to work very poorly in practice. The
DDJ survey into the current state of data management practices showed
that 66% of development teams will choose to "work around" their
organization's data group, and when they do so that 75% of the time it is
because they find the data group too difficult to work with, too slow to
respond, or that the data group doesn't provide sufficient value to justify
the effort of working with them (see Figure 1 below).
This is clearly problematic. It is possible to take a
lean/agile approach to data governance.
Take an agile approach to
Master Data Management (MDM).
The goals of MDM are to
promote a shared foundation of common data definitions within your
organization, to reduce data inconsistency within your organization, and
to improve overall return on your IT investment. There is
nothing inherently special about MDM -- it doesn't need to be complex nor
bureaucratic -- you can in fact take an
approach to MDM if you choose to. The critical concepts to accept
are that MDM is both an
enterprise-level issue and a
project-level issue, and that the only way for MDM to succeed is for it
to enhance data-oriented efforts on development projects and not hamper
their overall progress. Traditional approaches to MDM typically do the
exact opposite, and as a result struggle to provide value.
Figure 1. Reasons why development teams go around data groups.
|Although enterprise administration should be
straightforward, and it can be, many evolutionary/agile development teams find
existing enterprise administration groups difficult to work with. Some of
that difficulty lies in a weak appreciation within agile methods of enterprise
issues (hence the importance of
2nd philosophy), but most of the challenge lies with the inflexible, often
bureaucratic, and often serial approaches preferred by the administration
groups. Much of the problem lies in the administration-oriented frameworks
Control Objectives for Information and Related Technology (COBIT) and
Information Technology Infrastructure Library (ITIL)
which are invariably implemented in a command-and-control, instead of a
collaborative, manner. COBiT and ITIL each have some good ideas in them (ITIL
seems to have more, IMHO),
but like development processes based on the Capability Maturity Model (CMM)
Integrated (CMMI) the final implementation often proves to be less than
effective. Worse yet, from what I've seen, many organizations are
attracted to these frameworks because they're seen as the first step towards
outsourcing portions of your IT organization: get a well defined process in
place, get good at following it, then start outsourcing to lower-cost companies
who have also adopted those frameworks. The good news is COBiT hasn't
gained much of a foothold within the IT community, and considering how long it's
been since it was inflicted on us my hope is that it never really will.
ITIL, on the other hand, does seem to be gaining in popularity so hopefully we
can make it effective by tailoring agile concepts into it.