Treasury Enterprise Architecture Framework

Last updated July 16, 2022

Treasury Enterprise Architecture Framework (TEAF) was an enterprise architecture framework for treasury, based on the Zachman Framework. It was developed by the US Department of the Treasury and published in July 2000.^[2] May 2012 this framework has been subsumed by evolving Federal Enterprise Architecture Policy as documented in "The Common Approach to Federal Enterprise Architecture".^[3]

Overview

The Treasury Enterprise Architecture Framework (TEAF) an architectural framework that supports Treasury's business processes in terms of products. This framework guides the development and redesign of the business processes for various bureaus in order to meet the requirements of recent legislation in a rapidly changing technology environment. The TEAF prescribes architectural views and delineates a set of notional products to portray these views.^[1]

The TEAF describes provides:^[1]

Guidance to treasury bureaus concerning the development and evolution of information systems architecture,
A unifying concept, common principles, technologies, and standards for information systems, and
A template for the development of the enterprise architecture.

The TEAF's functional, information and organizational architecture views collectively model the organization’s processes, procedures, and business operations. By grounding the architecture in the business of the organization, the TEAF defines the core business procedures and enterprise processes. Through its explicit models, a TEAF-based architecture enables the identification and reasoning of enterprise- and system-level concerns and investment decisions.^[1]

History

The Treasury Enterprise Architecture Framework (TEAF) is derived from earlier treasury models, such as the US Treasury model (TISAF) released 1997, and the Federal Enterprise Architecture Framework (FEAF), released in 1999.^[4] The first version of the TEAF was released July 2000.

In the new millennium the Treasury Enterprise Architecture Framework (TEAF) has developed into the Treasury Enterprise Architecture (TEA), which aims to establish a roadmap for the modernization and optimization of the U.S. Treasury Department's business processes and IT environment. The Treasury Enterprise Architecture will provide a framework to guide IT investment planning, streamline systems, and ensure that IT programs align with business requirements and strategic goals.^[6]

TEAF topics

Enterprise architecture

Effective management and strategic decision making, especially for information technology (IT) investments, require an integrated view of the enterprise—understanding the interrelationships among the business organizations, their operational processes, and the information systems that support them. An Enterprise Architecture formalizes the identification, documentation, and management of these interrelationships, and supports the management and decision processes. The Enterprise Architecture provides substantial support for evolution of an enterprise as it anticipates and responds to the changing needs of its customers and constituents. The Enterprise Architecture is a vital part of the enterprise's decision-making process, and will evolve along with the enterprise's mission.^[2]

The TEAF has been designed to help both the bureaus and the department develop and maintain their Enterprise Architectures. The TEAF aims to establish a common Enterprise Architecture structure, consistent practices, and common terminology; and to institutionalize Enterprise Architecture governance across the department. This architectural consistency will facilitate integration, information sharing, and exploitation of common requirements across Treasury.^[2]

Enterprise architecture framework

The purpose of the enterprise architecture framework is to provide a structure for producing an Enterprise Architecture (EA) and managing Enterprise Architecture assets. To reduce the complexity and scope of developing and using an Enterprise Architecture, it must be subdivided so that portions may be used independently or built incrementally in separate projects. The TEAF subdivides an Enterprise Architecture by:^[2]

Views
Perspectives
Work products

The TEAF identifies, as shown in the figure, resources and work products that provide direction for EA development, work products constituting the EA description, and work products documenting how to accomplishment an EA implementation. The resources and work products for EA direction and accomplishment are not part of the EA description itself, but are developed and applied during the overall enterprise life cycle. The TEAF Matri, organizes the subdivisions of the EA description and demonstrates the relationships among them. The following sections describe the subdivisions of the EA and their relationships to the TEAF matrix.^[2]

TEAF matrix of views and perspectives

The TEAF matrix is a simplified portrayal of an EA structure to aid in understanding important EA aspects from various vantage points (views and perspectives). The TEAF matrix aims to provide a simple, uniform structure to an entire framework. As depicted in the figure, the TEAF matrix consists of four architectural views (Functional, Information, Organizational, and Infrastructure), which are shown as columns, and four perspectives (Planner, Owner, Designer, and Builder), which appear as rows. The TEAF matrix is a four-by-four matrix with a total of 16 cells. The views and perspectives are described in the following sections.^[2]

When an EA description work product is shown within one cell of the TEAF matrix, it means that the main vantage points for developing that work product correspond to that column (view) and row (perspective). However, information from other views (and sometimes other perspectives) is needed to produce a work product. Not all cells must be "filled-in" by producing an associated work product. Each bureau must define in its EA Roadmap its plans for producing and using an EA to match its needs.^[2]

Enterprise life cycle activities

An enterprise life cycle integrates the management, business, and engineering life cycle processes that span the enterprise to align its business and IT activities. Enterprise Life Cycle refers generally to an organization's approach for managing activities and making decisions during ongoing refreshment of business and technical practices to support its enterprise mission. These activities include investment management, project definition, configuration management, accountability, and guidance for systems development according to a System Development Life Cycle (SDLC). The Enterprise Life Cycle applies to enterprise-wide planning activities and decision making. By contrast, a System Development Life Cycle generally refers to practices for building individual systems. Determining what systems to build is an enterprise-level decision.^[2]

The figure on the left depicts notional activities of an Enterprise Life Cycle methodology. Within the context of this document, Enterprise Life Cycle does not refer to a specific methodology or a specific bureau's approach. Each organization needs to follow a documented Enterprise Life Cycle methodology appropriate to its size, the complexity of its enterprise, and the scope of its needs.^[2]

Products

The TEAF provides a unifying concept, common terminology and principles, common standards and formats, a normalized context for strategic planning and budget formulation, and a universal approach for resolving policy and management issues. It describes the enterprise information systems architecture and its components, including the architecture’s purpose, benefits, characteristics, and structure. The TEAF introduces various architectural views and delineates several modeling techniques. Each view is supported with graphics, data repositories, matrices, or reports (i.e., architectural products).^[1]

The figure shows a matrix with four views and four perspectives. Essential products are shown across the top two rows of the matrix. It is notable that the TEAF includes an Information Assurance Trust model, the Technical Reference Model, and standards profiles as essential work products. These are not often addressed as critical framework components. One of these frameworks should provide a means to logically structure and organize the selected EA products. Now, in order to effectively create and maintain the EA products, a toolset should be selected.^[1]

System interface description

The System Interface Description (SID) links together the Organizational and Infrastructure Views by depicting the assignments of systems and their interfaces to the nodes and needlines described in the Node Connectivity Description. The Node Connectivity Description for a given architecture shows nodes (not always defined in physical terms), while the System Interface Description depicts the systems corresponding to the system nodes. The System Interface Description can be produced at four levels, as described below. Level 1 is an essential work product, while Levels 2, 3, and 4 are supporting work products.^[2]

The System Interface Description identifies the interfaces between nodes, between systems, and between the components of a system, depending on the needs of a particular architecture. A system interface is a simplified or generalized representation of a communications pathway or network, usually depicted graphically as a straight line, with a descriptive label. Often, pairs of connected systems or system components have multiple interfaces between them. The System Interface Description depicts all interfaces between systems and/or system components that are of interest to the architect.^[2]

The graphic descriptions and/or supporting text for the System Interface Description should provide details concerning the capabilities of each system. For example, descriptions of information systems should include details concerning the applications present within the system, the infrastructure services that support the applications, and the means by which the system processes, manipulates, stores, and exchanges data.^[2]

Related Research Articles

The Zachman Framework is an enterprise ontology and is a fundamental structure for enterprise architecture which provides a formal and structured way of viewing and defining an enterprise. The ontology is a two dimensional classification schema that reflects the intersection between two historical classifications. The first are primitive interrogatives: What, How, When, Who, Where, and Why. The second is derived from the philosophical concept of reification, the transformation of an abstract idea into an instantiation. The Zachman Framework reification transformations are: identification, definition, representation, specification, configuration and instantiation.

Business process modeling Activity of representing processes of an enterprise

Business process modeling (BPM) in business process management and systems engineering is the activity of representing processes of an enterprise, so that the current business processes may be analyzed, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from events' logs using process mining tools.

Enterprise architecture (EA) is an analytical discipline that provides methods to comprehensively define, organize, standardize, and document an organization’s structure and interrelationships in terms of certain critical business domains characterizing the entity under analysis. The goal of EA is to create an effective representation of the business enterprise that may be used at all levels of stewardship to guide, optimize, and transform the business as it responds to real-world conditions. EA serves to capture the relationships and interactions between domain elements as described by their processes, functions, applications, events, data, and employed technologies.

The ARIS concept by August-Wilhelm Scheer aims to ensure that an enterprise information system can completely meet its requirements.

The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.

A federal enterprise architecture framework (FEAF) is the U.S. reference enterprise architecture of a federal government. It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement.

The British Ministry of Defence Architecture Framework (MODAF) was an architecture framework which defined a standardised way of conducting enterprise architecture, originally developed by the UK Ministry of Defence. It has since been replaced with the NATO Architecture Framework.

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models - typically matrices and diagrams - for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

Enterprise modelling is the abstract representation, description and definition of the structure, processes, information and resources of an identifiable business, government body, or other large organization.

Enterprise systems engineering (ESE) is the discipline that applies systems engineering to the design of an enterprise. As a discipline, it includes a body of knowledge, principles, and processes tailored to the design of enterprise systems.

In the business sector, business architecture is a discipline that "represents holistic, multidimensional business views of: capabilities, end‐to‐end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders."

In systems engineering, software engineering, and computer science, a function model or functional model is a structured representation of the functions within the modeled system or subject area.

Enterprise life cycle (ELC) in enterprise architecture is the dynamic, iterative process of changing the enterprise over time by incorporating new business processes, new technology, and new capabilities, as well as maintenance, disposition and disposal of existing elements of the enterprise.

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of a whole system from the perspective of a related set of concerns.

Core architecture data model (CADM) in enterprise architecture is a logical data model of information used to describe and build architectures.

Operational View (OV) is one of the basic views defined in the enterprise architecture (EA) of the Department of Defense Architecture Framework V1.5 (DoDAF) and is related with concept of operations. Under DODAF 2, which became operational in 2009, the collections of views are now termed 'viewpoints' and no longer views.

Technical Architecture Framework for Information Management (TAFIM) was a 1990s reference model for enterprise architecture by and for the United States Department of Defense (DoD).

NIST Enterprise Architecture Model is a late-1980s reference model for enterprise architecture. It defines an enterprise architecture by the interrelationship between an enterprise's business, information, and technology environments.

The Treasury Information System Architecture Framework (TISAF) is an early 1990s Enterprise Architecture framework to assist US Treasury Bureaus to develop their Enterprise Information System Architectures (EISAs).

TRAK is a general enterprise architecture framework aimed at systems engineers. It is based on MODAF 1.2.

References

1 2 3 4 5 6 7 8 FEA Consolidated Reference Model Document Archived 2010-07-05 at the Wayback Machine . whitehouse.gov May 2005.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 US Department of the Treasury Chief Information Officer Council (2000). Treasury Enterprise Architecture Framework Archived 2009-03-18 at the Wayback Machine . Version 1, July 2000.
↑ whitehouse.gov (May 12, 2012)The Common Approach to Federal Enterprise Architecture. Accessed January 10, 2013
↑ Jaap Schekkerman (2003). How to Survive in the Jungle of Enterprise Architecture Frameworks. p.113
↑ Standards and Configuration Management Team (SCMT) of the Treasury Enterprise Architecture Sub-Council (TEAC) (2007). Treasury Technical Standards Profile Archived 2008-12-10 at the Wayback Machine . May 2007
↑ E-Government Archived 2008-12-10 at the Wayback Machine U.S. Treasury Department, accessed 09 Dec 2008.

External links

U.S. Treasury - Office of the CIO homepage.
Other Architectures and Frameworks, The Open Group 1999–2006.

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[WH05-1] 1 2 3 4 5 6 7 8 FEA Consolidated Reference Model Document Archived 2010-07-05 at the Wayback Machine . whitehouse.gov May 2005.

[TEAF00-2] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 US Department of the Treasury Chief Information Officer Council (2000). Treasury Enterprise Architecture Framework Archived 2009-03-18 at the Wayback Machine . Version 1, July 2000.

[CA_FEA-3] whitehouse.gov (May 12, 2012)The Common Approach to Federal Enterprise Architecture. Accessed January 10, 2013

[4] Jaap Schekkerman (2003). How to Survive in the Jungle of Enterprise Architecture Frameworks. p.113

[5] Standards and Configuration Management Team (SCMT) of the Treasury Enterprise Architecture Sub-Council (TEAC) (2007). Treasury Technical Standards Profile Archived 2008-12-10 at the Wayback Machine . May 2007

[6] E-Government Archived 2008-12-10 at the Wayback Machine U.S. Treasury Department, accessed 09 Dec 2008.

[2]

[3]

[1]

[4]

[6]