A better plan for IT
- By Brian Robinson
- Jan 14, 2002
There may be some state or local government somewhere that won't eventually
need to develop its own information technology enterprise architecture plan,
but it's hard to see who that would be if architecture proponents are correct.
After all, they say, it's all but impossible to conduct e-government,
establish real security or build integrated criminal justice networks
a few top goals of most governments without having an enterprise architecture
in place.
Which, of course, begs the question: Exactly what is an enterprise architecture
(EA), and how do you develop one?
It's not an easy question to answer. Having an EA means knowing what
IT systems and business processes you have in place right now, acknowledging
what's good and facing up to what's bad. It requires pulling all the players
together and asking hard questions about business goals, program
drivers and returns on investment. And it means getting people to agree
on what's needed to move the focus from their protected turfs to a more
expansive and more uncertain governmentwide view of their computing
environment.
"This is tough stuff," said Carol Kelly, vice president and service
director for electronic government strategies at the META Group Inc., which
for many years has been pushing the need for EAs in the public and private
sectors. "It takes knowing just what your [architecture] governance model
will be and what the essential policy issues are. Above all, it takes commitment,
especially from the top."
But the rewards for governments that build and faithfully follow EAs
can be great. Among the benefits are significant cost savings by rooting
out redundant computer systems and creating standard, easier to manage IT
infrastructures.
{h3}A Pragmatic Approach
The National Association of State Chief Information Officers (NASCIO)
believes the best way to build a "technology adaptive enterprise" is to
use an architecture process that promotes a constant re-evaluation of an
enterprise's needs, both in terms of technology and mission objectives.
But that process has to be a pragmatic one (see "Cleaning out the IT garage"), according to NASCIO,
and should take into account that most governments are strapped for capital
investment dollars.
NASCIO has developed a template for how governments can go about building
these kinds of adaptive architectures and recently published the first version
of an Enterprise Architecture Development Tool-Kit, which emphasizes a real-world
approach.
"Implementing architecture via the big bang theory is not going to work,"
the toolkit document states. "Migrating to architecture within available
budgets is the only viable method."
The toolkit is a primer that NASCIO will use to educate people about
why they need to develop an EA, said Gerry Wethington, Missouri's chief
information officer and the chairman of NASCIO's Enterprise Architecture Committee.
And the template recognizes that building an EA must be a voluntary effort
and that each state must make its own business cases for it, he said.
The main reason to develop an EA is clear. Constituents don't want
to have to know how to navigate through agencies' online services, Wethington
said. They want to come to a government portal and be able to get things
done. That means agencies within governments and different levels of government will increasingly need to share information.
And that all but mandates an enterprise approach to IT, using common
systems, data structures and applications whenever practical. The problem
is that IT personnel have little time left these days to work out how to
accommodate that.
"Business drivers today change around every 15 to 18 months, which is
a lot faster than in the past," Wethington said. "And the rate at which
you have to replace technology is down to between 18 and 24 months, compared
to between three and seven years not so long ago."
That means IT people will have to make some quick moves, and those moves
will be aimed at breaking down the old "roll-your-own" technology silos,
a relic from when technology was first introduced in government in the 1960s
and 1970s.
"People need a blueprint to help them with this," Wethington said. "And
that's what an enterprise architecture is."
Although EAs are becoming more popular in the federal government, only
a few state and local governments have implemented them. Kansas published
the latest version of its architecture in October, its ninth in four years,
though state officials hope to soon whittle the major revisions down to just one a year.
Kansas' EA is organized into four "sub-architectural" components that
focus on different, yet related perspectives:
* A Business Architecture describes what missions the organization performs,
such as administering welfare benefits or collecting taxes, and what its
relationships are to external entities that support those missions.
* An Application Architecture shows how the IT systems that support
the business missions should be developed and what their end-user interfaces
need to be.
* An Information Architecture describes how information should be structured
so it can be used by a number of different organizations within the government,
and how it can be made secure while still providing the open access citizens
need.
* A Technology Architecture shows how the components of the technical
infrastructure, such as hardware and networks, should relate to one another
and to the applications and information they support.
To develop an EA, you need templates that show people how to get things
done, said Don Heiman, Kansas' CIO and chief information technology architect.
Governments need across-the-board agreements on how to go ahead with an
EA, as well as an early buy-in from agencies. And crucially, governments
need a common language for discussing the different components of the architecture,
"because you get a lot of different ideas as to what the architecture should
contain," he said.
That might point to a complex process, but "in truth, it's not that
bad," Heiman said. "And when people actually get to do an architecture,
they see it as helping to bring their efforts to a conclusion. It becomes
a cohesive thing."
The classic mistake made when putting an architecture in place is trying
to do "technology for technology's sake," said Tom Runkle, chief planning
officer for North Carolina's Office of Information Technology Services.
"An architecture isn't a product list, though most people do think that's
what it is, and that's the problem."
The hardest part of building North Carolina's EA was not the technology,
but coming up with a document that showed why the architecture was needed
and communicating that to the top executives.
"The quickest way to fail is to try to get an executive to understand
the details of the technology," Runkle said. "So we used the example of
what an architecture means to city planning and to the building industry.
We kept the approach very visual and never mentioned technology."
In fact, although technology is at the core the process, it's not a
factor in how the architecture is defined in the first place. First comes
a detailed description of the business processes that the architecture is
meant to support, and only after that is technology applied, experts say.
Even then, agencies are left to decide what technology they want to
use.
"We took the approach of guiding agencies into the strategic areas we
would like to see them in, in terms of software, hardware and services,"
said Paul Lubic, manager for IT policy and planning in Virginia's Department
of Technology Planning. "We don't put them on a short leash. We basically
tell them what particular direction they need to go with a buying decision
in order to be compliant with the architecture, but we never name a product."
Virginia, which is in the early stages of building its architecture,
started with the strategic framework that requires the architecture in the
first place and the vision, goals, priority business activities and enterprise
business strategies that the architecture would service. The effective use
of IT had to become an integral part of the state government's business,
Lubic said.
If an EA is like the plans for a house, then, like a house, once it's
built, you never stop having to do something to it.
"Putting an enterprise architecture in place is a never-ending process,"
said Jerry Simonoff, director of Virginia's Department of Technology Planning.
"What we need people to understand is that it's not just about the initial
creation, it's about the ongoing maintenance. Everything [about an enterprise
architecture] has a half-life."
Robinson is a freelance journalist based in Portland, Ore. He can be reached at [email protected]