Category Archives: Structure

A2 – Architecture Products

NAF v3: NAV-3 MODAF: AV-1/2

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Architecture
Meta-Data
A1
Meta-Data Definitions
NAV-3
AV-1/2
A2
Architecture Products
A3
Architecture Correspondence
ISO42010
A4
Methodology Used
NAF Ch2
A5
Architecture Status
NAV-1
AV-1
A6
Architecture Versions
NAV-1
AV-1
A7
Architecture Meta-Data
NAV-1/3
AV-1
A8
Standards
NTV-1/2
TV-1/2
Ar
Architecture Roadmap

The A2 Architecture Products view lists the products that describe an Architecture, and the views to which those products correspond.

Background

The A2 view specifies the structure of an architecture, and the products that describe the architecture. Each product may correspond to an architecture view. This view also traces the architectures onto the Enterprise Phases they correspond to (see also E2 – Enterprise Vision) and identifies the key stakeholders, their concerns and the products that address those concerns (from ISO42010).

Usage

Representation

Detailed View Description

Key Elements and Their Relationships

Meta-Model

a2-meta-model

P2 – Resource Structure

NAF v3: NSV-1/NOV-4 MODAF: SV-1/OV-4

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
L4-P4 (NSV-5)
Physical
Resource
Specifications
P1
Resource Types
NAV-2, NSV-2a,7,9,12
AV-2, SV-2a,7,9,12
P2
Resource Structure
NOV-4,NSV-1
OV-4, SV-1
P3
Resource Connectivity
NSV-2, NSV-6
SV-2, SV-6
P4
Resource Functions
NSV-4
SV-4
P5
Resource States
NSV-10b
SV-10b
P6
Resource Sequence
NSV-10c
SV-10c
P7
Physical Data Model
NSV-11b
SV-11
P8
Resource Constraints
NSV-10a
SV-10a
Pr
Configuration Management
NSV-8
SV-8

A P2 Resource Structure view addresses the composition and (high-level) interaction of resources.

Background

The P2 links together the operational and systems architecture views by depicting how resources are structured and interact in order to realise the logical architecture specified in an L2 – Logical Scenario. A P2 may represent the realisation of a requirement specified in a L2 (i.e. in a to-be architecture) and so there may be many alternative Resource view suites that could realise the operational requirement. Alternatively, in an as-is architecture, the L2 may simply be a simplified, logical representation of the P2 to allow communication of key information flows to non-technical stakeholders.

A P2 can be used to specify typical (or template) organisation structures, and also identify how human resources interact with each other and with systems.

A P2 can provide a simplified representation of a pathway or network, usually depicted graphically as a connector (i.e. a line with possible amplifying information). The P2 depicts interactions between resources that are of interest to the architect. Note that interactions between systems may be further specified in detail in the P3 – Resource Connectivity view.

Resources may be decomposed in a P2 to any level (i.e. depth) of decomposition that the architect sees fit. A P2 may also identify the physical asset (e.g. platforms) at which resources are deployed and can show the operational nodes that utilise those resources. In many cases, an operational node depicted in a L2 product may well be the logical representation of the resource shown in P2.

Usage

  • Definition of system concepts.
  • Definition of system options.
  • Human – System interactions.
  • Typical Organisation structures.
  • Interface requirements capture.
  • Capability integration planning.
  • System integration management.
  • Operational planning (capability configuration definition).

Representation

Detailed View Description

Key Elements and Their Relationships

p2-hlmm
The data in a P2 can include:

  • Resource Type (all subtypes thereof)
  • Configured Resource Type
  • Resource Type Configuration (whole-part relationship)
  • Resource Interaction (all subtypes thereof)

Resources are assembled as Configured Resource Types – there is one (and only one) Configured Resource Type for each usage of a Resource Type in the structure. This enables components, sub-systems, etc. of the same type but used in different positions to be be individually identified. This is particularly useful for interactions – e.g. being able to identify the connection the left-hand pump as distinct to the connection to the right-hand pump of the same type.

Meta-Model

The detailed meta-model for P2 can be viewed here

D2 – Deployed Resources

NAF v3: NOV-4 MODAF: OV-4

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Deployed
Resources
D1
Master Data
NAV-2
AV-2
D2
Deployed Resources
NOV-4
OV-4
Dr
Deployment Schedule
NCV-5
StV-5

The D2 Deployed Resources view covers the structure of specific, individual Resources. This could be actual instances of systems, organisations or natural resources.

Background

A D2 shows how specific individual resources are deployed and configured. The scope for D2 is broad and covers human and non-human resources. D2 can therefore be used for depicting organisational structures (as covered in NOV-4 Actual in NAF 3.1). D2 is broader than OV-4, however as it also covers equipment, systems and natural resources.

A D2 view may be used to:

  • Specify configuration of deployed resources.
  • Identify architecture stakeholders.
  • Identify process owners.
  • Illustrate current or future organisation structures.

Usage

Representation

Detailed View Description

Key Elements and Their Relationships

Meta-Model

L2 – Logical Scenario

NAF v3: NOV-2 MODAF: OV-2 DNDAF: OV-2, SecV-1/7 (logical)

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
Logical
Specifications
L1
Node Types
NAV-2
AV-2
L2
Logical Scenario
NOV-2
OV-2
L3
Node Interactions
NOV-2, NOV-3
OV-2,OV-3
L4
Logical Activities
NOV-5
OV-5
L5
Logical States
NOV-6b
OV-6b
L6
Logical Sequence
NOV-6c
OV-6c
L7
Logical Data Model
NSV-11a
OV-7
L8
Logical Constraints
NOV-6a
OV-6a
Lr
Lines of Development
NPV-2
AcV-2

The L2 Logical Scenario view shows, at a high level, the interactions between logical nodes and places them in the context of location(s).

Background

The primary purpose of the L2 View is to specify nodes (elements of capability) in context of each other. The context is usually expressed in terms of the information that flows between the nodes (e.g. the information flow requirements between capabilities in a given scenario). The context may also be flows of materiel, human resource or energy.

Since NAF v3, the L2 has been developed to:
• Adopt a more formal definition of logical flows to represent node connections.
• Support the introduction of Service Oriented Architecture (SOA).
• Accommodate the use of known resources (as defined in L2 – Resource Structure).

Usage

• Definition of operational concepts.
• Elaboration of capability requirements.
• Definition of collaboration needs.
• Associating capability with a location.
• Problem space definition.
• Operational planning.
• Supply chain analysis.

Security Usage

The L2 view is enhanced with additional features for modelling security:

• Security domain specification
• Logical entity trust models
• Threat specification (e.g. threat vectors) & counter-capability specifications

Representation

The following L2 example shows how security domains can be specified at a logical level:
l2-dbsy-example

The following example is a simple entity trust model described at a logical level:
l2-ent-trust-example

An L2 may also show the Operational Activities performed by each node:
l2 example activities 1

The required locations for Nodes may also be specified:
l2 example locations
Care must be taken when using locations, however. L2 is intended to be a Logical model (i.e. solution independent), and in many cases the location will not be known at design time.

Detailed View Description

**Julie – take care here when pasting in the MODAF documentation. L2 is not quite the same as OV-2. It is now preferred to put the capabilities and measures in L1 (though we still allow it in L2 if necessary). Also, the service orchestration is not in L2 any more, so the service examples go. ***

Key Elements and Their Relationships

l2-hlmm

Meta-Model

The detailed meta-model for L2 can be viewed here