Understanding the DODAF Architecture Review Process

A Department of Defense Architecture Framework (DODAF) architecture review is a structured evaluation of defense system architectures to ensure they meet mission requirements, comply with standards, and align with strategic goals. Unlike traditional design reviews, DODAF reviews focus on multiple architectural viewpoints—operational, systems, technical standards, and the all-encompassing view—to provide a comprehensive understanding of the system's structure, behavior, and interoperability. For defense projects, these reviews are not merely a checkbox activity; they are a critical mechanism for risk mitigation, cost control, and ensuring that fielded capabilities deliver warfighter value. This expanded guide walks through every phase of a DODAF architecture review, from pre-review preparation to post-review follow-up, incorporating best practices, common pitfalls, and actionable strategies.

Phase 1: Pre-Review Preparation

The success of a DODAF architecture review hinges on thorough preparation. Rushing into a review session without clear objectives, complete artifacts, and engaged stakeholders often leads to incomplete findings and wasted resources. Preparation typically requires two to four weeks, depending on the project's complexity and the number of viewpoints under review.

Assemble the Review Team

Assemble a cross-functional team that includes the lead architect, systems engineers, requirements managers, cost analysts, configuration managers, and representatives from the user community. Ideally, the team should include someone with formal DODAF training or certification to ensure consistency with DoD guidance. The review board should also include independent architects who were not directly involved in creating the architecture to provide objectivity. For large programs, consider forming a separate review panel with subject matter experts from each primary DODAF viewpoint domain (operational, systems, technical standards, and all-view).

Gather and Review Documentation

Collect all architecture artifacts, including DODAF-described models (AV-1, OV-1 through OV-6c, SV-1 through SV-11, etc.), system specifications, interface control documents (ICDs), risk registers, and prior review reports. The minimum required artifacts for a meaningful review include the Overview and Summary Information (AV-1) and the Integrated Dictionary (AV-2), plus the high-level operational concept (OV-1) and system interface description (SV-1). Ensure that all artifacts are version-controlled and clearly tagged with the date and author. Conduct a pre-screening to verify that each artifact exists in a reviewable state—unlabeled diagrams, missing descriptions, or incorrect nomenclature can derail a session.

Define Scope, Objectives, and Criteria

Clearly document the scope of the review: which viewpoints will be examined, whether the review covers all architectural layers or only operational and systems views, and whether it includes a compliance check against a specific DoD Instruction (e.g., DoDI 5000.02) or Joint Capabilities Integration and Development System (JCIDS) documents. Establish measurable evaluation criteria, such as completeness (e.g., all required data elements present), consistency (e.g., no conflicting OV and SV relationships), and clarity (e.g., models understandable to a non-expert stakeholder). Use a standardized scoring system (e.g., 1–5) for each criterion to enable objective comparisons across review cycles.

Create the Review Agenda

Structure the review session to maximize focus. A typical DODAF review for a medium-complexity project lasts two to three days. Day 1: Overview and All Viewpoint artifacts. Day 2: Operational Viewpoint and Systems Viewpoint deep dives. Day 3: Technical Standards Viewpoint, remaining viewpoints (CV, PV, DIV if required), and synthesis of findings. Allow at least two hours per major viewpoint with a 15-minute break between sessions. Include time for stakeholders to ask clarifying questions without derailing the schedule.

Phase 2: Conducting the Review

The core review process involves systematically evaluating each DODAF-described model against the established criteria. The review should be both qualitative (does the architecture tell a coherent story?) and quantitative (does it satisfy specific measurable requirements?).

Evaluate the All Viewpoint (AV)

Begin with AV-1 and AV-2. AV-1 should clearly state the architecture's purpose, scope, assumptions, and timelines. Look for missing or vague descriptions of key stakeholders, operational contexts, or decision points. The Integrated Dictionary (AV-2) should define every term and acronym used in the models. Common issues include inconsistent definitions across models (e.g., "node" defined in AV-2 but not used consistently in OV-1) and missing definitions for critical data elements.

Assess the Operational Viewpoint (OV)

The Operational Viewpoint describes the missions, tasks, activities, and information exchanges required to support the warfighter. Start with OV-1 (High-Level Operational Concept Graphic) and OV-2 (Operational Resource Flow Description). Validate that OV-1 aligns with the approved Concept of Operations (CONOPS). Check OV-2 for correct identification of external boundary nodes and accurate flow labels. Then review OV-5a/OV-5b (Operational Activity Models) for logical task decomposition. A frequent finding is that OV-5 models fail to reflect actual field procedures, relying instead on ideal workflows. Use red-teaming to challenge assumptions about information exchange rates and security classification levels.

Scrutinize the Systems Viewpoint (SV)

SV-1 (System Interface Description) is the backbone of the systems view. Verify that every interface shown matches a corresponding ICD or design document. Look for missing interfaces that are necessary to support operational activities documented in OV-2. SV-4 (Systems Functionality Description) should map functions to physical system components. Inconsistent function allocation is a common issue—for example, a function appearing in SV-4 but without a corresponding system in SV-1. Also review SV-10b (Systems State Transition Description) if the system has complex behavioral logic; ensure all operational states are covered.

Review the Technical Standards Viewpoint (TV)

TV-1 (Standards Profile) and TV-2 (Standards Forecast) are often overlooked but critical for interoperability. Verify that all listed standards are current and cited correctly (e.g., specific version of MIL-STD-1553 or STANAG). Identify any orphan standards no longer supported by vendors and flag candidate replacements. For programs with NATO interoperability requirements, check alignment with STANAGs and Allied Publications. A robust TV section reduces integration risk across joint and coalition environments.

Validate Stakeholder Needs Across All Viewpoints

Use traceability matrices to map each model back to requirements documents (e.g., Capability Development Document, System/Subsystem Specification). If a requirement has no corresponding architectural element, it is a gap. Conversely, if an architectural element exists without a requirement, it may indicate scope creep or unevaluated added capability. Reconvene stakeholders after each viewpoint session to confirm that the architecture as documented matches their operational needs.

Document Findings in Real Time

Assign a dedicated scribe to record findings during the session. Use a standardized template that captures the finding severity (critical, major, minor), the affected viewpoint, the specific model element, and a recommended corrective action. Avoid generating findings solely from the lead architect's opinion; base each finding on a clear deviation from the evaluation criteria or DODAF standards. At the end of each day, present a preliminary summary of findings to the team for verification.

Common Challenges in DODAF Reviews

Even well-prepared reviews encounter obstacles. Awareness of these challenges helps mitigation.

Incomplete or Inconsistent Artifacts

Many projects produce DODAF artifacts in isolation, leading to contradictions across viewpoints. For example, an OV-2 information exchange may list data elements that do not appear in any SV-6 (System Data Exchange Matrix). Mitigation: require cross-viewpoint consistency checks as part of quality gates. Use automated tools (e.g., Cameo Systems Modeler, IBM Rational Rhapsody) to validate consistency rules.

Stakeholder Disengagement

Stakeholders often perceive architecture reviews as bureaucratic exercises. When key operational users skip sessions, the review risks becoming a technical exercise disconnected from real needs. Mitigation: schedule the review to align with major program milestones and mandate attendance for operational representatives. Provide brief orientation training one week before the review to refresh understanding of DODAF concepts.

Scope Creep

Teams occasionally try to fix architecture problems during the review rather than documenting them for later action. This slows the session and diminishes focus. Mitigation: enforce a "document only" rule during the review. Any needed changes are recorded as findings and addressed in the post-review improvement plan.

Tools and Techniques to Support the Review

Modern DODAF reviews benefit from dedicated software that automates validation and provides a common repository. Popular tools include No Magic's Cameo Systems Modeler (now part of Dassault Systèmes), IBM Engineering Rhapsody, and Sparx Systems Enterprise Architect. These tools support model-based systems engineering (MBSE) and can enforce DODAF compliance rules, generate views automatically, and run impact analyses. For smaller projects without tool budgets, consider using spreadsheet-based checklists and manual diagram reviews, but recognize the increased error risk. Establish a single source of truth (e.g., a shared model or document repository) to eliminate conflicting versions.

Best Practices for a Successful Review

Beyond the step-by-step process, several overarching practices improve review quality and acceptance.

Maintain Objectivity

Base each finding on objective evidence, such as missing interface documentation or mismatched activity flows. Avoid subjective language like "this looks poorly designed." Instead say: "SV-1 shows a connection between System A and System B, but the corresponding ICD does not define the protocol, resulting in insufficient implementation guidance."

Standardize Review Materials

Create a review checklist tailored to the project's DODAF viewpoints. For example, an OV-2 checklist might include: "Are all producer/consumer nodes labeled?" "Does each information flow have an identifier?" "Are security classification markings present?" Using standardized checklists across multiple reviews enables trend analysis and process improvement.

Encourage Collaborative Discussion

Some of the most valuable findings come from unexpected connections made during open dialogue. For example, a systems engineer and an operator might realize that a communication link assumed to be terrestrial actually requires satellite backup. Foster an environment where junior team members feel comfortable challenging assumptions. Use whiteboarding sessions to sketch alternative solutions without committing to them.

Document Everything

Retain all versions of artifacts, review notes, and action items. Establish an audit trail that shows how architecture decisions changed over time. This documentation is invaluable for follow-on reviews, program transitions, and audits by the Defense Contract Management Agency (DCMA) or the Government Accountability Office (GAO).

Integrate With Other Program Reviews

Align the architecture review calendar with Technical Reviews (e.g., System Requirements Review, Preliminary Design Review) to avoid duplication. Architecture findings should feed into system-level risk registers and trade studies. Use the same taxonomy for risk severity to ensure consistency across the program.

Case Study: Example of a DODAF Review Finding

Consider a missile defense program undergoing a DODAF review. The OV-2 showed an information flow between a radar node and a command post labeled "track data." However, the SV-6 did not list any data element named "track data," nor did the message format ICD define it. The review team identified a critical gap: the interface was undefined, meaning the radar vendor could interpret "track data" differently from the command post vendor. The corrective action was to define the data element, update the ICD, and modify both OV-2 and SV-6 accordingly. This finding, caught during the architecture review, prevented a costly integration failure during developmental testing—saving an estimated 200 person-hours of rework and potential schedule delay.

Post-Review Activities

The review does not end when the meeting closes. Effective post-review activities ensure that findings translate into tangible improvements.

Compile the Review Report

Produce a formal report containing an executive summary, detailed findings (organized by viewpoint), severity ratings, and recommended corrective actions. Include a summary dashboard showing the overall score per criterion (e.g., completeness: 3.8/5, consistency: 2.9/5) to highlight weak areas. Distribute the report within one week of the review while discussions are still fresh.

Develop an Improvement Plan

Work with the architecture team to create a prioritized action plan. Critical findings (e.g., missing interfaces that affect safety or security) should be addressed before the next program milestone. Assign owners and deadlines for each action item. Use a configuration management board to track changes to architecture artifacts.

Schedule Follow-up Reviews

Do not treat the architecture review as a one-time event. Schedule a follow-up review after the improvement plan is executed—typically 30 to 60 days later for high-severity findings. Ongoing programs should conduct DODAF reviews at each major acquisition phase (e.g., Technology Maturation and Risk Reduction, Engineering and Manufacturing Development) to maintain architectural integrity as the system evolves.

Continuous Improvement of the Review Process

After several review cycles, conduct a meta-review: evaluate the review process itself. Survey participants about what worked and what was confusing. Look for patterns—e.g., if teams consistently misunderstand OV-3 (Operational Resource Flow Description), consider providing a one-page cheat sheet before the session. Track the number of findings generated per viewpoint; if certain viewpoints always produce zero findings, they may need deeper scrutiny or the evaluation criteria may need adjustment. Continuous improvement ensures that DODAF reviews remain a value-added activity rather than a bureaucratic bottleneck.

External References for Deeper Understanding

For official DODAF guidance, consult the DoD Chief Information Officer's DODAF page. The MITRE Guide to DODAF Viewpoints provides a practical reference for each model's purpose and content. For automated validation, see the OMG Unified Architecture Framework (UAF)—the commercial standard that aligns with DODAF 2.02. Additionally, the Software Engineering Institute (SEI) architecture evaluation resources offer techniques applicable to DoD contexts.

By systematically preparing, conducting, and following up on DODAF architecture reviews, defense organizations can significantly reduce integration risk, ensure stakeholder alignment, and deliver systems that meet their intended mission objectives. The process, while rigorous, pays dividends in cost avoidance and program predictability across the acquisition lifecycle.