Modaf Supports The Modeling Of Options

Published Date: 02 Nov 2017

The Ministry of Defense Architecture Framework (MODAF) defines a standard way to organize enterprise architectures for defense applications in the United Kingdom (UK). All major MOD weapons and information technology system procurements are required to document their enterprise architectures using the view products prescribed by the MODAF. MODAF is well suited to large systems and systems-of-systems (SoSs) with complex integration and interoperability issues. Although MODAF is primarily focused on defense applications, it can also be applied to commercial systems.

Guidance on MODAF

MODAF provides a coherent set of rules and templates, known as Views that, when populated, provide a graphical and textual visualization of the business area being investigated which would be developing both hardware and software for a phone running on android operating system. Each View offers a different perspective on the system to support different stakeholder interests. The Views are divided into seven categories:

Strategic Views (StVs) define the desired business outcome, and what capabilities are required to achieve. these kind of views will represent our main goal of the project which is developing a FullertonPhone system and defining the requirements that the customer desire.

Operational Views (OVs) define (in abstract rather than physical terms) the processes, information and entities needed to fulfil the capability requirements. those views will be used to define the processes required to apply the requirements of the customers.

Service Oriented Views (SOVs) describe the services, (i.e. units of work supplied by providers to consumers), required to support the processes described in the operational Views. Those views will be used by the customers to provide us with all the information required to produce work products.

Systems Views (SVs) describe the physical implementation of the Operational and Service Orientated Views and, thereby, define the solution. Those views will drive the implementation of the system

Acquisition Views (AcVs) describe the dependencies and timelines of the projects that will deliver the solution. Those views will be used to define the schedule that should be followed to fulfill the timeline of providing the system

Technical Views (TVs) define the standards that are to be applied to the solution. Those views will consider the standards that should be followed to develop the right work products and therefore providing the desired system

All Views (AVs) provide a description and glossary of the contents of the architecture

To ensure the coherence between the Views, MODAF is underpinned by a model which defines the relationship between all the data in all the Views. This model is called the MODAF Meta Model, also known as the "M3". The M3 also provides a technical standard to enable the exchange of data between architectures developed in different modeling (software) applications.

Specs of MODAF:

MODAF supports the application of rigour to requirements capture

The use of MODAF provides a de-facto element of rigour to requirements capture because the population of the Views requires the application of a structured analytical approach that leads the user from desired outcome to solution options.

MODAF supports the modeling of options

There are a number of commercially available tools that support the use of MODAF. As well as allowing the presentation of the Views, these tools also provide a repository in which the architecture can be stored and enable the modeling of different change options to support decision making.

MODAF supports interoperability

The use of MODAF as the standard architecture framework enables the coherent sharing of architectural information which helps identify gaps and overlaps between operating processes and the systems that support them.

MODAF has pedigree

MODAF was developed by MOD from the US Department of Defense Architecture Framework (DoDAF) version 1.0, but has been extended and modified to meet MOD requirements. MODAF is now itself internationally recognised as a best practice for enterprise architecting, and provided the template against which NATO Architecture Framework version 3.0 was developed.

MODAF has been adopted by organisations outside MOD

As well as MOD, MODAF is widely used by its industry partners, such as BAE Systems, Thales, Lockheed Martin, Boeing and Serco. It is also used by other government departments, such as GCHQ, and external bodies, such as the National Air Traffic Services. MODAF was recently adopted for use by the Swedish Armed Forces.

THE MODAF ARCHITECTING PROCESS

What is the MODAF Architecting Process?

The overall approach to developing a MODAF compliant architecture is broadly the same regardless of which MOD community is doing the work, or the MODAF views that are being generated. 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.

In reality, few, if any, teams within the MOD will simply follow the general six-step process outlined above from start to finish once only and then not utilise the architectures again. In practice there will be a wide variety of approaches to conducting architectural work that will involve various iterations and variations around this general process.

Step 1 – Establish Intended Use

It is essential that any architectural activities are conducted with a clear purpose in mind; the production of a suitable abstraction of complex real world situations that are amenable to detailed analysis. Therefore, step 1 of the architecture development process is aimed at determining and documenting the intended usage of the architecture which can subsequently be used to test whether the developed architecture is fit for purpose. It is often useful to elicit statements of intended use for the architecture through a workshop that includes all of the potential stakeholders who are expected to provide data to and / or utilise the resulting architecture.

Step 2 – Define Architecture Scope

The key outcome of this stage is a clear definition of the content and boundaries of the architecture that is to be developed. This will include a definition of the architectural scope in relation to many dimensions, examples of which may include:

• Process scope.

• Organisational scope.

• Systems / platforms scope – including those that have to be interfaced with.

• Geographic scope.

• Coverage of the Defense Lines of Development.

• Degree of granularity that is to be modeled (eg system, subsystem or component).

During this stage the team should also start to consider how the architectural information is likely to be presented so as to address the "exam questions" developed during Step 1. This would normally include a list of the key MODAF views that are expected to be produced.

In some cases modified MODAF views may be desirable in order to enhance the required analysis or presentation of results. For example, modified MODAF views may include the addition of overlays to enhance understanding. However, there is a risk that modified views my not be compatible with other tools / repositories. Therefore, advice should be sought through the SEIG to ensure maximum compatibility.

At this stage it is also important to inform the MODAF governance processes of the intended architectural activities. This will help ensure that architecture developers can be made aware of all extant architectural data sources before they commence work and can also be put in touch with other teams that may be developing architectures with similar or overlapping scopes. As repositories become more densely populated this will considerably ease the burden of developing architectures – whole elements could be cut-and-pasted from extant models.

Step 3 – Develop Data Requirements

Before commencing data gathering in order to populate the architecture, it is good practice to establish a data gathering plan. This should include the definition of what data is required, the level of granularity of data that is required, identification of multiple / redundant data sources to provide data validation and / or back-up sources. The data gathering plan should also consider data formats, pre-processing and data migration issues.

Over time, architectural repositories should become a valuable source of existing architectural data which could be re-utilised with little, if any, translation effort required. This is why it is important to inform the MODAF governance processes of the architecture’s intended scope; to enable a central register of all the MOD’s architectural activities to be built. Based upon this scope information, the repository team(s) can provide a summary of the available architectural data that may be of value to the new architecture.

An important consideration associated with the data gathering plan is conducting an assessment of the security aspects of the populated architecture. This needs to consider not only the classification of the individual data sources, but also the potential for a higher classification if certain combinations / aggregations of lower classification data are presented through the architecture. Consideration should also be made of the security implications for accessing the published architectural data and conducting the required analyses.

Tool Selection

This is probably also the most appropriate stage of the overall process in which to consider tool selection. MODAF does not require a particular tool / suite of tools to be implemented; definitive guidance as to tool availability and fit with different COIs is not available.

Architecting teams should, however, consider the following when selecting a tool / suite of tools:

• Does the tool enable modeling of the architecture at the right level (eg is it modeling at the business level or the technical level? Can it provide the right level of detail?)

• Does / can the tool support the MODAF Meta Model (M3)?

• Can architectural models created in the tool be easily shared with other tools or with the SEIG repository?

• Can the tool exploit existing architectural models?

Having made the tool selection it may be necessary to provide tool-specific training to those who are going to be deeply involved in capturing and editing the architectural models. It is expected that there will be a variety of tool-specific MODAF course available through tool vendors and their intermediaries.

Step 4 – Capture Architecture

It is during this stage of the process that the bulk of the architecture development actually takes place: importing and editing extant architectural models, capturing additional data and entering it into the architecture. This is likely to include extracting data from existing architectures via the SEIG or other repositories.

When building the architecture it is important that it is only constructed in accordance with the MODAF Meta Model and MODAF Taxonomy4. These constraints underpin the MODAF tool interoperability mechanisms and compliance with them ensures that the architecture will be compatible with the SEIG and other repositories and that others will be able to re-use the content in the future. Help on how to achieve this will be available through the CIO MODAF team, The Information Coherence Authority for Defence or the SEIG.

It is important that before the resulting architecture is baselined for publication and analysis its accuracy and validity is confirmed. This should include a review of the entire architecture by the subject matter experts who have provided key inputs. It may also be advisable to consult the MODAF governance processes / SEIG during the review process to ensure that any dependent architectures (eg with details of interfacing processes or systems) have not changed or are not in the process of changing.

At this point in the architecture development process the baseline (ie pre-analysis) architecture should be published to an appropriate repository in order to provide visibility to others across the MOD.

In order to facilitate the searching and query of architectures it is essential that the All Views (AV-1 with meta data regarding the architecture and AV-2 with the architecture’s object dictionary) are completed thoroughly for all architectures before they are published. It may even be appropriate to start the documentation of the AVs during an earlier stage and to refine them as the scope of the architecture evolves.

Step 5 – Conduct Analyses

Given the validated baseline architecture delivered through step 4 of the process, all of the required data should now be available to conduct the analyses that were identified during step 1. These analyses are likely to be COI-specific, and may include a variety of analytical techniques, including but not limited to:

• Static analysis, such as a gap / overlap analysis against the Strategic Views in order to identify capability issues.

• Dynamic analysis such as network traffic / bandwidth analysis based upon network configurations from SV-1 and traffic data from OV-2 / OV-3.

• Experimentation. Using information developed from the architectural analysis to establish the use cases / context for experimentation campaigns such as those run through NITEworks.

• Trials. Using architectures to provide use case / context information for exercises and trials at a variety of scales from battle labs to full brigade or division level exercises.

Step 6 – Document Results

Having conducted the required analyses, changes to the baseline architecture will often be identified. Examples might include:

• Capability analysis may have highlighted a serious capability gap which has been developed into an EP option. The capability, timing and other details of which should then be entered into the finalised architecture

• System interoperability analyses may identify interface problems that have to be rectified by means of changes to the applicable standards or introduction of gateway equipment, which need to be included in the finalised architecture

When the architecture has been updated with the relevant changes it should again be subjected to a further review and the resulting finalized architecture published to the appropriate repository.

What is the MODAF Meta-Model?

The MODAF Meta Model (M3) is the reference model that underpins MODAF. It, defines the structure of the underlying architectural information that is presented in the MODAF views. The goal is that MODAF tools are ‘model-driven’; ie, the views that are presented to the user are snapshots of underlying architectural data which is stored in the tool or in a repository.

Individually, views can only provide consistency in terms of the type of information produced; ie, it can be recognised that one view is a systems model, whilst another is a process model. However, the same information may be represented in more than one view, and there may be important relationships between the information in different views that should be captured. This consistency between views is provided by a reference model which identifies all the types of architectural elements represented across all the views, and the relationships between those concepts. The reference model (or Meta Model in the case of MODAF) therefore provides semantic rigour for the architectural framework.

Many of the benefits from using an architectural approach will ultimately come about from the ability to share, integrate, search and re-use architectural information across an enterprise. In order for the architectural information to be stored, managed and queried electronically, the reference model that underpins the views needs to support the sharing of architectural products between tools and the implementation of an architectural repository that stores those products and the metadata relating to those products.

Differences between (ADD) and MODAF

ADD ( Attribute-Driven design )

MODAF ( Ministry Of Defense Architecture Framework )

It’s a recursive method consists of 2 parts:

using tactics to achieve quality requirements:

make sure there is enough requirements information

decide which part of the system that will be decomposed

identify candidates architectural drivers

pick the design concept that will satisfy the architectural drivers been identifid

documenting decomposition:

instantiate architectural elements and assign responsibilities

define interfaces for the instantiated elements

verify requirements and define constraints for the instantiated elements

repeat all of the above steps for each element

MODAF consists of a set of rules and templates, known as Views that, when its established, it shows a graphical and textual visualization of the business being investigated. The Views are divided into 7 categories:

Strategic Views (StVs) define the desired business outcome expected, and what capabilities are required to achieve it

Operational Views (OVs) define the processes, information and entities needed to achieve the capability requirements

Service Oriented Views (SOVs) define the services, (i.e. units of work supplied by providers to consumers), required to support the processes described in the operational Views

Systems Views (SVs) define the implementation of the Operational and Service Orientated Views and, thereby, define the solution

Acquisition Views (AcVs) define the dependencies and timelines of the projects that will deliver the solution

Technical Views (TVs) define the standards to be applied to the solution