Decision: Product Architecture

Within the Product Concept branch of the Decision Driven® Strategy pattern, there’s a rich set of design decisions that address Product Architecture.  These are the engineering decisions that balance how the product will be realized between hardware, software and human operations (user tasks).  If you’re not a systems engineer, you might want to avert your eyes at this point …

The alternatives in the Product Architecture decision are typically represented by some type of block diagram or layer model that shows how the functions that the product must deliver are allocated to hardware elements, software elements and user actions.  This split defines the level of automation or automation boundary of the product.

The functional design of the product begins with a State Model.  States are typically groups of functions that are activated for a particular phase in the product’s life cycle or mission.  For example, most complex systems have a setup/configuration state, a maintenance/diagnostic state and one or more operational states.   In each state, only some of the total functionality of the device is active.  If you’ve recently programmed a DVR or Hi-Def TV, you likely switched the device into a “Setup Mode” in which it automatically searched through your channel lineup, detected which channels were available and did some magic so that only those channels would pop up when you “channel surf” in the operational state.

There’s usually a technology decision for each function that the product must support, i.e. what technology or method will we use to deliver or implement this function?  These are some of the most vital decisions that drive product design.

The detailed design of the human interface/interactions and hardware and software components then follows.  This is where you select the various building blocks of the solution and how they will be “wired together” to make the whole solution work successfully.

There may be a set of “Specialty Engineering” decisions that cut across the product design to optimize certain aspects of the solution.  These are typically called “Design for X” (DFX) decisions (e.g. DFA = Design for Assembly) or sometimes lumped into a group called the “ilities” (e.g. Testability, Producibility).

While there may be hundreds of decisions within the Product Architecture branch for a complex product, the good news is that usually only a handful are the “vital few” that will make-or-break the design.  Your first task when building a Thinking Breakdown Structure for your product is to use the Decision Network pattern to identify these high priority decisions.  This allows you to focus your brainpower on the most important questions and find an effective balance between 2 competing design philosophies:

• The devil is in the details
• Don’t sweat the small stuff!