Modeling Maturity Levels

Floor panels

Keith is responsible for providing the best floor panels installation experience in the world.

Of course, he is not working alone. His friend, Kim, started the journey in the floor panel business.

Kim needs to learn the jargon and the proper skills - he's smart so there's no doubt he won't do so.

Both came to do a job in one newly built house.

When they entered, the material was laying on the concrete ground.

The valid ones?

They started planning the work and the first thing that Keith begun with was using a impermanent, black marker.

Kim was a bit confused because he saw that Keith wrote on each "VALID" panel. But maybe that's the industry standard?

Each time after the panel got placed on the ground, Kim's task was to go and erase "VALID" text. Keith advised to write "INSTALLED" on it instead.

It looked quite strange, but maybe it's the industry standard?

Kim asked Keith what's the point with "VALID" and "INSTALLED" markings and got a simple reply: when a floor panel has "VALID" text, it can be properly installed. When "INSTALLED" text is written on it, then no further work on it is possible.

Well, that sounded a bit straightforward - only not installed floor panels can be placed on the ground, whereas those ones already laying there can't be installed anymore.

Still, Kim didn't know why Keith names each one to be installed as "VALID", but it might be the industry standard?

What do to with invalid ones?

From time to time, Kim and Keith needed to cut some floor panels to fit them into the right place in the room.

Just after cutting was completed, Keith advised Kim to erase "VALID" and put "INVALID" instead, provided that it cannot be further used.

Some of them were too short, too irregular or cut with a very strange shape. Kim was able visually distinguish them, but he did what Keith asked him for.

After couple of hours full of work, they finished they job.

The hourse owner appeared and was impressed by the outcome. However, he had two questions.

"Why all the installed floor panels have "VALID" text on them?", asked the service taker.

"Ah, that's because we wanted to indicate they can be placed on the ground", Keith anwsered. He seemed very confident with his words, he wanted to sound very professional to impress Kim.

"Well, couldn't you just look at them? It's pretty straightforward to know so?", the house owner was shocked a bit.

He urged both Kim and Keith to erase this marking from each installed floor panel.

After the task was finished, the house owner asked the second question.

"What is about that pile of irregular and cut panels? Why do they have "INVALID" text written on each?", the house owner grilled them with quite logical reasoning, simultaneously pointing at the pile.

Do you like art?

"Each floor panel with "INVALID" text, written on it, cannot be installed, but is still owned by the customer and can be further used.", Keith continued.

Keith told him that he can't throw out the product that was bought by the customer.

Kim couldn't believe in Keith's words.

"You must be kidding, right? IT IS A COMPLETE WASTE!", the house owner yelled vigorously.

"WHAT CAN I DO WITH A FLOOR PANEL THAT IS CUT LIKE THAT?", the house owner got a bit angry while showing a bizzare looking shape.

"Do you like art? You could think of a creative way of putting them together. If you take this...", Keith grabbed one.

"Enough. Take all "invalid" ones and throw them out. It's a complete waste", said the service taker.

Keith nodded and cleaned up the place from all the waste.

Kim and Keith left the house and were about to put leftovers into the trashbin, but Keith wanted to do the last thing with them.

"What do you want to do, Keith?", asked Kim.

Keith advised to put "WASTE" text on each. "That's the industry standard, Kim. It informs about what its status.", said Keith.

Magical thinking

I wonder what would be your reaction to such "an experience". Will you be shoked? Ashamed? Astonished?

Would you need written text to determine what a given floor panel could be used for? (it would be strange if you need 🤔)

I consider this exemplary, short tale, not as imaginary one. It's quite opposite.

When collaborating with business stakeholders, we might often hear very precise verbal descriptions about the context and related rules.

Especially when talking about concepts with the lifecycles - like a floor panel in our small scenario.

Almost immediately, it gets magical "status" attached to it. Fellow technical people easily put "a flag" to represent a specific status (if you want to check why this might not be the best modeling method in this blog post Bool considered harmful?).

The worst thing is that we "polluted" other minds with "status thinking". It isn't extraordinary to hear a domain expert saying "it's just a IsValid status in the database".

How does this "status" come from? Isn't it our magical thinking that might make the given concept have "status" stitched to it?

A floor panel has a status.

Really? This is one perspective - description of the properties.

One could ask: what else a floor panel has?

Along with the status, it might have a nominal weight, an actual weight, a size, a color, a batch serial number, but maybe also a marketing name, an actual name of the material?

Still, it's a single perspective.

Three perspectives of modeling

I mentioned them briefly in Software Engineering for busy parents blog post, but now it's time to give my perspective (pun intended) and observations.

Originally, it is mentioned in the book Rethinking Systems Analysis and General Thinking by Gerald Weinberg, elaborated thorougly by various people (for example: in Legacy Fighter course, by Mariusz Gil in Better Software Design podcast and by Sławek Sobótka).

But let's hold on a second. You probably already noticed I like to focus on the language we use. So what does it mean an aspect or a perspective?

They both might be related to various forms, different point of views.

We sometimes say "see it from a different angle", "you need to distance yourself from it" or "let's view it from a higher point" - each of those phrases is related to the position of an observer.

My reasoning wasn't clear - how to think about the three perspecitves? How to use them?

I haven't still introduced the perspectives, so here they are:

• Being
• Behaving
• Becoming

Each aspect has a set of associated questions:

• Being: What it has? What does it consist of? What is it?
• Behaving: What does it do? How it can be used? What one can do with it?
• Becoming: What does it change into? What it becomes? what can be created out it?

We could explore and find even more questions, related to the given aspect, especially those ones about the rules and invariants, but for now it's secondary.

We might say that one could have three different perspectives on how to look upon a given concept (in our current example it's a floor panel).

What is the perspective about the perspective?

As we discussed, it is important to envision an observer, when talking about the perspective. What metaphor would we use to visualize it?

Angle?

Distance?

Height?

The initial gut feeling was strongly related to an angle metaphor, hence the given visualization:

A floor panel and the three perspectives.

Imagine we are placing the observer (represented as an eye in the next picture, visible below).

Such approach excludes other perspectives, if one decides to go with a specific one, e.g. Being aspect. It would mean we see the given concept through either Being or Behaving or Becoming perspective.

A floor panel perceived from Being angle (perspective).

We could look at something, but only from one aspect at the same time.

In our tale, a floor panel had "status" associated with it and later we also enumerated couple of other traits. In the code, it could look as follows:

public class FloorPanel
{
    public string Status { get; set; }
    public double Width { get; set; }
    public double Height { get; set; }
    public string MaterialName { get; set; }
    public string MarketingName { get; set; }
    public double Price { get; set; }
    // ... other properties and answers to the question "What it has?"
}

But wasn't there any behavior related to such a floor panel? Oh yes, it was.

Even for such a toy example, thinking about "the structure" and answering the question "What it has?" made us focus on the static aspect of the concept.

We already know that both Keith and Kim were using floor panels across their workflow. So the behaviour didn't disappear.

A floor panel traits like Color, Width, MarketingName do no convey the context. They are meaningless, useless. When we put them next to the behavior, they become more meaningful - Install a floor panel, Cut a floor panel, Throw away a floor panel.

So the answers to the questions, related to the Behaving aspect, "What does it do?" or "How one can use it?" are solved at some point, the only question is - where? On what level (or layer?)?

Taking into account a floor panel model presented above, in the code, we would probably express the Behaving aspect on the service layer - a typical anemic model and "rich" in logic service layer.

As with Being aspect and behavior, similar might applies to Behaving aspect and the description of what a given concept has. We wouldn't be able to use only behaviors to express it completely.

What about the language?

Let's focus on the language again.

All the questions related to each aspect, might imply a certain language that is going to be used when trying to look for the answers.

What are the types of words that might match each of the perspective?

We might naturally observe that Being aspect is related to nouns - a floor panel, a color, a size, a marketing name, a price, etc.

Behaving aspect might correspond to verbs - install, throw away, cut, erase, write, etc.

The first observation might be that Being and Behaving aspect need to go hand in hand to provide a proper meaning - the King of Kings - the context.

What about Becoming aspect? (probably the most mysterious one 🤔)

The closest type of words I found describing it in a good way is adjective noun collocation. Let's check it's definition.

Examples of adjective noun collocation:

• installed floor panel
• broken car
• rich answer
• approved document
• completed task

It's very interesting - almost like attaching the context to the noun, without explicitly stating the verb that caused it.

Language and modeling perspectives

As Being and Behaving aspects needed each other to provide a proper context, Becoming aspect isn't perfect, but conveys the meaning and possible causes by building on top of the remaining aspects.

We could for example ask: What information and what actions are needed to have approved document?

The language defines the context

How could we actually use it in the code? This is something which most of us are interested in on daily basis.

We typically use nouns to describe data (or information), verbs to express behavior (or actions) and adjective noun collocations to manifest the consequence of a transformational behavior.

Also, throughout of this reasoning, one might notice that none of the perspective is sufficient alone (e.g. a noun without a verb - how useful is Color trait of a floor panel? We don't know without putting it next to the verb).

That might mean that "angle"-like visualization and metaphor for those perspectices isn't the most suitable one.

Let's distance ourselves a bit

When we are examining a concept, we would need to look from all possible angles to evaluate its usefulness in a given context.

Should we try another metaphor for mentioned modeling perspectives?

Let's go back, for a while, to the questions related to each perspective, but now putting accent on the rules that are relevant, we might get the following:

• Being: What is the maximum size? What colors are available? How long marketing name can be?
• Behaving: Is it always possible to install a floor panel? What information we need to have to decide if it could be installed, e.g. the actual size in comparison to required size?
• Becoming: What we can do with a not installed floor panel? What can we do with an irregularly shaped, cut floor panel?

Each of them use different language, and we already discussed it a bit. Rule-wise, Being is much more general, whereas Becoming sounds highly contextual.

What's more, as Becoming attaches more of the consequential context to the verb, it induces the related behavioral causes based on the rules and implications of them.

Same works for Behaving that requires contextual information to satisfy the rules of a given behavior.

For Being, the rules are very primitive, almost a data-oriented.

Instead of looking from different points, let's look from the same point, but from different distances.

So not from a different perspective, but look through a different perspective.

Looking and modeling through a different perspectives

Modeling Maturity Levels

This metaphor gives us some interesting properties because now we are positioning the observer (ourselves) almost like on the various heights, distances or levels.

One could say that when we are looking from a Becoming level, we have process perspective on a given concept. Such perspective require defining possible behaviors (or actions) to obey the transformational rules. Then, each behavior demands a set of information to satisy the invariants.

This might mean that observing a given concept from a specific level, requires including lower levels.

Distancing the observer gives the possibility to attach much more context to the analysis - either to Being or Behavaing aspects.

For example, when we have a cut floor panel then it might be installed if it fits the required size, or be thrown away if it has too irregular size and shape.

What's even more interesting, when a floor panel is thrown away it becomes a waste. It's no longer considered as a floor panel.

Such reasoning might constitute that Weinberg's three perspectives of modeling might be actually closer to levels, rather than perspectives.

As we discussed, perspectives incorporate the notion of the angle, whereas height/distance opens a possibility to include all underlying levels while modeling.

Being inspired by Richardson Maturity Model for REST, I started thinking about modeling, using discussed levels, as Modeling Maturity Levels.

Modeling levels

It could also be thought of as Model Maturity Levels, meaning that depending on what level (height or distance, as well) we "place" ourselves while modeling, the richer model we will get.

Also, it corresponds in an interesting way to the approached I already talked about in Many faces of DDD Aggregates in F#- one could say that the functional FSM approach incorporated Becoming level, pulling all "lower" levels into analysis and development.

It clearly shows the impact of using proper language and beyond "status thinking" approach (you can read more about such topics in Language of the problem and Bool considered harmful?).

But let's stop for a sec here, what about "angle"-like thinking about modeling - should it be that easily discarded and undervalued?

Is there a single modeling context?

"Looking from a various angles" is still valid, and required!

As Modeling Maturity Levels might provide a huge benefit for finding the richness for a given model, it applies to a single context.

It might mean that in installing service context, a floor panel might be behaviorally rich. Contrary to that, in product catalogue context, it might be shallow and work on the primitive data types level.

Those two contexts have totally different modeling levels and that is fine, as long as we manage the complexity of each context bounding it respectively.

When we combine two metaphors for modeling, levels and angles, we might have interesting mental model that can be visualized in the following way:

Combining levels and perspectives when thinking of modeling

Knowing what are the business contexts, in which our concept gets materialized, we are able to analyze and determine the level of richness.

Looking at a concept through various levels and from a different perspectives

Each "eye" (a process of observation), for a given angle, is placed on a certain level.

This might mean that we "see" contextually various sets of rules to satisfy, depending on the level we are "standing" and observing.

As it was once said, "all models are wrong (=imperfect), but some are useful".

Final words

Should you start using Becoming level in your next CRUD? Sure, don't forget to add Kubernetes to the stack.

As with everything, the context is the king. Simulation in your head and analysis doesn't mean Becoming level need to materialize in your code.

You might have InstalledFloorPanel, WastedFloorPanel, IrregularlyCutFloorPanel, CutFloorPanel and FloorPanel concepts in your codebase and have only tiny gap between the language used by the business experts and your code.

Will it be free? Nope, it will require effort, skills and competence to utilize such mental model.

One might be also afraid of The cost of modeling, but simplification doesn't mean the complexity of the reality disappears that easily.

We could happily model business concepts using data model (data structures) and say "this is fine" while sitting in the room full of fire.

The understanding, the reasoning, might suffer and this is the first step to hell.