CONCLUSIONS AND RECOMMENDATIONS FOR FUTURE

In the course of the research, I made a few observations as they relate to applying SOA technologies to DoD system challenges. These observations include a general migration of capabilities to internet technologies, a change in market leadership in the technical IT field and approaches for transitioning SOA technologies from laboratory to warfighter. In this final section we will first review the results of the research, discuss some of the observations described above and close with recommendations for future research.

The research started with a challenge of increasing volume of data and info and a potentially dramatic increase from exposing data using SOA technologies. To manage the data in a control and monitoring domain the research proposed use of two software patterns and a data fusion process. Using Gamma’s standard design pattern definitions the research detailed the zone and trickle-up patterns. Next the research discussed the application of the patterns in a command and control challenge associated with the Navy’s Maritime Domain Awareness system, and developed a prototype software system using SOA technologies to validate the patterns and process. Specifically the research validated the following:

• On the SOA data layer or infrastructure side we demonstrated the viability of the trickle-up pattern for a simple fusion problem, showing how we can divide the processing logic of the service from the fusion engine. At this phase you can readily see the need for a standard ontology and data schema. This type of semi-dynamic binding would be impossible without extensive knowledge of the meta-data. A common “track” definition is critical to this type of architecture.

• For control and monitoring software systems we detailed the Zone pattern, which discusses a distributed approach to sensor data management that

employs the content developed by the trickle-up pattern and departs from both the user defined operational picture (UDOP) approach of all sensor data

migrating into a core or the traditional “all data push” employed by the current Joint Global Command and Control System.

• Research prototype demonstrated use of SOA web-service based orchestration (BPEL) to administer a data fusion process.

• Research prototype demonstrated an Auto-Fusion discovery method along with a figure of merit method based on network costs, computational costs and potential fusion “benefit” based on the four level fusion model and employing the trickle-up pattern.

• Research explored impacts of an auto-fusion requirement as a broad Data Strategy goal for the Maritime Domain Awareness system.

In the following section we will discuss some general observations and recommendations from the research and close with some recommendations for future research.

In 1989 the Defense Communication Agency (now DISA) established the internet as a commercial activity and split the non-military segments of ARPANET to a

consortium of government, industry and academic leaders (Hobbes', 2). Early adopters quickly realized the potential of the network, however it still took some years for

applications to gain wide acceptance. Some of the hurdles stemmed from the complexity of the PC user interface as compared with a telephone or television set, while other hurdles stemmed from cost and availability of applications on the internet. One of the methods to spur adoption of new technologies was the availability of shareware or freeware products. For example, early adopters to the internet found little compelling content or applications, however a freeware product known as Mosaic (a freeware HTML browser), opened hyperextend images and graphics to a wider array of users, and put a “friendly” face on the Internet’s content. Mosaic put a “face” on the internet lowering the technological barrier of entry of users into the content of the internet. In a similar fashion, Service Oriented Architectures for DoD applications too require a “face” and more importantly a capability. DoD sponsored SOA demonstrations such as Horizontal Fusion

critical mass occurs and systems are widely adopted. The zone and trickle-up pattern provide a “face” to a control and monitoring domain software, which articulates to developers the three relationships a C2 monitoring system must enable and the sources they need. This “face” of SOA is a data management tool which manages the dynamic discovery and addition of content at runtime of data sources operating on a trickle-up SOA, such as TADIL, ELINT, SIGINT, raw and processed intelligence. This face or “Kmart COP” is the “last mile” managing the complexity of the architecture. To deliver the critical mass desired a Kmart COP must ride on a suitable SOA that too is non- proprietary in its binding between clients and data sources as discussed earlier in the research. Additionally, the Kmart COP tool set must extend the authority and user

experience of collaborative systems to managing an approved common operations picture as discussed in MDA CONOPS section of this paper. To gain initial user acceptance the tool must improve some near term user requirement, allowing a gradual adoption of the additional data richness and functionality. For example, when Microsoft first marketed the Outlook email program, users did not utilize much of the calendar and tasking tools provided. However over time, these tools gained wide acceptance and drove users to demand the increased functionality associated with using a Microsoft exchange server. In a similar fashion, Kmart COP, must provide an initial capability of access to present data, display it and allow the creation of a owned COP that can be collaborated on in and integrated application. Specifically, the tool must:

• Provide for the dynamic discovery of SOA track sources (trickle-up). • Provide capability to add and remove data sources at run time (trickle-up). • Provide integrated collaborative software between the data and the

visualization segment (zone pattern). • Provide a mapping/visualization segment.

• Provide mechanism to dynamically subscribe to other Kmart COP’s and integrate their managed pictures into a common picture (zone pattern)

• Leverage the capability of SOA segments to uniquely identify messages to provide a unique identification tag to mitigate data ringing (duplicative tracks displayed for the same contact).

• Conduct the data-management in a method to efficiently utilize bandwidth to support a disconnected or limited bandwidth user base.

In the preceding section we discussed observations relating to taking the zone and trickle- up pattern inspired software and migrating them from laboratory to warfighter, the next section discusses how the DoD is no longer the leader in information technology and needs to adopt from leader to participant in information technology standard development as well as recommendations of how acquisition managers can approach SOA

technologies.

Post World War II, defense contractors led industry in the development of high tech communications and computing systems. The defense industries lead began to fade during the 1980’s as personnel electronics and computing systems developed for

commercial use proliferated. Presently commercial industry leads many of the high tech factors and hence drives many of the commercial standards. Utilization of these

commercial standards significantly saves the DoD resources by shifting development costs to industry. Since the DoD is a large consumer of industry standards based systems it must maintain active participation in standard committee’s and development boards.

An additional requirement beyond interoperability standard development is the development of non-proprietary systems. These non-proprietary systems can maintain interoperability and extensibility while employing the incentives of industry

development. The Net-Centric Enterprise Solutions for Interoperability (NESI) method provides critical contracting language and references to develop non-proprietary military systems (NESI, Vol 1). Beyond NESI, initial core systems should be developed with strong government oversight. A potential solution is to focus initial development on

place for proprietary products and segments. In reality SOA’s can foster small businesses participation by lowering integration costs and increased sharing of solutions that an open SOA provides. The first brave steps however, must be made by agents of the government.

A great deal of written material is available discussing the shortfalls of present Command and Control systems, and extolling the virtues of a net-centric and service- oriented architectures (SOA). Books such as Power to the Edge and Net-Centric Warfare detail many of the why’s of SOA (Alberts, 15), this research rather focused on answering some of the how’s. Overall the message from the research is to demonstrate that although in the past, technology and bandwidth limited the potential for a SOA or web-based architecture for DoD solutions; the present state of the technology is in-fact mature enough to start fielding real systems that employ some of the technologies provided by web-enabled SOA’s.

Service Oriented Architectures offer a compelling solution to a number of the Navy’s command and control data management needs. A significant departure from existing technologies and methods, there are both acquisition and warfighter doctrinal impacts. A change in tool utilization alone will not deliver the results the DoD requires, doctrine must be altered concurrently. Additionally, some of SOA’s potential gains require a level of openness that runs contrary to the culture of defense contractors. This is not to say that all applications need to be non-proprietary/open source, just that the core communications between the services and specifications need to remain non-proprietary and vendor neutral to maximize open communications between systems and realize the transformation in Command and Control required to make FORCEnet a reality.

The dilemma acquisition managers have today remain unchanged since sword makers in Athens toiled with metallurgy; balancing the risks of new technologies, in a resource constrained environment against the demands to maintain present capabilities. Program offices answer to a chorus of various entities to become more “transformational” while functioning in the real world of maintaining and upgrading an existing system, and fielding systems in an extremely challenging fiscal environment. Despite, these obstacles

however, we need to take the next steps toward a net-centric vision and address the real and pressing poor record of both a technology refresh and expanded capabilities in the C2 field.