1. MITRE Public Release Statement
AF Distributed Common Ground System (DCGS) Modernization with Enterprise Services Manager (ESM) Susan Giallombardo Sharon Orser-Jackson
April 28, 2009
MITRE Public Release Statement
Case #

2. ESM Program Objectives ESM Technical Solutions Accomplishments
Outline
AF DCGS Overview
Transforming AF DCGS
ESM Program Objectives
ESM Technical Solutions
Accomplishments
Lessons Learned
What’s Next

3. AF DCGS Overview Users: PACOM, EUCOM, CENTCOM, Air National Guard
Legacy systems: Daily 24/7 operation for 25 years
Complex systems and interfaces
Part of a larger DoD DCGS interoperable ISR enterprise
Tailored DCGS capabilities fielded to meet each Service mission
Global Hawk
Predator
National U2
<speaker notes>
Work Clockwise around the diagram emphasizing the complexity of the system with the distributed sites, varied data, varied sources and multiple customers.
The AN/GSQ-272 “Sentinel” Weapon System is…
A Global Intelligence Surveillance and Reconnaissance (ISR) capability
The ISR provider for the Air Force
The primary warfighting Task Process Exploit Disseminate(TPED)/Task Post Process Use (TPPU) architecture
Enabled by a high capacity network and robust comms
- Legacy single purpose systems spliced together into a roughly integrated system
- -Today Operators and System at the edge of their envelope to provide the basic integrated picture
- - Human intervention required to engage in Time Critical Targeting
- Increasing fire-hose from new collectors
- - Global Hawk, Predator, others
- - Information management issues not fully considered during early phases of program
- OPS TEMPO increasing
- - OEF / OIF/ GWOT
- “Need to break down the Tribes….have machines talk to one another”
General John Jumper’s Speech at the C2ISR Summit Apr 2002
</speaker notes>
Multiple Data Sources and Methods

4. AF DCGS System Background
1998 AF DCGS Program of Record (POR)
9 Program Elements merged into 1 POR
9+ independent systems
Stove-piped operations
2001 – Operational Requirements Document (ORD)
Block upgrade program initiated
Network connectivity across multiple sites
2002 Weapon System Designation
DCGS Integrated Backbone (DIB) developed as part of AF DCGS Block upgrade and released to DCGS community
Provides a commercially-based integration platform (J2EE) for enabling data interoperability and common enterprise services across the Distributed Common Ground Systems (DCGS) Family of Systems (FoS)
Start of Net-Centric operations
Emerging AF DCGS SOA
<speaker notes>
To provide background to the legacy systems that are evolving to SOA we step through the history
Activity supports continued Block upgrades
The DIB is the first step in opening the architecture of the system to expose data and move toward SOA.
Backup data – 2007 v1.2 DIB, 2009 v1.3 DIB
</speaker notes>

5. Evolving AF DCGS SOA Market forces
Innovation by flexible / responsive systems
Provide seamless 24x7 access to services, programs and information
Higher customer expectations
Enhanced mission performance
Streamlining operations
A common view of information and resources
Deliver security of information
Innovate services to offer faster and improved quality of service and deliver new services across multiple channels of distribution
Create reusable straight-through operational processes which optimize linkages with constituents at reduced costs
Leverage industry standards (e.g. Web service standards) to provide single entry connectivity and improved reusability for compliance
<speaker notes>
Market forces that align with AF DCGS operational forces to move to a SOA and more flexible system. These same forces point AF DCGS to need the ability to have more modular systems, reusable processes and leverage industry to reduce cost over the life cycle. Innovative services to improve performance; definition of operational processes to optimize linkages with external organizations; leverage industry standard to provide reusability; common view of information creates interoperability across roles in the enterprise and with external organizations.
Customer Service
Expectations of customer service have changed. AF DCGS has more sources providing data that needs to be processed, exploited and disseminated to a growing number of customers. More Rapid change in a connected world means that the old definition of a single enterprise to support a vertical program is meaningless.
Enhanced Mission Performance - Streamlining Operations
Aging Legacy Systems - Continuous program extensions and modifications to original architectures has left mission critical delivery systems vulnerable to failure through high levels of complexity, technology obsolescence, long lead times for the delivery of new functionality and rising maintenance and development costs. Unless aging legacy systems are overhauled, technology will become an inhibitor to delivering capability and achieving desired mission instead of one of the key enablers.
Leverage industry standards to develop reusable operational processes to optimize interactions across the enterprise.
Use standard web services to provide for flexibility and modularity of the system improving performance.
Customer Expectations - Increases Mission Flexibility
Mission Performance - Reduces Timelines, Days to minutes, Right information to decision makers
Streamline operations - Integrates Sensor Data
Net-centric Interoperability
</speaker notes>
Create interoperability across the battlespace through services linking sensors, analysts, warfighters and mission control
Innovate front line services to offer improved response to real time intelligence data and secure information delivery

6. Enterprise Services Manager Determination
Utilize lessons from commercial industry
IT industry expertise to compliment domain knowledge
Utilize commercial SOA standards
Business Process Modeling
Service identification
Separate the architecting and service identification from the solution design and development
<speaker notes>
Even with experience from the Block upgrades executed for AF DCGS and the emerging SOA the program identified the need to bring in industry IT experience for properly architecting and evolving our SOA.
</speaker notes>

7. Enterprise Services Manager Objectives
Government Chief Architect & Engineer provide guidance, monitoring, approvals
Collaboration/WGs
950 ELSG SMEs
User -SMEs
National Mission Partner SMEs
AF DIB
Requirements analysis
AF DCGS
Business
Process
List
AF DCGS Roadmap Definition
Deployment
Strategies into
AF DCGS
Enterprise
Contract
Award
ESM
RFP
Service
Specs –
NCID S300
Sample
Business
Process
<speaker notes>
Based on the need to transform the AF DCGS to be modular and responsive to changing needs strategies were evaluated.
With the identification of the need for IT expertise strategies were evaluated to leverage those expertise. A Series of guidance and compliance documents were provided in the RFP. The Objectives included 10 technical products to create a foundation of service portfolio and architecture portfolio.
The strategy selected added the benefit to separate the development of the SOA foundation architecture and documents from the design and development of the solution.
The Enterprise Services Manager concept was developed to bring in IT expertise to help build the foundation and manage the modernization of AF DCGS to a Service Oriented Architecture. The products provide the roadmap to move from the pieces to one baseline and guide future modernization.
</speaker notes>
ESM
SOA Best Practices/Guidance
Service Portfolio
DoDAF Products
Business
Process Model

8. ESM Contract Highlights
Competition selected - Centech/IBM
PoP: 5 Mar Mar09
Functionality
Methodology
DCGS Architecture
= “the plan and design”
System Implementation
= “the operational system”
Strategy
= “DCGS’s purpose & goals”
DCGS Strategy
Fire and hope!
DCGS Architecture
Operating Environment
and IT Infrastructure
Architecture Governance
Operational View
System View
Organizational Structure
Change Programs
Soln Outline
Macro Design
Micro Design
Devt, etc.
Program Architecture
Technology
Availability
Intel
Opportunity
IT Strategy
Technical Standards
Roles
Transition Planning
Service Oriented Architecture
Processes & Activities
<speaker notes>
The contract was awarded to CENTECH/IBM team with IBM doing most of the heavy lifting. The period of performance was 1 year
CENTECH IBM team brought industry SOA and Architecture expertise with a strategy, methodology and plan to execute building the foundation for AF DCGS.
</speaker notes>

9. AF DCGS ESM Products & Dependencies
Candidate
Service
Analysis
Operational
Process
Model
DoDAF
Architecture
System
Performance
Spec
DIB Upgrade
report
Interface
Deployment
Plan
Developer
Style
Guide
Market
Research
Governance
Plans
<speaker notes>
Transition to technical strategy and solution
Based on the methodology brought by the CENTECH/IBM team the required technical products of the contract were evaluated for dependencies in development and maintenance.
Introduce the 10 technical products that were to be built with diagram
Then focus to the architecture
</speaker notes>
DoDAF
Architecture 9

10. Two Paths to Service Definition
Operation Process Modeling
Service Discovery
Current OPM
DCGS Incr. 2
CDD
Vignettes
AF DCGS Operational Process
Model
WebSphere
Business
Modeler
Rational
System
Architect
Service – Oriented Modeling & Architecture
OPM
DoDAF Architecture (tool:System
Architect)
GOAL
Services
DoDAF OV Products
DoDAF SV Products
<speaker notes>
A key goal of the Enterprise Services Manager effort was to identify where the AF DCGS system could leverage services. There are 2 parallel paths to a complete service identification. Operational Process Model service identification and a DoDAF Architecture path.
Different tools and techniques were utilized to ensure a complete enterprise architecture was developed and validated services were derived from the Operational Process Model and Architecture
</speaker notes>
Process Model
(OV-6c)
Operational Nodes / Activities (OV-2/5/3)
System Nodes
(SV-1/2)
System Functions
(SV-4/5/6)

11. Integrated Architecture
Operational Node Connectivity
External
Organizations
Enterprise
Management
Operations
Support
AF DCGS
Operational Activity Model
Functional Decomposition
<speaker notes>
The effort developed the 1st AF DCGS Enterprise integrated architecture. Previously pieces of the AF DCGS Weapon System had been documented but this was the first Enterprise effort. This architecture provides the vision and underlying roadmap to modernize the system to a single baseline leveraging SOA to make it more modular and scalable with a smaller maintenance tail.
The complexity of the effort is evident here in the Operational Node Tree which identifies 11 External Organization nodes and 3 internal logical nodes. The color coding is carried through out the architecture products to represent Blue = AF DCGS Enterprise, Green = Enterprise Management, Yellow = Operations, Brown = Operations Support and Grey = External Organizations.
It is important to note we specifically focused on Enterprise Management which is an emerging concept for AF DCGS. Additionally we included the Operations Support activities as these are owned by the weapon system and must occur for the operations to execute but are often left off architectures as “assumed” items or “too much detail”. We felt it important to model the entire system to identify modernization opportunities to permit the system to meet the new demands.
</speaker notes>

12. Integrated Architecture
Functional Data Flow
Functional Data Flow
<speaker notes>
The integrated architecture includes extensive detail on functional data flows that provide for identification and design of a loosely coupled system. Facilitates the validation of areas to leverage service development. Assists with future evaluation of design solutions.
</speaker notes>

13. Extending the Architecture
Enterprise Model*
Industry Design Language
DoDAF Views
Business Processes
Process Layer
Business
Business Logic (BPMN –
Business Process Modeling Notation)
DoDAF OV-3, OV-5, OV-6c
DoDAF OV-7
(Information Demand)
Orchestration Layer (BPEL –
Business Process Execution Language)
DoDAF SV-5 (Matrix Only)
Interface Layer
Service
Exposed Business Services (WSDL – Web Service Definition Language)
Protected Application Services (WSDL)
DoDAF SV-6
Services Interface Specification
<speaker notes>
Recognizing that moving to SOA requires evaluation of different Layers of the Enterprise Model the methodology implemented by the ESM contractor brought a parallel path approach. We have discussed the DoDAF integrated architecture. Now we will look at what IT industry brings to the service definition and the additional foundation documents beyond the architecture.
Utilize lessons learned by commercial industry to help build our SOA
Identification of value added business process & operating models
Provides a framework for IT to build against
Third party generates the business processes
Key to avoiding “technologists” incorrectly defining the business processes as they work to map/implement services
Industry mistakes indicate an ESM is a key part of the process in this regard
Provide the design and development of a candidate AF DCGS Business Process Model and capability release strategy
To continue the migration of AF DCGS to a fully integrated, multi-intelligence (multi-INT) network-centric (net-centric) enterprise
Based on the principles of Service Oriented Architecture (SOA), Modular Open Systems Approach (MOSA), and Open Technology Development (OTD), satisfying AF DCGS requirements/capabilities.
Provides business process model & architecture products
Ensures reduced redundancy/reuse of common functionality
</speaker notes>
DoDAF SV-4, SV-11
Application
Layer
Application Logic (.NET, J2EE, Legacy)
DoDAF OV-1, OV-2, SV-1, and SV-2
Represents multiple layer overlay
.NET
J2EE
Legacy
*derived from “Service-Oriented Architecture” by Thomas Erl
Utilize lessons learned by commercial industry to help build our SOA

14. AF DCGS ESM Products & Dependencies
Market
Research
Candidate
Service
Analysis
DIB Upgrade
Analysis
report
Service –Oriented Modelling and Architecture Identification Phase
System
Performance
Spec
Service
Interface
Spec
Operational
Process
Model
Service
Deployment
Plan
<speaker notes>
Starting with the Operational Process Model product we utilized standard Business Process Modeling notation to capture the AF DCGS process activities. This product was then leveraged in the IBM Service-Oriented Modeling and Architecture process to identify services. This structured process includes a litmus test to validate the service selections. Here we illustrate the steps in the process.
</speaker notes>
DoDAF
Architecture
Developer
Style
Guide
Governance
Plans 14

15. AF DCGS ESM Products & Dependencies
Market
Research
Candidate
Service
Analysis
DIB Upgrade
Analysis
report
System
Performance
Spec
Service
Interface
Spec
Leverage existing business application assets, isolate the impact of change
Prevent “Rip and Replace”
Investment Protection
Service Deployment
Operational
Process
Model
Service
Deployment
Plan
<speaker notes>
The outcome of the architecture and specifications documents is the service deployment. A product of the ESM effort was the Service Deployment Plan which provided a strategy and outline document to leverage for service deployment in a consistent and structured manner. With this consistency and structure AF DCGS can leverage existing systems and make sure the evolution of the weapon system to SOA is efficient. The structure considers the complications of evolving legacy and does not permit wholesale Rip and Replace protecting the current investment.
</speaker notes>
DoDAF
Architecture
Developer
Style
Guide
Governance
Plans 15

16. AF DCGS ESM Products & Dependencies
Market
Research
Candidate
Service
Analysis
DIB Upgrade
Analysis
report
System
Performance
Spec
Service
Interface
Spec
Operational
Process
Model
Operational
Process
Model
Service
Deployment
Plan
<speaker notes>
After discussing the suite of products that capture both the process and the service framework the focus is brought back to the key element the Operational Process Model which we will further detail in the next slides.
DoDAF
Architecture
Developer
Style
Guide
Governance
Plans 16

17. Operational Process Model: Service Identification
<speaker notes>
This portion of the operational process model focus on the Exploitation Plan Creation operational process thread from the integrated architecture.
The process model identified roles, external organizations and the process necessary to execute the mission activities. The process model was put into a database driven tool System Architect to integrate this with the rest of the DoDAF architecture. The iterative creation of the process model provided layers of detail that will be utilized for evolution of the AF DCGS SOA, modeling of the processes to understand change impacts and dependencies.
Process analysis can be conducted for duplication, application of automation. The process model was a driving factor in the SOMA process to identify candidate services for implementation into AF DCGS.
The color coding system for the architecture was carried into the OPM with externals being grey, and operations yellow.
</speaker notes>

18. Service Specification
OPM
Description
Details
Exploitation Plan Creation Service
Create Still Frame Imagery Exploitation Plan
Create Geospatial Exploitation Plan
Create Geospatial Spectral Exploitation Plan
This service will assign exploitation tasks to the resources on the mission for a Still Frame Imagery, Geospatial, or Geospatial Spectral Mission
Use the Personnel Assignments to determine the resources assigned to the mission, and the Sensor Plan to develop the exploitation tasks
Analyze each target to determine the complexity and level of difficulty for exploitation
Retrieve the target history
Retrieve the Personnel Assignments from
the Site Master Schedule for the mission.
Analyze the profile for each person resource to ascertain the skill level
Assign each exploitation task to a resource
Calculating the optimal exploitation plan
Data items:
Site Master Schedule
Sensor Plan
Personnel Profile
Target
Spectral Signatures Library
Geospatial Spectral Exploitation Plan
Input:
Mission ID.
Constraint (any special consideration to be used in the calculation).
Output: Exploitation Plan.
Owner: Site.
Exposure: Internal.
<speaker notes>
The service specification was developed from identification utilizing the architecture and Operational Process Model thread that briefed through out this presentation. Standards were applied to capture the service identification as a piece of the foundation documentation that will be utilized to evolve the weapon system.
The services were identified and captured in the Net-Centric Implementation Document, Service Specification Template S300 (NCID S300) version 2.0 dated 5 September 2006.
</speaker notes>
*Portion of the Standard template: NCIDS S300

19. Provides the foundation for evolving the SOA framework
Accomplishments
1st time AF DCGS enterprise operations modeled
Action: Operational Process Model (OPM) and Enterprise Architecture created through iterative workshop sessions held with the User community and SMEs
Result: Captured all AF DCGS enterprise operational processes to support the future vision
Enterprise Management
Multi-INT Operations
Support activities (e.g. schedule, maintenance and training)
Impact: Provides the vision to smartly execute modernization capability decisions
Developed a solid foundation for AF DCGS SOA modernization
Action: Utilized a 3rd party SOA expert to provide guidance on how to effectively and efficiently modernize AF DCGS
Result: Suite of integrated products created a foundation for modernization
OPM and Enterprise Architecture (Operational, System, and Technical Views)
Candidate Service List, Service Performance Spec, & Service Interface Spec
Developer Style Guide, Service Deployment Strategies, & Governance Plan
DIB Analysis and AF DCGS Recommendations
Impact: Integrated solution set compiles all of the processes, methods, and practices within a single construct to more effectively field capabilities to the warfighter
Provides the foundation for evolving the SOA framework
<speaker notes>
</speaker notes>

20. Lessons Learned
Modeling requires several iterations due to complexity of the processes driving challenges in modeling
Entire AF DCGS Enterprise processes are complex to model (42 Roles, 63 Processes and 1090 Tasks)
Definition of the scope of the effort was a challenge
A team of domain experts and IT experts is required for success
Forging a joint AF–Industry (IT experts) partnership is instrumental in creating an architecture to support a future vision
Partnership requires constant interaction and coordination
Strong teaming and collaboration environment necessary
Subject Matter Experts Workshops were essential to the development of the final ESM products
<speaker notes>
Created operational process models covering the scope of AF DCGS to support the 2015 Vision
63 Processes
1090 Tasks
Identified interactions between AF DCGS processes and Externals
11 external nodes
Identified data that is being produced and consumed
133 Data Objects
Structured as a Role-oriented Model
42 Internal Roles
316 Message Events
362 Decision Gateways
</speaker notes>

21. What’s Next
AF DCGS evolving towards a open and flexible architecture to be able to respond to ever changing mission needs
Operational Process Model supports implementing services where business case makes sense
Leveraging industry standards and processes ensures “best practices” applied
Structured foundation supports a consistent implementation of architecture throughout evolution
<speaker notes>
The suite of products developed positions AF DCGS for continued evolution of its emerging SOA.
</speaker notes>

22. Contact Information
AF DCGS 950 ELSG/KG
Susan Giallombardo
AF DCGS Lead Architect - ESM
Sharon Orser-Jackson
AF DCGS Lead Engineer - ESM