# Product Breakdown Designing systems requires problem-solving, and problem-solving requires us to break things down into a variety of smaller, more manageable chunks. These constituent parts of a problem are not isolated from each other, they require some level of connection or linking, in a sort of network. To make things more interesting, the problems we ought to solve are seldom isolated from the rest of the world. We usually deal with a set of connected problems; what management science calls "messes". In this decomposition process, we assign to that network of decomposed bits a structure that often appears to be hierarchical, where we categorize and group things together. It is like forming a small cabinet in our brains where we have little drawers where we put stuff in, and we take stuff out. But do our brains work in this drawer-like manner? The file cabinet approach makes it difficult or impossible to map or reuse the same piece of information in multiple drawers. Each time a change is made to any given file, it must be tracked down and updated in every location in which it exists. This leads to redundancy, with a cluttering of near-identical ideas, and significant work any time a system-wide change is required. It could not be overstated how critical, and ubiquitous hierarchies are in engineering design. It is by breaking—as in, decomposing—things down the wrong way that we can break—as in, destroy—projects down beyond repair; i.e. bad breakdowns can break everything down. Not only do the activities and tasks need to be broken down, but the functional and physical organization of the device-to-be as well. Practically every technical object around us is a container: objects composed of other objects, composed of other objects. Logic gates inside components of a System-on-chip live inside chip packages on top of PCBs which are part of backplanes which in turn are part of units which are then part of a rack which is part of a data center. We commented that during analysis we work with fictional representations of how things will look like, and one key depiction is the architecture. Architectural diagrams allow for an organized sharing of both business and technical information related to a project and product. Architectural depictions are a cornerstone of the systemic approach: a system is ultimately a collection of relationships, interfaces, forms, and functions. The essence of architecting is structuring, simplifying, compromising and balancing. Architectures are a powerful graphical tool for the representation of project aspects, thus capturing the imagination of the people's minds and streamlining communication. Architecture diagrams are the main consequence of the analytical phase. Analysis requires us to break things down by creating a tree-like set of (parent-child) relationships of objects, which in turn expand to many branches themselves. Breaking down means applying a "divide and conquer" approach. The main challenge is that this analysis phase produces many parallel breakdown structures, and not just one. For example, cost analysis, bill of materials, labor, product, and even org charts. The recursive nature of the systems we design doesn't help; this means there are breakdowns inside the breakdowns, and so on. We don't have the luck of dealing with only one breakdown structure; we deal with many of them in a sort of fractal way. Keeping them all aligned is a continuous activity throughout the project life cycle, which must never be abandoned.