Technical Architecture Framework for Information Management (TAFIM) - U.S. DoD (1994)

Theory Publication Information

Citation Information

Why Was the Model Created?

During the 1980s, the US Department of Defense faced significant information technology challenges. The Defense Department operated thousands of information systems across hundreds of military installations, commands, and agencies worldwide. These systems were independently developed, based on different technology platforms, incompatible with each other, and unable to communicate. Each acquisition followed its own technology standards. Systems could not exchange data, coordinate operations, or achieve interoperability. The result was redundant technology investments, incompatible systems, data isolation, and inability to integrate operations across command structures.

DoD recognized that ad-hoc technology acquisition and fragmented system development was unsustainable. Multiple incompatible systems increased technology costs, reduced operational effectiveness, prevented data sharing, and created security vulnerabilities. The military required a coherent technology architecture providing common technology standards, interoperability requirements, and reference models that all systems must align with. A common technical architecture would enable systems to interoperate, reduce technology fragmentation, enable data exchange, and reduce total cost of ownership.

TAFIM was formally withdrawn by the DoD on January 7, 2000, having been superseded by the C4ISR Architecture Framework (v1.0 June 1996, v2.0 December 1997), which was itself restructured as the Department of Defense Architecture Framework (DoDAF) in 2003. However, TAFIM’s layered architecture concepts had already been donated to The Open Group, where they became foundational to TOGAF.

The Technical Architecture Framework for Information Management (TAFIM) was created to provide this common technology architecture across the Department of Defense. TAFIM would establish technology standards, define layered architecture structure, specify reference models for each architectural layer, and require all new Defense information systems to conform to TAFIM architecture. By establishing common technology architecture with mandatory standards, the Defense Department could achieve interoperability, reduce technology fragmentation, and improve operational effectiveness.

Core Concepts and Definitions

TAFIM centers on several core concepts:

Source note: Structural claims about the Technical Reference Model on this page have been verified against TAFIM Version 3.0 Volume 2 (Technical Reference Model, 30 April 1996). Claims about other volumes are drawn from the published TAFIM configuration management record and commonly cited secondary treatments.

• Enterprise Architecture:A comprehensive structure defining how an organization’s information systems, technologies, and business processes align to support organizational strategy. Architecture provides blueprint for technology decisions across enterprise.
• Layered Architecture: Organizing the technical reference model around entities (application software, application platform, external environment) connected by standardized interfaces (Application Program Interface and External Environment Interface). Each entity has defined responsibilities and exchanges services across its interfaces.
• Reference Model: A standardized description of typical systems within each architectural layer. Reference models define common components, interfaces, and standards that actual systems should conform to.
• Interoperability: The ability of different systems to exchange information and coordinate operations despite being developed independently. Interoperability requires common standards, data formats, and communication protocols.
• Standards-Based Architecture: Using industry and government standards to define technology architecture rather than proprietary solutions. Standards-based architecture enables vendor independence and interoperability.
• Technology Acquisition Mandate: Requirement that all new systems acquisitions must conform to TAFIM architecture. Mandate creates compliance requirements and enables architecture governance.
• Information Model: Defining what information is created, stored, processed, and exchanged across systems. Information models enable data standardization and sharing.

What Does the Model Measure?

TAFIM is a prescriptive enterprise architecture framework and reference-model document rather than a measurement or psychometric model. It does not define latent constructs, scales, or validation instruments. Instead, it provides a structure against which DoD information systems can be assessed and categorized.

Evaluation concepts associated with TAFIM typically include:

• Architectural compliance:Whether a given system or acquisition conforms to TAFIM’s mandated standards, interfaces, and reference-model categorization.
• Interoperability: Whether systems can exchange data and coordinate operations as specified by the Technical Reference Model and accompanying standards profile.
• Standards coverage: Which services and interfaces in a system are covered by a TAFIM-referenced standard versus left unspecified or proprietary.
• Reference-model mapping: Whether application, platform, external environment, and information components can be mapped cleanly onto TAFIM layers.

TAFIM does not prescribe specific quantitative metrics; program offices apply the framework through architectural reviews and acquisition documentation rather than scored assessment instruments.

Preceding Models or Theories

TAFIM built upon and extended several prior architectural and standards-based approaches:

• Systems Integration Theory (Gottschalk, 1975): Early research examined how to integrate disparate systems. TAFIM applied integration principles at enterprise scale through standardized architecture.
• Open Systems Architecture (IEEE, 1980s): IEEE standards promoted open systems reducing vendor lock-in. TAFIM adopted open systems principles.
• Standardization Efforts (ISO/IEC, NIST, 1980s-1990s): Government and international standards organizations developed technical standards during the 1980s and early 1990s that predate TAFIM. TAFIM incorporated and referenced standards from standards bodies.
• OSI Reference Model (ISO/IEC 7498, 1984):The Open Systems Interconnection seven-layer reference model established the concept of layered reference architectures and standardized interfaces between layers, predating TAFIM’s Technical Reference Model (which is structured around three entities connected by the Application Program Interface and External Environment Interface, adapted from the IEEE POSIX.0 Open System Environment reference model).
• Database Normalization and Data Modeling (Codd, 1970; Chen, 1976): Relational database theory and entity-relationship modeling provided foundation for information modeling in TAFIM.
• Distributed Computing Concepts (1980s-1990s):Research on distributed systems, client-server architecture, and network computing informed TAFIM’s application platform layer.

Describe The Model

TAFIM provides comprehensive enterprise architecture structure through a multi-volume reference framework defining layered technology architecture, standardized reference models, and acquisition mandates ensuring DoD systems align with common architecture.

Technical Reference Model Entities and Interfaces

The TAFIM Technical Reference Model (Volume 2) adapts the IEEE POSIX.0 Open System Environment reference model. It defines three classes of entities and two types of interfaces rather than a four-layer stack:

• Application Software Entity: Mission-area applications and support applications delivering end-user functions. Mission-area applications implement specific operational requirements (e.g., payroll, materiel management, control of real-time systems). Support applications are common applications (e.g., e-mail, word processing) standardized across mission areas.
• Application Program Interface (API): The interface between the application software and the application platform across which all services are provided. Grouped into System Services, Communications Services, Information Services, and Human/Computer Interaction Services.
• Application Platform Entity: The set of resources (operating system kernel, real-time monitors, hardware and peripheral drivers) that provide services at the API. Implementation-specific characteristics are made transparent to the application software.
• External Environment Interface (EEI): The interface between the application platform and the external environment. Divided into Human/Computer Interaction Services EEI, Information Services EEI, and Communications Services EEI.
• External Environment: Contains external entities with which the application platform exchanges information, classified into human users, information interchange entities, and communications entities.

Key Architectural Principles

• Standards-based design: Use industry standards and government standards rather than proprietary solutions. Standards-based architecture enables vendor independence and system interoperability.
• Layered architecture: Organize systems into distinct layers with defined interfaces. Layering enables independent evolution of each layer without disrupting others.
• Common reference models: Define reference models for each layer describing typical components and interfaces. Reference models enable consistent system design across DoD.
• Interoperability requirements: Specify interoperability requirements and standards that all systems must meet. Mandatory interoperability requirements ensure systems can communicate.
• Information standardization: Establish information standards and data models that systems use. Common information models enable data sharing across systems.
• Acquisition governance: Require all new acquisitions to conform to TAFIM architecture. Acquisition mandate enforces architectural compliance.

TAFIM Content Volumes (Version 3.0, 30 April 1996)

Per the Version 3.0 TAFIM Document Configuration Management Page (all dated 30 April 1996):

• Volume 1: Overview
• Volume 2: Technical Reference Model
• Volume 3: Architecture Concepts and Design Guidance
• Volume 4: DoD SBA (Standards-Based Architecture) Planning Guide
• Volume 5: Program Manager’s Guide for Open Systems
• Volume 6: DoD Goal Security Architecture
• Volume 7: Adopted Information Technology Standards
• Volume 8: HCI Style Guide

The preceding Version 2.0 (30 June 1994) consisted of seven volumes, as recorded in the 30 March 1995 ASD memorandum reproduced in Appendix C of Volume 2.

Main Strengths

• Comprehensive framework: Provides comprehensive architecture structure covering all layers from application software through information management. Framework addresses multiple architectural concerns.
• Standards-based approach: Emphasis on standards-based architecture reduces vendor lock-in and enables vendor independence. Standards enable interoperability across independently developed systems.
• Acquisition mandate: Requiring all new acquisitions to conform to TAFIM provides enforcement mechanism. Mandatory compliance drives architectural adoption across organization.
• Addresses real problems: TAFIM directly addressed DoD problems of system fragmentation, incompatibility, and lack of interoperability. Framework solved documented problems.
• Practical reference models: Provides concrete reference models describing typical system components and architecture. Reference models provide practical guidance for designers and architects.
• Foundation for industry adoption: TAFIM principles influenced industry enterprise architecture thinking and were incorporated into commercial enterprise architecture frameworks.

Main Weaknesses

• Complexity and volume: The multi-volume TAFIM framework (seven volumes in Version 2.0; eight volumes in Version 3.0) is complex and voluminous. Architects and developers struggled to understand and apply TAFIM principles.
• Technology evolution outpaced framework: Technology changed faster than TAFIM could be updated. Framework became outdated as new technologies emerged.
• Over-specification risk: Mandating common architecture across diverse military functions created risk of over-specification. Not all military functions needed identical architecture.
• Vendor resistance: Vendors resisted standards-based approach preferring proprietary solutions. Vendors lobbied against TAFIM-mandated standards.
• Implementation challenges: Retrofitting existing systems to conform to TAFIM architecture was costly and difficult. Legacy systems were incompatible with new framework.
• Governance challenges: Enforcing TAFIM compliance across hundreds of independent military commands and agencies proved difficult. Governance structures were insufficient.
• Limited flexibility: Rigid architectural mandate limited flexibility to address specific command needs or emerging technologies.

Key Contributions

• Early large-scale enterprise architecture program: TAFIM is commonly cited as an early large-scale enterprise architecture program alongside earlier work such as the Zachman Framework (1987). It is not generally credited with originating the discipline, but it operationalized EA concepts through a large federal acquisition mandate.
• Applied layered architecture at enterprise scale: While layered reference models predate TAFIM (notably the OSI model, 1984), TAFIM applied a layered reference structure as a governance artifact across the full enterprise information technology acquisition process.
• Used acquisition-based enforcement at scale: TAFIM tied architectural compliance to the DoD acquisition process, an example of acquisition-based architecture governance that later programs (e.g., Federal agencies) built on.
• Articulated detailed reference models per layer:TAFIM’s per-layer reference models are commonly cited as an influence on subsequent enterprise architecture frameworks, though layered reference-model thinking itself predates TAFIM (e.g., OSI, 1984).
• Advanced standards-based architecture: Championed standards-based architecture over proprietary approaches. Standards-based philosophy influenced DoD and industry practice.
• Addressed system interoperability: Provided framework enabling system interoperability across large complex organizations. Framework solved critical DoD interoperability problem.
• Influenced industry enterprise architecture: TAFIM principles directly influenced commercial enterprise architecture frameworks including TOGAF.
• Foundation for government IT policy: TAFIM-based principles influenced Federal government IT policy and architecture requirements.

Internal Validity

As a prescriptive framework and reference-model document rather than an empirical theory, TAFIM is not subject to construct-validity testing in the psychometric sense. Considerations typically raised about its internal consistency include:

• Logical coherence: The argument that common architecture standards enable interoperability across independent systems is logically sound. Standardization should enable compatibility.
• Addresses documented problems: Framework directly addresses DoD problems of system fragmentation and incompatibility. Problems were well-documented and framework offered solutions.
• Comprehensive coverage: Framework covers multiple architectural layers addressing different aspects of architecture. Comprehensive approach addresses multiple concerns.
• Consistent with systems thinking: Emphasis on layered architecture and component interfaces reflects established systems engineering principles.
• Practical implementation examples: TAFIM-based system implementations demonstrated practical feasibility of framework principles.
• Influenced subsequent frameworks:TAFIM’s influence on TOGAF and other frameworks suggests validity of core principles.

External Validity

External validity considerations concern generalizability of TAFIM across diverse organizational contexts:

• Influenced commercial frameworks: TAFIM principles influenced development of TOGAF (The Open Group Architecture Framework), the dominant enterprise architecture framework in commercial sector.
• Influenced government IT policy: TAFIM principles influenced Federal Architectural Framework and other government IT policies, demonstrating applicability across government agencies.
• Applied across industries: Enterprise architecture discipline originating from TAFIM has been applied across commercial industries, healthcare, finance, and government.
• Scalability challenges: TAFIM worked better in some military commands than others. Scalability across extremely large heterogeneous organizations proved challenging.
• Technology evolution: TAFIM became outdated as technology evolved. Rapid technology change created challenges for static architecture framework.
• Cultural and organizational variation: Different military commands had different cultures and needs. Uniform architecture mandate did not accommodate organizational variation.
• Vendor ecosystem dependence: Success depended on vendors providing standards-based products. Weak vendor commitment to standards limited framework effectiveness.
• Governance capability required: Successful implementation required strong governance capability. Organizations with weak governance structures struggled with implementation.

Relevance to Technology Adoption

TAFIM addresses technology adoption by establishing that technology decisions should align with common enterprise architecture standards rather than being made independently by individual commands or units. TAFIM requires organizations to assess technologies against architecture standards and acquire only technologies conforming to standards. This enables managed technology adoption with interoperability assurance.

Barriers to Standards-Based Technology Adoption Identified

• Lack of architecture standards: Organizations without common standards lack framework for evaluating technology compatibility. Absence of standards leads to technology fragmentation.
• Technology inertia: Legacy systems that do not conform to new standards are expensive to replace. Retrofitting legacy systems to conform to standards is costly.
• Vendor resistance: Vendors may resist standards-based architecture if it limits proprietary solutions. Vendor interests may conflict with organization standardization goals.
• Inadequate governance: Enforcing architecture standards requires strong governance. Organizations with weak governance cannot enforce compliance.
• Standards incompleteness: Standards may not address all technology needs. Needs not covered by standards may require non-compliant acquisitions.
• Organizational silos: Different organizational units may resist common standards favoring autonomy. Organizational culture may prefer independent technology decisions.
• Cost of compliance: Conforming to standards-based architecture may increase technology costs. Standards-compliant products may be more expensive than alternatives.

Leadership Actions the Framework Prescribes

• Establish architecture standards: Define common architecture standards for organization. Standards should specify technology platforms, data formats, and interoperability requirements.
• Create reference models: Develop reference models for each architectural layer describing typical components and interfaces. Reference models enable consistent architecture across organization.
• Mandate architecture compliance: Require all technology acquisitions to conform to architecture standards. Acquisition mandate ensures compliance.
• Establish governance structures: Create governance structures to review acquisitions and enforce standards compliance. Governance ensures architectural oversight.
• Communicate architecture vision: Clearly communicate enterprise architecture strategy to organization. Communicate why standards-based architecture is necessary.
• Manage legacy systems: Develop plans to retire or retrofit legacy systems not conforming to standards. Managing legacy systems enables gradual architecture transition.
• Engage vendors: Work with vendors to develop standards-based products. Vendor engagement ensures product availability supporting architecture.
• Monitor technology evolution: Continuously monitor technology evolution and update architecture standards as needed. Standards must evolve with technology.

Following Models or Theories

TAFIM was succeeded by, and contributed to, a range of enterprise architecture frameworks and policies:

• TOGAF (The Open Group Architecture Framework, 1995 - present): Directly based on TAFIM principles, TOGAF became dominant enterprise architecture framework in commercial sector. TOGAF refined and expanded TAFIM concepts.
• Federal Enterprise Architecture Framework (FEAF, 1999): US Federal government developed FEAF based partly on TAFIM principles. FEAF applied architecture discipline to Federal agencies.
• DoDAF (Department of Defense Architecture Framework, 2003): Replaced TAFIM as DoD architecture framework. DoDAF refined TAFIM principles and addressed limitations.
• Enterprise Architecture Research (1990s-present): Enterprise architecture as a research area has multiple roots (Zachman, TAFIM, and later commercial frameworks among them); TAFIM is commonly cited within this body of work rather than being its sole origin.
• C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance, Reconnaissance) Framework: DoD developed C4ISR framework addressing military command and control architecture. C4ISR complemented TAFIM.
• Digital Government Strategy (White House, 2012; evolved): Federal government strategy emphasized architecture-based approach to digital transformation drawing on TAFIM legacy.

References

1. U.S. Department of Defense. (1994). Technical architecture framework for information management (TAFIM), version 2.0. U.S. Government Publishing Office.

Further Reading

1. The Open Group. (2011). TOGAF version 9.1 (The Open Group Architecture Framework). The Open Group Publications.
2. U.S. Department of Defense. (2003). DoD architecture framework version 1.0. U.S. Department of Defense.
3. Clinger-Cohen Act of 1996, 40 U.S.C. chapter 113 (requiring federal agency information architecture).
4. U.S. General Services Administration. (1999). The Federal Enterprise Architecture framework. U.S. General Services Administration.
5. Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard Business School Press.
6. Weill, P., & Ross, J. W. (2009). IT governance: How top performers manage IT decision rights for superior results. Harvard Business School Press.
7. Shah, H., & Kourdi, M. E. (2007). Frameworks for enterprise architecture. BCS, The Chartered Institute for IT.
8. White House, Executive Office of the President. (2012). Digital government: Building a 21st century platform to better serve the American people.
9. Kappelman, L. A. (Ed.). (2010). The SIM guide to enterprise architecture. CRC Press.

Series Navigation