Integrated System Engineering—Reducing Complexity…
Product Architects capture customer needs, translate those needs into design decisions that are communicated to the project thru design spec’s
One of the markers of today’s products is increased product complexity mostly around the combination of hardware, electronics, and software…
- “The vehicle is becoming the largest piece of consumer electronics a person will own” Raj Nair Ford CTO[i]
- Boeing 787 has ~5000 sensors, ECU’s, etc. communicating over 9000 connections via 1,000,000+ types of messages, performing 2000+ functions in triple redundant, physically separated fashion with each tail number a different configuration
- BMW has such a wide variety of options available on their 5 series, that ‘no two BMW 5 series sold last year was the same’
To handle complexity, our brains automatically decompose what we see into its constituent parts, making decomposition an important tenant of systems engineering. If you’d like to see this in action, ask a product architect what they are working on, they will head to the nearest whiteboard and begin drawing boxes and arrows decomposing the system they are working on. To further simplify they will organize the components into an architecture (an architecture is an arrangement)
This product decomposition is important for a variety of reasons…
- Helps us communicate about the product
- Organize the design
- Describes what needs to flow between design elements
- Provides infrastructure for product decisions
…this architecture forms the critical communication mechanism for telling everyone where we need to go and how we are going to get there. These product architects perform the same function as a building architect; i.e. they understand what the customer needs, make decisions on how to meet those needs and communicates those decisions through a set of blueprints. We could never imagine starting a building without a set of blueprints, but often product development is started without a complete set of architecture specs, which means there is no leadership on the project; so we shouldn’t be surprised when we get something out that we didn’t want. Back in the late 90’s, we did analysis into runaway projects (projects over budget, out of control) at a high-tech company, we found that unless we kept the architects ahead of the construction crews, there was a 70% probability of a project runaway. When a runaway happens, the architects go into catchup/documentation mode. This would be like an architect walking around the construction site documenting what the construction crews were building rather than leading the way with a set of specifications.
So how do you know if you have good architecture? That’s a large topic by itself, but we can point out some symptoms of bad architecture…
- Architecture that follows documentation structure–system spec’s, sub-system specs, etc. This often happens in highly regulated industries where you are expected to deliver a set of documents with your design. This often leads to confusion about what your product is—given you spend so much time on documentation you begin to think the documentation is your product.
- Conway’s Law: Mel Conway (some 50 years ago) noticed that product architecture had a tendency to match the organization structure.
Dr. Kim Clark/Dr. Steven Wheelwright from Harvard Business School noticed this as well in organizations they were analyzing for their case studies/books on Revolutionizing Product Development [ii]and used that to predict product issues. For example if the doors of a vehicle were designed in a different part of the organization than the chassis you could predict with some likelihood that the vehicle will have leaky doors. I attended a lecture by Dr. Wheelwright where he described how they could predict next year’s product problems with a high probability. Although it was gratifying how right they were, it was like watching a train wreck because of the systemic nature of the problem—i.e. organization change was required to avoid the problem. - Disconnected architecture—whether in documents or diagrams—if an architecture doesn’t track the changes, variation, product configuration, etc. we end up with a architecture view that is obsolete as soon as you print it (we know something is going to change somewhere).
…thus the importance of an integrated architecture that represents the cross-product arrangement and interfaces needed to pull off the reason you are creating the product.
While working on one project, I was the designee to deliver bad news in a project review… After the swearing was over, the program manager put it this way, “this is like driving a car looking thru the rear view mirror, I can see the problem after I’ve run over it. Why don’t you give me something I can see the problem coming and adjust my trajectory to avoid the problem”
An integrated architecture will do just that; it represents an agreement of where we are going, integrated with the lifecycle should give us constant visibility into it. As things change, discoveries are made, it changes as well, meaning we can see things in front of us rather than just running over them and then having to figure out how to fix the damage and cover the costs of the accident.
Integrated architecture is available now with System Modeling Workbench that’s integrated with Teamcenter Product Lifecycle Management (PLM).
[i] http://www.businessinsider.com/interview-with-ford-cto-raj-nair-2016-1
[ii] https://www.amazon.com/Revolutionizing-Product-Development-Quantum-Efficiency/dp/1451676298/ref=sr_1_1?s=books&ie=UTF8&qid=1481833572&sr=1-1&keywords=revolutionizing+product+development
