This post is the fourth 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
• Part 3: Maturities

As before, for this post, I will use the CMT/A thinking tool as a basis. CMT/A 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).

The first stakeholder role is the model engineer, who deals with the application in order to add new functionality, exploring a design, or doing any other activity that is directly in the core of product development. Remember that this person is using (usually digital) models. The method designer is the domain expert that is doing a certain part of product development for many years and knows best how to solve a specific type of problems. Finally, the tool smith is someone who provides tool support and builds or customizes the tool in this specific situation.

Usually the model engineer asks the method designer how to approach a specific problem in principle, but also how to apply the method. The method designer is already doing solutions for many years and is typically fed up of explaining often recurring questions very often, so he asks the tool smith for automation for certain parts of the concepts and method. The model engineer should get support from the tool smith mainly on how to use the tool, features, bugfixing, and similar practical things. New concepts and functionality should arrive to the tool smith mainly from the method designer. Of course, the tool smith also makes sure that the tool is kept up-to-date and maintained.

It is important to realize that the above are different roles with different concerns. This means they may or may not be actual different people, but it’s important that the roles have different concerns and that they will take different decisions based on which perspective they have. There is a much more extended set of roles to describe your modeling context even more precisely, but we will go into that in a different post.

Just like assets (or artifacts) can have different maturities, people have expertise. Expertise levels were made explicit by Dreyfus & Dreyfus:

1. Novice
2. Advanced beginner
3. Competent
4. Proficient
5. Expert

This is a pragmatic way of defining expertise levels, but you may use any more advanced scale or method to define amount of expertise. Most people in product development are between advanced beginner and competent and it takes quite often more than 10 years to become proficient. So it is important to realize that wanting only experts is unrealistic, since it takes 20 years or more to build this kind of expertise.

More interestingly, in addition to expertise levels, there are various types of expertise. There is expertise in the solution domain (technical part, concepts, how). Then there is expertise in the problem domain (product, problem we are trying to solve, what) - this requires quite different expertise from the former. Let’s use two examples to illustrate this:

• The method designer is quite competent in the problem domain (e.g. car development), but also has done his fair share of modeling and tool support, so he also knows quite something about the solution domain. The model engineer is a novice who just freshly finished their education and knows nearly nothing about the problem domain, but has seen some of tools and is thus not completely new to them. The tool smith has nothing to do with car development yet but has done a lot of tool support and automation. In this case, the tool smith and model engineer are both quite lucky with a method designer who has expertise in both domains and the method designer is happy with the tool smith because he will get what he needs/wants fast.
• The method designer and model engineer could be the same person, because in early phases where you want to automate things, you usually don´t just throw the tool to any user but mostly the one with the expertise is also the first one to apply it. However, the method designer has never done anything with automation. So there is a vacancy for someone that can help with tool support and the method designer would like them to be at least an advanced beginner. Too many beginners and no expertise in the technical solution domain would not help.

Summarizing (at the risk of becoming repetitive): using CMT/A as a base and adding stakeholders and their expertise allows you to be much more precise about the needs and planned next steps in a context (e.g. a product development project, a department, a team).

This concludes my fourth post on How to talk about systems modeling. If you found this helpful, stay tuned for the last post in this series: decision support and context.