UNIVERSITY OF CALIFORNIA, SAN DIEGO. Multi-Intelligence Distribution Architecture

Transcription

1 UNIVERSITY OF CALIFORNIA, SAN DIEGO Multi-Intelligence Distribution Architecture A Capstone Team Project submitted in partial satisfaction of the requirements of the Architecture-based Enterprise Systems Engineering Leadership Program Lydia Ines Rivera Debbie Salierno Allen Siwap Committee in charge: Professor Harold W. Sorenson, Chair Professor Ingolf Krueger Professor of Practice Alexander Zak Professor Thomas Roemer

2 ii

3 The Team Project prepared by Lydia Ines Rivera, Debbie Salierno and Allen Siwap is approved Professor Ingolf Krueger Professor of Practice Alexander Zak Professor Thomas Roemer Professor Harold W. Sorenson, Chair University of California, San Diego 2013 iii

4 Table of Contents 1.0 Context The Problem Goals The Multi-Intelligence Distribution Architecture MIDA Capabilities Strategic Drivers The Seven S s SWOT Analysis Project Strategy Diamond Framework Technical Organizational Personal (TOP) Analysis Stakeholder Communities Stakeholder Engagement Decision Support System Financial Analysis NPV Analysis NOV Analysis and Real Options Evaluation iv

5 2.0 Problem Formulation Top-Down Development Information Governance Use Cases Query Use Case Subscribe Use Case Integrated Dictionary Architectural Framework DoDAF Viewpoints Cross-Cutting Concerns Traceability and Concordance Complex Event Processing Development Process Solution Approach Domain Model User Request Data Process Data v

6 3.1.3 Exploit Manager Disseminate Data Patterns Model View Controller Specification with Repository Executable Model Service-Oriented Architecture Services Legacy Applications Service Registry Enterprise Service Bus Standards Solution Implementation Implementation Status Implementation Plan References vi

7 List of Figures Figure 1 Swimming in Sensors, Drowning in Data... 1 Figure 2 CV-1 MIDA Enables Access to the GIG... 4 Figure 3 OV-1 MIDA Operational Concept... 5 Figure 4 CV-2 MIDA Capability Taxonomy... 6 Figure 5 Diamond Framework Figure 6 TOP Analysis Figure 7 OV-4 Stakeholder Relationships Figure 8 Defense Acquisition Management Framework Figure 9 Total Worldwide UAV Market Figure 10 Military UAS Production Forecast by Mission Type Figure 11 MIDA Concept Map Figure 12 Use Cases Integration to Viewpoints and Domain Model Figure 13 SOA Governance Processes Figure 14 MIDA Governance Organizational Structure Figure 15 Query Use Case Figure 16 Subscribe Use Case Figure 17 Agile Development Cycle vii

8 Figure 18 DIV-1 MIDA Conceptual Data Model Figure 19 MIDA Domain Model Figure 20 OV-5b User Request Data Activity Diagram Figure 21 OV-6c User Request Data Sequence Diagram Figure 22 OV-5b Process Data Activity Diagram Figure 23 OV-5b Process Data Security Infrastructure Activity Diagram Figure 24 OV-6c Process Data Sequence Diagram Figure 25 OV-5b Exploit Manager Activity Diagram Figure 26 OV-6c Exploit Manager Sequence Diagram Figure 27 OV-5b Disseminate Data Activity Diagram Figure 28 OV-5b Disseminate Data Security Infrastructure Activity Diagram Figure 29 OV-6c Disseminate Data Sequence Diagram Figure 30 OV-6c Disseminate Data Security Infrastructure Sequence Diagram Figure 31 Model View Controller Pattern Figure 32 Specification with Repository Pattern Figure 33 Executable Model First Iteration Initial State Figure 34 Executable Model First Iteration Simulation Figure 35 Executable Model Second Iteration Initial State viii

9 Figure 36 Executable Model Second Iteration Simulation Figure 37 SvcV-4 MIDA Services Taxonomy Figure 38 Rich Services Pattern Figure 39 Transformation from Systems to Services Figure 40 NIST Cloud Computing Reference Architecture Figure 41 Future DoD Cloud Figure 42 DoD Mobility End-to-End Vision Figure 43 DoD Enterprise Cloud Service Broker Figure 44 NCES Services Figure 45 DoD NCES Service Registry Figure 46 SV-1 MIDA Rich Services ESB Figure 47 MIDA Rich Services Pattern Integration Layers ix

10 List of Tables Table 1 MIDA s Goals... 6 Table 2 SWOT Analysis Table 3 Net Present Value Table 4 Initial Capability Real Option Calculator Table 5 Final Capability Real Option Calculator Table 6 Use Case Actors Table 7 Query Use Case Requirements Table 8 Query Use Case Characteristics Table 9 Query Use Case Main Success Scenario Table 10 Query Use Case Scenario Extensions Table 11 Query Use Case Open Issues Table 12 Subscribe Use Case Requirements Table 13 Subscribe Use Case Characteristics Table 14 Subscribe Use Case Main Success Scenario Table 15 Subscribe Use Case Scenario Extensions Table 16 Subscribe Use Case Scenario Variations Table 17 Subscribe Use Case Open Issues x

11 Table 18 AV-2 Integrated Dictionary Table 19 MIDA DoDAF Viewpoints Table 20 StdV-1 Standards Table 21 CV-3 MIDA Capability Phasing xi

12 List of Abbreviations ABAC Attribute-based Access Control AESE Architecture-based Enterprise Systems Engineering BHAG Big Hairy Audacious Goal CEP Complex Event Processing CIO Chief Information Officer COCOMS Combatant Commands COI Community of Interest C2 Command and Control C4ISR Command, Control, Communications, Computers, Intelligence Surveillance, and Reconnaissance COMINT Communications Intelligence DDMS DoD Discover Metadata Specification DES Data Encoding Specification DI2E Defense Intelligence Information Enterprise DIL Disconnected, Intermittent and Low-bandwidth DISA Defense Information Systems Agency xii

13 DNI Director of National Intelligence DoD Department of Defense DoDAF DoD Architecture Framework DoDIE DoD Information Enterprise DoD IEA DoD Information Enterprise Architecture EDA Event-Driven Architecture ELINT Electronic Intelligence ESB Enterprise Service Bus GIG Global Information Grid HTML Hypertext Markup Language HTTP Hypertext Transport Protocol IA Information Assurance IaaS Cloud Infrastructure as a Service IC Intelligence Community IMINT Imagery Intelligence ISM Information Security Markings ISR Intelligence, Surveillance, and Reconnaissance xiii

14 IT Information Technology JIE Joint Information Environment JWICS Joint Worldwide Intelligence Communication System MILOPS Military Operations MVC Model View Controller NIEM National Information Exchange Model NIPRNET Unclassified but Sensitive Internet Protocol Router Network NG Northrop Grumman NGAS Northrop Grumman Aerospace Systems NIST National Institute of Standards and Technology NOV Net Option Value NPV Net Present Value NRT Near Real Time PaaS Cloud Platform as a Service PKI Public Key Infrastructure QoS Quality of Service RBAC Role-based Access Control xiv

15 SA Situational Awareness SaaS Cloud Software as a Service SIGINT Signals Intelligence SIPRNET Secret Internet Protocol Router Network SOA Service-Oriented Architecture SME Subject Matter Expert SSL Secure Socket Layer SWOT Strengths, Weaknesses, Opportunities and Threats TS SCI Top Secret Sensitive Compartmentalized Information UCORE Universal Core UDDI Universal Description, Discovery, and Integration Language WSDL Web Service Description Language XML Extensible Markup Language xv

16 ABSTRACT OF THE THESIS Multi-Intelligence Distribution Architecture By Lydia Ines Rivera Debbie Salierno Allen Siwap Architecture-based Enterprise Systems Engineering Leadership Program Professor Harold W. Sorenson, Chair Professor Ingolf Krueger Professor of Practice Alexander Zak Professor Thomas Roemer xvi

17 The Global War on Terror has led to a dramatic buildup of ISR sensor platforms over the past decade. But the Processing, Exploitation, and Dissemination (PED) systems that serve these platforms have not been able to keep pace with the enormous amount of data collected. The information deluge is exacerbated by the tendency of each organizational entity to build stovepipe systems with incompatible data formats, poor interoperability, and limited data sharing policies. The Federal government has spoken, and their message is clear: we need to dramatically change the way we do business. In December 2012, the Federal Chief Information Officer (CIO) published the National Strategy for Information Sharing and Safeguarding, which defines core principles and goals of a transformational change. This effort will be championed and implemented through guidance and governance provided by the office of the DoD CIO. As a major contractor on many of our nation s intelligence systems, Northrop Grumman has a stake in the robustness of the PED cycle. Through the Multi-Intelligence Distribution Architecture (MIDA), Northrop Grumman is posed to adapt and thrive in the rapidly evolving DoD Joint Information Enterprise. MIDA is a reference architecture of the PED cycle that embraces the new information sharing guidelines, while providing scalability and fast query response times. The MIDA reference architecture consists of the UML diagrams, Use Cases, DoDAF 2.0 Views, an executable model, as well as strategic and business case analyses. Next steps are outlined, including plans for an agile development process that implements the MIDA reference architecture. xvii

18 1 1.0 Context 1.1 The Problem In 2009, Lt. Gen. David A. Deptula, Air Force Deputy Chief of staff for Intelligence, Surveillance and Reconnaissance (ISR) famously said: We re going to find ourselves in the not too distant future swimming in sensors and drowning in data. Figure 1 Swimming in Sensors, Drowning in Data He was right. Increasing data volumes have diminished our ability to store, retrieve, process and exploit data within mission-critical timelines. Despite billions spent on these systems, few talk to each other. 1 The large volume of intelligence data overwhelms the limited number of analysts available to process the data. And because the data is not tagged and stored in a standard format, 1

19 2 the ability to find and exploit the data is compromised. To make matters worse, a user of one system may never see valuable, pertinent data being collected by another system, because an infrastructure and a policy is not in place to share the data. In many cases, the military continues to encounters operational problems that put the soldier at risk due to lack of data access. 2 These issues are all symptoms of a broken Processing, Exploitation, and Dissemination (PED) cycle. According to Gen. Robert Kehler, commander of the United States Strategic Command, We are collecting 1,500 percent more data than we did five years ago. At the same time, our head count has barely risen. 3 In Afghanistan alone, the military collects more than 53 terabytes a day. 4 This situation is a product of the Global War on Terror (GWOT) and the need for each service to address their own urgent individual requirements without the guidance or enforcement of overarching data management or data sharing policies. The result is an impressive array of collection systems featuring numerous advancements in sensor technology, all sending a plethora of data to disjointed and stove-piped PED systems on the ground, which are ill-equipped to effectively deal with all the data. The need for machines to communicate and synthesize information, known as interoperability, is paramount to the effectiveness of our military. Without interoperability, our national defense compromised by the inability to understand the relevance of the vast amount of data by these disparate systems

20 3 Ironically, non-interoperability is a self-inflicted problem resulting from US government agencies failure to enforce governance policies. Northrop Grumman s customers, military and intelligence agencies, are legally bound to a procurement process that has institutionalized the development of systems. 5 Interoperability plays an important role in the success of military operations. 6 United States military forces need the ability to execute joint operations with different friendly military groups and sharing information is critical. As a major contractor on many of our nation s intelligence systems, Northrop Grumman has a stake in the robustness of the Processing, Exploitation, and Dissemination (PED) cycle. Our sector in particular, Northrop Grumman Aerospace Systems (NGAS), depends on the ability to design and develop new collection systems to grow our business. Business growth opportunities are hindered by the view that the US Military should not be adding more collection systems, and instead should focus on making the PED functions work more effectively with the systems we already have. For example, in 2012, the Air Force cut future purchases of Reaper UAVs in half (from 48 to 24) because they didn t have the manpower to operate and process the data from even more aircraft. Solving the PED problem is paramount to NGAS s business prospects. 1.2 Goals In December 2012, the Federal Chief Information Officer (CIO) published the National Strategy for Information Sharing and Safeguarding, which defines core principles and goals for a sweeping, transformational change. This effort will be championed and implemented through guidance and governance provided by the office of the DoD CIO. A number of related initiatives are part of the DoD Transformation, including the DoD CIO s 10-Point Plan for IT Modernization, DoD CIO Cloud Computing Strategy, DoD Mobile Device Strategy, and the DoD

21 4 CIO Campaign Plan Summary. This DoD guidance includes the use of standard data metadata tags, an enterprise cloud, secure sharing of intelligence data across multiple Communities of Interest (COI), and Governance policies to enforce compliance. 1.3 The Multi-Intelligence Distribution Architecture The Multi-Intelligence Distribution Architecture (MIDA) is Northrop Grumman Aerospace Systems (NGAS) answer to the transformation underway in the DoD. Its implementation will provide the net-enabled solution necessary to interoperate in the DoD s Global Information Grid (GIG), as shown in Figure 2. Figure 2 CV-1 MIDA Enables Access to the GIG 1.4 MIDA Capabilities MIDA is an enterprise system that provides a Web-based (thin client) tool for access to intelligence data on a Private Big Data Processing Cloud. MIDA s architecture is built upon the use of DoD standard data schemas, cloud storage technologies, and multi-level secure data access through the use of enterprise-wide User Attribute Based Access Control (ABAC) policies.

22 5 Figure 3 is a high-level operational concept (OV-1) of MIDA. Existing collection platforms, such as the Global Hawk, Triton, Unmanned Combat Aerial System (UCAS), and Firescout will interface with MIDA using data interface adapters that transform their ingested data into appropriate DoD Discover Metadata Specification (DDMS) and National Information Exchange Model (NIEM) formats. Users who have registered with MIDA s subscription service will receive collected data that meets their specifications in near real time. And at any time, from any location, a user can use MIDA s query app to receive timely, actionably intelligence from all MIDA-ingested data sources, as long as they are an authorized user of the DoD cloud. Figure 3 OV-1 MIDA Operational Concept The capabilities of MIDA are shown in Figure 4, the MIDA Capability Taxonomy (CV-2).

23 6 Process Exploit Disseminate Store Infrastructure Governance Ingest Data Service Tag data Service Fuse Multi- INT data Analyze Data (future) Subscribe to NRT data feed Query Data Report Data Display Data Store Data in Cloud Hadoop Distributed File System Store data in Cloud using NCES Authenticate Authorize Access Control Manage Certificates Logging Messaging Routing Standards and Policies Monitoring and Compliance Figure 4 CV-2 MIDA Capability Taxonomy MIDA s goals, shown in Table 1, are based on solving high priority problems identified by the DoD CIO. Table 1 MIDA s Goals Problem Large volumes of data cannot be effectively analyzed Standard data formats are not being used, compromising the ability to find and exploit related information Access to data is based on location and organization Lack of security mechanisms requires DoD and mission partners to build unique infrastructures (per coalition) to enable information access Goal Manage large diverse data sets through the use of cloud computing technologies and parallel computing clusters Deployment of standardized data interfaces makes data visible and accessible to all authorized users Access to information is based on who you are and your information needs Enterprise security mechanisms that enable secure connection and control across mission partner network boundaries

24 7 Problem Fusion by the analyst is manually intensive and time consuming across federated enterprises Single-threaded mission thinking leads to duplication of capabilities and higher costs Goal Single query search across many information sources within the DoD cloud Enterprise thinking managed through the establishment of strong but lean governance 1.5 Strategic Drivers We propose to develop a Multi-Intelligence Distribution Architecture (MIDA) solution for Northrop Grumman to address the needs of the US military and intelligence agencies. These communities suffer from a shortage of actionable information. Military agencies own systems with similar capabilities however the systems have slight differences to address specific requirements. The intelligence community cannot expedite the delivery of actionable data. The disjointed systems do not provide an operational environment that gets data to the Warfighter faster. The military communities are dependent on information control as the path to get ahead of the enemy. A solution is needed to standardize data formats managed by a robust set of governance policies. This solution needs to delivery timely actionable data. This solution is MIDA. MIDA is an ideal enterprise for Northrop Grumman to solve the problem by enabling interoperability in near-real time. MIDA is an enterprise architecture that bridges disparate data and communication standards. MIDA provides data that is not previously available. MIDA will increase mission capabilities. The dissemination of data will be secured and provide intelligence to the soldiers The Seven S s McKinsey Consulting developed the Seven S s model (7S). The 7S model addresses the primary components of an organization. The model determines whether or not those components

25 8 are aligned with the business strategy. 7 This 7S model allows us to understand the complementary aspects of the Northrop Grumman organization. It will help the MIDA team make an assessment of the company and identify paths to solve complex problems. Before we began performing architecture development, we performed a McKinsey 7S Framework assessment and a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis on the MIDA concept (affectionately known as a Big Hairy Audacious Goal, or BHAG). The results of these efforts are summarized below Strategy Our strategy is to design a multi-intelligence distribution architecture. This project is aligned with the current Northrop Grumman s business capture efforts. Northrop Grumman is successful at leveraging the diversity of their products, customer and skill set to maximize our efficiencies of our similarities. This solution provides Northrop Grumman the ability to continue increase our market share while delivering superior quality products, and provide the tools necessary to our customer to make intelligent decisions with confidence Systems Northrop Grumman has well-established System Engineering processes as well as business processes for the success of their entire portfolio. Northrop Grumman s technical teams are aligned with the business teams to execute plans, identify and realize process improvements and maximize resources. Northrop Grumman has weekly and monthly meeting to review schedules, budget reviews with the teams and customers. Northrop Grumman always applies best practice guidelines to provide an environment that promotes productivity and execution. 7

26 Structure Northrop Grumman cross-functional organizations allow the opportunity designate the acquired skill set across all programs. It also provides the tools and processes to delivery products effectively. This functional matrix provides the flexibility to execute, a cross-disciplinary understanding of business development and engineering processes and the opportunity to be creative Staff Northrop Grumman has a cross functional organizations which has the expertise in system requirements development and verification, system architecture development, integration, test with verification and validation and logistics groups. Northrop Grumman s goal is to be the industry s employer of choice. It is committed to diversity in the workplace. Executive leadership believes that diversity of thought will produce the most creative solutions. This diverse team fosters new ideas to better execute and deliver products. The power of their performance will deliver value to our customers and shareholders Style The culture in the company is one of pride and commitment to our products. Leadership demonstrates a high level of engagement with their teams. They have established a lot of great programs to recognize teams for their accomplishments. It is important for the organization to support the community. 8 9 They have established scholarships for the employee s children 10 as well as making numerous donations to various non-profit organizations /Pages/default.aspx

27 Skills Northrop Grumman has a diverse talent base and the required skills for our project. They have the expertise in system engineering principles. Northrop Grumman strives to hire the right skill set. 12 They also have a continuous education program to support their employees to learn new technologies and get training. They also have lunch and learn programs to discuss current projects or new tools Shared Values Northrop Grumman and the MIDA team share a common desire to build systems that exceed customer expectations and deliver quality products timely. 13 The MIDA project is aligned with this value. Northrop Grumman has a team environment that allows collaboration and discussions of new ideas. Northrop Grumman takes pride in bringing the teams together for great community causes SWOT Analysis Before we began architecture development, we performed a SWOT assessment. The results of this assessment confirmed that the MIDA concept was strongly aligned with the NGAS business strategy 14 and that objective of MIDA to improve the PED cycle - is obtainable by NGAS. The SWOT analysis is summarized in Table Opens-2010-NextGen-Engineers-Scholarship-Competition.html?print= ault.aspx s.aspx 14

28 11 Table 2 SWOT Analysis 1.6 Project Strategy Diamond Framework MIDA was evaluated using the Diamond Framework 15 to ensure alignment with Northrop Grumman s strategy and to increase strategy refinement. This framework analyzes how the different components of the overall strategy fit together. It evaluates five key areas for a sound strategy: economic logic, arenas, vehicles, differentiation and staging as represented in Figure

29 12 Figure 5 Diamond Framework Staging: Internal research and development funding is necessary for new technologies. Stage 1: Internal research and development funding to develop new technologies Stage 2: Integrate technologies into existing product line and market new capabilities Arena: Aerospace System in the leader in Unmanned Systems and C4ISR US and International Customers Vehicles: Installation into Northrop Grumman existing products Existing partnerships with major suppliers Licensing Agreements

30 13 Differentiators: Northrop Grumman is the industry leader in Unmanned Systems Proven capabilities as lead systems integrator Bargaining power with suppliers Economic Logic: The US defense budget may be shrinking, but the Unmanned Systems market is forecasted to grow ($86.5 Billion over the next 5 years) 16 Emerging market for sensor data fusion and sharing Our architecture is aligned with our companies core focus on growing our Unmanned Systems and C4ISR business with affordable solutions for our customers Technical Organizational Personal (TOP) Analysis TOP Analysis is another approach that to analyze our project and verify that our project is aligned to Northrop Grumman s strategy. The MIDA solution is leveraging Northrop Grumman core technologies in the same market segments. Northrop Grumman has strong supplier relationships and a great skill set internally that can develop MIDA. Figure 6 provides the TOP analysis and validates that MIDA is aligned with Northrop Grumman s current strategy. 16

31 14 Figure 6 TOP Analysis 1.7 Stakeholder Communities We began the AESE program in search of a project that would be of value to NGAS, and by extension, to our NGAS Unmanned Systems customer base. Our customer base is primarily the US Military Services and Intelligence Communities that depend on data collected by sensors onboard our airborne unmanned ISR collection systems. During meetings with several NGAS Directors, we identified capability gaps within the ISR market that would be of high interest to NGAS and to our customers. With the encouragement of our stakeholders, we set out to create an architecture that targeted the following improvements in the Processing, Dissemination, and Exploitation cycle: 1) Use standard formats and meta data tags (Processing Improvement) 2) Use the metadata tags to exploit more data (Exploitation Improvement) 3) Use security and governance policies to share more data (Dissemination Improvement)

32 15 One of our stakeholders emphasized the value of understanding the user experience. There are a number of different types of users of a PED system, but for this initial effort we focused on the two principle users, the warfighter who needs data and the analyst who exploits data. Figure 7 shows a concept map we created in the early stages of our project and serves as an OV-4, an Organizational Relationships chart. The concept map shows the extensive interdependencies between the various stakeholders, and how the functions, structures, and processes of the various stakeholders are driven by strategy. As indicated in the lower left corner of the concept map, we did recognize from the beginning the investigative and advisor roles that government support agencies provide to the Federal Government including the DoD and IC. But we underestimated the degree of influence they have and how quickly new guidance and enforceable directives can come about. In the past few months it has become apparent that we need to pay particular attention to the IT transformational changes being implemented throughout the Federal Government. We have spent considerable effort working to understand the impacts of these changes. Because we planned a SOA approach from the outset, the impact to the logical architecture has been minimal. The majority of the impact has been to the way we deploy capabilities to our customers. MIDA will be deployed as an enterprise system that provides a Web-based tool for access to intelligence data on the DoD s Private Big Data Processing Cloud. Our physical and deployment diagrams will conform to the new DoD approach accordingly.

33 Figure 7 OV-4 Stakeholder Relationships 16

34 Stakeholder Engagement In the early stages of the problem identification and use case development process, we engaged with our internal senior stakeholders within NGAS. We have followed-up these initial feedback sessions with senior staff systems engineers with domain experience applicable to our project. While we did not have direct access to our end users, we were able to consult with NG employees with ISR field experience. To supplement our understanding of the user experience, we have been monitoring user community forums and websites. As we go forward and evolve into a more formal effort, we expect direct user feedback will be possible, and that it will occur as a natural part of our agile process. 1.8 Decision Support System The Decision Support System for our architecture is based on the Defense Acquisition Management Framework. The Defense Acquisition Management Framework will be used as a roadmap for activities and milestones for our architecture during R&D, Deployment, and Operations. Each milestone is a decision point for our stakeholders and provides a feedback loop to our architecture development.

35 18 Figure 8 Defense Acquisition Management Framework The R&D phase will consist of research, development, and demonstration of the system. Key milestones for our decision makers will be a Systems Requirements Review, Preliminary Design Review, Critical Design Review, and Test Readiness Review. These milestones need to be met before we can design and demonstrate our system. The Deployment phase will consist of low rate initial production and deployment of the system in theater. Key milestones for our decision makers will be an Initial Production Readiness Review and Deployment Readiness Review. These milestones need to be met before we can start low rate initial production and deployment of our system in theater. The Operations phase will consist of follow on production and sustainment of the system in theater. Key milestones for our decision makers will be a Production Readiness Review, Operational Readiness Review, and Operational Evaluation. These milestones need to be met before we can deploy our system for operations.

36 Financial Analysis Our architecture will initially target the US UAV market which currently spends the most. Domestic UAV sales are currently at $4 billion for 2012 and forecasted to grow to $7 billion by Additionally, a majority of the forecasted UAV sales are for ISR applications. We expect to capture some of this market by integrating existing UAV systems with our enterprise architecture. Figure 9 Total Worldwide UAV Market

37 20 Figure 10 Military UAS Production Forecast by Mission Type NPV Analysis Net Present Value (NPV) analysis was performed to determine the upfront investment required and the expected return on investment. We estimate that it will take 2 years of R&D at $3.5 million/year followed by 2 years of Deployment at $9 million/year. The R&D phase will consists of development and demonstration of the system. The Deployment phase will consist of a low rate production and deployment of the system into theater. We expect a return of $100 million/year after the first year of Operations. Our total NPV is estimated at $450 million over 11 years. 18

38 21 Table 3 Net Present Value Net Present Value Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 Year 9 Year 10 Year 11 R&D $3.5 $3.5 Deployment $9.0 $9.0 Operations $100.0 $100.0 $100.0 $100.0 $100.0 $100.0 $100.0 Net Free Cash Flow -$3.5 -$3.5 -$9.0 -$9.0 $100.0 $100.0 $100.0 $100.0 $100.0 $100.0 $100.0 NPV $ Notes: 1. Dollars are in millions 2. Discount Rate (DR) = 5% NOV Analysis and Real Options Evaluation Net Option Value (NOV) analysis was performed to determine the real options for incremental investing in the architecture. Real options provide us with a method to split our investment into phases with the option to proceed with the investment or discontinue funding. We decided on two options for investment in R&D. Since we are using agile development methods, we can have a deployable system with initial capabilities after 1 year of R&D. Full capabilities will require an additional year of R&D. The initial and full capability description is described in Table 21 CV-3 MIDA Capability Phasing. The initial capability option will require 1 year of R&D at a cost of $3.5 million/year. We estimate that it will take 2 years of deployment at a cost of $9 million/year with a profit of $50 million/year during operations. This results in an NPV of $258 million and an NOV of $303 million. The initial capability option is summarized below: R&D: $3.5 mil over 1 year Deployment: $18 mil over 2 years Operations: $50 mil profit each year NPV = $258 mil NOV = $303 mil

39 22 Table 4 Initial Capability Real Option Calculator Expiration (T) 2 Volatility (σ) 0.9 Risk Free Rate (r) 5% Discount Rate (DR) 5% Real Option Calculator NPV Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 Year 9 Year 10 Year 11 Option Purchase $3.3 $3.5 Option Exercise $16.7 $9.0 $9.0 Asset Value $321.9 $50.0 $50.0 $50.0 $50.0 $50.0 $50.0 $50.0 $50.0 Option Value $306.9 Net Option Value $ d d N(d1) 1 N(d2) 1 C(S,0) $ NPV $ $3.50 -$9.00 -$9.00 $50.00 $50.00 $50.00 $50.00 $50.00 $50.00 $50.00 $50.00 Notes: 1. Option Purchase = NPV of Investment to Purchase Option 2. Option Exercise = NPV of Investment to Exercise Option 3. Asset Value = NPV of Projected Free Cash Flow From Owning Asset (Revenues - Costs) 4. Option Value = BS Calculation Assuming No Dividends and Constant Interest Compounded at Rate r 5. Net Option Value = Option Value minus Option Purchase The final capability option will require 2 years of R&D at a cost of $3.5 million/year. We estimate that it will take 2 years of deployment at a cost of $9 million/year with a profit of $100 million/year during operations. This results in an NPV of $451 million and an NOV of $555 million. The final capability option is summarized below: R&D: $7 mil over 2 years Deployment: $18 mil over 2 years Operations: $100 mil profit each year NPV = $451 mil NOV = $555 mil

40 23 Table 5 Final Capability Real Option Calculator Expiration (T) 2 Volatility (σ) 0.9 Risk Free Rate (r) 5% Discount Rate (DR) 5% Real Option Calculator NPV Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 Year 9 Year 10 Year 11 Option Purchase $6.5 $3.5 $3.5 Option Exercise $16.7 $9.0 $9.0 Asset Value $576.5 $100.0 $100.0 $100.0 $100.0 $100.0 $100.0 $100.0 Option Value $561.5 Net Option Value $ d d N(d1) 1 N(d2) 1 C(S,0) $ NPV $ $3.50 -$3.50 -$9.00 -$9.00 $ $ $ $ $ $ $ Notes: 1. Option Purchase = NPV of Investment to Purchase Option 2. Option Exercise = NPV of Investment to Exercise Option 3. Asset Value = NPV of Projected Free Cash Flow From Owning Asset (Revenues - Costs) 4. Option Value = BS Calculation Assuming No Dividends and Constant Interest Compounded at Rate r 5. Net Option Value = Option Value minus Option Purchase

41 Problem Formulation sections. Our problem formulation is described in Figure 11 MIDA Concept Map and the preceding Figure 11 MIDA Concept Map 2.1 Top-Down Development As part of the development of MIDA, we performed extensive research about the existing problem that our customer has been experiencing for years. The customer collects large amount

42 25 of data from different sources. The ability to collect data is a capability that the customer knows well. The data is located in many disjointed repositories. The challenge is the difficulty to bring data together from multiple sources in support of the mission. The process of ingesting, fusing and dissemination of data to provide intelligent, actionable data, is the biggest challenge the customer encounters today. These tasks are extremely time-consuming as data is located at different repositories. The more the MIDA team researched our big hairy audacious goal (BHAG), the clearer it became that data is not used to optimize mission plans. When it goes to development, Northrop Grumman uses system engineering principles and processes. Northrop Grumman regularly meets with the customer to understand the problem. MIDA as part of the Northrop Grumman portfolio will be designed, implement, test, deployed and validated using same System Engineering principles. We met with internal stakeholders to determine their areas of interest and goals. Northrop Grumman will proceed to develop an Operational Concept document to description of the system and its corresponding sub-systems. We learned about the problem domain and read about the needs of the users and determined their goals. We discussed the problem domain with the internal stakeholders to gather domain information and identify the strategic gaps in the problem. We also researched the existing legacy systems that we may have to interact with as well as the future services and interfaces. We also need to review physical architecture legacy systems, future services and the interfaces. Part of the system engineering process is to define the operational concept for our architecture. This document describes our architecture from the user standpoint. It also includes the system capabilities and how they may achieve the desired end state. In the AESE Program, we developed Department of Defense Architecture Framework (DoDAF) viewpoints instead of an operational

43 26 concept document. If the project is added to Northrop Grumman portfolio, an operational concept will be developed. The Operational concept is used to expand the use cases. The use cases describe the scenarios between the user and the systems for which the architecture is designed. The scenarios represent the interaction between the user and the system. The use cases will help define the domain model in UML. Figure 12 represents how use cases integrated into the viewpoints and domain model. Figure 12 Use Cases Integration to Viewpoints and Domain Model Once the primary use cases were identified for the different primary scenarios, the capabilities and requirements were defined to create the views for the architecture. We proceeded to define the classes. For each class, the attributes and operations were identified based on the use cases. It is also required to define the rules for each operation. Behavioral diagrams were built using the use cases as the starting point. In order to continue decomposing the architecture, we developed activity, sequence and state machine diagrams. We

44 27 were able to identify operational views as well as identify services. Iterations were necessary to ensure concordance, then we were able to finalize the logical architecture. All the diagrams will provide the different characteristics of the architecture. We also have to develop the Physical Architecture Description document. This document represents the logical view of the physical components and how they are linked together logically. This is also an iterative process until the component diagrams and deployments are well defined and interconnections are established. It is important to ensure that the physical aspects are interconnected to support the logical expected behavior of the architecture thus reaching concordance. Through the entire process it is important that we maintain an Integrated Dictionary. 2.2 Information Governance MIDA will follow four governance processes essential to the success of the MIDA enterprise. A high level view of these processes are shown in Figure 13.

45 28 Figure 13 SOA Governance Processes The four governance processes: Compliance, Vitality, Communication, Exceptions & Appeals all interact, with each process feeding each other. While each process is an important part of our overall governance strategy, the compliance process and the vitality process are expected to be the most active and instrumental to the success of MIDA. Our vitality process will ensure that MIDA is using the most important emerging technologies, while our compliance process will ensure that we stay in compliance with DoD standards and policies, no small feat in these transformational times. These processes will be executed in an agile fashion by two NGAS teams: the MIDA Project Design Authority, primarily a technical team with day-to-day MIDA responsibilities, and a NGAS Advisory Group comprised of sector and division leadership. As shown in Figure 14, the MIDA Project Design Authority will include the chief architect, technical project manager, the lead intelligence data analyst, and a DoD Standards and Policy Watchdog. The DoD Standards

46 29 and Policy Watchdog will keep a close eye on what the DoD is doing in the DoD Joint Information Enterprise and on internal MIDA development efforts. The MIDA Design Authority will meet regularly with the NGAS Advisory Group, which provides governance guidance and strategic oversight. Figure 14 MIDA Governance Organizational Structure Part of the objective of the MIDA and NGAS governance bodies is to not only stay in compliance with DoD governance policies and technical standards, but to be a Mission Partner and lead contributor in the processing, exploitation, and dissemination of intelligence data in the evolving DoD Information Enterprise. Information Governance on MIDA will be consistent with the DoD IT Governance model led by the DoD CIO. The DoD CIO has established an overarching management construct consisting of an enterprise architecture, a policy framework and governance to ensure compliance with the management and evolution of the DoD Information Enterprise. The policy framework

47 30 will consolidate multiple processes for faster coordination, decision making, and resolution. Fundamental to this approach is an enterprise perspective and the elimination and prevention of information stovepipes. MIDA is fully on-board with this enterprise perspective and objective. 2.3 Use Cases Our architecture has 2 Use Cases: Query and Subscribe. The Cockburn template was used for developing our use cases. The following table describes the actors in our use cases. Table 6 Use Case Actors Actor Description Warfighter Analyst Administrator Collector User that is located in the battlefield. This user will submit queries to the systems to get an assessment in an area of interest. User will be submitting queries to the system. This user collects information and formulates useful analysis for the purpose of mission planning. Creates user accounts; maintains the system and grants access and monitors the system to ensure that the governance policy is followed. Intelligence data collection sources such as UAV sensors, Satellites, and Ground Control Segments Query Use Case The Query Use Case is shown in the figure below. The tables below describe the use case requirements, characteristics, scenario, and any open issues.

48 31 Figure 15 Query Use Case Table 7 Query Use Case Requirements ID UC-1.1 UC-1.2 UC-1.3 UC-1.4 UC-1.5 UC-1.6 Requirement The system shall provide the capability to search for data based on the user credentials The system shall a means for selecting an existing query The system shall a means for creating a customized query The system shall persist the request submitted The system shall provide a means for retrieving data The system shall provide a display for retrieving data

49 32 Table 8 Query Use Case Characteristics Goal in Context: Scope: Level: Pre-Condition: Success End Condition: Minimal Guarantees: Primary Actor: Trigger Event: User submits a query to MIDA and receives data requested via the MIDA display view User logins into the MIDA system and sends a request. The request goes through MIDA to the database and extracts data. The data is sent back to user via a display. Strategic User must login with a userid and a password into the system in order to submit a request MIDA provides the data requested by the user MIDA is up and running and user must enter userid and password before their third attempt login Analyst/Warfighter, Application The user selects the desired query option: existing query or customized query Table 9 Query Use Case Main Success Scenario Step Actor Action Description 1 Analyst/Warfighter User enters User Id and password to login into the system 2 Analyst/Warfighter User selects type of query: existing query or customized query 3 Analyst/Warfighter User presses the enter key to submit the request 4 MIDA UserRequest Manager receives the request, searches the repository, and processes relevant data based on the request criteria 5 MIDA Results are collected and send to DisseminateManager 6 MIDA DisseminateManager service sends data to the User s Display

50 33 Table 10 Query Use Case Scenario Extensions Step Actor Action Description 1a Analyst/Warfighter User enters user ID and password incorrectly three times 1b MIDA MIDA locks user out of the systems and sends a message to User to contact the Administrator 5a MIDA MIDA does not find relevant data and sends an error message to the User that data was not found to try a different query Table 11 Query Use Case Open Issues Issue ID Issue Description 1 What types of queries are relevant to the Analyst? Are they different? 2 What types of queries are relevant to the Warfighter? 3 How the system manages disadvantage user? A person with limited bandwidth or processing resources 4 How the dissemination of data needs to address different types of displays i.e. mobile, tablets Vs. computers? Subscribe Use Case The Subscribe Use Case is shown in the figure below. The tables below describe the use case requirements, characteristics, scenario, and any open issues.

51 34 Figure 16 Subscribe Use Case Table 12 Subscribe Use Case Requirements ID UC-2.1 UC-2.2 UC-2.3 UC-2.4 UC-2.5 UC-2.6 UC-2.7 Requirement The system shall provide the capability to search for data based on the user credentials The system shall a means for selecting an existing query The system shall a means for creating a customized query The system shall provide a means for cancelling the subscription The system shall persist the request submitted The system shall provide a means for retrieving data The system shall provide a display for retrieving data

52 35 Table 13 Subscribe Use Case Characteristics Goal in Context: Scope: Level: Pre-Condition: Success End Condition: Minimal Guarantees: Primary Actor: Trigger Event: User subscribes to receive data based on a query or set of queries selected User logins into the MIDA system and sends a request. The request goes through MIDA to the database and extracts data. The data is sent back to user via a display. Strategic User must login with a userid and a password into the system in order to subscribe MIDA provides the data requested by the user based on the subscription request criteria MIDA is up and running and user must enter userid/password before their third attempt login Analyst/Warfighter, Application The user selects the desired subscription option: existing query or customized query Table 14 Subscribe Use Case Main Success Scenario Step Actor Action Description 1 Analyst/Warfighter User enters User Id and password to login into the system 2 Analyst/Warfighter User selects type of query: existing query 3 Analyst/Warfighter User selects the subscription option: frequency of subscription, data format for notifications 4 MIDA User press the enter key to submit the request 5 MIDA MIDA displays the criteria selected for the subscription 6 Analyst/Warfighter User confirms subscription by pressing the enter key 7 MIDA MIDA updates the user s profile to record subscription

53 36 8 MIDA MIDA sends a confirmation to the display that the subscription is recorded Table 15 Subscribe Use Case Scenario Extensions Step Actor Action Description 1a Analyst/Warfighter User enters user ID and password incorrectly three times 1b MIDA MIDA locks user out of the systems and sends a message to User to contact the Administrator Table 16 Subscribe Use Case Scenario Variations Step Actor Action Description 2a Analyst/Warfighter User enters a customized query 2b MIDA User press the enter key to submit the request 2c MIDA UserRequest Manager receives the request, searches the repository, and processes relevant data based on the request criteria 2d MIDA Results are collected and sent to DisseminateManager 2e MIDA DisseminateManager service sends data to the User s Display 2f MIDA UserRequest Manager receives the request, searches the repository, and processes relevant data based on the request criteria 2g MIDA Results are collected and send to DisseminateManager 2h MIDA DisseminateManager service sends data to the User s Display 3a Analyst/Warfighter User cancels the subscription 3b MIDA MIDA sends confirmation of the cancellation to the subscription

54 37 3c Analyst/Warfighter User confirms cancellation request 3d MIDA MIDA removes subscription from the User s profile Table 17 Subscribe Use Case Open Issues Issue ID Issue Description 1 Do we want to notify user of new data available for his subscription via ? 2.4 Integrated Dictionary Table 18 is MIDA s integrated dictionary (AV-2) specifying definitions of the terms used throughout the definition of the MIDA architectural model. Table 18 AV-2 Integrated Dictionary ABAC Accessible Architecture Architecture Attribute Based Access Control (ABAC): A logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes. History: In 2003, with the emergence of Service Oriented Architecture (SOA), a new specification was published through the OASIS standards body called Extensible Access Control Markup Language (XACML) [XACML]. The specification first presented the elements of what would come to be known as ABAC. [NIST Special Publication ] Data and services can be accessed via the GIG by users and applications in the enterprise. Data and services are made available to any user of application except where limited by law, policy, security classification, or operational necessity Fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [Source: ISO/IEC 15288:2008 (IEEE Std ), Systems and software engineering System life cycle processes. 4.5.; as extended in the DoD Architecture Framework] A representation of a defined domain, as of a current or future point in

55 38 Description Authentication Authorization Availability Bandwidth Core Enterprise Services COI Confidentiality Discovery DNI DoD DoDAF 2.0 DoDIE time, in terms of its component parts, how those parts function, the rules and constraints under which those parts function, and how those parts relate to each other and to the environment. Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. Permission granted by properly constituted authority to perform or execute a lawful governmental function. Timely, reliable access to data and information services for authorized users. The amount of information or data that can be sent over a network connection in a given period of time. It is usually measured in bits per second, kilobits per second, or megabits per second. Core Enterprise Services: That small set of services, whose use is mandated by the CIO, to provide awareness of, access to, and delivery of information on the GIG. Community of Interest (COI): Collaborative groups of users who must exchange information in pursuit of their shared goals, interests, missions, or business processes and who therefore must have a shared vocabulary for the information they exchange. Assurance that information is not disclosed to unauthorized entities or processes. The process by which users and applications can find data and services on the GIG, such as through catalogs, registries, and other search services Department of National Intelligence. The DNI was established by the Intelligence Reform and Terrorism Prevention Act of The DNI directs and oversees the entire US National Intelligence Program, and as such serves as the head of the sixteen-member Intelligence Community. US Department of Defense, consisting of the Air Force, Army, Navy, Marine Corp, Coast Guard DoD Architecture Framework version 2.0 is an overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively. DoD Information Enterprise: The Department of Defense information resources, assets, and processes required to achieve an information advantage and share information across the Department and with mission

56 39 partners. It includes: (a) the information itself, and the Department s management over the information life cycle; (b) the processes, including risk management, associated with managing information to accomplish the DoD mission and functions; (c) activities related to designing, building, populating, acquiring, managing, operating, protecting and defending the information enterprise; and (d) related information resources such as personnel, funds, equipment, and information technology, including national security systems. DoD IEA DoD Enterprise Architecture Enterprise Architecture Fusion GIG Hadoop The DoD Information Enterprise Architecture (DoD IEA) is the authoritative capstone architecture that sets the operational context and vision of the Information Enterprise (IE). It is a description of the integrated defense information enterprise and the rules for the information assets and resources that enable it. The DoD IEA unifies the concepts embedded in DoD net-centric strategies into a common vision, highlighting the key principles, rules, constraints, and best practices drawn from collective policy to which applicable programs must adhere. [Draft DoDI 8210] DoD Enterprise Architecture: A federation of descriptions that provide context and rules for accomplishing the mission of the Department. These descriptions are developed and maintained at the Department, Capability Area, and Component levels and collectively define the people, processes, and technology required in the current and target environments; and the roadmap for transition to the target environment. (DoDD ) An enterprise architecture (EA) [as a noun] is a rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behavior) between them. EA describes the terminology, the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement (analysis), design, and evolution of an enterprise. This description is comprehensive, including enterprise goals, business process, roles, organizational structures, organizational behaviors, business information, software applications and computer systems. [Source: Wikipedia] In the context of intelligence data collection, fusion is the process of examining all sources of intelligence to derive a complete assessment of activity. Often associated with the exploitation stage of the PED cycle. Global Information Grid: The globally interconnected, end-to-end set of information capabilities for collecting, processing, storing, disseminating, and managing information on demand to warfighters, policy makers, and support personnel. Hadoop is a distributed file system for managing large data sets that has the ability to easily combine structured and complex data. Hadoop

57 40 provides vastly more storage at a much lower cost than legacy systems. HDFS IC Infrastructure MapReduce Net-Centric PED RBAC Reference Architecture Hadoop Distributed File System, one of two components of Hadoop Intelligence Community: The IC is a federation of 16 separate United States government agencies that work separately and together to conduct intelligence activities. The IC is led by the Director of National Intelligence (DNI). The IC includes the CIA, DIA, NSA, NGA, NRO, Air Force ISR Agency (AFISRA), Army Intelligence and Security Command (INSCOM), Marine Corps Intelligence Activity (MCIA), Office of Naval Intelligence (ONI), US Department of Homeland Security, Federal Bureau of Investigation (FBI), Drug Enforcement Agency (DEA), Department of Energy Office on Intelligence and Counterintelligence (OICI) A set of interconnected structural elements that provide the framework supporting an entire structure. One of two components of Hadoop, MapReduce is a parallel data processing system that exploits the distributed storage architecture of HDFS A vision to function as one unified DoD Enterprise, creating an information advantage for our people and mission partners by providing: (1) A rich information sharing environment in which data and services are visible, accessible, understandable, and trusted across the enterprise, and (2) An available and protected network infrastructure (the GIG) that enables responsive information-centric operations using dynamic and interoperable communications and computing capabilities. Processing, Exploitation, and Dissemination is an intelligence data cycle that involves the process of converting collected information into forms suitable to the production of intelligence. Dissemination is the delivery of this intelligence data that has been processed and exploited to users. Role-based Access Control: In computer systems security) is an approach to restricting system access to authorized users. It is used by the majority of enterprises with more than 500 employees, and can implement mandatory access control (MAC) or discretionary access control (DAC). RBAC is sometimes referred to as role-based security. [Wikipedia] Reference Architecture: Reference Architecture (RA) is an authoritative source of information about a specific subject area that guides and constrains the instantiations of multiple architectures and solutions. [Source: Reference Architecture Description, OSD/NII, June 2010]. An RA is essentially realization of one instance of an RM with additional attributes that are inherent to architecture description including: behavior, tailored to a specific purpose, technical guidance, pattern for use, tailoring of terms and vocabulary specific to the architecture s intended use. The DoD IEA is an example of a high-level reference

58 41 architecture describing the entire information enterprise. RAs, as referenced in the IEA document, are intended to further clarify and standardize how delivered Capabilities, derived from the IEA, will be implemented. Secured Availability Service SOA Trusted Visible Secured Availability (SA): Ensures data and services are secured and trusted across DoD. Security is provided, but security issues do not hinder access to information. When users discover data and services, they are able to access them based on their authorization. Permissions and authorizations follow users wherever they are on the network. This is a DoD Information Enterprise Architecture priority. Service: A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. Service Oriented Architecture: An evolution of distributed computing and modular programming. SOAs build applications out of software services. Services are relatively large, intrinsically unassociated units of functionality, which have no calls to each other embedded in them. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement.. Users and applications can determine and assess the suitability of the source because the pedigree, security level, and access control level of each data asset or service is known and available. The property of being discoverable. All data assets (intelligence, nonintelligence, raw, and processed) are advertised or made visible by providing metadata, which describes the asset. 2.5 Architectural Framework DoDAF To develop the Architectural Framework, we utilized DoDAF version 2.0 and it s fit-topurpose methodology to select viewpoints that define the overall MIDA architecture. The next section describes the viewpoints we have selected to describe our architecture.

59 Viewpoints Table 19 MIDA DoDAF Viewpoints Model Description Reference All Viewpoints AV-1 Overview and Summary Information Sections AV-2 Integrated Data Dictionary Table 18 Capability Viewpoints CV-1 Vision Figure 2 CV-2 Capability Taxonomy Figure 4 CV-3 Capability Phasing Table 21 Data and Information Viewpoints DIV-1 Conceptual Data Model Figure 18 Operational Viewpoints OV-1 High-level Operational Concept Figure 3 OV-4 Organizational Relationships Chart Figure 7 OV-5b Operational Activity Model Figure 20 Figure 22 Figure 23 Figure 25 Figure 27 Figure 28 OV-6c Event-Trace Description (Sequence) Figure 21 Figure 24 Figure 26 Figure 29

60 43 Figure 30 Services Viewpoints SvcV-4 Services Functionality Description (Activity) Figure 37 Systems Viewpoints SV-1 Systems Interface Description Figure 46 Standards Viewpoints StdV-1 Standards Profile Table Cross-Cutting Concerns During the early stages of our project, we recognized that our effort contained common functionality that spanned multiple layers of our architecture involving security and policy management. We have since added cloud storage and distribution technologies to our list of cross-cutting concerns. Our list of cross-cutting concerns consists of: Authentication, Authorization, Confidentiality, Availability Logging / Auditing Security and Governance policies Scalable, fault tolerant storage (e.g., Hadoop Distributed File System) Parallel Data Processing System (e.g., MapReduce) 2.7 Traceability and Concordance It is significantly important to ensure consistency between the elements used in the UML diagrams and the DoDAF models. Each diagram represents the process that executes the use cases. The exchanges between activities represent the association with other data flows in the architecture. This is commonly known as associations. Throughout the entire program, our team

61 44 held meetings to discuss the primary components of our architecture. We ensured that we had a common understanding of the task ahead. We went through numerous iterations of this process. We selected one person to configure and control of all documents for each delivery. We reviewed each other s documents and provided feedback as necessary. We constantly reviewed previous documents and make updates to the diagram as necessary. Spark Systems Enterprise Architecture software was a critical tool use to keep track of all class diagrams as well as behavioral diagrams. This tool allowed us to create baselines to ensure if mistakes were made, we could always go back to a different version and continue our development. 2.8 Complex Event Processing The ISR PED domain is a perfect fit for complex event processing. The initial operating capability of MIDA will be focused on basic individual services for storing, processing, and disseminating intelligence data, but a foundation for a SOA Event-Driven Architecture (EDA) will be in place for future expansion into complex event processing. For example, our initial subscription service will allow a user to subscribe to specific data content that has been received in near real time from a collection system, but initially event processing will be limited to events from one entity. We plan to evolve this into a complex event processing application that listens to events from a number of separate entities (for example, multiple sensors from one or more collection systems). Over time, we envision MIDA will add more event-driven capabilities as we implement more exploitation features in an analytic processing layer. 2.9 Development Process

62 45 Our development process will follow our company s system engineering management plan and Agile software development processes. There are many benefits to the Agile Methodology: Customer Relations The agile model encourages frequent customer interactions through onsite representatives. The plan-driven model also interacts with the customer, but this approach is more focused on contract agreement. Requirements Requirements can change rapidly. Agile is a more flexible model that can adjust to change. The plan-driven model is more controlling, and it has a formalized, predictable evolution of requirements. Environment The agile model is a fast-paced work environment with a high volume of changes. The plan-driven model has a controlling organizational environment, with less volume (and less tolerance) for change. This will allow the team to demonstrate progress to the stakeholders quickly. This type of development also reduces risk as you will be able to catch bugs at each iteration. Agile Methodology: Each functional unit is delivered in iterations Lasting 1 4 weeks with the following steps in Figure 17:

63 46 Figure 17 Agile Development Cycle Requirements analysis is critical to the success of our architecture. Requirements have to be actionable, testable and traceable to the business needs define by the stakeholders. The developer will use the new functionality and ensures that the expected behavior is achieved. This type of development will reduce the complexity of integration and reduce risks. The design phase captures the specifications to meet the requirements. Coding is the implementation of the requirements. Each unit test case needs to be unique from the other test cases. It will test the function or an entire class and ensure the results are as expected. Acceptance testing is the test suite that demonstrates if the requirements are met. It usually tests the software, the hardware, or the expected logic behavior. In many cases, acceptance testing is witnessed by a customer representative and is done prior to official delivery of the product.

64 Solution Approach The following Conceptual Data Model (DIV-1) describes the classes in the MIDA architecture and their inter-relationships. The next sections will go into the domain model, behavior diagrams, patterns, and executable models of the architecture.

65 Figure 18 DIV-1 MIDA Conceptual Data Model 48

66 Domain Model MIDA s domain model contains the following classes: UserMgr: This class handles the interfaces to outside users (ie. Analysts, Warfighters) SensorMgr: This class handles the interfaces to outside collectors (ie. UAV s) DisplayView: This class handles functions for MIDA s display UserRequestData: This class handles functions for user service requests ProcessData: This class handles functions and security infrastructure for processing intelligence data from collectors ExploitMgr: This class handles functions for exploiting intelligence data for the user service request StorageMgr: This class handles access and interfaces to different storage servers DisseminateData: This class handles functions and security infrastructure for disseminating data to the user

67 Figure 19 MIDA Domain Model 50

68 User Request Data The User Request Data class receives user service requests from MIDA s user display and sends the request to MIDA s storage repository. The service request is prioritized and status is sent back to MIDA s user display. The following activity and sequence diagrams describe the User Request class functions and their associations to other MIDA classes and actors User Request Data Activity Diagram Figure 20 OV-5b User Request Data Activity Diagram

69 User Request Data Sequence Diagram Figure 21 OV-6c User Request Data Sequence Diagram Process Data The Process Data class receives intelligence data from collectors (ie. Sensors), verifies collector data, and creates new metadata tags. The collector data and metadata is then sent to MIDA s storage repository. The following activity and sequence diagrams describe the Process Data class functions, security infrastructure, and their associations to other MIDA classes and actors Process Data Activity Diagram

70 Figure 22 OV-5b Process Data Activity Diagram 53

71 54 Figure 23 OV-5b Process Data Security Infrastructure Activity Diagram Process Data Sequence Diagram Figure 24 OV-6c Process Data Sequence Diagram Exploit Manager The Exploit Manager class receives data from MIDA s storage repository and performs exploitation functions such as tracking or fusion of different data sets. The exploited data is sent back to the storage repository for archiving and disseminated to the user display. The following activity and sequence diagrams describe the Exploit Manager class functions and their associations to other MIDA classes.

72 Exploit Manager Activity Diagrams Figure 25 OV-5b Exploit Manager Activity Diagram

73 Exploit Manager Sequence Diagram Figure 26 OV-6c Exploit Manager Sequence Diagram

74 Disseminate Data The Disseminate Data class receives intelligence data from MIDA s storage repository and sends it to MIDA s user display. It also performs classified data encryption and compression when needed. The following activity and sequence diagrams describe the Disseminate Manager class functions, security infrastructure, and their associations to other MIDA classes and actors Disseminate Data Activity Diagrams Figure 27 OV-5b Disseminate Data Activity Diagram

75 Figure 28 OV-5b Disseminate Data Security Infrastructure Activity Diagram 58

76 Disseminate Data Sequence Diagrams Figure 29 OV-6c Disseminate Data Sequence Diagram

77 60 Figure 30 OV-6c Disseminate Data Security Infrastructure Sequence Diagram 3.2 Patterns Model View Controller The Model View Controller pattern will be used to separate the presentation displayed to the user from our internal data model (storage and processing). Figure 31 describes our implementation of the Model View Controller pattern. Our ProcessData and StorageMgr classes map to the Model Our DisplayView classe maps to the View Our UserRequestData class maps to the Controller

78 61 Model View Controller Figure 31 Model View Controller Pattern Specification with Repository The Specification pattern will be used to allow users to query search the MIDA repository with boolean operators (ie. And, Or, Not). This pattern is implemented in the User Request Data class which handles user service requests from the Display View class. The Repository pattern will be used as an interface to different storage servers (ie. cloud servers). The StorageMgr class will be the repository interface for adding, deleting, and retrieving objects from different data stores.

79 62 Repository Specification Figure 32 Specification with Repository Pattern 3.3 Executable Model Using CPN Tools, we modeled in 2 iterations the part of our architecture that handles user requests and dissemination of data back to the user. The SetPriority transition represents a function in the MIDA architecture that assigns a priority to each user service request. The UserRequest transition combines all of the attributes associated with each MIDA user service request. The DisseminateData transition represents a function in the MIDA architecture that determines the level of compression required for outputting data to the user. In our first iteration, we decided that the SetPriority transition should assign high priority for ISR video requests and low priority for reports. The DisseminateData transition will perform high compression on ISR video data and low compression on reports. The figures below of our executable model show the initial state and the simulation state (50 transitions).

80 63 Figure 33 Executable Model First Iteration Initial State Figure 34 Executable Model First Iteration Simulation In this second iteration of our executable model, we added a new place UserBandwidth. We added this after realizing that MIDA s architecture needed to address an issue with disseminating data to disadvantaged users. The DisseminateData transition was modified to perform high compression on all data when user bandwidth is low. The figures below of our executable model

81 64 show the initial state and the simulation state (50 transitions). The simulation results after 50 transitions show how DisseminateData performs high compression for users who have low communication bandwidth with MIDA s server. This feature allows data to be sent timely to disadvantaged users. Figure 35 Executable Model Second Iteration Initial State Figure 36 Executable Model Second Iteration Simulation

82 Service-Oriented Architecture MIDA is an enterprise-wide system that ingests intelligence data and provides access to the data through MIDA web services. Designed from the start to be service-oriented, MIDA is comprised of services that handle data ingest processing, exploitation, dissemination, and storage to the cloud, as well as subscription and query services. MIDA s services are shown in Figure 37 Process Exploit Disseminate Store Infrastructure Governance Authenticate Ingest Data From Sensor Multi-INT Fusion Service Subscription Service Store HDFS Service Authorize Access Control Standards and Policies Query Service Manage Certificates Metadata Tagging Analyze Data Service (future) Display Data Service Store NCES Service Logging Messaging Routing Monitoring and Compliance Figure 37 SvcV-4 MIDA Services Taxonomy MIDA s services will operate within the DoD enterprise cloud with an infrastructure provided by the DoD. While it is still correct to state that MIDA applications will connect users to data via the Global Information Grid (GIG), a new DoD initiative is emerging, the Joint Information Environment (JIE). The MIDA architecture will likely need to evolve as we learn more about this new initiative. More information about JIE is provided in the next section.

83 66 MIDA will use the Rich Services architectural pattern. This pattern was chosen because of its ability to decompose and isolate major concerns. Each major concern can be designed separately, and then made available to the entire Rich Service via the Router/Interceptor layer. Another significant factor in our decision to use the Rich Service Pattern is that it is a scalable design pattern, and it will allow MIDA to scale across the DoD Enterprise. The Rich Service Pattern provides MIDA with the essential services of an Enterprise Service Bus (ESB) including a message-based communication infrastructure. As shown in Figure 38, an architecture based on the Rich Service architecture organizes a systems-of-systems enterprise into a hierarchically decomposed structure that supports both horizontal and vertical service integration. Horizontal service integration involves managing the interplay of application services and the corresponding crosscutting concerns at the same deployment level. Vertical service integration refers to the hierarchical decomposition of one application service, as well as the crosscutting concerns pertaining to this service (such as security), into a set of sub-services such that their environment is shielded from the structural and behavioral complexity of the embedded sub-services. The interaction between a Rich Service and its clients is accomplished via a Service/Data Connector. To manage the service orchestration, the communication infrastructure has two main layers. The Messenger layer is responsible for transmitting messages between services. The Router/Interceptor layer is responsible for intercepting messages placed on the Messenger and then routing them among all services involved in providing a particular capability.

84 67 Figure 38 Rich Services Pattern Services Figure 37 shows MIDA s SvcV-4 Services Taxonomy which identifies MIDA s application, infrastructure, and governance services. Our architecture has recently began evolving based on our understanding of the DoD s transformational move to the cloud, and we now believe all infrastructure and governance services will be provided by the DoD, with MIDA in the role of a consumer of those services. We indicate this by coloring these categories differently. A key insight we have gained from these changes is there truly is a move away from stove-piped infrastructure services and systems to a global DoD-wide standard. As shown in Figure 39, delivering systems is intentionally becoming rare, and delivery of services, including composable services, is the desired objective.

85 68 Figure 39 Transformation from Systems to Services In preparation for the new DoD Cloud and JIE initiatives, we have been studying the DoD, DISA, and NIST reference material. These standards are listed in our StdV-1 in Table 20. The NIST Cloud Computing Reference Architecture is shown in Figure 40. The five roles identified in the diagram are cloud consumer, cloud provider, cloud carrier, cloud auditor, cloud broker. The cloud provider includes a cloud Software as a Service (SaaS), and this is where MIDA fits in. DISA has been designated as the cloud broker for the DoD.

86 69 Figure 40 NIST Cloud Computing Reference Architecture Figure 41 shows a high-level view of the DoD Cloud, with the cloud platform, data, and software apps and services hosted on both local and remote data centers. Figure 41 Future DoD Cloud

87 70 The JIE will deliver the future Information Enterprise (IE) that enables DoD and mission partners to securely access information and services they need at the time, place and on approved devices of their choosing. The JIE is focused on five major focus areas which are driven by and aligned to Joint requirements. Four of the initial focus areas deliver capabilities: Data Center Consolidation, Network Normalization, Identity and Access Management (IdAM), Enterprise Services, all within a single Security Architecture. Figure 42 DoD Mobility End-to-End Vision and Figure 43 DoD Enterprise Cloud Service Broker show details from a DISA forecast briefing from August 8, Of special note in Figure 42 is the identification of a DoD Mobile Application Storefront, which is where we are targeting MIDA applications and web services. Figure 43 shows the future cloud environment with Producers (like NGAS collection platforms) and Consumers, which includes all DoD compartments. Figure 42 DoD Mobility End-to-End Vision

88 71 Figure 43 DoD Enterprise Cloud Service Broker Legacy Applications MIDA is designed towards future systems using data standards but is backwards compatible to legacy systems. Our ESB will be a multi-protocol ESB that accommodates adapters which will enable us to interface with legacy data sources. These adapters will be developed by MIDA developers with help from SMEs on the collection platforms. MIDA s Initial Operating Capability will include the ability to operate with data from two existing NG collection platforms (Global Hawk and Firescout), which use non-standard formats and meta-data. With our final operating capability, we will be able to interface with all NGAS collection platforms. We will also create an adapter kit that will allow us to create adapters for non-ngas platforms. Figure 3, the OV-1 MIDA Operational Concept in Section 1.4 MIDA Capabilities, shows the use of legacy adapters in MIDA.

89 Service Registry MIDA will exist within the DoD Joint Information Enterprise which provides infrastructure services, including Net-Centric Enterprise Services (NCES) capabilities which were established as part of the DoD s Net-Centric strategy. NCES provides an enterprise SOA foundation of core infrastructure services that supports data and application interoperability. Content Discovery and Delivery supports efficient information advertisement, discovery, and delivery. MIDA s application web services will be registered in the DoD s NCES Service Registry. In addition, MIDA s Web Service Description Language (WSDL) endpoints will be registered in the DoD Metadata Registry (MDR). The DoD Discovery Metadata Specification (DDMS) defines discovery metadata elements for resources posted to community and organizational shared spaces. "Discovery" is the ability to locate data assets through a consistent and flexible search. With the express purpose of supporting the visibility goal of the DoD Net-Centric Data Strategy, the DDMS specifies a set of information fields that are used to describe any data or service asset ( ie. resource), that is to be made discoverable to the Enterprise. It serves as a reference for developers, architects, and engineers by laying a foundation for Discovery Services. NCES and the DoD DMS specifies a set of information fields that are to be used to describe any data or service asset, i.e., resource, that is to be made discoverable to the Enterprise, and it serves as a reference for developers, architects, and engineers by laying a foundation for Discovery Services. As shown in Figure 44, MIDA will make use of these NCES services. Figure 45 shows a snapshot of the NCES Service Registry.

90 73 Figure 44 NCES Services Figure 45 DoD NCES Service Registry

91 Enterprise Service Bus At the heart of the MIDA architecture is an ESB. The MIDA ESB will be based on the Rich Service Pattern which provides distributed messaging, routing, business process orchestration, reliability, and security infrastructure services. Many of these services will be provided by the DoD s enterprise services, but we expect initially to obtain these services through our own local ESB. MIDA will be serving numerous Multi-INT Exploitation data processing locations spanning multiple Communities of Interest (COI). Since the Rich Services architectural pattern leverages the composite pattern, it is a good fit for a systems-of-systems enterprise such as the DoD enterprise environment. As shown in Figure 46, MIDA is connected to the DoD Global Information Grid. These separate integration layers add significant value especially for crosscutting services such as security and policy management. For example, we expect that many policies will be broadly applied across the DoD enterprise, with a minimum number of local policies. The Rich Service pattern accommodates this approach.

92 75 Figure 46 SV-1 MIDA Rich Services ESB 3.5 Standards Table 20 StdV-1 Standards Document Title Document Date Related Capability Related Initiative Document Type Federal CIO National Strategy for Information Sharing and Safeguarding DoD CIO Mobile Device Strategy DoD CIO Cloud Computing Strategy DoD Campaign Plan Summary DoD CIO s 10- Point Plan for IT 12/2012 Strategy 2013 Strategy 7/2012 Strategy

93 76 Document Title Document Date Related Capability Related Initiative Document Type Modernization DoD Enterprisewide Access to Network and Collaboration Services Reference Architecture (EANCS) 12/1/2009 Access Control; Architecture Development and Use; Collaboration; Cross Domain Security (CDS) Enforcement; Identity Provision and Management; Network Identity and Access Management (IdAM); Joint Enterprise Network (JEN) Architecture DoD Public Key Infrastructure Robust Certification Validation Service 4/22/2011 Architecture Development and Use; Best Practice Use; Standard Guidance Joint Enterprise Network (JEN) Architecture Global Information Grid (GIG) 2.0 Operational Reference Architecture (ORA) Version 1.5, January 17, 2010 Intelligence Community (IC) Core Identify & Access Management Reference Architecture Intelligence Community Security Reference Architecture 1/17/2010 Access Control; Architecture Development and Use 2/1/2011 Architecture Development and Use; Identity Provision and Management 9/14/2007 Access Control; Architecture Development and Use; Data and Metadata Protection; Identity Identity and Access Management (IdAM) Identity and Access Management (IdAM) Architecture Architecture Architecture

94 77 Document Title Document Date Related Capability Related Initiative Document Type Provision and Management NCES Service Discovery CES Architecture - Version 0.4 3/26/2004 Data and Functionality as Services Identity and Access Management (IdAM) Architecture DoD Discovery Metadata Specification (DDMS), Version 2.0 7/17/2008 Data and Service Availability; Information Sharing with Mission Partners Data Center and Server Consolidation Data DoD Data Net- Centric Data Strategy 9 May 03 5/9/2003 Data and Functionality as Services; Data and Service Availability Enterprise Cross Domain Services Data; Strategy DODD Data Sharing in a Net-Centric Department of Defense 4/23/2007 Data and Metadata Protection; Data and Service Availability; Standard Guidance Identity and Access Management (IdAM); Joint Enterprise Network (JEN) Policy DODI Netops for the Global Information Grid (GIG) 12/19/2008 Authoritative Body Identification / Empowerment; NetOps-Enabled Resources; Standard Guidance Joint Enterprise Network (JEN) Policy DODI Public Key Infrastructure (PKI) and Public Key (PK) Enabling 5/24/2011 Authoritative Body Identification / Empowerment; Network Defense; Sensitive / Classified Information Management; Policy

95 78 Document Title Document Date Related Capability Related Initiative Document Type Standard Guidance; Standard Protocol Management ICD Intelligence Information Sharing 1/21/2009 Collaboration; Data and Service Availability; Information Dissemination Management; Information Sharing with Mission Partners; Standard Guidance Identity and Access Management (IdAM) Policy Department of Defense (DoD) Information Technology (IT) Enterprise Strategy and Roadmap (ITESR) Initial Implementation Plan Version 1.0, November 4, /4/2011 Assured End to End Communications; Digital User and Service Attributes; Global Connections; Oversight of IE Implementation Strategy Department of Defense Net-centric Services Strategy: Strategy for a Net- Centric, Service Oriented DoD Enterprise, May 4, /4/2007 Data and Functionality as Services; Data and Metadata Protection; Data and Service Availability; Information Sharing with Mission Partners; Oversight of IE Implementation; Standard Guidance Enterprise Cross Domain Services Strategy DoD Information Sharing Implementation 4/20/2009 Cross Domain Security (CDS) Enforcement; Enterprise Cross Domain Services; Strategy

96 79 Document Title Document Date Related Capability Related Initiative Document Type Plan Information Sharing with Mission Partners; Oversight of IE Implementation Identity and Access Management (IdAM) Federal Cloud Computing Strategy 2/8/2011 Standard Guidance Data Center and Server Consolidation Strategy Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance 11/10/2009 Access Control; Architecture Development and Use; Credential Provision and Management; Identity Provision and Management; Oversight of IE Implementation Identity and Access Management (IdAM) Strategy GIG Architectural Vision V1.0 Jun 07 06/2007 Architecture Development and Use; Oversight of IE Implementation Enterprise Cross Domain Services; Joint Enterprise Network (JEN) Strategy IdAM Attribute Governance Access Control; Digital User and Service Attributes; Standard Protocol Management Identity and Access Management (IdAM) Strategy NIST SP : A NIST Definition of Cloud Computing 09/2011 Standard Guidance TLA Stacks Strategy Access Control in support of Information System Security Technical Implementation Guide Version 2, 10/29/2010 Access Control; Data and Metadata Protection; Oversight of IE Implementation; dentity and Access Management (IdAM) Technical

97 80 Document Title Document Date Related Capability Related Initiative Document Type Release 3 October 29, 2010 Sensitive / Classified Information Management Enclave Security Technical Implementation Guide Version 4, Release 2 10 March 1/28/011 Data and Metadata Protection; Network Defense; Oversight of IE Implementation; Standard Guidance; Standard Security Engineering Practices Technical

98 Solution Implementation 4.1 Implementation Status The AESE program exposed our team to best-of-practice technologies to be used in the development of an enterprise architecture. While we have made considerable progress in the development of an initial MIDA architecture, more architecture work must be done before proceeding to implementation phase. MIDA s architecture team will require in-depth knowledge of the DoD transformation efforts underway at the DoD. Key among these efforts is the Joint Information Environment (JIE) which encompasses the DoD Cloud Strategy and the Mobile Computing Strategy. MIDA will be integrated into a Government-owned Cloud framework. Our initial implementation will use open source software products that are compatible with the standards in place in the DoD Enterprise. The next section covers our implementation plans in detail. 4.2 Implementation Plan MIDA implementation will follow the agile development process. Before we get started on an initial capability, we would like to pause and reassess parts of our architecture in light of new emerging standards from the DoD. Once we have updated our domain model (and we have satisfied our NGAS stakeholders), we will begin implementation. Our initial implementation will implement the Rich Service Pattern in an ESB. We will attempt to obtain the ESB in use by DISA for use across the DoD enterprise. If this is not possible, we will get started using an open source product such a Mule Community (see Figure 47). In order to integrate with other ESBs, such as those in use by the DoD, we will need to perform ESB to ESB integration. Regardless of the availability of the standard DISA ESB, we

99 82 would like to get familiar with ESB to ESB integration because we believe there will be a period of time (years) before all systems have migrated to one standard enterprise ESB. Figure 47 MIDA Rich Services Pattern Integration Layers A quick review of integration patterns shows that the most effective integration approach will likely be the use of the Web Services integration pattern, which is based on a federated ESB pattern. In this pattern, the service provider s interface is exposed as a web service, and the service requestor, possibly hosted on a different and disparate ESB, subscribes to it using a messaging protocol such as SOAP over the Hypertext Transfer Protocol (HTTP). Many of our infrastructure services (especially security related services) will be provided by the DoD s enterprise services. Until those are available to us, we will initially use the services offered by Mule Community ESB. For security identity management we will initially use a Rolebased Access Control (RBAC) approach, but will migrate to a user Attribute Based Attribute

100 83 Control (ABAC). ABAC is becoming the standard identify management approach within the DoD. We have also become aware of DCGS Integration Backbone (DIB) 4.0, which is an open source framework based on standards-based data services focused on enterprise information sharing. This new version of the DIB provides a common framework to enable the construction of cloud services such as Platform as a Service (PaaS) type services for data exposure and transformation, and for enabling applications and users to discover and access information from a wide range of distributed sources. DIB 4.0 could become the foundation for MIDA. We would like to experiment with the DIB 4.0 in our integration lab. With respect to MIDA capabilities, our plans are to initially implement a basic query service. Our second step will build upon this initial capability by adding a subscription service using a simple case of EDA complex event processing with data from only one entity. Our initial focus for both of these capabilities will be with images (IMINT) and ELINT intelligence data. As we progress through our sprint iterations, we will continue to add capability until we reach our desired end state: a Multi-Level Secure, Multi-INT, Event-driven, DoD standards-based implementation of our Multi-INT Distribution Architecture

101 84 Our planned capabilities are shown in Table 21. Table 21 CV-3 MIDA Capability Phasing Category Initial Capability Final Capability Tools Query Services Subscription Services Additional analytical capabilities ESB Mule ESB Community Mule ESB Enterprise (or similar) Legacy Adapters Global Hawk Firescout All NGAS platforms Non-NGAS platforms EDA Event Stream Processing Complex Event Processing Data Fusion None 2 or more intelligence sources Data Collection Imagery Intelligence (IMINT) Electronics Intelligence (ELINT) Geospatial Intelligence (GEOINT) Full Motion Video (FMV) Communications Intelligence (COMINT) Human Intelligence (HUMINT) Data Sharing Intra-agency Multi-agency Coalition Partners Security PL-2 Multi-Single Level (MSL) Role Based Access Control (RBAC) PL-4 Multi-Level Security (MLS) User Attribute Based Access Control (ABAC) Data Management Standards NIEM DDMS IC-ISM NIEM DDMS IC-ISM

102 References Federal Chief Information Officer, National Strategy for Information Sharing and Safeguarding, December 2012 Teresa M. Takai, DoD Chief Information Officer, Campaign Plan Summary, 2013 Teresa M. Takai, DoD CIO, DoD CIO s 10-Point Plan for IT Modernization, 2013 Teresa M. Takai, DoD CIO, Mobile Device Strategy, Version 2.0, May 2012 Teresa M. Takai, DoD CIO, Cloud Computing Strategy, July 2012 Sandra I. Erwin, Too Much Information, Not Enough Intelligence, May 2012 William A. Brown, Robert G. Laird, Clive Gee, Tilak Mitra, SOA Governance Achieving and Sustaining Business and IT Agility, IBM Press, 2009 Defense Science Board Advisory Group, Final Report on Defense Intelligence, Counterinsurgency Intelligence, Surveillance, Reconnaissance Operations, January 2011 Booz, Allen, Hamilton, Augmenting Mission Effectiveness Through Cloud-Enhanced, Real-Time Intelligence Analysis, 2012 Hugh Taylor, Angela Yochem, Les Phillips, Frank Martinez, Event-Driven Architecture, How SOA Enables the Real-Time Enterprise, Addison-Wesley, 2009 Ken Vollmer, The Forrester Wave: Enterprise Service Bus, Q Matthew Arrott, Barry Demchak, Vina Ermagan, Claudiu Farcas, Emilia Farcas, Ingolf H. Kruger, Massimiliano Menarini, University of California, San Diego Calit2, Rich Services: The Integration Piece of the SOA Puzzle

103 86 Fang Liu, Jin Tong, Jian Mao, Robert Bohn, John Messina, Lee Badger, Dawn Leaf, National Institute of Standards and Technology (NIST), NIST Cloud Computing Reference Architecture, Special Publication , September 2011 Defense Information Systems Agency, Department of Defense, NCES Capabilities Overview, PEO-GES, Version 08.4 Ingolf Krueger, UCSD School of Engineering, Service-Oriented Architectures, Deployment of Rich Services using MULE (slide 60) Barry Demchak, Ingolf H. Kruger,, UCSD School of Engineering Calit2, Composable Chat: Towards a SOA-based Enterprise Chat System Green, John Stewart, Department of Computer Science and Creative Technologies, University of the West of England, United Kingdom, An Evaluation of four patterns of interaction for integrating disparate ESBs effectively and easily, Journal of Systems Integration, 2013/3