This post is the third in a short series on how to talk about modeling in the scope of product (or systems) development. You can read the other parts here:

• Part 1: Model vs. Tool
• Part 2: CMT/A

For the explanation in this post, I am going to use the CMT/A thinking tool, which distinguishes between a tool (T), its underlying concepts (C), a method (M) on how to use the tool (or which may be supported by the tool), and a specific situation to which the tool is applied: the application (A).

Each of the distinguished aspects (CMT/A) typically has a number of assets (sometimes also called artifacts) associated with it, which encode it. For example, applying a digital tool, will have one or more models associated with it that can be related to the tool. As an aside: assets are not only digital, since you can perfectly have a model on paper as an asset. For some contexts, it is important to ask yourself what the maturity of a specific asset is.

When we talk about maturities, you can make it as easy or complicated as you want (e.g. defining strict technology readiness levels or model readiness levels), but I have been using a pragmatic and relatively easy to introduce definition of maturity levels:

1. I only have an idea, but didn´t do anything serious with it.
2. I have a proof of concept and it does approximately what I need, but I didn´t yet make a full prototype.
3. I have a full prototype ready to be used, but only I know how to use it.
4. We have proven it in one product development project.
5. We have proven it in several product development projects.

It is important to note that the maturity of the tool, the application, the model, and even the concepts are not automatically equal in a specific context, but can greatly differ from each other. You can have an off-the-shelf tool that you buy with a very high maturity, but maybe no-one has an idea how to apply it in your problem domain in order to solve a concrete problem. So your application might then be level 1 (we just have an idea on how to apply it but didn´t really do it yet seriously). By being more precise, you can gain much more understanding in a specific situation, but you can also use this to take decisions on what next steps to take: do I want to improve the tool, or do I need to get more into its application, or do I need to extend the set of concepts, etc.

Let’s illustrate these possible differences in maturities in the following two examples:

• We have a commercial tool which is applied in 3 different contexts. In context A, someone is able to apply the tool, but it’s not yet self-explanatory. In context B, someone wants to apply but didn´t seriously start yet. Finally, in context C someone already has an idea of how to approach the tool application.
• We have a domain expert that has been doing their work for 20 years, having refined a sharp and consistent set of terms that he is using consistently in documentation, explanations, and any other work he does. The domain expert already is underway in explaining the gutfeel and intuition he built through the years to his colleagues as an explicit, repeatable method. Because some of the work is already so well-understood that he sees it as repetitive, he is starting to look into tool support, but he didn´t yet think it all through fully.

The two situations are really different and require different handling. In the second example, you may want to work more on the tool still and then on the cases, because we trust that the domain expert knows what he is doing since he has been doing this in many products over decades. In the first case, there is nothing to do about the tool, but it’s important that it becomes clear how to effectively use it in all relevant contexts. The nice property of distinguishing up to this level of CMT/A and adding maturities, is that by being more specific, you can be much more precise in communicating the needs of a project/context, as well as what is the status and what are the plans.

By being more specific, it is easier to communicate needs, status, and plans. Not only for tooling and way of working, but also for the product development itself.

This concludes my third post on How to talk about systems modeling. If you found this helpful, stay tuned for the next post in this series: stakeholders and expertise.