1 / 43

Practical Guidance for Net-Centric Pattern Developers

Practical Guidance for Net-Centric Pattern Developers. NCOIC Plenary Workshop February 25, 2009 Ft. Worth, Texas. Approved for Public Release Distribution Unlimited NCOIC-Patt Workshop-FebPlen-20090225. NCOIC Interoperability Framework (NIF™) Overview.

britanni-rogers
Download Presentation

Practical Guidance for Net-Centric Pattern Developers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Practical Guidance forNet-Centric Pattern Developers NCOIC Plenary Workshop February 25, 2009 Ft. Worth, Texas Approved for Public Release Distribution Unlimited NCOIC-Patt Workshop-FebPlen-20090225 V1.0-2009-02-24

  2. NCOIC InteroperabilityFramework (NIF™) Overview • NIF Scope and Problem Statement (NSPS) • Defines the scope of the NIF • Defines the interoperability problem space • Defines top level requirements for interoperability The NCOIC Interoperability Framework(NIF) provides resources for System Engineers and Architects who are working oninteroperablenet-centric(or net-enabled)systems Requirements • 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 Solution & Guide • Specialized Frameworks (SF) • Architectural principles and guidance for focused technical areas critical to interoperability(for example: Information Assurance, Mobility, Semantic Interoperability, Services) Specialization Please join the NIF Team or Specialized Frameworks Team for more information about the NIF and architectural approaches V1.0-2009-02-24

  3. 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 V1.0-2009-02-24

  4. 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 V1.0-2009-02-24

  5. Net-Centric Pattern Guidance • Net-Centric Patterns must guide users away from known problem areas! V1.0-2009-02-24

  6. 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 V1.0-2009-02-24

  7. 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 V1.0-2009-02-24

  8. Complicated Patterns NO! YES! Users of Net-Centric Patterns need Practical and Concise guidance on how to achieve interoperable solutions! V1.0-2009-02-24

  9. 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) V1.0-2009-02-24

  10. 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 V1.0-2009-02-24

  11. 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 SERVICECONSUMER “SMART”ROUTER SERVICECOMPONENTPROVIDER SERVICECOMPONENTPROVIDER V1.0-2009-02-24

  12. Technical Patterns • 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 V1.0-2009-02-24

  13. Net-Centric Pattern Hierarchy A Top-Down Approach 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” V1.0-2009-02-24

  14. Net-Centric Pattern Hierarchy A Top-Down Approach Technical Patterns Capability Pattern A Operational Pattern Capability Pattern B Capability Pattern C Capability Pattern D V1.0-2009-02-24

  15. Pattern Outline • Implementation Guidance • Standards • Expert Advice • NIF Overarching & Specialized Frameworks • Known Uses (optional) • Increased Capability Potential (optional) • Related Patterns • References (optional) • Verification & Conformance • Appendices (optional) • Supporting Information • Typical Implementation Types for this Pattern • Validation Artifacts/Evidence • Vision for the Future • Identity • Pattern Name and Identification • Aliases • Date & Version • Version History • Description • Problem Statement & Context • Participants • Pre-Conditions • Structure • Behavior • Post-Conditions V1.0-2009-02-24

  16. CONCISE SUMMARY: FULL DETAILS MOVEDTO APPENDICIES COMBINED SOME“CONSTRAINTS”MOVED HERE COMBINED COMBINED INPATTERN NAME PROMOTEDTO MAJORSECTION INCLUDED“STANDARDS” RENAMED “EXPERT GUIDANCE” SPLIT: DEPENDENT& ASSOCIATED COMBINED SWAP RENAMED “INCREASEDCAPABILITY POTENTIAL” COMBINED COMBINED MOVED TO APPENDICIES NIF NSD-RM Appendix A.1.7Pattern Outline • Description • Participants • Pre-Conditions • Structure • Behavior • Post-Conditions • Implementation • Known Uses • Forces • Related Patterns • Flexibility • References • Verification & Conformance • Tailoring • Specialized Framework • Tailoring • Identity • Pattern Name • Aliases • Type • Category • Date • Version • Version History • Purpose • Context • Problem Statement MOVED TO APPENDICIES All NIF NSD-RM Guidance about Net-Centric Patterns applied– some re-ordering & re-naming MOVED TO APPENDICIES V1.0-2009-02-24

  17. 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” V1.0-2009-02-24

  18. Pattern Identity • 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, asdifferent 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. V1.0-2009-02-24

  19. Pattern Description • 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. V1.0-2009-02-24

  20. Pattern Description(continued) • 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 V1.0-2009-02-24

  21. 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! V1.0-2009-02-24

  22. Pattern Description(continued) • 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 V1.0-2009-02-24

  23. Pattern Description(continued) • 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 V1.0-2009-02-24

  24. Pattern Description(continued) • 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 V1.0-2009-02-24

  25. Pattern Description(continued) • 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 V1.0-2009-02-24

  26. Pattern Description(continued) • 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 V1.0-2009-02-24

  27. Pattern Implementation Guidance • 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. 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. V1.0-2009-02-24

  28. Pattern Implementation Guidance(continued) • 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 V1.0-2009-02-24

  29. Pattern Implementation Guidance(continued) • 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 FrameworkPrinciples, 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 V1.0-2009-02-24

  30. Pattern Implementation Guidance(continued) • 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 V1.0-2009-02-24

  31. Pattern Implementation Guidance(continued) • 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 V1.0-2009-02-24

  32. Pattern Implementation Guidance(continued) • 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 V1.0-2009-02-24

  33. Pattern Implementation Guidance(continued) • 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 V1.0-2009-02-24

  34. Net-Centric PatternVerification & Conformance • 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. V1.0-2009-02-24

  35. Net-Centric PatternVerification & Conformance • 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 V1.0-2009-02-24

  36. Net-Centric PatternVerification & Conformance • 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 V1.0-2009-02-24

  37. Pattern Appendices • 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 V1.0-2009-02-24

  38. 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) • 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! V1.0-2009-02-24

  39. Pattern Appendices(continued) • 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 V1.0-2009-02-24

  40. Pattern Appendices(continued) • 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 V1.0-2009-02-24

  41. Pattern Appendices(continued) Conditions Change! Need to keep Net-Centric Patterns current! V1.0-2009-02-24

  42. Pattern Appendices(continued) • 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 V1.0-2009-02-24

  43. NCOIC Goal Net-EnabledFuture Stovepiped Systems, Point-to-Point Networks V1.0-2009-02-24

More Related