 |
 |
 |
 |
| |
|||||
|
|
|
|
|
||||
Frameworks Are Valuable Templates for Developing Enterprise Architectures Ann Reedy It's the rare house that's built without an architectural blueprint. Whether Colonial or Victorian, split-level or ranch, architects follow certain common practices in developing the specifications for building the entire house from various perspectives: foundation, walls, electricity, ventilation, plumbing, etc. In the world of enterprise modernization for government organizations, designers and developers also use common frameworks to integrate multiple perspectives and stakeholder interests within an enterprise architecture (EA). A common framework allows all stakeholders to understand and use an agency's EA, just as homeowners, contractors, and subcontractors build a house from a set of blueprints. A framework establishes a common terminology for cross-organization communication, and a common structure for classifying and organizing the EA contents. Frameworks provide a template for collecting information and they define the information to be stored in an EA repository. They frequently include guidance in terms of formats and detailed information about the contents of architecture work products (such as diagrams, models, or other descriptions of the enterprise's environment and design), as well as graphs, charts, and other tools to help communicate what is contained in the EA. In the federal government, EAs need to be consistent not only horizontally with other organizations at the same level, but also vertically with their higher-level managing organizations (and with external organizations). For example, EAs for agencies operating under the Department of Treasury need to be horizontally consistent to ensure they can cooperate in Treasury-wide missions and objectives, and EAs for the same agencies need to be consistent with the Department of Treasury's own EA. Moreover, if multiple agencies use the same EA framework, the work products could be used to enhance communication and interoperability among these agencies with respect to business processes and IT systems. MITRE's role in the development of many EA frameworks within the federal government puts us in a position to help ensure these frameworks are converging as they evolve. Our experience has allowed us to share lessons learned from multiple organizations with customers and incorporate the lessons into successive framework updates. MITRE's Center for Enterprise Modernization (CEM) is also participating in working groups that support the recently formed Federal Enterprise Architecture (FEA) Program Management Office (PMO). An important FEA PMO objective is to guide federal agencies in implementing architectures that focus on each agency's primary mission and core competencies and eliminate replication of support functions that could be centralized or outsourced. The four major frameworks used by U.S. government organizations are described below, along with information on the framework adopted by the National Association of State Chief Information Officers and the rapidly progressing FEA. Zachman Framework Though not a federal EA framework, the Zachman Framework has been widely accepted as a model for basic enterprise architecture. Many commercial and government frameworks base at least part, if not all, of their underlying structure on Zachman. John Zachman is credited with introducing the concept of an enterprise architecture framework in a 1987 issue of the IBM Systems Journal. His framework is a conceptual structure, in the form of a matrix, which organizes EA information in a standardized manner. It provides perspectives into the enterprise for five layers of enterprise stakeholders (planner, owner, designer, builder, and subcontractor) and orthogonal views based on functional areas (what, how, where, who, when, and why). Zachman does not specify architecture work products, although his publications have suggested the types of information to detail for each "cell" of his matrix. (For more information, see the Zachman Institute for Framework Advancement at www.zifa.com.) One area the Zachman Framework does not cover is information security. Many organizations attempt to retrofit security features into an architecture after it has reached the design or development stages. MITRE is strongly encouraging organizations to build security into the earliest concepts of an architecture. We are sponsoring internal research and development work on a new approach, using a concept called "security patterns" (analogous to design patterns) to build information security into each layer of an EA from initial planning through implementation. Although the MITRE project is based on the Zachman model, the security patterns concept could be used with any structured EA framework. 
Since the passage of the Clinger-Cohen Act and the revision of the OMB's Circular A-130 in 2000, federal agencies have been required to develop EAs to manage their information technology investments and projects. Starting in 2004, agencies must correlate their budget submissions with their EAs. DOD/C4ISR Framework Before EA frameworks were adopted by other government organizations—and before they were required by the Office of Management and Buget (OMB)—the Department of Defense (DOD) had begun developing an overall standardized architecture framework. DOD's C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance) Architecture Framework, Version 1, was produced in June 1996. For several years prior to that time, MITRE worked with the DOD to develop standard technical architectures (such as the Joint Technical Architecture) and technical reference models. Since 1998, C4ISR Version 2 has been the mandated framework for development of DOD architectures and has influenced the development of several other civilian and military architecture frameworks around the world, including NATO's and the Federal Enterprise Architecture Framework (FEAF). The C4ISR Architecture Framework is undergoing an evolutionary revision and is re-emerging as the DOD Architecture Framework. The DOD Architecture Framework is expected to become mandatory for all architectures within the Department of Defense, not only for C4ISR-related architectures, but for other elements as well, such as acquisitions, logistics, and financial management. In addition to being one of the principal authors of the original C4ISR framework, MITRE has contributed to its ongoing development, particularly during this crucial time of transition. The C4ISR/DOD Architecture Framework defines three views and their relationships: (1) operational: tasks, activities, operational nodes, and information flows associated with a mission or business; (2) systems: capabilities that implement operational requirements; and (3) technical: standards and other criteria for systems. Each view has an associated set of architecture work products. Products can be selected and used based on the specific purpose of the architecture. (For more information, see Assistant Secretary of Defense, Networks and Information Integration at http://cio-nii.defense.gov/.) TEAF MITRE played a strong role in the development of the Treasury EAF (TEAF), which is an adaptation of the Zachman Framework that has a specified set of work products similar to those used in the DOD. The TEAF is a common framework for the Treasury Department and its bureaus (including its largest, the IRS), enabling them to produce their EAs in a coherent and consistent manner. Recently, the Customs and Border Protection (CBP) bureau developed an EA based on the TEAF for its enterprise modernization program. This year Customs moved from the Treasury to become part of the Department of Homeland Security (DHS), along with more than 20 other government agencies, including the U.S. Coast Guard. The Coast Guard had also recently initiated an enterprise modernization program and had developed an EA based on the C4ISR Architecture Framework. Some agencies in DHS, including CBP and the Coast Guard, will need to continue modernizing their organizations according to pre-DHS plans, while simultaneously transitioning many of their functions to multiagency missions managed by DHS. MITRE is continuing to help Customs and Border Protection, as well as the Coast Guard and other agencies, with their modernization and architecture programs during this transition. (For more information about TEAF, see the U.S. Department of the Treasury.) FEAF In 1999, the Federal CIO Council developed the FEAF to provide architecture guidance for federal cross-agency or "segment" architectures. The idea is that a full Federal Enterprise Architecture is sufficiently complex that it must be built up out of segment architectures. Segments represent government business areas in which multiple agencies need to cooperate, either to coordinate activities or to share resources. Like the TEAF, the FEAF is based on the Zachman Framework. Unlike the DOD/C4ISR Architecture Framework, the current FEAF does not specify architecture work products, but instead focuses on introducing federal EA concepts and references. MITRE has been working with the Federal CIO Council's Architecture and Infrastructure Committee to update federal architecture guidance and practices in areas such as architecture work products, EA governance, tailored usage by small agencies, criteria for selecting EA tools and repositories, multi-agency planning, and information security. (For more information about FEAF, see the Chief Information Officers Council at www.cio.gov.) As MITRE continues to participate in working groups that advise the Federal CIO Council in updating federal architecture guidance, we will help determine how best to establish a "federated" architecture framework that integrates the best practices in frameworks and architectures across government agencies. NASCIO Framework In addition to the federal government EA frameworks, the National Association of State Chief Information Officers (NASCIO) has established an EA framework for use by states. Compatibility with the NASCIO framework is important to federal government agencies such as the Department of Homeland Security, which must coordinate with state and local agencies and first responders. (For more information, see the National Association of State Chief Information Officers at www.nascio.org.) FEA In 2001, a Presidential task force identified 24 e-government initiatives that could both transform the federal government and simplify common business and technical functions implemented by multiple government agencies. Driven partly by these e-government initiatives, OMB is facilitating implementation of a top-level Federal Enterprise Architecture that will identify common lines of business, performance measures, and data across federal agencies, and will specify common information technologies, components, and services for use by federal agencies. To help carry out this ambitious plan, OMB established the FEA Program Management Office (www.feapmo.gov) in 2002. The OMB's goals for this office are to provide outstanding service to citizens, manage performance, and take advantage of market successes (products and processes) to improve government. The FEA is being constructed as a set of interrelated "reference models," which represent both unique and common functions in government agencies and serve as a basis for identifying duplicative investments, gaps, and opportunities for collaboration within and across federal agencies. In June 2003, the FEA PMO released the newest version of its Business Reference Model, along with initial versions of the Service Component Model and Technical Reference Models. In August, it released the initial draft of the Performance Reference Model. As part of their annual budget submissions to OMB, agencies will be required to report information about their planned investments in terms of these reference models starting in FY2005. |
|||||
| For more information, please contact Ann Reedy using the employee directory. Page last updated: November 14, 2003 | Top of page |
|||||
Solutions That Make a Difference.® |
|
|
Download this issue [617KB]