Before the architect is engaged, there has been an “upstream process” that has defined issues, opportunities, and needs for the new system. This upstream is full of ambiguity. For example, what are the high-priority needs of the customer vs. the “nice to haves”? What are the regulations that must be considered and how will they be dealt with? And how is manufacturing competence aligned with the envisioned product?

The architect drives ambiguity from the upstream process. The architect is responsible for creating boundaries and concretizing goals. This includes:

• Interpreting corporate and functional strategies

• Interpreting competitive marketing analyses

• Listening to users, beneficiaries, customers, or their representatives

• Considering the competence of the enterprise and its extended supply chain

• Considering the operations and operational environment of the system

• Infusing technology where appropriate

• Interpreting regulatory and pre-regulatory influences

• Recommending standards, frameworks, and best practice

• Developing goals for the system based on the upstream influences

Once the goals for the system have been defined, there is the creative task of defining a concept for the system. A good concept does not ensure system success, but a bad choice of concept almost certainly dooms a system to failure.

The architect employs creativity to create the concept for the product, which captures the essential vision of the system, and differentiates the product relative to previous concepts. Several of the tasks in defining the concept are:

• Proposing and developing concept options

• Identifying key metrics and drivers

• Conducting highest-level trades and optimization

• Selecting a concept to carry forward, and perhaps a backup

• Thinking holistically about the entire product life cycle

• Anticipating failure modes and plans for mitigation and recovery

In the moment when the concept is chosen, there is a relatively small amount of information available to define the system. But very rapidly the information explodes, as team members start defining external interfaces, the first-level design and decomposition take place, and the considerations for downstream factors begin to be defined.

The architect manages investment in complexity and the evolution of complexity in the system, in order to ensure that the goals are delivered. A key component of the architect’s role in managing complexity is ensuring that the system is comprehensible to all. This aim is achieved by:

• Decomposing form and function

• Clarifying the allocation of functionality to elements of form

• Defining interfaces between subsystems and the surrounding context

• Configuring the subsystems

• Managing flexibility vs. optimality

• Defining the degree of modularity

• Articulating vertical vs. horizontal strategies

• Balancing in-house vs. outsourcing design and manufacturing

• Controlling product evolution

These three principal roles of the architect all center on information: identifying the necessary, consistent, and important information by reducing ambiguity; adding new information through creativity; and managing the explosion of information in the final architecture.

Traditional systems engineering conceives of a project as a three-way tradeoff among performance, schedule, and cost. [1] The enduring wisdom is that the systems engineer must identify the tensions among these and, in the end, can set one of these three variables, can manage to a second variable, and must allow the third variable to float. The dynamics that couple performance, cost, and schedule have now been largely defined through project management models in System Dynamics, [2], [3], [4] but the endogenous estimation of the three variables is rare, given the difficulty of obtaining the data and the expertise required to calibrate these models.

Complexity, creativity, and ambiguity are not as directly coupled as performance, cost, and schedule, but they are far more amorphous and difficult to manage. The metaphor of tension in systems engineering is directly applicable to the role of the architect; one of the primary mechanisms by which the architect acts is recognizing, communicating, and resolving tensions in the system (Box 9.1 Principle of the Role of the Architect).

Zhang and Doll [5] coined the term “the fuzzy front end” to express the idea that early development activities are challenging because the goals are unclear. These goals may be unclear because a defined customer base cannot articulate what it wants next, because the end customer is unclear, or because the underlying technology progress is unclear.

Leadership is not a management task unique to system architects. It is leadership that sets a vision for the firm and molds an amorphous context into an executable plan. However, we believe that the task of the architect is particularly challenging because the architect sits between firm strategy and product/system definition and therefore must competently bridge both worlds.

To these ends, we believe it is important for the architect to recognize and be able to deal with the various types of ambiguity. Strictly speaking, ambiguity is composed of two ideas: fuzziness and uncertainty. However, in common usage, ambiguity can also connote incorrect, missing, or conflicting information.

Fuzziness occurs when an event or state is subject to multiple interpretations. A color can be fuzzy; whether a color is blue or purple could be interpreted differently depending on the viewer. The color has a defined wavelength, but its adherence to the categories we call blue and purple is fuzzy. Fuzziness is rampant in the statements of needs of customers—for example, when they say they want a “smooth” finish or “good” gas mileage. Fuzziness is also influenced by context. What is good gas mileage will depend on the background of the customer. Customers in North America and Europe have different expectations. [6]

Uncertainty occurs when an event’s outcome is unclear or the subject of doubt. The outcome of a coin flip is uncertain. We can clearly articulate the potential states that could happen, but we don’t know which state will occur. For example, a new technology may or may not be ready at the date needed to support a new product.

Compounding the ambiguity that arises from fuzziness and uncertainty are the related phenomena of unknown information, conflicting information, and false information. In order to illustrate these variations, we use the shorthand (X, Y, Z), where X, Y, and Z are the true inputs to the system.

Unknown information (X, __, Z) occurs when information is under-determined or unavailable. This is a very common case early in the product development cycle; for example, you may know nothing about the product/market intentions of your competitors. You may know about the absence of information; an example of such a known unknown occurs when you don’t know whether your existing competitor will launch a product. Even more dangerous, you may not know about the absence of information; this is often called an unknown unknown. For example, a new competitor could introduce a competing product.

Conflicting information (X, D, Z and X, B, Z) occurs when two or more pieces of information offer opposing indications. The problem is over-determined. For example, you may have information from one source that the government will impose a new regulation affecting your product, but information from another source may suggest that the government will not do so.

False information (F, Y, Z) occurs when you are presented with incorrect inputs. In this case you may believe you have all the information (your information is complete), but some of it is wrong. For example, you may have been told that a supplier will be ready on a certain date, when the supplier actually has no plan whatsoever to be ready on that date.

Consider the following statements. What types of ambiguity are present?

• Please make me a smooth cover for this phone. (Fuzzy)

• Will it be a boy or a girl? (Uncertain, Fuzzy)

• Make sure you meet your quarterly goals. (Unknown, Conflicting)

• Produce a low-cost, high-quality product. (Conflicting, Fuzzy, Unknown)

• Every fourth year is a leap year. (False)

Ambiguity is almost always present in the upstream influences, which we have roughly segmented below by corporate functions.

• Strategy: How much risk is corporate, the board, or the government willing to take?

• Marketing: Will it fit with marketing’s plans for product line positioning and channels of distribution?

• Customers: What do the customers want/need? Will their needs change with time?

• Manufacturing: Will manufacturing be ready to produce it?

• Operations: What failures must the product endure and still operate?

• R&D: Is that technology infusible?

• Regulations: What are applicable regulations? Are they likely to change?

• Standards: What are the applicable standards, and will they change?

For each of these, the initial information that the architect receives could be fuzzy, uncertain, missing, conflicting, or false.

Given all these sources of ambiguity (Box 9.2 Principle of Ambiguity), the architect’s responsibility is to provide more certain, less fuzzy inputs to the team. In some cases, the ­ambiguity can be pared down by analysis. In other cases, one may choose to impose constraints simply to make the problem more tractable. Sometimes it is necessary to make an assumption so that work can proceed, being careful to mark the assumption well for future verification.

The architect must realize that no one explicitly “designs” the upstream influences; rather, they just occur, often with incomplete, overlapping, or conflicting outcomes. It is easy to get trapped in the thinking that the upstream influences (corporate strategy, marketing, the board, the customer, the government, and so on) have knowledge that can reduce the ambiguity, or that they have a responsibility to inform the architecture by commenting on early drafts.

The architect must engage these upstream influences and drive the ambiguity out to create a vision and plan for a successful product. This requires knowledge of what the upstream influences are, who has “control” of them, and how they are best engaged. The architect must keep in mind the objective: a consistent, complete, attainable, clear, and concise set of goals for the product.

Removing, reducing, and resolving ambiguity is the main role of the architect at the interface to the upstream process. The tools that we present to help with this include a list of the deliverables of the architect and the use of a holistic product development process (Section 9.3), the examination of several of the principal upstream and downstream influences (Chapter 10), the ABCD Product Case (Chapter 10), and the stakeholder needs-to-goals process (Chapter 11).

As a summary of the role of the architect, the list of deliverables of the architect is given below. Note that deliverables are very different from tasks in that they are the end result, not the procedure by which the state is achieved. The deliverables include:

• A clear, complete, consistent, and attainable (with 80–90% confidence) set of goals (with emphasis on functional goals).

• A description of the broader context in which the system will sit, and the whole product context (including legal and standards).

• A concept for the system.

• A concept of operations for the system, including contingency and emergency operations.

• A functional description of the system, with at least two layers of decomposition, including description of primary and secondary externally delivered function; ­process flow with internal operands and processes, including non-idealities, supporting ­processes, and interface processes; and a process to ensure that the functional decomposition is followed.

• The decomposition of form to two levels of detail, the allocation of function to form, and the structure of the form at this level.

• Details of all external interfaces and a process for interface control.

• A notion of the developmental cost, schedule, and risks, and the design and implementation plans.

Table 8.1 leads to the development of all but the last deliverable, which represents a summary of the project to be undertaken. However, one of the many challenges the architect faces is to represent these deliverables such that they can be easily absorbed and used. In Part 3, we focus on representing architecture in the context of complex development projects, where we recognize that diagrammatic languages such as OPM and SysML, while semantically exact, may not fit with existing process or culture. Therefore, part of the role of the architect is to capture the information from Part 2information however it can be most easily interpreted.

In summary:

• The role of the architect includes reducing ambiguity, employing creativity, and managing complexity.

• Architecture sits astride the upstream activities (things that are done before the architecture is created) and downstream activities (things that are done after the architecture is created but which must be factored into the architecture). Ambiguity arises from both.

• In common practice, ambiguity is a combination of fuzzy information, uncertainty, missing information, conflicting information, and incorrect information. The principal job of the architect at the interface to the upstream (the fuzzy front end) is to drive as much of this ambiguity from the system as possible.

• A high-level way to do this is to start to prepare the deliverables of the architect.