sdsfie governance plan-revision 1meet those objectives (sections 3.3 and 3.4). section 3.4.7 of this...

Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE)

Governance Plan

Revision 1

(31 JANUARY 2017)

Prepared By:

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

For:

The Assistant Secretary of Defense (Energy, Installations, & Environment)

© 2017

31 JAN 2017 SDSFIE Governance Plan R1

i

THIS PAGE IS INTENTIONALLY BLANK


i

Executive Summary

The Assistant Secretary of Defense for Energy, Installations, and Environment (ASD(EI&E)), under the authority, direction, and control of the USD(AT&L), established the Installation Geospatial Information and Services (IGI&S) governance group (the IGG) to develop coordinated and integrated approaches for IGI&S across the Department. The IGG consists of core members representing ASD(EI&E); 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 required schema or data model, and therefore is not registered in the DoD IT Standards Registry (DISR).


ii

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.7 of this revision incorporates and replaces the 2011 SDSFIE Change Management Process. 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 Changed By 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)

GIO, ASD(EI&E) 1 NOV 2016 Revision 1


iv

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

1.5 Document Maintenance ......................................................................................................................... 3

2 Overview of SDSFIE: What and Why .............................................................................................. 3

2.1 SDSFIE Online Definition ....................................................................................................................... 5

2.2 SDSFIE Goals ........................................................................................................................................ 5

2.3 Definition of Interoperability .................................................................................................................... 5

2.4 SDSFIE Guiding Principles .................................................................................................................... 6

2.4.1 SDSFIE Vector Guiding Principles (Mature) ...................................................................................... 6

2.4.2 SDSFIE Metadata Guiding Principles (Mature) ................................................................................. 7

2.4.3 SDSFIE Raster Guiding Principles (Mature) ...................................................................................... 7

2.4.4 SDSFIE Data Quality Guiding Principles (Mature) ............................................................................. 7

2.4.5 SDSFIE Portrayal Guiding Principles (Emerging) .............................................................................. 7

2.4.6 SDSFIE Services Guiding Principles (Emerging) .............................................................................. 7

2.4.7 SDSFIE Endorsed Standards Guiding Principles (Emerging) ........................................................... 7

2.4.8 SDSFIE Online Guiding Principles (Emerging) .................................................................................. 7

3 Governance ...................................................................................................................................... 8

3.1 Context ................................................................................................................................................... 8

3.2 Roles and Responsibilities ..................................................................................................................... 9

3.2.1 Stakeholder Roles ............................................................................................................................. 9

3.2.2 Role Accountability By Objective ..................................................................................................... 11

3.3 Objectives ............................................................................................................................................ 13

3.3.1 Governance ..................................................................................................................................... 13

3.3.2 Standards Management .................................................................................................................. 14

3.3.3 Documentation ................................................................................................................................ 15

3.3.4 Change Management ...................................................................................................................... 16

3.3.5 Implementation ................................................................................................................................ 20

3.4 Processes ............................................................................................................................................ 24

3.4.1 Document Approval Process ........................................................................................................... 24

3.4.2 IGG Consensus Process ................................................................................................................. 27

3.4.3 Standards Gap Resolution Process ................................................................................................. 28

3.4.4 New Version Processes .................................................................................................................. 31

3.4.5 Adaptation Processes ...................................................................................................................... 36

3.4.6 Implementation Scoring Process ..................................................................................................... 40


v

3.4.7 Change Management Process (CMP) ............................................................................................. 41

Annex A. SDSFIE Interoperability Framework ................................................................................. 54

Annex B. IGI&S Governance Namespace Description .................................................................... 55

Annex C. BPMN Quick Guide ........................................................................................................... 57


vi

Table of Figures Figure 1: SDSFIE Roles and Relationships ................................................................................................................. 11

Figure 2: Change Processing for a Document Change Request ................................................................................. 17

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

Figure 5: Document Approval Process BPMN Diagram ............................................................................................... 26

Figure 6: IGG Consensus Process BPMN Diagram ..................................................................................................... 28

Figure 7: Standards Gap Resolution Process .............................................................................................................. 30

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

Figure 9: Gather Requirements Sub-process BPMN Diagram ..................................................................................... 33

Figure 10: Requirements Document Analysis Sub-process BPMN Diagram ............................................................... 34

Figure 11: Develop New Model Sub-process BPMN Diagram ..................................................................................... 35

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

Figure 13: Adaptation Process BPMN Diagram ........................................................................................................... 38

Figure 14: Process Findings Sub Process BPMN Diagram ......................................................................................... 39

Figure 15: Implementation Scoring Process BPMN Diagram ....................................................................................... 40

Figure 16: Top-level CMP Processes BPMN Diagram ................................................................................................. 42

Figure 17: Evaluate Draft CR Sub-process BPMN Diagram ........................................................................................ 43

Figure 18: Analyze Formal CR Sub-process BPMN Diagram ...................................................................................... 45

Figure 19: Policy Review Sub-process BPMN Diagram ............................................................................................... 46

Figure 20: Specification/Model Change Feasibility Sub-process BPMN Diagram ........................................................ 47

Figure 21: Document Change Feasibility Sub-process BPMN Diagram ...................................................................... 48

Figure 22: SDSFIE Online Change Feasibility Sub-process BPMN Diagram .............................................................. 49

Figure 23: Develop Change Recommendation Sub-process BPMN Diagram ............................................................. 50

Figure 24: Evaluate CR Recommendation Sub-process BPMN Diagram .................................................................... 51

Figure 25: Implement Change Sub-process BPMN Diagram ....................................................................................... 51

Figure 26: Implement SDSFIE Online Change Sub-process BPMN Diagram .............................................................. 52

Figure 27: Implement Document Change Sub-process BPMN Diagram ...................................................................... 53

Figure : Implement Specification/Model Change Sub-process BPMN Diagram ............. Error! Bookmark not defined.

Figure : Implement SDSFIE-V Specification/Model Change Sub-process BPMN Diagram .......... Error! Bookmark not defined.

Figure : Implement SDSFIE-M Specification/Model Change Sub-process BPMN Diagram .......... Error! Bookmark not defined.


vii

Table of Tables Table 1: RACI by Objective .......................................................................................................................................... 12

Table 2: DISDI Information Types and Relative URL Paths ......................................................................................... 55

1

THIS PAGE IS INTENTIONALLY BLANK

2

1 Introduction This governance plan defines what the Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) are and is intended to define a set of roles, responsibilities and processes that the Installation Geospatial Information and Services (IGI&S) Governance Group (IGG) shall follow to guide development and usage of SDSFIE within the enterprise1 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 Spatial Data Standards for Facilities Infrastructure and Environment (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 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.

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.7 of this revision incorporates and replaces the 2011 Change Management Process referenced below.

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

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

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

Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) Change Management Process, Version 1.0, Office of the Deputy Under Secretary of Defense (Installations & Environment), Business Enterprise Integration Directorate, 9 June, 2011

Guidance for the Adaptation of SDSFIE 3.0, Office of the Deputy Under Secretary of Defense (Installations & Environment), Business Enterprise Integration Directorate, 11 May 2011.

1.4 Acronyms

ASD(EI&E) Assistant Secretary of Defense for Energy, Installations, and Environment

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

3

BEA Business Enterprise Architecture DISDI Defense Installations Spatial Data Infrastructure DISR DoD Information Technology (IT) Standards Registry DoD Department of Defense FoS Family of Standards GEOINT Geospatial Intelligence GWG Geospatial Intelligence Standards Working Group GWG ASFE GWG Application Schemas for Feature Encoding Focus Group GWG MFG GWG Metadata Focus Group GWG PFG GWG Geographic Portrayal Focus Group GWG GWS FG GWG Geospatial Web Services (GWS) Focus Group I&E Installations and Environment IGI&S Installation Geospatial Information and Services ISO International Standards Organization IT Information technology LDM Logical data model NSG National System for Geospatial Intelligence OGC Open Geospatial Consortium SDSFIE Spatial Data Standards for Facilities, Infrastructure, and Environment 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

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.

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 “Gold2” Logical Data Model and all Component HQ-level Adaptation Logical

2 The SDSFIE-V Gold Logical Data Model represents the consensus core of SDSFIE-V that the IGG has agreed to support.

4

Data Models3. 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.

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

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

5

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 realized 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. This early understanding became realized as www.sdsfie.org. Over time, the site has become known as SDSFIE Online and resides at 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.

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 Registry4, and from there back to appropriate

4 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

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; this section contains these revised guiding principles which help direct the creation and maturation of the SDSFIE family of standards. The principles are organized in two tiers5. 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(EI&E).

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.

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.

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

7

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(EI&E).

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

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 shall be vetted and endorsed by the IGG and made available through SDSFIE Online services where possible7.

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.

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

7 Redistribution of standards documents is not always possible due to legal restrictions.

8

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 policy8,

Uniform IT standards shall be used throughout the Department in a manner that achieves and enhances interoperable and net-centric enabled IT9, 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 users10.

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) 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(EI&E), then coordinates and facilitates their implementation. Furthermore, the IGG promotes approved 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.

8 DoDD 8000.01

9 DoDD 5101.7

10 DoDI 8320.02

9

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(EI&E) 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:

IGG The IGG is a forum, established by authority of the ASD(EI&E) 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(EI&E), 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(EI&E) to chair the IGG.

Component IGG Representative

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

Working Group11 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 (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.

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

10

Implementation Level Organization 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.

11

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

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

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

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

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

12

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

Objective

Sub-objective IGG

IGG

Ch

air

Co

mp

on

ent

IGG

R

epre

sen

tati

ve

Wo

rkin

g G

rou

p

Rep

rese

nta

tive

SD

SF

IE C

OR

SD

SF

IE S

up

po

rt C

on

trac

tor

GE

OIN

T S

tan

dar

ds

Wo

rkin

g

Gro

up

ILO

Us

er

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

Working Groups A R R C C I I I I

Standards Management

Requirements A R R C C C I I14 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 1: RACI by Objective

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

13

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.

14

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 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. A charter containing scope, products, and lifecycle expectation of a working group will be documented, approved, and modified, as required, over the lifecycle of the working group. A status report will be documented and submitted to the IGG for every working group on a quarterly basis.

Success Measures: The percentage of working groups with complete and current charters will be captured. The percentage of working groups that submit a status report shall also be captured.

Supporting Processes: The DISDI 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 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.

15

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 an interoperability framework 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 interoperability framework, 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 annex to this document called “SDSFIE Interoperability Framework.”

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.

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 ASFE 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,

16

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 Metadata Focus Group (MFG) because that is the submission endpoint. Similarly, the Implementation Schema should conform to the guidelines of the GWG ASFE 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 IGI&S Governance Namespace

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 a IGI&S governance namespace description that defines the structure for posting artifacts related to each SDSFIE part. Once SDSFIE parts or new versions of those 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 IGI&S Governance namespace description will reside in an annex to this document called “IGI&S Governance Namespace 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.

17

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.

Figure 2: Change Processing for a Document Change Request

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

18

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

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.

19

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.

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

20

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.

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:

21

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(EI&E) 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(EI&E) 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(EI&E) memorandum as Mandated. The IGG is responsible for recommending to the ASD(EI&E) 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.

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.

22

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 a high level of implementation progress has been made.

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

Red: No implementation plan exists or 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 Yellow and Green status levels.

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.

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

23

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

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

24

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

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

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.

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

25

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

26

Figure 5: Document Approval Process BPMN Diagram

27

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

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.

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

28

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.

29

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.

30

Figure 7: Standards Gap Resolution Process

31

3.4.4 New Version Processes

The New Version Process defines the sequence of actions or steps for creating a new major 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.

32

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

33

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

34

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.

35

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.

36

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.

Process Steps

The following steps describe the Adaptation Process which is also depicted in Figure 13:

0. An Adaptation is developed by the Component.

1. Once an Adaptation has been created by a Component, the Adaptation and supporting documentation17 is submitted by an Adaptation Submitter to the IGG via the IGG Chair.

2. 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”, along with a suggested resolution, must be made available to the Chair and the submitting Component for discussion. Each resolution can be one of two forms, either a) a recommendation for Adaptation revision made by the SDSFIE Support Contractor to the Adaptation Submitter or b) a recommendation for the submission of a Change Management Process (CMP) Change Request (CR) by the Adaptation Submitter. If a) is the selected resolution approach, then once the Adaptation has been revised as agreed, the Adaptation is sent back to the SDSFIE Support Contractor. If b) is the selected resolution, then the CMP CR must be approved for the resolution to be considered final. If b) is the selected resolution approach and the CMP CR is rejected, then the resolution must follow a) and the Adaptation must be modified. The process continues until all findings have

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

37

been addressed and the Adaptation passes the technical review. At the point that the Adaptation passes the technical review, the Adaptation, supporting documentation, and a comment matrix is forwarded to the IGG Chair.

3. A review deadline is assigned by the IGG Chair (typically one month) and communicated to the Component IGG Representatives upon dissemination of the Adaptation, supporting documentation, and comment matrix.

4. 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 sent to the Adaptation Submitter for comment response. The Adaptation Submitter should first combine all comments into a single matrix. At the time the comments are sent to the Adaptation Submitter, the IGG Chair will decide if a comment clarification period is needed (this would most often be the case) and the Adaptation Submitter and Component IGG Representatives communicate until the comments are clarified.

5. The IGG Chair will decide if revision of the DRAFT is required. If a revision is required, the Adaptation Submitter will receive the request for a revision and must then revise the Adaptation 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.

6. Once the Adaptation Submitter has prepared the FINAL DRAFT Adaptation and supporting documentation it is submitted as a FINAL DRAFT to the IGG via the IGG Chair.

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 Adaptation Submitter shall finalize the Adaptation and forward the Adaptation (according to any existing Adaptation submission guidelines) to the SDSFIE Support Contractor. The SDSFIE Support Contractor shall then 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.

38

Figure 13: Adaptation Process BPMN Diagram

39

Figure 14: Process Findings Sub Process BPMN Diagram

40

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(EI&E).

Trigger

Annual implementation scoring requirement

Deliverables

Consolidated Implementation Scoring Report

Figure 15: Implementation Scoring Process BPMN Diagram

41

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). 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 potential change and then develop a Draft Change Request (CR). Once complete, the CR is submitted to the CMP Tracking Log where it awaits adjudication by the Component. Components may decide to disallow Draft CRs 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 either draft and submit a Formal CR or evaluate Draft CRs with the potential to draft and submit one or more Formal CRs.

Contractor Formal Change Request: The SDSFIE Support Contractor may draft and submit a Formal Change Request by identifying a potential change and then developing a Formal CR.

DISDI Formal Change Request: The DISDI Program Office may draft and submit a Formal Change Request by identifying a potential change and then developing a Formal CR.

Formal Change Management Process: The process used to implement or reject a Formal Change Request. This process is described in the remainder of this section.

3.4.7.1 Identify Potential Change Activity

The Identify Potential Change activity is part of all top-level processes and represents the first step in the CMP, the identification of a change. 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 is a change 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 an identified change 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.

42

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 process and is accomplished by completing a CR submission form at the SDSFIE Online web site. Users (hereinafter called Requestor) from Components that allow Draft CR submission may submit a Draft CR. Users from outside of IGG member Components may also submit Draft CRs and they will be adjudicated by the DISDI Program. Once a Draft CR is submitted, it is entered into the CMP Tracking Log and provided a unique tracking identifier of the form DCR-yy-nnn, where yy are the last two digits of the calendar year in which the Draft CR was submitted and nnn is an integer representing the order in which the Draft CR was received.

The Change Management Tracking Log is updated with the status: “Registered” by creation of an entry for the Draft CR.

3.4.7.3 Evaluate Draft CR Sub-Process

The Evaluate Draft 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 Draft CR(s) in the CMP Tracking Log. Once each is evaluated, it may be rejected or accepted. If a Draft CR is accepted, then the Component may either issue a Formal CR or bundle the Draft CR with others into a single Formal CR.

43

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

3.4.7.4.1 Component Formal CRs

After evaluating and accepting one or more Draft CR(s), the Component will create a Component Formal CR.

If a Component Requestor identifies a potential change, then a Component Formal CR is initiated at the Component HQ level. Component Formal CRs differ from a Draft CR in that a) several Draft CRs can be bundled together to form a single Component CR and b) the source of the Formal CR is a Component HQ.

The Component will contain the following information in the Formal CR:

Combine duplicate Draft CRs into a single Component Formal CR (if applicable) The date of endorsement The DoD Component point of contact for the Formal CR (this is the DoD Component sponsor for

the change) A description of the functional / business lines that will benefit from the change, including affected

current or planned automated systems A description of the business requirement that the change is addressing or supporting

44

Optionally, the categorization of the change as Major, Minor, or Corrigendum (see section 3.3.4.1)

Description of the Component rationale for endorsing the change

The DoD Component then transmits the Formal CR and endorsement to the IGG Chair for consideration via the SDSFIE Online web site. This transmission becomes the Component Formal CR.

3.4.7.4.2 DISDI Formal CRs

If the DISDI Program identifies a potential change, then a DISDI Formal CR is initiated at the DISDI Program level. If a Non-IGG Requestor identifies a potential change, then the Non-IGG Requestor submits a Draft CR (as described in 3.4.7.2), which initiates a DISDI Formal CR if the DISDI Program determines that the change has merit. The DISDI Formal CR will contain all information required for a Draft CR, plus the following information:

The DISDI point of contact for the CR (i.e. the DISDI sponsor for the change). A description of the functional / business line that will benefit from the change, including affected

current or planned automated systems. A description of the business requirement that the change is addressing or supporting The categorization of the change as Major, Minor, or Corrigendum (see section 3.3.4.1)

When the Formal CR is ready, DISDI transmits it to the IGG Chair for consideration via the SDSFIE Online web site.

3.4.7.4.3 Contractor Formal CRs

If the SDSFIE Support Contractor identifies a potential change, then a Contractor Formal CR is initiated. The SDSFIE Support Contractor Formal CR will contain the same information requirements as for all Formal CRs.

When the Formal CR is ready, SDSFIE Support Contractor transmits it to the IGG Chair for consideration via the SDSFIE Online web site.

3.4.7.4.4 CMP Tracking Log Updates

The CMP Tracking Log is updated by creation of an entry for the Component, DISDI, or Contractor Formal CR. The CMP Tacking Log will be visible to all stakeholders throughout the lifecycle of all CRs.

If a Draft CR is accepted, then the CMP Tracking Log record for the Draft CR is updated with the status “Accepted, Forwarded By Component”. If a Draft CR is rejected, then the CMP Tracking Log record for the Draft CR is updated with the status “Rejected”.

A CR Identifier for the Formal CR is inserted into the CMP Tracking Log record for a Formal CR with the status “Registered”. The CR identifier of the form CR-yy-nnn, where yy are the last two digits of the calendar year in which the Formal CR was submitted and nnn is an integer representing the order in which the Formal CR was received.

When the CMP Tracking Log is updated by any of the processes defined in this process, then the CR submitter will be notified of the status change.

3.4.7.5 Formal Change Management Process

Trigger

A Formal CR is submitted into the CMP Tracking Log.

Deliverables

Implemented Change.

Process Steps

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

45

Analyze Formal CR,

Develop Change Recommendation,

Evaluate CR Recommendations, and

Implement Change

3.4.7.5.1 Analyze Formal CR

Figure 18 depicts the sub-process of analyzing a CR, with the two possible outcomes, rejected and not rejected (accepted). The process includes several sub-processes and activities, including:

a policy review by the IGG Chair (Figure 19),

a feasibility analysis (this analysis depends on the type of CR begin considered) by the SDSFIE Support Contractor (see Figure 20 for Specification/Model Change Feasibility, Figure 21 for Document Change Feasibility, and Figure 22 for SDSFIE Online Change Feasibility),

a cost/benefit determination activity conducted by the SDSFIE Support Contractor, and

an implementation cost and schedule proposal prepared by the SDSFIE Support Contractor and submitted to the SDSFIE COR.

Figure 18: Analyze Formal CR Sub-process BPMN Diagram

The DISDI Program, with support from the SDSFIE Support Contractor and/or the DISDI Program staff, will analyze all incoming Formal CRs. Initially, the DISDI Program will crosscheck incoming Formal CRs against existing CRs and review with respect to SDSFIE and DoD-level policy and guidance (see Figure 19). When the policy review begins, the CMP Tracking Log is updated with the status “Under Review”. This assessment will compare the requested change to SDSFIE and DoD policy. If the request conflicts with policy, the IGG Chair can determine whether to reject the request or review the policy. If the Formal CR is rejected, the CMP Tracking Log is updated with the status “Rejected” in the status and a rationale for the rejection. If the Formal CR conforms to policy, the IGG Chair sends the Formal CR to either the

46

SDSFIE Support Contractor (for parts SDSFIE-V or SDSFIE Online) or the DISDI Program staff (for parts SDSFIE-M, SDSFIE-Q, or SDSFIE-R) for a technical feasibility assessment.

Figure 19: Policy Review Sub-process BPMN Diagram

Depending on the type of change, one of three feasibility analyses will be conducted, as follows:

Specification/Model Change Feasibility—

The SDSFIE Support Contractor (for SDSFIE-V) or DISDI Program Staff (for SDSFIE-M) will analyze the impact of implementing the change to the SDSFIE part by conducting a thorough analysis of the Formal CR. Results of this analysis influence the cost/benefit analysis. This effort does not produce a cost estimate but informs the IGG Chair and the IGG of the magnitude of impact the Formal CR may have on the SDSFIE part. The categorization of the change as Major, Minor, or Corrigendum will be reviewed and either validated or adjusted at this stage.

The analyst will make a determination of whether the proposed changes align with subject matter expert intention by collaborating with individual IGI&S organizations who may find it necessary to contact the SME group for their assessment. If an SME group or functional experts are consulted in the development of a Formal CR, this portion of the analysis will gauge whether that input was sufficient and resolve deficiencies.

All of the above analyses will be gathered into a written Formal CR Analysis and bundled with the Formal CR. All of this will then be forwarded back to the IGG Chair for further processing. The IGG Chair will make a determination of whether the change is feasible on the basis of the analysis. The CMP Tracking Log will then be updated with the status “Pass Feasibility Analysis” to indicate that change is feasible or with the status “CR Rejected” to indicate infeasibility.

47

Figure 20: Specification/Model Change Feasibility Sub-process BPMN Diagram

Document Change Feasibility—

The IGG Chair determines the impact of the CR on SDSFIE part (SDSFIE-Q or –R) by analyzing the recommended changes with respect to the overall purpose of the document. If the IGG Chair determines that the recommended change does not adversely affect the integrity and purpose of the document, then the request passes functional analysis. The IGG Chair will produce a brief report on the functional analysis.

The DISDI Program staff will analyze the technical feasibility of the CR with respect to the rest of 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. The DISDI Program Staff will produce a brief report on the functional analysis.

All of the above analyses will be gathered into a written Formal CR Analysis and bundled with the Formal CR. All of this will then be forwarded back to the IGG Chair for further processing. The IGG Chair will make a determination of whether the change is feasible on the basis of the analysis. The CMP Tracking Log will then be updated with the status “Pass Feasibility Analysis” to indicate that change is feasible or with the status “CR Rejected” to indicate infeasibility.

48

Figure 21: Document Change Feasibility Sub-process BPMN Diagram

SDSFIE Online Change Feasibility—

The IGG Chair reviews the CR with respect to either tool functionality or website content depending on the nature of the CR.

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.

CRs pass functional analysis if they meet the following requirements:

The CR 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.

The CR 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.

Website Content:

The IGG Chair 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 IGG Chair determines that the recommended change does not adversely affect Web site functional integrity and functional operation, then the request passes functional analysis.

The SDSFIE Support Contractor reviews the CR with respect to technical feasibility of the tool or website change. The change will be reviewed to ensure it is consistent with DoD practice regarding hardware, software, communications, system development, and security/information assurance. The change is feasible if it 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).

49

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

All of the above analyses will be gathered into a written feasibility report and bundled with the Formal CR. All of this will then be forwarded back to the IGG Chair for further processing. The IGG Chair will make a determination of whether the change is feasible on the basis of the analysis. The CMP Tracking Log will then be updated with the status “Pass Feasibility Analysis” to indicate that change is feasible or with the status “CR Rejected” to indicate infeasibility.

Figure 22: SDSFIE Online Change Feasibility Sub-process BPMN Diagram

If the SDSFIE Support Contractor or DISDI Program Staff considers the change feasible, then one of two scoping activities take place (refer now to the right hand portion of Figure 18). If the CR is of type SDSFIE Online, then a cost/benefit analysis and a cost and schedule proposal for the change will be prepared by the SDSFIE Online Contractor and reported to the SDSFIE COR. If the CR is of type Document or Specification/Model, then a level of effort estimate and a proposed schedule for implementation are prepared by the DISDI Program Staff (and, if the part is SDSFIE-V, in collaboration with the SDSFIE Support Contractor) and delivered to both the IGG Chair and, if the part is SDSFIE-V, to the SDSFIE COR.

In any case, the cost or level of effort estimates are summarized into the written Formal CR Analysis and bundled with the Formal CR.

3.4.7.5.2 Develop Change Recommendation

Once the Formal CR has been analyzed and accepted, a recommendation is developed by the IGG Chair in collaboration with the SDSFIE Support Contractor or DISDI Program Staff. This process is referenced in Figure 16 and depicted in Figure 23.

In this step, the IGG Chair will develop an overview of the change and then a summary of the analysis prepared in the last step in collaboration with the SDSFIE Support Contractor (SDSFIE-V or SDSFIE Online) or the DISDI Program Staff (SDSFIE-M or SDSFIE-Q). The change overview shall start with the description provided in the Formal CR and be adjusted, as necessary, as a result of the analysis. A detailed disposition recommendation will be prepared as “Accept”, “Accept with Modification”, or “Reject”.

50

In the case of a recommendation to “Accept with Modification”, the modifications to the CR will be included in the Recommendation. In the case of a recommendation to “Reject”, the rationale for the rejection will be included in the Recommendation.

In any case, the cost or level of effort estimates are summarized into the written Formal CR Analysis and bundled with the Formal CR. The CMP Tracking Log will be updated with the status “Recommendation Complete”.

Figure 23: Develop Change Recommendation Sub-process BPMN Diagram

3.4.7.5.3 Evaluate CR Recommendations

Once a recommendation is developed the IGG approves or rejects the recommendation by consensus. This process is referenced in Figure 16 and depicted in Figure 24. Note that the process uses the IGG Consensus Process as a “call activity” (it is defined in section 3.4.2).

51

Figure 24: Evaluate CR Recommendation Sub-process BPMN Diagram

3.4.7.5.4 Implement Change

Once a CR recommendation is accepted, it is forwarded to the correct sub process for implementation, as appropriate. This process is referenced in Figure 16 and depicted in Figure 25.

Figure 25: Implement Change Sub-process BPMN Diagram

Depending on the type of the CR recommendation one of three sub-processes will be invoked:

Implement SDSFIE Online Change,

Implement Document Change, or

Implement Specification/Model Change

These sub-processes are defined in the following sections.

52

3.4.7.5.4.1 Implement SDSFIE Online Change

The Implement SDSFIE Online Change sub-process is invoked when a CR of type SDSFIE Online is accepted and recommended for implementation. The SDSFIE COR will scope the effort and task the SDSFIE Support Contractor as possible given available resources. The SDSFIE Support Contractor will implement the changes according to the CR Recommendation. Once completed, the CR Log will be updated with the status of “Accepted, Implemented”. Depending on the type of change, one of the two following sets of steps will be executed:

If the change is to Tools or Workflows, then the SDSFIE Support Contractor will then develop a Test Plan. Component IGG Representatives (most likely SDSFIE Online Working Group members) will then perform User Acceptance Testing. If the tests do not pass, then the process will return to the SDSFIE Contractor for correction. If the tests do pass, then the CR Log will be updated with the status of “Accepted, Implemented, Tested”.

If the change is to website content, then the Component IGG Representatives will review the content. If the content does not pass, then the process will return to the SDSFIE Contractor for correction. If the content passes review, then the CR Log will be updated with the status of “Accepted, Implemented, Tested”.

Figure 26: Implement SDSFIE Online Change Sub-process BPMN Diagram

3.4.7.5.4.2 Implement Document Change

53

The Implement Document Change sub-process is invoked when a CR of type Document is accepted and recommended for implementation. The IGG Chair will scope the effort and task the DISDI Program Staff according to the availability of resources. The DISDI Program Staff will implement the changes according to the CR Recommendation by creating a draft document. The draft document will be submitted by the IGG Chair into the Document Approval Process to be worked to conclusion. Once completed, the CR Log will be updated with the status of “Accepted, Implemented, Approved”.

Figure 27: Implement Document Change Sub-process BPMN Diagram

3.4.7.5.4.3 Implement Specification/Model Change

The Implement Specification/Model Change sub-process is invoked when a CR of type Specification/Model is accepted and recommended for implementation. Depending on the part being addressed by the change, one of the two following sub-processed will be executed:

Implement SDSFIE-V Specification/Model Change, or

Implement SDSFIE-M Specification/Model Change

These sub-processes are described below.

54

Annex A. SDSFIE Interoperability Framework

This Annex is the subject of future work and will be provided in the next revision of this document.

55

Annex B. IGI&S Governance Namespace Description

NOTE: THIS SECTION TO BE UPDATED ONCE THE NEW REGISTRY IS CONFIGURED AND STOOD UP.

This Annex describes the organization of the Defense Installation Spatial Data Infrastructure (DISDI) governance namepsace on the Department of Defense (DoD) Data Services Environment (DSE). The purpose of the DISDI governance namespace is to provide metadata for identifying and encoding Installation Geospatial Information and Services (IGI&S) data and geospatial metadata18. This metadata may include geospatial metadata schemas, platform independent application schemas, platform specific schemas, data models, data dictionaries, data quality specifications, content specifications, entity catalogues, extraction guides, and profiles of these for specific application areas within the Installation and Environment (I&E) enterprise.

By providing these documents on the DSE, operations which otherwise do not have access to the Internet (e.g., Disconnected, Intermittent, and Low-bandwidth (DIL) or enclave environments) will be able to access these code list dictionaries through copies of the DSE hosted locally or on [Internet] disconnected networks.

The DISDI namespace is governed by the DISDI COI under the Real Property and Installation Management Domain of the Business Mission Area of the DoD Enterprise. Content published in the DISDI governance namespace can be accessed through the DSE using the base Uniform Resource Locator (URL):

http://metadata.ces.mil/dse/ns/DISDI

The information types and the path from the base URL is described in Table 2. This table will be periodically updated as new information types are required.

Table 2: DISDI Information Types and Relative URL Paths

Information Type Description Path

Code Lists

(not specifically organized)

Identifiers and definitions of common, related terms used to normalize the value of one or more data elements that are global (i.e., used by more than one SDSFIE part).

codelist (e.g.: codelist/ContextCode)

SDSFIE-M XML exchange schemas

(organized by version)

The XML exchange schema for the SDSFIE-M Implementation Specification: XML Exchange Schema (SMIS)

smis/version (e.g.: smis/1.0.1)

SDSFIE-M -specific Code Lists19


Identifiers and definitions of common, related terms used to normalize the value of one or more data elements that are specific to SMIS.

smis/version/codelist (e.g.: smis/1.0.1/codelist/ContextCode)

SDSFIE-V GML application schemas19


The GML application schema for SDSFIE-V.

sdsfie/version (e.g.: sdsfie/4.0/gml)

18 The use of the term “geospatial metadata” to refer to documentation of IGI&S data is necessary in this annex to differentiate it from the DSE use of the less specific term “metadata” that is refers to documentation of IT resources in general.

19 Denotes a future posting, do not expect to find resources at the URL given in the example.

56

SDSFIE-V-specific Code Lists19

(organized by version and component)

Identifiers and definitions of common, related terms used to normalize the value of one or more data elements that are specific to SDSFIE-V.

sdsfie/codelist/version/component (e.g.: sdsfie/codelist/4.0/usaf) (Note: The component “sdsfie” is used for global keyword codelists)

SDSFIE-V Keyword Thesauri (and subordinate Keywords) 19

(organized by version and component)

Thesaurus (set of keywords) that describe keywords associated with Entities in SDSFIE-V.

sdsfie/keywordCodelist/version/component/thesaurusName (e.g.: sdsfie/keywordCodelist /4.0/usn/ UtilityTypeCode) (Note: The component “sdsfie” is used for global keyword codelists) (Note: The standard TopicCategoryCode thesaurus relative URL is sdsfie/keywordCodelist/4.0/sdsfie/TopicCategoryCode

57

Annex C. 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)

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

58

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.

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.

Descriptive Text Here

Na

me

Po

ol N

ame

La

ne

Na

me

La

ne

Na

me