This post is the first in a short series on how to talk about modeling in the scope of product (or systems) development. In my opinion, modeling is a crucial part of digital transformation in product development context, therefore the topic gets early attention in this blog.

I am going to share with you something that I call a thinking tool. This is something we really need to become better at professionalizing these kinds of modeling activities. I’m going to explain some concepts that I developed, which really help to be precise when you are communicating something about modeling and you are trying to explain the impact, or who is involved, or what is the progress, etc. Hopefully it will be helpful for people dealing with this kind of modeling context.

A lot of the questions I get are often based on the confusion around the fact that there is a difference between model and *a tool (typically we mean digital tools when mentioning the word tool) and the distinction between the two.

When talking about modeling, usually there is a tool involved and most of the time the tool is not product-specific (relative to the product you are developing). Often it is a generic tool that we can use in the domain of the product we develop. We apply a tool to a specific problem in our product development and this is the model or the application.

You can apply the same tool in different situations to try to analyze different models (i.e. to solve concrete problems) - so the tool is generic but the situations can be different.

There is a term coming from architecture called form follows function, which means that first you have to know what is the problem you are trying to solve, and only then you will decide what kind of model you need, and only then you will decide what kind of tool is useful. So I can have the same model, but use different tools to analyze the model, but the question or problem that you want to answer or solve is leading.

“Form follows function” → the question/purpose/need is leading! The same question may be answered by different models; the same model may be created/edited/analyzed by different tools.”

To determine what kind of support you need with solving your problem, you can distinguish between different model types. To do this, we need to look at their purpose. There are three main categories: specification, analysis, and synthesis. For example, communicating, documenting, or explaining concepts and how they relate to each other, would be done with specification models. In another case, you would want to evaluate design alternatives and support the design process by finding an answer to what is an optimal solution in a certain situation. This is dealt with by analysis models. An example of analysis would be a simulation, but there are also other types, such as model checking, data analysis, and formula-based calculation. A third case would be synthesis models, which cover producing derived artifacts based on the model. This involves generating some artifact or asset from your model, e.g. generating software code or configuration parameters, generating (pieces of) CAD models, or even synthesizing a physical object, like is done with 3D printing.

What kind of support do I want? → specification, analysis (incl. simulation), synthesis.

Another way to distinguish models deals with what vs. how. For what, you can think about what functionality or product capabilities you are going to make. Examples of questions you can answer with what: “do I want to bring this feature to the market?”, “what is the value of a feature”?, or “what is the application of a certain feature?”. The what part is encountered most often in earlier development phases like architecture and early design, where different options and design alternatives need to be compared and (often) principal choices need to be made. The how part is about how you are going to build or change the product, which is more often encountered in later phases like design and engineering. Examples of how questions would be “what (if any) software library do I use for implementing functionality X?”, “in which discipline are we solving feature Y?”, and “which part should I buy to fulfill sub-functionality Z in subcomponent C?”. When the how can be automated, this is related to synthesis. You may still use what-models in later phases as a basis onto which to specify detailed design parameters or from which to generate artifacts.

What is it about? → what (architecture and design phases), how (design and engineering phases).

This concludes my first post on How to talk about systems modeling. If you found this helpful, stay tuned for the next post in this series: looking further than only tools vs. models by using the CMT/A thinking tool.