Building for the future

At least one federal chief information officer has been known to quip that on any given day, his department violates the spirit, if not the letter, of any of several laws designed to make government work better.

Among the more frequently tread-upon measures, the Clinger-Cohen Act of 1996 calls on agencies to get smarter about their information technology spending by developing what's known as an enterprise architecture (EA) plan.

An EA is a sort of customized, master blueprint for computer systems that is supposed to better align an agency's IT investments with its business mission. If used properly, an EA can save an agency lots of money by helping eliminate computer system redundancy and create a more standard, easier-to-manage IT infrastructure.

It's a great idea, but can be difficult in reality, which is why only some agencies have developed EAs, and even fewer actually use them to guide and control new IT spending and development.

By many accounts, however, the half-hearted efforts will change this year.

The main reason is unprecedented pressure from the Office of Management and Budget. OMB officials see EAs as a good way to identify and capitalize on opportunities to build cross-agency e-government applications, one of President Bush's key IT goals. In formulating fiscal 2003 budgets, agencies have been warned that they need to include adequate EA plans if they want to get new IT funding, according to Mark Forman, associate director for IT and e-government at OMB.

"It's a powerful stick that sends a message back about how important these things now are," said Alan Balutis, executive director of the Federation of Government Information Processing Councils and the Industry Advisory Council.

In addition, growing criticism of costly mismanagement of technology — and vulnerabilities in agency security and emergency preparedness, which were highlighted by the Sept. 11 terrorist attacks — is also pushing agencies to get serious about EAs.

Among the many EA efforts under way in the government is the Department of Health and Human Services' massive EA project, which started with an initiative to bolster the department's IT security, but has since expanded significantly.

At the Department of Veterans Affairs, an EA is at the heart of an ambitious plan called "One VA," designed to dramatically overhaul the department. And officials at the Education Department say that their fledg.ling EA program has already paid for itself many times over.

Early Returns

An EA is not only about computer systems and technical standards. The real point behind an EA is for an agency to get a better grip on how it conducts business, now and in the future, and from that insight, develop a blueprint for future IT systems that more efficiently support the mission.

"What we're looking to get out of the [EA] analysis in the departments is for them to rationalize how they're structured and to think about how are they best investing their available management resources, whether it's IT, or adding more people or funds, to drive improvement in their mission performance," Forman said.

Simply taking an inventory of a department's current business practices and IT infrastructure, which is a preliminary but vital step in developing an EA, can pay dividends.

That sort of an end-to-end, baseline inventory analysis allowed Education Department officials last summer to realize that several of their offices were independently developing electronic document management systems to comply with the Government Paperwork Elimination Act (in EA terms, GPEA would be a "business driver").

Without the EA exercise, Education would have probably gone about its business as usual, funding each of the projects separately, according to Craig Luigart, Education CIO. That means the department would have paid top dollar to acquire products for each of the projects, as well as spent money on redundant application development work, training programs and system support teams.

"A real advantage of the enterprise architecture is to identify and reduce duplication, so that you spend dollars just once on a product, component or service," Luigart said.

Embracing the EA's holistic view of the organization, Education is consolidating the multiple document management projects into one for considerable savings. In doing so, officials plan to deploy a standard system (still in the prototype stage) that meets about 85 percent to 90 percent of the different offices' requirements, according to Arthur Graham, Education's deputy CIO for information management.

With the baseline inventory completed, Education officials are now defining where they want the department to go in terms of new business processes and supporting technology (the so-called target architecture) and how they plan to get it there (the migration plan).

Those still-unfinished plans have already identified some common systems around the department that will be standardized to reduce costs, such as using Microsoft Corp.'s Windows NT/2000 as the network operating system and Oracle Corp.'s financial management software. In a more forward-looking stroke, the plans also call for using H.323-compliant network systems to be the backbone in the department's plan to run all of its telephone voice traffic over its data network.

Help Offered

Some agencies decide to go it alone on their EA projects, but Education is getting help on its year-old EA project from Booz Allen Hamilton, one of the many consulting firms that offers assistance to agencies developing EAs.

"We can help [agencies] from soup to nuts, from strategy on developing and using the architecture...to getting business line organizations on board, and even building a Web-based system to manage the architecture process itself, as we did with U.S. Customs and some others," said Michael Farber, a principal with Booz Allen Hamilton.

Whichever path they choose, EA development teams can find various government resources to help get started. For example, the CIO Council offers on its Web site a manual on how to develop, use and maintain an EA called "A Practical Guide to Federal Enterprise Architecture."

In fact, most agencies end up modeling their EAs after one of three popular government EA frameworks: the CIO Council's Federal Enterprise Architecture Framework; the Defense Department's Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance Architecture Framework; or the Treasury Department's Treasury Enterprise Architecture Framework.

These frameworks, as many do, draw on the work of John Zachman, who is credited with creating the EA concept while working for IBM in 1987. He now runs the Zachman Institute for Framework Advancement in California.

The primary tangible products of an EA project usually consist of text-based documents that describe the goals and procedures for the EA as well as various graphical models that illustrate the agency's business processes, data flows and technical infrastructure. Agencies usually store these records on paper or electronically on a secure intranet site.

There are also many specialized software products that can help EA teams model their business processes and applications, such as Rational Rose from Rational Software Corp., System Architect from Popkin Software, FrameWork from Ptech Inc. and the Enamics BTM Platform from Enamics Inc.

EA projects also usually require the creation of new management committees to plot strategy and to ensure that the architecture is followed. For example, when the VA recently launched its ambitious EA plan, it created a new IT board to replace the department's CIO council (see "VA rethinks technology strategy," FCW, Nov. 5, 2001, P. 21).

Reflecting the more holistic view of enterprise operations that an EA requires, the new VA board consists of technical as well as business representatives from the department. The VA also created an IT council to review changes to the architecture plan.

All Together Now

Some agencies have specific objectives or benefits in mind when they start to develop their EAs. For example, HHS' desire to beef up its IT security and to improve its responsiveness to emergencies led it to an EA plan, according to Brian Burns, deputy CIO at HHS.

With 13 largely autonomous operating divisions, HHS' decentralized organization contributed to inconsistent and vulnerable information security. The improvement plan, begun more than a year ago, called for the creation of an enterprisewide management infrastructure that is part systems management software — a sort of dashboard for the enterprise — and part standard policy and operating procedure that all divisions will follow.

In a nutshell, when the system (and management approach, really) is finished, it will enable HHS officials to more easily deploy and better manage their critical infrastructure and security assets, because the various components are standard — or at the very least, can interoperate with a standard management tool. Existing non-compliant equipment will not be ripped out, Burns said. Instead, a migration will occur over time as product upgrades are made according to the new standards.

This is the sort of goal that many agencies have with their EA blueprints: better performance for less money by moving gradually toward enterprisewide standardization. It also illustrates the relationship in an EA between a business driver — such as the need for better security — and the IT architecture that must be built to support it.

Interestingly, HHS' system management project was not originally the department's "official" EA plan, even though it has now morphed into that, according to Burns. Along with the official designation comes more of the issues that make developing an EA so challenging.

Chief among them is convincing unit- or division-level CIOs and IT managers to look beyond their own immediate needs to the bigger enterprise picture, where the real efficiencies can take place. In practice, this means they must yield some control over the kinds of systems they build and how they spend their money.

For now, HHS is using more of a carrot than a stick approach to win cooperation, Burns said. That's done mainly by citing a range of benefits for the divisions, including discounts on new products through bulk purchasing; capital planning assistance from the department CIO office to ease the paperwork burden on division CIOs; and better career opportunities for IT workers because their skill sets can be used on any of the standard systems that will be deployed throughout the department.

"Our goal has been to get as far as we can with collaboration and get as much buy-in as we can," Burns said. "But if we can't get the consensus, there will be some point at which we will have to do a mandate."

Rules to Follow

A primary goal of most agency EAs is to identify cross- functional areas for standardization. The most common areas for standardization are security, network infrastructure, e-mail systems, desktop computers, and financial and human resource management systems. But most agency EAs allow operating units some freedom to deploy nonstandard technology if it is required to perform a specific mission.

That doesn't mean that a project like this lives outside the EA. In fact, this scenario is a good example of how an EA must evolve, just as an agency's mission and operations evolve. The procedures that allow this evolution to happen are critical to an EA's success. EA practitioners call this the governance system and say that it's what determines whether an EA just sits on a shelf or becomes a real guiding and controlling force in IT operations.

"Governance is about manifesting the plan into reality," said Scott Bittler, vice president of the enterprise planning and architecture strategies services at the META Group Inc. Through governance, one of three outcomes is possible when someone proposes a project that is not compliant with the architecture, Bittler said:

One, the EA review committee suggests a way to build the solution in an architecture-compliant fashion that was not apparent to the project planners. Two, the business requirements driving the need for this non-compliant project are not unique, as first thought, so the architecture is modified to incorporate a new standard. Three, the business requirements are indeed unique and outside the mainstream, so the review board will grant a waiver from the architecture to compartmentalize it and will document the reasons for doing so.

Even though government interest in EAs is high right now, much work must be done. It remains to be seen if the commitment to EAs from OMB and agencies will endure. If it doesn't, a good deal of well-intentioned effort will fall into the category of lost opportunity. "It's a lot easier to do things that are only for the short term, but it's the long-term [EA] efforts that have far more beneficial impact," EA originator Zachman said.