MODAF Final Paper PDF

Ministry of Defence
Architecture Framework
MODAF
By:
Jason Caruso
Tefe Jakova
Kristin (Kramer) Mills
Aaron Varrone
CIS 695 Enterprise Architecture
Dr. Richard McCarthy
Spring 2010
Quinnipiac University
Page 2 of 66
TABLE OF CONTENTS
Overview and Scope of MODAF .................... 3
History of MOD and MODAF ....................... 28
Strengths of MODAF ................................. 31
Weaknesses of MODAF ............................. 32
Comparison of MODAF to Other Frameworks 32
Compliance Issues ................................... 37
MODAF Users .......................................... 38
Upcoming MODAF Versions ....................... 44
Analysis of Enterprise Architecture ............. 44
References.............................................. 64
Page 3 of 66
OVERVIEW AND SCOPE OF MODAF

The Ministry of Defence Architecture Framework is built upon the MODAF
Meta Model (M3) (Ministry of Defence, 10 March 2009). The M3 provides the
overall structure for each of the seven MODAF viewpoints and describes
elements of an architecture and how they relate to one another (Ministry of
Defence, 10 March 2009. Information can be represented in more than one
viewpoint, where each shows a different perspective of the architecture
information. The MODAF Ontology defines a common set of definitions that
are used across the framework (Ministry of Defence, 3 February 2009).
MODAF provides a way of documenting an architecture. Unlike a framework
such as TOGAF, MODAF does not prescribe a process for building an
architecture.
MODAF FRAMEWORK
MODAF, which stands for the British Ministry of Defence Architectural
Framework, is an architectural framework which defines a standardized way
of conducting Enterprise Architecture. MODAF was originally developed by
the UK Ministry of Defence. MODAF is an internationally recognized
enterprise architecture framework developed by the MOD to support Defence
planning and change management activities. MODAF does this by enabling
the capture and presentation of information in a rigorous, coherent and
comprehensive way that aids the understanding of complex issues.
MODAF is used to provide a conclusive set of rules and templates, known as
Views that, when completed, provide a view of the business area being
investigated by providing various charts, graphs, and text. Each of the
different Views offers a separate viewpoint on the business to support
different stakeholder needs or areas of interest. The Views are divided into
seven categories (Ministry of Defence):
Strategic Views (StVs) are used to define the desired outcomes or

goals of the business and the capabilities needed to achieve these.
Operational Views (OVs) are used to describe the tasks and activities,
operational elements, and information exchanges required to conduct
business and operational activities
Service Oriented Views (SOVs) are used to describe the services, (i.e.
what is provided to the customer), required to support the tasks and
activities described in the Operational Views
Page 4 of 66
Systems Views (SVs) are used to describe what happens when the
Operational and Service Orientated Views are implemented and,
thereby, define the solution.
Acquisition Views (AcVs) are used to describe what is needed and how
long it will take for the projects that will deliver the solution.
Technical Views (TVs) contain standards, rules, and policy and

guidance that are applicable to aspects of the architecture.
All Views (AVs) are used to provide a summary of the contents of the
architecture and any related terms/characters/abbreviations used.
Strategic Viewpoint (StV)
The strategic viewpoint defines the overall vision of the organization in order
to support military operations and is broken down into six views. The
strategic views are focused primarily on capability management. A
capability is described by MODAF as a specification or classification of the
ability of the enterprise (Ministry of Defence, 24 November 2008).
Capabilities are stable over time, but the requirements of capabilities can
change. A requirement capability says that a certain capability must be
achieved within a time period (Ministry of Defence, 24 November 2008).
While there are six views in the strategic viewpoint, they are not all
required. An organization may only need to use a few of them. Since
military capabilities change over time, views typically refer to a particular
period in time. If a capability undergoes a significant change, it is necessary
to reassess the views.
The first is StV-1 (Enterprise Vision), which provides the overall strategy for
the framework. A capability vision shows what is required to meet the
organizations strategy. MODAF version 1.2 calls for a diagram to show an
organizations goals and capabilities. An example is shown below.
Page 5 of 66
(MODAF, 2008)
While the StV-1 view only describes high level goals, the StV-2 view is
referred to as the capability taxonomy and breaks down each capability into
a hierarchy. Each capability describes what is to be done, but does not
specify how something is to be completed. Capabilities are often broken
down into structured lists and an approach such as unified modeling
language (UML) may be used (MODAF, 2008).
StV-3 is the capability phasing view, which deals with the realization of
capability during different time periods. This view strives to look for
differences or overlapping areas of capability, by plotting projects and
support over time. The following diagram shows where capabilities are
missing over a period of two years.
Page 6 of 66
(Ministry of Defence, 24 November 2008)

StV-4 is the capability dependence view, and as its name suggests, it looks
for areas in which capabilities rely on one another. This can be represented
in UML diagrams or in box diagrams as shown below.
Page 7 of 66

StV-5 is called the Capability to Organization Deployment Mapping. It shows
how capability requirements should be filled. As in StV-3, it shows
dependencies, but is more detailed than that view. The information from
StV-5 comes from other views, specifically, AcV-2, StV-2, OV-4, and SV-1.
This view is typically shown in a table, with parts of the organization on one
side, and capabilities on the other side. There is typically a view for each
enterprise phase. StV-5 can also be shown on a timeline (Ministry of
Defence, 24 November 2008).
StV-6 is Operational Activity to Capability Function Mapping. This view
shows which capabilities support which particular operational activities. It is
generally represented in tabular form, with the capabilities on one axis and
the operational activities on the other axis. The operational activities shown
in the matrix are typically high level, and do not changed drastically over
time, therefore typically only one StV-6 table is necessary (Ministry of
Operational Viewpoint (OV)
The second viewpoint in the MODAF architecture is the Operational
Viewpoint. Operational Views describe the tasks and activities, operational
elements, and information exchanges required to conduct business and
operational activities (Ministry of Defence, 12 February 2009). The
Operational Views do not describe operations in respect to military actions,
but instead are logical representations of required or existing capabilities in
context to each other (IBailey, 2007). Basically, they represent what the
enterprise is, does, or is required to do, and who the players are in the
process. The players can be individual organizations, people, or systems.
There are 11 views that comprise the Operational Views Viewpoint.
OV-1a is the High-level Operational Concept Graphic which provides a
graphical view of what the architecture is about and an idea of the players
and operations involved. It can be a general map of the enterprise that is
used as an overview to present to upper-management. It generally depicts
the business processes or missions, high-level operations, organizations, and
the geographical distribution of assets. Again, it is very basic and not very
detailed. The following diagram is an example of what an OV-1a view may
look like.
Page 8 of 66
(Ministry of Defence, 12 February 2009)

OV-1b is the Operational Concept Description which basically verbally
summarizes and describes the graphics shown in OV-1a. It is a textual
description of the graphic. OV-1c is the Operational Performance Attributes
which provides detail of the operational performance attributes associated
with the scenario / use case represented in the High Level Operating
Concept Graphic (OV-1) and how these might evolve over time (Ministry of
Defence, 12 February 2009). The values expressed define the performance
of specific or multiple capability elements, and can be represented as either
single values or a range of values across a defined timescale (Ministry of
Defence, 12 February 2009).
OV-2 is the Operational Node Relationship Description which defines the
operational nodes and how they relate to each other or are connected. An
operational node is a logical element of the operational architecture that
may produce, consume, or process information, energy, material, or people
(Ministry of Defence, 12 February 2009). Nodes can be groups, bases of
operation, facilities, or even organization types. The main goal of OV-2 is to
give descriptions of the individual nodes relevant to the architecture and
show their collaboration needs. OV-2 can track communication between
nodes within and outside the architecture and even give specific locations of
the operational nodes. OV-2 views may also be used to depict nodes in a
Page 9 of 66
SOA models, using service elements instead of traditional needlines.

Needlines document the required or actual exchange of information between
nodes. OV-2 views can also combine service elements with traditional
needlines, helping to represent most common architectures that consist of
point-to-point connections as well as service interactions (Ministry of
Defence, 12 February 2009). Below is an example of an OV-2 with
traditional needlines and Service elements.
OV-3 is the Operational Information Exchange Matrix which provides more

detail on the information that is exchanged between various nodes in the
architecture. The Operational Information Exchange Matrix details
information exchanges by identifying which nodes exchange what
information, with whom, why the information is necessary, and the key
attributes of the associated information products (Ministry of Defence, 12
February 2009). OV-3 tracks critical information exchanges, as represented
in OV-2 by the needlines. They do not always match up one-to-one though
as many exchanges in OV-3 may occur across the same needline
represented in OV-2 (Ministry of Defence, 12 February 2009). In OV-3
information is typically captured in tabular form. Below is an example of an
OV-3 in table form:
Page 10 of 66

OV-4 is the Organizational Relationships Chart and it shows organizational
structures and interactions. A typical OV-4 chart illustrates the command
structure or relationships (as opposed to relationships with respect to a
business process flow) among human roles, organizations, or organization
types that are key players in the business represented by the architecture
(Ministry of Defence, 12 February 2009). OV-4 helps to clarify relationships
between organizations inside and outside of the architecture. MODAF does
not model individual people though, rather specific posts within the
enterprise. So OV-4 may show types of organizations and the typical
structure of those organizations, actual specific organizations, or it may
show a hybrid of both. Below is an example of the hybrid diagram.
Page 11 of 66
The OV-5 Operational Activity Model describes the operations that are
normally conducted in the course of achieving a mission or a business goal
(Ministry of Defence, 12 February 2009). OV-5 describes the different
business processes and workflows, and gives a clear definition of roles and
responsibilities. OV-5 is usually coupled with OV-2. OV-5 focuses on the
operational activities while OV-2 focuses on the operational nodes. OV-5
was created to describe military activites, but it is well suited to work with
non-military activities as well. It is used to describe the operations or
actions that are normally conducted in achieving a mission or a business
goal (Ministry of Defence, 12 February 2009).
OV-6 is really made up of 3 different views. OV-6a which is the Operational
Rules Model, specifies operational or business rules that are constraints on
the way that business is done in the Enterprise. OV-6b is the Operational
State Transition Description which is a graphical method of describing how
an operational node or activity responds to various events by changing its
state. Finally, OV-6c is the Operational Event-Trace Description, and it
provides a time ordered examination of the information exchanges between
participating operational nodes as a result of a particular scenario. The
three views describe the dynamic behavior and timing performance
characteristics of an architecture. Views OV 1-5 gives us knowledge of the
operational nodes, activities, and information exchanges (Ministry of
Defence, 12 February 2009). But OV-6a,b,c shows what happens when an
activity occurs in the architecture and how that architecture behaves. When
we send a message from node A to node B, it is important to know what
kind of response we will receive.
The OV-7 Information Model addresses the information perspective on an
operational architecture (Ministry of Defence, 12 February 2009). It
documents the business information requirements and structural business
process rules of the architecture (Ministry of Defence, 12 February 2009).
An OV-7 is very useful when different organizations use the same terms to
refer to completely different things.
Service Oriented Viewpoint (SOV)
The third viewpoint that differentiates MODAF from other frameworks is the
service oriented viewpoint. It identifies views that can be used in a service
oriented architecture and was derived from the NATO Architecture
Framework (Ministry of Defence, 27 November 2008). The service oriented
viewpoint consists of seven views.
The first view is SOV-1, which is Service Taxonomy. The NATO Architecture
Framework (NAF) equivalent is NSOV-1. The Service Taxonomy view
Page 12 of 66
provides governance for service oriented architecture by showing services in

a hierarchy (Ministry of Defence, 27 November 2008). Each level of service
in the hierarchy is a specific type of a service from another level. In addition
to governance, SOV-1 can be used for planning services, looking at gap
analysis relating to services, recognizing services, and auditing services
(Ministry of Defence, 27 November 2008). SOV-1 can be depicted using
charts, UML, or through shape drawings. The following diagram shows SOV1 relationships between services, service generalization, attributes of
services and service policy, which is optional.
The following UML diagram shows how a service hierarchy might be set up.
Page 13 of 66

SOV-2 is the Service Interface Specification view. As the name suggests,
this view shows what interfaces that a services uses. It also shows which
service can be used in conjunction with other services. The items used in
SOV-2 usually include services, service interfaces, interface operations
which show how a service is accessed, and interface parameters which
show what is either inputted or outputted from the service. This view is
typically represented using UML or in a table.
The third service oriented view is SOV-3, Capability to Service Mapping. It is
the equivalent to NAFs NCV-7 (Ministry of Defence, 27 November 2008).
This view details the services that support a capability. It is used for
governance as well as planning services. It can be represented in table form
or by UML and usually includes the specific service, the capability that
supports it, and the relationship between the two (Ministry of Defence, 27
November 2008). SOV-3 can be as simple as a matrix with capabilities on
one axis and services on the other, with a designation of where the two
intersect. Services can support multiple capabilities and a capability can be
supported by multiple services.
The fourth level of the service oriented viewpoint is broken down into SOV4a, SOV-4b, and SOV-4c. None of the three views have exact NAF
equivalents (Ministry of Defence, 27 November 2008). SOV-4a is the
Service Constraints view. Again, as its name suggests, this view shows any
constraints that apply to carrying out a service. This view can also be shown
as a table or in UML and can consist of a service and the service policy. It
can be used to specify services or in the governance of services (Ministry of
Page 14 of 66
SOV-4b is the Service State model. It shows the different possible states
that a service may have and is used in service specification (Ministry of
Defence, 27 November 2008). SOV-4b can be illustrated with UML or by
another modeling language. The objects represented by this view are only
the service and the service state machine. The last view on the fourth level
is SOV-4c, the Service Interaction Specification. This view shows the
interactions of services with outside elements, the sequence of these
elements and any dependencies between the interactions. It is usually
signified through a UML sequence diagram, with objects such as the
services, interfaces between services, lifelines, and the consumers (Ministry
of Defence, 27 November 2008). The following example shows a sequence
diagram.

The last view of the service oriented viewpoint is SOV-5, which is Service
Functionality. Unlike the last three views, it does have any equivalent in
NAF, NSOV-5 (Ministry of Defence, 27 November 2008). This view is used
to specify services and to define requirements. It can be documented using
UML or another type of diagram and typically includes a service and the
function of that service. Where SOV-1 and SOV-4 define the implementation
of a service, SOV-5 shows the functionality (Ministry of Defence, 27
November 2008).
Page 15 of 66
System Viewpoint (SV)

The System Views (SVs) are a set of views that describe the resources that
realize capability (Ministry of Defence, 12 February 2009). The SVs describe
resource functions and interactions between resources and can also provide
detailed system interface models (Ministry of Defence, 12 February 2009).
There are 16 views that comprise the System Viewpoint:
The first view is SV-1 Resource Interaction Specification and it addresses the
composition and interaction of resources (Ministry of Defence, 12 February
2009). SV-1 is the link to OV-2 by showing how resources are structured
and interact in order to realize the logical architecture specified in OV-2. SV1 depicts all interactions between resources that are of interest to the
architect. An interaction means that information is passed between two or
more resources. A single needline in OV-2 may translate into multiple
interactions (Ministry of Defence, 12 February 2009). In most cases it is
best to model SV-1 and SV-4 together, since they are shown to provide
complementary representations. Below is an example of SV-1 view.

The second view, SV-2 Systems Communications Description, is made up of
3 views intended for the representation of communications networks and
pathways that link communications systems, and provides details regarding
their configuration (Ministry of Defence, 12 February 2009). SV-2 is a
physical representation of the implementation of the information needlines
identified in OV-2. SV-2 can give geographic locations and layouts of
Page 16 of 66
network components like switches and routers. SV-2 focuses on the physical
characteristics of a link by specifying attributes. The goal of SV-2 is to show
how systems are connected, what interfaces each system exposes (ports),
the type of hardware interface used and the information transmitted across
the interface. SV-2 expands on SV-1 by giving more detail of the physical
characteristics of those interactions specified in SV-1 that are between
systems. The first SV-2 view, SV-2a System Port Specification, which
specifies the ports on a system and the protocols used by those ports when
communicating with other systems. SV-2a is used to fully describe the
interface protocols and hardware specifications of each port on a system.
SV-2a lists the names of the ports, the interface protocol used, and the
physical port specification. The second SV-2 view is SV-2b System to
System Port Connectivity Description, which specifies the communications
links between systems and may also list the protocol stacks used in
connections. SV-2 gives a precise specification of a connection between
systems. Lastly, the third SV-2 view is SV-2c System Connectivity Clusters,
which define how individual connections between systems are grouped into
logical connections between parent resources (Ministry of Defence, 12
February 2009). An example of the SV-2c is shown below.

The third view is the SV-3 Resources Interaction Matrix. SV-3 provides a
summary of the resource interactions that were specified in SV-1 in tabular
form. It helps speed up assessments of potential commonalities and
redundancies. MODAF does not have any guidelines on symbols that can be
used in the table, but if SV-3 is used, it is critical to include a key.
The fourth view is SV-4 Functionality Description which addresses human
and system functionality (Ministry of Defence, 12 February 2009). SV-4
Page 17 of 66
gives a description of the necessary data flows that are input (consumed) by
and output (produced) by each resource. It makes sure that inputs receive
the information that they are requesting and at the proper level of detail.
SV-4 is the behavioral counterpart to the SV-1 (in the same way that OV-5
is the behavioral counterpart to OV-2) (Ministry of Defence, 12 February
2009). A simple example of an SV-4 is shown below.

The fifth view is the SV-5 Function to Operational Activity / Service Function
Traceability Matrix. The SV-5 view depicts the mapping of functions (and
optionally, the resources that provide them) to operational activities or
service functions (Ministry of Defence, 12 February 2009). SV-5 shows the
linkage between functions described in SV-4 and Operational Activities
specified in OV-5. SV-5 also shows the linkage between functions described
in SV-4 and the Service Functions in SOV-5. SV-5 is typically shown in a
tabular form. SV-5 tablets can be very generic in scope or they can be very
detailed. Below is a simple example of an SV-5 view.
Page 18 of 66
The sixth view is the SV-6 Systems Data Exchange Matrix view. It specifies
the characteristics of the system data exchanged between systems with the
focus on data crossing the system boundary (Ministry of Defence, 12
February 2009). SV-6 is the physical equivalent of the logical OV-3 table
and provides detailed information on the system connections that implement
the information exchanges specified in an OV-3. If the information is nonautomated, it is captured in the SV-1 and SV-3 only. SV-6, like SV-5, uses a
tabular format to present the data. The focal point of SV-6 is on how the
system data exchange is affected, in system-specific details covering
periodicity, timeliness, throughput, size, information assurance, and security
characteristics of the exchange. Also represented in the table are the
system data elements, their format and media type, accuracy, units of
measurement, and system data standards. The seventh view is the SV-7
Resource Performance Parameters Matrix. SV-7 depicts the performance
characteristics of a Resource (ie. system, role or capability configuration). It
builds upon SV-6, and therefore should be developed in conjunction. SV-7
takes the information presented in SV-1 and expands upon it by depicting
the characteristics of the resources shown in SV-1 (Ministry of Defence, 12
February 2009). To help facilitate a mission or goal, SV-7 is used to
communicate which characteristics are considered most crucial. The format
used in SV-7 is also that of a table.
The eighth view is the SV-8 Capability Configuration Management view. SV8 presents a whole lifecycle view of a resource, describing how its
configuration changes over time (Ministry of Defence, 12 February 2009).
SV-8 s main function is to show change over time. Sv-8, when linked
together with other evolution views such as AcV-2, StV-3 and TV-2, provides
a rich definition of how the enterprise and its capabilities are expected to
evolve over time (Ministry of Defence, 12 February 2009). These types of
views are good for presenting a potential future snapshot to management.
The ninth view is the SV-9 Technology and Skills Forecast. This view defines
the underlying current and expected supporting technologies and skills
(Ministry of Defence, 12 February 2009). SV-9 will show future trends in
technology and skills that may directly impact the architecture. This view is
used to forecast future investments in technology that will be needed. Given
the future-oriented nature of this product, forecasts are typically made in
short, mid, and long-range timeframes (Ministry of Defence, 12 February
2009). An example of Sv-9 may show the forecast for an operating system
like Microsoft; where the newest version may be in the short-term and
future upgrades mid and long term forecasts.
The tenth view is SV-10 which is actually made up of three models. Each of
the three views may be used to describe the dynamic behavior and
Page 19 of 66
performance characteristics of the SV (Ministry of Defence, 12 February

2009). It is important to study the behavior of the architecture. We can use
the example that it is important to know whether a response is expected
when message x is sent to resource Y. The first of the SV-10 models is called
SV-10a Resource Constraints Specification. SV10a specifies functional and
non-functional constraints on the implementation aspects of the
architecture. SV-10a describes the rules that are set to control, constrain or
guide the implementation aspects of the architecture. MODAF categorizes
constraints as: structural assertions, action assertions, and derivations. The
second SV-10 model is SV-10b Resource State Transition Description. SV10b
represents the sets of events in which the resources in the architecture will
respond as a function of its current state. SV-10b shows the changes that
occur with the transition from one state to another. It can provide a quick
snap-shot and analysis of a rule set and be able to detect dead-ends or
missing conditions. This can help eliminate problems early on that if not
caught, can cause serious behavioral errors in fielded capabilities or
expensive correction efforts. The third model is the SV-10c Resource EventTrace Description. SV-10c provides a time-ordered examination of the
interactions between resources. SV-10c products are very helpful in making
sure all information is available when moving to the next level of detail from
the initial solution design, and to help define a sequence of functions and
system data interfaces. Typically SV-10c is used in conjunction with SV-10b
to describe the dynamic behavior of resources (Ministry of Defence, 12
February 2009).
The eleventh view is known as the SV-11 Physical Schema. SV-11 defines
the structure of the various kinds of system data that are utilized by the
systems in the architecture (Ministry of Defence, 12 February 2009). SV11
is an implementation-oriented data model that is used in the system
viewpoint to describe how the information requirements represented in OV-7
Information Model are actually implemented (Ministry of Defence, 12
February 2009). Below is an example of an SV-11.
Page 20 of 66
The final view in the SV grouping is the SV-12 Service Provision. SV-12
specifies configurations of resources that can deliver a service and the levels
of service those resources can deliver in different environments (Ministry of
Defence, 12 February 2009). SV-12 is related to the Service Oriented Views
(SOVs) in MODAF because the SV-12 shows how those SOVs affect the
architecture. SV-12 provides the mapping from services to the resources
that provide those services. The service attributes defined in SOV-1 can be
given values in SV-12 and can therefore relate to the environment under
which those values are true (Ministry of Defence, 12 February 2009). The
diagram below shows a UML representation of SV-12:
Page 21 of 66

Acquisition Viewpoint (AcV)
The acquisition viewpoint details how projects and capabilities are dependent
from one another across Defence Lines of Development (DLOD) (Ministry of
Defence, 21 November 2008). The goal of the acquisition views are to
show the fielding and acquisition processes. The viewpoint only consists of
two views, and since MODAF does not require that all views are used, it is
possible either only one or neither will be used (Ministry of Defence, 21
November 2008).
AcV-1 is the Acquisition Clusters version 2 view. This was originally called
the SoS Acquisition Clusters view in the original MODAF framework. AcV-1
shows dependencies between the organizations and their projects. This view
generally includes the project, the owner of the project, and the enterprise
phase. AcV-1 can be documented through diagrams or in a language such
as UML (Ministry of Defence, 21 November 2008).
Generally, AcV-1 is shown as a hierarchy of systems and acquisition
projects. The following diagram shows an example of AcV-1.
Page 22 of 66
(Ministry of Defence, 21 November, 2008)

AcV-2 is Programme (sic) Timelines v.1.2. This view was originally called
Acquisition Programmes in the first version of MODAF. AcV-2 is used for
project management, dependency management, portfolio management,
dependency management within a System of systems (SoS), and to identify
risks in project dependencies. This view can be shown in a Gantt chart,
which shows the timelines of various projects, dependencies between
projects, project milestones, and how different capabilities are put together
(Ministry of Defence, 21 November, 2008).
The bars in the Gantt chart in AcV-2 are usually shaded in with a color to
indicate its cycle in the CADMID (Concept Assessment Development
Manufacturing In-Service Disposal) cycle. CADMID is a procurement policy
specified by the Ministry of Defence. There are also icons which are color
coded, so that some will be colored in to indicate that there are no issues in
a project, where another color will signify that there are issues that need to
be attended to. An icon will indicate the maturity level in the DLOD (Ministry
of Defence, 21 November, 2008).
Page 23 of 66
Example of Icon in AcV-2:

Green indicates no outstanding issues and appropriate DLOD maturity
Yellow indicates some outstanding issues but resolution of these issues is
scheduled and appropriate DLOD maturity
White indicates that DLOD maturity is not known
Black indicates that the DLOD maturity is not required for this phase
Red indicates outstanding issues with no planned resolution; DLOD maturity
level is not at the appropriate level

Technical Standards Viewpoint (TV)
The Technical Standards Views (TVs) are tabular views containing standards,
rules, policy and guidance that are applicable to aspects of the architecture
(Ministry of Defence, 20 November 2008). The MODAF Technical Standards
Views are derived from the core DoDAF views so they can be more easily
used when presenting technical and non-technical standards. Therefore, the
information contained in the views, do not need to be technical, as the name
implies. The information can be applied to operational activities ( i.e.
doctrine, Standard Operating Procedures and Tactics, Techniques and
procedures) as well as systems (i.e. standards and protocols) (Ministry of
In the technical Standards Views there are two views. The first view is the
TV-1 Standards Profile which defines the technical and non-technical
standards, guidance and policy applicable to the architecture (Ministry of
Defence, 20 November 2008). Not only does TV-1 identify the applicable
technical standards, but it also may document the policies and standards
Page 24 of 66
that apply to the operational or business context (Ministry of Defence, 20

November 2008). TV-1 is basically a guide to the standards being used in
the architecture. It lists the standards and policies, and helps road-map
them based on time to account for emerging technologies and upgrades.
TV-1 should identify any existing guideline or standard, as well as point out
areas where the guidelines are lacking. The technical standards (which is
one type of TV-1) govern what hardware and software may be implemented
and on what systems. See the examples below.

If you include more than one emerging standard time-period in your
architecture, then you should complete a Standards forecast (TV-2) as well
as a TV-1. The standards cited are referenced as relationships to the
systems, system functions, system data, hardware/software items or
communication protocols in SV-1, SV-2, SV-4, SV-6, OV-7 and SV-11
products, where applicable. The protocols referred to interface and
communications descriptions (SV-2) are examples of standards and these
should also be included in TV-1 (Ministry of Defence, 20 November 2008).
Page 25 of 66
The second view in TV is TV-2 Standards Forecast which describes any

expected changes in technology-related standards and conventions, which
are documented in TV-1 (Ministry of Defence, 20 November 2008). Similar
to TV-1, TV-2 is used to represent and show future technology changes and
upgrades to standards over set amounts of time. The main purpose of TV-2
is to identify critical technology standards, how they change, and what
impact they will have in the future of the architecture. TV-2 is a compliment
to TV-1 and expands upon it when more than one emerging standard timeperiod is applicable to the architecture (Ministry of Defence, 20 November
2008). TV-2 delineates the standards that will potentially impact upon the
relevant system elements (from SV-1, SV-2, SV-4, SV-6 and OV-7) and
relates them to the time periods that are listed in SV-8 and SV-9 (Ministry of
Defence, 20 November 2008). See below for an example of TV-2.

All Views (AV)
The final viewpoint in the MODAF framework is the All Views (AV) viewpoint.
AVs provide an encompassing description of the architecture, its scope,
ownership, timeframe, and all of the other data that is required in order to
search and query architectural models effectively (Ministry of Defence, 19
Page 26 of 66
November 2008). One can also use it as a place to record any findings and
notes while constructing the architecture. AVs also contain a glossary of
terms used, to help others easily understand and translate in the future.
MODAF states that AV is critical whenever an architecture is created or
modified because it is where the records and notes are stored, so the
information is available for future access and modifications (Ministry of
Defence, 19 November 2008). The AV viewpoint is made up of two views.
The first view is AV-1 Overview and Summary Information view. AV-1, as
the name implies, is a summary of all the information related to the
architecture in an executive-level designed for quick reference and
comparison. AV-1 includes assumptions, constraints, and limitations that
may affect high-level decisions relating to an architecture-based work
program (Ministry of Defence, 19 November 2008). AV-1 also serves as the
planning guide for when the architecture is being built, and answers the
who, what, where, when, why and how of the plan. AV-1 is critical when
building a MODAF architecture because it keeps everything on plan and in
order, similar to blueprints for a house. AV-1 provides a summary of these
descriptions: Architecture Project Identification, Scope, Purpose and
Perspective, Context, Status, Tools and File Formats Used, Assumptions and
Constraints, and Data Completed (Ministry of Defence, 19 November 2008).
AV-1 may also include Findings and Costs. AV-1 can be a dynamic
document as the architecture is being built, however a final draft should be
completed once the architecture is finished to document the final product.
An example of AV-1 is shown below.
Page 27 of 66

The second AV view is AV-2 Integrated Dictionary. This is used as a place to
explain terms and abbreviations used in the building of the architecture. It
is closely tied to the MODAF Ontology which tries to ensure that the same
terms are used to refer to the same objects across the MOD. The MODAF
project requires a standard classification scheme in order to ensure a
common use of terminology for the appropriate architectural elements. An
architect should be in no doubt about what types of systems, organizations,
etc. are at his/her disposal to use (Bailey, 2006). The goal is to make sure
everyone is on the same page and that the same term does not refer to
many different objects. Any entry into the Integrated Dictionary should
contain the following:
The name used for this element in the architecture

Alternative names for this element- e.g., if the element is listed in the
MODAF Ontology, it may have multiple names
A brief description of the element.
A list of the views in which the element is used.
(Ministry of Defence, 19 November 2008):
Page 28 of 66
An example of an AV-2 entry is shown below:
HISTORY OF MINISTRY OF DEFENCE AND MODAF

The United Kingdoms Ministry of Defence is composed of five different
departments, four of which existed before they were included in the overall
structure of the Department of Defence (Ministry of Defence, N.D.). The
first is The Admirality which is a naval board that dates back to 1546
(Ministry of Defence, N.D.). Henry VIII created a Navy Board which handled
operational activities and policy. The Board existed along with the Board of
Admirality, which handled political affairs. The Navy Board was eventually
eliminated in 1832 and its operations were moved to the Board of Admirality
(Ministry of Defence, N.D.).
The second Department of State was the War Office, which was responsible
for the British Army (Ministry of Defence, N.D.). When the office began, it
did not have much spending power or political control. It was not until 1854
that the War Office took over entire financial and political control of the
Army, but the office was still not very efficient. The office was eventually
overhauled in 1904 (Ministry of Defence, N.D.). The Air Ministry was created
in 1918 and its first job was to direct the Royal Air Force, which had been
created by the unification of the Royal Flying Corps and the Royal Naval Air
Service (Ministry of Defence, N.D.). The final department was the
Procurement Executive, which started in 1971 and was the descendent of
the Ministry Supply, Ministry of Aviation, and Ministry of Technology
(Ministry of Defence, N.D.).
The Ministry of Defence first consisted of the Board of Admirality, the War
Office, and the Air Ministry which were all consolidated in 1964 (Ministry of
Page 29 of 66
Defence, N.D). In 1971, the Procurement Executive became part of the

MOD as well. Todays Ministry of Defence sets policy and provides political
control over the United Kingdoms military. The head of the MOD is the
Secretary of State for Defence, who is supported by three defence ministers:
the Minister of State for Armed Forces, Minister of State for Defence
Equipment and Support, Under-Secretary of State for Defence/Minister for
Veterans (Ministry of Defence, N.D.). The Defence Ministers report to
Parliament and they each have both a military and a civilian advisor.
MODAF
The Department of Defence introduced the first version of MODAF on August
31, 2005. MODAF 1.0 was based largely on the United States Department
of Defense Architecture Framework (DoDAF). It contained the operational
viewpoint, systems viewpoint, technical standards viewpoint, and the all
views, which exist in DoDAF (Ministry of Defence, 31 August 2005). MODAF
differed, however by introducing the strategic and acquisition viewpoints.
The framework was developed to meet the specific needs of the Ministry of
Defence. The original document details that each view is grouped into a
specific viewpoint, which covers a specific topic. A view can portray overall
information about an enterprise, detailed information about a specific
purpose, or information about how different areas of the enterprise are
connected (Ministry of Defence, 31 August 2005).
MODAF 1.0 goes on to state that while there is a single organization that is
portrayed, there are different views based on the role of the viewer (Ministry
of Defence, 31 August 2005). The goal of MODAF was to realize the
following benefits: to gain clearer analysis of business concerns, improved
quality assurance, lower overall investment costs, detail of more specific
requirements, improved efficiency, and greater integration of military
systems and processes (Ministry of Defence, 31 August 2005). The MODAF
1.0 viewpoints show detail from different perspectives. The views are
consistent and compatible with DoDAF, but go on to meet some of the
specialized requirements of the MOD. MODAF does not require that all views
be used, an organization may only need a few selected views from each
viewpoint to sufficient show the operations and processes within their
enterprise (Ministry of Defence, 31 August 2005). The following image
shows the six original viewpoints and their objects in MODAF 1.0.
Page 30 of 66
MODAF 1.0
(MODAF, 2005)
MODAF VERSION HISTORY
There have been several small revisions and one major revision to MODAF
since its introduction in 2005. Minor revisions usually involve changes to
architectural elements of a view, changes to the name of a view, or additions
or changes to the overall meta-model that do not dramatically change the
purpose of a particular view (Ministry of Defence, 18 May 2009). Major
revisions can involve the addition or removal of views or viewpoints, major
changes to the overall meta-model or the renaming of a viewpoint (Ministry
of Defence, 18 May 2009).
In April of 2007, Version 1.1.001 made some minor revisions to section OV2 and changed the title of the section from Operational Node Connectivity
Description to Operational Node Relationship Description. Version 1.1.002
changed the layout of the first page, changed the order of the menu on the
side, made a note about the delay in revising M3 (the MODAF Meta Model),
Page 31 of 66
and added a section for Configuration Control Policy. Revisions 1.1.003 and
1.1.004 revised the Navigation and allowed the user to print the document
without the navigation links (Ministry of Defence, 18 May 2009).
Version 1.2.000 was a major revision of MODAF and was released in June of
2008. It suggested some alternate names for some of the views, introduced
a new viewpoint: the Service Oriented Views, and allowed software and
artifacts as a resource type. This version also permitted the use of services
in some of the operational views, and added an interactive Frequently Asked
Questions section (Ministry of Defence, 18 May 2009). The new service
oriented viewpoint was largely based upon the NATO Architecture
Framework as discussed earlier in this report (Ministry of Defence, 27
November, 2008).
Revision 1.2.001 made some minor updates to M3, and some corresponding
view changes to SV-5 and SV-12. Revisions 1.2.002 and 1.2.003 made
some additional changes to M3. Revision 1.2.002 added software to SV-11
and added some requirements to SV-12, OV-1, and StV-1. Revision 1.2.003
added data and information elements to several views.
STRENGTHS OF MODAF
As mentioned earlier, MODAF is partially derived from the United States
Department of Defense Architecture Framework (DoDAF). MODAF includes
several components of DoDAF, including the operational viewpoint, systems
viewpoint, technical standards viewpoint, and the all views. The use of the
same views offers some compatibility between the two frameworks. MODAF
usually offers several options for representation in each view. For example,
an architect may elect to use a tabular representation or a specific modeling
tool such as UML.
MODAF is also advantageous to other defense frameworks because it offers
three additional viewpoints: the strategic, service oriented and acquisition
viewpoints. The strategic and acquisition views offer more in terms of
strategy and program management. They also show how capabilities are
shared and used in various operational activities. The service oriented view
supports the use of service oriented architecture (SOA). SOA is an approach
to integrating information technology services. The strategic, acquisition,
and service oriented viewpoints were discussed earlier in this document in
further detail.
Another strength of MODAF is that it is compliant and useful with the Unified
Modeling Language (UML). This allows MODAF to be more flexible and
useful with other architectures, like DoDAF. In March 2008, the UPDM
Group was re-formed by members of INCOSE and the OMG (Object
Page 32 of 66
Management Group) to create the Unified Profile for DoDAF and MODAF
(Hause, 2008).The group is working on ways to create a common
architecture language so that different architecture can be viewed together.
MODAF was one of the first architecture frameworks to work with UML.
WEAKNESSES OF MODAF
One of the main disadvantages of MODAF is its length. MODAF focuses on 7
different viewpoints, each of which has a number of different views. It
includes a great deal of material and requires a user to invest a considerable
amount of time to understand it. The framework itself specifies a number of
deliverables, some of which are required and others are optional. An
organization using MODAF would have to have a clear understanding of their
architecture before creating these deliverables. MODAF itself does not detail
a process for producing the required pieces of the framework, unlike a
framework such as TOGAF.
Before an enterprise can start to create viewpoints using MODAF, there are
several things they must sort out. First of all, the organization has to
understand the overall problem that they are attempting to solve. The
architects need to understand the overall strategy of the organization and
what they wish to ultimately achieve from the architecting process. It is also
critical that the process has stakeholders. Without stakeholders, the project
for creating an architecture is likely to fail, as there needs to be cooperation
throughout the enterprise, which can be facilitated by the stakeholders.
MODAF is not particularly flexible in that it is not easy to change the
structural representation of a view or viewpoint or an approach for a specific
view. Major changes need to go through an approval process. The MODAF
Steering Group must review and approve such changes (Ministry of Defence,
18 May 2009). Minor changes can either be reviewed and approved by the
Steering Group or by the MODAF Technical Group (Ministry of Defence, 18
May 2009). This can be challenging for organizations to do as they might
not necessarily fit the overall model of the Ministry of Defence. MODAF was
designed specifically to meet their needs and may not apply as well to
others.
COMPARISON OF MODAF TO OTHER FRAMEWORKS
DoDAF
As mentioned earlier, although MODAF is based upon the DoDAF framework,
MODAF is more based on MoD lifecycle processes, where views of the
Page 33 of 66
framework are incorporated and tailored more to MoD terminology as

oppose to DoD terminology (MODAF, 2009).
Both MODAF and DoDAF organize enterprise architecture into multiple
viewpoints, where both frameworks share an All Viewpoint (AV), Operational
Viewpoint (OV), Systems View (SV), and a Technical Standards View (TV).
However, MODAF also incorporates a Strategic Viewpoint (StV), defining the
overall vision of the organization; an Acquisition Viewpoint (AcV), which
describes how projects and capabilities are dependent from one another;
and an Services Oriented Viewpoint (SOV), which describes the services
required to support the processed described in the Operational Views. Below
is a representation showing the key differences between the two
frameworks.
Viewpoint
All Viewpoint
(AV)
Description
Extends all views by

providing context,
summary, or overviewlevel information
Operational
Shows what is going on
Viewpoint (OV)
in the real world that is
to be supported or
enabled by systems
represented in
architecture
Systems View
Describes existing and
(SV)
future systems
Technical
Lists standard
Standards View (commercial off-the(TV)
shelf, government offthe-shelf system parts
or components
Strategic
Overall vision of the
Viewpoint (StV) organization to support
military operations
Acquisition
Shows how projects and
Viewpoint (AcV) capabilities are
dependent on one
another across DLOD
Service Oriented Describes the services
Viewpoint (SOV) required to support the
processed in OV
MODAF
DODAF
Page 34 of 66
Another difference between MODAF and DoDAF is that the MODAF

metamodel is specified in an Unified Modeling Language (UML) 2.1, which is
used to diagram and model the objects of the system in an architecture (IRC
Software Glossary, 2009). MODAF also utilizes XMI 2.1 open standards for
data interoperability (MODAF, 2009).
DoDAF uses the Core Architecture Data Model (CADM), which is a formal
model of architecture products, structures, and their interrelationships. This
model provides a common database for repositories of architectural
information, which allows the ability to store data in a commonly shared
manner between other framework-based architectures (Minoli, 2008). Below
is an example of CADM.
(OS Join Task Force, 2006)

TOGAF
The Open Group Architecture Framework (TOGAF), which is developed and
published by the Open Group made freely available to anyone, was created
to provide access to integrated information, within and among enterprises,
based on open standards and global interoperability (Minoli, 2008). Similar
to the goals of MODAF, TOGAF helps organizations produce: well-integrated
solutions, clearly defines interfaces, reduces complexity, and better manages
Page 35 of 66
technology (Jones, Fatma, Blevins, & Siegers, 2007). Below is an example

of a TOGAF Model.
(Jones, Fatma, Blevins, & Siegers, 2007)

This relationship between the two frameworks can be seen as follows:
The All Views in MODAF largely aligns with the Preliminary Phase
and Phase A: Architecture Vision in TOGAF
The Operational View in MODAF largely aligns with Phase B:

Business Architecture and Phase C: Information System
Architecture activities in TOGAF
The System View in MODAF largely aligns with Phase C: Information

Systems Architecture, Phase D: Technology Architecture, Phase F:
Migration Planning, and Phase E: Opportunities and Solutions in
TOGAF.
Page 36 of 66
The Technical Standards View in MODAF largely aligns with Phase D:

Technology Architecture, and phase E: Opportunities and Solutions
in TOGAF.
The figure below shows an overview of the primary relationships between

the two frameworks.
TOGAF Phase
Focus
Applicable MODAF
Models
Preliminary
Framework & Principles
AV-1, OV-1
Vision
AV-1, OV-1
Business Architecture
AV-2, OV-1, OV-2, OV3, OV-4, OV-5, OV-6
Information Systems
Architecture: Data
Architecture
OV-7, SV-11
Information Systems
Architecture:
Applications
Architecture
SV-4, SV-5, SV-6, SV10
Technology Architecture
SV-1, SV-2, SV-3, SV-4

SV-5, SV-7, SV-10, TV1
Opportunities &
Solutions
SV-8, SV-9, TV-2
Migration Planning
SV-8
Implementation
Goverance
AV-1, OV-1
Change Management
SV-9, TV-2
(Jones, Fatma, Blevins, & Siegers, 2007)

This relevance between the two relationships show that the frameworks are
complimentary to each other and enable architects to use TOGAF to build
MODAF architectures which align to business requirements and services.
Additionally, both frameworks have a services-based history and reference
Page 37 of 66
models, and have the fundamental capability as mentioned before to create

Service Oriented Architecture.
In order for frameworks to be successful, they must conform to several key
required elements through the application of TOGAFs Development Method,
such as: repeatable methodology, standardized output models, governance,
collaboration, formal validation, collaboration guidelines, configuration
management, tools and patterns; which in the end can create a disciplined
process in developing MODAF set of views to model the architecture (Jones,
Fatma, Blevins, & Siegers, 2007).
COMPLIANCE ISSUES
There are no significant compliance issues in regards to MODAF. The MOD
has created 3 main phases to ensure that groups within MOD are compliant
when creating an architecture. The first phase is the development stage.
This is where all information is gathered, architects are consulted, the seven
views are completed, and pilot projects are rolled out. The second stage is
the roll-out phase where MODAF is delivered across the MOD. Typically this
can take up to 12 months and includes a lot of formal training. The third
phase is the maintain phase. This consists of a series of audits to determine
if groups are in compliance set forth by the MODAF. More training may
occur at this stage (Ministry of Defence, 2004). The approach to developing
a MODAF-compliant architecture is shown in the diagram below which shows
how a MODAF user within any community in the MOD goes about
establishing the intended use, as well as the scope and data requirements in
developing the architecture, and lastly use this to conduct the required
analyses by document the results.
Page 38 of 66
(Ministry of Defence, 2005)

MODAF USERS
One of the significant means of establishing a cost-effective integrated and
interoperable Defence capability is to build a comprehensive architectural
framework which can deliver information in a form that can be visualized by
addressing analytical and decision making processes (Lockheed Martin UK,
2010).
Lockheed Martin UK
Lockheed Martin is an aerospace, defense, security, and advanced worldwide technology company that uses MODAF guidelines and technical
standards for the Air Warfare Centre, which defines the Command and
Battlespace Management for in the Air environments. The company has
been integrating and continues to integrate key components across the
structured set of the architecture framework views including:
Page 39 of 66
Defence organizations and high level interoperability requirements

Defence activities and information exchange
People and appointments
Equipment platforms, sensors and weapon systems
Information systems, communication systems and data exchange
Operational roles conducted by people, organizations and equipment
Capability, user, and system requirements
Defences Capability Themes (Defence tasks, effects based tasks)
Lines of development
Concepts, doctrine, and procedures
Performance, time, and cost parameters
(Lockheed Martin UK, 2010)
The MODAF framework has helped Lockheed Martin deliver an integrated

capability to defence systems including: Requirements Capture and
Management (RC&M), and Interoperable Systems Management and
Requirements Transformation (iSMART). The figure below represents this
integration.

Some of the benefits gained from using MODAF at Lockheed Martin include:
Capability integration compared across organizational and capability

boundaries
Page 40 of 66
Conducting capability gap and overlap analysis

A structured approach allowing the Enterprise to be viewed from
capability interoperability perspectives
Identifies Defence capability needs
Clarifies roles, boundaries, and interfaces
A mechanism for military and industry to share the capability throughlife from vision through design to termination or disposal.
Defines performance across all views and architecture components
including organizations, operational activities, roles, and equipment
Analyzes interoperability issues
Develops and manages user and system requirements with owner and
stakeholder involvement.
DSTL
The Defence Science and Technology Laboratory (DSTL), which is an agency
of the UKs Ministry of Defence and its center of scientific excellence, houses
one of the largest groups of scientists and engineers in the UK. The mission
of DSTL is simple, which is to ensure that the UK Government and Armed
Forces have access to world-class scientific advice and from there can
deliver defensive research, specialist technical services, and the ability to
track global technological developments by establishing defensive policies
making and operations. In order to provide the best possible solutions to
the government, as well as bring exciting and innovative technologies to the
table; DSTL is required to build their architecture around MODAF (M2
Presswire, 2010).
BMT Hi-Q Sigma
BMT Hi-Q Sigma, a company which helps to deliver complex programmes
through the integration of programme management, and systems
engineering, uses a modern driven requirements approach by utilizing
MODAF (BMT Hi-Q Sigma, 2010). A recent example of this includes the
company being contracted in 2007 to produce a User Requirements
Document (URD) for the Apache Army Helicopter Mark 1 (AH). The intention
of this document was to produce a baseline capability and articulate what
was needed in order to meet the capability throughout its intend lifespan.
In order for the company to gather the future capability requirements, a
number of Operational Views from MODAF were produced, which allowed HiQ Sigma to scope the various aspects of the equipment required.
The following is a list of key benefits that MODAF provided to the company
for this particular project:
Page 41 of 66
A more complete URD

Consideration across all Lines of Development (LoDs)
Clear separation of effects required VS The level of effect to be
achieved
Identification of the current capability gaps
(BMT Hi-Q Sigma, 2007)
Suppliers of UKs Land Forces

Because demands in recent times have increased substantially for suppliers
of UKs Land Forces, the requirements have evolved significantly since
moving from historic theaters of operations in Europe and the UK. Todays
environment includes evolving fragmented solutions to specific needs, with
diverse logistic requirements. With this being said, a new approach for
these suppliers is required in order to provide a capability for wider
operational use that: supports theatres world-wide, minimizes user
overheads, is modular, scalable, and readily upgraded, accommodates
technology insertion and integration of Commercial-Off-The-Shelf (COTS)
elements, is interoperable with other UK and Allioes equipment, and lastly
fulfills the need of each Defence Line of Development (DLOD) (Davis &
Washington, 2009) .
MODAF has helped manage the complexity in implementing workable
solutions that fulfills the users requirements which can be delivered on time
and to budget. The framework has captured the many aspects, views, and
perspectives of the organization, its people, its processes, and the system
and data that support the organization as a whole. In addition, MODAF has
facilitated the planning of future procurements so that capability levels can
be enhanced or maintained in a way where the information required to make
planning decisions become simple and much easily understood (Davis &
Washington, 2009).
Results:
The Strategic Views for the new capability allowed terms from existing
policies to be presented and familiar with to both the military and
industry.
The Operational Views showed that taking an abstract at a high-level
view, successfully stripped away the unnecessary complexity that can
create confusion among the presentation of the core requirement.
Additionally, the support and maintenance requirements were also
modeled in the Operational Views, which is an aspect that is often
overlooked by most (Davis & Washington, 2009).
Page 42 of 66
The System and Technical Views were used to represent the user
requirements and sample configurations that satisfied the operational
requirements represented in the Operational Views. This showed the
potential deployments and which existing systems could be used as a
system-of-systems in order to provide the required information
management and communications (Davis & Washington, 2009).
The Acquisition Views were easily understood in Gantt-style diagrams that
gave an immediate indication of programmed interactions and potential
scheduling conflicts. For the new system, the platforms that were going
out of service were immediately identified so that their replacement could
be identified and informed of the new requirements. Additionally, some
platforms were able to be scheduled for the fitting of the legacy
equipment and eventually be considered as replacements and as the
correct fit for the system (Davis & Washington, 2009).
In the end, the complete set of the six MODAF views were selected:
All Views (AV-1 & AV-2)

Strategic Views (StV-1, 4 & 6)
Operational Views OV-1a, 1b, 2, 3, 4, 5, 6a, 6b)
System Views (SV-1, 3, 4[7], 5, 6, 7, 9, 10a, 10b
Technical View (TV-1)
Acquisition View (AcV-2)
(Davis & Washington, 2009)
Below is an example of the organizations MODAF Operational View

(OV-1a)
Page 43 of 66

This project has demonstrated that the Model-Based Systems Engineering
(MBSE) approach using MODAF has:
Enhanced communications across multiple teams

Provide a basis to manage critical risks and resolve issues
(including those associated with emergent behavior, budget and
resources) as they arise. As each user need is traceable to a
stakeholder, any future issues can be resolved by consultation with
the owners of the relevant requirements
Enabled effective management of the interfaces (including strategic
reallocation of capability)
Ensured consistency from the initial phases of system definition
whilst supporting change impact analysis and technology insertion
Page 44 of 66
UPCOMING MODAF VERSIONS

Going on forward, the MoD expects to keep changes to a minimum;
however, there is some alignment work going on which may affect MODAF:
1. The Object Management Group (OMG) Unified Profile for DoDAF and
MODAF (UPDM) version 2 enthusiastically supported by MOD, as it

provides the MoD with assurance that UML/SysML architecture software tools
that use UPDM have implemented a correct representation of the MODAF
Meta Model.
2. The International Defence Enterprise Architecture Specification (IDEAS)
a five nation (United States, United Kingdom, Canada, Australia and
Sweden) group that is driving forward coherence and convergence of
national frameworks, to improve our capability to share architecture
information.
3. The NATO Architecture Framework version 3 fundamentally based on
MODAF version 1.1, but has recently been updated so that the NAF Meta
Model is fully aligned with the MODAF Meta Model version 1.2.
(Gorman, 2010)
ANALYSIS OF ENTERPRISE ARCHITECTURE
As we known Enterprise Architecture (EA) models are able to support
hundreds of applications used from the organization. It is very important to
analyze the EA based on the following techniques:
Dependency analysis in this type of analysis, the enterprise architectures
artifacts are analyzed to find the direct or indirect relationships between
them. The reports could be presented using cross reference reports or visual
dependency graphs. Some of the questions answered from this analysis are
such as which business processes could be affected from a server change or
finding the list of applications that could make the life-cycle of products
easier (Bucher, Fischer, Kurpjuweit, & Winter).
Coverage analysis this type of analysis covers more than two EA layers. A
two dimensional matrices is used to present the analysis. The checked cells
in the matrix could indicate the applications used in each of the platforms
and how the products and applications are connected through business
processes. Using this coverage analysis, we could discover gaps and
redundancies (Bucher, Fischer, Kurpjuweit, & Winter).
Interface analysis - studies the interfaces within enterprise architecture
artifact classes. As an example to represent interface analysis, we could use
the analysis of technical interfaces of components in software architecture.
Page 45 of 66
The main purpose of this analysis is to study the artifacts, minimize their
coupling, and maximize the cohesion between them. Interface analysis is
also used for the organizational and strategy layer, and also the study of
homogeneity of the structure and artifacts (Bucher, Fischer, Kurpjuweit, &
Winter).
Heterogeneity analysiss- purpose is to locate the elements which could
increase efficiency of architecture homogeneity. Homogeneous structures
have low costs for maintenance, software, hardware and that all issues are
treated the same (Bucher, Fischer, Kurpjuweit, & Winter).
Complexity analysis and interface analysis go together- Its goal is to lower
the enterprise architecture complexity by studying the complexity measure
and dependency between the components. Compliance frameworks,
regulations by law, and market standards have gained tremendous
importance during the last couple of years (e.g., Solvency II, Basel II and
the Sarbanes Oxley Act) (Bucher, Fischer, Kurpjuweit, & Winter).
Compliance analysis- is analyzed if some policies such as process and data
ownership are correctly identified in the organizational level of abstraction
and if authorization and recovery mechanisms are successfully implemented
(Bucher, Fischer, Kurpjuweit, & Winter).
Cost analysis- calculates costs of enterprise architecture artifacts such as
new implementations or sales. It is very important to know IT costs and how
to distribute them to products, services, processes and other layers (Bucher,
Fischer, Kurpjuweit, & Winter).
Benefit analysis- calculates the contribution of different parts of the
companys units, systems or products to the whole organization. Every
organization has set goals and balanced scorecards, which are good
indications of how they perform (Bucher, Fischer, Kurpjuweit, & Winter).
The whole purpose of a system architecture is the link and collaboration
between its components; and that it works by using interaction protocols
among the components (Bucher, Fischer, Kurpjuweit, & Winter). The
interaction between the protocols should be error free, so there wont be any
deadlocks, logical inconsistencies or not controlled interactions. Another way
to control that all interactions go according the plan is by using Architecture
Description Language (ADL)
Model checking techniques are very important since the enterprise
architectures are widely distributed in organizations, and often too many
processes are running at the same time, interacting with each other but with
no standardized techniques to be analyzed. As a result of no coordination;
Page 46 of 66
they often could spend value time and resources (Bucher, Fischer,
Kurpjuweit, & Winter).
The Architecture Description Language provides well defined and distinct
syntax for processes, components, ports, interfaces, channels, and protocols
of interaction (Sircar & Kott, 2000). ADL is similar to other programming
languages that run code to check the system characteristics. This system
analysis tool can give important feedback on enterprise control. The strong
capabilities of the tool are to be able to eliminate errors in designs during
different situations such as when multiple components are interacting with
each other.
The figure below represents the ADL method:
(Sircar & Kott, 2000)

If inefficiencies are found, it is important to find a fix, and when doing
analysis to compare different architectural models, it would be wise to
choose the best one by weighting advantages and disadvantages.
In order for an organization to have all departments work in symphony with
each other, it is not possible just to make local changes, however changes
need to be made to the organization as a whole instead. Then integrate all
the components together by utilizing description techniques and the analysis
techniques of the architectural models. Often changes are needed to be done
Page 47 of 66
to the architecture framework model, and in this case to do a model-based

analysis. As a result, different methods of analysis need to be utilized to let
users such as architects and stakeholders choose the best option by
weighting advantages and disadvantages (Sircar & Kott, 2000).
Analysis Techniques
As mentioned above, stakeholders and architects need to weigh the
advantages and disadvantages of the outcomes in order to put best results
into work. They need to analyze quality, expenditures, timeframe, short
term and long term outcomes, performance, and more importantly the effect
that the different available alternatives could have on the existing
architecture setup. Since enterprise architecture is very complex, a very
detailed examination is needed by using very complex algorithms.
Below represents the analysis dimensions:
Quantitative
Analytical
Analysis
dimensions
Simlulation
Functional
(Lankhorst, 2005)
The analysis of architecture has to be done looking from different
perspectives. The first step is by comparing inputs and outputs; i.e.
functional versus quantitative (Lankhorst, 2005).
By performing the Functional Analysis, the architecture is looked upon from
the inside. This way data is generated on how a system conforms to the
particular architecture functions and what would be the causes of an
architecture change, and finally to check if the architecture is working or
being followed step by step. When a functional analysis is performed,
answers are not received to the questions on how fast will it be done or
Page 48 of 66
how much it will cost. These questions get a response when a quantitative
analysis is done, although it is very difficult to answer those kinds of
questions from an architectural model since the quantitative analysis of the
framework doesnt offer an option to regulate and correlate quantitative
results taken from the present detailed analysis methods.
The Functional and the Quantitative Analysis utilizes two different techniques
as well: the analytical and simulation technique. The simulation would show
the results of a models execution. The simulation is divided into Functional
and Animated simulation which looks at the performance and actions of the
system and as a result, helps the architects look and find ways to adapt the
changes, and also helps the stakeholders to have better knowledge on the
architecture. When running the functional simulation, architects and
stakeholders could be faced with interpretation problems; which could be
caused from the situations created from architecture abstraction.
Formal and Analytical analysis methods defer from the Simulation by
providing distinctive and reproducible results. By running the Analytical
techniques, architects and stakeholders can achieve better results than the
quantitative simulation during the quantitative analysis, which helps the
architects detect the bottlenecks of the framework, its performance, and also
helps to make better decisions if many options are available during the what
if analysis. When utilizing the analysis techniques, it will also answer the
question if the existing techniques should be used or if it will be necessary
create new ones. If architects choose to create new techniques, there will be
two available options: buy it or build it? From the Buy it question, offspring
two other questions: Which available technique should be chosen?, and
How to apply it?, and from the other perspective from the Build it
question, two more questions will be asked: How will the development be
implemented? and For which of the issues will the technique be built for?
(Lankhorst, 2005).
Quantitative Analysis
The enterprise architectures concern is to have a detailed description of how
all the important fundamentals of the enterprise operate together, such as
business products, processes, and software applications. From the
quantitative point of view, these fundamentals are related to each other in
multiple ways. Often, there is a misunderstanding that quantitative analysis
would get too complicated and give high level details when ran on the
architectural level. In the other side, performance engineers think that
quantitative (non-functional) aspects are equally important as functional
aspects to all stages of the system design and enterprise architectures, and
not just as a back-up idea. In enterprise architecture modeling, the
Page 49 of 66
quantitative sides are put on a global level, where the weight falls on the
structure which in enterprise architectures is used as a mechanism to
regulate the quantitative properties of organizations and their systems
(Lankhorst, 2005). When doing a quantitative analysis, there are several
issues to look at:
1. Quantitative analysis is used as an optimization tool for systems or
different processes by having a definite answer in case different design
alternatives are available.
2. Quantitative analysis could be used as a tool that could help architects
take the right measures in order to be able to prevent negative effects
of changes.
3. The last type of issue that quantitative analysis studies is capacity

planning. Capacity planning would analyze the available resources and
tell how many people would be needed to fulfill a process on time, or
would the present infrastructure be able to handle the actual processes
or if changes to storage, network capacity should be made?
The models that organizations could utilize could be represented in different
ways:
Performance measure This represents the timeframe that measures,
such as throughputs or resource exploitation,
Reliability This measure the ease of use and reliability.
Cost measures Which measures the cost of implementing.
(Lankhorst, 2005).
Quantitative Analysis - Performance Views
In order to structure a framework, there are different options available.
Architects could be dealing with different concerns, and as a result there are
different views available with each having different performance
characteristics:
User/customer view In this case the stakeholders are: customers, or
just a simple user of the application or system. The response time is
the time it takes for a request to be completed.
Process view In this case the stakeholders are: process owners and
operational managers. The process view represents the time it is
required for a step of the process to be completed. For example: if a
Page 50 of 66
customer has multiple requests this represents the time that it takes
for a request to be completed; or in the case of an information system,
the time it takes to finish a batch of a process.
Product view - In this case the stakeholders are: product managers
and operational managers. Processing time represents the time it
takes to complete a product, excluding the wait, or delay time. In a
computer system it is represented by the time when the CPU is busy.
System view - In this case the stakeholders are: owner and managers.
Throughput is represented by the number of requests that are
completed by the system in a time unit. For example: the number of
scanned pages in an hour. In system view, the term processing
capacity represents the maximum attainable throughput depending on
the number of available resources and their capacity.
Resource view - In this case the stakeholders are: resource managers
or capacity planners. The representation of time in percentage
calculated by using the time the resource is busy compared to total
operation time is known as Utilization. Utilization is a great tool that
shows the effectiveness in time of resources. By analyzing the time of
the resource it takes to be completed, bottlenecks could be found as
well. In an information system architecture, the network load time is
represented as utilization (Lankhorst, 2005).
Sometimes performance measures of different views could be interrelated,
and sometimes can be in conflict with each other when trying to increase the
performance of the belonging system. For instance, an example of high
throughput which as a result could lead to higher resource utilization. This
situation could be helpful to a manager because it increases the response
time, but it is not good for a users time. As a result, system performance
optimization is a very important and key issue (Lankhorst, 2005).
Quantitative Analysis - Performance Analysis Techniques for
Architectures
Although many applications are used to create models of enterprise
architectures, many of them, if not most of them do not analyze
architectures from the quantitate point of view. Multiple performance
analysis techniques have been planned for computing, manufacturing, and
telecommunication systems; and are therefore very efficient with a relatively
highly accurate estimate. Quantitative analysis can be used on all aspects of
enterprise architecture, beginning from the technical infrastructure layer, to
software applications, ending with the business processes supported by
these applications (Lankhorst, 2005). Additionally, enterprise architecture
Page 51 of 66
layers should be related to each other, and this happens also from the
quantitative side. For example, lower layers influence the higher layers and
higher layers influence the lower layers.
Infrastructure layer infrastructure domain is strongly affected from
the performance evaluation of computer and communication systems. The
hardware specifications in a system are described from the queuing models;
in the meanwhile the applications workload are controlled from the abstract
stochastic arrival process (Lankhorst, 2005).
Application layer the discipline of performance engineering of
software applications are considered at a global level, from which the
analysis of performance characteristics of some architectural styles and also
the performance issues are based from the SAAM method, which is a fivestep method analyzing software for architectures. Architecture description
language (ADL) suggests the queuing of models from software architecture.
Compositionality, which is another important architecture issue, describes
that the performance of a system could be expressed as the sum of the
performance of each of its components. Stochastic extension of process
algebras could be used for the compositional performance analysis, but they
are very computationally intensive. Process-algebra-based approaches allow
compositional specifications of performance models, but the analysis results
are not always compositional (Lankhorst, 2005).
Business layer there are many business and general process
modeling tools, such as Arena and ExSpect, that are used for quantitative
analysis using discrete-event simulation. The simulation is very helpful to
interpret the data, but if it is inserted at a very detailed level, it might be
very difficult to read for inexperienced users. Different companies offer
different analytical methods that help with completion times and critical path
analysis of processes, simulation based performance analysis, and very
complicated computational analytical solutions (Lankhorst, 2005).
Quantitative Analysis - Quantitative Modelling
ArchiMate language is a tool used for quantitative modeling of serviceoriented enterprise architectures. As mentioned above, the performance
views are the same for any modeling language, and as a result can be
converted to the ArchiMate language. ArchiMate uses the following
quantification prospects: triggering, access, realization, and used by.
Triggering relations are easily proven and very important in determining the
behavior of dynamic systems. Some quantitative methods that work for
business process-oriented modeling formalism cannot be applied to
ArchiMate because of two reasons:
Page 52 of 66
1. Some methods are only applied locally to partial architectures.

2. Behavior elements and resources are concerned, and do not cross the
borders of specific architecture domains.
(Lankhorst, 2005).
In the horizontal method, the resources work is at the top two layers of an
architecture model. In the vertical method, the methods work across
multiple architectural domains, using the used by and realization relations.
Even though the horizontal and vertical methods work differently, they could
be combined together just fine. For instance, an analysis can be done
through the layers using the propagation of quantities. For example, it could
used the case of workload measures (arrival frequencies) that are requested
as a demand from the users, in which could be customers located at the
higher levels. The quantities are dispersed through the layers transforming
into demand for each model element. When the demand has been
determined, the workloads will require some steps to be completed from the
resources. The effort is a in a relationship with performance measures
and/or costs. It all starts at the infrastructure and spreads to all the higher
layers. The approach is built in two phases: the workload phase started from
the users and the performance measures which are calculated from the
inputs (Lankhorst, 2005).
Below represents the layers of ArchiMate models:
(Lankhorst, 2005)
Reliable input data is the most important step of quantitative analysis. The
data can be retrieved from different sources. In an already existent system,
measurement could be very accurate, but retrieving the data correctly is
fundamental. It is not always clear on what needs to be measured, what
Page 53 of 66
must have a defined number or number of measurements, and last but not
least whether the measurements should be retrieved from different
situations so that there is a variety of data. What needs to be noted is that
while the system or organization still has work in progress, measurements
shouldnt be taken. For instance, if data is needed it should be retrieved
from the specifications of the components that are used or from another way
which is to get the data from similar architectures (Lankhorst, 2005).
Quantitative Analysis - Quantitative Analysis Technique
The quantitative analysis technique is composed of three steps:
1. Model normalization
2. Top-down workload calculation
3. Bottom-up performance calculation
By using different formulas during these three steps, it would be easier to
study the effects of input parameter on performance (Lankhorst, 2005).
Functional Analysis
Existing techniques in formal methods could be used for functional analysis.
The formal methods are mathematically precise because they use different
systems and are tested in various situations. The following aspects: static,
structural and dynamic, or behavioral are distinguished in functional analysis
of frameworks. The signature is the basis when trying to analyze the static
structure of architecture. The symbolic representation of the structural
elements and their relationships abstract from other architecture aspects
such as rationale, visualization and pragmatics. The most important feature
is the separation of concerns which help in the improvement of the
complexity of the architecture. The signature could be built in XML for a
variety of reasons, such as storage and communication, and at the same
time could be used as an independent piece, such as graphics for
visualization. The formal semantics of a symbolic model in a given
architecture could be described from a signature, but when interpreting it,
the details are quite obvious. A signature can have a large number of
interpretations because of the various available architectures that give
different meanings to the signature (Lankhorst, 2005). The techniques used
for static and dynamic analysis that will be described later on; will give a
better idea on how enterprise architectures should be interpreted on an
individual concept and by various relationships. These techniques are very
helpful for enterprise architects as it checks the correctness of their
architecture, increases clearness, and widens the architecture descriptions
with important information.
Page 54 of 66
Functional Analysis Static Analysis

Description logics are important formalisms when related to structural
analysis of architectures. They are part of knowledge representation
languages built to give information about concepts and concept hierarchies.
They provide a logical basis to:
1.
2.
3.
4.
5.
6.
Frame-based systems,
Semantic networks,
KL-ONE languages,
Object-oriented representation,
Semantic data models,
Type systems.
(Lankhorst, 2005)
Description logic systems could be used to build different applications such

as conceptual modeling, view maintenance, software management systems,
query mechanisms, information integration, planning systems, configuration
systems, and a natural language of understanding. In architecture systems,
the main reason of why description logics are used is to study the effects of
the architecture change by answering the question of which parts of the
system will be affected from the change (Lankhorst, 2005).
As an example to analyze, a case of an insurance company which sells
insurance to customers could be used. The company sells its products by
the help of intermediaries, whom talk to the customers trying to understand
their concerns, negotiate the policy contract, create the contract and do all
the communication with the insurance company. The figure below shows a
description of the company.
Below represents the fictional ArchiInsurance company:
Page 55 of 66
(Lankhorst, 2005)
The intermediary has just a commercial interest. They sell the product to
customers and makes sure that the paperwork is filled in a correct way, until
the customers agrees by signing the contract. After this point, the
intermediary works with the customer or insurance company in case of
premium issues. For the insurance company, it would be helpful to eliminate
the intermediaries, but before doing that, the architects need to investigate
quickly and precisely on what the impact of this kind of change will be on the
company. As a start, it is required to analyze the relationships between the
different views and logical theory. The basis is a single architecture model,
which is connected to a signature used in the logical analysis. In the
signature there are roles such as collaborations, and there are domain
dependent types such as an insurance company and its customers. When
doing the structural analysis, architects need to study every single available
relationship that could be in the architectural design, and make sure if the
change will affect any of the relations. For example, if a service provided by
an application changes, all the users that need to use that specific service
will be affected (Lankhorst, 2005).
As mentioned above, every relationship in the architecture model is
represented by a relation in the logic. The translation includes constraints
between the sorts and the relations, in order to make the correspondence
precise. For example:
x: Customer(x) -> Role(x)
xy: Participate(x,y) -> Role(x) /\ Collaboration(y)
Page 56 of 66
(Lankhorst, 2005)
The first relation shows that every Customer could be a Role; in the second
case the each Role can be part of Collaborations, and that Collaborations
could be Roles. This is just a simple example that shows the rules that are
written, which shows the effects of changes that are much more complex.
Those rules are ran by rules engine that automate the impact analysis.
Going back to the above example, if the insurance company will remove the
intermediaries, it will have to check all the relations where the intermediary
is involved since they will be affected by the break up. Because of these
changes, many business processes will be working on this because of the
interactions that are part of the collaborations, for example the Close
Contract process is part of them, which uses multiple applications, some of
which will be affected by the change.
Below shows the Impact (in red) on collaborations.
(Lankhorst, 2005)
This figure below shows the impact (in red) on Close Contract business.
Page 57 of 66
(Lankhorst, 2005)
This figure below shows the impact (in red) on applications.
(Lankhorst, 2005)
Functional Analysis Dynamic Analysis
Functional analysis techniques used for process algebras and data flow
networks are important for dynamic analysis of architectures. Sometimes
there are two or more roles acting on the same time, overwriting or
destroying one-anothers work, as a result would require one to create a
protocol to stop this from happening in the future. Functional behavior
analysis can be looked upon as formal methods in which a qualitative
analysis will check to find errors, have an improved consistency, and focus
on the logic of models.
Page 58 of 66
The dynamics of a system with a framework description created by the

signature could be specified in multiple ways such as specifications built
around issues such as control flow modeling and data flow modeling
(Lankhorst, 2005). Control flow modeling is linked with algebra and data
flow modeling with data flow networks. For instance, the example of a small
company called ArchiSell will illustrate the formal methods using ArchiMate.
ArchiSell sells products which are supplied by different vendors. ArchiSells
employees order the items they need and then they sell them. Archisell has
designated sellers who are responsible for selling their own products. The
figure below describes how the system works. Archimate modeling concepts
and their relationships will be used to describe the enterprise (Lankhorst,
2005).
Below describes the business process architecture at ArchiSell:
(Lankhorst, 2005)
In the structural concepts we have products, roles and objects; in the
structural relationships we utilize association; the behavioral concepts use
processes; and behavioral relationships use triggering. The structural and
behavioral concepts are linked using the assignment and access relations
(Lankhorst, 2005). Each employee has to follow the steps below, as a
procedure necessary to order the products:
1. Orders must be registered in the Order Registry before placing it. The
Order Registry is used only for administrative purposes. Since orders
could be made of many products, the Order Registry will be used to
check the order.
Page 59 of 66
2. As soon as the employee sends the order form, the supplier are
required to gather the products and distribute them to ArchiSell as
soon as possible.
3. When the supplier delivers the order, the employee will have to make
sure if there is an order matching this delivery. After confirming, the
order will be accepted.
4. Lastly, the employee will check the Product Registry to see who
ordered the product, and as a result will be the owner of the product.
(Lankhorst, 2005)
Signature
The signature of the business process architecture gives examples of the
signature that could be:
1.
2.
3.
4.
5.
6.
Role
Object
Employee
Product
Order Registy,
And Product Registry
(Lankhorst, 2005).
More detailed information about the framework is represented symbolically

in different extensions of one of the signature. Signatures can be used to
create complex types based on primitive sorts. Product type is an operation
represented as T1 x T2, where T1 and T2 are the types, and we have the
function T1 -> T2 where T1 is the argument and T2 is the result. Functional
types could be represented as F(T1): T2, where F is the function of T1 ->
T2, and they are used to represent attributes. To illustrate this, an example
of Employee and N, being primitive sorts, and Age(Employee):N as a
function are able to find the age of the employees. The sub-sort relation
could be represented as:
Employee is_a Role
Product is_a product
Order_Registry is_an Object
Product_Registry is_an Object
Owns is_an association
(Lankhorst, 2005).
Page 60 of 66
Meta-model information of the framework is encoded as part of the

signature of the framework. Partial orders between sorts and relations of
signature express the relation between meta-model sorts, relations,
framework sorts and relations (Lankhorst, 2005).
Interpretation
The interpretation of a signature could be used to find a formal model of a
system which could be a semantic interpretation of the symbolic model of its
framework description (Lankhorst, 2005).
Process Algebra
Process algebra describes the control flow behavior of complex systems.
Beginning at the language syntax, every statement provides a behavior, and
by using a semantic equivalence, one can determine which behavior is the
same. Axioms and equation laws are expressed from process algebra. The
axioms are supposed to be sound, which means that if two behaviors are
equal they are semantically equivalent or vice-versa, which identifies as
completeness. The system has many processes collaborating with each
other regulated by rules. From the basic actions, processes hierarchically
are means of operators, for example sequential composition, choice and
parallel composition. Process algebra could be used as a modeling tool for
any given business function and to check if it is running correctly. The
processes can transform the specifics of a business and its framework
abstractly and as a result, can check if those processes are conforming to
the specifics (Lankhorst, 2005).
Going back to the ArchiSell example, processes are the same as functions.
The following arguments and result values are listed below:
Roles assigned to processes, show the argument and result value
related to the given function.
The type of argument and result value of the relating function are
shown from the outgoing access relation from a process to a data
Incoming access relations from object to process provides information
about the type of the argument
(Lankhorst, 2005).
The functions are as follows:
Register_order_placement
o domain name=Employee
o domain name=Order_Registry
o codomain name=Employee
Page 61 of 66
o codomain name=Order_Registry
Place_order_for_product
Accept_product
o domain name=Order_Registry
Register_product_acceptance
o domain name=Product_Registry
o codomain name=Product_Registry
(Lankhorst, 2005)
Pseudo-language could be used to describe the interpretation of processes,
but matrices of input/outputs could be used as well.
Data Flow Networks
Data flow networks are used as a technique for the behavior of complex
systems, and it contains processes in which communicate data over lines.
Processes do the transformation of data inside a given system, and where a
line as First In First Out connects a maximum of two processes together.
When data is sent over the line from a process, it will arrive in an x time, in
the same order it was initially transmitted. Business functions could be
represented from data flow diagrams. This technique gives a general view
of the business and ends with a detailed analysis of all the functional areas
of interest, which are up to the requirements of the required level. For
instance, a top-down expansion could be used to analyze the target in a
precise way showing all the activities through diagrams. In the ArchiSell
example, from a data flow point of view, every process is described as an
independent data-consuming/producing entity, where these entities have
input and output ports. The data flow interpretation has a goal to study the
data flow inside a process and not the actors that perform the process
(Lankhorst, 2005).
The figure below helps interpret the data flow network as the following:
Not to include role information about roles and individuals within the
role sort. Data flow diagram shouldnt contain any details of actors or
process steps.
Stores will be represented as registries. They will store the
information which could be retrieved later.
Page 62 of 66
The input and output ports will have a value associated with them
representing the number that have to be sent or received
(Lankhorst, 2005).
Below shows ArchiSell as a data flow network:
(Lankhorst, 2005)
The following values are communicated:
list of products that have to be ordered;
order registry record;
supplier order;
list of products received;
list of products accepted;
list of products accepted;
product registry record;
product registry record;
order registry record
(Lankhorst, 2005).
The data flow diagram defines each data flow step, where the functions
transform the input values into output values. This function could be
described using pseudo-language and can derive an active simulation of the
Page 63 of 66
process architecture. The data flow diagram will also look at the actors and
how to assign them correctly to processes (Lankhorst, 2005).
Summarizing The Analysis of Enterprise Architecture
The relation between enterprise architecture models and architecture
analysis are very important, with two main classes of methods as the focal
point, which are the quantitative and functional analysis. Most performance
analysis are examined in a given domain inside the architecture. A new
approach was introduced for the distribution of workload and performance
measures through the layered framework model which could be used as an
analysis framework. The top-down and bottom-up technique are used to
analyze the performance of a document management system for storage
and retrieval of damage reports. Queuing formulas are used for the answer
times from lower to higher layers in which could increase the local service
times.
Meanwhile, the functional analysis techniques help us understand how to
better read architectures, reduce mistakes, and enrich architecture
descriptions with more important information in easier steps and more
accurately. In addition, the examination of the difference between static,
structural, dynamic, behavioral aspects, compared symbolic and semantic
models were looked at. In which, the most important part of symbolic
model is the signature which gives details about structural elements and
relationships. The semantic models integrate static and dynamic elements.
This framework uses the integration of different techniques such as static
analysis, process algebras and data-flow networks. In the end, the results
of quantitative and functional analysis make it clear to architects on what
issues need to be addressed in the making of enterprise architectures.
Page 64 of 66
References
Artisan Software Tools: UK's Defence Science and Technology Laboratory
chooses Artisan Studio. (12 January). M2 Presswire. Retrieved March 4,
2010, from ProQuest Computing. (Document ID: 1937530421).
Bailey, Ian. (12 April 2006). Ministry of Defence Classification and Reference
Data Support for MODAF.
Bailey, Ian. (12 November 2007). Representing Information Exchange
Requirements using the MOD Architecture Framework (MODAF).
BMT Hi-Q Sigma. (2007). Project Case Study- Attack Helicopter Mid Life
Update URD. Bath, BA2 3DZ.
BMT Hi-Q Sigma. (2010). About Us. Retrieved March 1, 2010, from BMT HiQ Sigma: http://www.hiqsigma.com/?/1791
Bucher, T., Fischer, R., Kurpjuweit, S., & Winter, R. Enterprise Architecture
Analysis and Application An Exploratory Study. St.Gallen: Institute of
Information Management, University of St. Gallen.
Davis, G., & Washington, K. (2009, Winter). Developing a System Using the
MOD Architecture Framework -a Case Study. Defence Codex(5), 78-83.
Design XML schemas using UML. (2003, February 1). Retrieved February 21,
2010, from IBM:
http://www.ibm.com/developerworks/xml/library/x-umlschem/index.html
Gorman. P. <Patrick.Gorman429@mod.uk> (2010, February 06). About
Modaf [tjakova@quinnipiac.edu]. (2010, February 11).
Hause, Matthew. (October 2008). An Overview of UPDM- A Unified Profile for
DoDaf/MODAF. http://www.mil-embedded.com/articles/id/?3653
IRC Software Glossary. (2009). Retrieved February 15, 2010, from Natural
Resource Ecology Laboratory:
http://www.nrel.colostate.edu/projects/irc/public/Documents/Software/Glos
sary.htm
Jones, J., Fatma, D. F., Blevins, T., & Siegers, R. (2007, May). The Synergy
of Architecture Frameworks: What Goes Around Comes Around. Retrieved
March 3, 2010, from Information Management:
Page 65 of 66
http://www.information-management.com/infodirect/20070518/10826021.html
Lankhorst, M. (2005). Enterprise Architecture at Work - Modelling,
Communication, and Analysis. Enschede: Springer.
Lockheed Martin UK. (2010). Architecture Framework Modelling. Retrieved
March 1, 2010, from Lockheed Martin UK: http://www.lmisgs.co.uk/defence/architecture_framework_modelling.htm
Ministry of Defence. (4 September 2004). MOD Architectural Framework
(MODAF) Tri-Fold
Ministry of Defence. (31 August 2005). MOD Architecture Framework
Version 1.0.
Ministry of Defence. (31 August 2005). Project Management Reference
Guide.
Ministry of Defence. (19 November 2008). The MODAF Technical Standards
Views (TV) Viewpoint.
Ministry of Defence. (20 November 2008). The MODAF Technical Standards
Views (TV) Viewpoint.
Ministry of Defence. (21 November 2008). The MODAF Acquisition (AcV)
Viewpoint.
Ministry of Defence. (24 November 2008). The MODAF Strategic Views
(StV) Viewpoint.
Ministry of Defence. (27 November 2008). The MODAF Service Oriented
View (SOV) Viewpoint.
Ministry of Defence. (3 February 2009). Ontologies and Their Uses MODAF
1.0.
Ministry of Defence. (12 February 2009). The MODAF Operational Viewpoint
(OV).
Ministry of Defence. (17 February 2009). The MODAF System Viewpoint
(SV).
Ministry of Defence. (10 March 2009). MODAF Meta Model V 1.0.
Page 66 of 66
Ministry of Defence. (18 May 2009). MODAF Configuration Control Policy

and History.
Ministry of Defence. History of the Ministry of Defence.
http://www.mod.uk/DefenceInternet/AboutDefence/History/HistoryOfTheMO
D/
Minoli, D. (2008). Enterprise Architecture A to Z. Boca Raton, FL: Auerbach
Publications.
MODAF. (2009). Retrieved February 15, 2010, from Architecture Framework
Forum: http://www.architectureframework.com/modaf/
OS Join Task Force. (2006, December 3). A Brief Introduction to the DoDAF
CADM-AP233 Mappings. Retrieved March 2, 2010, from Open Systems Join
Task Force:
http://homepages.nildram.co.uk/~esukpc20/exff2005_05/ap233/dodaf/dod
af.html
Sircar, S., & Kott, A. (2000). Enterprise Architecture Analysis using an
Architecture Description Language. Pittsburgh: Logica Carnegie Group.

MODAF Final Paper PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

MODAF Final Paper PDF

Cargado por

Copyright:

Formatos disponibles

Ministry of Defence

OVERVIEW AND SCOPE OF MODAF

Strategic Views (StVs) are used to define the desired outcomes or

Technical Views (TVs) contain standards, rules, and policy and

(Ministry of Defence, 24 November 2008)

(Ministry of Defence, 24 November 2008)

(Ministry of Defence, 12 February 2009)

SOA models, using service elements instead of traditional needlines.

(Ministry of Defence, 12 February 2009)

OV-3 is the Operational Information Exchange Matrix which provides more

(Ministry of Defence, 12 February 2009)

(Ministry of Defence, 12 February 2009)

provides governance for service oriented architecture by showing services in

(Ministry of Defence, 27 November 2008)

(Ministry of Defence, 27 November 2008)

(Ministry of Defence, 27 November 2008)

System Viewpoint (SV)

(Ministry of Defence, 12 February 2009)

(Ministry of Defence, 12 February 2009)

(Ministry of Defence, 12 February 2009)

(Ministry of Defence, 12 February 2009)

performance characteristics of the SV (Ministry of Defence, 12 February

(Ministry of Defence, 12 February 2009)

(Ministry of Defence, 12 February 2009)

(Ministry of Defence, 21 November, 2008)

Example of Icon in AcV-2:

(Ministry of Defence, 21 November 2008)

that apply to the operational or business context (Ministry of Defence, 20

(Ministry of Defence, 20 November 2008)

The second view in TV is TV-2 Standards Forecast which describes any

(Ministry of Defence, 20 November 2008)

(Ministry of Defence, 19 November 2008)

The name used for this element in the architecture

An example of an AV-2 entry is shown below:

(Ministry of Defence, 19 November 2008)

HISTORY OF MINISTRY OF DEFENCE AND MODAF

Defence, N.D). In 1971, the Procurement Executive became part of the

framework are incorporated and tailored more to MoD terminology as

Extends all views by

Another difference between MODAF and DoDAF is that the MODAF

(OS Join Task Force, 2006)

technology (Jones, Fatma, Blevins, & Siegers, 2007). Below is an example

(Jones, Fatma, Blevins, & Siegers, 2007)

The Operational View in MODAF largely aligns with Phase B:

The System View in MODAF largely aligns with Phase C: Information

The Technical Standards View in MODAF largely aligns with Phase D:

The figure below shows an overview of the primary relationships between

Framework & Principles

AV-2, OV-1, OV-2, OV3, OV-4, OV-5, OV-6

SV-4, SV-5, SV-6, SV10

SV-1, SV-2, SV-3, SV-4

SV-8, SV-9, TV-2

(Jones, Fatma, Blevins, & Siegers, 2007)

models, and have the fundamental capability as mentioned before to create

(Ministry of Defence, 2005)

Defence organizations and high level interoperability requirements

The MODAF framework has helped Lockheed Martin deliver an integrated

(Lockheed Martin UK, 2010)

Capability integration compared across organizational and capability

Conducting capability gap and overlap analysis

A more complete URD

Suppliers of UKs Land Forces