IT's Tower of Babel

The name of the game for enterprise architecture is linking all the technological systems a government uses.
by | November 2002

It's hard to hold a conversation about enterprise architecture when the key talking points are such dense words and phrases as domains, middleware, platforms, data standards and "a framework for government information systems integration." No wonder so many people use analogies to describe a concept aimed, ironically, at reducing the complexity in how governments buy and use technology.

Since the aforementioned is a pretty worthy goal, I'm not averse to picking up on those analogies to explain what's going on with an idea that's been around for a while but currently is getting a higher profile. In part, the new attention flows from the National Association of State CIOs' updated "toolkit" report issued this July for how governments should proceed with enterprise architecture. But it's also because the technology is finally available to enable better and easier integration of systems and processes. With the Internet and new kinds of programming languages, such as XML, it is now more feasible to get technological systems working in sync, which is what enterprise architecture is all about.

More specifically, enterprise architecture is a way for a government to tie together its agencies' business processes with the technology and standards needed to make everything work in concert, both within the agency and with the government enterprise as a whole. The government, in essence, develops a comprehensive roadmap of technologies and technology practices. Then, any time an agency automates or re-automates a business process, everyone can be reading from the same map and buying what fits.

The roadmap doesn't just cover what technologies exist in various agencies. It can also require that particular brands of equipment be purchased, that a certain amount of training must go along with its implementation or that project management be mandatory. The decisions on what's in the roadmap are made by individual governments. States such as Kansas and Kentucky have put enterprise architecture requirements into statute.

In explaining the need for an overarching architecture for a government's technology, Ray Herold, director of IT architecture and planning for Fairfax County, Virginia, uses this analogy: When a building goes up, plumbers, carpenters and other technicians put certain pieces in place, according to a design someone has made for the overall building. Enterprise architecture is like being the city planner overseeing hundreds of buildings that must be built to code and integrated into the community. "You can't have a building that doesn't have any access," Herold says, "or a place where there's a barn on one block and a 40-story building on the next."

When it comes to building technology, agencies left to their own devices tend to choose systems without regard to whether they may be incompatible with what their neighbors are using, creating a mishmash of pieces that don't work very well together. The whole idea of enterprise architecture is to have a framework for deciding what pieces should be used and where they should go. Everyone has to follow the blueprint to keep the barns out of the urban areas.

Kentucky is doing that by limiting what agencies are allowed to buy. The analogy Doug Robinson, executive director for technology in the governor's office, uses is Baskin-Robbins. "Before, we had 31 flavors, all independent kingdoms," he says. Now there are fewer tastes to lure agency heads. So, where the state once had several different word processing packages, for instance, 95 percent of employees now use one word processing package. The same approach applies to Internet routers and other pieces of equipment. "It's a governance model," says Robinson. "We're willing to take the heat. It's a decision based on minimizing the diversity in state government."

Kentucky first built the conceptual architecture and is now picking standards and asking agencies to give up equipment and applications that don't meet those standards. Robinson still hears arguments about the loss of flexibility or complaints that the state didn't pick the super-duper best product on the market. But more important than having the absolute best is making sure that whatever Kentucky buys, or migrates to, fits in with the whole enterprise. The state makes technology decisions based on what's "best for the whole enterprise, not the 14 little business units out there," he says. There's a reason why the motor pool buys all Ford Tauruses: It's easier to maintain and support one product.

That's all the analogies for this month, folks.

Join the Discussion

After you comment, click Post. You can enter an anonymous Display Name or connect to a social profile.

More from Tech Talk