Representing Information Exchange Requirements using the MOD Architecture Framework (MODAF)

Introduction:

There has always been some confusion about how the OV‐2 and OV‐5 views in MODAF should be used. These views form part of the Operational Viewpoint in MODAF. OV‐2 represents the logical structure of the enterprisei, and OV‐5 presents a very simple activity‐based representation of the behaviour of the enterprise. Together, these views provide a useful tool for specifying and analysing information exchanges. MODAF version 1.1 has sought to tighten‐up their usage, and their relationship to other views, however, consistent Enterprise Architecture is not guaranteed by the existence of a framework alone. There is also a need for a consistent approach in the use of the framework. The need for a methodology for MODAF has been debated in the past, and is still being debated. What is being suggested here is not a methodology as such, but just a clarification about how some of the key MODAF views are related.

Background:

There were some significant changes to MODAF with the release of version 1.1. At first sight they seem minor, but they were intended to clean up some of the inconsistencies in the framework and to ensure that architects were clear about how certain views were to be used. One of the reasons they seem minor is that the views retain the same codes (OV‐2, OV‐5, SV‐1, SV‐4, etc.). There was probably a strong case for renaming the Operational Views (OVs) and the System Views (SVs). The OVs aren’t necessarily operational in the military sense of the word, but are logical representations of required or existing capabilities in context of each other. Similarly, the SVs describe systems in the broadest sense – i.e. they include humans. The original names were kept in order to maintain consistency with MODAF v1.0 and DoDAF, but it is quite useful to think of the OVs as “Logical” and the SVs as “Physical”.

Previous to these changes in MODAF v1.1 some architects were interpreting the operational views to be business models and the systems views to be technical models. This was never the intent, nor wasit the original intent of DoDAF. This tighter adherence to logical and physical distinctions means that architects need to think clearly before deciding if their process model is an OV‐5 or an SV‐4 (even if it is a business process model – remember the SVs now model human factors). Similarly, it is no acceptable to just treat the OV‐2 nodes as platforms or organisations.