MODAF (the Ministry of Defence Architecture Framework) is the UK Ministry of Defence’s enterprise architecture framework for planning defense capability, first released in August 2005 and last revised as version 1.2.004 in May 2010. The MOD withdrew it on 15 January 2021 and replaced it with the NATO Architecture Framework version 4 (NAF v4), whose current edition, NAF v4.1, was published in March 2026.
This guide is built from the MOD’s own MODAF documentation, which is still downloadable from GOV.UK: the seven viewpoints, all 47 views, the six-step architecting process the MOD published, how MODAF differed from DoDAF, and a view-by-view map to NAF v4.1 for anyone converting a legacy MODAF model.
| MODAF at a glance | Detail |
|---|---|
| Full name | Ministry of Defence Architecture Framework (MOD Architecture Framework) |
| Owner | UK Ministry of Defence |
| Derived from | US Department of Defense Architecture Framework (DoDAF) version 1.0 |
| First release | MODAF 1.0, August 2005 |
| Final release | MODAF 1.2.004, May 2010 |
| Structure | 7 viewpoints, 47 views |
| Meta-model | M3 (MODAF Meta Model), later MODEM, built on the IDEAS foundation model |
| Status | Withdrawn by the MOD on 15 January 2021 |
| Replaced by | NATO Architecture Framework version 4 (NAF v4); current edition NAF v4.1, March 2026 |
What is MODAF?
MODAF is a set of standard views that describe a defense enterprise from several angles: the capabilities it needs, how it operates, which services and systems deliver those capabilities, which standards apply and which projects will deliver the change. The MOD’s own definition, from its MODAF guidance:
MODAF provides a coherent set of rules and templates, known as ‘views’, that, when populated, provide a graphical and textual visualisation of the business area being investigated.
UK Ministry of Defence, MOD Architecture Framework guidance (GOV.UK)
Each view is a snapshot of one shared model, not a standalone drawing. The MODAF Meta Model (M3) defines how the data in every view relates, so an operational node shown in OV-2 is the same node that owns a swimlane in OV-5, and a model built in one tool can be exchanged with another. The MOD’s stated goal was that MODAF tools be “model driven”.
The MOD developed MODAF from DoDAF version 1.0, then extended and modified it to meet MOD requirements. By the MOD’s own account, MODAF was also used by industry partners including BAE Systems, Thales, Lockheed Martin, Boeing and Serco, by GCHQ and National Air Traffic Services, and was adopted by the Swedish armed forces.
Is MODAF still used in 2026?
Not for new work. On 15 January 2021 the MOD marked its MODAF guidance on GOV.UK as withdrawn, with a one-line notice:
MODAF has been replaced with the NATO Architecture Framework (NAF) V4.
Withdrawal notice, MOD Architecture Framework page, GOV.UK, 15 January 2021
The documents were withdrawn, not deleted. The full MODAF 1.2.004 set (the viewpoint guides, the M3 and MODEM meta-models, the view summary and the FAQs) can still be downloaded from the withdrawn GOV.UK page, which matters if you inherit a MODAF model built before the switch.
NAF v4 has itself moved on. NATO’s Architecture Capability Team published NAF v4.1 (document version 2026.03) in March 2026. It renamed several viewpoints, for example L2 Logical Scenario became Logical Structure and P1 Resource Types became Resource Taxonomy, and it states that NAF v4 compliant architectures can be built with The Open Group’s ArchiMate or the Object Management Group’s Unified Architecture Framework (UAF) Domain Meta-model. OMG published UAF 1.3 as a formal specification in April 2026.
MODAF version history
MODAF went through four releases in five years and then stayed frozen at 1.2.004 for more than a decade before its withdrawal.
| Date | Release or event | What changed |
|---|---|---|
| August 2005 | MODAF 1.0 | First release, developed from DoDAF 1.0 |
| April 2007 | MODAF 1.1 | Changes from a review of the views inherited from DoDAF |
| April 2008 | MODAF 1.2 (1.2.003) | Service Oriented Views added, making seven viewpoints; services used in OV-2, OV-5 and OV-6c; software added as a resource type |
| May 2010 | MODAF 1.2.004 | Final release: new view SV-12b Service Composition, with the old SV-12 renamed SV-12a, for 47 views in total |
| December 2012 | GOV.UK guidance | MOD publishes its MODAF guidance and documents on GOV.UK |
| 15 January 2021 | Withdrawn | Guidance withdrawn; MODAF replaced with NAF v4 |
| March 2026 | NAF v4.1 | Current edition of the successor framework |
Sources: the MOD’s 1.2.004 download, 1.2 version history and 1.2.004 change log; withdrawal date from GOV.UK.
The 7 MODAF viewpoints
MODAF groups its 47 views into seven viewpoints. Each viewpoint serves a different stakeholder, so a capability planner, an acquisition manager and a systems engineer can each read the part of the architecture that concerns them.
| Viewpoint | Code | Views | What it describes (MOD’s definition) |
|---|---|---|---|
| All Views | AV | 2 | A description and glossary of the architecture: scope, ownership, timeframe and the metadata needed to search and query it |
| Strategic Views | StV | 6 | The desired business outcome and the capabilities required to achieve it |
| Operational Views | OV | 11 | The processes, information and entities needed to fulfil the capability requirements, in abstract rather than physical terms |
| Service Oriented Views | SOV | 7 | The services (units of work supplied by providers to consumers) required to support the operational processes |
| Systems Views | SV | 17 | The physical implementation of the operational and service views, which defines the solution |
| Technical Standards Views | TV | 2 | The standards, rules, policy and guidance that apply to the solution |
| Acquisition Views | AcV | 2 | The dependencies and timelines of the projects that will deliver the solution |
Two of these viewpoints were the MOD’s answer to gaps in DoDAF 1.0: Strategic Views for capability managers and Acquisition Views for acquisition managers. The Service Oriented Viewpoint came later, in version 1.2, and the MOD’s framework comparison names NATO’s NAF as the source of the views added in that release.
All 47 MODAF views (version 1.2.004)
MODAF 1.2.004 defines 47 views: 2 All Views, 6 Strategic, 11 Operational, 7 Service Oriented, 17 Systems, 2 Technical Standards and 2 Acquisition. The names below are taken from the MOD’s 1.2.004 documentation, and the category column from the MOD’s 2009 view summary, which sorted every view by the kind of artifact it produces.
| View | Name | Category |
|---|---|---|
| AV-1 | Overview & Summary Information | Tabular |
| AV-2 | Integrated Dictionary | Ontology |
| StV-1 | Enterprise Vision | Tabular |
| StV-2 | Capability Taxonomy | Ontology |
| StV-3 | Capability Phasing | Mapping |
| StV-4 | Capability Dependencies | Structural |
| StV-5 | Capability to Organisation Deployment Mapping | Mapping |
| StV-6 | Operational Activity to Capability Mapping | Mapping |
| OV-1a | High-Level Operational Concept Graphic | Pictorial |
| OV-1b | Operational Concept Description | Tabular |
| OV-1c | Operational Performance Attributes | Tabular |
| OV-2 | Operational Node Relationship Description | Structural |
| OV-3 | Operational Information Exchange Matrix | Tabular |
| OV-4 | Organisational Relationships Chart | Structural |
| OV-5 | Operational Activity Model | Behavioural |
| OV-6a | Operational Rules Model | Behavioural |
| OV-6b | Operational State Transition Description | Behavioural |
| OV-6c | Operational Event-Trace Description | Behavioural |
| OV-7 | Information Model | Structural |
| SOV-1 | Service Taxonomy | Ontology |
| SOV-2 | Service Interface Specification | Tabular |
| SOV-3 | Capability to Service Mapping | Mapping |
| SOV-4a | Service Constraints | Behavioural |
| SOV-4b | Service State Model | Behavioural |
| SOV-4c | Service Interaction Specification | Behavioural |
| SOV-5 | Service Functionality | Behavioural |
| SV-1 | Resource Interaction Specification | Structural |
| SV-2a | System Port Specification | Structural |
| SV-2b | System to System Port Connectivity Description | Structural |
| SV-2c | System Connectivity Clusters | Structural |
| SV-3 | Resource Interaction Matrix | Mapping |
| SV-4 | Functionality Description | Behavioural |
| SV-5 | Function to Operational Activity / Service Function Traceability | Mapping |
| SV-6 | Systems Data Exchange Matrix | Tabular |
| SV-7 | Resource Performance Parameters Matrix | Tabular |
| SV-8 | Capability Configuration Management | Timeline |
| SV-9 | Technology & Skills Forecast | Tabular |
| SV-10a | Resource Constraints Specification | Behavioural |
| SV-10b | Resource State Transition Description | Behavioural |
| SV-10c | Resource Event-Trace Description | Behavioural |
| SV-11 | Physical Schema | Structural |
| SV-12a | Service Provision | Mapping (listed as SV-12 in 2009) |
| SV-12b | Service Composition | Not in the 2009 grid (added 2010) |
| TV-1 | Standards Profile | Tabular |
| TV-2 | Standards Forecast | Tabular |
| AcV-1 | Acquisition Clusters | Structural |
| AcV-2 | Programme Timelines | Timeline |
OV-7 and SV-11 are MODAF’s two data models: the logical information model and the physical schema. If those terms are new, our guide to enterprise data modeling covers the difference.
The seven view categories
The categories cut across the viewpoints: a viewpoint says what a view is about, and a category says what kind of artifact it is. The MOD’s view summary defines them as follows.
- Tabular (11 views): views that are essentially tables, including structured text.
- Structural (10): diagrams of the structural aspects of an architecture.
- Behavioural (12): diagrams of its behavioral aspects.
- Mapping (7): matrix or similar mappings between two different types of information.
- Ontology (3): views that extend the MODAF ontology for a particular architecture.
- Pictorial (1): exactly one view, OV-1a, which is essentially a free-form picture.
- Timeline (2): diagrams of the programmatic aspects of an architecture.
Do you need all 47 views?
No. The MOD was explicit that a team populates only the views relevant to its question, and that most communities would only ever work with a subset:
Indeed, each group of users within the MOD will have different needs and will only populate and exploit those MODAF Views that are of relevance to them.
UK Ministry of Defence, MOD Architecture Framework guidance (GOV.UK)
The MODAF architecting process: 6 steps
The MOD published a six-step example process for building a MODAF architecture in The MODAF Architecting Process (February 2009). It presented the steps as one workable approach, not a mandatory method:
However, the MOD does not prescribe a “MODAF Method” for architecting and creating MODAF views. What this document presents is an example of one approach to take; there are many different ways to approach the architecting process.
UK Ministry of Defence, The MODAF Architecting Process, 2009
- Establish intended use. Agree the questions the architecture must answer, which the MOD calls “exam questions”, often in a workshop with all the stakeholders who will supply or use its data. The MOD’s examples include finding capability gaps and overlaps, trading off capability options and fixing system boundaries and interfaces.
- Define architecture scope. Bound the architecture by process, organization, systems, geography, Defence Lines of Development, timeframe (as-is or to-be) and level of detail; list the views you expect to produce; and tell MODAF governance, so existing architectures can be found and reused.
- Develop data requirements. Write a data-gathering plan (what data, at what granularity, from which sources), assess the security classification, including the risk that combined data is more sensitive than its parts, and choose a tool, checking that it supports the M3.
- Capture architecture. Build the model strictly to the M3 and the MODAF taxonomy, have subject matter experts review it, complete AV-1 and AV-2, and publish the baseline to the repository.
- Conduct analyses. Run the analyses defined in step 1, for example a static gap and overlap analysis against the Strategic Views, or a dynamic network bandwidth analysis using SV-1 configurations and OV-2 and OV-3 traffic data.
- Document results. Feed the findings back into the architecture, review it again and publish the finalized version.
The MOD also described shortcuts. When an architecture largely exists already, steps 1 to 3 can be done in a single quick pass, and read-only users such as assurance teams follow an abbreviated version with no update or publication. The six-step shape outlived MODAF: NAF v4.1 states that its own method is compliant with the six-step architecting process introduced by DoDAF.
What MODAF was designed to achieve
MODAF was designed to make defense architectures consistent, governed, reusable, shareable and adaptable to the question at hand. The MOD never published these as a numbered list of principles, but each one is stated in its own documents.
| Aim | What the MOD’s documentation says | Source |
|---|---|---|
| Standardization | A common set of rules and templates (the views), underpinned by one meta-model, the M3, which is also the standard for exchanging architecture data between modeling tools | MODAF guidance |
| Governance | Major revisions (adding or removing views or viewpoints, renaming a viewpoint, changing the meta-model approach) needed MODAF Steering Group approval; new architectures were to be registered with MODAF governance and published to a repository | Version history; Architecting process |
| Reusability | Capabilities defined in the Strategic Views are expected to be reused across a number of architectures, and repositories were meant to let teams copy whole elements from existing models | MODAF guidance; Architecting process |
| Collaboration | Sharing architecture information to find gaps and overlaps between operating processes and the systems that support them, across the MOD, industry and allies | MODAF guidance; Framework comparison |
| Flexibility | Each team populates only the views relevant to it, and the MOD prescribed no single method | MODAF guidance; Architecting process |
MODAF vs DoDAF: what the MOD changed
MODAF started from DoDAF 1.0 and diverged where the MOD needed to model capability, incremental acquisition and physical flows. The MOD’s own comparison with other frameworks lists the differences and adds that they were not peculiar to Britain:
None of these factors are believed to be specific to the UK procurement regime or UK defence architecture requirements.
UK Ministry of Defence, Comparison of MODAF with other frameworks, 2009
| Area | DoDAF 1.0 | MODAF |
|---|---|---|
| Capability planning | No dedicated viewpoint; architectures framed as as-is and to-be | Strategic Viewpoint for capability managers: capability taxonomy, phasing and dependencies |
| Projects and programs | Treated as out of scope; evolution shown through SV-8, SV-9 and TV-2 | Acquisition Viewpoint linking projects to the capabilities they deliver and to each other |
| Flows between nodes | Needlines carry information exchanges | Node connections also carry flows of energy, materiel and people |
| Nodes | Operational nodes plus separate System Nodes | Operational nodes are strictly logical; what DoDAF calls System Nodes become Physical Assets in the M3 |
| Organizations | A single Organization concept | Separates organizations from posts, and actual organizations from organization types |
For DoDAF’s structure today, see our DoDAF guide; for how DoDAF, MODAF, TOGAF, Zachman and UAF fit together, see enterprise architecture frameworks compared.
How MODAF maps to the Zachman Framework
The MOD mapped each MODAF viewpoint to a row of the Zachman Framework. Most MODAF viewpoints land in the top two rows, because MODAF is about planning and specifying capability rather than implementation technology.
| MODAF viewpoint | Zachman row | The MOD’s reasoning |
|---|---|---|
| Strategic (StV) | Scope / Planner | Enterprise planning |
| Operational (OV) | Business Model / Owner | The business at any one time |
| Systems (SV) | System Model / Designer | Capability specification: designing and assembling capability configurations |
| Technical Standards (TV) | Scope / Planner | Standards for the enterprise as a whole, not implementation technology |
| Acquisition (AcV-2) | Scope / Planner | A closer look at the enterprise planning process |
| StV-6 and SV-5 | Between rows | Both are mappings between layers |
MODAF to NAF v4.1: where each viewpoint went
Each MODAF viewpoint has a home in the NAF v4.1 grid, which arranges viewpoints in five rows (Concepts, Service, Logical, Physical Resource and Architecture Foundation) and columns for taxonomy, structure, connectivity, behavior, information, constraints and roadmap. NATO publishes the mapping from its older NAF v3 views at row level (NAF v4.1, Table 3-24), and the MOD says MODAF was the template for NAF v3.
| MODAF viewpoint | NAF v3 view | NAF v4.1 row | Basis |
|---|---|---|---|
| Strategic (StV) | Capability (NCV) | Concepts (C) | NATO Table 3-24 |
| Service Oriented (SOV) | Service-Oriented (NSOV) | Service (S) | NATO Table 3-24 |
| Operational (OV) | Operational (NOV) | Logical (L) | NATO Table 3-24 |
| Systems (SV) | Systems (NSV) | Physical Resource (P) | NATO Table 3-24 |
| All Views (AV) | All Views (NAV) | Architecture Foundation (A) | NATO Table 3-24 |
| Technical Standards (TV) | Not in NATO’s table | A8 Architecture Standards | Our reading of the A8 purpose statement |
| Acquisition (AcV) | Not in NATO’s table | Roadmap column, chiefly Lr Logical Roadmap | Our reading of the Lr purpose statement |
The NAF v3 column is NATO’s; the step from MODAF to NAF v3 is ours, based on matching view names. The MOD’s own 1.2.004 documentation names NAF v3 equivalents for its service views, for example SOV-1 to NSOV-1 and SOV-3 to NCV-7.
View-level crosswalk for converting a MODAF model
For a migration, the row is not enough; you need to know where each view goes. The table below pairs MODAF views with the NAF v4.1 viewpoint whose name or purpose statement matches. It is our mapping, prepared from the two documents’ own definitions, and NATO does not publish one at this level.
| MODAF view | Closest NAF v4.1 viewpoint | Why they match |
|---|---|---|
| StV-1 Enterprise Vision | C2 Enterprise Vision | Same name; strategic context for the capabilities |
| StV-2 Capability Taxonomy | C1 Capability Taxonomy | Same name; capabilities organized into taxonomies |
| StV-3 Capability Phasing | Cr Capability Roadmap | Both tie capabilities to capability increments over time |
| StV-4 Capability Dependencies | C3 Capability Dependencies | Same name |
| SOV-1 Service Taxonomy | S1 Service Taxonomy | Same name |
| SOV-2 Service Interface Specification | S3 Service Interfaces | Interfaces of a service |
| SOV-3 Capability to Service Mapping | C1-S1 Service to Capability Mapping | Same mapping; the MOD lists NCV-7 as its NAF v3 equivalent |
| SOV-4a Service Constraints | S8 Service Constraints | Same name since NAF v4.1 |
| SOV-4b Service State Model | S5 Service States | States of a service and transitions between them |
| SOV-4c Service Interaction Specification | S6 Service Sequence | NAF called S6 Service Interactions until v4.1 |
| SOV-5 Service Functionality | S4 Service Functions | Functions a service provides |
| OV-2 Operational Node Relationship Description | L2 Logical Structure | Nodes and the Needlines between them |
| OV-5 Operational Activity Model | L4 Logical Activities | Activities of the logical layer |
| OV-6a Operational Rules Model | L8 Logical Constraints | Rules and constraints on the logical layer |
| OV-6b Operational State Transition Description | L5 Logical States | States of a node and transitions between them |
| OV-6c Operational Event-Trace Description | L6 Logical Sequence | Time-ordered sequence of activities and flows |
| OV-7 Information Model | L7 Information Model | Same name |
| SV-1 Resource Interaction Specification | P3 Resource Interactions | Interactions between active resources |
| SV-4 Functionality Description | P4 Resource Functions | Functions carried out by resources |
| SV-5 Function to Operational Activity / Service Function Traceability | L4-P4 Activity to Function Mapping | Links resource functions to operational activities and service functions |
| SV-8 Capability Configuration Management | Pr Resource Roadmap | NAF called Pr Configuration Management until v4.1 |
| SV-10a Resource Constraints Specification | P8 Resource Constraints | Constraints and requirements on resources |
| SV-10b Resource State Transition Description | P5 Resource States | Resource states in response to events |
| SV-10c Resource Event-Trace Description | P6 Resource Sequence | Chronological sequence of resource interactions |
| SV-11 Physical Schema | P7 Data Model | Data entities and their relationships |
| TV-1 Standards Profile and TV-2 Standards Forecast | A8 Architecture Standards | Standards, rules, policy and guidance, including forecasts of change |
| AcV-2 Programme Timelines | Lr Logical Roadmap | Acquisition planning and project dependencies |
The remaining views, such as AV-1, AV-2, OV-1a to OV-1c, OV-3, OV-4, StV-5, StV-6, SV-2a to SV-2c, SV-3, SV-6, SV-7, SV-9, SV-12a, SV-12b and AcV-1, have no clean one-to-one match. Read the purpose statement of each candidate NAF v4.1 viewpoint before moving them.
MODAF’s meta-model: M3 and MODEM
The MODAF Meta Model (M3) is the information model behind every MODAF view: it defines the structure of the architectural data that the views present. Its final version, M3 1.2.004, runs to 172 pages and was a profile that extended UML.
MODEM (the MODAF Ontological Data Exchange Mechanism) is its successor. It contains all the M3 elements but was rebuilt on the IDEAS (International Defence Enterprise Architecture Specification) foundation model. The MOD described the difference this way:
It contains all the MODAF elements currently in M3, but has been built from first principles to support enterprise architecture whereas M3 was a profile that extended UML.
UK Ministry of Defence, MODAF guidance on MODEM (GOV.UK)
NAF v4.1 takes a different route. Its NAF Information Model is conceptual and not meant for direct implementation; for building compliant architectures it names two commercial meta-models, ArchiMate and the UAF Domain Meta-model, and points to the NATO Interoperability Standards and Profiles (NISP) for the versions required.
Inherited a MODAF model? What to do now
Treat the MODAF model as the source format and NAF v4.1 as the target, since the MOD’s own guidance now points to NAF v4. In practice:
- Place each view. Use the crosswalk above, and read the NAF v4.1 purpose statement before moving any view without a clean match.
- Pick the meta-model. NAF v4.1 accepts ArchiMate or the UAF Domain Meta-model; check NISP for the versions your customer requires.
- Keep the MODAF documents. The 1.2.004 viewpoint guides on GOV.UK are still the best record of what each legacy view was meant to contain.
- Check the view names. NAF v4.1 renamed several viewpoints in March 2026, so mappings written against the 2020 edition may use the old names.
FAQs
What does MODAF stand for?
MODAF stands for Ministry of Defence Architecture Framework, also written MOD Architecture Framework. It is the UK Ministry of Defence’s enterprise architecture framework, first released in 2005 and withdrawn on 15 January 2021 in favor of the NATO Architecture Framework version 4 (NAF v4).
Is MODAF still used?
Not for new work. The MOD withdrew its MODAF guidance on 15 January 2021, stating that MODAF has been replaced with NAF v4. The MODAF 1.2.004 documents remain downloadable from GOV.UK, so legacy MODAF models can still be read and migrated. NATO’s current edition of the successor is NAF v4.1, published in March 2026.
How many viewpoints and views does MODAF have?
MODAF 1.2.004 has seven viewpoints (All Views, Strategic, Operational, Service Oriented, Systems, Technical Standards and Acquisition) and 47 views. Sources that say six viewpoints describe MODAF before version 1.2, which added the Service Oriented Viewpoint in 2008.
What is the difference between MODAF and DoDAF?
MODAF was built from DoDAF version 1.0 and extended for UK needs. It added a Strategic Viewpoint for capability planning and an Acquisition Viewpoint for program planning, later a Service Oriented Viewpoint, and it modeled flows of energy, materiel and people between nodes, not just information.
What replaced MODAF?
The NATO Architecture Framework version 4 (NAF v4). Its current edition, NAF v4.1 (document version 2026.03), arranges viewpoints in a grid of five rows (Concepts, Service, Logical, Physical Resource and Architecture Foundation) and accepts ArchiMate or the OMG UAF Domain Meta-model for building compliant architectures.
What is OV-1 in MODAF?
OV-1 is the operational concept, split into three views: OV-1a High-Level Operational Concept Graphic, a free-form picture and the only Pictorial view in MODAF; OV-1b Operational Concept Description, the text that explains the graphic; and OV-1c Operational Performance Attributes, the measures of effectiveness.
How this page was checked
Checked 7 October 2026 against primary sources only: the MOD’s MODAF 1.2.004 documentation and withdrawal notice on GOV.UK, NATO’s NAF v4.1 (document version 2026.03) and the OMG UAF 1.3 specification page. The view names and categories were read from the MOD’s own view summary and 1.2.004 contents pages, not from secondary summaries.
Corrections in this revision: an earlier version of this page said MODAF had six viewpoints (it has seven), described a six-step process and a six-element meta-model that do not appear in the MOD’s documentation, and did not say that MODAF had been withdrawn. The process infographic has been relabeled with the steps the MOD actually published.
Sources
- UK Ministry of Defence, MOD Architecture Framework, GOV.UK (withdrawn 15 January 2021)
- UK Ministry of Defence, MODAF 1.2.004 documentation download (May 2010)
- UK Ministry of Defence, The MODAF Architecting Process (February 2009)
- UK Ministry of Defence, A Summary of MODAF Views by Their Use and Data Types (February 2009)
- MODAF 1.2 Version History and MODAF 1.2.004 Change Log
- UK Ministry of Defence, Comparison of MODAF with Other Frameworks (May 2009)
- MODAF Meta Model (M3) 1.2.004 and MODAF Ontological Data Exchange Mechanism (MODEM)
- NATO, NATO Architecture Framework Version 4.1, document version 2026.03 (March 2026)
- Object Management Group, Unified Architecture Framework, version 1.3 (April 2026)
Using Google Search? Add erp-information.com as a preferred source.