Buy over build: The military systems migration mantra

Story

March 12, 2013

Steve Graves

McObject

COTS-based DBMSs are emerging to take the reigns from homegrown and enterprise databases on the legacy migration path.

In the shift toward greater use of Commercial Off-the-Shelf (COTS) system components, software lags hardware, and the prevalence of non-COTS technology is still relatively high in military/aerospace systems because of protracted life cycles. But contractors increasingly view system migration in terms of acquiring and integrating new prebuilt software rather than adding to their old “homegrown” code base.

The trend is particularly marked in middleware and other complex software such as protocol stacks, messaging, and data management. Consider protocol stacks, for example. High-performance embedded networking requires fast, reliable, and reentrant TCP/IP stacks, extensively tested in multiple environments. Today’s COTS protocol stacks deliver this, and are also configurable, enabling applications to choose between allocating buffers in advance or at runtime.

Data management for military/aerospace systems has similarly outgrown its self-developed roots. With the advent of the Internet, high-speed communications and inexpensive memory, and relatively faster processors, embedded software now manages greater volumes of more complex data.

To meet this challenge, a new breed of COTS DataBase Management System (DBMS) has emerged – poised to replace both homegrown database code and enterprise DBMSs used in some military embedded systems – thereby offering a new migration path. The following examines some of their characteristics.

Many short, fast transactions

The transaction – a grouping of operations that must succeed or fail as a unit – is a database system’s basic unit of work, whether that DBMS is part of a corporate system or buried deep within defense gear. A key difference is the required transaction speed. Embedded applications typically have high transaction rates, with each transaction of short duration. Tellingly, enterprise DBMSs are benchmarked in transactions per minute, while for today’s fast embedded databases, the common metric is transactions per second.

One key change is that emergent embedded databases replace the client/server architecture of enterprise DBMSs with a design in which database operations execute within the application process. This eliminates the latency of Inter-Process Communication (IPC) between client and server, helping to deliver the needed submillisecond responsiveness.

Shared data and event processing

Most defense applications are event-driven, responding to interrupts from external sources. COTS databases for defense systems support event processing by propagating events to other “interested” software components. For example, in an Airborne Warning And Control System (AWACS), this “event” could be acquisition of data objects – airborne, seaborne, and terrestrial – from sensors, which triggers an operator console to show an alert.

Another example: In battlefield simulation, a task representing one combatant group takes some action, which is recorded in the database and in turn triggers another task (simulating another combatant) to reevaluate the battlefield scenario. Without COTS database systems to provide event notifications, developers of legacy systems would likely spend time cobbling together a solution based on homegrown message-passing code.

Complex data and design flexibility

Defense systems manage complex data, at a speed that is not amenable to using the SQL Data Definition Language (DDL) and Application Programming Interface (API) of enterprise DBMSs. For example, flight systems work with standard airport data that includes the objects DateTime, AirportStatus, WeatherSource, AirportWeather, and Airport. These objects are complex (that is, each contains records consisting of different data types) and they are nested: DateTime is a record type within WeatherSource, and WeatherSource is a type within AirportWeather.

SQL is notoriously bad at handling nested data, because processing it requires decomposing/recomposing the data to/from a normalized form (that is, third normal form, 3NF, or higher). However, COTS-based DBMSs gaining ground for mil/aero systems provide APIs and DDLs that map directly to the C programming language used widely in the industry. With support for fixed- and variable-length arrays of atomic data types as well as nested structures, opaque, or untyped data, they handle complex data with speed and fluidity.

Fault tolerance

Military technology must be resilient; therefore, a DBMS needs the capability to maintain one or more standby copies of the database on separate hardware, with failover. Today’s COTS database solutions go beyond simplistic mirroring or replication. They offer sophisticated mechanisms like “2-safe” replication, in which transactions must complete on replica node(s) before finishing on the master node; clustering architectures also dramatically increase net processing power and reduce system expansion costs, while delivering a more scalable and reliable database solution.

In contrast, some legacy systems provided basic homegrown replication, but without COTS DBMS bells and whistles (such as hot synchronization or binary schema evolution), much less full-blown clustering architectures.

Preserving time and talent

It is true that the capabilities described could be developed in-house by defense contractors, as in military days of yore where proprietary systems dominated. Additionally, some engineers still relish such a challenge, and this, as much as anything, ensures that homegrown data management, protocol stacks, and messaging software won’t vanish from our midst.

But assuming that COTS vendors price their technology reasonably, deploying the time, expertise, and expense to build these features in-house is becoming less and less justifiable economically – in the case of modern DBMSs and other technologies – and is an ineffective use of the organization’s time and talent these days.

Steve Graves is cofounder and CEO of McObject and can be contacted at [email protected].