© copyright 2009 ncoic - all rights reserved approved for public release distribution unlimited...

© Copyright 2009 NCOIC - All Rights Reserved

Approved for Public ReleaseDistribution Unlimited

NCOIC-PatternGuidance-20091217

Practical Guidance forNet-Centric Pattern Developers

December 2009


Past Platform focused Performance driven Standalone

Present Technology exists, but not universally

integrated Some transformational programs funded Lack of common System-of-Systems

approach Industry assistance required for interoperability

Future Integrated, ad hoc, interoperable solutions Global multi-domain System-of-Systems

Industry working together with governmentsto accelerate global interoperability of systems

Network-Centric Operations Industry Consortium (NCOIC)

Systems A, B, C, …

Comm & NetworkingArchitecture

InformationArchitecture

Applications

HSI HSI

System A

System B

System C




NIF Solution Description (NSD) Reference Manual (NSD-RM) Including overarching

framework and principles for interoperable, net-enabled systems

• User’s Guide (NSD-UG) with stakeholder-oriented information regarding the NIF approach (future)

NIF Scope and Problem Statement (NSPS) Defines the scope of the NIF Defines the interoperability problem space Defines top level requirements for interoperability

Req

uire

men

tsSo

lutio

n &

Gui

de

Please join the NIF Team or Specialized Frameworks Team for more information about the NIF and architectural approaches

Please join the NIF Team or Specialized Frameworks Team for more information about the NIF and architectural approaches

Specialized Frameworks (SF) Architectural principles and guidance for focused

technical areas critical to interoperability(for example: Information Assurance, Mobility, Semantic Interoperability, Services) Sp

ecia

lizat

ion

NCOIC Interoperability Framework (NIF™) Overview

The NCOIC Interoperability Framework (NIF) provides resources for system engineers and architects who are working on interoperable net-centric (or net-enabled) systems


Context of Net-Centric Patterns (NCP) NIF Overarching Framework contains:

– Concepts: Necessary knowledge definitions, dictionaries, ontologies, information models, etc.

– Processes: Top-down, bottom-up, & middle-out architecture and design approaches

– Principles: Overall requirements, goals, tenets, and best practices that foster net-centricity

– A construct for developing guidance for solving operational and technical problems for a given context: Net-Centric Patterns

Patterns provide practical guidance for creating systems with the desired net-centric capabilities in order to mitigate specific net-centric interoperability problems – Patterns are not contained in the NIF, will be stored in an online repository

in the near future


Definition & Intent of Net-Centric Patterns Definition of a Net-Centric Pattern, as per the NCOIC Lexicon:

– “A Net-Centric Pattern (NCP) provides expert practical guidance based on open standards for creating systems with desired Net-Centric capabilities in order to mitigate specific Net-Centric interoperability problems.”

Patterns are:– Prescriptive guidelines for practical use by designers and implementers that

can be tailored and re-used for solving interoperability problems

– Sufficiently detailed to facilitate verification of vendor evidence of conformance to the pattern

– Guidance for hardware, software, processes, and procedures(more than just traditional software patterns)

Patterns are not:– Intended as theoretical or philosophical discussions of the “nature” of net-

centricity and interoperability approaches, which are best addressed elsewhere

– Intended as rigid specifications for point design solutions


Net-Centric Pattern GuidanceNet-Centric Patterns must guide users away from known problem areas!


Intent of Net-Centric Patterns Patterns should be easy to read and their purpose clearly

understood by individuals knowledgeable in the subject matter, and not just by the pattern authors– Front portion of the pattern document needs to be

clear and concise, with as few pages as possible,in order to get to the implementation guidance section(which is the key part of the pattern)

– Developers need to quickly understand whether the pattern is relevant to the problem at hand, without having to read through a lot of pages

– A pattern can have as many appendices as necessary to provide relevant reference and background information to support the pattern, without distracting from the objectives stated above


Focus of Patterns Pattern developers need to continually remind themselves that

net-centric patterns pertain to “interoperability” of network-centric systems – Pattern developers should focus on interoperability and not the

broader topic of all aspects of performance

– However, interoperability does affect performance

Lesson Learned from developing sample patterns:– It’s very easy to get off track and emphasize the wrong things by

exploring solutions to performance problems Rather than just developing specific guidance regarding the impact of

interoperability on performance

– It’s tempting to develop giant, all-encompassing patterns Rather than dividing the problem into a manageable hierarchy of patterns

– Thereby making the pattern too complicated


Users of net-centric patterns need practical and concise guidance on how to achieve interoperable solutions!

Users of net-centric patterns need practical and concise guidance on how to achieve interoperable solutions!

YES!NO!

Complicated Patterns


Each Category provides guidance for different needs(Mission-oriented, Function-oriented, and Design-oriented)

Each Category provides guidance for different needs(Mission-oriented, Function-oriented, and Design-oriented)

Pattern Categories There are three categories of Patterns:

– Operational: Describes standard practices and their interoperability requirements needed to conduct activities (military operations or business objectives) in a given mission context

– Capability: Describes the standard methodologies and functions needed to support required activities in a mission context from an interoperability perspective as specified in Operational Pattern(s)

– Technical: Describes the technical standards, technologies, and interoperability techniques needed to support required capabilities in a functional context specified in Capability Pattern(s)


Includes descriptions of pertinent operational scenarios and their interoperability requirements

– Military or Commercial

Typically requires operational analysis

May invoke dependent Capability Patterns that support required operations

Operational Patterns


SERVICECOMPONENT

PROVIDER

“SMART”ROUTER

SERVICECONSUMER

SERVICECOMPONENT

PROVIDER

Capability Patterns Sample Capabilities:

– Enterprise Service

– SOA Service Provider

– Community-of-Interest Portal

– Application Program

– Data Conversion Provider

May invoke dependent Technical Patterns that support required functions


Sample Technologies:– Communications technology

– Data exchange protocol

– Information formatting, etc.

May invoke other dependent Technical Patterns that provide a foundation or infrastructure required by a Technical Pattern

See NSD-RM for top-down, bottom-up, middle-out approachesfor pattern development– Bottom-up approach typically identifies practical constraints to provide reality

to a concurrent top-down approach

Technical Patterns


OPERATIONALPATTERN

OPERATIONALPATTERN

CAPABILITYPATTERN 1

CAPABILITYPATTERN 2

CAPABILITYPATTERN 3

CAPABILITYPATTERN 4

TECHNICALPATTERN

“A”

TECHNICALPATTERN

“B”

TECHNICALPATTERN

“C”

TECHNICALPATTERN

“D”

TECHNICALPATTERN

“E”

TECHNICALPATTERN

“F”

TECHNICALPATTERN

“G”

TECHNICALPATTERN

“X”

TECHNICALPATTERN

“Y”

TECHNICALPATTERN

“Z”

Net-Centric Pattern HierarchyA Top-Down Approach


Net-Centric Pattern Hierarchy

Operational Pattern

Capability Pattern

Technical Pattern

supports

requires

also maysupport other

types ofconstruction

supports

requires

also mayrequire othercapabilities

also mayrequire other

tools

also maysupport otherconstruction

activities


Pattern Outline Cover Page

– Pattern Name and Identification– Aliases– Date & Version– Version History– Abstract

Description– Problem Statement & Context– Expected Benefits– Participants – Pre-Conditions – Structure– Behavior – Post-Conditions

Implementation Guidance– Standards– Expert Advice– NIF Overarching & Specialized

Frameworks– Known Uses (optional)– Increased Capability Potential

(optional)– Related Patterns– References (optional)

Verification Appendices (optional)

– Supporting Information– Typical Implementation Types

for this Pattern– Validation Artifacts/Evidence– Vision for the Future


The clarity of this section determines the ease of organization and retrieval, thereby increasing use. This section should be

no more than one page, suitable as a cover page.

The clarity of this section determines the ease of organization and retrieval, thereby increasing use. This section should be

no more than one page, suitable as a cover page.

Cover Page DescriptionIdentity

– Title A descriptive and unique name that helps in identifying and referring to the

pattern Include the pattern category in the name (e.g., “Operational”, “Capability”, or

“Technical”), such as “XYZ Technical Pattern”

– Aliases List any alternative pattern names that may be (or may have been) used in place

of the pattern name listed above, as different nationalities or technical disciplines may understand it by a different name

If none, state “none”

– Authors List the author(s) and affiliation(s)

– Date & Version Use NCOIC standard versioning, e.g. V1.1-2009-01-20


Cover Page Description (continued)

Identity (continued)

– Version History

List of prior version numbers and dates. Do not include draft versions. Indicate briefly what major changes have taken place, deferring detailed change descriptions to an Appendix to the pattern. Sample version history might be:V1.1-2009-01-20 Standard xyz updatedV1.0-2008-12-25 Clarified verification methodology

– Abstract

A consistent and clear 200 word or less summary of the problem, course of action, results obtained, conclusions, and any recommendations

This section will be used on the NCOIC website and in other contexts to help potential users understand what will be found within the pattern.

– Header and Footer Header: Contains NCOIC logo, pattern name, NCOIC entity

Footer: Contains page #, version #, & clearance status


This section illustrates the manner in which the pattern would be used, and the problems that would be solved through its

application. It provides for greater specificity and focus.

This section illustrates the manner in which the pattern would be used, and the problems that would be solved through its

application. It provides for greater specificity and focus.

Pattern DescriptionDescription

– Problem Statement & Context Problem

– Describe the problem that the pattern solves within the appropriate context (described next)

– In other words, why is this pattern needed? Context

– Describe the context or scenario in which the pattern is applicable, and the conditions under which the pattern is to be used:

Operational Pattern: describe the mission domain and operational entities

Capability Pattern: describe a scenario in which this capability would be used

Technical Pattern: explain the technical goal of the pattern– Keep this section short, consider placing lengthy details in an Appendix


Pattern Description (continued)

Description (continued)

– Expected Benefits

Describe the advantages accruing from the use of this pattern, i.e., a reason for following this pattern

– Participants

Actors

– Describe the people and systems (actors or performers or participants) which require this operation/capability/technology to achieve their goals

– Include indirect participants that may provide input, or receive output, as a result of pattern use


Participants: Views & viewpoints (pictures) are worth a thousand words… if the viewer understands the visual methodology

Use views & viewpoints only as applicable & useful!





– Participants (continued)

Actors (continued)

– For an Operational Pattern: Describe how people and systems (both internal and external)

interact to accomplish their activities (military operations or business objectives) in the given mission context

– For a Capability Pattern: Describe how people and external systems invoke (or use or

supply data to, or receive data from) the capability to achieve the required functions

– For a Technical Pattern: Describe how people and external systems interact with the

system or service that incorporates the pattern




– Participants (continued)

Interfaces– Focus on identifying and describing characteristics of

interfaces between participants, or interfaces between participants and the system(s) and process(es) associated with the pattern

– Suggest using an appropriate method to show the participants that are associated with the pattern, such as:

UML or SysML use case diagram showing actors and use cases of the system, procedure, or operation

DoDAF / MoDAF / NAF / DAF diagrams: Operational & Capability

Or even a simple table of participants and their interfaces




– Pre-Conditions Describe the constraints and assumptions that must be met in

order for the pattern to be applicable or function properly – Operational Pattern: May include a description of operational

state(s) that must exist before the pattern is applicable– Capability Pattern: May include a description of the conditions that

must be in place before the capability can be used– Technical Pattern:

May include infrastructure conditions that must be available for the technology to function properly

Key Performance Parameters (KPP) of the system prior to application of the pattern




– Structure Describes logical static elements supporting the understanding and the

implementation of the pattern:

– Identify pattern’s bounds

– Specify main object (components, functions, and services) used in this pattern and their roles and relationships in the design.

– Distinguish between provided and consumed functions and services

Suggest using an appropriate method to show the structure of the operation/capability/technology as applicable to its use, such as:

– UML class diagram

– SysML block definition diagram (and SysML parametric diagrams or requirement diagrams if applicable)

– DoDAF / MoDAF / NAF / DAF diagrams: Systems & Services

– Or even a simple block diagram of components




– Behavior Describe the dynamic interaction of the structure elements and

participants described in the prior sections– In other words, what major interactions are required to achieve the intent

of the pattern?

Describe the major steps to accomplish the operation or capability pattern– Or the sequence of activities and interactions of components in the

technical pattern

Suggest using an appropriate method to show interactions in the operation/capability/technology, such as:– UML or SysML activity diagram, sequence diagram (and state machine

diagram and timing diagram if applicable)

– DoDAF / MoDAF / NAF / DAF diagrams: Services & Capabilities

– Or even a simple flow diagram of procedural steps




– Post-Conditions Describe the results, consequences, and any potential side-

effects in the operation/capability/technology using this pattern

– Operational Pattern: may include a description of operational conditions that result from completion of the operational scenario

– Capability Pattern: may include a description of the conditions that result from the use of the capability

– Technical Pattern: may include states and modes resulting from use of the

technology

KPP of the system after the application of the pattern


This section is the main body of the pattern. It provides the detail necessary for a user to apply the pattern, and to determine

if it meets the stated needs outlined in Problem Statement.

This section is the main body of the pattern. It provides the detail necessary for a user to apply the pattern, and to determine

if it meets the stated needs outlined in Problem Statement.

Pattern Implementation GuidanceImplementation Guidance

– Standards Describe the standard(s) (including version(s) and any optional

variations to be applied in the operations/capability/technology implementation– Any specified protocols should be associated with the selected standard(s)

Use open or commercial standards such as IETF, ITU, IEEE, ISO, OMG, AIAA– Do not use proprietary standards

– Minimize use of special application or country unique defense standards such as US DoD or NATO classified standards

May use DoDAF / MoDAF / NAF / DAF diagrams: Technical Standards


Provide flexible guidance,avoid specifications for an implementation

Provide flexible guidance,avoid specifications for an implementation

Pattern Implementation Guidance (continued)

Implementation Guidance (continued)

– Expert Advice

Lessons learned

– Describe lessons-learned and best practices that Subject Matter Experts (SMEs) recommend for successful implementation of the standard(s) applicable to this pattern, especially:

Known cost / schedule / performance risks

Root causes of interoperability failures in use of the specified standards in prior and current systems (as of the time of pattern release)




– Expert Advice Constraints

– Lists any constraints on recommended solutions that affect interoperability

– Recommendations to invoke certain optional behavior, features of the standards; implement more than one standard; provide gateways, bridges, translators

Opportunities

– Methods of achieving significant improvement in interoperability

– Identify way to mitigate some of the restrictions imposed by constraints


At present, Specialized Frameworks Principles are still under development– most mature are the Services Principles

At present, Specialized Frameworks Principles are still under development– most mature are the Services Principles



– NIF Overarching and Specialized Frameworks NIF Guidance

– Examine the NIF Overarching Principles, determine their applicability to the pattern under development and if applicable, verify adherence to NIF Overarching Principle (NIF NSD-RM Section 2.3.1.2)

Verify adherence to principles and analysis contained in Specialized Frameworks as appropriate– Information Assurance– Mobility– Semantic Interoperability– Services



Implementation Guidance (continued) – Known Uses (optional)

List missions and/or systems which have used or currently use this pattern

– Increased Capability Potential (optional) Identify any portions of the pattern which can have increased

capability without interfering with interoperability: – Operational Pattern: might include mission flexibility

– Capability Pattern: might include acceptable variations of the capability

– Technical Pattern: might include additional capability (such as use of an optional extension of a standard) which if excluded or included would not impact interoperability of systems incorporating Building Blocks from different vendors


Remember to avoid giant, all-encompassing patterns!Break the problem into a manageable hierarchy of patterns

Remember to avoid giant, all-encompassing patterns!Break the problem into a manageable hierarchy of patterns


Implementation Guidance (continued) – Related Patterns: Dependent Patterns (Required)

Identify any dependent patterns that are REQUIRED by this pattern

– Operational Pattern: might include required Capability Patterns

– Capability Pattern: might include required Technical Patterns

– Technical Pattern: may include lower-level Technical Patterns that provide a foundation or infrastructure that must be present in order to support this pattern

If none known, state “none”



Implementation Guidance (continued) – Related Patterns: Associated Patterns (Optional)

Identify any associated patterns that are typically related to this pattern

The purpose of mentioning any associated patterns is to explain the context of use in relation to this pattern

– Operational Pattern: might include other Operational Patterns that are typically used before/after/during the mission

– Capability Pattern: might include Operational Patterns that are known to typically require this capability

– Technical Pattern: might include Capability Patterns and/or Technical Patterns that are known to typically require this technology




– References (optional)

Identify any industry-standard documentation, reports, or other materials that designers used to develop the pattern

Keep this section short by just providing links

– Any details should be placed in the Appendices at the end of the pattern document


Building Blocks must conform to net-centric pattern guidance,therefore net-centric patterns must include VERIFICATION CRITERIA

Building Blocks must conform to net-centric pattern guidance,therefore net-centric patterns must include VERIFICATION CRITERIA

The Relationship Between Building Blocks and Net-Centric PatternsNCOIC Building Blocks Certification Program

– "NCOIC Certified" logo on a product or service Gives buyers assurance that vendor promises of “network-centric

capabilities” are backed up by specific conformance to NCOIC Patterns Allows conforming vendors to advertise this assurance to their customers

while ensuring that non-conforming vendors cannot Does not change existing company and industry certification programs

– Vendors complete an application process to certify products and services against the specifications in an NCOIC Pattern

NCOIC's Certification Authority reviews application for completeness If OK, then the product or service is listed as being certified in the Building

Blocks database

– Architects and designers consult the NCOIC Building Blocks database for NCOIC Certified products and services


The intent of this section is to provide vendors a method to ensure that their products conform to the pattern. It is important that this section is

very specific, without ambiguous or subjective language.This section is the link between Patterns and Building Blocks.

The intent of this section is to provide vendors a method to ensure that their products conform to the pattern. It is important that this section is

very specific, without ambiguous or subjective language.This section is the link between Patterns and Building Blocks.

Net-Centric Pattern VerificationVerification (Required)

– A method to ensure compliance to standards, specifications, and protocols contained in patterns Develop requirements (SHALL/MUST, SHOULD, or MAY

statements, etc.) May use any of the following as the basis of requirements:

– Lines between Actors and Use Cases on Use Case diagrams– Interfaces in DoDAF / MoDAF / NAF / DAF diagrams– SCOPE analysis– NIF Overarching & Specialized Framework Principles

– Requirements are to be expressed for the products or services that implement this pattern


Operational Patterns are unlikely to be VERIFIABLEand thus unlikely to have associated Building Blocks

Operational Patterns are unlikely to be VERIFIABLEand thus unlikely to have associated Building Blocks

Net-Centric Pattern Verification (continued)

Verification (Required)– Use Metrics in requirement statements

Capability Pattern metrics might include:– Business Objectives and/or Measures of Effectiveness (MOE) and/or

Measures of Performance (MOP) Technical Pattern metrics might include:

– MOPs and/or Technical Performance Measurements (TPMs) Metrics shall be must be deterministic and not subjective Metrics shall be verifiable via:

– Analysis (e.g., modeling/simulation)– Test– Demonstration– Inspection


Net-Centric Pattern Verification & Conformance

Verification (Required)

– Identify any interdependencies between metrics(e.g. output power level/RF power vs. bit rate)

– Patterns containing optional extensions must include requirements in this section for those extensions For example, a technical pattern regarding communications may

include an objective bit rate (higher than a threshold or minimum bit rate); Therefore, this pattern would include:

– One requirement statement for the threshold or minimum required bit rate

– A second requirement statement for the objective or higher bit rate


The details in this section contribute to the clarity of the pattern’s intent and guidance

The details in this section contribute to the clarity of the pattern’s intent and guidance

Pattern AppendicesAppendices (optional)

– Identify any supporting material, such as: Details of prior versions Comments from prior reviews that were deferred for future

implementation, e.g.,– Standards known to be in-work, or complete but not yet approved

– New technologies that are currently not mature enough for use at this time (TRL 5 or below)

– Due to legal implications, product liability, political considerations (e.g., inability to obtain export approval)

Indication of planned pattern enhancements deferred into the future


New participants in the NCOIC are often unaware of priordiscussions and often question consensus on issues— need to

DOCUMENT consensus process regarding pattern content!

New participants in the NCOIC are often unaware of priordiscussions and often question consensus on issues— need to

DOCUMENT consensus process regarding pattern content!

Pattern Appendices (continued)

Appendices (optional) (continued)

– Identify any supporting material, such as: Description of conflict resolution between technical factions to

avoid reopening already-resolved issue(s), or discussion of conditions under which the issue(s) should be reexamined

Names of Working Groups, Integrated Project Teams, and individuals that worked jointly on this pattern (if applicable)

Indication of future pattern enhancement Description of issue resolution to avoid repeating topics over

again etc. (anything else that the pattern developers may feel is

supporting material)




– Typical implementation types for this pattern Describe type(s) of typical implementation of the pattern, e.g.:

– Architectural guidance

– Design implementation guidance

– Requirements definition and/or validation/verification guidance

– Procedural guidance

Note that a pattern may incorporate just one, or several, of these categories/types, depending on the pattern: – Operational Patterns: Typically include requirements and procedural

guidance

– Capability Patterns: Typically include architectural and requirements and procedural guidance

– Technical Patterns: Often include architectural and design and requirements guidance




– Validation artifacts/evidence Attach/include evidence documenting what was done to validate the

credibility and completeness of this pattern

The intent of this section is to capture artifacts, test results, reports, briefings, analyses, Subject Matter Expert (SME) recommendations, etc., from the review of this pattern

– Operational patterns: might include a description of how the pattern was derived from a validated Operational Requirements Document (ORD), a commonly accepted Concept of Operations (CONOPS) or a commonly accepted Operational Scenario

– Capability patterns: might include historical evidence of how this capability has been successfully used in operational missions

– Technical patterns: might include description of, or test results from a prototype implementation of the technology in the pattern and field trials or experimentation



Conditions change! Need to keep Net-Centric Patterns current!




– Vision for the future Recommended roadmap for follow-up activities Decision-points for revisiting the pattern

– Update standards and/or guidance

– Replace or retire the pattern

– Formats For Actors, recommend using:

– UML/SysML use case diagram showing actors & use cases of the system, procedure, or operation

– DoDAF / MoDAF / NAF / DAF diagrams: Operational & Capability




– Formats For Structure, recommend using:

– UML class diagram

– SysML block definition diagram

– DoDAF / MoDAF / NAF / DAF diagrams: Systems & Services

– A simple block diagram of components

For Behavior, recommend using:– UML or SysML activity diagram, sequence diagram

– DoDAF / MoDAF / NAF / DAF diagrams: Services & Capabilities

– Flow Diagram of procedural steps


NCOICTM Goal

© copyright 2009 ncoic - all rights reserved approved for public release distribution unlimited...

Documents

interoperable netcentric

netcentric patternspatterns

rights reserved context

rights reserved copyright

netenabled systems copyright

netcentric pattern ncp

centric patternsdefinition

semantic interoperability