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 hullite@mindspring.com.