Treasury Information System Architecture Framework: Difference between revisions

Revision as of 07:23, 13 August 2013

Latest revision as of 01:32, 13 August 2018

(2 intermediate revisions by 2 users not shown)

Line 2:

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).<ref name="Raines97">Franklin D. Raines (1997). [http://clinton3.nara.gov/OMB/memoranda/m97-16.html MEMORANDUM FOR THE HEADS OF EXECUTIVE DEPARTMENTS AND AGENCIES] US GOV MEMORANDUM M-97-16, June 18, 1997.</ref>

The TISAF was developed by the [[US Department of the Treasury]] in 1997, and let to the development of the [[Treasury Enterprise Architecture Framework]], released in 2000. The TEAF represents the second-generation framework for Treasury. TISAF was the first-generation framework.<ref name="TEAF00">US Department of the Treasury Chief Information Officer Council (2000). [http://www.eaframeworks.com/TEAF/teaf.doc Treasury Enterprise Architecture Framework] {{Webarchive|url=https://web.archive.org/web/20090318003653/http://www.eaframeworks.com/TEAF/teaf.doc |date=2009-03-18 }}. Version 1, July 2000.</ref>

== Overview ==

Line 14:

* 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"how to”to" processes for developing an information systems architecture in accordance with TISAF.<ref name=" GOA98">United States General Accounting Office (US GOA) (1998). [http://www.gao.gov/archive/1998/ai98070.pdf CUSTOMS SERVICE MODERNIZATION : Architecture Must Be Complete and Enforced to Effectively Build and Maintain Systems] Report to Congressional Requesters.</ref> In 1989 US congress granted $200,000 for the department-wide implementation of the Treasury Information System Architecture Framework.<ref>US Congree (1998) ''Congressional Record, V. 144, Pt. 19, October 19, 1998, to December 19, 1998''. p. 27114</ref>

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.<ref>Mark G. Mykityshyn (2007) ''Assessing the Maturity of Information Architectures for Complex Dynamic Enterprise Systems''. p. 77</ref> 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.

Line 27:

* ''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”"services" (e.g., software and telecommunications) needed to implement information systems across the agency.

TISAF’sTISAF's functional, work, and information components together form the logical view of the architecture, while its infrastructure represents the technical view of the architecture.<ref name=" GOA98"/>

=== 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).<ref name=" GOA98"/>

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’sagency'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’sarchitecture'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.<ref name=" GOA98"/>