Treasury Enterprise Architecture Framework (TEAF)

What is Treasury Enterprise Architecture Framework (TEAF)?[1]

The Department of the Treasury published the Treasury Enterprise Architecture Framework (TEAF) in July 2000. The Department of the Treasury is comprised of a number of offices that function as individual enterprises. Therefore, its enterprise architecture needs to map the interrelationships among the organizations in order to manage IT resources. The TEAF aims at facilitating “integration, information sharing, and exploitation of common requirements across the department”. Similar to DoDAF, TEAF includes descriptions of work products for documenting and modeling enterprise architectures. TEAF also explicitly states that these work products align with FEAF models and DoDAF products.

TEAF can be described in terms relative to the Zachman Framework, i.e., ‘perspectives’ and ‘views.’ The four perspectives are the same as in the Zachman Framework and FEAF matrix with the exception that TEAF combines the ‘Builder’ and ‘Subcontractor’ into one, named ‘Builder.’ Also, the TEAF Information view corresponds to the FEAF Data Architecture; the TEAF Functional view corresponds to the FEAF Applications Architecture; and the TEAF Infrastructure view corresponds to the FEAF Technology Architecture. FEAF does not currently reflect the TEAF Organizational view. This view shows the types of workers and the organizational structures. TEAF allows the flexibility to define additional views and perspectives that focus uniquely on areas important to specific stakeholders.

TEAF Matrix[2]

The TEAF (Treasury Enterprise Architecture Framework) is derived from an earlier treasury model, TISAF (Treasury Information System Architecture Framework), the FEAF (Federal Enterprise Architecture Framework, 1999), and the Zachman Framework. The purpose of this architecture is to provide guidance for treasury enterprise architecture development and management and to support treasury bureaus and offices with the implementation of their architectures based on strategic planning. The core of the TEAF is the TEAF Matrix which provides a simplified view of the enterprise architecture from various vantage points (views and perspectives). The 16 cells of the TEAF Matrix contain Work Products which document a set of related information for the enterprise architecture.

TEAF Matrix
source: Wikipedia

  • Specification document: Within the TEAF Matrix for each cell (work product) different kinds of specification documents are suggested: for example an organization chart to describe the organizational view from the planners' perspective or an activity model to describe the functional view from the owners' perspective. For generating the activity model the UML activity diagram for example could be used.
  • Meta model: In the TEAF no explicit meta model(s) for the specification documents exist(s). But some cells and specification documents of the TEAF Matrix are described on a generic level (e.g. organization chart). Additionally, for all suggested specification documents (cells of the TEAF Matrix) their components (entities, attributes, and relationships) are described in detail (e.g. the organization chart). But this description of the structure of the specification documents can only be partly regarded as meta models. Even though there do not exist any detailed meta-models for the specification documents, the integrated enterprise architecture structure in TEAF is governed by an underlying integrated meta-model that defines both element types and their interrelationships. This meta-model provides integration of information and relationships across the multiple types of models (or specification documents) that are used in the various work products (cells of the TEAF Matrix).
  • Role: Within the TEAF one of the key issues is: “Who will use the enterprise architecture descriptions and how?” To contribute to this issue a governance process identifies participant roles and responsibilities. The TEAF contains a description of roles, associated responsibilities, and team composition of architecture management participants. Each bureau defines at appropriate level roles and responsibilities for developing and managing the enterprise architecture.
  • Technique: The TEAF does not contain a detailed description of how to generate the specification documents (work products) that are suggested for each cell of the TEAF Matrix. Even if there is a detailed description of the specification document (entities, attributes, and relationships), techniques for creating them are missing.
  • Procedure model: Within the TEAF a set of activities and guidelines exist to specify the development process. The four basic enterprise architecture activities are:
    • to define an enterprise architecture strategy,
    • to define an enterprise architecture management process,
    • to define an enterprise architecture approach and finally
    • to develop the enterprise architecture repository.

These activities represent a roadmap for the remainder of the TEAF and define a procedure model for developing the enterprise architecture descriptions within the TEAF. Another procedure can be seen in the structure of the TEAF Matrix: going down the rows, the work products get more detailed – starting at a high-level contextual view and driving down to a design view.

See Also