1 / 38

Architecture & Lexicon Workgroup

Sense & Respond Logistics (S&RL). Architecture & Lexicon Workgroup. Crystal City Plenary Tuesday, 18 SEP 07 08:40-10:00 Crystal 2 Kendall Young (321) 951-5706o kendall.young@ngc.com Sara Ebrahim (321) 951-6590o sara.ebrahim@ngc.com

tanner
Download Presentation

Architecture & Lexicon Workgroup

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. Sense & Respond Logistics (S&RL) Architecture & Lexicon Workgroup Crystal City Plenary Tuesday, 18 SEP 07 08:40-10:00 Crystal 2 Kendall Young (321) 951-5706o kendall.young@ngc.com Sara Ebrahim (321) 951-6590o sara.ebrahim@ngc.com Paul McGreevy (401) 846-2802o/ paul.mcgreevy@bearingpoint.com Tom Dlugolecki (619) 546-7854o/379-2512m tom.dlugolecki@ncoic.org Approved for Public Release Distribution Unlimited NCOIC-SRL-LEX-2007-09-18

  2. Architecture & Lexicon (A&L) WG – Agenda • Strawman Purpose Deliverable – Why Architecture? • Obstacles addressed by A&L • PFC Introduction • Architecture Inputs to PFC • JDDSP Architecture Rendering – a Draft OD in DoDAF • Purpose Deliverable Discussion & Maturation

  3. Architecture & Lexicon – Promoting Common Understanding (DRAFT) OBJECTIVES (STRATEGIC): • Improved and shared understanding of the Logistics domain among key stakeholders, including customers, operators, suppliers, service providers, designers, and builders. Specific stakeholders to be considered include the DoD, NATO and Federal Agencies. A logistics reference architecture / lexicon will enhance common understanding. SCOPE OF WORK (OPERATIONAL): • Derivation of a logistics domain reference architecture, based upon three or more specific logistics mission domains spanning military, federal, and commercial segments. • Drive towards a common set of architecture artifacts and a lexicon that support multiple logistics domain spaces. • Identify architectural patterns for describing logistics operations and supporting networked systems. • Identify both common and unique logistics attributes across military, federal, & commercial segments. • Support the analysis and selection of standards and technologies to enhance logistics operations. • Align architecture support to address Obstacles to Logistics Interoperability WAY FORWARD (TACTICAL): • Identify candidate logistics mission spaces for analysis & development of Operational Description (OD) • Conduct architectural analysis / leverage SMEs of JDDE (Joint Deployment Distribution Enterprise) • Support PFC Development • Encourage participation of architecture SMEs and builders SUPPORTING FACTS AND CONSIDERATIONS: (Open Format) • Leverage existing frameworks and architecture description languages – DoDAF, MoDAF, NAF, SADT, SysML, UML • Leverage NCOIC FTs products and membership participation – Reqs Valid, NIF, Spec FWs

  4. Architecture & Lexicon – Promoting Common Understanding (9/18/2007) OBJECTIVES (STRATEGIC): • Improved and shared understanding of the Logistics domain among key stakeholders, including customers, operators, suppliers, service providers, designers, builders, and application developers • Specific stakeholders to be considered include the DoD, NATO and Federal Agencies • Logistics Reference Architecture / Lexicon – intended enhance common understanding SCOPE OF WORK (OPERATIONAL): • Derivation of a logistics domain reference architecture & data definitions, based upon three or more specific logistics mission domains spanning military, federal, and commercial segments • Drive towards a common set of architecture artifacts & lexicon to support multiple logistics domains • Identify architectural patterns for describing logistics operations and supporting networked systems • Identify both common and unique logistics attributes across military, federal, & commercial segments • Leverage Stakeholder Outreach WG to establish an Architecture Governance process • Support the analysis and selection of standards and technologies to enhance logistics operations • Align & Assess architecture support to address Obstacles to Logistics Interoperability WAY FORWARD (TACTICAL): • Identify candidate logistics mission spaces for analysis & development of Operational Description (OD) • Conduct architectural analysis / leverage SMEs of JDDE (Joint Deployment Distribution Enterprise) • Support PFC Development • Encourage participation of architecture SMEs and builders • Collaborate with Requirements Validation & NIF FTs SUPPORTING FACTS AND CONSIDERATIONS: (Open Format) • Leverage existing frameworks, architecture description languages, and reference models • DoDAF 1.5, MoDAF, NAF, FEAF, TOGAF, Zachman, SADT, SysML, UML, NCOW RM, KIPs, GIG IA • Leverage NCOIC FTs products & membership – Reqs Valid, NIF, Spec FWs, Lexicon WIKI

  5. Architecture & Lexicon Activities – Overcoming Logistics Interoperability Obstacles • COMPLETE LIST OF S&RL ACTIVITIES / ARCHITECTURE & LEXICON ACTIVITIES • Identify and resolve policy restrictions on sharing information in a multi-level security environment. • Identify those interoperability obstacles to achieving total asset visibility throughout the network. • Determine quality of service parameters for logistics network operation. • Identify core logistics services for a global service description framework to enable interoperability. • Build an end-to-end interoperable network from source of raw material to location of end-user. • Use COTS and GOTS components to meet military logistics operational requirements. • Identify commercial and government RFID standards for secure and complete transmission of item location data. • Open up capability use to go beyond prearranged ownership or delegation of authority relationships. • Initiate dynamic spectrum allocation methods to make efficient use of the spectrum resource limited environment. • Reduce or eliminate redundant data across multiple systems. • Make acquisition procurement cycles match up with technology development cycles. • Implement network hosted business rules for ubiquitous sourcing and lateral re-distribution. • Develop standard baseline information assurance architecture for the logistics domain. • Fully integrate Intelligence, Operations, Logistics and a net centric environment under a single UDOP and portal. • Develop proven practices for mapping existing capabilities to customer needs in a network centric environment. • Develop data formats and standards to support continuously evolving business rules and knowledge links. • Gain agreement on services and service parameters to facilitate the use of service oriented approaches. • Design plug-and-play communications capabilities to enable interoperability across different systems. • Design security guarantees allowing for dynamic identification and levels of trust for casual and regular users. • Ensure configuration management standards and other key documents within the logistics domain. • Identify semantic interoperability obstacles such as using part numbers as universal locators. • Enforce the use of standards across enterprises to enable high levels of collaboration in a DOT_LPF environment. • Define the interoperability needs of both DOD and NATO forces in support of complex humanitarian disasters. • Reduce or eliminate semantic interoperability Unique Item Identifier disconnects in reference terminology. • Develop DoD capability to document, translate, and manage commander’s intent and situational awareness into appropriate logistics actions in an automated process.

  6. Protocol Functional Collection (PFC) - Standards and Design Patterns for Net Centric Logistics Executive Summary • NCOIC Interoperability Framework (NIF) • Interoperability Framework development process & guidelines • Guidance for Building of Standards-Based Interoperable Architectures from multiple COIs • Network Centric Systems for any User Environment • Supports NCO Principles: • Connectivity, Information, Services, Interoperability, Security, Discovery, End-toEnd Development • PFC – Provides Application Guidance the NIF in a given functional domain - Logistics Domain • Architecture provides: • A Basis for Communication and Sared Understanding • Reflective of NIF interoperability guidance • Expresses the Stakeholders’ Vision. • Architecture Process Describes: Common Architecture Reference & Deployment Models • NIFv1: Point-to-Point Systems Interfaces and Networks • PFC Transition to: Service Oriented NIFv2 guidance documents

  7. Protocol Functional Collection (PFC) - Standards and Design Patterns for Net Centric Logistics Foreword • Initial Release of the NCOIC Sense & Respond Logistics PFC • Basic guidance for the functional level of operations in the logistics applications domain. • NIFV1 was the Guiding Document • NCOIC Processes and Tools – applied to Logistics Domain • Guidance for achieving network and system interoperability and collaboration. • Five Tools – Utilized at the appropriate step in the Network Nentric Engineering Process • Customer Requirements Capture; • SCOPE (Systems – Capabilities – Operations – Programs – Enterprises) Analysis; • NIF (NCOIC Interoperability Framework); • NCAT (Network Centric Analysis Tool); • BB (Building Blocks for systems and networks). • Global Logistics Network – Defined by key families of “super-nodes”: • Joint Deployment Distribution Supply Platform (JDDSP) • Mobile Sea Bases • Government Training & Deployment Centers • Global Commercial Distribution Centers

  8. Protocol Functional Collection Introduction - Standards and Design Patterns for Net Centric Logistics Purpose • Provide Guidance to network-centric logistics designers in order to achieve global interoperability. • Two Primary Functions: • Enable architects and engineers to select design patterns, protocols or standards from diverse domains • Align differing system architectures for improved interoperability • Per NIFV1 - PFC is “a collection of protocols that spans some set of the protocol layers and targets a particular functional area. A PFC is a set of protocols chosen from relevant layers that are profiled and described in the context of the Global Aspects that apply to their usage.” • PFCs contain: • A Reference Architecture - How User Applications (UAs) making use of the PFCs for connectivity • An Evaluation of the protocols in the PFC with respect to the Global Aspects • A Catalogue of the specific protocols that make up the PFC. • Ultimate Impact – Effect of Interoperability upon S&RL business rules & operations Scope • Global Net-Centric Logistics Domain within the interoperability framework described in the NIF, to the extent it is released at the time of this PFC publication. • Also currently bounded by the following Operational Descriptions (ODs): • Joint Deployment Distribution Support Platform (JDDSP) • NATO Response Force (NRF) Training and Development Center

  9. Protocol Functional Collection (PFC) - Standards and Design Patterns for Net Centric Logistics • Approach • S&RL Problem Description, • Problem Solutions, including desired properties and capabilities • Enabling technology patterns • Open Protocols and Standards. Interoperability and Business Model Implications are discussed in separate sections also. A nine-step systems engineering implementation process, which forms a basis for the development a successful operational system, is described in Appendix 1. • Planned Hierarchy of PFCs • Functional PFCs - S&RL PFC • Supporting PFCs - Web Services PFC • Sense & Respond Logistics Domain • This PFC is focused on the global commercial and government logistics Community of Interest • Supporting NIF processes / tools identified include: architectural patterns, design patterns, solution patterns (pre-defined constructs), recommendations, methodologies, and policies. • Today, Tightly Coupled …… Tomorrow, Loosely Coupled, Network Enabled • Broad mix of global, joint and coalition, commercial and government, enterprises which must collaborate for success. • Wide set of logistics operational functions including: product development, goods and personnel deployment/distribution, and full lifecycle maintenance and support • Sum of the Operational Descriptions (ODs) and their Concept of Operations describe the “complete definition” of the logistics domain.

  10. Protocol Functional Collection (PFC) - Standards and Design Patterns for Net Centric Logistics • PFC Application –Global WGs to identify obstacles to logistics interoperability • Initiated by DoD, NATO, EDF, Ministries of Defense, & various corporate logistics stakeholders • Understand why interoperability gaps are present • Review legacy network system functions for operational redundancies / needs (design & modification) • Facilitate network transition planning • Total Asset Visibility –a PFC application example • Supports analysis the network of nodes for DoD force deployments & sustainment • Describes how disparate systems can rapidly exchange asset visibility information • Evaluate global aspects: QoS, IA, mobile networking • JDDSP –PFC application • Identify patterns, standards & protocols for IEM (Information Exchange Model) or Service Model • Examples: EDI; Email; Secure or signed email; File transfer protocol; Secure FTP Secure Shell; XML Message Types; Web Services; SOAP; WSDL; RFID Protocols; SQL Data Model; UDDI; SYSML Swedish Design Rules – parallel approaches • Design rules for developing a network based defense C2 system. • Technical System – includes required services, system / security management • Enabling System – includes functions for rapid, cost-effective & evolutionary development • Architecture framework, reference & target architectures, & security architecture are defined • The Design Rules – multiple levels • High-level: describing & achieving interoperability, flexibility, mobility, scalability and security • Lower-level: comprehensive design documentation, including support for requirements, reference & target architectures, infrastructures, frameworks, service descriptions, and operating scenarios

  11. Protocol Functional Collection (PFC) - Section 2 – Architecture Principles and Artifacts • 2Architecture Principles and Artifacts • 2.1Purpose & Relevance of S&RL DoDAF Enterprise Architecture • 2.2Architecture Stakeholders • 2.3S&RL Architecture Team and Roles • 2.4S&RL Operational Bounds • 2.5S&RL Driving Scenarios • 2.6Architecture Issue Definition • 2.7Architecture Artifact Selection • 2.8Tailored Architecture Artifacts • 2.9Architecture Reference Sources • 2.10Architecture Development / Deployment Tools • 2.11Architecture Analyses

  12. Protocol Functional Collection (PFC) - Architecture Principles and Artifacts Purpose & Relevance of S&RL DoDAF Enterprise Architecture • defining a common taxonomy for the S&RL domain, • promoting a common understanding among S&RL stakeholders, • providing architectural rigor to support analysis of S&RL domain issues, • enhancing understanding of S&RL interoperability and net-centricity, and • providing support to the S&RL PFC development. • DoD Architecture Framework (DoDAF) - standardized, integrated set of views, artifacts, data entities, and relationships • Applicable for describing large defense, federal, or commercial enterprises. • Broad pallet of artifacts for describing: enterprise capabilities, strategies, concepts, organizations, processes, information / data / materiel flows, behaviors, systems, platforms, environments, scenarios, functions, roles, & networks • DoDAF development is tied to stakeholder issues which scope the architecture analysis Architecture Artifact Selection • Stakeholder concurrence on issues for analysis • Select & Produce appropriate architecture artifacts • Core Products – AV/OV products (AV-1, 2, OV-1, 2, 3, and 5) for describing the operational problem domain • Additional Products – NCOIC aims to identify commons sets of functionality and standards • SV-4, 5 and TV-1 and 2 • DoDAF V.1.5 – provides explicit support for services (web-based functionality) through the expanded SV-4 and 5 products.

  13. Protocol Functional Collection (PFC) - Architecture Principles and Artifacts • Architecture Stakeholders • S&RL Domain Subject Matter Experts, S&RL PFC developers, network centric logistics designers • Development of useful DoDAF products is dependent upon SME input / review • Architecture plan focused on serving needs and addressing issues of the SMEs and PFC developers • S&RL Architecture Team and Roles • Various NCOIC member companies / organizations to provide DoDAF architects and tools • Architecture leaders: discern stakeholder requirements & plan the architecture work • Any number of architects to execute the evolving architecture plan, building the commensurate DoDAF artifacts, data entities, and relationships and supporting the PFC analysis and development • S&RL Operational Bounds • Manage the scale and scope of the effort • Limited to the JDDSP operational domain as defined by the customer-provided JDDSP artifacts • Time frame for this future architecture is 2008 • Principally located in the Southern California geography • Agreed-upon architecture helps us to counter physical and information security threats to the JDDSP. • S&RL Driving Scenarios • Explored by analyzing a series of S&RL operational scenarios and rendered as OV-6c artifacts • Coordination with S&RL operational SMEs

  14. Protocol Functional Collection (PFC) - Sect 2 – Architecture – OV-1 Example

  15. Purpose of S&RL DoDAF Architecture • DoDAF is the DoD-mandated framework for describing enterprise architectures • Means of defining a common taxonomy for the S&RL domain • Promote a common understanding among S&RL stakeholders • Provide architectural rigor to support analysis of the S&RL domain • Enhance understanding of S&RL interoperability and net-centricity • Support development of the S&RL PFC

  16. DoDAF Introduction – DoD Architecture Framework • DoDAF is a “notation” or “presentation” standard for presenting information on architectures within the DoD. DoDAF supports a disciplined analysis of warfighter communities: their behaviors, operations, structures, information flows, and organizations. • The Department of Defense (DoD) Architecture Framework (DoDAF), Version 1.0, defines a common approach for DoD architecture description development, presentation, and integration for both warfighting operations and business operations and processes. • The Framework is intended to ensure that architecture descriptions can be compared and related across organizational boundaries, including Joint and multinational boundaries. • DoDAF augments traditional Systems Engineering with an integrated set of architecture artifacts.

  17. Source Documentation (Public Domain Information) – JDDSP CONUS Distribution Model Public Domain Information

  18. DoDAF Rendering Approach & Draft Products • Source Document – provided by Tom Dlugolecki • JDDSP CONUS Distribution Model • Approach • Interpreted Source Document – Recast in DoDAF • Gleaned what appeared to be Operational Activities, Nodes and associated hierarchy • Draft Products • Rendered operational views (in Telelogic SA – “Popkin”) • OV-5 Operational Activity Node Trees • OV-2 Operational Connectivity Descriptions (following charts)

  19. DoDAF OV-5 (Draft #1) – Operational Activity Model, Node Tree

  20. DoDAF OV-5 (Draft #2) – Operational Activity Model, Node Tree

  21. DoDAF OV-5 (Draft #3) – Operational Activity Model, Node Tree

  22. DoDAF OV-5 (Draft #4) – Operational Activity Model, Node Tree

  23. DoDAF OV-2 (Draft #1) – Operational Node Connectivity Description

  24. DoDAF OV-2 (Draft #2) – Operational Node Connectivity Description

  25. DoDAF OV-2 (Draft #3) – Operational Node Connectivity Description

  26. DoDAF OV-2 (Draft #4) – Operational Node Connectivity Description

  27. DoDAF OV-2 (Draft #5) – Operational Node Connectivity Description

  28. DoDAF OV-2 (Draft #1 – Functional Groups) – Operational Node Connectivity Description

  29. DoDAF OV-6c – (Participation Invited) – Operational Event Trace Description

  30. DoDAF Architecture – Going Forward • Review / Feedback Required • An interpretation only • Must be informed by the SMEs • Governance is essential • Further JDDSP Development • Other Operational Descriptions (ODs) • Need to explore multiple domains to derive generalized architectural patterns for logistics operations. • These general patterns should support a broad range of PFCs.

  31. Architecture & Lexicon – Promoting Common Understanding (9/18/2007) OBJECTIVES (STRATEGIC): • Improved and shared understanding of the Logistics domain among key stakeholders, including customers, operators, suppliers, service providers, designers, builders, and application developers • Specific stakeholders to be considered include the DoD, NATO and Federal Agencies • Logistics Reference Architecture / Lexicon – intended enhance common understanding SCOPE OF WORK (OPERATIONAL): • Derivation of a logistics domain reference architecture & data definitions, based upon three or more specific logistics mission domains spanning military, federal, and commercial segments • Drive towards a common set of architecture artifacts & lexicon to support multiple logistics domains • Identify architectural patterns for describing logistics operations and supporting networked systems • Identify both common and unique logistics attributes across military, federal, & commercial segments • Leverage Stakeholder Outreach WG to establish an Architecture Governance process • Support the analysis and selection of standards and technologies to enhance logistics operations • Align & Assess architecture support to address Obstacles to Logistics Interoperability WAY FORWARD (TACTICAL): • Identify candidate logistics mission spaces for analysis & development of Operational Description (OD) • Conduct architectural analysis / leverage SMEs of JDDE (Joint Deployment Distribution Enterprise) • Support PFC Development • Encourage participation of architecture SMEs and builders • Collaborate with Requirements Validation & NIF FTs SUPPORTING FACTS AND CONSIDERATIONS: (Open Format) • Leverage existing frameworks, architecture description languages, and reference models • DoDAF 1.5, MoDAF, NAF, FEAF, TOGAF, Zachman, SADT, SysML, UML, NCOW RM, KIPs, GIG IA • Leverage NCOIC FTs products & membership – Reqs Valid, NIF, Spec FWs, Lexicon WIKI

  32. Architecture & Lexicon – (Skeleton Only) Promoting Common Understanding • OBJECTIVES (STRATEGIC): Discuss the value of this workgroup in accomplishing the overall objective: “Reduce Obstacles to Logistics Interoperability.” List 1-3 objectives. • SCOPE OF WORK (OPERATIONAL): Describe in greater detail than above the operational activities that must be completed in order to accomplish objectives. • WAY FORWARD (TACTICAL): List specific tactical level activities that need to be accomplished in order to meet objectives. • SUPPORTING FACTS AND CONSIDERATIONS: Provide any data or other artifacts to clarify your conclusions. Use whatever format suits you best.

  33. Architecture & Lexicon WG – Participation Welcomed Contacts: • Kendall Young (321) 951-5706o kendall.young@ngc.com • Sara Ebrahim (321) 951-6590o sara.ebrahim@ngc.com • Paul McGreevy (401) 846-2802o paul.mcgreevy@bearingpoint.com • Tom Dlugolecki (619) 546-7854o tom.dlugolecki@ncoic.org Venues for Participation: • Twice Weekly Webex hosted by Paul McGreevy & Tom Dlugolecki (Tues./Wed.) • http://www.ncoic.org/ and go to Webex Link Enablers (Not Requirements) • Architecture, Operations, Logistics experience • Access to Telelogic System Architect, Tau, Rhapsody or any modeling tool

  34. Architecture & Lexicon – Attendee Registration

  35. Architecture & Lexicon – Attendee Registration

  36. Activities to Overcome Obstacles to Logistics Interoperability • DO ANY OF THESE ACTIVITIES APPLY TO YOUR WORKGROUP??? • Identify and resolve policy restrictions on sharing information in a multi-level security environment. • Identify those interoperability obstacles to achieving total asset visibility throughout the network. • Determine quality of service parameters for logistics network operation. • Identify core logistics services for a global service description framework to enable interoperability. • Build an end-to-end interoperable network from source of raw material to location of end-user. • Use COTS and GOTS components to meet military logistics operational requirements. • Identify commercial and government RFID standards for secure and complete transmission of item location data. • Open up capability use to go beyond prearranged ownership or delegation of authority relationships. • Initiate dynamic spectrum allocation methods to make efficient use of the spectrum resource limited environment. • Reduce or eliminate redundant data across multiple systems. • Make acquisition procurement cycles match up with technology development cycles. • Implement network hosted business rules for ubiquitous sourcing and lateral re-distribution. • Develop standard baseline information assurance architecture for the logistics domain. • Fully integrate Intelligence, Operations, Logistics and a net centric environment under a single UDOP and portal. • Develop proven practices for mapping existing capabilities to customer needs in a network centric environment. • Develop data formats and standards to support continuously evolving business rules and knowledge links. • Gain agreement on services and service parameters to facilitate the use of service oriented approaches. • Design plug-and-play communications capabilities to enable interoperability across different systems. • Design security guarantees allowing for dynamic identification and levels of trust for casual and regular users. • Ensure configuration management standards and other key documents within the logistics domain. • Identify semantic interoperability obstacles such as using part numbers as universal locators. • Enforce the use of standards across enterprises to enable high levels of collaboration in a DOT_LPF environment. • Define the interoperability needs of both DOD and NATO forces in support of complex humanitarian disasters. • Reduce or eliminate semantic interoperability Unique Item Identifier disconnects in reference terminology. • Develop DoD capability to document, translate, and manage commander’s intent and situational awareness into appropriate logistics actions in an automated process.

  37. Architecture & Lexicon – Promoting Common Understanding (Tom’s original thoughts) OBJECTIVES (STRATEGIC): • Identify the currently used reference architecture for key logistics stakeholders such as DOD, NATO, or other enterprises. Consider the JDDE (Joint Deployment Distribution Enterprise) architecture. SCOPE OF WORK (OPERATIONAL): • Complex network centric logistics systems by their very nature are difficult to communicate to those who wish to understand their value. Common language and common graphical views of these networks enables practitioners to understand and communicate how all these networks assist us. Network centric workgroups are continuously referring back to lexicons and standard views such as DODAF to understand each other. Each application domain has unique attributes which form patterns that can be captured in a lexicon of common terms and a portfolio of common graphics. • During the process of implementing network centric logistics and various interoperability products and processes in the logistics domain, each defining operational description is drawn in architecture and described in text. The accumulation of these operational descriptions such as the JDDSP results in a full picture and description of the operational domain. These communications standards enable productive work to be performed amongst members of the community of interest. This workgroup will help define the baseline for those standards and identify existing or future standards that may be applicable to their work. WAY FORWARD (TACTICAL): SUPPORTING FACTS AND CONSIDERATIONS: (Open Format)

  38. Architecture & Lexicon – Promoting Common Understanding (9/18/2007) OBJECTIVES (STRATEGIC): • Improved and shared understanding of the Logistics domain among key stakeholders, including customers, operators, suppliers, service providers, designers, builders, and application developers • Specific stakeholders to be considered include the DoD, NATO and Federal Agencies • Logistics Reference Architecture / Lexicon – intended enhance common understanding SCOPE OF WORK (OPERATIONAL): • Derivation of a logistics domain reference architecture & data definitions, based upon three or more specific logistics mission domains spanning military, federal, and commercial segments • Drive towards a common set of architecture artifacts & lexicon to support multiple logistics domains • Identify architectural patterns for describing logistics operations and supporting networked systems • Identify both common and unique logistics attributes across military, federal, & commercial segments • Leverage Stakeholder Outreach WG to establish an Architecture Governance process • Support the analysis and selection of standards and technologies to enhance logistics operations • Align & Assess architecture support to address Obstacles to Logistics Interoperability WAY FORWARD (TACTICAL): • Identify candidate logistics mission spaces for analysis & development of Operational Description (OD) • Conduct architectural analysis / leverage SMEs of JDDE (Joint Deployment Distribution Enterprise) • Support PFC Development • Encourage participation of architecture SMEs and builders • Collaborate with Requirements Validation & NIF FTs SUPPORTING FACTS AND CONSIDERATIONS: (Open Format) • Leverage existing frameworks, architecture description languages, and reference models • DoDAF 1.5, MoDAF, NAF, FEAF, TOGAF, Zachman, SADT, SysML, UML, NCOW RM, KIPs, GIG IA • Leverage NCOIC FTs products & membership – Reqs Valid, NIF, Spec FWs, Lexicon WIKI

More Related