Global Force Management Data Initiative

1. Global Force ManagementData Initiative  Joint Staff, J-814 December 2004

2. 5 Separate SecDef Snowflakes authored on this subject. Responsibility for answering these five snowflakes was distributed throughout the Joint Staff. 21 Dec 02: �I think we are going to have to find a way to take all of the responsibilities for activating the guard and reserve from the services, the Joint Forces Command and the combatant commanders and put them in one place so that the flow of forces, whether it is active duty or reserves, is all in one location.� Answered by J4. 9 Jun 03: �I am coming to the conclusion that we need to have a better process to provide forces to the Combatant Commanders, to include active forces, Guard and Reserve. That may be a single force provider - or something else�. Answered by J7. 2 Jul 03: �Please give me...a proposal as to how JFCOM can be established as the headquarters of OPR as to how we ought to be organized and arranged for force projection, both for CONUS and OCONUS forces, active and reserve�. Answered by J4, but response never transmitted to CDR JFCOM. 22 Sep 03: �I have said...I would be more comfortable if force rotation and the deployment/mobilization process were handled by a single point of contact and that should be JFCOM...If what I have proposed does not make sense, we need to talk it out and find out what does make sense.� Being answered by J3 as part of JFM . 27 Sep 03: �I want to see what piece of paper we send to Joint Forces Command to make sure that he understands and everyone else in the world understands, that he�s got the baton on mobilizations, rotations and stop losses and the whole kit and caboodle.� Being answered by J3 as part of JFM. The Joint Staff requirement to develop the Global Force Management Process was tasked as part of the SecDef-directed Operational Availability Action Items memo, dated 18 Aug 03 SecDef has released another SF, (#677, dated 28 Jan 2004) on �Forces For� that has implications for GFM/JFM; being actioned by J8. Text of SF as follows: "I think I ought to have a meeting on "forces for". I am concerned about it. We need to address the question that was raised of ownership versus access, and how we change the law."5 Separate SecDef Snowflakes authored on this subject. Responsibility for answering these five snowflakes was distributed throughout the Joint Staff. 21 Dec 02: �I think we are going to have to find a way to take all of the responsibilities for activating the guard and reserve from the services, the Joint Forces Command and the combatant commanders and put them in one place so that the flow of forces, whether it is active duty or reserves, is all in one location.� Answered by J4. 9 Jun 03: �I am coming to the conclusion that we need to have a better process to provide forces to the Combatant Commanders, to include active forces, Guard and Reserve. That may be a single force provider - or something else�. Answered by J7. 2 Jul 03: �Please give me...a proposal as to how JFCOM can be established as the headquarters of OPR as to how we ought to be organized and arranged for force projection, both for CONUS and OCONUS forces, active and reserve�. Answered by J4, but response never transmitted to CDR JFCOM. 22 Sep 03: �I have said...I would be more comfortable if force rotation and the deployment/mobilization process were handled by a single point of contact and that should be JFCOM...If what I have proposed does not make sense, we need to talk it out and find out what does make sense.� Being answered by J3 as part of JFM . 27 Sep 03: �I want to see what piece of paper we send to Joint Forces Command to make sure that he understands and everyone else in the world understands, that he�s got the baton on mobilizations, rotations and stop losses and the whole kit and caboodle.� Being answered by J3 as part of JFM. The Joint Staff requirement to develop the Global Force Management Process was tasked as part of the SecDef-directed Operational Availability Action Items memo, dated 18 Aug 03 SecDef has released another SF, (#677, dated 28 Jan 2004) on �Forces For� that has implications for GFM/JFM; being actioned by J8. Text of SF as follows: "I think I ought to have a meeting on "forces for". I am concerned about it. We need to address the question that was raised of ownership versus access, and how we change the law."

3. GFM Bottom Line Force structure pulls everything together Readiness reporting Resources (including personnel & equipment) Capabilities Devil�s in the details Need commonality between Services Need common naming (Enterprise-Wide Identifiers) Default operational force structures Starting point for any joint task organization Readiness Reporting is based on force structure Personnel & Materiel are tied in below the UIC level Reporting must be rigorous for any task organization

4. Global Force ManagementDirection Document the �Authorized� force structure in a single, authoritative data source (ADS) Improve the SecDef's ability to manage risk across current worldwide operations, warfighting capabilities, and future force capability needs(i.e., Assignment, Allocation, and Apportionment) Make net-centric GFM data transparent, easily accessible to all users, and shared using common standards and resources GFM is referred to two distinct ways: The GFM Process GFM Data

5. GFM ProcessProblem Statement Problem Disconnected assignment, apportionment, and allocation methodologies No process to align all with Defense Strategy Ad Hoc risk assessment when demand exceeds supply No process in place to assess risk day-to-day Force presence not tied to global availability requirements No process to globally source force requirements Lack of inherent visibility across the joint force structure No process to manage joint availability Problem Disconnected assignment, apportionment, and allocation methodologies No process to align all with Defense Strategy Ad Hoc risk assessment when demand exceeds supply No process in place to assess risk day-to-day Force presence not tied to global availability requirements No process to globally source force requirements Lack of inherent visibility across the joint force structure No process to manage joint availability

6. GFM Data Problem Statement GFM is a process that enables insight into global availability of US forces, and provides a means to assess risks associated with proposed allocation, assignment and apportionment. GFM data will be transparent, universal and accessible on demand in a net centric environment. GFM is a process that enables insight into global availability of US forces, and provides a means to assess risks associated with proposed allocation, assignment and apportionment. GFM data will be transparent, universal and accessible on demand in a net centric environment.

7. Net-Centric Vision

8. Global Information Grid (GIG) Enterprise Services is way to common capabilities Idea you want to get across is that the idea is entered in the acquisition domain and then becomes available in the other domains.Idea you want to get across is that the idea is entered in the acquisition domain and then becomes available in the other domains.

9. Force Structure Construct DRRS = Defense Readiness Reporting System DIMHRS = Defense Integrated Military Human Resources System (PAY)DRRS = Defense Readiness Reporting System DIMHRS = Defense Integrated Military Human Resources System (PAY)

10. Why Put A Node (Aggregation Point) in an Org Chart?

11. Force Structure Construct (FSC) This is the �operational� organization, not the administrative. But, includes the administrative organizations as well. Remember that this includes ALL equipment, not just the platforms (the knife with the Air Combat Element (ACE), 1 per pistol.)This is the �operational� organization, not the administrative. But, includes the administrative organizations as well. Remember that this includes ALL equipment, not just the platforms (the knife with the Air Combat Element (ACE), 1 per pistol.)

12. Force Management Identifier Specification Force Management Identifiers: Are the collection of identifiers used in the GFM Information Exchange Data Model (GFMIEDM) (e.g., the �Organization-Identifier� and �Alias-Identifier� are FMIDs) Includes all GFMIEDM Identifiers and Indexes Are of data type Enterprise-wide Identifier [EWID] Can be used to uniquely identify any data across the GIG All GFM data is tagged for ease of software development and interoperability An Enterprise-wide Identifier [EWID] data type is: A non-intelligence bearing, 64-bit number that includes no information about the entity it identifies, composed of a 32-bit prefix and a 32-bit suffix Prefix is called an EWID Seed, is globally unique, and obtained via a controlled server. Suffix is local user controlled and maintained. May be used as a primary or alternate identifier (or key) When any GFMIEDM data is created, it is tagged for life � this includes: Organizations, Materiel Authorizations, Personnel Authorizations, and Relationships and associations between these entities

13. Connectivity EDIPI = Electronic Data Interchange Personal IdentifierEDIPI = Electronic Data Interchange Personal Identifier

14. Global Force Management FSC �On-hand� data = user pull�On-hand� data = user pull

15. GFM Data Prototype Effort Preparing a �Combat Slice� from each of the Services and putting it into GFMIEDM format Navy � Expeditionary Strike Group (ESG) USMC � Marine Expeditionary Unit (MEU) Army � Unit of Action (UA) Air Force � 4th Fighter Wing Simultaneously preparing the Concept of the Operations (CONOPS) in three areas: Organization Server Operations Allocation, Assignment & Apportionment process GFM in a net-centric environment

16. Summary Force Structure is the central integrating theme (i.e., the �foundation�) for Global Force Management The GFM Force Structure Construct is an organizational�way to electronically document force structure data A fully-articulated, hierarchal, default force structure that will be the authoritative source for authorized force structure data for use by all systems within the DoD enterprise A net-centric means of accessing this information (XML & Web Service enabling) Enterprise-Wide Identifiers (EWID) for tagging data for organizations, manpower, and equipment authorizations within DoD POC is Mike Boller (SAIC, ISO Joint Staff, J-8, MASO) � (703) 614-6772 michael.boller@js.pentagon.mil

17. Back-Up Slides

18. GFM-EDI Deliverable Sequence

20. Functional Cases FC #1 � Authorization Data ADS FC #2 � Populate the GFMIEDM in Org Servers FC #3 � Test Scalability of the Org Server FC #4 � �Links & FS Roles� FC #5 � Demonstrate the Time Variables FC #6 � Organization, Equipment & Personnel Changes FC #7 � Link �Authorized� to �On-Hand� data

21. FC #1 � Authorization Data ADS Purpose: Identification of initial Service-based authorization authoritative data sources (ADSs) for input into the Org Servers, and provide feedback to Services on how to populate an Org Server Concept: Determine which ADS are going to populate which fields in the GFMIEDM Environment: Unclassified Organizational Servers Products: Authoritative data sources for the population of the Org Servers are identified: Listing of fields and authoritative data sources and mapping between input ADS and Org Servers Identity of disconnects Final Display: A visual example of the documentation Who: BAH One of the primary things we are trying to accomplish is to have a single place where people can go to find �the� authoritative data source for authorization data Since we are trying to create this place, we have to determine what all of the different sources are that have to feed it. As a general rule, we are going to the Force Management community, and they may not have all of the data that we need for the model. We are assuming that the Services �know� where they got the data that they gave to us. When we find gaps, we will ask for the supporting data. Task to be accomplished: Listing of what each of the services gave Listing of where that information was used to populate the GFMIEDM List of who gets R/W/E permissions for each of the fields in the Org Server What we want to do is show the Services where we got the information from and how it maps into the GFMIEDMOne of the primary things we are trying to accomplish is to have a single place where people can go to find �the� authoritative data source for authorization data Since we are trying to create this place, we have to determine what all of the different sources are that have to feed it. As a general rule, we are going to the Force Management community, and they may not have all of the data that we need for the model. We are assuming that the Services �know� where they got the data that they gave to us. When we find gaps, we will ask for the supporting data. Task to be accomplished: Listing of what each of the services gave Listing of where that information was used to populate the GFMIEDM List of who gets R/W/E permissions for each of the fields in the Org Server What we want to do is show the Services where we got the information from and how it maps into the GFMIEDM

22. FC #2 � Populate the GFMIEDM in Org Servers Purpose: To identify structural and functional issues Concept: Put real authorization data into the GFMIEDM Environment: Unclassified Org Servers (DoD & Services) Products: A database populated with an �authorized� slice of the Force Structure data Viewable Organizational Charts Fully functional & populated GFMIEDM Force Structure slices from top of DoD (ARL) to the billet level (BAH) Documentation of the population processes DDMS integration with web services Web service specifications Associated XML schemas Final Display: Web browser based display tool with an active database IChart extended functionality (ARL) Web service enabled (for external links to the data) Who: BAH lead, Service review, JDS/JS

23. FC #3 � Test Scalability of the Org Server Purpose: Examine the scalability of the Org Server expanded to the size of a full-scale model to: Examine performance of a fully-populated model Gain insights into the architecture issues Concept: Copy �slice� data (x49 [~2% of FS data to ~100% est. FS data] x 10[years]), rename it, and populate the model Environment: Unclassified Org Servers Products: A database populated to the approximate size with �authorized� Force Structure data Final Display: Applicable performance tests and metrics Recommendations for Org Server architecture Who: JDS lead, ARL assist

24. FC #4 ��Links & FS Roles� Purpose: To Demonstrate: The model can use links/roles to perform task organization The ability to document billets in a Service and display the �Joint� Billets as part of the task organization Concept: Build a Marine Expeditionary Unit with authorization data Environment: Classified �User� database (not the org server) Products: A Task Organized Unit derived from the Org Server using links, using authorization data Demonstration use of links/roles Demonstration of Navy Corpsman, documented in the Navy, as an integral part of the MEU Final Display: A before and after picture of the MEU using the web browser-based tool Who: BAH lead, ARL assist

25. FC #5 � Demonstrate the Time Variables Purpose: Demonstrate potential to use time for documentation and in 4 critical areas Concept: To demonstrate that time can be used as a variable for: Data entry, effective dates/applicable periodicity, planning, and historical purposes Environment: Classified �User� database, using �authorization� data Products: Demonstration of Joint Task Organization process implementation Demonstration of the ability to plan for future operations Final Display: Show a JTO on a map display, over two separate time periods Who: JDS lead

26. FC #6 � Organization, Equipment & Personnel Changes Purpose: Demonstrate that authorization data changes over time can be disseminated to users and effectively managed Concept: Show changes to organization, equipment, and personnel, (O/E/P) using start/termination dates and authorization data Environment: Unclassified �User� system Products: Demonstration of the ability to track changes in authorizations using a start and end date Maintenance of historical integrity of the data Description of approach and process in the CONOPS and Configuration Management Plan Final Display: Before and after displays using web browser-based tool Who: BAH lead

27. FC #7 �Link �Authorized� to �On-Hand� data Purpose: Demonstrate this can be done and once it is done it can be replicated and re-used Concept: Pull a copy from Service databases & map EWIDs to applicable entities Environment: Unclassified and Classified �user� database Products: Copy of Personnel and Equipment files from each of the Services, annotated with EWIDs from the FS slice Demonstration of the ability to use in FC 4, 5, & 6 Final Display: PowerPoint charts or web browser based display showing the information Who: BAH