I would argue that JADC2 is about giving the warfighter more options. What we’re trying to do with mosaic is do that with speed. The way I like to think of it in the theme of monolith busting is JADC2 busts up monolithic platforms into distributed architectures. What we’re doing with mosaic is trying to bust up monolithic architectures and make them into fluid and dynamic warfighting constructs. We like to contrast mosaic with a jigsaw puzzle. A normal system-of-systems is jigsaw puzzle where the different systems are carefully architected with well defined interfaces that have to go together one particular way. The mosaic metaphor says we have a collection of tiles, and they may be all kinds of different colors and shapes, but I can select the tiles I want in a much more flexible — not predefined — manner to build that mosaic artwork.
That was DARPA’s Timothy Grayson on a short but excellent episode of the the Federal Drive. It’s interesting to see how JADC2 and mosaic are now coming together. My understanding had been that mosaic was the overarching concept of distributed/networked systems, JADC2 was the command and control aspect within that networking, and ABMS (for the Air Force) was the technical or programmatic implementation of JADC2.
I think I like Grayson’s version better. In terms of JADC2, the goal is really to rapidly prototype, downselect, and improve operational systems that disaggregate the sensing/shooting functions. But a real worry is that all new products options be pre-planned for integration into a kill chain through pre-defined standards. That not only slows down development, it could lock out real technological advances that don’t conform.
So continuously creating new opportunities in the DoD might not work out like it did for the cloud/mobile economy. The DoD needs interoperability, but is much smaller and more restricted than the commercial world. I could imagine DoD processes requiring these supposedly low-cost single function systems to be preplanned as part of a larger program build.
That’s where the mosaic concept comes in — the ad hoc interoperability of systems rather than adherence to preselected global standards. I’d really like to see STITCHES upgraded in terms of status. For more on STITCHES, see my podcast with Dan Patt and Bryan Clark. Here’s more from Grayson:
Imagine, you got an ops floor or a squadron ready room, and the warfighters are there building the next days battle plan — very similar to what we do today — but a lot of that building of a mission plan involves wiring things together in different ways. In the rough vision we got, the geeks will be sitting in the back room right off the ready room, and the warfighters yell over or push a button, and the geeks pop up and start sitting at the keyboard with things like that STITCHES tool, or building the config file for the dynamo comm system, or any of the other tools we’re building, which amounts to knocking out the mission data files based upon that package the warfighters design. Then they take that stack of software and load it onto the jets or into the other weapon systems. That’s the rough top level decisions.
His vision I’m sure is closer to reality than mine. My comprehension had been that STITCHES would translate any of the external software interfaces for a particular component or system with the external interfaces of another components or system. It could be for a radar and an aircraft’s embedded mission system, or the aircraft’s data link with a satellite, or whatever needs “talking” between. STITCHES would allow developers to just build the best radar of a certain size, weight, and power, as it were, then figure out software integration with STITCHES. Once a particular connection was made, it would be available for everyone.
What Grayson is talking about is different. I’ll take a shot at interpreting, or really guessing. It seems like there will be a library of different ways all sorts of systems can interoperate. But that won’t be pre-loaded onto each and every system. Someone might need a unique kill chain, a group creates that interoperability, and then deploys it using containerization. If another group has a similar requirement, but is using systems that the information wasn’t loaded to, the “geek” team could quickly get that set up for them.
I’ll be interested to learn more about how JADC2 and mosaic warfare come together. As a last note, Grayson mentioned in the interview that one of his big challenges will be figuring out how to resource the efforts across the ecosystem. There’s plenty of talk in media outlets about JADC2 and mosaic, but its still on the far margins of DoD spending. The biggest challenges are not technological, but acquisition. Money flows through these long programming timelines, and focus on a predictable weapons platforms rather than experimentation and interoperability. Anyone who cares about the future of JADC2 and mosaic must also pick up the cause of reforming how the DoD selects and resources programs. Otherwise, the promise will come to naught, and the skeptics will chant “I told you so!”
Leave a Reply