Picture a world in which no two hardware stores stock the same type of connectors. Where no two manufacturers produce parts that can interoperate because of differences in each company’s connector sizes, shapes and pin count. In such a world, scales of economy would be difficult to achieve due to the difficulty in making things fit together. Innovation in such an environment would be slow because the barriers to integration would effectively limit access to the wide pool of talent and ideas that live outside of a company’s walls. The workings of a modern factory are amazing because the parts which make it up and that go into its operation come from different places: each bringing special expertise, held together by a web of standards.
Until relatively recently, software was built in a world where no one had the same type of connectors. The result was large, monolithic software packages built by separate companies. Just as it would be in the mechanical case, software was not readily extensible because development had to come from within that single provider. There was no simple way to add something, no matter how wonderful, from outside that vendor’s portfolio because there was no standard way to “attach” it.
As the Open Source Movement gained popularity, more and more powerful, high quality capabilities became freely available. These capabilities were frequently created to provide a single, specific function; for example: providing efficient data storage or providing parts of a user interface. Put enough of these specialized parts together and you have a software product. However, to make this assemble-it-yourself approach work required a set of standards. That is, a set of interfaces which developers could use to connect the disparate pieces together. While this explanation oversimplifies things, a large part of why the software world moves so quickly today are these componentized capabilities and the application programming interfaces (APIs) that hold them together. One could say, APIs are like the standardized connectors of software development.
Recent pushes by the technology development branches of the armed services, as exemplified by the Air Force’s VAULT platform, are looking to take advantage of this interconnected, API driven worldview to improve C2 systems. This is a short, high-level description of how it works.
A C2 platform comes with a certain set of capabilities built-in. Figure 1 shows these:
How can such a system be enhanced without the long process normally required to modify, qualify and update the entire platform?
The simplest way to do this, as shown in figure 2, is by adding an external application. However, if the existing data and presentation infrastructure is duplicated by this application, it would be time consuming, expensive and wasteful to develop. Therefore the ideal approach is to add capability which uses the existing platform’s infrastructure while adding only the new features needed. This is where APIs come in.
As shown in figure 3, using an API, data can be taken from the platform’s data storage system and made available to the external application. REST stands for REpresentational State Transfer. It is one of the more common approaches used in APIs today because it is simple to implement and works across different operating systems and programming languages.
Once the external application has performed its analysis or data processing, the results can be put back into the platform’s storage system as shown in figure 4. In the case of Falkonry’s Operational AI application, this might be a list of “interesting” patterns which have been found in the data along with classifications (names) and a list of the most important signals for those events.
Figure 5 shows how this new information is made available to the existing applications and presentation layer of the C2 platform. With it, users can visualize the new information in familiar ways or use existing decision support workflows in order to determine and coordinate next steps.
Applications like Falkonry Clue were built for a world in which software systems are made up of best-of-breed components. This design makes Clue easy to use in fulfilling the DoD’s new modular software strategy.