The downstream development of the system is an equally significant source of ambiguity for the architect. An important role of the system architecture is to compress and extract the relevant downstream details and inject them back into the decision-making process up front. We begin with implementation as downstream influence.

All systems must be implemented. In physical systems, the distinction between design and manufacturing is sharp (although it may be iterative). In software systems, the boundary is blurred, because both the design and the product are information objects. We use the term “implementation” rather than “manufacturing” (a traditional hardware notion) to cover both hardware and software. Designing software consists of choosing algorithms and abstractions, designing data structures and program flow, writing pseudo code, and so on. Implementing is writing the actual code and testing. There is a great deal of contemporary work on coding, manufacturing, and supply chain management, so this discussion will focus on the interrelationships with architecture.

Like technology development, implementation is an ongoing business process. The product under the control of the architect will fit in a queue of other projects that the implementation system produces. Therefore, it is critical that the architect understand the implementation process that will be used for the product. The architect must design for implementation and must work with the implementers from early in development.

Implementation is a broad set of activities that includes sourcing (strategic partnerships, supplier selection, supply contracts); implementation capitalization, set up and ramp-up; software module development and testing; hardware element manufacturing and quality control; supply chain management; system integration; system-level testing; certification; and ongoing implementation operations.

The activities of conceiving the architecture and designing must merge with sourcing and ­supply chain management at the actual implementation process (Figure 10.4).

From the perspective of the architect, the key implementation decision is whether to make or buy: Will the implementation of the product be done within the enterprise or at a supplier? The issue hinges on what is within the enterprise’s defined core implementation competence. Does the firm have (or want to develop) the implementation capabilities to build the entire system? A secondary question is capacity: Is there “space” in the implementation process to realize this product?

If key suppliers are to be involved, the architect faces two additional questions: How early to involve suppliers and how to deal with their impact on the architectural decomposition? Early involvement of suppliers has benefits (access to more technology, implementation expertise), but it also has drawbacks (the suppliers will start influencing the architecture for their own good). Once a supplier is slated to provide a component, that component becomes a hard boundary and will influence decomposition. Suppliers can define decomposition or defy decomposition. The architect should involve the implementation team early, should participate in make/buy discussions, and should carefully time the introduction of suppliers into the architecting process.

A final implementation issue for the architect is the dynamics of the supply chain. The implementation system is large, and there are many points of coordination (often with incomplete information) and lags. Modern approaches to supply chain management work to harmonize these issues, but the architect should be prepared to understand them, because they affect many timing decisions, such as time to market of the first product.