Category Archives: Taxonomy

A1 – Meta-Data Definitions

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 A1 Meta-Data Definitions view specifies the categories of meta-data tag used throughout the architecture.

Background

Architectures, particularly large ones, usually require meta-data tags to aid with searching and discovery. NAF specifies some built-in meta-data tags, such as:

  • Definition
  • Assumption
  • Finding
  • Recommendation
  • Purpose
  • Approver, Approval Milestone, Modeller, Manager, Responsible Owner, Tool Used (see Ap – Architecture Plan)

Usage

Representation

Detailed View Description

Key Elements and Their Relationships

Meta-Model

a1-meta-model

P1 – Resource Types

NAF v3: NAV-2, NSV-7,9 MODAF: AV-2, SV-7,9

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

The P1 view specifies the types of Resources, Technology and Competences required for the architecture. It can also be used to specify properties of Resources.

Background

The P1 view collects together all the Resource Types in the architecture. It can also be used to identify Technologies and Competences and map these to resource types. Technologies and Competences can also be set against a timeline indicating when they are expected to be in use.

Usage

  • Identifying Resource Taxonomies.
  • Forecasting technology readiness against time.
  • HR trends analysis.
  • Recruitment planning.
  • Planning technology insertion.
  • Input to options analysis.
  • Definition of performance characteristics.
  • Identification of non-functional requirements (input to SRD).

Representation

Detailed View Description

Key Elements and Their Relationships

p1-hlmm

Meta-Model

The detailed meta-model for P1 can be viewed here

D1 – Master Data

NAF v3: NAV-2 MODAF: AV-2

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 D1 Master Data view specifies standard reference data in the deployed space. This includes organisations, locations, facilities, and individual platforms.

Background

Usage

Representation

Detailed View Description

Key Elements and Their Relationships

d1-hlmm

Meta-Model

The detailed meta-model for Pr can be viewed here

S1 – Service Taxonomy

NAF v3: NSOV-1/NAV-2 MODAF: SOV-1/AV-2

TaxonomyStructureConnectivityProcessesStatesSequencesInformationConstraintsRoadmap
C1-S1 (NSOV-3)
Service
Specifications
S1
Service Taxonomy
NAV-2, NSOV-1
AV-2, SOV-1
S3
Service Interfaces
NSOV-2
SOV-2
S4
Service Functions
NSOV-3
SOV-5
S5
Service States
NSOV-4b
SOV-4b
S6
Service Interactions
NSOV-4c
SOV-4c
S7
Service I/F Parameters
NSOV-2
SOV-2
S8
Service Policy
NSOV-4a
SOV-4a
Sr
Service Roadmap

The Service Taxonomy View (S1) specifies a hierarchy of services. The elements in the hierarchy are service specifications (rather than service implementations), and the relationships between the elements are specialisations – i.e. one service is a special type of another.

Background

The purpose of an S1 is to provide a governance structure for a Service-Oriented Architecture. Along with S3 (Service Interfaces), it specifies a standard library of service specifications for an enterprise, which service implementers are expected to conform to.

Usage

  • SOA governance.
  • Identification of services.
  • Service planning.
  • Service audit.
  • Service gap analysis.
  • Providing reference services for architectures.
  • Tailoring generic services for specific applications.

Representation

  • Tabulation.
  • Hierarchical (connected shapes).
  • UML class diagram.

Detailed View Description

In NAF terms, a service is an implementation-independent specification of a packaged element of functionality and/or capability. There is potential for confusion between services and capabilities. The key indicator of a service is that it provides a standard interface to consumers. This means that services may be used as “wrappers” for one or more capability in order to provide a standard method of access to the capability. A well-designed service taxonomy provides a set of specifications for capability providers to adhere to.

An S1 depicts services, specialisation relationships between services, service attributes and service policy (i.e. constraints). A service taxonomy persists over time (an architect may wish to specify historical, current or future services) and may be referenced by multiple architectures.

In S1, services are only defined in the abstract, i.e. S1 does not specify how a service is to be implemented. An S1 is structured as a specialisation hierarchy of services, with the most general at the root and most specific at the leaves.

An S1 is structured using only specialisation relationships between elements (super-subtype). Any service that specialises from another must implement all the functionality of its parent, and provide all the same input and output interfaces of its parent; in other words, any specialised service shall be entirely compatible with its parent (however, it may add functionality and interfaces). For example, if a service, “Printing”, requires input of paper size and ink colours, a service, “Hi-Resolution Printing”, that specialises from it must also accept these parameters and produce equivalent behaviour when initiated.

s1-example-1

Services may have attributes and constraints (service policy) defined against them. Attributes are inherited by specialised services. Where an attribute is specified for a service, implementations of that service shall specify their values for the attribute. The example below shows an availability attribute defined against the top service. All other services inherit that attribute, and the WarfightingService sets a constraint (service policy) that the availability shall be greater than 95%. This policy is then inherited by the three situational awareness services. Note that policy may be overridden in specialised services.

s1-example-2

Key Elements and Their Relationships

s1-hlmm

  • Service Specification (was <<Service>> in NAF 3.1)
  • Service Generalisation (super-subtype relationship between Service Specifications)
  • Measure Category
  • Measure

Meta-Model

The detailed meta-model for S1 can be viewed here

L1 – Node Types

NAF v3: NAV-2 MODAF: AV-2

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

An L1 view specifies the types of logical Node used in the architecture. The nodes can be organised into a specialisation hierarchy (subtype-supertype).

Concerns Addressed

  • User Requirements
  • Operational Planning
  • High-Level Systems Requirements

Background

An L1 is used to define all the Nodes that will appear in a Logical Architecture. Nodes are elements of capability that are assembled and orchestrated in Logical Architecture. The levels of capability provided by each node are expressed as Measures of Performance, and these may be dependent on the environments in which the Node is required to operate.

Usage

  • Initial set up of a Logical Architecture
  • Defining measure of performance for requirements specification purposes
  • Defining the types of environment in which Nodes may operate

Representation

An L1 can either be shown as a diagram that traces nodes to capabilities (also showing required measures of performance) or as a table:

l1-example
l1-example2

Detailed View Description

Nodes are traced to the Capabilities they manifest using the Capability For Node relationship. In addition, Measures of Performance may be specified for each node that map to the Measures of Effectiveness of the Capabilities. Each Measure can be expressed in terms of the environment – e.g. higher performance may be expected in clear weather than in bad.

The L1 helps to de-clutter an L2 by taking care of the properties and capabilities mappings that were previously shown in NAF v3 in NOV-2. It is still possible to show capabilities and properties in an L2 if required though.

Key Elements and Their Relationships

l1-hlmm

Meta-Model

The detailed meta-model for L1 can be viewed here