I would like to start this briefing by taking you out of this room and onto the battlefield for a moment. Imagine Marines preparing to move forward when they hear and see a UAV fly over. The cannot see what that UAV can see, though it would undoubtedly tell them what they were going to meet over the next hill. Imagine commanders back at the ground station for that UAV seeing an ambush waiting for those marines and shouting at the monitor for them to stop. Unfortunately, they did not have the connectivity, equipment, or software needed to communicate with these marines and the result was fatal. This happened in Afghanistan. Unfortunately, there are many other instances like this where individual systems had the capabilities our warfighters needed, but do to a lack of connectivity, lack of the ability to locate these capabilities, and lack of interoperability these systems were of no use.
What are some of the key changes we are seeing in military transformation. We are moving from a system centric view to a network centric view where capabilities are published as discoverable services on the network. This moves the power from information producers to information consumers. We are moving from point to point integration to horizontal fusion. This provides open ended integration to combine capabilities in new ways as needed. Finally we are moving from Data Centric to process / knowledge centric paradigm. As General Wagner mentioned analysts are spending more time sifting through data than analyzing it. We are in fact swimming in data. We have precision weapons we just can’t determine where to put them. We need to be able to interpret the data and have conclusions be part of decision / action workflows. Workflows in which physical users work in conjunction with virtual users in to automate the decision cycle. This is how we can bridge the technology, conops, operator gap. We need to draw the line from the data to the conclusion. This is how we can achieve signifcantly shorter decision cycles. This follows the industry model for setting up workflows for logistics chains. It also allows us to quickly add services and adapt conops for a particular battle by changing or creating new workflows.
So how are we doing on interoperability. We are making progress, but are far from being there. We have IP networking to provide a common technology for communications. Wired networks are pretty much a “done deal”. RF networks are being developed. The real challenge in application layer, as was mention by Mrs. Meyerriecks. In how we define services, data, and communicate between applications. Transformation requires even more reliance on information sharing and collaboration in near-real time.
What are some of the things are warfighters need They need systems that are easy to use where they can focus on fighting, not on IT. The complexity of the network and processing should disappear and the warfighter will be left with his core warfighting tasks. We need to reduce training needs and the workload we place on operators. Warfighters need rapid access to current useful information and interpretation of that information. We need to remove the barriers preventing warfighters from getting the resources they need. Again this also fits in to the concept of process oriented workflows. Warfighters need flexibility to adapt to changing conditions and partnerships. They may need to use new services and quickly modify workflows on the fly. The future of warfare may be decided by how fast we can adapt our capabilities, not just using what we have. The systems need to be survivable. They need to still function standalone and then be more powerful when connected to the network. The warfighter needs reliability and availability of the networks and capabilities (read services).
There are many problems facing industry and the services to achieve transformation. Software stovepipes exist, resist, and persist. Absent of architectural change they will probably outlive us. The question is what change needs to happen and how is it effected. Industry and the services need to work together on the interoperability problem. They also need to be motivated to do so. This may mean changing how we fund programs. Programs of Record are the primary method for allocating funding. PORs tend to fight off non-POR invaders. We need to be able to do no harm will enabling radical change.
There are many barriers to interoperable net-centric warfare. We haven’t agreed on how to connect components. There is a myriad of middleware products and standards. Most of which don’t interoperate. The widely used client-server model is static and brittle. Interfaces are private leading to stovepipe systems. Present systems assume a static, reliable network. The wireless networks of the future will have variable bandwidth and connectivity. I like to call this “evilnet”; we need to be sure to design our applications to deal with this. Much of the existing software is hardwired. They make static connections to other components and embed too much information about their execution context. Adoption of Service Oriented Architectures can remove these barriers.
How do we evolve to a revolutionary capability? As we mentioned there are many challenges. Conops Bureaucratic Financial Technical Perhaps the technical challenges are the easiest of this set. We have tried to get interoperability in the past by a list of standards (JTA), then by selecting implementations of those standards (DII COE), and now we moving to architectures. To start the journey we need to commit to embracing interoperable architectures and adopt service oriented architectures.
This slide shows transformation architectures and programs at the joint level and between the services. We are trying to have programs born joint and blend the capabilities of all our services together. CLICK We have to start with the network fabric, the basic connectivity. That is well underway with various GIG efforts including TCS, WIN-T, and JTRS. We are starting to define enterprise architectures for each of the services and also at a joint level. There are some agreements already about interoperability. The primary two architectures at this level are NCES / GES which focuses on C2 and the DCGS Integration Backbone (DIB ) which focuses on ISR. CLICK Beneath the enterprise architectures we are also seeing the emergence of tactical architectures, such as Future Combat Systems System of Systems Common Operating Environment. CLICK Finally there are a whole series of transformational programs that are being fielded with these architectures. CLICK All of these architectures share some common service-oriented themes. Some share common technologies. Making these architectures interoperable is key to making the applications they run on them interoperable.
These architectures are evolving and to some extent competing. Warfighter applications will need isolation from changing operational environments. How can an application built with one architecture communicate with another? Service Oriented Architecture can enable interoperability across enterprise and tactical architectures.
We cannot predict how we will need to put services together in the future to meet certain threats. We must be able to out adapt our enemy. The battlefield is a dynamic environment SOA / SBA focus on dynamic distribution of services and reduce system formation costs.
There are many pitfalls to implementation; Who leads How do we avoid rice bowls Can we move to focus on applications vs infrastructure services. Every program seems to create new infrastructures. As the network provides great connectivity and multiplying effect, it also provides a common path for enemies to access all of our systems.
What is a service oriented architecture. Allow the construction of systems based on components with well-defined service interfaces. In service based architectures components publish their capabilities as discoverable services on the network and perform work on behalf of other components. Web services have some SBA characteristics.
SOA ease integration across heterogeneous environments and applictcations. They facilitate the reuse of existing applications by turning their capabilities into discovery network services. This allows retention of previous investments and a bridge to the future force. Business (warfighting) processes should drive decisions on technical specifics – not the converse.
Here are a few key principles of service oriented architectures: Identify & expose specific sub-functions that existing applications can execute for others Agree to common interface standard Leverage existing tools pub/sub, web services, etc. The objective is to have loosely coupled aggregation of services.
Points to make This example shows how a system could possibly be built with the new architecture: Start with just a network and a lookup service. As components are connected to the network they publish their services with the lookup. Other items that need those services are notified that those services are now available and they automatically download and use them.
Notes This shows a simple example of how this could work. As systems connect to the network (whether local or dispersed) they publish their services. These services provide everything that the other system needs to make use of that service. A key point for this approach is that both the service consumer (client) and service provider (server) parts of the software are developed, tested and validated by the same contractor (the service provider). This will drastically cut down the issues of interoperability due to incorrect implementation of the ICD. Also, since this approach assumes a standard network connection, it’s much simpler and cheaper to implement (no custom hardware or connectors). In this example the CGS publishes its interfaces to a lookup service that is available to all systems on the network. The interfaces are then downloaded into the individual systems. Because the interfaces were originally developed by the system that you are wanting to talk to, the issues of ICD validation should be significantly reduced.
Here is a slide that address the concept you had for controlling both the ISR & targeting assets from a single Common Operational Picture. The slide builds to show the dynamic addition of components. I try to explain it below, but if you would like more clarification please let me know. In this scenario the CGS, which is acting as the QB for motion imagery (MTI and UAV) dynamically provides the relevant modules to the DCGS System Framework. These modules include the ability to visualize the data on a C4ISR geo-referenced display (display the data on a map), the UAV Visualization tool for real-time video and the Human-Computer Interface panels for tasking/statusing the sensor. The AFATDS system provides the user interface to target based on coordinates given from the ISR system. A scenario might go something like this……. ----------------------------------------------------------------- The CGS operator is tracking what is thought to be a high value target target (HVT). The track is automatically updated on the COP. The COP operator request additional coverage via UAV. The UAV confirms the target. Once the target is confirmed a Call for Fire is made immediately via the AFATDS service (which already has missiles targeted based info provided by the HVT). This would drastically decrease the sensor-to-shooter timeline.
We need to strive for a single service model, with a common concept of identity that allows services created in one architecture to plug be used by services in another architecture. This will allow C4ISR applications to be common among these architectures. This follows the vision that Mrs Meyerriecks presented.
What steps can we take to achieve interoperability. Begin the evolution by publishing existing capabilites. Each POR should identify the key services they can provide and service enable them. Develop a strategy for service discovery. You really want this to be plugable, just like you want the transport to be plugable. Begin decomposition of monolithic legacy applications into self-contained services that can be used in many targeted environments.
You want to re-choreograph existing war fighting process to capitalize on these deployable services. You want to allow flexible workflows and make changes to the workflows somewhat transparent to both users and software. Finally we need to establish de-confiliction rules or processes among services. And for this to work we must get serious about the security solutions. The network is both a strength and a weakness. The security solution should be plugable. We also need to solve the MILS / MLS security problem.
Government and industry collaboration is key. Frank and open dialog leading to quick decisions in forms like NDIA are critical. Equities between services and flagship programs should be incorporated wherever feasible. Get joint buy in Get prime contractor by in. Establish joint government / industry execution team
Let’s go back to the battlefield for a moment armed with this technology. Marines are about to move forward and they need to know what is over the next hill. They bring up their situation displays and filter for sensor services in their area. They notice a UAV they have seen is providing a video feed. The click on the UAV and are provided the application that displays the video the UAV is seeing. They realize they would be heading into an ambush and discover several shooter services that could be allocated to their target. The optimal fire solution is provided to them. They decide to use this option and take out the target.
Service Oriented Architecture Key to Net-centric Interoperability
Service Oriented Architecture Key to Net-centric Interoperability <ul><li>Guy Bieber </li></ul><ul><li>Senior Systems Architect </li></ul><ul><li>General Dynamics C4 Systems </li></ul>GENERAL DYNAMICS C4 Systems
Transformation <ul><li>System-Centric -> Net-Centric </li></ul><ul><ul><li>Remove barriers for Warfighters </li></ul></ul><ul><ul><li>Power shift from producers to consumers </li></ul></ul><ul><li>Point Integration -> Horizontal Fusion </li></ul><ul><ul><li>Stovepipes -> Network Services </li></ul></ul><ul><ul><li>Open ended integration to combine capabilities in new ways. </li></ul></ul><ul><li>Data Centric -> Process Centric / Knowledge Centric </li></ul><ul><ul><li>Not just about moving the data. </li></ul></ul><ul><ul><li>What does it mean? What should you do? </li></ul></ul><ul><ul><li>Software is helping to draw conclusions from the data and participating with users in decision workflows. </li></ul></ul>
Interoperability: How are we doing? <ul><li>Many improvements, but not yet enough </li></ul><ul><ul><li>IP networking enables process communication </li></ul></ul><ul><ul><li>Wire/fiber communications are a “done deal” </li></ul></ul><ul><ul><li>RF systems becoming software-configurable </li></ul></ul><ul><ul><li>The “Application Layer” is the real challenge </li></ul></ul>Tomorrow’s military must rely even more on information sharing and collaboration in near-real time
What Do Our WarFighters Need? <ul><li>Ease of use </li></ul><ul><ul><li>Reduced training load </li></ul></ul><ul><ul><li>Ability to focus on fighting, not IT </li></ul></ul><ul><li>Rapid access to current/useful interpretation of information </li></ul><ul><li>Flexibility </li></ul><ul><ul><li>Adapt to changing conditions and partnerships </li></ul></ul><ul><ul><li>Collaborate with US/Allies/Coalition & even Non-Governmental Organizations </li></ul></ul><ul><li>Survivability </li></ul><ul><li>Reliability/Availability </li></ul>
Problems and Constraints <ul><li>Software stovepipes exist, resist and persist </li></ul><ul><ul><li>Absent architectural change, they’ll outlive us </li></ul></ul><ul><ul><li>What’s the right change? </li></ul></ul><ul><ul><li>Can we effectively achieve one? </li></ul></ul><ul><li>Industry and Services require encouragement </li></ul><ul><li>“Programs of Record” </li></ul><ul><ul><li>Today’s primary method for allocating funding </li></ul></ul><ul><ul><li>PORs are inclined to fight off non-POR “invaders” </li></ul></ul>Must “Do No Harm” while enabling radical change
Barriers to Interoperable Net-Centricity <ul><li>We haven’t agreed on how to connect components </li></ul><ul><ul><li>There are hundreds of middleware products/standards </li></ul></ul><ul><li>Widely-used client-server model is static and brittle </li></ul><ul><ul><li>Interfaces are private, leading to stovepiped systems </li></ul></ul><ul><li>Present systems assume static, reliable networks </li></ul><ul><ul><li>Tactical networks are not highly available or reliable </li></ul></ul><ul><ul><li>Future networks will still be highly dynamic </li></ul></ul><ul><li>Much existing application software is “hard-wired” </li></ul><ul><ul><li>Far too much embedded context dependent information </li></ul></ul>Proper adoption of SOAs can remove these barriers
Evolving to Revolutionary Capability <ul><li>Numerous challenges exist </li></ul><ul><ul><li>Procedural (e.g. CONOPs and TTPs) </li></ul></ul><ul><ul><li>Bureaucratic (Industry/Service stakeholders) </li></ul></ul><ul><ul><li>Financial (who pays and who loses?) </li></ul></ul><ul><ul><li>Technical – perhaps the easiest </li></ul></ul><ul><li>Start the journey with a first step </li></ul><ul><ul><li>Commit to embracing interoperable architectures </li></ul></ul><ul><ul><li>Adopt Service-Oriented Architecture principles </li></ul></ul>SOA’s designed to accommodate change - allows DoD to leverage business innovation
JC2 FCS DCGS-MC DCGS-AF DCGS-A DCGS-N MC2C BMC2 GIG TCS WIN-T JTRS C2C / C2ERA ForceNet LandWarNet NCES / GES DIB SOSCOE JBI AOC MAJIIC CEASAR DCGS-J UOC Army Air Force Navy Marines JOINT Network Fabric Enterprise Architectures Transformational Programs Tactical Architectures Real Time and Distributed C2 Primarily C++ Supports Java And Ada95 Enterprise Services: J2EE, Web Portal, Web Services IA, etc. Primarily Java, C2 Focus J2EE and Web Services ISR Focus
The Net-Centric Landscape <ul><li>Enterprise and Architectures are still evolving </li></ul><ul><ul><li>Existing complex and competing architectures </li></ul></ul><ul><ul><li>Emergent and evolving architectures </li></ul></ul><ul><ul><ul><li>For instance: LandWarNet and C2 Constellation </li></ul></ul></ul><ul><li>Warfighter applications will need isolation from changing operational environments </li></ul><ul><ul><li>Change will continue </li></ul></ul><ul><ul><li>We will need to provide means for interoperability across enterprise networks for a long period </li></ul></ul>SOAs enable interoperability across different enterprise and tactical network architectures
Why Service Oriented/Based Architectures? <ul><li>The problems we need to solve today are not necessarily yesterday’s problems </li></ul><ul><ul><li>Therefore systems to solve today’s problems may not be the system we had yesterday </li></ul></ul><ul><li>A military example: </li></ul><ul><ul><li>If we do not know who our enemy is tomorrow or what his approach will be, we cannot predict with precision what capabilites (read “services”) our military systems will need or how our capabilities may need to be combined in the future. </li></ul></ul>Dynamic environments require dynamic systems SOA/SBA focus on dynamic distribution of services reduces system formation cost
Potential Pitfalls to Implementation <ul><li>Leadership </li></ul><ul><ul><li>Someone (Joint) needs to “be in charge” </li></ul></ul><ul><ul><li>Achieving “buy in” across the Community </li></ul></ul><ul><li>Rice Bowls </li></ul><ul><ul><li>Numerous redundancies exist in legacy PORs </li></ul></ul><ul><ul><li>Will cooperation protect programs? Obstruction? </li></ul></ul><ul><li>Application vs. infrastructure services </li></ul><ul><ul><li>Can net proliferations be contained and concentrate on applications? </li></ul></ul><ul><li>Security concerns across the enterprise </li></ul>
What’s a Service Oriented Architecture? <ul><li>Built around a collection of reusable software components with well-defined interfaces </li></ul><ul><li>Components may perform work (“service”) for others on a network, and inherently provide: </li></ul><ul><ul><li>Ability to “discover” the existence of services </li></ul></ul><ul><ul><li>Ability to convey information necessary for usage </li></ul></ul><ul><ul><ul><li>Descriptions, including formats & protocols </li></ul></ul></ul>SOAs enable dynamic formation of systems and net – critical for effective net-centric operations
Some Potential SOA Benefits <ul><li>Ease integration across heterogeneous environments and applications </li></ul><ul><li>Facilitate reuse of existing applications </li></ul><ul><ul><li>Facilitate efficient integration of existing systems </li></ul></ul><ul><ul><li>Reduce retraining impact of new major systems </li></ul></ul><ul><ul><li>Allow evolution by facilitating deployment of “best of breed” capabilities </li></ul></ul><ul><ul><li>Accelerate transition to integrated functionality </li></ul></ul>Business (warfighting) processes should drive decisions on technical specifics – not the converse!
A Few Key SOA Principles <ul><li>Identify & expose specific sub-functions that existing applications can execute for others </li></ul><ul><li>Agree to common interface standards </li></ul><ul><li>Leverage existing tools in business world </li></ul><ul><ul><li>Inter-process messaging </li></ul></ul><ul><ul><li>Publish and subscribe </li></ul></ul><ul><ul><li>Web Services </li></ul></ul><ul><ul><li>Deployable network services </li></ul></ul>Objective is “loosely coupled” aggregation of services
Ad-hoc Component Integration Lookup Service Local Area Network Map Services Data Services Interface Services Database Normalized Data Map Server PL PL
System of Systems Interoperability Lookup Service Local Area Network ASAS Services AFATDS Services CGS Services Systems interface with each other using published interfaces. Software that others need to access a system’s services is fielded and validated with that system. AFATDS ASAS CGS
Distributed Services CGS Visualization Service Framework Mobile Graphical Components COTS/GOTS Visualization Package UAV MTI AFATDS AFATDS Targeting Interface Provided by AFATDS UAV Viewing App Provided by CGS
Interoperability Strategy Networks Networks ( internal and external ) Operating System & Platform Platform (ISRIS Server) Operating System JVM Interoperability Packs Joint (NCES) Interop Pack Army (SOSCOE) Interop Pack Airforce (C2ERA) Interop Pack Navy (FORCENet) Interop Pack Marine (MAGTFOC) Interop Pack Architecture Portability – Contains Connector, Disocovery, and Security plug-ins C4ISR Applications C2 ISR Mission Planning Execution Automation / Decision Aides Fusion Services Sensor Services Advanced User Interaction Targeting
Steps to Achieve Interoperability via SOA Implementation <ul><li>Begin the evolution- Publish existing services </li></ul><ul><ul><li>Each POR responsible for publishing key service </li></ul></ul><ul><ul><ul><li>Design for technology change </li></ul></ul></ul><ul><ul><li>Enable existing applications for network usage </li></ul></ul><ul><ul><ul><li>SBA wrappers, Web-Service access </li></ul></ul></ul><ul><li>Develop strategy for services discovery </li></ul><ul><ul><li>Decision is key </li></ul></ul><ul><ul><li>Allow for evolution of standards by isolation of applications from OE’s </li></ul></ul><ul><li>Begin decomposition of monolithic legacy applications </li></ul><ul><ul><li>Critical services first </li></ul></ul><ul><ul><ul><li>Self-contained, loosely-coupled services </li></ul></ul></ul><ul><ul><ul><li>Modify as necessary for more robust service </li></ul></ul></ul>
Steps to Achieve Interoperability to via SOA Implementation <ul><li>Re-choreograph existing business (war fighting) processes to capitalize on deployable services </li></ul><ul><ul><li>Focus on applications needed by war fighters first </li></ul></ul><ul><ul><li>Providing flexibility to the user is key to innovation </li></ul></ul><ul><ul><li>Make services user-transparent, who uses will change </li></ul></ul><ul><li>… Finally….. </li></ul><ul><li>Establish de-confliction rules among services </li></ul><ul><ul><li>Important to get agreement on deployment from “owners” of critical data </li></ul></ul><ul><li>Get serious about the security solution </li></ul><ul><ul><li>Security policy must address evolution of service/data usage </li></ul></ul><ul><ul><li>Objective, reduce HW complexity at mobile levels </li></ul></ul><ul><ul><ul><li>Eliminate multiple LANS, </li></ul></ul></ul><ul><ul><ul><li>Workstation complexity - MILS workstation, perhaps </li></ul></ul></ul>
Recommendations and Conclusions <ul><li>Government/industry collaboration is key </li></ul><ul><ul><li>Frank and open dialog, leading to quick decisions </li></ul></ul><ul><ul><li>NDIA provides an excellent, unbiased forum </li></ul></ul><ul><li>Service “equities” and flagship programs should be incorporated wherever feasible </li></ul><ul><ul><li>Essential to achieve “buy in” across Government </li></ul></ul><ul><ul><li>Necessary to garner prime contractor support </li></ul></ul><ul><li>Establish joint Govt/industry execution team </li></ul>Joint SOA will enable net-centric interoperability!