modaf- ministry of defence architecture framework

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

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

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

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

organization‟s strategy. MODAF version 1.2 calls for a diagram to show an

organization‟s goals and capabilities. An example is shown below.

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.

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.

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.

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

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:

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.


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

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

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

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 NAF‟s 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 SOV-

4a, 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


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

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

1 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

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

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.


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

automated, 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. SV-

8 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

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

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

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:

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.

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

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

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

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

period 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

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.

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):

of 66

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


HISTORY OF MINISTRY OF DEFENCE AND MODAF

The United Kingdom‟s 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

of 66

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

MOD as well. Today‟s Ministry of Defence sets policy and provides political

control over the United Kingdom‟s 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.

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

2 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),

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

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

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 Description MODAF DODAF

All Viewpoint

(AV)

Extends all views by

providing context,

summary, or overview-

level information

√ √

Operational

Viewpoint (OV)

Shows what is going on

in the real world that is

to be supported or enabled by systems

represented in

architecture

√ √

Systems View

(SV)

Describes existing and

future systems √ √

Technical

Standards View

(TV)

Lists standard

(commercial off-the-

shelf, government off-

the-shelf system parts

or components

√ √

Strategic

Viewpoint (StV)

Overall vision of the

organization to support

military operations

√ ×

Acquisition

Viewpoint (AcV)

Shows how projects and

capabilities are

dependent on one

another across DLOD

√ ×

Service Oriented

Viewpoint (SOV)

Describes the services

required to support the

processed in OV

√ ×

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

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.

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

A Vision AV-1, OV-1

B Business Architecture AV-2, OV-1, OV-2, OV-

3, OV-4, OV-5, OV-6

C Information Systems Architecture: Data

Architecture

OV-7, SV-11

Information Systems

Architecture:

Applications

Architecture

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

10

D Technology Architecture SV-1, SV-2, SV-3, SV-4

SV-5, SV-7, SV-10, TV-

1

E Opportunities &

Solutions

SV-8, SV-9, TV-2

F Migration Planning SV-8

G Implementation

Goverance

AV-1, OV-1

H 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

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.

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 world-wide 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:

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.

(Lockheed Martin UK, 2010)

Some of the benefits gained from using MODAF at Lockheed Martin include:

Capability integration compared across organizational and capability

boundaries

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

life 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. (Lockheed Martin UK, 2010)

DSTL

The Defence Science and Technology Laboratory (DSTL), which is an agency

of the UK‟s 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 Hi-

Q 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:

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 UK’s Land Forces

Because demands in recent times have increased substantially for suppliers

of UK‟s Land Forces, the requirements have evolved significantly since

moving from historic theaters of operations in Europe and the UK. Today‟s

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 user‟s 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).

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 organization‟s MODAF Operational View

(OV-1a)

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


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 architecture‟s

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.

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 analysis‟s- 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 company‟s 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 won‟t 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;

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

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:

(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

Analysis dimensions

Quantitative

Simlulation

Functional

Analytical

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 doesn‟t 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 model‟s 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 architecture‟s 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

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

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 user‟s 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

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 application‟s 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 five-step 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 service-

oriented 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:

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

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

shouldn‟t 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.

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. Frame-based systems,

2. Semantic networks,

3. KL-ONE languages,

4. Object-oriented representation,

5. Semantic data models, 6. 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:

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)

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.

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-another‟s 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.

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. ArchiSell‟s

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.

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

2. Object

3. Employee

4. Product

5. Order Registy,

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

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

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=Employee 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 shouldn‟t contain any details of actors or

process steps. Stores will be represented as registries. They will store the

information which could be retrieved later.

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

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.

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

Q 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. <[email protected]> (2010, February 06). About

Modaf [[email protected]]. (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:

of 66

http://www.information-management.com/infodirect/20070518/1082602-

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

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

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- ministry of defence architecture framework

Travel