Use of MODAF

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. This general approach is shown in the following diagram, and summarised below.

In addition to showing the steps that a MODAF user should follow, the diagram also highlights the key interactions that are required with the MODAF governance processes. Amongst the MODAF governance mechanisms is the Architectural Repository that is run by the Integration Authority (IA). This (and potentially other repositories) can be used to run queries and extract existing architectural data – such as information on the systems that a new capability has to interface with. It is also important that all new architectures are lodged with the appropriate repository to inform others and allow the re-use of the most current architectural data. Furthermore, for the Acquisition community the IA also provides additional integration services that assist in modelling end-to-end performance and interoperability assurance.

Prerequisites

Before commencing a MODAF architecture it is important that the team concerned familiarise themselves with the MODAF architecture development approach, the available views and the expected nature of architectural activities associated with their COI. Although all of this information is available through the MODAF baseline documentation suite, it is recommended that the affected team attends an introductory course regarding the use of MODAF within their COI. At this point it is probably not appropriate to undertake training regarding the use of any particular MODAF architecture tools – as subsequent architectural scoping work may influence the team’s final tool selection.

Step 1 – Establish Intended Use

It is essential that any architectural activities are conducted with a clear purpose in mind – the main reason for developing architectures is 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.

Some examples of the “exam questions” that MODAF architectures might address for different COIs include:

More details of the COI specific usage of MODAF architectures is contained in the MODAF COI Deskbooks.

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:

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 – guidance for which can be found in the relevant MODAF COI deskbook(s).

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 IA 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 – much of 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 – so that a central register of all the MOD’s architectural activities can 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 / aggregation of lower classification data is presented through the architecture. Consideration should also be made of the security implications for accessing the published architectural data and conducting the required analyses.

This is probably also the most appropriate stage of the overall process in which to consider tool selection. Since the MODAF tool certification scheme is still being developed at the time of this MODAF baseline issue, definitive guidance as to tool availability and fit with different COIs is not currently available. Therefore, interim guidance exists on the availability of MODAF convergent tools . A further consideration in the tool selection process should be an analysis of the tool(s) used to develop the bulk of the available architectural data that is relevant to the new modelling effort. Although model interchange will be available between all MODAF certified tools, there will often be an advantage to edit models within the native format that they were developed in – which maintains the intended graphical layout and potentially additional architectural data that goes above and beyond the MODAF specification.

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 IA or associated tool-specific repositories.

When building the architecture it is important that it is only constructed in accordance with the MODAF Meta Model and MODAF Taxonomy. These constraints underpin the MODAF tool interoperability mechanisms and the IA’s repository, and compliance with them ensures that the architecture will be compatible with the IA repository 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 MODAF project or IA.

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 / IA 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 the 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:

As with the review of the baseline architecture, it would be good practice to conduct a review on the initial analyses and if necessary to revise the analyses before issuing the final product(s).

Step 6 – Document Results

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

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

Practical Applications of General Approach to MODAF Architectures

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 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.

Approaches to Iterative Development

There is no right way of conducting iterations around this general architecting process, but some practical examples are highlighted in this diagram.

The first common type of iteration (1) is where having generated the architecture there are periodic analysis / update cycles without any major refresh of the architecture itself. This approach may apply for example to the development and detailing of a number of capability options within Customer 1’s processes of finalising the Equipment Programme.

Another type of iteration (2) would be where the architecture is refreshed with more up to date data before the analysis is repeated. This approach may apply for example to the update of the Strategic Views each time the capability audit is conducted within Customer 1’s processes.

In some cases (3) it may be appropriate to periodically return right back to the start of the architecture processes to review the purpose, scope and data sources. A good example of where this may apply is within an acquisition IPT as it moves between CADMID/CADMIT stages – where there are different stage objectives, the solution boundaries may have changed and new data sources may be available. Of course these review activities of the early architectural activities can usually be conducted quite rapidly – possibly covering the review of steps 1 to 3 in a single workshop.

Sometimes, as the data is being gathered and entered into the architecture it may become apparent that it is not going to be possible to achieve the desired results using the elements being considered. In this case (4) it may be necessary to re-visit the architecture scope and / or data gathering plan in order to develop an architecture that will satisfy the original objectives.

Approaches to Rapid Architectural Update

In some cases the team will be working with an architecture that is largely pre-existing (eg from elsewhere within the IA repository) and against a well defined task and scope definition. In these cases it may be possible to abbreviate the process and conduct steps 1 to 3 in a single quick pass through the definition of desired outcomes, architectural scope and data sources as shown here.

It is still good practice to document the key deliverables of each of these architectural stages even if they are in a single document that has been captured during a single workshop.

It should be noted that similar iterative options could still exist with this rapid update approach.

Read-Only Architectural Usage

In some cases particular groups of MOD architecture users will not need to create architectures of their own but will be conducting analysis on the architectures produced by others. For instance, this may apply to the assurance and scrutiny communities who want to examine the adequacy and maturity of architectural activities conducted by IPTs at various stages of the acquisition lifecycle. In this case, a rather abbreviated version of the six-step process applies and there will be no update or publication of the architecture, as shown in this diagram.

It should be noted that similar iterative options could still exist with this rapid update approach.

Parallel Architectural Activities

Another common situation in the MOD will be where there are a number of parallel streams of architectural activities being conducted in relation to the same overall project. For example, within the Concept stage of the acquisition cycle there will be refinement activities on the URD being conducted largely using the OV suite of MODAF views while simultaneously a high level suite of SVs will be in the process of being developed for the purpose of optimising different system solutions. In some cases these parallel streams of architectural activity may be being conducted by quite separate teams. However, in most cases these various architectural streams will need to converge at certain points in the project when joint / cross-cutting analyses are required (see diagram below), such as an IPT conducting an overall risk assessment using elements from both the OVs and SVs to assess issues such as the clarity of use cases and the degree of interface definition.

Page version 1.1, dated 4th April 2007

Top of Page