I often repeat the claim that decisions provide the context (superstructure, framework, skeleton, glue) for all other future-focused information. Decisions create the future and anything that exists (as far as humans can reach) flows from conscious or unconscious decisions on the part of human beings.
Today, let me pick on models. I know there is much industry buzz associated with model-based systems engineering or model-driven design. However, models really shouldn’t be touted as the glue or engine for creating anything. They have one simple purpose – to inform decisions.
A model is a representation of the structure and/or behavior of an alternative. As such, it enables the decision-maker to stand in the present and estimate or predict how well an alternative will perform against one or more stakeholder criteria (requirements, goals, objectives, constraints). A model is a shortcut that saves time; with a model you create a limited version of the real alternative instead of having to build the real thing. Building the full solution would yield better data, but in the design phase we can seldom afford the time and investment to use a 100% trial-and-error (build, then test/measure) approach.
If you pull a model out of its decision context and make it an end in itself, you run into all sorts of foolishness. People start to model for the sake of modeling; they create detailed models well beyond the fidelity (precision) required to make a confident decision. What a waste!
The most serious error that I’ve seen from model-centric design is tunnel vision. If an engineer or software developer creates/draws a model and overlooks the fact that their “boxes and arrows” represent just one possible alternative solution, it can easily become “the” solution. A model can “balance” and account for all of its inputs and outputs correctly (i.e. be valid), but still stink in terms of its effectiveness in meeting stakeholder priorities. Until you use the model as one input to the decision, to estimate the effectiveness of the one alternative it represents, you can’t tell whether there may be 2, 5 or 50 other alternative constructs that could perform better. From my experience, it’s better to think of 3 or more widely varying solution concepts (alternatives) first, describe their differences with their names and a sentence or two, before you draw the model of the first alternative. Even the simplest model, a decomposition represents an alternative in a decision; you could always break down any structure a different way that might be more effective.
Some might claim that they use models to represent requirements, not solutions/alternatives. However, decisions create requirements; every requirement is a “derived requirement”, an inherent consequence of a committed alternative in an upstream decision. So if you build a requirements model, you’re really just elaborating the structure and behavior of an alternative in a higher-level decision.
Models are great; I use them all the time to inform decisions. But they’re not central to the design process; they serve their decision masters!
Use the Decision Breakdown Structure (DBS) tool available within the Decision Driven® Solutions Framework (DDSF) to define decisions for your project and then inform these decisions with models data. Please contact the Decision Driven® Solutions team at email@example.com or firstname.lastname@example.org to start your free trial of DDSF.