# What is Product Architecture? There are several definitions of architecture. See below. ## Classic Systems Engineering Definition "The structure, arrangements, or configuration of system elements and their internal relationships necessary to satisfy constraints and requirements." *Professor Edward F. Crawley ESD.34 - System Architecture IAP 2007* ## Product Design Development Definition "The arrangement of the functional elements into physical blocks." *Ulrich & Eppinger, 2012* ## Software Architecture Primer "The whole consists of parts; the parts have relationships to each other; and when put together, the whole has a designed purpose and fills a need." *Reekie & McAdam, 2006* ## Patterns in System Architecture Decisions "An abstract description of the entities of a system and the relationship between those entities." _Selva, Cameron, & Crawley, 2016_ ## ISO/IEC/IEEE Standard 42010 "The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles governing its design and evolution." *ISO/IEC/IEEE 42010:2011* ## The Open Group Architecture Framework (TOGAF) "A formal description of a system, or a **detailed plan** of the system at component level to guide its **implementation**" (_The TOGAF Standard,_ 2018). # Architectural Features and Decisions The **key architectural features** are those that separate one design from another. Architectural decisions are special: They are not made based on pure intuition but rather require thoughtful analysis of **impact** and **difference.** ### Impact Architectural decisions are the **subset of design decisions** that are most **impactful**. They relate to form-function mapping, they determine the performance envelope, they encode the key trade-offs in the eventual product, and they often strongly determine cost. ### Difference Architectural decisions lead to architectures that are **fundamentally different** from each other. They are decisions that have an impact on choice of **technology**, ability to **reuse**, and ability to **customize**. For example: - which wheels are powered on a car (front, rear, or all-wheel) - whether or not an aircraft has a tail - whether an algorithm runs in real-time or not ### Prioritization How can you tell if a **design** decision is an **architectural** decision? There is a test you can apply to the decision: - Does this decision strongly influence metrics, such as performance, cost, and risk? This is a question about **sensitivity**. - Would substantial rework be required to change this decision? Could we make this decision downstream without regard for other decisions? This is a question about **connectivity**. With these two questions, we can build a two-by-two matrix. Quadrant I holds decisions that are both **highly sensitive** and **strongly connected**. These decisions are therefore **architectural decisions** and will be **prioritized first**. The quadrants are numbered in order of decreasing priority: Quadrant I is the highest priority, while Quadrant IV is lowest priority. ![[Pasted image 20240726173038.png]] > [!Recommended Reading] > Learn more about how Lattix helped improve L.L. Bean’s software architecture and performance by reading the complete [case study](https://www.lattix.com/wp-content/uploads/2019/07/LLBean_Case_Study.pdf). Other case studies and papers are also available on the [Lattix website](https://www.lattix.com/resources/). # Form and Function **Form** and **function** are very important and distinguishing features which need to be decided by the product designer. ## Form - What the system **is**. - The **physical** or informational embodiment of that which exists or has the potential to exist; what is **visible**. - The sum of the objects, which are **elements** of the form. - The **structure** or **arrangement** of objects of form, the “formal” relationships among the objects; this includes shape, configuration, arrangement, and layout. ## Function - What the system **does**. - The activities, operations, and transformations that cause, create, or contribute to **performance** (i.e., meeting goals). - The **actions** for which a thing exists or is employed. - **Functions** are made up of one or more processes. # Design Structure Matrix (DSM) A Design Structure Matrix, or DSM, is a way to organize information and represent the architecture of a product using a matrix approach. A DSM is also known as a: - Design Dependency Matrix - N² Matrix or N² Diagram - Adjacency Matrix (used in graph theory) ![[Pasted image 20240727001420.png]] Most literature simply uses a binary DSM where "1" represents the existence of a connection and "0" (or nothing) represents the absence of a connection. However, in general, we need more details about the physics underlying the functions, which we will see below. A DSM is an N² matrix with the same elements on the left side as along the top, in the same order. In this case, you can see Objects 1, 2, and 3 along the top and left sides. The relationships among the elements are defined inside the matrix. If a component has a physical relationship with another, clearly there is a relationship in the other direction as well, resulting in **symmetry**. It is also possible to have relationships that are **asymmetrical**. Functions like flow of information, mass, fluids, or energy could be unidirectional and therefore not symmetrical. In a DSM, we can also track dependencies, which is useful for analyzing architecture and innovation. For this, we start with a list of all the components and then create a matrix (a grid) where the components are listed along each row and column. Put marks along the diagonal, so that column A, row A is always marked (since tautologically, changing A requires changing A). If changing component A necessitates changing component B, put a mark in column A, row B. A is called the "modifying" component and B is the "dependent" component. ![[Pasted image 20250329105403.png]] >[!Figure] > This shows the next simplest case, where there is a single dependency. Changing component C requires changing component A as well. Note that the dependencies are one-way: In this case, changing component A does _not_ require changing component C. ![[Pasted image 20250329105526.png]] > [!Figure] > Here’s an example of a real-life DSM, in this case describing a combustion engine. Engineers commonly used DSMs to capture more complex information than this model needs — in this case, the different colors describe different sorts of relationships. This model would consider any color to be a marked box. Adapted from Browning, T. (2001) Applying the design structure matrix to system decomposition and integration problems: A review and new directions. IEEE Transactions of Engineering Management, 48(3). [URL](https://www.researchgate.net/publication/3076682_Applying_The_Design_Structure_Matrix_To_System_Decomposition_And_Integration_Problems_A_Review_And_New_Directions) ![[Pasted image 20250329105642.png]] >[!figure] > This real-life DSM describes a design process. This illustrates how a DSM can be used for soft technologies as well as hardware. Adapted from Browning, T. (2001) Applying the design structure matrix to system decomposition and integration problems: A review and new directions. IEEE Transactions of Engineering Management, 48(3). [URL](https://www.researchgate.net/publication/3076682_Applying_The_Design_Structure_Matrix_To_System_Decomposition_And_Integration_Problems_A_Review_And_New_Directions) ![[Pasted image 20250329105157.png]] >[!figure] > This shows two different ways of viewing DSMs. The first is a grid. The second shows it as a network, where each component here is represented as a circle, and dependencies are shown as arrows. So, for example, this shows that component C depends on component B (and component B modifies component C). In other words, if B is changed, then C must change too. # Generic Objectives of Product Architecture - Enable better quality through **decomposition** that simplifies the total design problem. - **Deliberate reuse** of components in new products via a Product Commonality Plan. - Clean interfaces to the external world. - Isolation of change and reduction of impact on: - Technology used for implementation - Operational environment (networks, customer use, etc.) - To make a product extensible: giving the **ability to change** its performance, add new functions, add new combinations of components for new products, and make other improvements and changes over time.