sdsfie metadata foundation (smf) · 1/31/2019 · retitled and revised the igi&s governance...

Spatial Data Standards for Facilities,

Infrastructure, and Environment (SDSFIE)

Governance Plan

Revision 3 31 January 2019

Prepared By: The Installation Geospatial Information and Services (IGI&S) Governance Group

For: The Assistant Secretary of Defense (Sustainment)

© 2019

31 January 2019 SDSFIE Governance Plan R3

i

THIS PAGE IS INTENTIONALLY BLANK


i

Executive Summary

In accordance with DoD Instruction (DoDI) 8130.01, Installation Geospatial Information and Services (IGI&S), the Assistant Secretary of Defense for Energy, Installations, and Environment (ASD(EI&E)), under the authority, direction, and control of the USD(AT&L), is responsible for developing, managing, and publishing IGI&S standards. DoDI 8130.01 also established the IGI&S governance group (the IGG) to develop coordinated and integrated approaches for IGI&S across the Department. In accordance with the National Defense Authorization Act of Fiscal Year 2017, the USD(AT&L) is now the USD(Acquisition & Sustainment) and the responsibilities of the ASD(EI&E) are now with the ASD(Sustainment). The IGG consists of core members representing ASD(S); the Secretaries of the Military Departments; the Commandant of the Marine Corps; the Director, Washington Headquarters Services; the Commanding General, U.S. Army Corps of Engineers, and the DoD Geospatial Intelligence (GEOINT) Manager (advisory).

This governance plan is intended to define a set of roles, responsibilities and processes that the IGG shall put in place to guide development and usage of the spatial data standards used within the enterprise in order to achieve the goals and objectives defined in the IGG charter and DoD policy. For the purposes of this document, “the enterprise” is the DoD Installations and Environment (I&E) and civil works communities and the spatial data standards in question are those that are intended to support the production, use, and sharing of geospatial information within the enterprise, hereafter known collectively as the Spatial Data Standards for Facilities Infrastructure and Environment (SDSFIE).

This plan defines the SDSFIE as a family of standards, and provides a description of the roles, responsibilities, governance objectives, and related processes that guide the development and use of the SDSFIE within the enterprise. This plan is intended to apply specifically to the EI&E community as well as the US Army Corps of Engineers Civil Works community, and any other DoD organization mandated to use SDSFIE as specified in the DoD IT Standards Registry (DISR). Its applicability for other interested organizations is suggested but not mandatory.

The Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) are a family of IT standards (models, specifications) which define a DoD-wide set of semantics intended to maximize interoperability of geospatial information and services for installation, environment and civil works missions.

The SDSFIE family consists of these parts:

1. SDSFIE Vector (SDSFIE-V): This is the vector data model which prior to 2014 was recognized simply as “SDSFIE”, including versions 2.6, 3.0, 3.1. The latest version, 4.0, is the first to carry the SDSFIE-V part name. SDSFIE-V includes the current SDSFIE Specification Document (DISR cited), as well as the current “Gold ” Logical Data Model and all Component HQ-level Adaptation Logical Data Models . The specification document provides an overview of the 4.0 version of the SDSFIE-V “Gold” logical data model as well as a high level description of how physical implementation and change management are governed and executed.

2. SDSFIE Metadata (SDSFIE-M): SDSFIE-M is a Class-2 profile of ISO 19115 and ISO 19115-2. Extensions to ISO 19115 adopted by DoD via the National System for Geospatial Intelligence (NSG) Metadata Foundation (NMF) are included, as are extensions from the North American Profile of ISO 19115 (NAP). SDSFIE-M will be updated in the future to be a Class 2 profile of the NSG Application Schema 8.0, which includes the models directly profiled which include ISO 19115-1, 19115-2, 19110, and 19157. SDSFIE-M includes the current SDSFIE-M Specification Document (DISR cited), and the SDSFIE-M Implementation Specification (SMIS). SMIS conforms to ISO 19115-3 and encoding rules from ISO 19139.

3. SDSFIE Raster (SDSFIE-R): SDSFIE-R is a guidance document which defines the preferred and recommended raster standards to be used by the IGI&S community. SDSFIE-R and its associated annex - the Raster Standards Compendium (RSC) - include a comprehensive summary of raster and related standards adopted, endorsed, recommended or referenced by the Department of Defense (DoD) via the National System for Geospatial Intelligence (NSG). This standard does not include a


ii

required schema or data model, and therefore is not registered in the DoD IT Standards Registry (DISR).

4. SDSFIE Data Quality (SDSFIE-Q): SDSFIE-Q specifies over-arching guidance for how DoD will implement a tiered approach to quality across the IGI&S community, including data quality processes, measures, and metrics for vector, raster, and geospatial services. This standard does not include a required schema or data model, and therefore is not registered in the DoD IT Standards Registry (DISR).

5. SDSFIE Portrayal (SDSFIE-P): This is a “to be” document (or set of documents) specifying the presentation of geospatial information to humans. These may include map portrayal, symbology, or related encoding specifications.

6. SDSFIE Services (SDSFIE-S): This is a “to be” document (or set of documents) specifying a distinct part of geospatial functionality that is provided by an entity through information technology-based interfaces (for example, web service interfaces).

7. SDSFIE Endorsed Standards (SDSFIE-E): The “to be” collection of consensus specifications, standards, models, and publications pertaining to geospatial information and services developed and managed by organizations other than the IGG, but which are vetted and endorsed by the IGG and are recommended for use across all DoD installation, environment, and civil works missions.

In addition to the definitions above this document defines an implementation support tool, the SDSFIE Online website (section 2.1). Goals and guiding principles for SDSFIE as a whole and for the individual parts are presented in Sections 2.2 through 2.4. The document then describes the governance context for the SDSFIE parts and the roles of individuals and organizations involved in this governance process (sections 3.1 and 3.2). The document then presents governance objectives and the processes used to meet those objectives (sections 3.3 and 3.4). Section 3.4.5 of this revision updates the Adaptation Process, and Section 3.4.7 of this revision incorporates changes to the previous Change Management Process as agreed to by the IGG at their 10 May 2017 meeting (and as implemented in the SDSFIE Automated Process Portal (SDSFIE A/P/P)). The plan concludes with annexes which are essentially standalone documents offering additional information than what could be contained in the main document. The annexes provide: information which clarifies the process diagrams; more detailed processes which are called for in the main document.


iii

Revision History

Description Date Version

Initial Version 13 MAY 2014 Initial Version

Updated entire document to reflect DoDI 8130.01. Updated entire document to reflect the role of the ASD(EI&E). Updated document to reflect current state of all parts, namely SDSFIE-V, -M, -R, and –Q. Updated the Change Management section to:

• Include the concept of changes to parts of type Specification/Model and Document

• Include the concept of Major, Minor, and Corrigendum changes to parts of type Specification/Model (including examples)

• Revise the version creation to account for differences related to the part types Specification/Model and Document, including Major, Minor, and Corrigendum versions

Updated the SDSFIE Online section to reflect the use of the Change Management Process Revised the New Version Process Revised the Adaptation Process Revised the Change Management Process (supersedes the 2011 CMP document)

31 JAN 2017 Revision 1

Refresh of Executive Summary and introductory sections Updated document to reflect current state of all parts, namely SDSFIE-V, -M, -R, and –Q. Revised the Change Management Process as approved by the IGG on 10 MAY 2017. Revised the Adaptation Process as approved by the SDSFIE Governance Group on 9 AUG 2017.

13 SEP 2017 Revision 2

Updated the Executive Summary to reflect OSD level organizational changes. Updated the Introduction to reflect OSD level organizational changes. Changed ASD(EI&E) to ASD(S) when used in present context. Added a new objective (3.3.1.4, Procedures) codifying the use of the IGG standard operating procedures (SOP) document. Revised the Working Groups objective (3.3.1.5) to simplify the charter requirement. Revised the Alignment objective (3.3.2.3) to tie it to a to-be-developed SDSFIE Reference Architecture. Retitled and revised the IGI&S Governance Namespace objective (3.3.3.3, now titled “SDSFIE Artifact Registration”) to reflect the fact the SDSFIE Online and the NSG Registry are where SDSFIE artifacts exist, and that the IGI&S Namespace on the Data Services Environment is no longer active. Revised the Implementation Scorecard objective (3.3.5.5) to include a new status level of Gray. Revised the Adaptation Process (3.4.5) to better reflect the iterative nature of developing an Adaptation (current practice of the IGG). Removed Annex A, “SDSFIE Interoperability Framework,” which will now be an Appendix called “SDSFIE Reference Architecture”. Retitled and provided content for the new Annex A, “SDSFIE Artifact Registration Description”.

31 JAN 2019 Revision 3


iv


v

Table of Contents Executive Summary .................................................................................................................................... i

1 Introduction ...................................................................................................................................... 2 1.1 Purpose and Applicability ....................................................................................................................... 2 1.2 Scope ..................................................................................................................................................... 2 1.3 References ............................................................................................................................................. 2 1.4 Acronyms ............................................................................................................................................... 3 1.5 Document Maintenance ......................................................................................................................... 4

2 Overview of SDSFIE: What and Why .............................................................................................. 4 2.1 SDSFIE Online Definition ....................................................................................................................... 6 2.2 SDSFIE Goals ........................................................................................................................................ 6 2.3 Definition of Interoperability .................................................................................................................... 6 2.4 SDSFIE Guiding Principles .................................................................................................................... 7

2.4.1 SDSFIE Vector Guiding Principles (Mature) ...................................................................................... 7 2.4.2 SDSFIE Metadata Guiding Principles (Mature) ................................................................................. 8 2.4.3 SDSFIE Raster Guiding Principles (Mature) ...................................................................................... 8 2.4.4 SDSFIE Data Quality Guiding Principles (Mature) ............................................................................. 8 2.4.5 SDSFIE Portrayal Guiding Principles (Emerging) .............................................................................. 8 2.4.6 SDSFIE Services Guiding Principles (Emerging) .............................................................................. 8 2.4.7 SDSFIE Endorsed Standards Guiding Principles (Emerging)............................................................ 8 2.4.8 SDSFIE Online Guiding Principles (Emerging) .................................................................................. 9

3 Governance ...................................................................................................................................... 9 3.1 Context ................................................................................................................................................... 9 3.2 Roles and Responsibilities ................................................................................................................... 10

3.2.1 Stakeholder Roles ........................................................................................................................... 10 3.2.2 Role Accountability By Objective ..................................................................................................... 12

3.3 Objectives ............................................................................................................................................ 14 3.3.1 Governance ..................................................................................................................................... 14 3.3.2 Standards Management .................................................................................................................. 15 3.3.3 Documentation ................................................................................................................................ 16 3.3.4 Change Management ...................................................................................................................... 18 3.3.5 Implementation ................................................................................................................................ 21

3.4 Processes ............................................................................................................................................ 25 3.4.1 Document Approval Process ........................................................................................................... 25 3.4.2 IGG Consensus Process ................................................................................................................. 28 3.4.3 Standards Gap Resolution Process ................................................................................................. 29 3.4.4 New Version Processes .................................................................................................................. 32 3.4.5 Adaptation Processes ...................................................................................................................... 37 3.4.6 Implementation Scoring Process ..................................................................................................... 42


vi

3.4.7 Change Management Process (CMP) ............................................................................................. 43 Annex A. SDSFIE Artifact Registration Description.......................................................................... 57

Annex B. BPMN Quick Guide ........................................................................................................... 58


vii

Table of Figures Figure 1: SDSFIE Roles and Relationships ................................................................................................................. 12 Figure 2: Change Processing for a Document Change Request.................................................................................. 18 Figure 3: Change Processing for a Specification/Model Change Request ................................................................... 19 Figure 4: Change Processing for an SDSFIE Online Change Request ........................................................................ 25 Figure 5: Document Approval Process BPMN Diagram ............................................................................................... 27 Figure 6: IGG Consensus Process BPMN Diagram ..................................................................................................... 29 Figure 7: Standards Gap Resolution Process .............................................................................................................. 31 Figure 8 New Version Process BPMN Diagram (Top-Level) ........................................................................................ 33 Figure 9: Gather Requirements Sub-process BPMN Diagram ..................................................................................... 34 Figure 10: Requirements Document Analysis Sub-process BPMN Diagram ............................................................... 35 Figure 11: Develop New Model Sub-process BPMN Diagram ..................................................................................... 36 Figure 12: Subject Matter Expert Modeling Sub-process BPMN Diagram ................................................................... 37 Figure 13: Adaptation Process BPMN Diagram ........................................................................................................... 40 Figure 14: Process Findings Sub Process BPMN Diagram ......................................................................................... 41 Figure 15: Implementation Scoring Process BPMN Diagram ....................................................................................... 42 Figure 16: Top-level CMP Processes BPMN Diagram ................................................................................................. 44 Figure 17: Evaluate Draft CR Sub-process BPMN Diagram ........................................................................................ 45 Figure 18: Technical Feasibility Review Sub-process BPMN Diagram ........................................................................ 49 Figure 19: Policy Review Sub-process BPMN Diagram ............................................................................................... 50 Figure 20: Cost/LOE Review Sub-process BPMN Diagram ......................................................................................... 51 Figure 21: IGG Chair Review Sub-process BPMN Diagram ........................................................................................ 52 Figure 22: Working Group Review Sub-process BPMN Diagram ................................................................................ 54 Figure 23: IGG Vote Sub-process BPMN Diagram ...................................................................................................... 55 Figure 24: Implementation Sub-process BPMN Diagram ............................................................................................. 56


viii

Table of Tables Table 1: Stakeholder Roles .......................................................................................................................................... 10 Table 2: RACI by Objective .......................................................................................................................................... 13 Table 3: Reviewer Roles by Change Type and SDSFIE Part ...................................................................................... 47 Table 4: Cost/LOE Reviewer Roles by Change Type and SDSFIE Part ...................................................................... 50 Table 5: Working Group Assignments by Change Type and SDSFIE Part .................................................................. 52


1

THIS PAGE IS INTENTIONALLY BLANK


2

1 Introduction In accordance with DoD Instruction (DoDI) 8130.01, Installation Geospatial Information and Services (IGI&S), the Assistant Secretary of Defense for Energy, Installations, and Environment (ASD(EI&E)), under the authority, direction, and control of the USD(AT&L), is responsible for developing, managing, and publishing IGI&S standards. DoDI 8130.01 also established the IGI&S governance group (the IGG) to develop coordinated and integrated approaches for IGI&S across the Department. In accordance with the National Defense Authorization Act of Fiscal Year 2017, the USD(AT&L) is now the USD(Acquisition & Sustainment) and the responsibilities of the ASD(EI&E) are now with the ASD(Sustainment). The ASD(S) issued this governance plan to define the Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) as the family of IGI&S standards required by DoDI 8130.01. The IGI&S Governance Group (IGG) shall follow this governance plan1 to guide development and usage of SDSFIE within the enterprise to achieve the goals and objectives defined in DoDI 8130.01 and the IGG charter. For the purposes of this document, “the enterprise” is the DoD Energy, Installations, and Environment (EI&E) and civil works communities and the spatial data standards in question are those intended to support the production, use, and sharing of geospatial information within the enterprise, hereafter known collectively as the SDSFIE.

1.1 Purpose and Applicability The purpose of this SDSFIE Governance Plan is to define the SDSFIE as a family of standards, and to provide a description of the roles, responsibilities, governance objectives, and related processes that guide the development and use of the SDSFIE within the enterprise. This plan is intended to apply specifically to the IGG core voting member organizations, including the US Army Corps of Engineers Civil Works community, and any other DoD organization mandated to use SDSFIE as specified in the DoD IT Standards Registry (DISR). Its applicability for other interested organizations is suggested but not mandatory.

1.2 Scope This document defines all parts of the SDSFIE “family of standards” as well as the IGI&S community’s implementation support tool, the SDSFIE Online website. As a governance mechanism, it also defines goals and guiding principles for SDSFIE as a whole and for each individual part. The document then describes the governance context for the SDSFIE parts and the roles of individuals and organizations involved in this governance process. The document concludes with governance objectives and the processes used to meet those objectives. Section 3.4.5 of this revision updates the Adaptation Process, and Section 3.4.7 of this revision incorporates changes to the previous Change Management Process as agreed to by the IGG at their 10 May 2017 meeting (and as implemented in the SDSFIE Automated Process Portal (SDSFIE A/P/P)).

1.3 References The informative (non-normative) documents listed here are useful to understanding and using this document: DoD Directive 5101.7, “DoD Executive Agent for Information Technology Standards,” May 21, 2004

DoD Directive 8000.01, “Management of the Department of Defense Information Enterprise,” February 10, 2009

DoD Instruction 8320.02, “Sharing Data, Information, and Information Technology (IT) Services in the Department of Defense,” August 5, 2013

1 http://www.webopedia.com/TERM/G/Governance_Plan.html as extracted 16 December, 2013

http://www.webopedia.com/TERM/G/Governance_Plan.html


3

DoD Instruction 8130.01, “Installation Geospatial Information and Services(IGI&S),” April 12, 2015 (as amended)

DoD 8320.2-G, “Guidance for Implementing Net-Centric Data Sharing,” ASD (NII)/DoD CIO, April 12, 2006

SDSFIE Governance Plan, Revision 2, ASD(EI&E), 13 September 2107

1.4 Acronyms AGC Army Geospatial Center ASD(EI&E) Assistant Secretary of Defense for Energy, Installations, and Environment ASD(NII) Assistant Secretary of Defense for Networks & Information Integration ASD(S) BEA

Assistant Secretary of Defense for Sustainment Business Enterprise Architecture

BPMN Business Process Model and Notation CADD Computer Aided Design and Drafting CIO Chief Information Officer CMP Change Management Process COI Community of Interest COR Contracting Officers Representative CR Change Request DCR Draft Change Request DDL Data Definition Language DISDI Defense Installations Spatial Data Infrastructure DISR DoD Information Technology (IT) Standards Registry DoD Department of Defense DoDI Department of Defense Instruction FCR Formal Change Request FoS Family of Standards GEOINT Geospatial Intelligence GIO Geographic Information Officer GIS Geographic Information System GML Geography Markup Language GSIP GEOINT Structure Implementation Profile GWG Geospatial Intelligence Standards Working Group GWG ASMFG GWG Application Schemas and Metadata Focus Group GWG PFG GWG Geographic Portrayal Focus Group GWG GWS FG GWG Geospatial Web Services (GWS) Focus Group HQ Headquarters I&E Installations and Environment IC Intelligence Community IGG IGI&S Governance Group IGI&S Installation Geospatial Information and Services ILO Implementation Level Organization ISO International Standards Organization IT Information technology ITSC Information Technology Standards Committee JESC Joint Enterprise Standards Committee LOE Level of Effort LDM Logical data model NAP North American Profile


4

NAS NSG Application Schema NCGIS National Center for Geospatial Intelligence Standards NGA National Geospatial-Intelligence Agency NMF NSG Metadata Foundation NSG National System for Geospatial Intelligence OGC Open Geospatial Consortium OMB Office of Management and Budget PDF Portable Document Format PIM Platform Independent Model PSM Platform Specific Model RACI Responsible, Approval, Consulted, Informed RAM Responsibility Assignment Matrix RSC Raster Standards Compendium SDSFIE Spatial Data Standards for Facilities, Infrastructure, and Environment SDSFIE A/P/P SDSFIE Automated Process Portal SDSFIE-E SDSFIE Endorsed Standards SDSFIE-M SDSFIE Metadata SDSFIE-P SDSFIE Portrayal SDSFIE-Q SDSFIE Quality SDSFIE-R SDSFIE Raster SDSFIE-S SDSFIE Services SDSFIE-V SDSFIE Vector SMIS SDSFIE-M Implementation Specification SOP Standard Operating Procedures SQL Structured Query Language UML Unified Modeling Language US United States USD(A&S) Under Secretary of Defense for Acquisition and Sustainment USD(AT&L) Under Secretary of Defense for Acquisition, Technology, and Logistics WG Working Group XML eXtensible Markup Language

1.5 Document Maintenance This document will be reviewed periodically (annually) and updated as needed.

This document contains a revision history log. When changes occur, the version number will be updated to the next increment and the date, owner making the change, and change description will be recorded in the revision history log of the document.

2 Overview of SDSFIE: What and Why The Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) are a family of IT standards (models, specifications) which define a DoD-wide set of semantics intended to maximize interoperability of geospatial information and services for installation, environment and civil works missions.


5

The SDSFIE family consists of these parts2:

1. SDSFIE Vector (SDSFIE-V): This is the vector data model which prior to 2014 was recognized simply as “SDSFIE”, including versions 2.6, 3.0, 3.1. The latest version, 4.0, is the first to carry the SDSFIE-V part name. SDSFIE-V includes the current SDSFIE Specification Document (DISR cited), as well as the current “Gold3” Logical Data Model and all Component HQ-level Adaptation Logical Data Models4. The specification document provides an overview of the 4.0 version of the SDSFIE-V “Gold” logical data model as well as a high level description of how physical implementation and change management are governed and executed.

2. SDSFIE Metadata (SDSFIE-M): SDSFIE-M is a Class-2 profile of ISO 19115 and ISO 19115-2. Extensions to ISO 19115 adopted by DoD via the National System for Geospatial Intelligence (NSG) Metadata Foundation (NMF) are included, as are extensions from the North American Profile of ISO 19115 (NAP). SDSFIE-M will be updated in the future to be a Class 2 profile of the NSG Application Schema 8.0, which includes the models directly profiled which include ISO 19115-1, 19115-2, 19110, and 19157. SDSFIE-M includes the current SDSFIE-M Specification Document (DISR cited), and the SDSFIE-M Implementation Specification (SMIS). SMIS conforms to ISO 19115-3 and encoding rules from ISO 19139.

3. SDSFIE Raster (SDSFIE-R): SDSFIE-R is not a traditional IT standard. It is a guidance document which defines the preferred and recommended raster standards to be used by the IGI&S community. SDSFIE-R and its associated annex - the Raster Standards Compendium (RSC) - include a comprehensive summary of raster and related standards adopted, endorsed, recommended or referenced by the Department of Defense (DoD) via the National System for Geospatial Intelligence (NSG). SDSFIE-R contains collection and interchange formats, specifications, and best practices for all forms of raster data (raster maps, raster imagery, elevation, etc.). SDSFIE-R does not include a required schema or data model, and therefore is not registered in the DoD IT Standards Registry (DISR) as a traditional IT standard.

4. SDSFIE Data Quality (SDSFIE-Q): SDSFIE-Q specifies over-arching guidance for how DoD will implement a tiered approach to quality across the IGI&S community, including data quality processes, measures, and metrics for vector, raster, and geospatial services. This standard does not include a required schema or data model, and therefore is not registered in the DoD IT Standards Registry (DISR) as a traditional IT standard would be. Instead, SDSFIE-Q is modeled after the ISO 19157 conceptual model of quality for geographic data (ISO 19157 is a normative reference for several DISR –mandated geospatial standards which are related to the SDSFIE family of standards). SDSFIE-Q defines an IGI&S data quality framework, with enterprise-level and Component-level elements. When implemented together, this model for data quality will ensure IGI&S data and services align with IGI&S mission requirements, conform to DISR mandates, and are understandable, trusted and interoperable in accordance with DoDI 8130.01. SDSFIE-Q includes a formal process for defining measures to assess the quality and completeness of data, as well as the reporting of metrics associated with these data quality measures using the SDSFIE Metadata (SDSFIE-M) standard and other applicable means. Adherence to the data quality guidance and processes in this document are required any time IGI&S data or services are created, updated, maintained, or shared. SDSFIE-Q also includes certain specific data quality processes, measures, and metrics which apply individually to IGI&S vector data (SDSFIE-V), raster data (SDSFIE-R), or services (SDSFIE-S), as the case may be.

2 SDSFIE parts are one of two types: Document (e.g. SDSFIE-R and -Q) or Specification/Model (e.g. SDSFIE-V and -M). 3 The SDSFIE-V Gold Logical Data Model represents the consensus core of SDSFIE-V that the IGG has agreed to support. 4 Compliance of HQ-level Adaptations of SDSFIE-V is determined by Implementation Guidance published with the release of an SDSFIE-V Gold version. Compliance of lower level adaptations of SDSFIE-V are the subject of Component –specific governance. SDSFIE Online can maintain adaptation Logical Data Models as well as Physical Data Models. However, currently the policy is that Gold and Component HQ-level Adaptations are included in the officially maintained version of SDSFIE-V.


6

5. SDSFIE Portrayal (SDSFIE-P): This is a “to be” document (or set of documents) specifying the presentation of geospatial information to humans. These may include map portrayal, symbology, or related encoding specifications.

6. SDSFIE Services (SDSFIE-S): This is a “to be” document (or set of documents) specifying a distinct part of geospatial functionality that is provided by an entity through information technology-based interfaces (for example, web service interfaces).

7. SDSFIE Endorsed Standards (SDSFIE-E): The “to be” collection of consensus specifications, standards, models, and publications pertaining to geospatial information and services developed and managed by organizations other than the IGG, but which are vetted and endorsed by the IGG and are recommended for use across all DoD installation, environment, and civil works missions.

2.1 SDSFIE Online Definition In late 2006, the IGI&S community recognized the importance of investing in a set of enterprise tools to support the implementation of SDSFIE. Furthermore, with the advent of net-centricity, the IGG decided that SDSFIE tools should be web-based. The initial web-based tools and web site was known as www.sdsfie.org; the site has evolved significantly and is now known as SDSFIE Online (http://www.sdsfieonline.org).

SDSFIE Online is a web-centric interface that enables users to access documentation, participate in functionality and utilize tools that support the goals of the SDSFIE family of standards.

2.2 SDSFIE Goals In September, 2006, the board of directors of the Tri-Service Computer Aided Design and Drafting and Geographic Information Systems (CADD/GIS) Center who had managed SDSFIE since its inception ceded control of the standard to a group of leaders representing the installation geospatial information and services (IGI&S) programs from the DoD Components (Army, Navy, Marine Corps, Air Force, Washington Headquarters Service and US Army Corps of Engineers). This group became the DISDI Group, formally established by the Deputy Under Secretary of Defense (Installations & Environment) (DUSD(I&E)) on 21 March, 2007. The DISDI Group established a set of goals and guiding principles for SDSFIE, which were followed from 2006-2013 and served as the foundation for re-engineering the standard from version 2.6 to version 3.0. On 15 May, 2013, the DISDI Group (now the IGI&S Governance Group (IGG)) endorsed the following goals for the SDSFIE family of standards for the period 2013-2018:

1. Advance and maintain SDSFIE in order to achieve interoperability for both data and systems, using accepted industry practices.

2. Promote implementation of SDSFIE DoD-wide.

3. Align SDSFIE with functional business mission requirements and the DoD Business Enterprise Architecture (BEA).

4. Maintain and sustain a coordinated SDSFIE program management process.

5. Educate, train, and support the implementation of SDSFIE within the user community.

2.3 Definition of Interoperability The key element in the definition of SDSFIE and the goals above is the concept of interoperability. The concept of interoperability can have complex contextual meanings, thus the IGG believes it is essential to define interoperability in the context of SDSFIE.

First, for the broader community of organizations and IT users in DoD “Interoperability” is defined as:

The condition achieved among communications-electronics systems or items of communications-electronics equipment when information or services can be exchanged directly and satisfactorily between them and/or their users. The degree of interoperability should be defined when referring to specific cases.

http://www.sdsfie.org/

http://www.sdsfieonline.org/


7

Second, for SDSFIE Vector the more specific definition of interoperability is:

The condition of commonly understood semantics and syntax for exchange of installation location (geospatial) data and services. Information traceability is established from concepts in SDSFIE to their specification in the supporting SDSFIE Registry5, and from there back to appropriate authoritative concept sources (laws, regulations, policies). The SDSFIE Vector standard as a whole seeks to answer the [vector geospatial] information exchange questions of “what do we mean?” (semantics) and “how do we represent it?” (syntax).

As other parts of SDSFIE are developed the IGG will provide specific meanings of interoperability for each, as appropriate.

2.4 SDSFIE Guiding Principles As noted above, during the period 2006-2013 the DISDI Group established goals and guiding principles for SDSFIE. The DISDI Group revised the goals and principles in 2013; these revised guiding principles remain valid today, and guide the creation and maturation of the SDSFIE family of standards. The principles are organized in two tiers6. First are a set of overarching principles (immediately below), followed by part-specific guiding principles.

• The SDSFIE family of standards are the mandatory enterprise spatial data standards for EI&E business missions in accordance with DoD policy. All of the SDSFIE parts are governed by consensus of the IGG (formerly the DISDI Group), as chartered by the ASD(S).

• The SDSFIE family of standards shall be responsive and built to support the official mission requirements and enterprise priorities of the DoD business mission area, including civil works missions.

• The parts of the SDSFIE family of standards which are developed and maintained by the IGG shall not duplicate or overlap with external consensus standards for geospatial data; the IGG shall continuously vet and endorse such standards for use across all DoD installation, environment, and civil works missions.

• SDSFIE artifacts (schemas and code lists, for example) shall reside in a publicly accessible repository as defined and specified by the IGG.

• The SDSFIE family of standards shall be vendor neutral, and shall reside in the public domain to the extent allowed by DoD policy.

2.4.1 SDSFIE Vector Guiding Principles (Mature) On 15 May, 2013, the IGG endorsed the following guiding principles for the SDSFIE Vector Schema for the period 2013-2018:

• SDSFIE-V is the mandatory vector schema standard for I&E business missions in accordance with DoD policy. It is a DISR community standard governed by consensus of the IGG, as chartered by the DUSD (I&E).

• SDSFIE-V shall focus on the vector geospatial representation of features with minimal attributes. To the greatest extent practicable, attributes shall not duplicate those found in authoritative I&E business systems or databases.

5 The SDSFIE Registry is a part of the SDSFIE Online web site that is defined later in this document. It is an ISO 19126 compliant feature concept register (and is exposed via SDSFIE Online as the SDSFIE Data Dictionary). 6 Note that the section headings for each set of guiding principles contains the parenthetical term “Mature” or “”Emerging”. This is meant to indicate to the reader the maturity of the sets of guiding principles.


8

• SDSFIE-V shall provide a data model that is scalable from local or installation mapping up to regional (major command) and national (component or department) level; from local to global.

• SDSFIE-V shall be aligned with the standards of the GEOINT Structure Implementation Profile (GSIP) and harmonized to the extent practicable with the concepts in the NSG Application Schema (NAS).

• SDSFIE-V shall be adaptable to meet the needs of Component users. Adaptation of SDSFIE-V will be governed by Implementation Guidance.

2.4.2 SDSFIE Metadata Guiding Principles (Mature) • SDSFIE-M is the mandatory metadata standard for EI&E business missions in accordance with

DoD policy. It shall be a DISR community standard governed by consensus of the IGG, as chartered by the ASD(S).

• SDSFIE-M shall specify metadata for collections of vector and raster data, for individual vector or raster “layers”, and for individual features7.

2.4.3 SDSFIE Raster Guiding Principles (Mature) • SDSFIE-R shall specify community-driven preferences and recommendations concerning

collection methods and format requirements for all forms of raster data (imagery, elevation, etc.).

• SDSFIE-R shall incorporate Government and industry best practices.

2.4.4 SDSFIE Data Quality Guiding Principles (Mature) • SDSFIE-Q shall provide general guidance toward improved data quality and data quality reporting

at a level applicable to all vector and raster based data, as well as services.

• SDSFIE-Q shall provide a quality framework including processes, measures, and metrics for assessing and reporting the quality and completeness of data.

• SDSFIE-Q shall leverage SDSFIE-M for the reporting of quality and completeness of data through metadata records

• SDSFIE-Q shall define a framework for specifying data content that results in higher quality and more complete data collection.

2.4.5 SDSFIE Portrayal Guiding Principles (Emerging) • SDSFIE-P shall specify the presentation of geospatial information to humans. These may include

map portrayal, symbology, or related encoding specifications.

2.4.6 SDSFIE Services Guiding Principles (Emerging) • SDSFIE-S shall specify geospatial web service interfaces or profiles of standard web service

interfaces.

• SDSFIE-S shall incorporate Government and industry best practices.

2.4.7 SDSFIE Endorsed Standards Guiding Principles (Emerging) • SDSFIE-E shall include specifications, standards, models, and publications pertaining to

geospatial information and services developed and managed by organizations other than the IGG that may have applicability to business stakeholder’s geospatial needs. These external standards

7 The initial version of SDSFIE-M does not standardize feature level metadata; that work is planned as a profile of the initial version.


9

shall be vetted and endorsed by the IGG and made available through SDSFIE Online services where possible8.

2.4.8 SDSFIE Online Guiding Principles (Emerging) • The SDSFIE Online web site shall serve as a shared resource for the EI&E community providing

web-based support to enable DoD and Component business stakeholders to utilize the full set of standards as described in these SDSFIE Guiding Principles.

3 Governance This section of the document defines:

• the context within which SDSFIE governance exists,

• the roles and responsibilities required to execute the governance,

• the objectives which SDSFIE governance should meet and the related measures that indicate levels or progression toward success, and

• the processes which will be used to realize the governance objectives.

3.1 Context SDSFIE exists because it is an appropriate way to manage geospatial data and systems interoperability within the EI&E enterprise, based on the context (or framework) of current DoD policy and guidance. For the purposes of this plan, geospatial data and services standards are considered IT standards. A brief synopsis of the policy and guidance context for SDSFIE is provided, beginning at the DoD information enterprise level then moving through the Geospatial Intelligence (GEOINT) level to the EI&E enterprise level.

It is DoD policy that:

• Information shall be considered a strategic asset to the Department of Defense; it shall be appropriately secured, shared, and made available throughout the information life cycle to any DoD user or mission partner to the maximum extent allowed by law and DoD policy9,

• Uniform IT standards shall be used throughout the Department in a manner that achieves and enhances interoperable and net-centric enabled IT10, and

• Data, information, and IT services are considered enablers of information sharing to the DoD. Data, information, and IT services will be made visible, accessible, understandable, trusted, and interoperable throughout their lifecycles for all authorized users11.

DoD guidance encourages the use of collaborative forums known as communities of interest (COI) to perform activities to implement these key policies and ultimately to increase mission effectiveness across the Department of Defense. The IGG functions as the COI for the IGI&S community and will develop practices which focus all IGI&S capabilities on the EI&E missions defined in DoD policy.

According to DoDI 8130.01, Installation Geospatial Information and Services (IGI&S), the IGG is established by the ASD(EI&E) (now ASD(S)) and functions as a standards consensus body for IGI&S. The IGG develops updates or changes to IGI&S standards, recommends them for approval to the ASD(S), then coordinates and facilitates their implementation. Furthermore, the IGG promotes approved

8 Redistribution of standards documents is not always possible due to legal restrictions. 9 DoDD 8000.01 10 DoDD 5101.7 11 DoDI 8320.02


10

IGI&S standards for validation through the GEOINT Standards Working Group (GWG) and submission to the DoD Intelligence Community Joint Enterprise Standards Committee (JESC) for final approval and inclusion into the enterprise standards baseline, contained in the DoD Information Technology Standards Registry (DISR).

The IGG has these additional responsibilities:

• To establish guidelines needed to reduce duplicate investments, enable interoperability of IGI&S capabilities, and ensure that IGI&S data has the quality necessary for effective enterprise-wide decision making.

• To establish guidelines for IGI&S portfolio management to ensure that existing and future EI&E functional business mission spatial information resources are identified, qualified, catalogued, and made visible and accessible to authorized DoD users by creating and associating metadata, including discovery metadata in accordance with DoDI 8320.02.

• To develop mechanisms to make IGI&S data and metadata visible and accessible (to the maximum extent allowed by law or DoD policy) across the federal data sharing environment (e.g. the Geospatial Platform) in order to meet agency responsibilities in accordance with OMB Circular A-16.

DoDI 8130.01 also defines several key roles with respect to the IGG and IGI&S standards. First, the ASD(S) designates a geospatial information officer (GIO) to chair the IGG and provide the technical support necessary to execute the group’s functions and responsibilities. Second, the Secretary of the Army is responsible for providing technical development, change management, general support, and implementation support for IGI&S standards as a supporting function to the IGG. This role is currently filled by the Army Geospatial Center (AGC) through a support services contract, overseen by the contracting officer’s representative (COR). Together these two roles lead or coordinate virtually all of the many technical, working group, or supporting functions which fulfill the goals and objectives laid out in this plan and further defined in section 3.2.

All of these activities imply the need for a set of data and exchange standards, and governance processes to manage the standards and their implementation.

3.2 Roles and Responsibilities

3.2.1 Stakeholder Roles The roles identified in SDSFIE Governance are as follows:

Table 1: Stakeholder Roles

IGG The IGG is a forum, established by authority of the ASD(S) and serving under the shared direction of the DoD GEOINT Manager, which functions as a consensus standards body for IGI&S and develops updates or changes to IGI&S standards, recommends them for approval, then coordinates and facilitates their implementation. The IGG core members are the ASD(S), U.S. Air Force, U.S. Army, U.S. Army Corps of Engineers, U.S. Marine Corps, U.S. Navy, Washington Headquarters Services, and NGA (advisory).

IGG Chair The individual designated by ASD(S) to chair the IGG.

Component IGG Representative

The individual who represents a core member DoD Component in the IGG.


11

Working Group12 Representative

An individual who represents and is delegated to provide the authoritative input of a Component IGG Representative on a SDSFIE Working Group. A Working Group Representative can be a Contractor.

SDSFIE Contracting Officer’s Representative (SDSFIE COR)

Contracting officer's representative is an individual designated in accordance with subsection 201.602-2 of the Defense Federal Acquisition Regulation Supplement and authorized in writing by the contracting officer to perform specific technical or administrative functions.

SDSFIE Support Contractor The contractor holding the SDSFIE support services contract.

Implementation Level Organization (ILO) User

A DoD Component user that implements one or more of the SDSFIE family of standards.

Other User A user of one or more of the SDSFIE family of standards that does not have a Component IGG Representative.

GEOINT Standards Working Group

The GWG is a National System for Geospatial-Intelligence (NSG) forum that serves the Director, National Geospatial-Intelligence Agency (NGA) and the NGA Chief Information Officer who is the delegated functional manager for GEOINT architecture and standards (GEOINT Manager). The GWG provides the forum for the coordination of GEOINT standards activities on behalf of the DoD GEOINT Manager. The GWG is led and chaired by the NGA's National Center for Geospatial Intelligence Standards (NCGIS). In addition to its designation as an NSG Functional Management forum, the GWG is a Joint Technical Working Group that participates in both the DoD and IC standards governance processes. In the DoD, the GWG votes and manages GEOINT standards lifecycle recommendations reported to the Information Technology Standards Committee (ITSC), the governing group responsible for developing and promoting standards interoperability in support of net-centricity within the Department of Defense (DoD). Approved GEOINT standards are then cited in the DoD Information Technology (IT) Standards Registry (DISR).

The following figure depicts the relationships between these roles in terms of organization, reporting, and communication.

12 A subgroup of the DISDI Group that is created to perform technical work with a particular scope as specified by the DISDI Group.


12

Figure 1: SDSFIE Roles and Relationships

3.2.2 Role Accountability By Objective A responsibility assignment matrix (RAM), also known as RACI matrix, describes the participation by various roles in completing tasks or deliverables for a project or business process13.

RACI is an acronym derived from the four key responsibilities used in this document14:

Responsible (R) - Roles that have a significant responsibility in performing the objective as well as government roles that have responsibility over an objective

Approval (A) – Roles that have review and approval authority. There may be several levels of review in the same objective

Consulted (C) – Roles that collaborate and consult at some point during the process but do not have approval authority

13 Margaria, Tiziana (2010). Leveraging Applications of Formal Methods, Verification, and Validation: 4th International Symposium on Leveraging Applications, Isola 2010, Heraklion, Crete, Greece, October 18–21, 2010, Proceedings, Part 1. Springer. p. 492. ISBN 3-642-16557-5. 14 Note that the set selected for this document is most commonly used for decision-making. The “A” is often used to mean “Accountable”, but, in our case “Approval” is a better choice.


13

Informed (I) – Roles that are socialized concerning the activities or artifacts but do not have approval, review nor consulting responsibilities

The roles defined in section 3.2.1 have responsibilities in the objectives of this governance plan. These responsibilities are expressed in the RACI chart depicted in Table 2.

Objective Sub-objective IG

G

IGG

Cha

ir

Com

pone

nt IG

G

Rep

rese

ntat

ive

Wor

king

Gro

up

Rep

rese

ntat

ive

SDSF

IE C

OR

SDSF

IE S

uppo

rt C

ontr

acto

r

GEO

INT

Stan

dard

s W

orki

ng

Gro

up

ILO

Use

r

Oth

er U

ser

Governance Roles and Responsibilities A R R C C I I I I

Objectives A R R C C I I I I Processes A R R C C I I I I

Procedures A R R C C I Working Groups A R R C C I I I I

Standards Management Requirements A R R C C C I I15 I Resolve Gaps R A R R R R,C R,C I I

Alignment A R R R,C R,C R,C C I I Documentation

Documents and Artifacts A R R R,C R,C R,C C C I Standards Registration A,R R R C C C A I I

IGI&S Governance Namespace R A R R,C R,C R,C C I I Change Management

Technical Changes A R R C R R,C I I I External Standards Changes A,R R R C R R A I I

Retire/Replace a Part of the SDSFIE Family A R R C A, C C C I I Version Creation A R R R,C R,C R,C C C I

Implementation Standards Flexibility A R R C R R,C I I I Versioning Strategy A R R C C C I I I

Implementation Guidance A R R C C C I I I Component Implementation Plans C A R I C C I I I Implementation Status Scorecard C A R I I I I I I

Implementation Support I C R C A R I C C Training R R R C A R I C C

Outreach A R R C R R C C C SDSFIE Online R R R R A R I C I

Table 2: RACI by Objective

15 Standards Requirements from Users must come through Component DISDI Group Representatives


14

3.3 Objectives The objectives of the SDSFIE governance are presented in this section. A set of measurable objectives is the foundation of good governance; therefore, one or more objective measurements are included to show the level of (or progress toward) success.

The objectives are grouped according to five major areas:

• Governance—objectives that relate to the overall governance of SDSFIE, e.g. the structures and processes presented in this document;

• Standards Management—objectives that relate to ensuring that the set of standards within the SDSFIE are managed such that they meet validated user requirements and applicable policy mandates;

• Documentation—objectives that relate to the proper documentation of the SDSFIE family of standards;

• Change Management—objectives that relate to the defined, accountable management of change within the SDSFIE;

• Implementation—objectives that relate to supporting the implementation of the SDSFIE within the I&E community.

Under each major objective are a number of sub-objectives that are presented using the following elements, each answering a question:

Desired Outcome: What is the outcome desired under this sub-objective?

Strategy: How will the sub-objective be realized? What will be done?

Success Measures: How will we know if we have succeeded?

Supporting Processes: What processes will be used to support the sub-objective and to help govern the activity defined under the Strategy?

3.3.1 Governance Ensure that effective SDSFIE governance exists, is followed, and is in alignment with DoD policy and with OMB Circular A-119, Federal Use and Development of Voluntary Standards. SDSFIE governance will be defined by openness, balance of interest, due process, appeals, consensus, and accountability.

3.3.1.1 Roles and Responsibilities Desired Outcome: Understandable and documented roles and responsibilities for SDSFIE Governance.

Strategy: All roles and responsibilities required for the development, implementation, and governance of SDSFIE will be identified, defined, and documented. The roles and responsibilities will be mapped to each of the desired objectives.

Success Measures: List of roles and responsibilities, and mapping of roles to objectives as approved by the IGG. The percentage and status of approved objectives that have roles and responsibilities defined.

Supporting Processes: Document Approval Process, see section 3.4.1. The content mentioned by the success measures will reside in the SDSFIE Governance Plan.

3.3.1.2 Objectives Desired Outcome: Documented, understandable objectives for SDSFIE Governance.

Strategy: All of the objectives of the SDSFIE Governance process will be defined and documented with a desired outcome, strategy, success measures, and supporting processes.


15

Success Measures: List of objectives, as approved by the IGG. The percentage and status of approved objectives that are defined and documented with a desired outcome, strategy, success measures, and supporting processes.

Supporting Processes: Document Approval Process, see section 3.4.1. The content mentioned in the success measures will reside in the SDSFIE Governance Plan.

3.3.1.3 Processes Desired Outcome: Clear, understandable, and repeatable processes that will be used to reach the objectives of SDSFIE governance.

Strategy: Processes will be defined, documented, and implemented to achieve the desired outcomes. Processes will have the characteristics of openness, balance of interest, due process, appeals, and consensus. Each will be defined by a business process (or set of business processes) clearly documented in plain language and in process diagrams expressed in Business Process Model and Notation (BPMN), version 2.0 (i.e. BEA-compliant artifacts).

Success Measures: Set of processes that are defined, approved, implemented, and tracked. The status of each process will be reported.

Supporting Processes: Document Approval Process, see section 3.4.1. The content mentioned in the success measures will reside in the SDSFIE Governance Plan.

3.3.1.4 Procedures Desired Outcome: Clear, understandable, and repeatable procedures that will be used to reach the objectives of SDSFIE governance.

Strategy: Procedures will be defined, documented, and implemented to achieve the desired standards governance outcomes defined in policy and this plan. Procedures will have the characteristics of openness, balance of interest, due process, appeals, and consensus. Each will be clearly documented in plain language, for example in standard operating procedures (SOP) documents.

Success Measures: Set of operating procedures that are defined, approved, implemented, and tracked. The status of each procedure will be reported.

Supporting Processes: IGG Consensus Process, see section 3.4.2. The content mentioned in the success measures will reside in the IGG SOP.

3.3.1.5 Working Groups Desired Outcome: Tiered governance, where expert representatives can contribute by working together on specialized activities and make recommendations to the IGG.

Strategy: Working groups should be created to govern the creation and maintenance of each SDSFIE part, for developing and maintaining this Governance Plan, and for other purposes as decided by the IGG. Working groups can be permanent or temporary depending on the needs of the IGG. Refer to the IGG standard operating procedures (SOP) for the definitions of each WG, including the scope, products, and lifecycle expectation of each. The outcomes generated by each WG shall be documented and reported to the IGG on a quarterly basis.

Success Measures: The percentage of working groups with complete and current descriptions (charters) in the IGG SOP. The percentage of working groups that submit a quarterly status report of outcomes to the IGG shall also be captured.

Supporting Processes: The IGG Consensus Process, see section 3.4.2, should be used to create working groups.

3.3.2 Standards Management Ensure that the SDSFIE family of standards meets the needs of the stakeholder community, conforms with DISR mandates, and otherwise relies upon voluntary, consensus standards from domestic and


16

international organizations (such as the Open Geospatial Consortium (OGC) and the International Standards Organization (ISO)).

3.3.2.1 Requirements Desired Outcome: IGI&S standards requirements are comprehensively known, validated, and met by SDSFIE.

Strategy: Standards requirements are identified and proposed by Component IGG representatives as recommendations to the IGG. If accepted by the IGG, requirements are added to the requirements list. Each addition to the requirement list produces a standards gap (or contributes to an existing standards gap). Each standards gap will be documented along with its supporting requirements.

Success Measures: List of accepted requirements, List of standards gaps and supporting requirements as approved by the IGG. The percentage and status of accepted requirements that have a defined gap and supporting documentation.

Supporting Processes: IGG Consensus Process, see section 3.4.2

3.3.2.2 Resolve Gaps Desired Outcome: Standards gaps are resolved by adjusting the SDSFIE parts.

Strategy: Analysis of requirements related to standards gaps will result in recommendations for a) adding DISR or External Standards to the Endorsed Standards List, b) extending existing SDSFIE parts or c) defining a new SDSFIE part. Each SDSFIE part will have a well-defined set of goals, guiding principles and a definition of the meaning of interoperability to aid in the implementation and management of the standard.

Success Measures: List of SDSFIE parts, including a definition as approved by the IGG. For each part: goals, guiding principles, interoperability definition. The percentage of listed parts completed with the status of each goal, guiding principle, and interoperability.

Supporting Processes: Standards Gap Resolution Process, see section 3.4.3, will generate a recommendation that will be submitted to the IGG Consensus Process, see section 3.4.2.

3.3.2.3 Alignment Desired Outcome: All the parts of SDSFIE align with each other (e.g. versioning, no semantic overlap) and with relevant Endorsed Standards.

Strategy: Alignment of the parts of SDSFIE is accomplished through the development of a Reference Architecture that focuses on the boundaries and interactions between the parts and the set of endorsed standards. Criteria shall be developed that enable objective measurement of the alignment of the parts. Points of interaction between the standards themselves and SDSFIE Online should also be discussed, where appropriate.

Success Measures: The status and percentage completed of the SDSFIE parts that align with criteria in the SDSFIE Reference Architecture, as approved by the IGG.

Supporting Processes: Document Approval Process, see section 3.4.1. The content mentioned in the success measures will reside in an appendix to this document called “SDSFIE Reference Architecture.”

3.3.3 Documentation Ensure that SDSFIE is fully documented and understandable to the stakeholder community.

3.3.3.1 Documents and Artifacts Desired Outcome: The parts of the SDSFIE are thoroughly documented, with the correct set of artifacts and in compliance with applicable requirements. SDSFIE documentation is understandable to stakeholder community.


17

Strategy: All parts of the SDSFIE shall be documented in a manner that is consistent with their scope and content.

Example 1: SDSFIE-V is an adaptable logical data model (LDM) implemented via concrete platform specific models (PSM) and it is maintained using the SDSFIE Registry (an SDSFIE Online component) containing a platform independent model (PIM). Because of this fact, the PIM is documented in a Word or PDF specification document and in the SDSFIE Registry and exported via a Microsoft SQL Server or, simplified, Microsoft Access database. Any particular LDM (such as the Gold LDM) is documented via Excel, UML or GML. Any particular PSM is documented in form appropriate to the platform such as Geodatabase (Workspace) XML. Adaptations are documented in exactly the same way as Gold. The specification document and associated Gold LDM forms should conform to the guidelines of the GWG Application Schemas and Metadata Focus Group (ASMFG) because that is the submission endpoint.

Example 2: SDSFIE-M is a metadata standard and is documented via a Conceptual Schema (UML) in a Word or PDF document and an Implementation Schema (XML Schema) with an accompanying Word or PDF document. Profiles, such as the Feature Level Metadata profile, should be documented in the same way (the implementation schema might differ and be something like SQL DDL). The Conceptual Schema should conform to the guidelines of the GWG Application Schemas and Metadata Focus Group (ASMFG) because that is the submission endpoint. Similarly, the Implementation Schema should conform to the guidelines of the GWG ASMFG because that is the submission endpoint.

Example 3: If one of the SDSFIE parts is a series of policy and best practice recommendations, then it would be documented in simple Word or PDF document form.

Use SDSFIE Online as mechanism for providing documentation, to include training and outreach materials to help ensure stakeholder understanding. Consider the SDSFIE Online as a source of feedback on the understandability of the documentation.

Success Measures: SDSFIE documentation or documentation package per SDSFIE part, as approved by the IGG. The status and percentage completed of new or modified SDSFIE parts documentation. The logging and presentation to IGG of stakeholders that expressed a misunderstanding of any SDSFIE part.

Supporting Processes: Document Approval Process, see section 3.4.1, and New Version Processes, see section 3.4.4.

3.3.3.2 Standards Registration Desired Outcome: Applicable parts of SDSFIE (e.g. those developed exclusively by the IGG and which have a logical data model or schema) are registered in the DoD IT Standards Registry (DISR) or other appropriate mechanisms.

Strategy: After first determining which SDSFIE parts should be acquisition binding (and to whom), the part will be submitted as a change request to the DISR through the GEOINT Standards Working Group and its subordinate focus groups. When new versions of SDSFIE parts are developed the GWG process will also be used to retire previous versions from DISR and replace with the new version at the appropriate time.

Success Measures: The status and percentage of approved new or modified SDSFIE parts successfully added to DISR or other appropriate DoD registries, as recommended to and approved by the IGG.

Supporting Processes: Document Approval Process, see section 3.4.1, and New Version Processes, see section 3.4.4.

3.3.3.3 SDSFIE Artifact Registration Desired Outcome: Schemas, code lists, metadata files, taxonomies, and other artifacts from all parts of SDSFIE are available via an online environment.

Strategy: The IGG shall develop and maintain an SDSFIE artifact registration description that defines the structure for posting artifacts related to each SDSFIE part. Once SDSFIE parts or new versions of those


18

parts are approved by the IGG, all appropriate artifacts will be posted to SDSFIE Online and the NSG Registry as described.

Success Measures: The percentage of artifacts that are posted to SDSFIE Online and the NSG Registry, and the status of those not.

Supporting Processes: No SDSFIE-specific process is required. The IGG Chair will ensure that these tasks are accomplished. The SDSFIE artifact registration description will reside in an annex to this document called “SDSFIE Artifact Registration Description.”

3.3.4 Change Management Ensure that SDSFIE meets IGG requirements through a defined and accountable change management process.

3.3.4.1 Technical Changes Desired Outcome: IGG approved requirements to change SDSFIE parts are addressed.

Strategy: Requests to change SDSFIE parts shall be documented, validated, evaluated, approved, implemented, and closed using a well-defined, orderly process that accounts for policy, technical, and fiscal factors. This process is the SDSFIE Change Management Process (CMP, see section 3.4.7). Decisions to create a new version of a particular standard based on implemented changes are separate from the process for managing change, and is the subject of section 3.3.4.4.

SDSFIE parts are one of two types: Document (e.g. SDSFIE-R and –Q) or Specification/Model (e.g. SDSIFE-V and –M).

The overall process of change varies slightly between each part type. Figure 2 depicts the case for the Document part type; note that approved changes must still be implemented and subsequently approved via the Document Approval Process. Figure 3 depicts the case for the Specification/Model part type; note that approved changes to a Model may also require updates to the Specification and, if so, those changes must be approved via the Document Approval Process.

DocumentChangeRequest

Approved?Change

ManagementProcess

Yes

No

DocumentApprovalProcess

Start

End

Figure 2: Change Processing for a Document Change Request


19

Specification/ModelChangeRequest

Approved?Change

ManagementProcess

Yes

No

DocumentApprovalProcess

Start

End

RequiresSpec

Change?Yes

ImplementModelChange

No

Figure 3: Change Processing for a Specification/Model Change Request

Changes to SDSFIE parts of type Specification/Model are categorized by the level interoperability impact that they have on existing implementations. The categories of change are:

• A Major change re-structures elements within a part in such a way that would significantly change the organization of implementations and/or require a major level of effort to populate the new schema (via migration, for example). Major changes have significant impact on the interoperability of implementations.

• A Minor change is a change that does not significantly change the organization of implementations and require a minor level of effort to populate the new schema (via migration, for example). Minor changes have some impact on the interoperability of implementations.

• A Corrigendum change is used to a) correct technical errors in part such as typos or incorrectly encoded elements, or b) to introduce changes that do not significantly affect interoperability (such as adding optional elements). Corrigendum changes have no (or extremely minor) impact on the interoperability of implementations.

The Implementation Guidance for a part shall contain the criteria for categorization of changes as major, minor, or corrigendum. Examples of changes are:

• Major change examples:

o SDSFIE-V: Splitting an existing entity into multiple entities or merging multiple entities into a new entity

o SDSFIE–M: Changing the structure of container elements (for example, 19115-1 changed the CI_ResponsibleParty element by restructuring it in order to allow more flexible associations of individuals, organizations, and roles requiring restructuring of all existing metadata)

• Minor change examples:

o SDSFIE-V: Adding a required entity that does not duplicate an existing concept; Modifying properties of an existing entity in a way that adversely affects interoperability (for example, changing the default or removing a permissible geometry); Adding a required attribute to an entity; Modifying the properties of an attribute in non-interoperable ways (e.g., changing a data type, adding a constraining enumeration, adding a default value, decreasing the length, changing precision or scale); Changing the properties of an enumeration; Changing the meaning of one or more of the enumerants in an existing enumeration; Changing an existing association


20

o SDSFIE-M: Decreasing the multiplicity of an element; Changing the obligation of an element to mandatory or conditional; Changing the type of an element; Adding a required attribute to an element or changing the meaning of an attribute

• Corrigendum change examples:

o SDSFIE-V: Adding an optional entity that does not duplicate an existing concept; Adding an optional attribute to an entity; Increasing the length of a string data type for an attribute; Adding an enumerant that did not previously exist to an existing enumeration; Adding an optional association that did not previously exist ; Adding an enumeration used by an optional attribute that did not previously exist (where the new enumeration cannot cover the same concept space as an existing enumeration and the optional attribute must not already have existed without the enumeration in the current release); Adding a permissible geometry to an entity

o SDSFIE-M: Adding an optional element that does not duplicate an existing concept; Increasing the multiplicity of an element; Adding an optional attribute to an element that does not duplicate an existing concept

Success Measures: List of change requests, percentage of completion, and related status through to either rejection or implementation and closeout; updates to the CMP as approved by the IGG.

Supporting Processes: Change Management Process, see section 3.4.7.

3.3.4.2 External Standards Changes Desired Outcome: External standards meet SDSFIE requirements to the extent possible, following external standards governance processes.

Strategy: Standards requirements that are best met by changes to external standards should be discussed and agreed in the IGG before being submitted to external standards organizations. In this case, a recommendation should be developed and submitted, for consideration by the IGG, which fully describes the proposed change and how it meets the requirements. Once the recommendation is approved by the IGG, it shall be submitted using the processes of the external standards organization.

Success Measures: Percentage of changes are adopted (or rejected) by external standards organizations.

Supporting Processes: No SDSFIE-specific process is required. However, the IGG Consensus Process, see section 3.4.2, or the Document Approval Process, see section 3.4.1, may be used to decide on the exact documentation to submit to external standards organizations.

3.3.4.3 Retire/Replace an Entire Part of the SDSFIE Family of Standards Desired Outcome: SDSFIE standards requirements are, when necessary, addressed by making scope changes (additions and subtractions) and by retiring SDSFIE parts as appropriate.

Strategy: Standards requirements (usually driven by major mission changes) that lead to major scope changes (either additions to scope or subtractions from scope) or retirements should be discussed and agreed in the IGG. In this case, a recommendation should be developed and submitted by any IGG member organization, for consideration by the IGG as a whole, which fully describes the scope change or retirement and how it meets the requirements.

Success Measures: Percentage of changes are made as required, as recommended to and approved by the IGG.

Supporting Processes: The IGG Consensus Process, see section 3.4.2, will be used to determine the correct changes to make, in terms of scope changes or retirements. Once the scope of additions are decided, the Change Management Process, see section 3.4.7, will be used to process the changes.

3.3.4.4 Version Creation Desired Outcome: The creation of new versions of internal standards is consistent.


21

Strategy: Version of parts of type Document shall be created when a decision to make a new version is made as a result of a change request made via the Change Management Process or a recommendation made via the IGG Consensus Process. The revision is approved via the Document Approval Process. The initial version is simply titled appropriately and subsequent revisions are given the sub title “Revision n”, where n is a number starting at 1. For example, the initial version of SDSFIE Quality will be “SDSFIE Quality (SDSFIE-Q)” and the first revision will be “SDSFIE Quality (SDSFIE-Q), Revision 1”

Versions of parts of type Specification/Model are categorized into three levels depending on the interoperability impact they have on existing implementations and correspond to the change categories provided above. The version categories are:

• A major version is used to collect existing, approved major, minor, and corrigendum changes and should be driven by requirements to implement some significant set of major and minor changes. The scale of changes is in the range of thousands to tens of thousands. The initial version of a major revision has minor (and corrigendum) version set to zero.

• A minor version is used to collect existing, approved minor and corrigendum changes in order to provide a new baseline for implementation and should be driven by requirements to implement some significant set of minor changes. The scale of changes is in the range of hundreds to thousands. The version attribute shall use the Major.Minor version number initially set at 0 and shall be incremented after each minor version (e.g., 4.0 to 4.1).

• A corrigendum version is used to collect existing, approved corrigendum changes in order to provide a baseline for Component Adaptations. The scale of changes is in the range of tens to hundreds. Each corrigendum version will incorporate all corrigendum-level change requests approved since the last version release of SDSFIE-V or SDSFIE-M. The version attribute shall use the complete Major.Minor.Corrigendum version number initially set at 0 and shall be incremented after each corrigendum release (e.g. 4.0 to 4.0.1 or 4.1.2 to 4.1.3).

When the decision to create a new major version is made then the New Version Process (see section 3.4.4) shall be used to create the new version. All existing, approved major, minor and corrigendum changes shall be included in the new major version.

When the decision to create a new minor version is made, all outstanding change requests in the CMP that are not considered by the IGG to be “major” should be processed or adjudicated through to either implementation or rejection. All existing, approved minor and corrigendum changes shall be included in the new minor version.

When the decision to create a new corrigendum version is made, all outstanding change requests in the CMP that are not considered by the IGG to be major or minor should be processed or adjudicated through to either implementation or rejection. All existing, approved corrigendum changes shall be included in the new corrigendum version.

Once a candidate major or minor version is complete, it shall be vetted and approved by the IGG for adoption. Once approved, any specification documentation required by the GEOINT Standards Working Group should also be generated and approved. The development and release of a new version does not automatically trigger the requirement that the new version be implemented; the initial lifecycle state of a new version is “Emerging”. See 3.3.5.2 for more information on the Versioning Lifecycle.

Success Measures: Existence of an appropriate SDSFIE document or documentation package, approved by the IGG.

Supporting Processes: New Version Processes, see section 3.4.4 and the Change Management Process, see section 3.4.7.

3.3.5 Implementation Maximize the timely implementation of SDSFIE across the enterprise.

3.3.5.1 Standards Flexibility Desired Outcome: The allowable implementation flexibility for SDSFIE parts is well governed.


22

Strategy: The IGG shall determine whether flexible implementation of an SDSFIE part should be allowed by the adaptation process. This decision is documented in Implementation Guidance for the part. If adaptation is allowed, then technical rules and guidelines must be developed to ensure that Adaptations retain the interoperability intended for the part. The IGG shall define and implement an adaptation process that ensures thorough, consistent, accountable, and understandable application of the Implementation Guidance. When a new version is created, any Implementation Guidance should be revised as needed. Implementation Guidance shall contain format and content requirements for submissions to the Adaptation Process.

Success Measures: Implementation Guidance exists for all Mandated SDSFIE parts that require such guidance, as approved by the IGG. Implementation Guidance is consistent with the current Mandated version (see 3.3.5.2).

Supporting Processes: Adaptation Process, see section 3.4.5.

3.3.5.2 Versioning Lifecycle Desired Outcome: All SDSFIE parts of type Specification/Model conform to a standard versioning lifecycle. Only one version of each SDSFIE part is “Mandated” at any point in time.

Strategy: All SDSFIE parts of type Specification/Model will have the following lifecycle states:

Emerging

The version is created and approved but it is not yet Mandated. The version is expected to be Mandated within one to two years. Because each case may be unique, implementing organizations should consider the potential compatibility risks and impacts before considering whether to upgrade to an Emerging standard. For example, upgrading to a minor version may involve less risk than to a major version.

Mandated

The version is to be implemented and considered essential for interoperability in the EI&E community as well as conformance with the Business Enterprise Architecture (BEA). The milestones and deadlines for implementation of the Mandated version shall be developed by the IGG and approved by ASD(S) in accordance with DoDI 8130.01. Mandated versions are required to be implemented by new systems or other IGI&S capabilities, although conversion of existing data and systems to the mandated standard shall be governed by the ASD(S) approved milestones.

Retired

A new version is now Mandated. Continued use of the Retired version may be limited by implementation milestones established by the IGG and may require an in-place implementation (migration) plan.

The IGG shall periodically consider versioning of all parts of the SDSFIE of type Specification/Model. If an “Emerging” version of a part exists as well as Implementation Guidance (including adaptation, if applicable) for that version, the IGG shall decide whether or not to change the “Mandated” version. Typically, the decision will consider EI&E mission needs, available resources, and business system impacts. If the decision is to make the “Emerging” standard the “Mandated” version, then the currently “Mandated” version will become “Retired”. The newly Mandated version shall be communicated via SDSFIE Online.

A version of an SDSFIE part is established by ASD(S) memorandum as Mandated. The IGG is responsible for recommending to the ASD(S) a version for Mandate. The recommendation shall include implementation milestones and deadlines, approved Implementation Guidance, and a draft implementation memorandum.

Success Measures: A single, current Mandated version exists for all SDSFIE parts of type Specification/Model, as approved by the IGG.

Supporting Processes: IGG Consensus Process, see section 3.4.2.


23

3.3.5.3 Implementation Guidance Desired Outcome: Appropriate Implementation Guidance exists for all SDSFIE parts of type Specification/Model.

Strategy: The timing of the requirement to implement new versions, any policy and general guidelines for adaptation, all implementation metrics and criteria for meeting status indicators to be used in the implementation scorecard, and any other technical guidance to Components concerning the implementation of a particular SDSFIE part shall be documented in Implementation Guidance.

DoD policy or IGG consensus shall determine whether implementation plans are required from Components. If they are required, then the guidance shall include a specification for the plan and shall indicate the timing of its delivery.

If tools exist on SDSFIE Online (or otherwise) that support implementation of a part, then use of those tools shall also be documented and considered as part of Implementation Guidance. When a new version is created, any Implementation Guidance should be revised as needed.

Success Measures: Implementation Guidance exists for all Mandated SDSFIE parts of type Specification/Model, as approved by the IGG. Supporting Processes: Document Approval Process, see section 3.4.1.

3.3.5.4 Component Implementation Plans Desired Outcome: Implementation plans of IGG members shall be documented when required by Implementation Guidance or in the SDSFIE part itself.

Strategy: Where implementation of an SDSFIE part is dictated by DoD policy and by consensus of the IGG, Components shall develop plans consistent with the specification provided in the Implementation Guidance. Component Implementation Plans will be reviewed and validated by the IGG Chair to ensure they are consistent with DoD policy and IGG guidance or processes.

Success Measures: Component Implementation Plans (where applicable)

Supporting Processes: Document Approval Process, see section 3.4.1.

3.3.5.5 Implementation Scorecard Desired Outcome: The implementation progress status of an SDSFIE part is documented for each Component.

Strategy: In order to achieve the SDSFIE goals for synchronized parts and overall interoperability, an implementation scorecard shall be maintained that tracks the implementation progress of all currently mandated SDSFIE parts for each Component according to the following status indicators:

Green: An implementation plan exists and implementation is complete.

An implementation plan exists and a significant level of implementation progress has been made.

Red: An implementation plan exists but little or no other implementation progress has been made.

Gray: No implementation plan exists; little or no implementation progress has been made.

The Implementation Guidance for each part shall define both the metrics to be reported and the levels of the metrics required to achieve the Red, Yellow and Green status levels. For example, the Green status level definition should clearly state what implementation completion means.

Success Measures: Implementation Guidance complete with metrics exists per SDSFIE part and an annual scorecard is generated that accurately reflects each Component’s status.

Supporting Processes: Implementation Scoring Process, see section 3.4.6.


24

3.3.5.6 Implementation Support Desired Outcome: The implementation of SDSFIE (all parts) is supported for all DoD users to the maximum practical extent.

Strategy: Components’ HQ level IGI&S Programs shall be the first stop for implementation level organization (ILO) users regarding implementation support. Nevertheless, to ensure uniformity and interoperability of SDSFIE data sets, centralized implementation tools and other means of implementation support shall be provided through the SDSFIE support contract. Implementation support to DoD users of SDSFIE Online shall be provided via telephone and email by the SDSFIE Help Desk, as well as via the SDSFIE Online web site. Implementation specific guidance to Component users should be passed along to the appropriate Component support location.

Success Measures: Weekly or Monthly Help Desk Statistics, Up to date SDSFIE Online web site, Up-to-date knowledge of Component implementation support mechanisms and POCs.

Supporting Processes: N/A

3.3.5.7 Training Desired Outcome: Standardized, broadly applicable training support for SDSFIE shall be available to the IGG member organizations.

Strategy: The IGG shall identify common training needs concerning the implementation of SDSFIE parts. The SDSFIE COR shall ensure that identified training resources are developed subject to the availability of resources. Components should strive to ensure that training resources developed within their programs can be tailored to meet common needs, where possible.

Success Measures: Effective training resources are available for all SDSFIE parts. Training activities shall be logged and status reported to IGG.

Supporting Processes: No SDSFIE-specific process is required. The IGG will work together to ensure that proper training is developed and offered.

3.3.5.8 Outreach Desired Outcome: Current information and news about SDSFIE shall be available to the entire user community in a timely fashion.

Strategy: The IGG shall identify communication and news release requirements. The SDSFIE COR shall ensure that identified communications and new items are disseminated via the SDSFIE Online web site, subject to the availability of resources. Components should strive to ensure that communications and news items are released via their internal communication mechanisms, where possible.

Success Measures: Effective communications are developed and released to the implementation community. News items are released in a timely manner to the implementation community. The logging and reporting of outreach activities shall be reported to IGG.

Supporting Processes: No SDSFIE-specific process is required. The IGG will work together to ensure that information and news are communicated.

3.3.5.9 SDSFIE Online Desired Outcome: The technical architecture, roadmap, content, and capability of the SDSFIE Online web site shall meet the requirements of all stakeholders.

Strategy: The IGG shall develop and maintain a requirements process for SDSFIE Online that results in system requirements documentation. The IGG shall participate in the periodic review and approval of an SDSFIE Online technical architecture that meets the requirements of stakeholders. IGG members shall develop and annually update a roadmap that prioritizes and sets forth enhancement goals for SDSFIE Online for the year. SDSFIE Support Contractor should plan and execute enhancement spirals in accordance with the development roadmap to include the detailed design of capabilities. IGG members shall participate in design review of capabilities to ensure that the designs align with the technical


25

architecture and meet the requirements of the stakeholders. IGG members shall participate in regular testing and acceptance to ensure that the as-built capabilities meet the requirements of stakeholders. Individual changes to SDSFIE Online shall be approved by the SDSFIE Online Working Group and reflected in a Change Log on the SDSFIE Online web site. Any change which is considered of a large enough impact by a member of the SDSFIE Online Working Group, may, at the request of an IGG member, be processed as depicted in Figure 4.

SDSFIE OnlineChangeRequest

Approved?Change

ManagementProcess

Yes

No

ImplementWebsite or Tool

ChangeStart

End

Figure 4: Change Processing for an SDSFIE Online Change Request

Success Measures: SDSFIE Online System Requirements Documentation, SDSFIE Online Technical Architecture. SDSFIE Online Enhancement Roadmap. Regular (by spiral or by “capability”) design reviews of upcoming enhancements occur. Regular (by spiral) testing and acceptance of SDSFIE Online enhancement occurs. The logging and reporting of SDSFIE Online change activities shall be reported to IGG.

Supporting Processes: Document Approval Process, see section 3.4.1 and Change Management Process, see section 3.4.7.

3.4 Processes The set of processes that support the objectives are provided in this section.

The processes are documented using Business Process Model and Notation (BPMN)2.0 (as required in section 3.3.1.3 and the annex to this document called “BPMN Quick Guide”). More detailed descriptions can be found at http://www.bpmn.org/. BPMN is very flexible and can result in diagrams that are difficult to understand. The BPMN Method and Style approach16 presents a methodology and style rules to achieve the guiding principle “that the process logic should be described unambiguously, completely, and consistently from the diagram alone”, therefore it was selected for use in this document.

3.4.1 Document Approval Process The Document Approval Process shall be designed to standardize the way that documents are approved by the IGG so that all comments are logged and reported, and that a fair, thorough review is accomplished.

16 BPMN Method and Style, 2nd Edition, with BPMN Implementer's Guide, Bruce Silver, Cody-Cassidy Press, 2011,

http://www.bpmn.org/


26

Process Steps The following steps describe the Document Approval Process which is also depicted in Figure 5:

0. A document is drafted in whatever context makes sense for the document by whomever is the submitter. The context could be, for example, within a working group by a working group chair, within another process such as the New Version Process, or within a Component. The DRAFT Document can be socialized early in the drafting process, if desired. Early socialization is recommended for complex or controversial topics.

1. Once a “solid” draft condition is reached, the document is submitted to the IGG via the IGG Chair for review and comment as a DRAFT. The document shall be submitted with a comment matrix according to the comment matrix template provided by the IGG Chair. A review deadline shall be assigned by the IGG Chair (typically one week, two weeks, or one month depending on the complexity of the document) and communicated to the Component IGG Representatives upon dissemination of the document and comment matrix.

2. The document shall be reviewed by each Component; any comments are placed into a Component-specific instance of the comment matrix. Once the Component review is complete, an email shall be sent to the IGG Chair along with the comment matrix or the statement “No comment”. All comments are then to be sent to the document submitter for comment response. The submitter should first combine all comments into a single matrix. At the time the comments are sent to the submitter, the IGG Chair shall decide if a comment clarification period is needed (this would most often be the case) and the submitter and Component IGG Representatives communicate until the comments are clarified.

3. The IGG Chair shall decide if revision of the DRAFT is required. If a revision is required, the submitter will receive the request for a revision and shall then revise the document and, along the way, respond to all comments with a disposition description, disposition summary code (one of Approved, Partially Approved, Rejected, or Information) and a rationale. Once the Revised DRAFT is submitted along with the Response to Comments, the process returns to step 1. If a revision is not required, then the IGG Chair makes a request for a FINAL DRAFT.

4. Once the submitter has prepared the FINAL DRAFT document it shall be submitted as a FINAL DRAFT to the IGG via the IGG Chair.

5. The IGG Chair shall disseminate the FINAL DRAFT to the Component Representatives and announce a recommendation due date. The due date cannot be set sooner than one week of receiving the FINAL DRAFT. Component Representatives are responsible to make an outcome recommendation based on the review of the FINAL DRAFT. This recommendation can be submitted either electronically (email) or in-person. If the recommendation is electronic the IGG Chair shall stipulate the time period during which recommendations can be accepted. Component Representatives shall recommend Approve, Reject or Abstain. A recommendation of Reject shall be accompanied by a statement of the reasons for the rejection. Any Component that does not make a recommendation in the time period given by the IGG Chair is assigned a recommendation of Abstain. The IGG Chair shall evaluate all of the recommendations and determine the overall consensus group recommendation. If significant reservations exist that resulted in Reject recommendations, the IGG Chair must recommend Reject.

Trigger The Document Approval Process is triggered at Step 1, when the document is submitted to the IGG Chair.

Deliverables An Approved or Rejected Document


27

Figure 5: Document Approval Process BPMN Diagram


28

3.4.2 IGG Consensus Process The IGG Consensus process shall be designed to methodically document and reach consensus on a recommendation. Recommendations can take many forms, but are typically written or have written supporting materials. Example recommendations include 1) adoption of an output from the Standards Gap Resolution Process, b) creation of a new version, or c) approval of an Adaptation submitted by a Component.

Process Steps 1. Once a recommendation is submitted, it is subjected to a policy review conducted by the IGG

Chair who shall identify any violation of policy that might occur on approval of the recommendation.

a. If the recommendation fails the policy review, a revision request is sent to the submitter along with a reason for the revision. Once the submitter decides to resubmit the revised recommendation, the process returns to step 1.

b. If the recommendation passes policy review, then the IGG Chair communicates the recommendation to the Component IGG Representatives and the process continues with the next step.

2. Each Component IGG Representative shall review the recommendation and make an approval recommendation. Recommendations to reject shall be accompanied by a reason for the rejection.

3. The IGG Chair will collate the results and determine whether to approve, reject, or ask the submitter for a revision to the recommendation.

a. If the determination is to ask for a revision, the submitter is sent a revision request. Once the submitter decides to resubmit the revised recommendation, the process returns to step 1.

b. If the determination is to reject, a rejection notice is sent to the submitter along with a reason for the rejection; the recommendation is considered rejected and the process is completed17.

c. If the determination is to approve, then the submitter is notified of the approval and the process is completed.

Trigger A recommendation is submitted.

Deliverables An approved or rejected recommendation.

17 The submitter has the option, outside of this process, of appealing the rejection to the Functional Business Governance Board, resubmitting a new recommendation, or doing nothing further.


29

Figure 6: IGG Consensus Process BPMN Diagram

3.4.3 Standards Gap Resolution Process The Standards Gap Resolution Process shall be designed to get from a requirement or set of requirements that identify a standards gap to a recommendation that resolves the gap.

Process Steps 1. When a standards gap resolution requirement is submitted to the IGG Chair, the current DISR

baseline is analyzed for standards that may address the requirement.

a. If a standard is found in the DISR that is deemed to address the requirement, then a recommendation is created to add the standard to the Endorsed Standards List. The process is completed with the gap resolved.


30

b. If a standard is not found in the DISR that addresses the requirement, then the process continues.

2. The work of external standards organizations is considered and their existing standards and work plans are analyzed to determine if there is existing standardization activity that will address the requirement.

a. If a standard is found in external standards organizations that is deemed to address the requirement, then a recommendation is created. If the work is already completed, then the recommendation would be to add the standard to the Endorsed Standards List. If the work is ongoing, then a recommendation can be made to wait or participate in the activity to ensure that the output(s) of the standardization activity meet the requirement. The process is completed with the gap resolved.

b. If a standard is not found in external standards organizations that addresses the requirement, then the process continues.

3. Existing SDSFIE parts are analyzed to determine if an existing SDSFIE part can be extended to meet the requirement.

a. If the determination is that a part extension is feasible and will meet the requirement, then a recommendation is made to extend the scope of the part. If that recommendation is approved and the work is assigned, then the process is completed with the gap resolved. If, at some time in the future, the work is either not completed or fails to fully meet the requirement, then the requirement can be resubmitted to the IGG Chair.

b. If the determination is that a part extension is not feasible or that such an extension will meet the requirement, then the process continues.

4. A recommendation is made to create a new part. If that recommendation is approved and the work is assigned, then the process is completed with the gap resolved. If, at some time in the future, the work is either not completed or fails to fully meet the requirement, then the requirement can be resubmitted to the IGG Chair.

Trigger A standards gap resolution requirement is submitted to the IGG Chair.

Deliverables A recommendation for resolving the gap.


31

Figure 7: Standards Gap Resolution Process


32

3.4.4 New Version Processes The New Version Process defines the sequence of actions or steps for creating a new major or minor version. This process is relatively complex and has embedded sub-processes, therefore it is presented hierarchically.

Top-Level Process Steps 1. The New Version Process starts when a decision to create a new version is made and this

decision is communicated to the SDSFIE Support Contractor. Two parallel processes start immediately:

a. The Gather Requirements sub-process is used to gather the requirements for the new version (in terms of additions, deletions, and changes to model elements). The Gather Requirements sub-process is described below. Requirements gathering requires interaction with the Component IGG Representatives.

b. The Change Management Process (see section 3.4.7) is used to process all outstanding model requests.

2. Because SDSFIE is a multi-part family of standards, the potential for alignment issues exists. The second activity in the process is to determine potential alignment impacts so that they can be mitigated in the development of the new version.

3. The third sub-process is to develop the new model. The Develop New Model sub-process is described below (Sect. 3.4.4.3). The new model is submitted as a recommendation for approval via the IGG Consensus Process. If revisions to the model are required prior to approval, then the required revisions must be described and conditional IGG approval may be given pending completion of the revisions.

4. Once the new model is developed a specification document can be created (in the case of a first version) or modified (in the case of a revision to a version). The format and content outline of the specification document is determined by interaction between the SDSFIE Support Contractor, the IGG Chair, and the relevant GWG focus group Chair and is subject to the approval of the IGG. The specification document is approved by the IGG as an input to the Document Approval Process.

5. Once the specification document is completed, a package can be prepared for submission to the GWG for insertion into the DISR via the GWG’s DISR change request process. Note that independent of the outcome of the GWG process, the creation of the package for DISR is desirable because it bundles all necessary artifacts for dissemination. At this point the New Version Process is complete.

Trigger IGG decision to make a new version.

Deliverables A new version.


33

Figure 8 New Version Process BPMN Diagram (Top-Level)


34

3.4.4.1 Gather Requirements Sub-process The Gather Requirements sub-process is designed to obtain an understanding of all requirements for a new version. The requirements being gathered shall, in the end, represent requirements for addition, deletion, or modification of mode elements.

Gather Requirements Process Steps 1. Requirements are gathered from three sources, each with a slightly different focus:

a. Component Requirements are those solicited from Components directly via a request and a response and then integrated to form the set of Component requirements (note that requirements embodied in the previous version adaptations need not be supplied by this means as they are considered in c) below;

b. Requirements Documents are those that are extracted via analysis of policies (instructions and directives), guidance, manuals, best practices, and other documentation (see section 3.4.4.2 for details of the Requirements Document Analysis sub-process); and

c. Adaptation requirements are extracted from an analysis of previous version adaptations.

2. Once all requirements have been gathers from these sources, they are collated in a form that can be used in later activities. At this point the sub-process is considered complete.

Figure 9: Gather Requirements Sub-process BPMN Diagram


35

3.4.4.2 Requirements Document Analysis Sub-process The Requirements Document Analysis sub-process is designed to obtain an understanding of all requirements for a new version. Note that it is possible that this process can be executed within a Component or at the IGG level.

Requirements Document Analysis Sub-process Steps 1. The Requirements Document Analysis sub-process begins with a request to the Components for

new or updated requirements documents, which is followed by a response. The list of new or updated requirements documents are analyzed in parallel to:

a. Determine if new elements are required. If there are new elements required, then the requirements document is registered as such in the Registry and then the process ends. (Note that the new element requirement is carried forward to the Gather Requirements process where it is collated in the new activity) If there are not new elements required, then the process ends.

b. Determine if there is impact on existing elements. If existing elements are impacted, then the elements are updated in the registry with the new requirements document(s) and the new requirements document(s) are added to the registry and then the process ends. If existing elements are not impacted, then the process ends.

Figure 10: Requirements Document Analysis Sub-process BPMN Diagram

3.4.4.3 Develop New Model Sub-process The Develop New Model sub-process is designed to obtain an understanding of all requirements for a new version.


36

Develop New Model Sub-process Steps 1. The approved change requests from the Change Management Process are implemented (this is

actually the last step in the CMP, but it is shown here to depict the linkage between the two processes.

2. The subject matter expert modeling sub-process is invoked next for each subject matter expert group.

3. Finally, the subject matter expert group models are integrated to develop the complete model.

Figure 11: Develop New Model Sub-process BPMN Diagram

3.4.4.4 Subject Matter Expert Modeling Sub-process The Subject Matter Expert Modeling sub-process is designed to obtain a new model for a subject matter area for a new version.

Subject Matter Expert Modeling Sub-process Steps 1. A draft model for a subject matter area is developed to start the process. This model is

represented as new model elements, changes to existing model elements, and deletion of model elements. Issues and decisions concerning the model are also raised for consideration by subject matter experts. All of this information is sent to subject matter experts and responses are received.

2. An updated model is created on the basis of the comments.

3. A subject matter expert meeting is held to address any remaining issues and concerns. If needed, additional meetings are held until all issues and concerns are addressed.

4. The model is updated with all of the outcomes of the subject matter expert meetings and the process ends.


37

Figure 12: Subject Matter Expert Modeling Sub-process BPMN Diagram

3.4.5 Adaptation Processes The Adaptation Process has been designed to standardize the way that Adaptations are approved by the IGG so that all comments are addressed and a fair, thorough review is accomplished. At the request of an IGG Principal member, the IGG Chair may adjust steps within the Adaptation Process as long as the intent of the process is maintained and IGG members concur. All variances to this process will be documented and justified by the requesting Component, and presented to the IGG for consideration.

Process Steps The following steps describe the Adaptation Process (also depicted in Figure 13 and Figure 14):

1. An Adaptation is developed by the Component. The Adaptation shall, at the time it is submitted, align with all currently approved CRs which apply to the basis model for the Adaptation. Align means that the Adaptation does not contain any conflict with an approved CR.

2. Once an Adaptation has been created by a Component, the Adaptation and supporting documentation18 is submitted by an Adaptation Submitter to the IGG via the IGG Chair. In the case of SDSFIE-V, if the Adaptation does not already exist in the SDSFIE Registry (e.g. because it was developed there using online tools), then the SDSFIE Support Contractor will ingest the Adaptation into the Registry from the Adaptation Submission Workbook format as required by the SDSFIE-V Implementation Guidance.

3. The Adaptation undergoes technical review by the SDSFIE Support Contractor. This technical review shall ensure that the Adaptation conforms to the Implementation Guidance for the part. If the Adaptation does not conform, then each non-conforming “finding” must be made available to

18 The adaptation and supporting documentation requirements are defined in the Implementation Guidance for each SDSFIE part that allows for adaptation.


38

the Chair and the submitting Component for discussion. This discussion includes the Chair (or Chair’s representative), the SDSFIE Support Contractor, and the Adaptation Submitter. The goal of this discussion is to develop a set of recommendations, one for each finding. Each recommendation can be one of two forms, either 1) a recommendation for Adaptation revision made by the SDSFIE Support Contractor to the Adaptation Submitter or 2) a recommendation for the submission of a Change Management Process (CMP) change by the Adaptation Submitter.

4. All findings of type 1) are sent to the Adaptation Submitter for use in developing a next draft of the Adaptation. All findings of type 2) must be submitted into the CMP for adjudication. Within the CMP there are three possible outcomes for each change, a) the change is accepted, b) the change is rejected, or c) an exception is granted. An exception is defined as a recommendation by the IGG Chair that the finding be excluded from the requirement to follow the Implementation Guidance. Exceptions can, potentially, impact interoperability and are therefore subject to the same scrutiny as other changes via the CMP. Exceptions can be recommended to the IGG Chair, or by the IGG Chair, at any time in the process of resolving findings, including during the development of recommendations or at any point in the CMP prior to Working Group Review.

All rejected changes (without exception) shall require an Adaptation revision. All changes that are accepted or receive an exception shall require addition of justification language19 into the Adaptation. Any new revisions and the requirements for element justification are sent to the Adaptation Submitter for use in developing a next draft of the Adaptation. The Adaptation Submitter shall revise their Adaptation according to the revision and requirements for element justification and return back to the IGG Chair. In the case of SDSFIE-V, the Registry shall be updated either by the Adaptation Submitter or the SDSFIE Support Contractor.

During the initial technical review step, continue to A, else continue to B.

A. The process continues until all findings have been addressed and the Adaptation passes the technical review. At the point that the Adaptation passes the technical review, the SDSFIE Support Contractor prepares the Adaptation and any supporting documentation for dissemination and forwards to the IGG Chair.

The SDSFIE Contractor shall prepare a DRAFT corrigendum release that contains all corrigendum level changes approved at the time of the Adaptation dissemination and shall forward to the IGG Chair.

The format of the dissemination shall be conducive to the efficient processing of comments. For example, an SDSFIE-V Adaptation shall be disseminated as an element sheet with comment columns.

Continue to Step 5.

B. The process continues until all findings have been addressed. The SDSFIE Support Contractor prepares the FINAL DRAFT Adaptation and any supporting documentation for dissemination and forwards to the IGG Chair.

The SDSFIE Contractor shall prepare a FINAL DRAFT corrigendum release that contains all corrigendum level changes approved at the time of the Adaptation dissemination and shall forward to the IGG Chair.

Continue to Step 7.

5. The IGG Chair will disseminate the DRAFT Adaptation, DRAFT corrigendum release, and supporting documentation to the Component IGG Representatives. A review deadline is

19 A reference to the Accepted or Rejected (with exception) Change by Formal Change Request and Change identifier should be included in the justification. See Rule 4-10 in SDSFIE-V Implementation Guidance for more details.


39

assigned by the IGG Chair (typically one month) and communicated to the Component IGG Representatives.

6. The Adaptation is reviewed by each Component; any comments are placed into a Component-specific instance of the comment matrix. Once the Component review is complete, an email is sent to the IGG Chair along with the comment matrix or the statement “No comment”. All comments are then adjudicated by the IGG Chair, the SDSFIE Support Contractor, and the Adaptation Submitter. For each comment there are three possible outcomes 1) a recommendation for Adaptation revision made by the SDSFIE Support Contractor to the Adaptation Submitter, 2) a recommendation for the submission of a Change Management Process (CMP) change by the Adaptation Submitter, or 3) no action required. If there are outcomes of type 1 or type 2, the process returns to step 4.

7. The IGG Chair will disseminate the FINAL DRAFT to the Component Representatives and will announce a recommendation due date. The due date cannot be set sooner than one week of receiving the FINAL DRAFT. Component Representatives are responsible to make an outcome recommendation based on the review of the FINAL DRAFT. This recommendation can be submitted either electronically (email) or in-person. If the recommendation is electronic the IGG Chair must stipulate the time period during which recommendations will be accepted. Component Representatives may recommend Approve, Reject or Abstain. A recommendation of Reject must be accompanied by a statement of the reasons for the rejection. Any Component that does not make a recommendation in the time period given by the IGG Chair is assigned a recommendation of Abstain. The IGG Chair will evaluate all of the recommendations and determine the overall outcome recommendation. If significant reservations exist that resulted in Reject recommendations, the IGG Chair must recommend Reject.

8. Once the Adaptation achieves the approved status, the SDSFIE Support Contractor shall then finalize and publish the Adaptation on SDSFIE Online.

Trigger The Adaptation Process is triggered at Step 1, when an Adaptation is submitted to the IGG Chair.

Deliverables An approved Adaptation.


40

Figure 13: Adaptation Process BPMN Diagram

Ada

ptat

ion

Proc

ess

SDSF

IE S

uppo

rt C

ontr

acto

rCo

mpo

nent

IGG

Rep

rese

ntat

ives

IGG

Cha

ir

Ada

ptat

ion

Subm

itte

r

Disseminate Draftand CommunicateReview Deadline

ReviewDeadline

Review and Comment

ReviewDeadline

Comments?

Disseminate Final Draftand Communicate

Recommendation DueDate

for eachComponent

RecommendationDeadline

Review Final Draft

RecommendationDeadline

ReceiveRecommendations

and Make FinalRecommendation

Recommend Outcome

for eachComponent

for eachComponent

Recommendation?

Approved

Rejected

Perform TechnicalReview Adaptation

PassesReview?

Publish Model

DRAFTAdaptation

Received

Process Findings - A(Technical Review)

Receive RevisedDRAFT Adaptation

Send REJECTED

Send APPROVED andRequest for Finalized

Adaptation

Create Adaptation inRegistry

AdaptationAlready InRegistry?

Update Adaptationand Corrigendum In

Registry

Process Finding - B(Comments)

Update Adaptationand Corrigendum in

Registry

Finalize Adaptationand Corrigendum

DRAFTAdaptation

Rejected

Status"Rejected"

No

Yes

Revised DRAFTAdaptation andResponse toComments

Yes

Approved

Yes

No

Status"Approved"


41

Figure 14: Process Findings Sub Process BPMN Diagram


42

3.4.6 Implementation Scoring Process The Implementation Scoring Process shall be designed as an I&E community-wide implementation scorecard based on a synthesis of individual Component implementation scorecards.

Process Steps 1. Annually, on the start date set forth by the IGG, the IGG Chair will prepare implementation

scoring guidance that details the format and content of that years’ implementation scorecard report. The guidance will indicate which SDSFIE parts, having appropriate implementation scoring metrics, are to be included in the scorecard.

2. A request will then be made to each component to provide their implementation scoring according to the guidance.

3. Each Component will prepare their implementation scorecard according to the guidance and will provide the scorecard to the IGG Chair. The Chair shall provide and review all scorecards with the IGG before release to any other governance body.

4. The IGG Chair will synthesize the scorecards to create a Community Scorecard and will send the scorecard to the ASD(S).

Trigger Annual implementation scoring requirement

Deliverables Consolidated Implementation Scoring Report

Figure 15: Implementation Scoring Process BPMN Diagram


43

3.4.7 Change Management Process (CMP) The Change Management Process (CMP) is actually a series of related processes for managing change in the SDSFIE parts and the SDSFIE Online web site. It may continue to be expanded to include other change management needs within the SDSFIE parts as necessary.

All changes are handled via the processing of a Change Request (CR). Any number of Changes can be included in a Change Request. As presented in sections 3.3.4.1 and 3.3.5.9, there are three types of Change Request:

• Document—a CR related to an SDSFIE part of type Document,

• Specification/Model—a CR related to an SDSFIE part of type Specification/Model, or

• SDSFIE Online—a CR related to SDSFIE Online content or tools.

Figure 16 depicts the following top-level processes that make up the CMP:

Component Draft Change Request: Within any Component, users may draft and submit change requests by identifying a set of potential Changes and then develop a Draft Change Request (DCR). Once complete, the DCR is submitted where it awaits adjudication by the Component as a Draft Final CR. Components may decide to disallow DCRs and choose other methods of developing candidate CRs from within their ranks and, in this case, Component Implementation Guidance should describe the process to be used.

Component Formal Change Request: Within any Component, the IGG Representative or assignees, may a) evaluate a Draft Final CR with the potential to draft and submit some or all of the contained Changes as an FCR and/or b) draft and submit a Formal Change Request by identifying potential changes and then creating Changes and inserting them into a new FCR.

Contractor Formal Change Request: The SDSFIE Support Contractor may draft and submit a Formal Change Request by identifying potential changes and then creating Changes and inserting them into a new FCR.

DISDI Formal Change Request: The DISDI Program Office may draft and submit an FCR by identifying potential changes and then creating Changes and inserting them into a new FCR.

Formal Change Management Process: The process used to a) accept and implement or b) reject a set of Changes within a Formal Change Request. This process is described in the remainder of this section.

3.4.7.1 Identify Potential Changes Activity The Identify Potential Changes activity is part of all top-level processes and represents the first step in the CMP, the identification of changes. This process is not defined more thoroughly within the CMP because it varies widely depending on the part and the context of requirement for change. In any case, there can be no request made until there are changes identified.

Best Practice: To ensure the most efficient process possible, the SDSFIE Support Contractor (for SDSFIE-V or SDSFIE Online) or the DISDI Program (for SDSFIE-M, -Q or -R) should be contacted about identified changes prior to preparing a CR. Contact can be made either via email, phone, or during working group meeting. This communication is important to ensure that the issue:

• is a valid CR, and not just a minor bug fix; • has not already been addressed, possibly through another registered CR; or • will be addressed through changes being made, under development, or for which plans are

already in place.


44

Figure 16: Top-level CMP Processes BPMN Diagram

3.4.7.2 Develop Draft CR Activity The Develop Draft CR activity is found only within the Component Draft Change Request (DCR) process and is accomplished using the SDSFIE Auomated Process Portal (SDSFIE A/P/P) at https://app.sdsfieonline.org.20. Users (hereinafter called Change Owner) from Components that allow DCR submission may submit a DCR. Users from outside of IGG member Components may also submit DCRs and they will be adjudicated by the DISDI Program.

Change Owners utilize the SDSFIE A/P/P to create all of the requested changes and then group them into a DCR. Once all have been entered and documented in the SDSFIE A/P/P, the DCR can be submitted. Once submitted, the DCR becomes an unclaimed Draft Final CR. The Component IGG Representative and assignees will get notified that a DCR has been submitted.

20 Alternatively, you may go directly to submission by selecting “Submit Change Request” in the drowdown menu with your username at the SDSFIE Online web site home page.

https://app.sdsfieonline.org/


45

Best Practice: Changes should be specific and descriptive of how a model or content of a document should be changed and should be at a level that is immediately implementable. Abstract and non-specific Changes are less likely to be adopted and require a lot more work on the part of all participants. Change Requests should bundle many like Changes along the functional lines or commonality of the items being address, the type of change required, or similarity in implementation technique.

3.4.7.3 Evaluate Draft Formal CR Sub-Process The Evaluate Draft Formal CR sub-process is found only within the Component Draft Change Request process and is depicted in Figure 17. This sub-process is invoked by a Component whenever they decide to process (or claim) Draft Final CR(s).The set of processes in this step are simply a recommended approach and are not supported directly by the SDSFIE A/P/P. Once each is evaluated, some or all of the Changes within it may be rejected or accepted. If a set of Changes within a DCR is accepted, then the Component may either submit it or add in other Changes and submit a single FCR.

Figure 17: Evaluate Draft CR Sub-process BPMN Diagram

3.4.7.4 Develop Formal CRs This section details the creation of Formal CRs by Component HQ level users, DISDI Program users, and by the SDSFIE Support Contractor, aside from the process just described of turning a DCR into an FCR. The distinction of the source of the request is important because only Formal CRs developed by Component HQ, DISDI Program, or Support Contractor will be analyzed and evaluated by the IGG.


46

3.4.7.4.1 Component Formal CRs If a Component Change Owner identifies a set of potential changes, then they will utilize the SDSFIE A/P/P to create all of the identified Changes and then group them into a “New” FCR. Once all have been entered and documented in the SDSFIE A/P/P, the FCR can be submitted into the Formal Change Management Process. Once submitted, the FCR becomes un-editable by the Change Owner and the status becomes “Pending Technical Review”. The parties responsible for initiating the Formal Change Management Process (Technical Feasibillity Review) are notified about the now submitted FCR.

3.4.7.4.2 DISDI Formal CRs If a DISDI Program Change Owner identifies a set of potential changes, then they will utilize the SDSFIE A/P/P to create all of the identified Changes and then group them into a “New” FCR. Once all have been entered and documented in the SDSFIE A/P/P, the FCR can be submitted into the Formal Change Management Process. Once submitted, the FCR becomes un-editable by the Change Owner and the status becomes “Pending Technical Review”. The parties responsible for initiating the Formal Change Management Process (Technical Feasibillity Review) are notified about the now submitted FCR.

3.4.7.4.3 Contractor Formal CRs If a SDSFIE Support Contractor identifies a set of potential changes, then they will utilize the SDSFIE A/P/P to create all of the identified Changes and then group them into a “New” FCR. Once all have been entered and documented in the SDSFIE A/P/P, the FCR can be submitted into the Formal Change Management Process. Once submitted, the FCR becomes un-editable by the SDSFIE Support Contractor (unless allowed to make edits by virtue of their role in the process) and the status becomes “Under Technical Review”. The parties responsible for initiating the Formal Change Management Process (Technical Feasibillity Review) are notified about the now submitted FCR.

3.4.7.5 Formal Change Management Process Trigger An FCR is submitted.

Deliverables Implemented Change.

Process Steps The process steps in the Formal Change Management Process are as follows and are described in the following sections:

Sub-process 1. Technical Feasibility Review

Sub-process 2. Policy Review

Sub-process 3. Cost/LOE Review

Sub-process 4. IGG Chair Review

Sub-process 5. Working Group Review

Sub-process 6. IGG Vote

Sub-process 7. Implementation

As depicted in Figure 16, the Change Owner is able to withdraw any individual Change during the process and, specifically, during Sub-processes 1, 2, and 5. What is not depicted is the logic that if all Changes within an FCR are withdrawn, that the FCR terminates processing.

3.4.7.5.1 Technical Feasibility Review The first step in the Formal Change Management Process is a Technical Feasibility Review. This step is designed to be a technical feasibility analysis of the proposed Changes. Depending on the type of Change and the SDSFIE Part being changed, the Reviewer role as defined in Table 3.


47

Table 3: Reviewer Roles by Change Type and SDSFIE Part

Change Type SDSFIE Part Reviewer

Specification/Model

Vector SDSFIE Support Contractor

Metadata DISDI Program Staff

Document

Quality DISDI Program Staff

Raster DISDI Program Staff

SDSFIE Online SDSFIE Support Contractor

Typically, the Technical Feasibility Review contains the following activities (see Figure 18):

• Develop Initial Analysis—The Reviewer will examine each Change and make a determination as to the feasibility of the change with respect to the Implementation Guidance and good modeling practice and enter it into SDSFIE A/P/P.

o For Specification Model Changes—The SDSFIE Support Contractor (for SDSFIE-V) or DISDI Program Staff (for SDSFIE-M) will analyze the change with respect to the Implementation Guidance to determine whether the Change violates any of the rules therein. The Reviewer will then analyze the impact of implementing the Change to the SDSFIE part by conducting a thorough analysis of the Change. The Reviewer will make a determination of whether the proposed changes align with subject matter expert intention by collaborating with individual SMEs and may find it necessary to contact SMEs for their assessment.

o For Document Changes—The DISDI Program Staff analyze the recommended Changes with respect to the overall purpose of the document. If the Reviewer determines that the recommended change does not adversely affect the integrity and purpose of the document, then the Change passes functional analysis. The Reviewer will then analyze the technical feasibility of the Change with respect to the document content. If the staff analysis determines that the recommended change does not adversely affect the technical content of the document, then the request passes technical analysis.

o For SDSFIE Online Changes— The SDSFIE Support Contractor reviews the Changes with respect to technical feasibility of the tool or website change.

The Reviewer analyzes the Changes with respect to either tool functionality or website content depending on the nature of the Change:

• Tool Functionality— This analysis will focus on the purpose of the tool, the expected input to the tool, and the expected products of the tool. Changes pass functional analysis if they meet the following requirements:

o The Change is an enhancement (added functionality) to the tool and the IGG Chair determines that the enhancement benefits other DoD Components and the enhancement does not cause adverse effects on current or planned automated systems.

o The Change maintains functional integrity of the tool. This means that the change does not duplicate another function in the tool and does not cause another function to fail or become obsolete.


48

• Website Content—The Reviewer determines the impact of the CR on the functional integrity of the Web site by analyzing the recommended changes to the overall purpose of the Web site and compliance to DoD-level policy. If the Reviewer determines that the recommended change does not adversely affect Web site functional integrity and functional operation, then the request passes functional analysis.

The Changes will be reviewed to ensure consistency with DoD practice regarding hardware, software, communications, system development, and security/information assurance. The changes are feasible if they meets the following requirements:

• Hardware, software, and communications restrictions of the DoD.

• Commercially available hardware, software, and communications.

• Within the realm of production systems (outside the realm of research).

• Does not adversely impact the security or information assurance posture of SDSFIE Online.

• Update Major/Minor/Corrigendum Determination—For Specification/Model Changes (currently the Vector and Metadata parts), the Reviewer will verify the Change Owners stipulation concerning the category of the change as Major, Minor, or Corrigendum and will update the category using SDSFIE A/P/P, if required.

• Collaborate with Change Owner to Update Changes—The Reviewer will meet with the Change Owner (and potentially others, such as DISDI Program Staff) to collaborate over the Changes and to update them using SDSFIE A/P/P to remove as many negative feasibility determinations as possible. The Change Owner may choose to withdraw the Change as a result of these discussions.

• Make Final Feasibility Determination—The Reviewer will document the final feasibility determination inSDSFIE A/P/P

The above activities are multi-instance activities and occur for each Change in the FCR. Modifications to the Change content are made as the task continues by the Reviewer and are visible at all times by all with role-based access, most notably the Change Owner.

Once all of the above have been entered and documented in the SDSFIE A/P/P, the Technical Feasibility Review can be marked as completed. Once the sub-process is completed, the status becomes “Under Policy Review”. The parties responsible for initiating the Policy Review sub-process are notified about the FCR.


49

Figure 18: Technical Feasibility Review Sub-process BPMN Diagram

3.4.7.5.2 Policy Review The next step in the Formal Change Management Process is a Policy Review. This step is designed to be a policy analysis of the proposed Changes. Typically, the Policy Review contains the following activities (see Figure 19):

• Develop Initial Analysis—The Reviewer will examine each Change and make a determination as to the feasibility of the change with respect to DoD and SDSFIE Policy and enter it into SDSFIE A/P/P.

• Collaborate with Change Owner to Update Changes—The Reviewer will meet with the Change Owner (and potentially others, such as DISDI Program Staff) to collaborate over the Changes and to update them using SDSFIE A/P/P to remove as many negative feasibility determinations as possible. The Change Owner may choose to withdraw the Change as a result of these discussions.

• Make Final Feasibility Determination—The Reviewer will document the final feasibility determination in SDSFIE A/P/P

The above activities are multi-instance activities and occur for each Change in the FCR. Modifications to the Change content are made as the task continues by the Reviewer and are visible at all times by all with role-based access, most notably the Change Owner.

Once all of the above have been have been entered and documented in the SDSFIE A/P/P, the Policy Review can be marked as completed. Once the sub-process is completed, the status becomes “Awaiting Cost/LOE Estimate”. The party responsible for performing the Cost/LOE Estimate sub-processes is notified about the FCR.


50

Figure 19: Policy Review Sub-process BPMN Diagram

3.4.7.5.3 Cost /Level of Effort (LOE) Review The next step in the process is the Cost/LOE Review. The same role indicated by Table 3 by Change Type and SDSFIE Part will perform the first step in the Cost/LOE Review, which is basically a cost/LOE estimation. The estimation will depend on the Change type, as follows:

• SDSFIE Online—The Reviewer will determine the costs and benefits of all Changes in the FCR. Typically, the Reviewer will:

o analyze the cost/level of effort to implement the proposed changes and will provide an estimate in man hours and/or dollars for each Change in the FCR;

o analyze the benefit to the end user/target audience for each Change or the set of Changes as a whole;

o develop a simple schedule for the implementation; and

o enter the cost/benefit information into the SDSFIE A/P/P.

• All Other Change Types—The Reviewer will determine the level of effort to complete the implementation of all proposed changes and prepare a proposed schedule for the work.

BEST PRACTICE: In general, the Cost/LOE estimation stage should be fairly generalized and lightweight. The primary exception to this are Changes to SDSFIE Online Tools which can be complex and costly. In the former case, the text area provided by the SDSFIE A/P/P should be sufficient to contain the results of the estimation process. In the latter case, it is recommended that a short document (possibly a spreadsheet) be developed and attached for the purpose of communicating the Cost/LOE estimate more completely.

Once the estimation has been completed, the Cost/LOE Reviewer will be notified. This reviewer is determined as listed in Table 4.

Table 4: Cost/LOE Reviewer Roles by Change Type and SDSFIE Part

Change Type SDSFIE Part Cost/LOE Reviewer

Specification/Model


51

Vector SDSFIE COR

Metadata DISDI Program COR / IGG Chair

Document

Quality DISDI Program COR / IGG Chair

Raster DISDI Program COR / IGG Chair

SDSFIE Online SDSFIE COR

Figure 20: Cost/LOE Review Sub-process BPMN Diagram

The Cost/LOE Reviewer will review the estimation and may choose to update the estimation information. At this point the Reviewer will choose to accept or reject Changes on the basis of Cost or LOE.

BEST PRACTICE: If the Reviewer rejects the Change in the FCR on the basis of cost, the SDSFIE A/P/P content should be modified to reflect a discussion of this point and the rationale behind the rejection.

Once all of the above have been have been entered and documented in the SDSFIE A/P/P, the Cost/LOE Review can be marked as completed. Once the sub-process is completed, the status becomes “Under IGG Chair Review”. The IGG Chair is notified about the FCR.


52

3.4.7.5.4 IGG Chair Review The next step in the Formal Change Management Process is the IGG Chair Review. This step is designed to result in a accept/reject recommendation to be considered by the appropriate Work Group for each of the proposed Changes. The IGG Chair Review contains the following activities (see Figure 21):

• Review Information From All Previous Processes—The IGG Chair will examine each Change and its process history through all previous Formal Change Management Process steps.

• Make and Document Final Determination—The IGG Chair will make and document a final recommendation for each Change based on the previous review and enter this information into the SDSFIE A/P/P. At this point, the IGG Chair can propose that a Change requesting an exception (as part of the Adaptation Process) be rejected with the “with Exception” caveat and will clearly state this in the recommendation text. In this case, the Change will be marked as “Rejected”, but will have the “With Exception” value set to “Yes”.

The above activities are multi-instance activities and occur for each Change in the FCR.

Once all of the above have been entered and documented in the SDSFIE A/P/P, the IGG Chair Review can be marked as completed. Once the sub-process is completed, the status becomes “Under Working Group Review”. The parties responsible for initiating the performing the Working Group Review sub-processes are notified about the FCR.

Figure 21: IGG Chair Review Sub-process BPMN Diagram

3.4.7.5.5 Working Group Review Once the IGG Review is completed and a recommendation per change has been made. The FCR is assigned to a Working Group for consensus processing. Depending on the type of Change and the SDSFIE Part being changed, the Reviewer role as defined in Table 5.

Table 5: Working Group Assignments by Change Type and SDSFIE Part

Change Type SDSFIE Part Reviewer

Specification/Model

Vector SDSFIE Vector (SDSFIE-V) Working Group

Metadata Metadata Working Group

Document

Quality Quality Working Group

Raster Raster Working Group

SDSFIE Online SDSFIE Online Working Group


53

The Chair of the assigned Working Group will hold one or more working group meetings to consider the individual Changes in an FCR, and specifically, the IGG Chair recommendation. Any updates to the Changes to make them acceptable to the Working Group and the Change Owner may be made during this task. Once complete, any further comments as to the outcome of this task for the changes in question may be provided (this is called the Working Group Recommendation and is displayed prominently by the SDSFIE A/P/P on each Change for which this text has been entered)..

BEST PRACTICE: The Working Group Recommendation should be written so as to clearly identifiy the exact Change that will be made to the specification, model, document, tool, or website content. It should indicate, in summary form, how the change is different than that originally submitted. This will alleviate the ned for users to “dig deep” into the history for each change to determine what has occurred during the process and will facilitate the IGG Vote.

To be clear, the A/P/P does not process a formal vote at the Working Group level, and thus the Components do not cast ballots through the A/P/P at the Working Group level. The formal vote process that is managed through the A/P/P takes place at the IGG level only.

At the Working Group level, the Working Group Chair seeks to obtain consensus on each change. For each change in the FCR, the Working Group outcomes are classified and recorded in one of four possible ways:

• “Accept” (Unanimously) – all Working Group members approve the change

• “Reject” (Unanimously) – all Working Group members do not approve the change

• “No Consensus” (Non-unanimous) – some Working Group members approve the change, and some do not

• “Deferred” – no further action is taken on the change, within the current FCR, but the change remains active and can be added to a different FCR at a later point in time

Once all of the above have been entered and documented in the SDSFIE A/P/P, the Working Group Review can be marked as completed. Once the sub-process is completed, the status becomes “Awaiting IGG Vote”.


54

Figure 22: Working Group Review Sub-process BPMN Diagram

After the Working Group meeting, if all changes have been classified and the Working Group Chair has concluded that task, then Vote processes are automatically generated with the SDSFIE A/P/P for IGG action:

• For a given FCR, all of the changes for which there was a unanimous outcome (either “Accept” or “Reject”) will be bundled into a single Vote process within the A/P/P, to be acted upon by the IGG.

• For a given FCR, each change for which there was “No Consensus” will be considered within a single Vote process within the A/P/P, to be acted upon by the IGG.

This consideration for the unanimity of Component positions within the Working Group for each change allows the vote process to be conducted by the IGG in an informed and efficient manner, with distinction given to the Working Group’s “No Consensus” outcomes.

3.4.7.5.6 IGG Vote The next step in the Formal Changement Management Process is the IGG Vote. This process step is intended to obtain a final outcome on all non-deferred Changes withn an FCR. The IGG Vote process is totally automated and requires no intervention, except to perform proxy voting (in the case where a Component requests that occur).

The process begins with a notification to all primary and alternate IGG voters that the vote has started. At this point the process will simply wait for the Voters to cast their ballots until the end date of the vote. The vote duration shall be specified in the IGG Standard Operating Procedures (SOP). The Cast Ballot process will allow primary or alternate voters to cast a ballot for a Component as the ballots are “per organization”.

The ballot possibilities include the following and have the indicated meaning:

• For the votes reflecting a consensus recommendation by the Working Group:

o Yes—concur with the consensus recommendation of the Working Group (which means, agreeing to accept or reject the changes as recommended by the Working Group and


55

may include agreeing with a “With Exception” caveat on rejected changes). “Yes” ballots can be accompanied by a textual description of the reason(s) for concurrence.

o No—non-concur with the consensus recommendation of the Working Group. “No” ballots must be accompanied by a textual description of the reason(s) for non-concurrence.

o Abstain— formally decline to vote either for or against. “Abstain” ballots must be accompanied by a textual description of the reason(s) for abstaining.

• For the votes reflecting non-consensus of the Working Group (and thus relate to a single Change):

o Yes—accept the change. “Yes” ballots can be accompanied by a textual description of the reason(s) for concurrence.

o No—reject the change. “No” ballots must be accompanied by a textual description of the reason(s) for non-concurrence.

o Abstain— formally decline to vote either for or against. “Abstain” ballots can be accompanied by a textual description of the reason(s) for abstaining.

If the alternate voter votes for an organization, then they may recast their ballot until either the primary voter casts the ballot or the vote period ends. If the primary voter casts a ballot, the alternate voter can no longer cast a ballot. The primary voter may recast their ballot at any time up to the end of the vote period.

Once the end of the vote period is reached, the SDSFIE A/P/P will finalize the vote by replacing all non-votes with a “Yes”.

Figure 23: IGG Vote Sub-process BPMN Diagram


56

The IGG Chair records the final vote according to procedures specified in the IGG SOP.

Once an FCR has been voted upon and finalized, all of the Voters receive a notification that the Vote has ended. the Accepted Changes should be implemented.

3.4.7.5.7 Implementation The final step in the Formal Change Management Process is the Implementation of all Accepted Changes. The SDSFIE A/P/P will generate a Work Item process for each Change assigned to the same person as defined in Table 3. The SDSFIE A/P/P will notify the assignee of the Work Item and will then Monitor the Work Item, accepting process reports, request for progress reports, and issuing reminders as defined in the Work Item information. The assignee will complete the Work Item, providing periodic progress reports (if the task has a long duration). Once completed, the assignee will mark the Work Item as completed.

Once all Work Items related to Accepted Changes within an FCR have been completed, the FCR is considered closed and the status is set to “Implemented”.

Figure 24: Implementation Sub-process BPMN Diagram


57

Annex A. SDSFIE Artifact Registration Description

This annex outlines the current registration locations for SDSFIE Artifacts, by part.

SDSFIE Vector Models/Adaptations All SDSFIE-V Gold Models and Component HQ Adaptations are posted to the

SDSFIE Registry at SDSFIE Online (https://www.sdsfieonline.org) and are viewable via the Browse/Generate Tool

Enumerations Enumerations from the currently active SDSFIE-V Gold model are posted to the NSG Registry (https://nsgreg.nga.mil) under the IGG Authority.

SDSFIE Metadata Schemas SDSFIE-M schemas are posted to SDSFIE Online in the directory

https://www.sdsfieonline.org/schemas/metadata/version, where version is the version number

Code Lists Code lists from the currently active SDSFIE-M conceptual model are posted to the NSG Registry (https://nsgreg.nga.mil) as follows:

• When unchanged from the NAS baseline, they are reused under the Metadata WG authority

• When changed from the NAS baseline, they are published under the IGG Authority.


58

Annex B. BPMN Quick Guide

This annex provides a quick guide to the symbology of BPMN 2.0.

Element Description Notation

Event An Event is something that “happens” during the course of a Process. These Events affect the flow of the model and usually have a cause (trigger) or an impact (result). Events are circles with open centers to allow internal markers to differentiate different triggers or results. There are three types of Events, based on when they affect the flow: Start, Intermediate, and End. • The Start Event indicates where a particular

Process will start. • Intermediate Events occur between a Start Event

and an End Event. They will affect the flow of the Process, but will not start or (directly) terminate the Process.

• The End Event indicates where a Process will end.

Start

Intermediate

End

Activity An Activity is a generic term for work performed in a Process. An Activity can be atomic or non-atomic (compound). The types of Activities that are a part of a Process Model are: Task and Sub-Process, which are rounded rectangles. • Task: A Task is an atomic Activity that is included

within a Process. A Task is used when the work in the Process is not broken down to a finer level of Process detail.

• Sub-Process (collapsed): The details of the Sub-Process are not visible in the Diagram. A “plus” sign in the lower-center of the shape indicates that the Activity is a Sub-Process and has a lower level of detail.

• Sub-Process (expanded): The boundary of the Sub-Process is expanded and the details (a Process) are visible within its boundary. Note that Sequence Flows cannot cross the boundary of a Sub-Process.

Task

Sub-Process (collapsed)

Sub-Process (expanded)


59

Activity Looping The attributes of Tasks and Sub-Processes will determine if they are repeated or performed once. There are two types of loops: Standard and Multi-Instance. • Standard: A small looping indicator will be

displayed at the bottom-center of the activity. • Multi-instance Sequential: A set of three

horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances.

• Multi-instance Parallel: A set of three vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances.

A Text Annotation is typically attached to indicate what the instances represent (for example, “For all buyers”).

Standard

Multi-instance Sequential

Multi-instance Parallel

Text Annotation (attached with an Association)

Text Annotations are a mechanism for a modeler to provide additional text information for the reader of a BPMN Diagram.

Pool A Pool is the graphical representation of a Participant in a Collaboration. It also acts as a “swimlane” and a graphical container for partitioning a set of Activities from other Pools, usually in the context of business-to-business situations. A Pool MAY have internal details, in the form of the Process that will be executed. Or a Pool MAY have no internal details, i.e., it can be a "black box." “Black box” pools in this document are styled in blue and their name indicates an organization or a participant. Standard pools in this document are styled in white and their name is the name of the Process.

Lane A Lane is a sub-partition within a Pool, and will extend the entire length of the Pool. Lanes are used to organize and categorize Activities. Lanes in this document are styled in green and their name indicates a participant in the Process.

Descriptive Text H

Nam

e Po

ol N

ame

Lane

N

ame

Lane

N

ame


60

Gateway A Gateway is used to control the divergence and convergence of Sequence Flows in a Process. Thus, it will determine branching, forking, merging, and joining of paths. Internal markers will indicate the type of behavior control. • A diverging Exclusive Gateway (Decision) is

used to create alternative paths within a Process flow. A converging Exclusive Gateway is used to merge alternative paths.

• A diverging Inclusive Gateway (Inclusive Decision) can be used to create alternative but also parallel paths within a Process flow. A converging Inclusive Gateway is used to merge a combination of alternative and parallel paths.

• A Parallel Gateway is used to synchronize (combine) parallel flows and to create parallel flows.

Exclusive

Inclusive

Parallel

Sequence Flow A Sequence Flow is used to show the order that Activities will be performed in a Process.

Message Flow A Message Flow is used to show the flow of Messages between two Participants that are prepared to send and receive them. In BPMN, two separate Pools in a will represent the two Participants.