Frequently asked questions
- By Sara Michael
- Sep 06, 2004
Although enterprise architectures permeate agencies' information technology planning and budgeting, the concepts can be elusive. From determining why an architecture is important to defining reference models, experts acknowledge that the principles can be difficult to grasp. The first step to developing an architecture and gathering management support is understanding the terms. The following is a list of frequently asked questions and explanations from the experts, covering several of the basics about enterprise architectures.
1. What is an enterprise
An agency's enterprise architecture is similar to a map, connecting an organization's business functions and systems and directing an agency's IT investments. An enterprise architecture provides a detailed picture of an organization, documenting the state of technology investments in general and the agency's overall target technology state, according to Government Accountability Office officials. It allows agency officials to plan systems and make investments for greater consistency and efficiency.
Mike Tiemann, a principal in AT&T Government Solutions' enterprise architecture practice, described enterprise architecture as "a comprehensive analysis that starts with the business and mission functions, documented down through several related layers, and the technologies that are required to support those business functions."
Tiemann, who helped develop the federal enterprise architecture, distinguished between the actual architecture and the enterprise architecture program. The federal enterprise architecture program, for example, is the set of activities and tools that must be used to develop the architecture, from policies to governance structures to staffing.
The definition evolves within an agency as officials understand the organization's needs and requirements, said Patrick Bolton, director for enterprise architecture at DigitalNet LLC.
"Starting first as a compliance requirement, [the architecture] will grow into taking on the best practices of integrating enterprise architecture into the governances and organizational decisions, the mission-oriented decisions, to effectively manage change in the direction they want," Bolton said.
2. Why is an enterprise architecture important?
Developing anything complex requires organization, Tiemann said.
"When you're implementing something that's reasonably complex, you [will] make fewer mistakes and it's easier to do if you do a lot of analysis through a toolset and diagrams and models," he said.
An enterprise architecture allows agency officials to determine their strategic direction and better organize their resources. Agencies that use enterprise architectures are more efficient and effective, experts said. With an enterprise architecture, officials can better understand how their organization works, measure performance and maximize the use of IT resources, said Scott Bernard, an assistant professor at Syracuse University's School of Information Studies.
Enterprise architecture development "is the first professional discipline to provide methods to design, re-engineer and/or modernize an enterprise at all levels of operation," Bernard said. "The perspectives that EA documentation provides can help an enterprise understand itself more, which supports better planning and decision-making."
Simply put: Successful organizations practice enterprise architecture, said Randolph Hite, GAO's director of IT architecture and systems. Without that framework, an agency is left with disparate, nonintegrated systems. "If you look at organizations that haven't had one, [they] have stovepipes and heterogeneous solutions," he said.
3.What is the federal enterprise architecture?
To control IT spending and guide individual agencies' enterprise architecture development, Office of Management and Budget officials created the federal enterprise architecture two and a half years ago. The federal model provides common standards and definitions for consistent governmentwide architecture development and ensures that agencies are making responsible IT investments.
"It's not really an architecture," Hite said. "It's a framework or classification schema to help inform the developers of enterprise architectures for agencies. It's not an enterprise architecture in the sense that it's something that can be implemented, because that's ultimately what you are trying to get to."
Although the federal enterprise architecture originated as a way to rein in IT spending, the concept has evolved, Bolton said. "Now, it focuses on how to share best practices and how to leverage service-
oriented capabilities," he said. "Finally, it's starting to move into one of the original intents, which is [facilitating] integrated services: federal health architecture, Recreation One Stop, lines of business. Each of those is starting to look across agencies."
4.What is a reference model?
The federal enterprise architecture is divided into five reference models: performance, business, service, technical, and data and information. The models detail everything from agencies' functions to the technology that agencies use.
"A reference model is an [enterprise architecture] standard that defines how one or more parts of an EA framework will be documented, and how that documentation will be used," Bernard said. "For example, the federal enterprise architecture's business reference model provides categories for the gathering and reporting of business-level information."
Just as a model presents a simplified version of reality, the reference models present a simplified version of a complex architecture, Hite said, explaining how the various areas within the organization relate to one another. The reference models provide a common taxonomy and give agency officials a starting point to further develop their architectures.
5. How are the reference models related to one another?
The reference models of the federal enterprise architecture are linked to one another. They were designed to be used together, experts said.
"There are very strong dependencies among them, and as you build these models out, you have to understand these dependencies," Hite said.
For example, he said, the business reference model defines how an agency performs its functions, and the performance reference model sets measurements for that performance. The data model outlines the information used to execute the agency's functions, and the service model defines the applications and systems used to perform the functions. Finally, the technical reference model defines the standards used to build those systems, he said.
6. How does the federal enterprise architecture relate to agencies' enterprise architectures?
The federal enterprise architecture provides a framework and guidance for individual agency architectures. Unlike agency architectures, OMB officials did not develop the federal framework for implementation, but rather to provide an outline for agencies. Agency enterprise architectures contain information in diagrams, text and charts. With the federal architecture, agency officials can apply that information to fill out the reference models, Bernard said.
The federal version is a cumulative set of agency architectures, Tiemann said.
"The federal enterprise architecture contains the agency architecture," he said. "It does not exist by itself."
7. How do you develop an enterprise architecture?
Embarking on an enterprise architecture program is much like eating an elephant, said Leon Kappelman, Farrington Professor of Information Systems at the University of North Texas College of Business Administration.
"You do it one bite at a time," he said. "At the same time, you might want to get a handle on what the whole elephant looks like so you can know what part you want to eat first."
Experts agree that developing an architecture is not easy and requires a great deal of organizational understanding and a structured approach. Architects often liken an enterprise architecture to plans for building a house, Bolton said, but the analogy should be expanded because it's much more complex.
"Enterprise architecture is more community building," he said. "We have to work through how to coordinate this community and all the requirements. It forces you to realize there are other communities -- user communities -- that have their own needs, and you have to prioritize them with limited resources."
Before starting the program, officials should ensure proper management support, resources and the requisite skills for developing the architecture, experts said. For Samuel Holcman, president of the Zachman Institute for Framework Advancement, the first step to building an enterprise architecture is taking inventory and organizing the existing systems and functions.
"Every organization has a ton of existing stuff in their enterprise that needs to be harvested," Holcman said. "The architect should take that and organize it across the dimensions and find gaps, overlaps and anomalies before they go and talk to everyone. They start to understand why the organization has issues and are not wasting the business' time. Once that's there, then we go out and talk to the business about the gaps, the overlaps, the anomalies."
Developing the architecture should be seen as a long-term project, rather than as a single project, to ensure IT funding or compliance with federal regulations, experts said.
"You need to recognize this is a continuing program element that's just not going to go away, and it's a part of your planning process," Tiemann said.
Michael is a freelance journalist based in Chicago.