Page 1V1.0-2009-02-24

NCOIC Plenary Workshop

February 25, 2009 Ft. Worth, Texas

Practical Guidance for

Net-Centric Pattern Developers

Approved for Public ReleaseDistribution Unlimited

NCOIC-Patt Workshop-FebPlen-20090225

Page 2V1.0-2009-02-24

NCOIC InteroperabilityFramework (NIF™) Overview

The NCOIC Interoperability Framework (NIF) provides resources for System Engineers and Architects who are working oninteroperablenet-centric(or net-enabled)systems

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

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

Page 3V1.0-2009-02-24

Context ofNet-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 specificnet-centric interoperability problems – Patterns are not contained in the NIF, will be stored in an online

Repository in the near future

Only discussing NET-CENTRIC PATTERNS in this workshop,please join the NIF Team for more information about the NIF

Only discussing NET-CENTRIC PATTERNS in this workshop,please join the NIF Team for more information about the NIF

Page 4V1.0-2009-02-24

Definition & Intent ofNet-Centric Patterns

Definition of a Net-Centric Pattern, as per the NCOIC Lexicon: – “A Net-Centric Pattern (NCP) provides expert guidance based

on 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

Page 5V1.0-2009-02-24

Net-Centric Pattern Guidance

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

Page 6V1.0-2009-02-24

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 beclear 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 patternis 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

Page 7V1.0-2009-02-24

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

Page 8V1.0-2009-02-24

Complicated Patterns

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!

NO!

YES!

Page 10V1.0-2009-02-24

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)

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)

Page 11V1.0-2009-02-24

Operational Patterns

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

Page 12V1.0-2009-02-24

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

SERVICECOMPONENT

PROVIDER

“SMART”ROUTER

SERVICECONSUMER

SERVICECOMPONENT

PROVIDER

Page 13V1.0-2009-02-24

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

Page 14V1.0-2009-02-24

Net-Centric Pattern Hierarchy

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”

A Top-Down Approach

Page 15V1.0-2009-02-24

Net-Centric Pattern Hierarchy

Capability Pattern A

Capability Pattern B

Capability Pattern C

Capability Pattern D

Operational Pattern

Technical PatternsA Top-Down Approach

Page 16V1.0-2009-02-24

Pattern Outline

1. Identity

– Pattern Name and Identification

– Aliases

– Date & Version

– Version History

2. Description

– Problem Statement & Context

– Participants

– Pre-Conditions

– Structure

– Behavior

– Post-Conditions

3. Implementation Guidance– Standards– Expert Advice– NIF Overarching &

Specialized Frameworks– Known Uses (optional)– Increased Capability

Potential (optional)– Related Patterns– References (optional)

4. Verification & Conformance

5. Appendices (optional)– Supporting Information– Typical Implementation

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

Page 17V1.0-2009-02-24

NIF NSD-RM Appendix A.1.7Pattern Outline

1. Identity

Pattern Name

Aliases

Type

Category

Date

Version

Version History

2. Purpose

Context

Problem Statement

3. Description Participants Pre-Conditions Structure Behavior Post-Conditions Implementation Known Uses Forces Related Patterns Flexibility References

4. Verification & Conformance

5. Tailoring Specialized Framework Tailoring

COMBINED

COMBINED

MOVED TO APPENDICIES

COMBINED

COMBINED

PROMOTEDTO MAJOR

SECTION

COMBINED INPATTERN NAME

CO

MB

INED

RENAMED “INCREASEDCAPABILITY POTENTIAL”

SPLIT: DEPENDENT& ASSOCIATED

MOVED TO APPENDICIES

MOVED TO APPENDICIES

CONCISE SUMMARY:FULL DETAILS MOVEDTO APPENDICIES

INCLUDED“STANDARDS”

SWAP

All NIF NSD-RM Guidance about Net-Centric Patterns applied– some re-ordering & re-naming

RENAMED “EXPERT GUIDANCE”

SOME“CONSTRAINTS”

MOVED HERE

Page 18V1.0-2009-02-24

Net-Centric Patterns—SIMPLE vs. EASY

IT IS A SIMPLE SPORT– YOU JUST KEEP THE BULL BETWEEN YOU AND THE GROUND…

… YOU WILL SOON FIND OUT THE DIFFERENCE BETWEEN“SIMPLE” AND “EASY”

Page 19V1.0-2009-02-24

Pattern Identity

1. Identity– Pattern Name and Identification

• 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”– Date & Version

• Use NCOIC standard versioning, e.g. V1.1-2009-01-20– 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

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

more than 1 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 1 page, suitable as a cover page.

Page 20V1.0-2009-02-24

Pattern Description

2. Description– Problem Statement & Context

• Describe the problem that the pattern solves within theappropriate context (described next)

• In other words, why is this pattern needed?• 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– 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

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.

Page 21V1.0-2009-02-24

Pattern Description(continued)

2. Description (continued)– Participants

• 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

• 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

Page 22V1.0-2009-02-24

Pattern Description(continued)

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

Use Views & Viewpoints only as Applicable & Useful!

Page 23V1.0-2009-02-24

Pattern Description(continued)

2. Description (continued)

– Participants (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

Page 24V1.0-2009-02-24

Pattern Description(continued)

2. Description (continued)

– 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

Page 25V1.0-2009-02-24

Pattern Description(continued)

2. Description (continued)

– Structure

• 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

Page 26V1.0-2009-02-24

Pattern Description(continued)

2. Description (continued)– 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

Page 27V1.0-2009-02-24

Pattern Description(continued)

2. Description (continued)

– 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

Page 28V1.0-2009-02-24

3. Implementation 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 Stds.

Pattern Implementation Guidance

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.

Page 29V1.0-2009-02-24

Pattern Implementation Guidance(continued)

3. Implementation Guidance (continued)

– Expert Advice

• Describe lessons-learned and best practices that Subject Matter Experts 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)

• Describe constraints and opportunities regarding interoperability

– Strongly recommend doing so via the SCOPE dimensions

Provide flexible guidance,avoid specifications for an implementation

Provide flexible guidance,avoid specifications for an implementation

Page 30V1.0-2009-02-24

Pattern Implementation Guidance(continued)

3. Implementation Guidance (continued) – NIF Overarching and Specialized Frameworks

• Describe guidance relative to NIF Overarching Principles for interoperable, net-enabled systems (see NIF NSD-RM)

• Describe guidance relative to Specialized Framework Principles, e.g.

– Information Assurance

– Mobility

– Semantic Interoperability

– Services

• May include SCOPE analysis, litmus test results, or any other analysis recommended in the specialized frameworks

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

Page 31V1.0-2009-02-24

Pattern Implementation Guidance(continued)

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

Page 32V1.0-2009-02-24

Pattern Implementation Guidance(continued)

3. 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”

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

Page 33V1.0-2009-02-24

Pattern Implementation Guidance(continued)

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

Page 34V1.0-2009-02-24

Pattern Implementation Guidance(continued)

3. Implementation Guidance (continued)

– References (optional)

• Identify any industry-standard documentation, reports, or other materials that designers may find useful in designing missions or systems that incorporate 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

Page 35V1.0-2009-02-24

Net-Centric PatternVerification & Conformance

4. Verification & Conformance (Required)– Interfaces: Identify requirements associated with the people and

systems (shown in the “Participants” section) that INTERFACE with a vendor’s product or service (Building Block) that claims conformance to the pattern

• Develop requirements (SHALL or MUST 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

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.

Page 36V1.0-2009-02-24

Net-Centric PatternVerification & Conformance

4. Verification & Conformance (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 must be must be deterministic and not subjective

• Metrics must be verifiable via:– Analysis (e.g., modeling/simulation)– Test– Demonstration– Inspection

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

Page 37V1.0-2009-02-24

Net-Centric PatternVerification & Conformance

4. Verification & Conformance (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

Page 38V1.0-2009-02-24

Pattern Appendices

5. Appendices (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

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

Page 39V1.0-2009-02-24

Pattern Appendices(continued)

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

• etc. (Anything else that the pattern developers may feel is supporting material)

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

DOCUMENT consensus process regarding pattern content!

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

DOCUMENT consensus process regarding pattern content!

Page 40V1.0-2009-02-24

Pattern Appendices(continued)

5. Appendices (optional - continued)

– 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

Page 41V1.0-2009-02-24

Pattern Appendices(continued)

5. Appendices (optional - continued)

– 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

Page 42V1.0-2009-02-24

Pattern Appendices(continued)

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

Page 43V1.0-2009-02-24

Pattern Appendices(continued)

5. Appendices (optional - continued)

– 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

Page 44V1.0-2009-02-24

NCOIC Goal

Net-EnabledFuture

Stovepiped Systems, Point-to-Point Networks