United States on Enterprise architecture

“A conceptual framework that links the Departmental and Programmatic missions, goals, and objectives, and provides a mapping of the current and future DOE business information required to support them.”

“The concept of enterprise architecture emerged in the mid-1980s as a means for optimizing integration and interoperability across organizations. In the early 1990s, GAO research of successful public and private sector organizations led it to identify enterprise architecture as a critical success factor for agencies that are attempting to modernize their information technology (IT) environments. Since then, GAO has repeatedly identified the lack of an enterprise architecture as a key management weakness in major modernization programs at a number of federal agencies. It has also collaborated with the Office of Management and Budget (OMB) and the federal Chief Information Officers (CIO) Council to develop architecture guidance. In 2002, OMB began developing the Federal Enterprise Architecture (FEA), an initiative intended to guide and constrain federal agencies’ enterprise architectures and IT investments.”

“During the mid-1980s, John Zachman... identified the need to use a logical construction blueprint (i.e., an architecture) for defining and controlling the integration of systems and their components... Since Zachman introduced his framework, a number of frameworks have emerged within the federal government, beginning with the publication of the National Institute of Standards and Technology (NIST) framework in 1989. Since that time, other federal entities have issued enterprise architecture frameworks, including the Department of Defense (DOD) and the Department of the Treasury. In September 1999, the federal CIO Council published the Federal Enterprise Architecture Framework, which was intended to provide federal agencies with a common construct for their architectures, thereby facilitating the coordination of common business processes, technology insertion, information flows, and system investments among federal agencies. The Federal Enterprise Architecture Framework describes an approach, including models and definitions, for developing and documenting architecture descriptions for multi-organizational functional segments of the federal government.”

“Since the late 1980s, architecture frameworks have emerged within the federal government, beginning with the publication of the National Institute of Standards and Technology framework in 1989. Subsequently, we issued EA guidance, and our research of successful public and private sector organizations’ IT management practices identified the use of EAs as a factor critical to these organizations’ success. Since that time, other federal entities have issued EA frameworks, including the Department of Defense, Department of the Treasury, and the federal CIO Council. Although the various frameworks use different terminology and somewhat different structures, they are fundamentally consistent in purpose and content, and they are being used today to varying degrees by many federal agencies. The emergence of federal frameworks and guidance over the last 5 years owes largely to the Congress’s passage of the Clinger-Cohen Act in 1996. This act, among other things, requires the CIOs for major departments and agencies to develop, maintain, and facilitate the implementation of information technology architectures as a means of integrating business processes and agency goals with IT. In response to the act, OMB, in collaboration with us, issued guidance on the development and implementation of EAs...”

“The concept of EAs dates back to the mid-1980s. At that time, John Zachman, widely recognized as a leader in the field, identified the need to use a logical construction blueprint (i.e., an architecture) for defining and controlling the integration of systems and their components. Accordingly, Zachman developed a “framework” or structure for logically defining and capturing an architecture. Drawing parallels to the field of classical architecture, and, later, to the aircraft manufacturing industry, in which different work products (e.g., architect plans, contractor plans, shop plans, bills of lading) represent different views of the planned building or aircraft, respectively, Zachman’s framework identified the kind of work products needed to understand and thus build a given system or entity. In short, this framework provides six perspectives or windows from which to view how a given entity operates. The perspectives are those of the (1) strategic planner, (2) system user, (3) system designer, (4) system developer, (5) subcontractor, and (6) system itself. Associated with each of these perspectives, Zachman also proposed six abstractions of the entity, or models covering (1) how the entity operates, (2) what the entity uses to operate, (3) where the entity operates, (4) who operates the entity, (5) when entity operations occur, and (6) why the entity operates. Zachman’s framework provides a way to identify and describe an entity’s existing and planned component parts and the parts’ relationships before the costly and time-consuming efforts associated with developing or transforming the entity begin.”