BIG IDEA: How can a small group of technologists and investors think about and organize the Mission Economy on a large scale? We employ Technology Architectures to address this challenge.

Introduction

In-Q-Tel plays a central role in the Mission Economy - the network comprising US Intelligence Community Mission Problems, technology capabilities, and the startups who are working to commercialize them. We invest in a broad spectrum of technologies in service of a broad spectrum of mission requirements. Our portfolio includes companies in AI and Data Analytics, Biology, Communications, Quantum Technologies, and Autonomous Technologies among many other disciplines.

Figure 1 is a representation of the Mission Economy. The four blue nodes on the left represent our IC partners and the blue edges emanating from them represent demand for specific technology capabilities which are represented by the brown nodes. The green nodes on the right represent startups and the green edges emanating from them represent supply of technology capabilities. The thickness of the blue edges is proportional to the amount of demand for a specific capability and the size of brown nodes is proportional to the sum of the demand and supply.

It is easy to make some important observations from this simple diagram.

• Some problems require specific capabilities that are not (yet) supplied by the startup ecosystem. This either represents a technology gap or a business opportunity for startups in adjacent areas.
• Requirements for several technology capabilities are shared amongst our IC partners. This represents an opportunity to deploy startup innovation in multiple mission problems.
• Demand-side imbalances exist. There is demand for a specific capability with only a limited supply.
• Supply-side imbalances exist. Startups provide a capability but there is limited demand.

This analytical microscope on the Mission Economy gives us the ability to dig deeper into these scenarios to understand underlying causes and take specific actions.

How can a small group of technologists and investors think about and organize the Mission Economy on a large scale? We employ Technology Architectures to address this challenge and outline our architectural approach in this article.

Four questions

Our approach is driven by four key questions.

1. What is the nature of the problems we are attempting to solve?

The various 'INTS' - GEOINT, SIGINT (and children ELINT and COMINT), HUMINT, and OSINT - represent enduring challenges for the IC. While some of these problems can be addressed with a single technical solution, most of them require assembling multiple technical capabilities. Some of them even have hallmarks of Wicked Problems. We will see how to decompose problems into tractable chunks in Section 3.

2. What are the fundamental building blocks of technology innovation?

Before we decompose complex problems into tractable chunks we had to make a choice about the fundamental building blocks of technology innovation. Unlike DNA in biology or the chemical elements in chemistry, there is no objective way to do this. We have many options. Therefore, we need to agree on a convention.

Let's take a short detour into the evolution of technology.

The montage in Figure 2 shows three apparently unrelated systems: a bicycle, the Wright Flyer, and a covert communication transmitter. Closer examination reveals that the sprocket-and-chain, a capability for transmitting rotary motion from one shaft to another, makes an appearance in each of these systems. Two observations are salient. First, the Wright Brothers chose to use this mechanism because they were already familiar with it - they were bicycle mechanics! Second, a capability, once commoditized, can be repurposed in a variety of other uses. This is what led to its use in the transmitter. Bicycles were commonplace in France during WWII. The history of technology is replete with such examples.

This fundamental idea of starting with the capabilities that already exist and combining them to create new capabilities, combinatorial evolution, is captured in the excellent book, The Nature of Technology. This idea also implies that the more capabilities we have, the more we will have.

At In-Q-Tel, we have settled on the language of Technology Capabilities - functional units of technology. Our library of capabilities contains around 26,000 entries drawn from the IEEE, ACM, PLOS, and our own subject matter experts.

3.  How can we decompose mission problems, complex engineered systems, ecosystems, and value chains into these building blocks?

We decompose challenging problems into hierarchical assemblies of technology capabilities drawn from our dictionary (described above). We call these decompositions Architectures (yes, it's an overused word, but it makes sense in this context). Our working definition is: An Architecture is a canonical, hierarchical representation of a problem or system that shows its constituent technology capabilities and how they fit together. This is shown abstractly in Figure 3 below.

Each box represents a technology capability. A single Architecture is represented by boxes of the same color. It is possible that some capabilities themselves are comprised of a lower-level architecture. This is depicted by the dotted telescoping lines. Each box, irrespective of its color, is a specific capability drawn from our library.

We don't focus on specific interfaces between capabilities in an Architecture. Architectures work for us because, to paraphrase Minsky, "As more complex things are made, architecture dominates materials!" and well-thought out Architectures have long shelf lives and can remain useful for several years and can help drive technology roadmaps (Phaal et. al, Phaal).

We built a software tool, christened ArQ, that allows our technical staff to create such zoomable architectures using capabilities from our library, request the addition of new capabilities by a curator, and tag companies with the technology capabilities they supply. This allows us to connect potential investments to all the mission problems where they may be applicable and reduce friction in our two-sided marketplace. We plan on open-sourcing ArQ in the upcoming months.

4. How do the building blocks evolve?

We need to understand how technology capabilities evolve. In our context, this is important for at least two reasons. First, we need to understand whether our investment is being used for incremental improvement or to create a new capability. Second, we are interested in understanding what becomes possible when the capability has a marginal cost that tends to zero. Several scholars have looked at these questions (Henderson and Clark, Benson and Magee, Nagy et. al). We summarize their insights in the figure below.

1. New capabilities can come about through invention or recombination of existing capabilities. Consider a historical example. Denis Papin invented a steam cooker, a digester of bones, in 1679 and this inspired the creation of the first practical steam engine by Thomas Newcomen with the addition of a better piston. The engine was further made much more efficient by James Watt who was repairing a Newcomen engine!
2. A second way is not to just improve the components but to improve the architecture of the system or embed a capability in a different architecture.
3. Capabilities can improve through incremental improvement in their functional performance metrics (FPM). This is abstractly represented by the red dot in the figure. For concrete FPMs in a wide variety of technology areas, see, for example, Table 1 in this recent paper. We are all familiar with Moore's law improvements in silicon technology, but there are several other scaling laws that have been identified. Indeed, these scaling laws offer the possibility of forecasting FPMs.

Architectures are a general-purpose tool

We outline other uses for well-thought out architectures beyond investing in startups. As we have conceived them, Architectures are not models of the world - they are lenses that we use to look at the world and can be useful in myriad ways. Startup founders can use them to understand their location in value chains or to discover alternate Architectures to embed their technology in (i.e., find adjacent markets or pivot). People managing or studying technology ecosystems can use them to discover capability gaps, funding gaps, or clusters of innovation. This can be use to drive policy decisions about where and how to grow these ecosystems. On a larger scale nations can use them to perform competitive analyses, forecast threats and opportunities, or to aid investment or regulatory decision-making.