Easing legacy migration in Systems of Systems
StoryDecember 05, 2012
Gordon Hunt
Real Time Innovations (RTI)
The next evolution of the legacy software migration will need to focus on flexibility, and should be architected to enable the construction of Systems of Systems.
Historically, the military acquires systems – each to meet specific requirements. Because of this acquisition approach, legacy migration is a concern during a program’s operations and maintenance phase.
Today, the acquisitions environment is changing in response to many pressures. The most obvious change is the reduction in spending on new systems. And, there are also pressures for the acquisition process to be agile and responsive to the asymmetric threat. The net effect is the next generation of systems will not be developed as new systems. Instead, acquisition officials look to gain efficiencies by reusing existing capabilities in new combinations to achieve new expanded capabilities, resulting in a System of Systems (SoS).
Benefits of Systems of Systems
The ability to assemble legacy capabilities is a force multiplier, and the extended capabilities of a System of Systems provide increased effectiveness beyond the individual systems and technologies. From the operator’s perspective, Systems of Systems allow the use of costly weapon systems at their full kinematic ranges. From the combatant commander’s perspective, a System of Systems is a means to a reduced “troop to task” ratio, meaning a reduction in the number of troops required to accomplish a task. Most significantly, from the taxpayer’s perspective, Systems of Systems allow us to pay once for a capability, not repeatedly, which significantly reduces the largest portion of total ownership cost – operations and support.
Challenges of Systems of Systems
Creating a System of Systems from legacy systems or applications is fundamentally different from creating a system to requirements. Because the different components of a System of Systems have their own ownership, architecture, and original requirements, traditional architectural approaches to legacy migration are insufficient. The traditional concerns of legacy migration and application portability are still present in the assembly of a System of Systems, but now with the additional challenge of multisystem interoperability introduced by a System of Systems.
The infrastructure of an application must support technical and syntactic interoperability. The infrastructure of a System of Systems must also support semantic interoperability. To support semantic interoperability, a software infrastructure must have three main characteristics: First, that it is based solely on open standards; second, it has an open data model that is rigorously defined, rigorously described, and fully discoverable; third, the primary nonfunctional requirement of a System of Systems software infrastructure is flexibility.
Open standards
The appropriate software infrastructure will leverage open standards that support interoperability. Examples of standards that support technical interoperability are IEEE 422, ARINC 1553, and POSIX. Examples of standards that support syntactic interoperability are DDS, MPEG, and XML. Examples of standards that support semantic interoperability are SQL and DDS.
Data model
The software infrastructure provides a semantic bridge between systems; therefore, it must be semantically aware. Semantically aware software infrastructure uses an extensible data model that captures semantics. This model must include the system’s entities, the relationships between the entities to establish context, and explicit definitions of the system’s observable and measureable phenomena (such as attitude, distance, location, position, and so on). This explicit definition must include the reference frame, units, and precision to concretely establish the context of the data to be exchanged. It must be rigorously defined, described, and discoverable.
Flexibility via super patterns
Finally, the software infrastructure must be flexible, because there is no one technology that is sufficient for the range of behaviors necessary for System of Systems-level software infrastructure. This flexibility is achieved by using architectural “super patterns” of distributed systems. The super patterns for organization, topology, state management, and communication patterns allow the other patterns to be constructed. The super pattern for organization is the traditional client server pattern. The super pattern for communication is the “event driven pub/sub” pattern. The topology super pattern is the “peer-to-peer” pattern. The state management super pattern is the “delegate to logical central repository” pattern.
Building the software infrastructure on these super patterns allows the software infrastructure to construct all of the other interaction patterns that legacy applications might have used.
Next evolution of systems migration is here
The next evolution of legacy migration enables the construction of Systems of Systems. A sophisticated software infrastructure, such as RTI Connext, is constructed specifically for this purpose.
Gordon Hunt is Chief Applications Engineer at RTI. He can be contacted at [email protected].
