Treasury Information System Architecture Framework

Last updated March 15, 2019

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).^[1]

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. May 2012 this framework has been subsumed by evolving Federal Enterprise Architecture Policy as documented in "The Common Approach to Federal Enterprise Architecture".

Overview

The Treasury Information System Architecture Framework (TISAF) consists of a list of goals and objectives for planning Treasury information technology a set of architectural principles for developing information systems, an EISA model for describing distinct views of enterprise information systems, and a set of standards for guiding specific product selection.^[1]

Information technology (IT) is the use of computers to store, retrieve, transmit, and manipulate data, or information, often in the context of a business or other enterprise. IT is considered to be a subset of information and communications technology (ICT). An information technology system is generally an information system, a communications system or, more specifically speaking, a computer system – including all hardware, software and peripheral equipment – operated by a limited group of users.

The EISA model provides four architectural views to organize, plan, and build enterprise information systems, consisting of the Information, Functional, and Work architectures and the Infrastructure.^[1]

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.

History

TISAF incorporated elements from the C4ISR Architecture Framework, which was developed by the Mitre Corporation from 1994 on.^[3] In January 1997, US Department of the Treasury issued TISAF Version 1, consisting of three volumes:^[2]

The Mitre Corporation is an American not-for-profit organization based in Bedford, Massachusetts, and McLean, Virginia. It manages federally funded research and development centers (FFRDCs) supporting several U.S. government agencies.

the Treasury Information Systems Architecture Framework,
Treasury Architecture Development Guidance, and
the Treasury Architecture Development Process.

In July 1997, the Treasury issued additional guidance to complement Treasury Information System Architecture Framework (TISAF). This guidance, which was finalized in September 1997, provides “how to” processes for developing an information systems architecture in accordance with TISAF.^[4] In 1989 US congress granted $200,000 for the department-wide implementation of the Treasury Information System Architecture Framework.^[5]

Further developments in the US Department of the Treasury let to the development of the Treasury Enterprise Architecture Framework, first published in July 2000. The TEAF represents a revision to TISAF and incorporated elements of FEAF.^[6] It was the result of an evaluation of Department and bureau experiences in applying and using the TISAF, and emerging best practices from other government organizations and industry.

TEAF is intended to emphasize the broader scope of the architecture framework, which includes both business and technical vantage points within an enterprise-wide perspective. The TEAF includes descriptions of a common suite of work products for documenting and modeling EAs. These work products align with FEAF models and with Department of Defense Architecture Framework (DoDAF) products.^[2]

TISAF building blocks

Departmentwide architecture framework

According to TISAF, a complete architecture has the following four components, each representing a different perspective or view of the agency:^[4]

Functional: A representation of what the organization does (i.e., its mission and business processes) and how the organization can use information systems to support its business operations.
Work: A description of where and by whom information systems are to be used throughout the agency.
Information: A description of what information is needed to support business operations.
Infrastructure: A description of the hardware and “services” (e.g., software and telecommunications) needed to implement information systems across the agency.

TISAF’s functional, work, and information components together form the logical view of the architecture, while its infrastructure represents the technical view of the architecture.^[4]

Top-down approach

To develop and evolve systems that effectively support business functions, a top-down process must be followed. The logical architecture (e.g., business functions and information flows) is defined first and then used to specify supporting systems (e.g., interfaces, standards, and protocols).^[4]

Treasury endorses this top-down approach. Treasury officials responsible for developing and implementing TISAF stated that development of the architecture begins with defining and describing the agency’s major business functions. Once this is accomplished, the agency can identify the relationships among the functions, the information needed to perform the functions, the users and locations of the functions, and the existing and needed applications and related information technology required to execute and support the business functions. According to Treasury guidance, the architecture’s infrastructure component (i.e., its systems specifications and standards) should be derived from the other three components. In addition, the guidance states that each element of the architecture must be integrated and traceable, and the relationships between them must be explicit.^[4]

TISAF Architecture

The Information Architecture is the "what" of information systems which defines and organizes all information needed to perform business operations and describes the relationships among this information. The Functional Architecture is the "how" of information systems which defines and organizes the business functions, processes, or activities that capture, manipulate, and manage the business information to support business operations.^[1]

The Work Architecture is the "where" of information systems which depicts the decentralization of the business, the description of the work organizations to business locations, and the communications and coordination between these locations. The Infrastructure is the "enabler" of information systems which describes the supporting services, computing platforms, and internal and external interfaces needed to provide technology environments within which information systems run.^[1]

To provide a context for discussing technical standards, a Technical Reference Model (TRM) is developed to organize and depict building blocks of an information system as a set of services categorized by functional areas.^[1]

TISAF 1997 to TEAF 2000

Key changes from TISAF 1997 to Treasury Enterprise Architecture Framework (TEAF) 2000 are summarized below:^[2]

The Principles have been revamped
The Work Architecture is renamed to Organizational View
The order of the TEAF Matrix columns has been changed to: Functional, Information, Organizational, and Infrastructure
The TISAF Matrix rows have been renamed in the TEAF Matrix to: Planner, Owner, Designer, Builder
Work products have been revamped
The concept of essential vs. supporting work products has been introduced
The TISAF Technical Reference Model has been removed. Example TRMs are cited
The Standards Profile content has been removed from the TEAF. A Standards Profile is part of an EA, but not part of a framework
Inputs that drive the development of EA are now included and are documented as EA Direction resources and work products
Approaches for implementing an EA are now included and are documented as EA Accomplishment work products
Alignments of the TEAF with the FEAF and the Zachman Framework are provided

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.

Enterprise architecture (EA) is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."

The Open Group Architecture Framework (TOGAF) is a framework for enterprise architecture that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture. TOGAF is a high level approach to design. It is typically modeled at four levels: Business, Application, Data, and Technology. It relies heavily on modularization, standardization, and already existing, proven technologies and products.

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.

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.

Unicom System Architect is an enterprise architecture tool that is used by the business and technology departments of corporations and government agencies to model their business operations and the systems, applications, and databases that support them. System Architect is used to build architectures using various frameworks including TOGAF, ArchiMate, DoDAF, MODAF and NAF. System Architect is developed by UNICOM Systems, a division of UNICOM Global, a United States-based company.

The British Ministry of Defence Architecture Framework (MODAF) is an architecture framework which defines a standardised way of conducting enterprise architecture, originally developed by the UK Ministry of Defence.

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.

In information systems, applications architecture or application architecture is one of several architecture domains that form the pillars of an enterprise architecture (EA).

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.

Business reference model (BRM) is a reference model, concentrating on the functional and organizational aspects of the core business of an enterprise, service organization or government agency.

FDIC Enterprise Architecture Framework is the Enterprise Architecture framework of the United States Federal Deposit Insurance Corporation (FDIC). A lot of the current article is about the Enterprise Architecture Framework developed around 2005, and currently anno 2011 out-of-date.

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.

Enterprise interoperability is the ability of an enterprise—a company or other large organization—to functionally link activities, such as product design, supply chains, manufacturing, in an efficient and competitive way.

Jaap Schekkerman is a Dutch computer scientist and founder of the Institute For Enterprise Architecture Developments (IFEAD) in the Netherlands. He is particularly known for his 2003 book How to Survive in the Jungle of Enterprise Architecture in which he compared 14 Enterprise Architecture Frameworks.

Dynamic Enterprise Architecture (DYA) is an enterprise architecture framework developed by the consulting company Sogeti. It focuses on software design in general, and improving the architectural design function.

References

1 2 3 4 5 6 Franklin D. Raines (1997). MEMORANDUM FOR THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES US GOV MEMORANDUM M-97-16, June 18, 1997.
1 2 3 4 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.
↑ Janis Putman (2001) Architecting With Rm-Odp. p. 719
1 2 3 4 5 United States General Accounting Office (US GOA) (1998). CUSTOMS SERVICE MODERNIZATION : Architecture Must Be Complete and Enforced to Effectively Build and Maintain Systems Report to Congressional Requesters.
↑ US Congree (1998) Congressional Record, V. 144, Pt. 19, October 19, 1998, to December 19, 1998. p. 27114
↑ Mark G. Mykityshyn (2007) Assessing the Maturity of Information Architectures for Complex Dynamic Enterprise Systems. p. 77

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.

[Raines97-1] 1 2 3 4 5 6 Franklin D. Raines (1997). MEMORANDUM FOR THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES US GOV MEMORANDUM M-97-16, June 18, 1997.

[TEAF00-2] 1 2 3 4 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.

[3] Janis Putman (2001) Architecting With Rm-Odp. p. 719

[GOA98-4] 1 2 3 4 5 United States General Accounting Office (US GOA) (1998). CUSTOMS SERVICE MODERNIZATION : Architecture Must Be Complete and Enforced to Effectively Build and Maintain Systems Report to Congressional Requesters.

[5] US Congree (1998) Congressional Record, V. 144, Pt. 19, October 19, 1998, to December 19, 1998. p. 27114

[6] Mark G. Mykityshyn (2007) Assessing the Maturity of Information Architectures for Complex Dynamic Enterprise Systems. p. 77