Legacy algorithm harvesting for net-centric environments

Story

May 16, 2009

Tod Hagan

Modus Operandi

The U.S. Army's Guardrail Common Sensor (GRCS) SOA-based, net-centric system provides war fighters with vital intelligence information, so it's no wonder that migrating its crucial algorithm had its fair share of challenges.

The heart of the U.S. Army Guardrail Common Sensor (GRCS) system is its emitter geolocation capability. This capability has proven to be one of the most reliable and accurate in the DoD Signals Intelligence (SIGINT) community. The subject of our case study – GRCS – employs multiple emitter location algorithms and capabilities in an effort to optimize intelligence collection and emitter exploitation.

Accordingly, when migrating the GRCS algorithm, the first task was to understand the context in which the resulting SOA-based service would be deployed. The SOA system design paradigm makes software services available to network-centric applications. The role of SOA is to allow for information interoperability and exchange among producers and consumers. Relevant considerations for the migration included:

Which type of integration will be used to make the new algorithm available in the target deployment environment?
How will the migrated algorithm be integrated with the target environment's security and metadata models?

The deployment environment for the GRCS algorithm is the Distributed Common Ground System-Army (DCGS-A). Since GRCS contains multiple candidate emitter location algorithms, a critical step was determining which algorithm to harvest. The GRCS Hyper-Wide fix algorithm was a clear choice due to its low coupling with the rest of the GRCS system.

The next challenge was to harvest the Gauss-Newton emitter location algorithm. While more accurate than the GRCS Hyper-Wide fix algorithm, the Gauss-Newton algorithm is significantly more complex as a result of its distribution across several software modules. The first challenge we encountered was that the Gauss-Newton algorithm was not easily decoupled from the system. To add to the complexity, the algorithm has both C and Fortran components. This identified the algorithm as at least a Type 3 migration (partial application refactoring) effort. Because the Gauss-Newton algorithm was well documented, the opportunity for a Type 4 (full application refactoring) integration was possible. After discussing options with stakeholders, it was concluded that a clean port using modern tools for a Type 4 integration would be the preferred course of action.

Algorithm harvesting process

At the beginning of the GRCS algorithm harvesting effort, an industry survey was conducted to find relevant research on this topic. The most mature work was the Service-oriented Migration and Reuse Technique (SMART) supported by the Software Engineering Institute (SEI). SMART is a four-step process that describes the activities needed to analyze legacy systems and determine if they can be exposed as an SOA service. The first step is to work with stakeholders to capture project goals. Step two identifies candidate algorithms in the legacy system that meet stated goals. Step three evaluates migration costs against ROI of harvested algorithms. The fourth step is to prioritize the migration of each algorithm based on cost and stakeholder goals.

These four steps in the SMART process only represent a partial solution. The SOA service must still be designed, constructed, tested, and deployed. Our process on GRCS added a fifth step to support construction, test, and deployment needs. Step five is repeated for each algorithm and includes evaluation of migration options, test case and test data development, actual migration effort, and stakeholder progress reviews.

The GRCS migration effort used a modern spiral development approach to reverse-engineering legacy code, performing comprehensive reviews of algorithm documentation, and interviewing domain experts. Many opportunities to leverage modern computing technologies such as mathematic libraries for computationally intensive calculations and Web services/Java for platform-independent construction and deployment were used.

Lessons learned

The following lessons learned are valuable for any organization tasked with migrating legacy systems to a net-centric environment:

Break the task in manageable spirals. Breaking the effort into two- to three-month implementations provides a good opportunity for short-term goals to be achieved.
Define specific goals for the reengineering/modernization effort. By picking specific goals, designers can keep a narrow focus on the functionality required to migrate. This suits the unique opportunities of Web service migration well because by nature each service function should be automatic and decoupled (independent) from the rest of the system.
Do not count reimplementation out. When a piece of functionality is well documented, reimplementation can be very easy with the use of modern engineering tools.
Build a good graphical UI/test harness. The test harness with UI provides an easy mechanism to review work with project stakeholders and a concrete example of how to access the SOA service from consumer applications.

Tod Hagan is director of ISR Software Solutions at Modus Operandi, Inc. He served as the project lead for the design and development of critical software components on the U.S. Army Guardrail Common Sensor program. He can be reached at [email protected].