UAF Architecture Description: [Enterprise, mission or system of systems name]
Architecture description organised by the OMG Unified Architecture Framework (UAF) version 1.3
grid: Architecture Management, Summary and Overview, Strategic, Operational, Services, Personnel,
Resources, Security, Projects, Standards and Actual Resources viewpoints, read across the aspects
(Motivation, Taxonomy, Structure, Connectivity, Processes, States, Sequences, Information,
Parameters, Constraints, Roadmap, Traceability). It records stakeholders and concerns, the grid
cells selected, the content of each viewpoint, cross-cutting requirements, information,
measures and risks, traceability and correspondence rules, the mapping to DoDAF 2.02 and NAF v4,
and model management. Conformance is claimed against ISO/IEC/IEEE 42010:2022. Replace every
[bracketed] value and every row marked Example; the worked example is a regional wildfire
response system of systems.
Document control
| Field | Value |
|---|
| Document ID | [UAF-AD-001] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@chief-architect] |
| Approvers/reviewers | [@capability-owner], [@systems-engineer], [@security-accreditor], [@programme-manager] |
| Last updated | YYYY-MM-DD |
| Classification | [Official / Internal / Restricted] |
| Architecture name and identifier | [Name], [ARCH-ID] |
| Architecture type | [Enterprise / Capability / Solution / System of systems] |
| Time frame | [As-is YYYY / To-be YYYY / Transition steps] |
| Framework and version | OMG UAF 1.3 (DMM formal/25-10-01, UAFML formal/25-10-03) |
| Modelling tool and model location | [Tool and version], [repository path or model server URL] |
| Conformance claimed | ISO/IEC/IEEE 42010:2022 architecture description |
Approvals
| Role | Name | Decision | Date |
|---|
| Architecture owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Capability owner | [@name] | [Decision] | YYYY-MM-DD |
| Security accreditor | [@name] | [Decision] | YYYY-MM-DD |
| Programme manager | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft: scope, stakeholders, selected grid cells |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved to-be architecture for increment 1 |
| 1.1 | YYYY-MM-DD | [@name] | Example: Added Security Constraints and Parameters: Risk views after accreditation review |
Contents
1. Purpose, scope and conformance
1.1 Purpose
[State the decision or activity this description supports.] Example: This architecture
description supports the investment decision for a regional wildfire response capability that
joins fire services, the forestry agency, emergency medical services and two municipalities into
one system of systems. It defines the target capability for 2029, the operational concept, the
services and resources needed, the security posture and the three projects that deliver it.
1.2 Scope and boundary
| Item | Value |
|---|
| Enterprise or system of interest | Example: Regional Wildfire Response (RWR) system of systems |
| Participating organisations | Example: Regional fire service, forestry agency, ambulance trust, two municipalities, national weather service (external) |
| In scope | Example: Detection, alerting, incident command, resource dispatch, public warning, after-action review |
| Out of scope | Example: Long-term forest management; aircraft maintenance |
| Architecture states described | Example: As-is 2026, to-be 2029, transition steps 2027 and 2028 |
| Level of detail | Example: Capability and logical levels complete; resource level for new systems only |
1.3 Conformance
UAF states that it conforms to the architecture description terms of ISO/IEC/IEEE 42010, citing
the 2011 edition. This description claims conformance to the 2022 edition, which uses the same core
ideas (stakeholders, concerns, viewpoints, views, model kinds, correspondences) with an updated
vocabulary. Record how each 42010 element is satisfied here.
| ISO/IEC/IEEE 42010:2022 element | Where satisfied in this document |
|---|
| Identification of the entity of interest and its environment | Section 1.2 |
| Stakeholders and their concerns | Section 4.1 |
| Architecture viewpoints used, with the concerns they frame | Section 4.2 (UAF grid selection) |
| Architecture views and models | Sections 5 to 14 and the referenced model |
| Correspondences and correspondence rules | Section 15 |
| Architecture decisions and rationale | Section 18 |
| Known issues and inconsistencies | Section 18 |
The companion Architecture Description (ISO/IEC/IEEE 42010) template
(architecture/architecture-description-42010) gives the generic structure; this template
specialises it for UAF.
2. Architecture management
UAF 1.3 places metadata about the architecture in the Architecture Management viewpoint (prefix
Am). Record the content of the cells you use.
| Grid cell | View specification | Content in this architecture |
|---|
| Am-Mv | Architecture Principles | Example: AP-01 Capability before solution; AP-02 Reuse national services first; AP-03 Every exchange is secured at the classification of its most sensitive element |
| Am-Sr | Architecture Views | The selected grid cells and their stakeholders (section 4.2) |
| Am-Cn | Architecture References | Example: References to the national emergency services architecture and the forestry agency's IT architecture |
| Am-Pr | Architecture Development Method | Example: Iterative: capability baseline, operational concept workshop, solution options, review, increment planning |
| Am-St | Architecture Status | Example: Strategic and Operational views approved; Resources views in review |
| Am-If | Dictionary | Section 19.1 and the model dictionary |
| Am-Pm | Architecture Parameters | Example: Measures used to compare options: time to alert, coverage, cost |
| Am-Ct | Architecture Constraints | Example: Must reuse the national emergency radio network; no new classified enclave |
| Am-Rm | Architecture Roadmap | Example: Releases of this architecture: v1.0 investment decision, v2.0 design authority baseline |
| Am-Tr | Architecture Traceability | Example: Links from this description to the investment case and the CONOPS |
3. Summary and overview
| Item | Content |
|---|
| Purpose and decision | Example: Approve investment of [amount] for RWR increment 1 |
| Key findings | Example: Detection-to-alert time is limited by manual hand-offs between three control rooms, not by sensors; a shared common operating picture service removes two hand-offs |
| Recommended option | Example: Option B: shared incident data service on the regional cloud, integrated with existing dispatch systems |
| Assumptions | Example: The national weather service keeps providing fire weather indices through its public interface |
| Constraints | Example: Existing radio network retained until 2031 |
| Limitations of this description | Example: Actual Resources analysed for the summer peak only |
| Analysis performed | Example: Coverage simulation, cost comparison of three options, security risk assessment |
4. Stakeholders, concerns and grid selection
4.1 Stakeholders and concerns
| ID | Stakeholder | Concern | Answered by cells |
|---|
| CON-01 (Example) | Regional fire chief (capability owner) | Which capabilities are needed by 2029 and in what order? | St-Tx, St-Rm, Pj-Rm |
| CON-02 (Example) | Incident commanders | How will incidents be run across agencies? | Op-Sr, Op-Pr, Op-Sq, Ps-Sr |
| CON-03 (Example) | Systems engineers | Which systems and interfaces are new or changed? | Rs-Sr, Rs-Cn, Sv-Cn |
| CON-04 (Example) | Security accreditor | What information is exchanged at which classification and how is it protected? | Sc-Tx, Sc-Cn, Sc-Ct, Sc-Mv |
| CON-05 (Example) | Programme manager | Which projects deliver what, with which dependencies? | Pj-Sr, Pj-Cn, Pj-Rm |
| CON-06 (Example) | Finance board | What does each option cost and what does it achieve? | Am-Pm, Ar-Sr, Parameters (section 14.3) |
| [CON-NN] | [Stakeholder] | [Concern] | [Cells] |
4.2 Grid selection
Rows are viewpoints, columns are aspects. Mark each cell S (selected), R (referenced from
another architecture) or leave it blank. Abbreviations follow the UAF acronyms.
| Viewpoint | Mv | Tx | Sr | Cn | Pr | St | Sq | If | Pm | Ct | Rm | Tr |
|---|
| Architecture Management (Am) | S | | S | S | S | S | | S | S | S | S | S |
| Strategic (St) | S | S | S | S | | | | | | S | S | S |
| Operational (Op) | | S | S | S | S | S | S | S | | S | | S |
| Services (Sv) | | S | S | S | S | | | | | S | S | S |
| Personnel (Ps) | | S | S | S | | | | | | S | | S |
| Resources (Rs) | | S | S | S | S | | S | S | | S | S | S |
| Security (Sc) | S | S | S | S | | | | | | S | | S |
| Projects (Pj) | | S | S | S | | | | | | | S | S |
| Standards (Sd) | | S | S | | | | | | | | S | S |
| Actual Resources (Ar) | | | S | S | | | | | | | | S |
Example selection shown. Cells exist in the published grid only where UAF defines a view
specification; check the grid in the DMM before selecting a cell. Requirements (Motivation),
Information and Parameters content that spans viewpoints is summarised in section 14.
5. Strategic viewpoint
5.1 Strategic Motivation and Taxonomy
| ID | Capability | Definition (outcome, solution independent) | Parent | Measure |
|---|
| CAP-01 (Example) | Detect wildfire | Identify a new fire and its location | None | Time from ignition to confirmed detection |
| CAP-01.1 (Example) | Remote sensing detection | Detect fires from sensors and imagery | CAP-01 | Area covered, false alarm rate |
| CAP-02 (Example) | Alert and warn | Inform responders and the public of a confirmed fire | None | Time from detection to first responder alert |
| CAP-03 (Example) | Command multi-agency incident | Coordinate all agencies on one incident picture | None | Number of manual hand-offs |
| CAP-04 (Example) | Dispatch resources | Assign and track crews, vehicles and aircraft | CAP-03 | Time to dispatch |
| CAP-05 (Example) | Learn after action | Capture data and lessons from each incident | None | Share of incidents with completed review |
| [CAP-NN] | [Capability] | [Definition] | [Parent] | [Measure] |
Record challenges and opportunities that motivate the change in the Strategic Motivation view, for
example the rise in fire season length reported by the regional climate assessment.
5.2 Strategic Structure, Connectivity and Constraints
Show capability composition and dependencies. Example: CAP-03 depends on CAP-02 for alerts and
on CAP-04 for resource status; CAP-05 depends on data retained by CAP-03.
| Constraint ID | Capability | Constraint | Source |
|---|
| ST-CT-01 (Example) | CAP-02 | First responder alert within 5 minutes of confirmed detection | Regional emergency plan |
| [ST-CT-NN] | [Capability] | [Constraint] | [Source] |
5.3 Strategic Roadmap: Deployment and Phasing
| Capability | 2026 as-is | 2027 | 2028 | 2029 to-be | Delivered by |
|---|
| CAP-01.1 (Example) | Lookout towers and public calls | Pilot camera network | Camera network region-wide | Camera and satellite fusion | PRJ-01 |
| CAP-03 (Example) | Three separate control rooms | Shared incident data service in build | Shared incident data service live (fire season 2028-05); joint command procedures | Single common operating picture | PRJ-02 |
| [CAP-NN] | [State] | [State] | [State] | [State] | [Project] |
Strategic Traceability links each capability to the operational activities that exhibit it
(section 15).
6. Operational viewpoint
6.1 Operational Taxonomy and Structure
| ID | Operational performer | Role in the concept | Capabilities exhibited |
|---|
| OP-01 (Example) | Detection cell | Receives and confirms fire reports | CAP-01 |
| OP-02 (Example) | Joint incident command | Leads the response to a confirmed incident | CAP-03 |
| OP-03 (Example) | Resource dispatch | Assigns crews and assets | CAP-04 |
| OP-04 (Example) | Public warning authority | Issues warnings to the public | CAP-02 |
| OP-05 (Example) | Field crew | Fights fire and reports status | CAP-03, CAP-04 |
| [OP-NN] | [Performer] | [Role] | [Capabilities] |
6.2 Operational Connectivity
| Exchange ID | From | To | Information | Trigger | Timeliness |
|---|
| OX-01 (Example) | OP-01 | OP-02 | Confirmed fire location and size | Detection confirmed | Within 2 minutes |
| OX-02 (Example) | OP-02 | OP-04 | Warning area and message | Command decision | Within 5 minutes |
| OX-03 (Example) | OP-05 | OP-02 | Crew position and fire line status | Every 10 minutes and on change | Near real time |
| [OX-NN] | [From] | [To] | [Information] | [Trigger] | [Timeliness] |
6.3 Operational Processes, States and Sequences
Describe the main operational activities, the states of a key element and one or two time-ordered
scenarios. The CONOPS (requirements/conops) holds the narrative; this section holds the model.
6.4 Operational Information and Constraints
| ID | Information element | Description | Classification | Constraint |
|---|
| OI-01 (Example) | Incident record | Location, perimeter, status, assigned resources | Official | Retained 7 years for inquiries |
| OI-02 (Example) | Casualty information | Persons injured or missing | Personal, sensitive | Shared with ambulance service only |
| [OI-NN] | [Element] | [Description] | [Classification] | [Constraint] |
7. Services viewpoint
| ID | Service | Consumers | Provider (to be decided in Resources) | Supports activities | Policy and level |
|---|
| SV-01 (Example) | Incident data service | OP-02, OP-03, OP-04 | Shared regional service | Command, dispatch, warning | 99.9 percent during fire season |
| SV-02 (Example) | Sensor alert service | OP-01 | Camera network operator | Detection | Alert within 60 seconds of image analysis |
| SV-03 (Example) | Public warning service | OP-04 | National warning platform | Public warning | Message delivered to area within 3 minutes |
| [SV-NN] | [Service] | [Consumers] | [Provider] | [Activities] | [Level] |
Services Connectivity, Processes and States show how services interact and behave; Services
Roadmap shows when each service version becomes available. Interfaces at resource level go into
the Interface Control Document (architecture/interface-control-document).
8. Personnel viewpoint
| ID | Post or role | Organisation | Fills performer | Competences required | Number in 2029 (Example) |
|---|
| PS-01 (Example) | Joint incident commander | Fire service | OP-02 | Multi-agency command, common operating picture use | 12 |
| PS-02 (Example) | Detection analyst | Forestry agency | OP-01 | Imagery interpretation | 8 |
| PS-03 (Example) | Warning officer | Municipalities | OP-04 | Warning procedures | 6 |
| [PS-NN] | [Post] | [Organisation] | [Performer] | [Competences] | [Number] |
Use Personnel Connectivity for command and reporting lines, Personnel Sequences for hand-overs,
Personnel Constraints for rules such as shift length, and Personnel Roadmap for recruitment and
training over time.
9. Resources viewpoint
| ID | Resource | Type | New or existing | Implements | Owner |
|---|
| RS-01 (Example) | Camera detection network | Capability configuration | New | SV-02 | Forestry agency |
| RS-02 (Example) | Shared incident data platform | Software system | New | SV-01 | Regional IT shared service |
| RS-03 (Example) | Fire service dispatch system | Software system | Existing, changed | Part of SV-01 consumers | Fire service |
| RS-04 (Example) | Emergency radio network | Communications system | Existing | Voice exchanges | National operator |
| [RS-NN] | [Resource] | [Type] | [New / Existing] | [Service or function] | [Owner] |
| Resource exchange | From | To | Realises operational exchange | Protocol or medium |
|---|
| RX-01 (Example) | RS-01 | RS-02 | OX-01 | Event message over secured interface |
| RX-02 (Example) | RS-02 | RS-03 | Dispatch request | Integration interface |
| [RX-NN] | [From] | [To] | [OX-NN] | [Medium] |
Resources Processes, States and Sequences describe functions and behaviour; Resources Roadmap
records versions and retirements; Resources Information gives the logical data model.
Detailed requirements go into the System Requirements Specification
(requirements/system-requirements).
10. Security viewpoint
| ID | Security asset | Owner | Enclave | Classification | Controls applied (Security Controls view) |
|---|
| SC-01 (Example) | Incident record (OI-01) | Fire service | Regional shared enclave | Official | Access by role, encryption in transit and at rest, audit |
| SC-02 (Example) | Casualty information (OI-02) | Ambulance trust | Health enclave | Personal, sensitive | Separate store, need-to-know access, data protection impact assessment |
| SC-03 (Example) | Camera feeds | Forestry agency | Sensor enclave | Official | One-way transfer to shared enclave |
| [SC-NN] | [Asset] | [Owner] | [Enclave] | [Classification] | [Controls] |
Security Connectivity shows exchanges that cross enclave boundaries; Security Constraints records
policy, law and guidance; Security Processes shows security activities such as access approval.
Reference the control catalogue you use (for example ISO/IEC 27001 Annex A or NIST SP 800-53) by
control identifier and keep the accreditation evidence in the security case.
11. Projects viewpoint
| ID | Project | Delivers | Start | Key milestone | Depends on |
|---|
| PRJ-01 (Example) | Camera detection network | RS-01, CAP-01.1 increment | 2027-01 | Region-wide coverage 2028-06 | None |
| PRJ-02 (Example) | Shared incident data platform | RS-02, SV-01, CAP-03 increment | 2027-03 | Live for fire season 2028-05 | PRJ-03 interface changes |
| PRJ-03 (Example) | Dispatch system integration | RS-03 change | 2027-06 | Integration accepted 2028-03 | None |
| [PRJ-NN] | [Project] | [Deliverables] | [Start] | [Milestone] | [Dependencies] |
Link this to the Architecture Roadmap and Transition Plan
(architecture/architecture-roadmap-transition) for the programme view.
12. Standards viewpoint
| ID | Standard or protocol | Version | Applies to | Status over time |
|---|
| SD-01 (Example) | Common Alerting Protocol (OASIS) | [Version] | SV-03 public warning messages | Mandated |
| SD-02 (Example) | Emergency services data exchange standard | [Version] | RX-02 | Current; next version expected [year] |
| SD-03 (Example) | Regional cloud security baseline | [Version] | RS-02 | Mandated |
| [SD-NN] | [Standard] | [Version] | [Element] | [Status] |
Standards Roadmap records when standards are adopted, mandated, or retired.
13. Actual resources viewpoint
| Configuration | Description | Scenario | Measure | Result (Example) |
|---|
| AR-01 Option A (Example) | Existing three control rooms, cameras added | Peak day with 5 simultaneous fires | Confirmed detection to first responder alert, 95th percentile | 14 minutes |
| AR-02 Option B (Example) | Shared incident data platform plus cameras | Same | Same | 4.5 minutes |
| AR-03 Option C (Example) | Single merged control room | Same | Same | 4 minutes, with high organisational cost |
| [AR-NN] | [Configuration] | [Scenario] | [Measure] | [Result] |
Actual Resources Connectivity shows the actual links in each configuration; Actual Resources
Traceability links actual resources to the resource types in section 9.
14. Requirements, information and parameters
14.1 Requirements
| ID | Requirement | Type | Traces to | Verification |
|---|
| REQ-01 (Example) | Alert first responders within 5 minutes of confirmed detection in 95 percent of incidents | Operational | CAP-02, OX-02, ST-CT-01 | Exercise and simulation AR-02 |
| REQ-02 (Example) | Incident data service available 99.9 percent from 1 May to 30 September | Service | SV-01, RS-02 | Monitoring during first season |
| [REQ-NN] | [Requirement] | [Type] | [Elements] | [Method] |
14.2 Information
Summarise the conceptual or logical information model (Operational Information and Resources
Information views) and link to the Data Dictionary (architecture/data-dictionary) where one
exists.
14.3 Parameters
| Parameter type | Content in this architecture |
|---|
| Environment | Example: Fire season conditions: temperature above 30 C, wind above 40 km/h, low connectivity in valleys |
| Measurements | Example: Detection time, alert time, coverage percentage, cost per year |
| Mission vignette and scenario | Example: V-01 Five simultaneous fires on a red flag day; V-02 Fire crossing municipal boundary at night |
| Risk | Example: RSK-01 Camera network coverage gaps in valleys; RSK-02 Dispatch vendor delays interface changes |
15. Traceability and correspondence rules
| Rule ID | Correspondence rule | Check |
|---|
| CR-01 (Example) | Every capability is exhibited by at least one operational activity | Strategic Traceability query; no unlinked capability |
| CR-02 (Example) | Every operational exchange is realised by at least one resource exchange or recorded as manual | Operational to Resources traceability |
| CR-03 (Example) | Every service has a provider resource in the to-be state | Services Traceability |
| CR-04 (Example) | Every security asset has an owner and an enclave | Security Traceability |
| CR-05 (Example) | Every new resource is delivered by a project milestone | Project Traceability |
| [CR-NN] | [Rule] | [Check] |
| Capability | Operational activity | Service | Resource | Project | Requirement |
|---|
| CAP-01.1 (Example) | Confirm fire report | SV-02 | RS-01 | PRJ-01 | [REQ-NN] |
| CAP-02 (Example) | Issue warning | SV-03 | National warning platform | Not applicable (existing) | REQ-01 |
| CAP-03 (Example) | Lead joint response | SV-01 | RS-02, RS-03 | PRJ-02, PRJ-03 | REQ-02 |
16. Mapping to other frameworks
UAF grew out of the Unified Profile for DoDAF and MODAF (UPDM) and states that UAFML can be used to
develop architectures compliant with DoDAF 2.02, MODAF 1.3 and NAF 3.1 and v4. MODAF guidance was
withdrawn by the UK government in January 2021 and replaced by NAF v4; record MODAF only for
legacy architectures.
| Requested framework view group | UAF viewpoint that supplies it | Notes |
|---|
| DoDAF All Viewpoint | Architecture Management, Summary and Overview | Overview and dictionary content |
| DoDAF Capability Viewpoint | Strategic | Capability taxonomy, dependencies, phasing |
| DoDAF Operational Viewpoint | Operational | Performers, activities, exchanges |
| DoDAF Services Viewpoint | Services | Service specifications |
| DoDAF Systems Viewpoint | Resources | Systems and resource exchanges |
| DoDAF Data and Information Viewpoint | Information aspect | Conceptual and logical data |
| DoDAF Project Viewpoint | Projects | Projects and milestones |
| DoDAF Standards Viewpoint | Standards | Standards profile and forecast |
| NAF v4 views | Matching UAF viewpoint and aspect | Check UAF Appendix A, Traceability, for the cell by cell mapping |
17. Model management and tool conformance
| Item | Value |
|---|
| Modelling language | UAFML (UAF Modeling Language), a profile of SysML 1.6 |
| Tool and version | [Tool], [version] |
| Tool conformance level | [Type 1 view specification / Type 2 conceptual syntax / Type 3 formal syntax / Type 4 model interchange], as the vendor declares |
| Model exchange | Example: XMI export at each baseline; stored with this document |
| Configuration management | Example: Model baselined at each document version; changes through the design authority |
| Model conventions | Example: Element names in singular nouns; IDs as in this document; one package per viewpoint |
| Review method | Example: Model walkthrough with stakeholders of each selected cell; correspondence rule queries run before each baseline |
UAF 1.3 defines four conformance types for tools, each building on the one before: view
specification conformance, conceptual syntax conformance, formal syntax conformance and model
interchange conformance. Ask the tool vendor which type their implementation claims.
18. Issues, decisions and review record
| ID | Type | Description | Rationale or resolution | Owner | Status |
|---|
| UAF-DEC-001 (Example) | Decision | Choose Option B (shared incident data platform) | Meets REQ-01 at lower organisational cost than Option C (section 13) | @chief-architect | Approved |
| UAF-ISS-001 (Example) | Issue | Personnel numbers for 2029 depend on the municipal budget | Re-check after budget approval | @capability-owner | Open |
| UAF-ISS-002 (Example) | Inconsistency | RX-02 protocol not yet agreed with dispatch vendor | Resolve in PRJ-03 design | @systems-engineer | Open |
| [UAF-XXX-NNN] | [Type] | [Description] | [Rationale] | [@owner] | [Status] |
Record full decisions in the Architecture Decision Log (architecture/architecture-decision-log).
19. Glossary and references
19.1 Glossary
| Term | Meaning in this document |
|---|
| Viewpoint (UAF grid row) | A group of view specifications addressing related stakeholder concerns, such as Strategic or Operational; UAF 1.3 calls these viewpoints, earlier versions called them domains |
| Aspect (UAF grid column) | A way of looking at elements, such as Taxonomy or Connectivity; earlier versions called these model kinds |
| View specification | A grid cell: the rules for one kind of view |
| Capability | What the enterprise must be able to achieve, independent of how |
| Operational performer | A logical role that carries out operational activities |
| Resource | A system, software, organisational or natural element that performs work |
| Actual resource | A specific configuration of resources used for analysis or verification |
| System of systems | A set of independently owned systems working together for a shared outcome |
19.2 References
| Reference | Version or date | Use |
|---|
| OMG Unified Architecture Framework (UAF), Domain Metamodel (DMM) | Version 1.3, formal/25-10-01, formal version adopted April 2026, omg.org/spec/UAF | Grid, viewpoints, aspects, view specification names |
| OMG UAF Modeling Language (UAFML) | Version 1.3, formal/25-10-03 | Modelling language profile |
| OMG UAF Appendix A Traceability, Appendix B Sample Problem, Appendix C Enterprise Architecture Guide | Version 1.3 (informative) | Framework mapping and method guidance |
| ISO/IEC/IEEE 42010, Software, systems and enterprise: Architecture description | 2022 (Edition 2) | Conformance (section 1.3) |
| DoD Architecture Framework | Version 2.02 | Mapping (section 16) |
| NATO Architecture Framework | Version 4 | Mapping (section 16) |
| UK MOD Architecture Framework (MODAF) | Withdrawn 15 January 2021, replaced by NAF v4 | Legacy note only |
| [Sponsor architecture standard] | [Version] | [Use] |
Standard and licence note
Based on the OMG Unified Architecture Framework (UAF) version 1.3 (Domain Metamodel formal/25-10-01
and UAF Modeling Language formal/25-10-03, formal version April 2026), with conformance mapped to
ISO/IEC/IEEE 42010:2022. Viewpoint, aspect and view specification names are used as published by
OMG for reference; no specification text, figures or tables are reproduced, and all explanations,
selections and the worked example are original. ISO/IEC/IEEE 42010 is copyrighted: only its
element names are used. Check the current OMG specification at omg.org/spec/UAF and the current
edition of each referenced framework before use. UAF, UML and SysML are trademarks of the Object
Management Group; this template is not affiliated with or endorsed by OMG. Template licence: MIT.