Military frameworks, systems engineering and enterprise architecture

Image illustrating architecture

(Courtesy of Pixaby on

In the world of architecture modeling, the military organizations like the US Department of Defense (DoD), the UK Ministry of Defence (MoD) or the NATO organization created enterprise architecture frameworks adapted to their needs.

On the market today, 3 main frameworks are existing and used in military projects:

Objectives and dimensions of the military frameworks

The main objective searched by military organization is to be able to master a global project of several billions of dollars/euros from the design phase to the support and operational phase. Because those projects/programs can be very large and very complex, the idea was that everyone (military organization and supplier organizations) share the same set of "views" on the program in order to share understanding of what was to be done, how requirements were taken into account, what is the full lifecycle of the product and how the project should be managed.

Table 1: Structure of military requirements

# Dimension Details
1 Product definition Can be an aircraft, weapon, complex system, etc. and all the related IT systems to manage them. The objective is to use a systems engineering approach (model-based in that case), based on requirements.
2 Product support and operations The objective of this phase is to detail all the systems that will permit the support of the product. This is generally a wide topic including maintenance, parts procurement, etc. Moreover, the product use must be envisaged in operations preparation and in battle field in coordination with other systems and organizations.
3 Digital transformation The objective of this phase is to evaluate and deal with the impacts of the product and product support in the operational organization, processes and IT of the army.
4 Project plan The objective is to be able to describe the the plan to deliver the product conforming to the requirements (phases, milestones and so on), to permit project steering, and product support procurement.

We can classify the military enterprise architecture frameworks as pursuing 4 objectives, as shown in table 1.

Modeling domains

Those 4 objectives are traditionally modeled with 3 different modeling techniques:

Figure 1: The 3 domains Military framework concerns in the industrial V-model

The 3 modeling domains of military frameworks

The figure 1 shows the 3 modeling modeling domains that they are traditionally covered in military frameworks.

In terms of modeling, we could say that the core objective of the military frameworks is to have, in a single repository, the systems engineering (MBE/MBSE), the enterprise architecture and the project management gathered together.

Positioning in the V-model

Those 4 areas of concern can be mapped on an industrial V-model as shown in Figure 2.

Figure 2: Military framework concerns in the industrial V-model

Military framework in V-model

The first dimension, product definition, is in the left part of the V and corresponds to the product architecture, from its operational conditions, requirements to its system design. The second dimension is corresponding to product support (we often speak about "support concept"). The two last dimensions are running all along the project, being at the project/program level or at the digital transformation level (integrate the new product into the current organizations).

We can see in Figure 2 how an integrated modeling of those two highest branches of the V-model can be important for the military customer:

Most of all, on top of being a common modeling language, it enables complex tradeoffs, including performance, finance, supportability, etc.


The RFLP process

In manufacturing, the objective is to create products. The starting point of a product manufacturing is generally a set of requirements. To go from the requirements to the product is generally a long process involving the following phases:

This view is, for sure, simplified and some industries (or specific businesses inside the industries like embedded software, electronics, or mechatronics) are often using more complex processes, with dedicated sub-processes for every discipline.

However, seen from a high level standpoint, the various phases of the MBSE are the 4 we mentioned, leading some people to call the MBSE process a "RFLP" process (RFLP standing for Requirements, Functional, Logical, Physical).

Currently, we find more and more people skipping the "S" of MBSE to talk about MBE, for model-based engineering. The term becomes larger because it does not have this embedded system connotation anymore.

Maintaining the digital thread

For sure, a RFLP process aims to create a digital "thread" or "link" between the various entities, at least between the requirements, the functions and the systems (plus all the connectivity semantics). The system entities are a solution matching the requirements, and so is their "physical" description; but this solution is the result of various levels of trade-off analysis. In other terms, solutions can (and will) evolve with time.

The full digital thread of information will have to be maintained through changes. Changes in requirements (or operational conditions) will lead to changes in systems and changes in systems (like obsolescence) must be compliant with requirements.

RFLP processes with many variable dimensions

The RFLP processes that we can find in the industry are generally describing many parameters attached to the various elements (requirements, functions, systems, etc.): the performance, the price, the various criteria of manufacturability, the respect of regulation and standards are among the most important of parameters (the weight also in aerospace).

Those parameters are crucial because, during the various design phases:

Modeling in MBSE

The topic is quite vast but we will, once again, try a simplification. Modeling can be done mainly with 3 different approaches:

In the first style of systems engineering, the digital thread is extremely difficult to maintain or trace, and generally, to be able to do it, a lot of manual and painful efforts are required. Most of the time, the requirements are vague, not measurable, and the trade-offs analysis are not recorded.

With time, we see a growing consciousness of the advantages of the third solution to be able to do complex trade-offs very early in the product design phase (see the system engineering book of knowledge here).

MBE/MBSE seen from the military

The MBE/MBSE modeling techniques are a way for military organizations to ensure that their requirements are correctly understood and are refined the right way. Especially, the requirements being tightly coupled with operational conditions (often called CONOPS for CONcept of OPerationS), the graphical modeling in a unified language is an enabler for common understanding, sharing of decisions in complex trade-offs and sharing of information.

For sure, this is being true for the design phase of the system.

About the complexity of modeling hybrid systems

The fact is systems engineering is very adapted to design the early phases of a product and do the right structuring trade-offs.

But the "products" of today are much more complex than the products of yesterday. If we take the sample of aerospace, the "ground segment", or the set of software that enable to manage the machines from the ground is much bigger and much more complex than before.

Let us take a sample in a non military domain: the constellations of satellites. To be able to operate a constellation of more than 100 satellites in a crowded space, the ground segment complexity is very high.

The thing is it is not easy to design the product (the satellite) as the set of software required to operate many instances of this very satellite. More and more military systems are facing the same kind of problems: they must tightly couple together the product definition and the product support design phases.

How to ensure that all the requirements are taken in charge by all sub-systems in the global system, above all when the way of model management software systems is more related to IT techniques such as enterprise architecture, IT architecture or software architecture?

Modeling enterprise architecture

The enterprise architecture domain is very wide and our objective is not here to describe it extensively. We will just mention that this domain is mainly split in 2 concerns:

There are many enterprise architecture methodology frameworks, but the most used nowadays is TOGAF.

The most used enterprise architecture modeling language is Archimate (see our introductory article and our recommended recipes). This language is particularly adapted to model most of the other dimensions of interest of the military project, especially the organizations, strategy, processes and IT systems, whatever the complexity.

It proposes 13 basic viewpoints (see here) but its global metamodel makes it adapted for many complex representations.

Traditionally enterprise architecture is information systems oriented and aims at reintroducing the business common sense in IT. In order to tackle the strategic intentions of a company that wants to transform, process and IT transformation must be considered together as a system in order to avoid the 2 common traps:

Samples of those traps are numerous. For the first case, transformation projects led by process experts often lead to a huge loss of money because they create more Excel tools and often add layers of procedures to already overly complex environments. For the second case, a typical example is the "tool project approach": when users have a need, let's buy a tool and deploy it. Those two sample lead to the same result: inefficient, error prone and expensive processes, and inefficient, error prone and expensive IT systems. In one word: more recurring costs, less productivity and a future cost of change that increased.

Enterprise architecture, by its way of considering the processes and IT systems together enables to perform the proper tradeoffs in projects and to plan a real digital transformation, meaning a process and IT systems joint transformation targeting a better efficiency (cost reduction or productivity enhancement).

Various solutions for military projects

Considering the military requirements of table 1, let us dig into the various frameworks that enable to model military projects.

The best of breed solutions

If we look at the market and take the best of breed modeling solutions adapted to the requirements of table 1, we could propose the solutions presented in Table 2.

Table 2: Best of breed solutions for military programs

# Dimension Solution
1 Product definition SysML systems engineering modeling language
2 Product support and operations Archimate enterprise architecture modeling language
3 Digital transformation Archimate enterprise architecture modeling language
4 Project plan Complex planning tools for programs (set of projects with dependencies) + Archimate with the implementation and migration package

As we can see in the table 2, we have 3 ways of modeling the full program: SysML, Archimate and a planning tool.

The 3 metamodels not being integrated together, we may have problems at the "interfaces" of each domain (see later in the article).

SysML proposes 9 kinds of diagrams and Archimate 13 basic viewpoints, what corresponds to approximately 22 types of diagrams. If we had 2 or 3 viewpoints for planning, we would end up with a solution presenting around 25 viewpoints.

The military frameworks


The military frameworks, for decades, defined a set of artifacts and views to have it all covered.

The Figure 3 shows the structure of views of DoDAF version 2.

Figure 3: DoDAF viewpoint structure (52 viewpoints)

DoDAF viewpoint structure


The Figure 4 shows the structure of views of MoDAF.

Figure 4: MoDAF viewpoint structure (46 viewpoints)

MoDAF viewpoint structure


The Figure 5 shows the structure of views in NAF v4.

Figure 5: NAF viewpoint structure (46 viewpoints)

NAF viewpoint structure


An attempt of "unification" of those three frameworks was done by the OMG with the so-called Unified Architecture Framework (UAF).

The Figure 6 shows the structure of views in UAF v1.

Figure 6: UAF viewpoint structure (+70 viewpoints)

UAF viewpoint structure

Views and metamodel

All frameworks propose a metamodel that is often very rich, and also very complex. With time, the metamodels got more abstract which makes their use quite difficult.

Genericity, specialization and taxonomy

The core advantage - and the core problem - of those frameworks is that they are generic. With the same semantics (or almost), it is possible to describe a project for a new military aircraft, or a project for a new military device or a project for a new IT application.

The fact is that, in every of those projects, some notions can be called the same even if they don't cover the same reality.

Let us take the sample of "service" (which is very emblematic of those frameworks). Some of those framework describe it as being a "service in the broadest sense of the term".

An aircraft can provide a service, so is a military device, so is an application. For each of those "products", the notion of service will represent a different reality: the aircraft can provide a high level service to the army, the device a service to other devices and the IT application a service to a set of users. The connectivity between those services will depend on the context and on what we are talking about.

If we imagine a more complex project such as an aircraft, its ground segment and all support processes, it will be very complex to represent all those various objects and their interconnectivity with generic concepts.

To address this problem of "specialization" of very general concepts (or meta-concepts), the military frameworks propose the "taxonomy" approach. By defining for the various kind of views the appropriate taxonomy, the architects define the content of the views which removes the ambiguity.

In this spirit, each project will "instantiate" the military architecture framework according to its needs: the taxonomy of artifacts will clarify the meaning of abstract artifacts in the context of the project. This way of working is very common in military projects where a "guidance conference" at project start defines the various implementation options that are taken by the project.

This way of working can be quite easy in a simple project but can quickly become very complicated when the project is suppose to build several "products" of several kinds (which is the case in big military programs).

For instance, to be able to create meaningful and useful views in a new aircraft project containing the aircraft, the ground segment and the support system, complex and different conventions will have to be taken for each big "chunk" of the program. But, if we specialize each part of the program with a specific meaning of artifacts per program part, why not using domain-specific modeling languages such as presented in the "best of breed" part above?

Bridging several semantic domains together

The advantage of having an integrated framework is the bridges between various domains. In a best of breed solution, the bridging are almost impossible unless the modeling tool is unifying several modeling languages (see later in the article).

Bridges can be very important in the lifecycle of a program, because they can link the two parts of the V-model (as shown in figure 2). Samples are numerous and at the heart of many industrial projects:

When the modeling language and its metamodel enables to create those connections, the complexity of big programs can be described with many details [1].

A problem of semantics

The problem, as we saw it in figure 2, is that, under the military frameworks are "concrete" semantic domains underlying. We identified 4 semantic areas in table 1 and figure 1 and 2:

We can add that the target of military frameworks is to support a certain kind of projects that are belonging to a limited number of categories: full device, partial device and IT systems, more or less.

In those conditions, the advantages brought by the chosen framework must be balanced with its drawbacks. Among them we can name:

Syncretism or unification?

Evolutions and work-arounds

It is important to note that, with time, the military frameworks opened to some modeling standards, while keeping their own core metamodel, which does not appear as fully consistent.

Using Archimate for everything

For instance, NAF v4 indicates that Archimate and UAF can be used for modeling.

Clearly, Archimate can be used for product support and digital transformation (lines 2 and 3 of table 1) but it seems a bit light to model product definition (even with the physical package introduced in version 3). Concerning the project management Archimate has basic artifacts but that cannot enable the management of a complex program, in the way NAF or other military frameworks picture it. That means that Archimate can be used in NAF for certain kinds of projects, but cannot cover all that NAF intends to cover [2].

Figure 7 shows the classic use of Archimate which deliverables are processes and IT systems.

Using SysML for everything

Another option in the market is to consider that SysML can be used for everything. We propose to look at figure 7 a comparison between Archimate and SysML on an abstract RFLP process, declined respectively in a product definition process for SysML and on a set of processes and IT systems definition process for Archimate.

Figure 7: SysML and Archimate comparison

SysML and Archimate comparison

As we said earlier, the systems engineering area is introducing now more and more executable domain specific languages (DSL) to be able to simulate, optimize and perform early tradeoffs for system architecture. That is showing that SysML will never be the only systems engineering modeling language.

Second of all, if we compare to Archimate, we can see basically that the two modeling languages are not targeting the same problem. As we said in the best of breed solution, each project which scope encompasses a physical product plus processes and IT would definitely need both approaches.

Using UAF for everything

UAF on the other hand pretends to cover it all. Its metamodel being an extension of SySML, it seems well suited for product definition. As the meta-model integrates many more artifacts, the coverage seems one of the most extensive of the market.

The problem of NAF is, for us, the one we already described and that is attached to every military framework: in order to use it concretely, you have to instantiate it with the precise taxonomy of elements you will use. This is the way the military are doing things, but this way may not be adapted for every company.

Using a custom architecture framework for everything

Some companies are inventing their own modeling frameworks, quite often by sticking various semantically incompatible metamodels together, or by redefining from scratch a large set of artifacts in a brand new metamodel. In 25 years, we never saw this approach work: worse, we always saw this approach end badly.

The drawbacks of this approach are numerous:

This word is very important: helpful. The modeling framework aims to help architects to build better systems, not to glorify the ego of the gurus.

The path of creating a new framework with a new metamodel is very dangerous and always ends badly, so we do not recommend it at all. It is a waste of time, energy and brains.

That's why standardization groups were created: to put a lot of people with skills and large experience to define frameworks that work in many contexts and projects. You can look at our article on Archimate that explains why Archimate works.

One or many?

We have to say that we don't believe in unification, in the single modeling approach that covers any use case, in the "one size fits all" universal modeling language. That means we must use a syncretic approach: taking several modeling languages for what they do best.

The problem of interlinking models from different modeling languages remains. It can be solved by two approaches:

Figure 8: Sharing concepts between two modeling languages

Sharing concepts

The second approach is shown in figure 8. Doing the exercise of concept sharing between different modeling languages is very healthy, because it will define what we want to really pilot at the project level. As the modeling languages are domain specific, they will be used at specific moments of the project and so the interfaces between the various modeling activities can be formalized. With the help of the common semantic concepts and relationships, we can define quite easily a maturity process of exchanges between the various poles of expertise of the project during all the phases of its execution.


Using military frameworks for military contracts

When the military customer requires it, the use of those frameworks is mandatory.

Here are pieces of advice for a pertinent use of those frameworks:

In all cases, discuss, debate and negotiate in order to find the best compromise between the interests of the customer and the ones of the supplier. Big projects are successful when people share and work together on complexity.

Using military frameworks in the industry

Military frameworks are tuned to be used on the customer side: they rely on the hypothesis that the army is the customer and the industrial company (or companies) is (or are) the supplier(s). Table 1 explains the foundations of the military concerns. Military preoccupations are very concrete: features and performance, money, schedule, operational model.

Those concerns are not the ones of the supplier company, as shown in Figure 2 in the V-model. The supplier company would target an integration at other levels to be able to perform other tradeoffs than the military, who is often an important customer but not the only one.

All military frameworks, even UAF, are the result of the works and experience of the military organizations trying to manage projects of billions of dollars/euros. Those military frameworks are born from the military as a customer constraints. When the set of constraints is different, which is the case for the supplier company as an industrial company, the framework needed will not be the same.

The industrial world becoming more and more complex, many industrial companies are searching to define or reuse big modeling frameworks to ensure that every aspect of theirs problems is covered, and that they can do all the panels of their required tradeoffs. Currently, in the market, there seem to be no obvious integrated enterprise framework suiting the full range of their needs.

For the industry currently and unfortunately, syncretism of modeling languages seems the only solution.


[1] On the other hand, concerning the product lifecycle and specifically the links between engineering and support, some other industry-specific standards are covering the process aspect of such a challenge: the ASD standards - Back to text.

[2] See the first NAF to Archimate mapping in the online article of Mark Lankhorst - Back to text.

[3] Please see also the extensive works of Nicolas Figay on PLM interoperability and Archimate models interoperability - Back to text.

(November 2019)