A new technology is often at the heart of a new product, and a shift in technology is often a primary motivation for developing a new architecture. Especially in the entrepreneurial community, a proprietary piece of technology is the central feature of the company’s first product. One of the pivotal roles of the architect is deciding whether and how to infuse a new technology into an architecture. An enormous amount has been written about this process, and we will therefore provide only a brief overview.

The first question that should be addressed by the architect is: Will the technology be ready for infusion? Here we are focused primarily on technologies early in the “S” curve of their development. Technology development is a process that proceeds at its own pace, independent of the timing of a new product or system. A new technology may be ready in time for your system, it may be late, or it may have lain fallow so long that the development team has dispersed. Advocates sometimes overstate the readiness of the technology. A useful tool for assessing the readiness of a technology is the Technology Readiness Level (TRL) scale shown in Figure 10.3. Despite the impression left by the TRL rating, technology development is not a linear process, and setbacks and iterations before final infusion readiness are common. It is the responsibility of the architect to understand the potential technologies that might be infused into the product.

Another key question for the architect is: Will this technology actually create additional value from the perspective of the customer and other stakeholders? This is best determined by comparative analysis in conceptual design (Chapter 12) of the architectures that would be possible with the new technology versus those without the technology. The associated risks of timely delivery and long-term supplier base of the technology must be included in such an analysis.

If it is judged that the technology is ready and will create customer value, the final question is: How will the technology be effectively transferred into the product or system?^* This discussion often jumps immediately to ownership of intellectual property (IP). Although consideration of IP is necessary, it is not sufficient for effective knowledge transfer. IP ownership or licensing covers the “know what” of transfer, but the real problem is the transfer of “know how.”

People are by far the most effective means of knowledge transfer. Where there are corporate research labs, the people who develop a technology often move with it to the product development team. In modern practice, the approach of many firms is to de-invest in technology and use a supply chain approach to acquiring technology from suppliers, universities, and government laboratories and through the acquisition of smaller companies.

As a marketplace of technologies, this market is very inefficient. The developers of the technology often do not know of the potential value it may bring, they almost certainly do not know of the architect’s intended application, and they almost never have enough money and time to bring the technology to the level of readiness that the architect would prefer before making a final decision on infusion. It is the role of the architect, working with the technology team of the enterprise, to devise a mechanism for effective knowledge transfer and successful infusion of new technologies into the product.