We have discussed a number of upstream and downstream influences on architectures. It is the responsibility of the architect to prioritize among these influences and to determine which require careful attention. In thinking about influences as a list, one can become too linear. It is not possible just to tackle the influences in sequence, enumerate their goals and constraints, and then sum them up to produce the concept. This section explores a simple iterative model that combines influences explicitly.

Innovation in products and systems is traditionally thought to derive from one of two sources: The firm either has identified a new customer need or has identified and commercialized a new technology that delivers a higher performance/cost ratio in satisfying an existing need. Adding an icemaker to a refrigerator is responding to customer need with existing technology, whereas adding automatic tracking of stored food depends on the development of new RFID (radio-frequency identification) technology. This is a very simplified perspective on product strategy. It does not express strategies that capture new value in the value chain by backwards or forward integration, strategies that leverage home markets against regional or global expansion, or strategies that leverage the firm’s installed base of hardware to deliver high-margin service strategies.

Figure 10.9 shows a simple model that includes technology and customer need in an iterative process and provides a simple anchor around which we can enumerate the highest-level considerations when introducing an architectural innovation in a corporation. We call this the Product Case.

The diagram is intended to convey that there is a strong interaction between two processes: the development of a business case and the choice of system architecture. When the product innovation has identified a customer need, this need sets goals for the system architecture. The architect must then evaluate whether the solution is feasible and help determine whether the business case “closes” (stands up to financial scrutiny, see below) based on the cost of the solution. When product innovation derives from a new technology, the architect must help evaluate whether the solution would address customer needs. The challenge is broader than this, of course, because there are additional external and internal factors.

Figure 10.10 shows the complete ABCD framework. First, two external drivers are added to the framework: the competitive environment and regulations. The competitive environment primarily impacts the business plan, through barriers to entry, competitor product offerings, and market timing. Regulation primarily acts to constrain the available technical solutions, although creative use of the regulatory environment can create strong advantages in the business case. For example, the introduction of Tier 4 Final emissions regulations for off-highway trucks primarily set emissions targets that had to be met by new designs. But it also had an impact on the business case and created market opportunity by resetting the products on offer. Thus, it both challenged firms to sell off finished-goods inventory prior to the deadline and invited them to compete on new dimensions after the deadline.

Two internal drivers are then added: the firm’s strategy and its competence in supply chain execution. As stated earlier, the architecture must absorb goals set by strategy. The intent is for investments made at the firm level to contribute positively to the business case for the architecture, rather than imposing constraints on it. By analogy, the architecture must absorb goals set by the supply chain environment. The “currency” of each analysis is also shown—the financial analysis of the business case and the benefit analysis of the architecture. The two combine to inform the value proposition, which is defined as benefit at cost.

In the completed ABCD framework we have also represented the channels or distribution system and the product lines sold through them, as well as the legacy elements and the platforms they adhere to. It may surprise the reader to see channels listed as an architectural consideration. From the perspective of stakeholder needs, however, it becomes clear that architecture can inhibit channel distribution, or take advantage of it. The relationship between platforms and product lines is uncertain. In some businesses they are synonymous; in others the platform is purely a technical artifact, while the product line is channel focused. For example, recent research ^[13] revealed a case where the retail channels through which a heavy-equipment product was sold were responsible for the addition of five new variants in a product line of four variants. Matching product competitor price points was the originating dynamic, but this would not necessarily have motivated the firm to produce unplanned variants. The channel customer not only identified the opportunity but lobbied hard for it as well.

The ABCD framework is intended to make it clear that creation of the architecture is an inherent process that sits alongside the better-known “business case” deliverable. In some enterprises, the combined document is called the “product case.” It is common to speak of the business case “closing”—that is, the projected revenues are earning sufficient margin to merit the investment. Similarly, the technical architecture has to “close;” the goals are met by solutions, the required technology is present or developed, and the architecture can be delivered by the planned supply chain. These parallel cycles end when the technical architecture closes and the business case closes. This point is known as the Decision, implying that the enterprise makes a decision to move ahead and commit itself to the product.