There has been considerable discussion among some of my peers (who are mostly into or working with defense ministries). Most arguments are about the adoption of most appropriate framework for their organization. I decided to give a brief introductory contrast between the two most well-thought frameworks out of all the frameworks discussed.
This brief introductory article is suitable for someone who wants to know what DoDAF/MoDAF are, and when both are usually used. I will be more than happy to add a detailed well-studied article if need arises.
“What exactly is MoDAF?”
MoDAF is British Ministry of Defense Architecture Framework originally developed by the UK Ministry of Defense. It is an architecture framework which defines a standard way of conducting the Enterprise Architecture.
“Okay!! Then what exactly is DoDAF?”
DoDAF is the Department of Defense Architecture Framework of the United States of Department of Defense. This department provides visualization infrastructure for specific stakeholders that concerns through viewpoints organized by various views
MoDAF guidance is useful for the following audience:
- Enterprise architects who are the primary customers of the MoDAF views. They need to correctly interpret its views provided to them and control the tasks required to create new views
- Architectural modelers need guidance on the creating and interchange of the MoDAF views
- Tool Developers and engineers implementing data repositories for storing and manipulating MoDAF architecture data elements
- Trainers and educators requiring reference material for training and support
Meanwhile, DoDAF has been designed to meet the specific business and operational needs of the Department of Defense.
It defines a way of representing an enterprise architecture that enables stakeholders to focus on specific areas of interests in the enterprise.
DoDAF provides the means of abstracting essential information from the underlying complexities and helps its stakeholder’s to present and maintain coherence and consistency
MoDAF is based on the DoDAF version 1 baseline. This section summarizes the main distinctions between MODAF Meta model M3 and the current version of DoDAF. It is recognized that DoDAF is in a state of evolution. And thus the contents of this section should not be taken as indicating significant divergence from the evolving DoDAF
Following factors and needs have led to differences between core MODAF at version 1.1 compared with DoDAF version 1:
- Modelling incremental acquisition programmes as they represent an increasingly common form of defense procurement
- Modelling transformational programmes and their inter-dependencies
- Capability Modelling as the outcome from force development and capability integration programmes
- Solution modelling for resources in terms of people as well as technical system resources
- The need to model physical attributes and capabilities and, by extension, flows of personnel, energy and material not just information
- The need to integrate programme models into traditional architecture models in order to meet the needs of enterprise architects. A drive towards a more coherent object oriented underpinning for the Architectural Framework.
None of these factors are believed to be specific to the UK procurement regime or UK defense architecture requirements.
It is therefore expected that, over time, existing defense architectural frameworks like DoDAF will evolve to accommodate the changing needs of defense architects
The Acquisition Viewpoint was introduced into MODAF to address the concerns of Acquisition Managers. DoDAF takes a traditional view of architecture in which programme development is considered outside scope. To compensate for this, various DoDAF views represent the evolution of systems, technologies and standards.
The integration of acquisition views (organizational and project oriented views) with the more traditional architecture views is a characteristic aspect of MODAF-based enterprise architecture. This approach provides most benefit when time-based views are accepted as being needed at all levels within an enterprise architecture
This all being said, there is still a lot more points that can ideally be added further to explain both the frameworks in more details, scope of which would totally depend on one’s use case and problem statement only.