View
216
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended