Cutout: While the TOGAF/DoDAF working group initially set out simply to compare the two frameworks, its efforts recognized that the frameworks were complimentary, meaning architects today can immediately use the TOGAF ADM to build DoDAF architectures, and leverage a more robust, comprehensive, and complete enterprise architecture development method designed with business alignment in mind
About the Authors
Fatma Dandashi is currently leading an Object Management Group (OMG) effort to define a UML profile for the DOD Architecture Framework. Prior to this she supported the development of the Air Force Enterprise Architecture for SAF/XC. Dr. Dandashi was task lead on the MITRE development team responsible for the DoD Architecture Framework Version 1.0 (Volumes I and II), and currently serves on the working group developing DoDAF Version 2.0. She has a PhD in information technology from George Mason University, a Master of Science in computer science from the University of Louisiana (Lafayette), and a Bachelor of Arts in computers/business administration from the Lebanese American University.
Terence Blevins is branch chief and lead architect on the Air Force Operational Support Enterprise Architecture at Mitre. He supports the U.S. Air Force in the role of branch chief and lead architect of the Air Force Operational Support Enterprise Architecture. Terence has been involved with the architecture discipline since the ‘80s when he was at NCR as director of strategic architecture. He has been involved with evolving this discipline since 1996 when he was first introduced to The Open Group’s Architecture Forum. He was its co-chair and a frequent content contributor to TOGAF including the Business Scenario Method. Terence was previously vice-president and CIO of The Open Group where he contributed to its Vision of Boundary-less Information Flow. Mr. Blevins holds undergraduate and masters degrees in mathematics from Youngstown State University. He is TOGAF 8-certified.
Rolf Siegers is Raytheon’s corporate director of architecture & systems integration and an Engineering Fellow. He joined Raytheon in 1984 and leads its Enterprise Architecture Process (REAP) Initiative, a standards-based unification of several architecture frameworks and a company-wide architecting process. Rolf also sits on Raytheon’s corporate Architecture Review Board (ARB), leading and supporting veriious architecture-related initiatives. His program experience includes leading several multi-discipline software architecture teams for large-scale, software-intensive national and international systems since 1997. He is a certified TOGAF-8 architect (The Open Group), a ATAM Evaluator (SEI), and a Software Architecture Professional (SEI). He has bachelor degrees in computer science and mathematics from Huntingdon College and is a member of IEEE and INCOSE.
Judith Jones has served as an advisor to Brussels, CCTA and Industry Organizations on Enterprise Architecture and IS/IT Architecture and Frameworks, eGovernment, Practitioner of TOGAF, and Prince 2. Her background experience includes 10 years as an independent consultant and 20+ years as a business manager with ICL, now Fujitsu Services. She is an experienced program manager and principal consultant with significant skills in customer-centric programs including customer relationship management, enterprise architecture, operational business and IT infrastructures. Her consulting experience includes business change, strategy development and communications, business architecture, business development and marketing, sales, strategy and partnership alignment, business re-engineering to change, specify and deliver customer value, process and commercial initiatives. Judith is an extremely active member of The Open Group and has worked with its Architecture Forum to establish Enterprise Architecture development processes and strategies suitable for global government and the private sector. She currently leads the TOGAF 9 development effort.
So Many Frameworks…So Little Time: What’s an Architect To Do?
The relationships between The Open Group Architecture Framework and the U.S. Department of Defense Architecture Framework
by Fatma Dandashi, Terence Blevins, Rolf Siegers, and Judith Jones
Numerous architecture framework standards have been developed and have matured over the past decade. Some of these standards overlap in their focus areas, and others address completely different aspects of the architecting process. In this latter case, a natural synergy can sometimes be identified and leveraged between frameworks. An industry working group was formed to analyze and document the relationships between The Open Group Architecture Framework and the U.S. Department of Defense Architecture Framework, identifying complementary areas between these two standards. This article is a brief summary of that initiative’s detailed 50-page white paper, “The Open Group Architecture Framework and the U.S. Department of Defense Architecture Framework.”
The Open Group Architecture Framework (TOGAF) is primarily focused on architecting methodology — i.e, the “how to” aspect of architecture without prescribing description constructs to document the architecture. The U.S. Department of Defense Architecture Framework (DoDAF) is focused on architecture description via a set of views without specifying any methodology. The complementary aspects of these two frameworks lead to the question: “Can architects benefit from leveraging both TOGAF and DoDAF together?” Two years ago, this is what a working group that included representatives from MITRE, Raytheon, and Architecting-the-Enterprise — supported by members of The Open Group Architecture Forum — set out to study. Core members of the group included individuals from the official DoDAF and TOGAF standards working groups. The baseline versions of the documents used were TOGAF Version 8.1 and DoDAF Version 1.0. Upcoming revisions of both these standards will heighten their support of architecting service-oriented systems, and both are valuable enablers to architects and architecture teams.
Below are some of the group’s key findings, as well as insights into how architects can use these frameworks to align their business objectives better with IT infrastructure and systems.
Architecture Methodology: The Open Group Architecture Framework
The Open Group first developed the TOGAF Architecture Development Method (ADM) in 1995, baselining it from the Technical Architecture Framework for Information Management (TAFIM), a series of architecture guidance documents provided to them by the U.S. Department of Defense. The DOD spent millions of dollars and several years evolving its TAFIM before turning it over to the Open Group for its ongoing maturation and dissemination across government and industry. TAFIM was subsequently retired.
The ADM is a prescriptive, step-by-step instruction guide for “how to” architect. It’s presented in a series of phases that guide the architect or architecture team through the architecting lifecycle of system development. The first seven releases of TOGAF ADM (1995-2001) were focused on providing technical architecting guidance. The 2002 release of TOGAF 8.0 extended this earlier technical focus into four areas: business, data, applications, and technology architectures. This “collection” of architectures is commonly known as enterprise architecture — the interrelation and integration of business and technology. This same business and technology interrelation and integration are at the heart of service-oriented architecture design and implementation.
Architecture Description: U.S. Department of Defense Architecture Framework (DoDAF)
The primary focus of the DoDAF is architecture description — it prescribes a specific set of models that illustrate the architecture of concern. The framework defines 26 products (see Table 1) that reflect three different architectural viewpoints: operational, systems, and technical standards. DoDAF was developed to support interoperability between systems whose architectures are described with this framework. It’s easier to determine how to integrate systems when they are modeled in a “common language” so that system interfaces, data formats and exchanges, implemented standards, etc. can be analyzed with the operational and system behaviors and structure.
DoDAF has formed the basis for several other frameworks such the U.K.’s Ministry of Defense Architecture Framework (MODAF) and the soon-to-be-published Standardization Agreement (STANAG) NATO Architecture Framework. DoDAF is comprised of two volumes: “Definitions & Guidelines” and “Product Descriptions.”
A supplemental DoDAF Deskbook was also published to provide guidance to DoDAF users. This Deskbook consolidates supporting information such as white papers, case studies, discussion on the Core Architecture Data Model (CADM), architecture tools, Universal Reference Resources (URRs), and the Federal Enterprise Architecture (FEA) reference models.
Table 1 DoDAF Version 1.0 – List of Products
Applicable View
Framework
Product
Framework ?Product Name
General Description
All Views
AV-1
Overview and Summary Information
Scope, purpose, intended users, environment depicted, analytical findings
All Views
AV-2
Integrated Dictionary
Architecture data repository with definitions of all terms used in all products
Operational
OV-1
High-Level Operational Concept Graphic
High-level graphical/textual description of operational concept
Operational
OV-2
Operational Node Connectivity Description
Operational nodes, connectivity & information exchange between nodes
Operational
OV-3
Operational Information Exchange Matrix
Information exchanged between nodes and the relevant attributes of that exchange
Operational
OV-4
Organizational Relationships Chart
Organizational, role, or other relationships among organizations
Operational
OV-5
Operational Activity Model
Capabilities, operational activities, relationships among activities, inputs, and outputs. Overlays can show cost, performing nodes, or other pertinent information.
Operational
OV-6a
Operational Rules Model
One of the three products used to describe operational activity – identifies the business rules that constrain operations
Operational
OV-6b
Operational State Transition Description
One of the three products used to describe operational activity – identifies business process responses to events
Operational
OV-6c
Operational Event/Trace Description
One of the three products used to describe operational activity – traces actions in a scenario or sequence of events
Operational
OV-7
Logical Data Model
Documentation of the system data requirements and structural business process rules of the Operational View.
Systems
SV-1
Systems Interface Description
Identification of systems nodes, systems, and system items and their interconnections within and between nodes
Systems
SV-2
Systems Communications Description
Systems nodes, systems, and system items, and their related communications lay-downs
Systems
SV-3
Systems-to-Systems Matrix
Relationships among systems in a given architecture; can be designed to show relationships of interest, e.g., system-type interfaces, planned versus existing interfaces, etc.
Systems
SV-4
Systems Functionality Description
Functions performed by systems and the system data flows among system functions
Systems
SV-5
Operational Activity to Systems Function Traceability Matrix
Mapping of systems back to capabilities or of system functions back to operational activities
Systems
SV-6
Systems Data Exchange Matrix
Provides details of system data elements being exchanged between systems and the attributes of that exchange
Systems
SV-7
Systems Performance Parameters Matrix
Performance characteristics of System View elements for the appropriate timeframe(s)
Systems
SV-8
System Evolution Description
Planned incremental steps toward migrating a suite of systems to a more efficient suite, or toward evolving a current system to a future implementation
Systems
SV-9
System Technology Forecast
Emerging technologies and software/hardware products that are expected to be available in a given set of time frames that will affect the future development of the architecture
Systems
SV-10a
Systems Rules Model
One of three products used to describe systems functionality – identifies constraints that are imposed on systems functionality due to some aspect of systems design or implementation
Systems
SV-10b
Systems State Transition Description
One of three products used to describe systems functionality – identifies responses of a system to events
Systems
SV-10c
Systems Event/Trace Description
One of three products used to describe systems functionality – identifies system-specific refinements of critical sequences of events described in the Operational View
Systems
SV-11
Physical Schema
Physical implementation of the Logical Data Model entities, e.g., message formats, file structures, physical schema
Technical
TV-1
Technical Standards Profile
Listing of standards that apply to Systems View elements in a given architecture
Technical
TV-2
Technical Standards Forecast
Description of emerging standards and their potential impact on current Systems View elements within a set of time frames
Results Summary
The TOGAF/DoDAF working group validated its original hypothesis that there is synergy across a number of areas between these two frameworks, where DoDAF views can be used throughout the steps of the TOGAF ADM phases to develop a model of the overall architecture. The model can be used to document architectural decisions made following the TOGAF architecture methodology and through ongoing iteration and evolution of all architecture artifacts across the system development lifecycle. The general relationships between the DoDAF views and TOGAF phases are as follows:
DoDAF’s All Views primarily aligns with TOGAF Preliminary Phase and Phase A: Architecture Vision.
DoDAF’s Operational View primarily aligns with TOGAF Phase B: Business Architecture and Phase C: Information Systems Architecture activities.
DoDAF’s Systems View primarily aligns with TOGAF Phase C: Information Systems Architecture, Phase D: Technology Architecture, Phase F: Migration Planning, and Phase E: Opportunities and Solutions.
DoDAF’s Technical Standards View primarily aligns with TOGAF Phase D: Technology Architecture, Technical Reference Model, and Phase E: Opportunities and Solutions.
Table 2 overviews the primary relationships identified through analysis of these two leading architecture frameworks. Specific tailoring guidelines to adapt the TOGAF ADM methodology steps for DoDAF model outputs are documented in the detailed white paper of this analysis effort.
Table 2: TOGAF ADM Phase Mapping to DoDAF Models
TOGAF?Phase
Focus
Applicable DoDAF Models
Preliminary
Framework & Principles
AV-1, OV-1
A
Vision
AV-1, OV-1
B
Business Architecture
AV-2, OV-1, OV-2, OV-3, OV-4, OV-5, OV-6
C
Information Systems Architecture: Data Architecture
OV-7, SV-11
Information Systems Architecture: Applications Architecture
SV-4, SV-5, SV-6, SV-10
D
Technology Architecture
SV-1, SV-2, SV-3, SV-4 (Refined), SV-5, SV-7, SV-10 (Refined), TV-1
E
Opportunities & Solutions
SV-8, SV-9, TV-2
F
Migration Planning
SV-8
G
Implementation Governance
AV-1, OV-1
H
Change Management
SV-9, TV-2
Relevance of the Findings
While the TOGAF/DoDAF working group initially set out simply to compare the two frameworks, its efforts recognized that the frameworks were complimentary. What this means for architects today is that they can immediately use the TOGAF ADM to build DoDAF architectures, and, in doing so, leverage a more robust, comprehensive, and complete enterprise architecture development method designed with business alignment in mind.
The working group also observed that both frameworks are currently dealing with potential gaps such as support for service orientation. The organizations that maintain these different frameworks would benefit should they come together to harmonize their efforts and work on evolving their respective frameworks to deal with the gaps such as security viewpoints, Service Oriented Architectures, and net centricity. For the architect, this ultimately means being better equipped to practice within a much broader space, which is a significant advantage in today’s competitive environment.
Conclusion
Each complex architecting endeavor requires several key elements to be successful: repeatable methodology, standardized output models, formal validation, governance, collaboration guidelines, configuration management, tools, and patterns. The architect can address many of these needs through the application of the Open Group’s Architecture Development Method as a disciplined process in developing the Department of Defense Architecture Framework set of views to model the architecture.
So Many Frameworks…So Little Time: What’s An Architect To Do?
Page PAGE 2 of NUMPAGES 11