Creating Department of Defense Architecture Framework (DoDAF) artifacts is only the first step. Without a deliberate, lifecycle-wide maintenance and update discipline, these architecture views quickly become stale, misaligned, and ultimately useless for decision-making. In my work with DoD program offices and systems engineering teams, I have repeatedly seen that the difference between a valuable architecture and a shelf-ware artifact is the rigor applied to keeping it current. This article details how to maintain and update DoDAF artifacts across every phase of the system lifecycle—from concept development through disposal—so that they remain authoritative, actionable, and compliant with DoD guidance.

The Role of DoDAF Artifacts Across the System Lifecycle

DoDAF artifacts are not static deliverables created once at program inception. They are living representations of a system’s operational, systems, and technical standards views. Each lifecycle phase demands specific updates to ensure the architecture stays aligned with evolving requirements, technology refresh, and operational realities.

Concept and Development Phase: From Blank Canvas to Baseline

In the early stages, artifacts are initially developed to define capability gaps, operational concepts, and candidate solutions. The Operational View (OV-1) and OV-2 capture high-level missions and node connectivity. During development, these views must be updated as requirements mature through the JCIDS process. For instance, when an Analysis of Alternatives alters the system concept, the Systems View (SV-1) and SV-4 (Systems Functionality Description) must reflect new interfaces and functions. Establish a baseline configuration at the System Requirements Review (SRR) and enforce configuration control from that point forward.

Production and Deployment Phase: Capturing Field Feedback

As the system moves into production and operational testing, real-world data drives artifact updates. Operational Activity Models (OV-5) may need revision when user feedback reveals that a planned process is impractical. Interface updates—whether due to hardware changes or software patches—must flow into the Systems Interface Description (SV-2) and Systems Data Exchange Matrix (SV-6). During this phase, maintain a tight feedback loop between test events and architecture governance boards to ensure updates are approved and recorded before the next build cycle.

Sustainment Phase: The Long Tail of Maintenance

Sustainment is where most architecture decay occurs. Systems often operate for decades, undergoing technology refreshes, obsolescence management, and capability upgrades. Every engineering change proposal (ECP) should trigger an impact assessment on the architecture. For example, replacing a legacy radio with a software-defined radio affects the Technical Standards Profile (StdV-1) and Systems Communications Description (SV-6). Without disciplined updates, the architecture no longer represents the fielded system and cannot support downstream decisions like cybersecurity certification or interoperability assessments.

Disposal Phase: Lessons Learned and Archives

Even at disposal, artifacts have value. Update the All View (AV-1) to document the system’s final state, decommissioning schedule, and migration path. Archive the baseline along with change logs to provide a traceable history for future programs that may draw lessons from the architecture. Many organizations fail to capture this final snapshot, losing institutional knowledge. Ensure that your configuration management plan includes a disposition milestone for artifact closure.

Establishing a Governance Structure for Artifact Maintenance

Maintenance of DoDAF artifacts cannot rely on ad hoc updates by individual engineers. It requires a formal governance structure with defined roles, processes, and tools. A typical model includes an Architecture Governance Board (AGB) chartered to approve changes, assign impact analyses, and ensure consistency across views. Below the board, a Architecture Configuration Manager (ACM) handles version control, repository hygiene, and change request tracking.

Configuration Management Best Practices

  • Integrated Change Control: Require a standardized change request form for any proposed artifact update, including the viewpoint identifier, reason for change, and anticipated impact on other views.
  • Versioning Convention: Use semantic versioning (e.g., v2.1.3) aligned with system baselines. Major version increments correspond to significant architectural shifts (e.g., new interface protocols), while minor versions reflect incremental corrections or additions.
  • Peer Review: Before acceptance, all artifacts must be reviewed by at least one subject matter expert from the operational and engineering domains to validate accuracy. Use a structured checklist covering completeness, consistency, and adherence to DoDAF meta-model rules.
  • Repository Access Control: Limit write access to authorized roles. Use locked baselines that can only be changed through formal change requests, and maintain read-only snapshots for audit trail.

Best Practices for Updating DoDAF Views

Each view type has unique update triggers and conventions. Below I distill the key considerations for the major view categories, drawing on guidance from the DoD Architecture Framework Version 2.02 documentation and field experience.

Operational Views (OV)

OV-1 (High-Level Operational Concept Graphic) should be revisited whenever the operational concept changes—for example, after a capability development document update or a new concept of operations (CONOPS) is approved. OV-2 (Operational Resource Flow Description) and OV-3 (Operational Resource Flow Matrix) must be updated when organizational relationships change or new data exchanges are introduced. Because operational views often drive systems view requirements, prioritize their maintenance. If you update an OV-5 activity model, ensure corresponding SV-4 (Systems Functionality Description) activities align.

Systems Views (SV)

Systems views are the most dynamic during sustainment. SV-1 (Systems Interface Description) changes whenever hardware or software interfaces are modified, added, or removed. Keep the SV-2 (Systems Resource Flow Description) in sync with the SV-6 (Systems Resource Flow Matrix)—a common pitfall is updating one and forgetting the other. For cyber-focused updates, the SV-7 (Systems Measures Matrix) must reflect updated performance thresholds resulting from system modifications. I recommend establishing a monthly review cycle for SV artifacts during the sustainment phase, keyed to contract deliverables and engineering reviews.

Technical Standards Views (StdV)

StdV-1 (Technical Standards Profile) lists the standards, protocols, and policy directives the system complies with. This view requires updates whenever a new standard is mandated (e.g., new DISA Security Technical Implementation Guides (STIGs)) or when an adopted standard is retired. The StdV-2 (Technical Standards Forecast) should be revised annually to anticipate future compliance requirements. Because standards often apply across multiple systems, coordinate with the Enterprise Architecture team to maintain alignment.

All Views (AV)

AV-1 (Overview and Summary Information) is the index and narrative of the architecture. Update it with each new baseline to include the change history, scope changes, and key decisions. AV-2 (Integrated Dictionary) must be kept current with any new terms or data definitions introduced across all views. I have seen many architectures fail interoperability assessments simply because AV-2 was outdated and terms were ambiguous. Treat AV-2 as a living glossary, and enforce its use when writing SV and OV elements.

Integrating DoDAF Updates with Systems Engineering Processes

DoDAF artifact maintenance should not be a parallel, isolated activity. It must be embedded into the broader systems engineering lifecycle. For example, the Technical Review and Milestone Approval gates defined in DI-IPSC-81431 and related DoD standards should include architecture artifact completeness and currency checks. When an engineering change proposal (ECP) is processed, the impact analysis must extend to the architecture. In my practice, I tie artifact updates to the Problem Report/Change Request (PR/CR) workflow in the program’s defect tracking system. This ensures no interface or requirements change is implemented without a corresponding architecture update.

Additionally, link DoDAF views to model-based systems engineering (MBSE) artifacts. If you use SysML in tools like Cameo Systems Modeler or MagicDraw, the DoDAF-MODAF (UAF) Profile can synchronize operational and systems views with the underlying parametric and requirement models. This integration eliminates redundant data entry and reduces the risk of inconsistency. For programs adhering to the DoD Digital Engineering strategy, storing architecture in a central, model-based repository ensures that updates propagate automatically to views that reference the same elements.

Leveraging Tools for Efficient Artifact Management

Manual maintenance of DoDAF artifacts in static documents is error-prone and unsustainable. Modern enterprise architecture (EA) tools provide automation, validation, and traceability that dramatically reduce the update burden.

  • UAF Profile Tools: Products such as No Magic MagicDraw (now Dassault) and Sparx Enterprise Architect with the UAF plugin enforce DoDAF meta-model rules. They can generate views automatically from a central model, so when you change an element in one view, all related views are updated.
  • Automated Impact Analysis: Many EA tools have impact matrix features that highlight which views and elements are affected by a change. Use this before approving any modification to understand ripple effects.
  • Version Control Integration: Store artifact files in a configuration management system like SVN or Git. This provides a full change log and enables rollback. For model-based repositories, use tool-integrated version control that captures snapshot of the entire model database.
  • Validation Scripts: Write scripts (e.g., using the tool’s API) to check for common errors such as dangling references, missing required attributes, or violations of DoDAF rules. Automate these checks as part of the build process for each new baseline.

For a deeper understanding of tool capabilities and modeling practices, refer to the official DoDAF resources on the DoD CIO website and the OMG UAF specification that maps to DoDAF.

Common Pitfalls and How to Avoid Them

Through multiple program audits and architecture assessments, I have identified recurring pitfalls that undermine artifact maintenance. Avoid them with these countermeasures.

Stale Artifacts After Major Milestones

Often, artifact creation peaks at milestone reviews, then drops off until the next gate. By then, the architecture has diverged from reality. Countermeasure: Schedule quarterly architecture refresh sprints independent of program reviews. Use a lightweight update form for minor changes and require a full baseline revision at least annually.

Inconsistency Across Views

Updating a single view without propagating the change to related views (e.g., updating SV-1 but not SV-2) creates confusion. Countermeasure: Use a tool that enforces referential integrity. If manual tools remain, maintain a traceability matrix that lists all views and their dependencies, and require the matrix to be updated as part of any change request.

Lack of Stakeholder Engagement

When operators and maintainers are not involved in review, the artifacts represent an idealized system rather than the fielded one. Countermeasure: Include operational and sustainment representatives in the architecture governance board. Have them sign off on OV and StdV updates. Conduct periodic walkthroughs of the architecture with field users to validate accuracy.

Ignoring Small Incremental Changes

Minor modifications (e.g., updating a single interface number or a data field length) often get deferred, then accumulate into significant divergence. Countermeasure: Empower the architecture configuration manager to approve and record small updates that pass a "low impact" test (e.g., no change to external interfaces). This keeps the architecture granularly current without burdening the full board.

Conclusion

Maintaining and updating DoDAF artifacts is not a compliance exercise; it is a strategic capability that ensures system architectures remain trustworthy decision-support tools. By embedding disciplined update processes into the system lifecycle, establishing governance, leveraging modern EA tools, and avoiding common pitfalls, organizations can keep their architecture views accurate, consistent, and valuable from concept through disposal. A living architecture pays dividends in faster change impact analysis, improved stakeholder communication, and smoother interoperability certifications. Treating artifacts as a static deliverable is a mistake; treating them as a dynamic, governed asset is the only path to sustained success.

For further reading, consult the DoD CIO DoDAF page for the latest version guidance, and review the Configuration Management Planning guidance from the Office of the Under Secretary of Defense for Acquisition and Sustainment. Additionally, the OMG UAF standard provides the modeling foundation that integrates directly with DoDAF 2.02.