Three steps toward developing an enterprise architecture
These three key steps are where the real work, and often resistance, begins in the enterprise architecture process
Agencies can choose from many enterprise architecture models — some developed by consultants, others adapted for government use. Whatever the model, developing an architecture usually involves about seven or eight major steps.
The preliminary ones involve getting management to buy in to the project, selecting an architecture model or framework to use, appointing teams that will perform and oversee the work, and setting up the procedures that the teams will follow. In many ways, that's the easy part.
The next three steps are where the real work, and often resistance, begins. They also produce what are viewed as some of the most tangible products of the enterprise architecture process. With an aggressive timetable, these next three steps can be completed in about 18 months, according to Scott Bernard, director of graduate programs at Syracuse University's School of Information Studies.
n Create a baseline model. First, you must record an inventory of your current IT infrastructure and business processes, sometimes called the "as is" or baseline model. For example, the Department of Health and Human Services recently completed a painstaking inventory of its information technology systems. At first blush, this might seem a fairly straightforward task — just documenting what you have — but there are many challenges.
Due to the enormous size of some federal agencies, complete inventories, though preferred, are too expensive to collect, so sampling techniques are sometimes used. It can also be hard to get midlevel managers to cooperate in the inventory.
"Some of the resistance is due to embarrassment, because it will be revealed how needlessly complex some systems were built, for good reason or not," said Scott Bittler, vice president of enterprise planning and architecture strategies at the META Group Inc.
n Create a target model. The next step is to develop a "to be" or target model of the enterprise. This might include, for example, plans for a new, citizen-focused e-government service. That model then drives the changes required to support the new service.
But if getting the operations managers to fess up to what's running in their own fiefdoms is tough, getting them to agree on how things should run collectively, which often means yielding some control, is even more difficult. That's why a purely consensus-based approach will usually not work.
"Where each department is today has a lot to do with where they want to go," said Lee Holcomb, chief information officer at NASA and co-chairman of the Architecture and Infrastructure Committee of the CIO Council. "But you have to establish a common vision and say this is what we're going to do. If it comes down to a vote, you're likely to get deadlocked."
It's critical to pick the emerging technologies and standards that most cost-effectively support future business operations, which is the point of developing an architecture. But making the right bets is tricky.
Holcomb recalled, for example, that during the early planning stages for the international space station in 1983, NASA picked a promising new programming language called Ada to develop some of the station's software. "By the late 1980s, Ada was basically not adopted by the commercial sector and became basically an orphan language," he said. "Today, we are well into the station, and the onboard software is still written in Ada."
Because of uncertainties about new technologies, most target architectures are projected for three to five years into the future.
n Develop a migration plan. The last step in the initial development is coming up with a migration or sequencing plan to get from the baseline to the target architecture. You create this by identifying the gaps between the baseline and target, then plotting the process, system changes and additions required to bridge the gaps.
Once all of these steps are done, an agency can start to use the architecture to guide future IT investments. Never really completed, an architecture is an ongoing process, regularly updated to reflect changing business requirements and tap new technologies.
NEXT STORY: E-commerce costs USPS