The infrastructure is the correct place to accommodate change and the FACE™ Technical Standard supports and encourages this approach.
The only constant in systems is change (with apologies to Heraclitus). We can minimize its impact, and many software engineering principles such as modularity or encapsulation are aimed at exactly this, but it is inevitable that some changes will escape the scope of a single component and impact other parts of the system – this is the fundamental integration problem and one we must solve to deliver warfighting capabilities faster and cheaper.
The infrastructure is the correct place to accommodate change and the FACE™ Technical Standard supports and encourages this approach.
Making the infrastructure the point of variation is an architectural principle we will call Infrastructure-Centric Integration, in contrast to the historically common alternative Application-Centric Integration. Individual applications simply do not have the necessary context. This is clear when we consider some kinds of differences. What happens when one application uses meters and another uses feet? Or when receiver needs data structured differently from sender? Or when another system has standardized on a different communication protocol? Or when performance constraints require a new deployment configuration?
By definition these differences exist only when we consider the integrated system and recognize its differences when compared to a distributed application. If our response to change is to vary applications it forces them to know more about their surrounding environment, and we have created knowledge dependencies in the wrong direction. An application is less reusable if its implementation depends on every other application it interacts with. Systems integration becomes a combinatorial problem.
Another more practical issue with Application-Centric Integration is duplicated functionality. Consider an application that must handle incoming positions expressed as both radians and degrees. The obvious solution is to normalize incoming data before it is passed to the business logic, but what how should outgoing data be handled? There are two (at least!) "right" answers: we can say that it's the other side's problem and send in our desired units, or we can reverse the normalization so the receiver gets the format it expects.
These solutions are not hard per se, but having every application implement its own mediation capability a massive duplication of effort -- and thus time and cost. Additionally, it means the systems integrator must learn how each implementation works. This represents time spent on the mechanics of integration instead of the intent. One counterargument is that the problem is solved if everyone settled on a single application framework or middleware. This is unrealistic. Integration by commonality does not work, for all the same reasons that choosing common units, message structures, or wire protocols is impractical.
The FACE™ Technical Standard provides two crucial pieces of the solution. First, data models require software components to rigorously specify their data interfaces to the rest of the system. It is not a common message set but rather a common method to document messages, including language-level representation (integer vs. string), units (feet vs. meters), and measurement systems (WGS84 vs. EFEF). Additionally, data messages document high-level concepts (position vs. orientation) and context (the position of an aircraft vs. its observed position by a radar). Thus, we can rigorously document the expected inputs and outputs in a structured, machine-readable format.
The second piece is the FACE™ software architecture, which requires these inputs and outputs be sent and received over a standardize Transport Service (TS) API. The FACE™ Technical Standard allocates responsibilities to well-defined segments. Two important ones are the Portable Component Segment (PCS), where application business logic resides, and the Transport Service Segment (TSS), where communication and infrastructure reside. The infrastructure is thus another component of the system that may be separately procured and managed.
With these two pieces in hand we can solve the puzzle. Data models describe how all the portable components expect to interact with the rest of the system and the Transport Service infrastructure provides the place to resolve differences when these expectations conflict. When a publisher sends radians and a subscriber expects degrees, the infrastructure can transform one unit to another. When a subscriber expects collated data from several sources the infrastructure can combine messages from individual publishers and provide the aggregated structure. When bandwidth or latency dictates specialized low-level protocols, the infrastructure can abstract these from business logic.
This does require a more capable infrastructure, but importantly it is work that must already be done -- remember, change and differences are inevitable. The FACE™ approach of explicitly allocating this responsibility to the TS infrastructure has many advantages. It lets portable components focus on their business logic, thus making them simpler and more reusable. It lets integrators work with the mediation capabilities within the Transport Service infrastructure instead of needing to learn many mediation options across every application. It encourages a market for infrastructure providers to specialize and innovate. Finally, the standards at the top and bottom of the Transport Service along with the standardization of the data models eliminate vendor-specific dependencies. This enables integrator flexibility and independence from application design and specifications.
Infrastructure-Centric Integration may seem novel, but it is really a natural evolution of layering. We don't write a compiler for a new microcontroller or an operating system for new real-time needs. Today, there is similarly no need for applications to write their own mediation or infrastructure layers that would distract development from core business logic functions.
By enabling the infrastructure to address integration needs and enabling the infrastructure to be maintainable and updateable at a different pace and rate from the systems being integrated one can truly change the upper bound on a systems size, scale and complexity.
Written by Shaun Foley, Principal Software Engineer at Skayl.