Concept maps

"Can you build it?"

Imagine we were challenged to build a software for organizing workshops.

Investor came and suggested that they have a brilliant idea and their novel approach will make millions.

Because of being a "yes-man" type of people, we said "yes".

We called them for another meeting in order to get proper details.

What is the relationship?

They started laying out the information (for your information: the "speech" is a raw stream of characters/words/sentences to simulate "real-life" conversation, or monologue if you wish - "real-life" means cognitive loading).

Apparently, they were technical IT folks, who built many enterprise solutions.

The investor suggested drawing a data model in order to provide clarity what is related to what.

As we are experienced too, we focused on the entities, or nouns, if you will.

What concepts are there?

We weren't lazy so we got some additional questions about how those things are related to each other - as they suggested.

How concepts are related to each other?

Now, the chaos started becoming tamed.

The orders began emerging.

As expected - a Workshop is a central entity there.

Main entity in our data model

What's more, we listened carefully and our model includes a possibility that a Workshop can have no Premise or no Attendees.

Only when an organizer has an "idea" for a Workshop.

Does our model cover that?

We are experienced developers and/or architects, we know how to deal with such a problem.

a Workshop has a Status.

Trivial! A Status.

Now, finally, everything is complete - our model is flexible - we can model "a workshop, that is a mere idea, can have no attendees and no premise".

Good'n'old Status solves that and we can even write a specification, in the form of a test, for it: should create a workshop with status 'WorkshopIdea' having no premise and having no attendees. (Curious why am I so explicit about specification and test? Please check "The ambiguity" of TDD)

Terrific.

How it evolves?

What do you feel right now?

Does it look familiar?

Can we, taking into account our data model, tell anything about what is possible? What activities, operations and rules are there?

We could argue - that's only a data model, it's a single view on the system.

Does it express what the investor was telling us? Sure - one might say.

If we wanted to look how the central "entity", a Workshop, evolves - where could we find this information?

Possibly in the "user story" or in an "issue" in Github.

Maybe even in a executable specification as a test!

This data model expresses the static aspects of this small realm - a realm of how entities are related when thinking about workshop organizing.

When we look from a Modeling Maturity Levels perspective, we captured the reality in the form a Being aspect.

As a reminder for ourselves, each aspect is related to a set of questions one might use to model this aspect.

Clearly, we can say that, for instance:

• a Workshop has none or many Attendees
• a Workshop consists of none or many schedules
• a Session has one to three Teachers,
• etc.

Simple.

But can we capture the problem space from a different level - still focusing on the main concept? (please pay attention I deliberately used a "concept" word instead of an "entity")

"Look Ma - no status!"

Let's try to pay attention to the language.

Our investor haven't used Status in their stream of words.

What have their used? (play with the discussion by clicking on the tab titles)

By carefully listening, we were able to capture the following group of words:

• "workshop idea"
• "planned workshop"
• "'approve' workshop"
• "workshop gets published"
• "workshop"
• "workshop is finished"
• "workshop 'rates'"

Of course, there might be much more, but at least that's what we were able to find.

Let's draw them.

Is there a single workshop?

We used "nouns" with a "companion" - an "adjective". Just by doing so, the context got enriched.

Are they similar?

Based on the discussion we had, we know that each "workshop" might have some different details - or maybe differently named details?

Let's take the first one - Workshop "Idea".

We know that it comes from an Organizer and we can assume there's nothing more than a Schedule (is it any Schedule?). Let's model it further.

"workshop idea" has a...

We can assume, by knowing what our investor mentioned, when they think it's a good "idea", then they start working on a Planned Workshop.

An Organizer checks how many Prospects might be interested for attending.

Let's model that.

"planned workshop" has a...

We know that when an Organizer feels it pays off to run a Workshop, they approve it and publish it so that people can sign up.

This is the time when teachers are appearing with a detailed schedule.

Let's model that.

"published workshop" has a...

Finally, when the time comes, a Workshop is run - there are Sessions carried by a Teacher for Attendees.

Then, when the time is up, Workshop becomes Finished Workshop.

Eventually, people can rate the Finished Workshop so it becomes Rated Workshop.

Let's see it.

"Where are my relations?"

I hear you, my dear Reader: "where are the lines?", "what are those floating gizmos?!" (or am I hearing myself?)

Is there any point to put lines?

I believe one could get the feeling of what is communicated through this little "model", even without "lines".

Actually, the lines might no longer exist.

Why? Because we don't need lines. We need arrows.

Suddenly, instead of a "static" relations, we got a flow, a direction.

Our model stopped envisioning structures and started expressing the process.

It shows how "things" are getting transformed over a period of time (note that there's no timeline drawn!)

And where is our "friend", Status?

"There is no spoon"

What if I told you there is no spoon, ekhm, status?

At least on this level.

We don't need it because we tried modeling domain concepts by capturing the language. Our investor didn't mention any status!

It still might appear and live a good life but in totally different plane.

What plane?

Infrastructure - think of sending it over the wire or storing it in a database - "status" is a word that "infrastructure experts" use when it comes to mentioned activities.

Domain-Driven Design encourages modeling solutions around the language - and "status" has its place too - in the "domain" of the infrastructure.

Nouns = bad, Verbs = good

Modeling around behaviors, hence "verbs", was always a desired direction, however, not always followed.

We were skilled in "looking for nouns" when exposed to a problem to solve.

Focusing on Behaving level (you don't know what I am talking about? Please check Modeling Maturity Levels) has its benefits when it comes to modeling.

Especially, when we compare it to Being level.

Nouns themselves are not "bad" or "not suitable", when we think of providing a model to a given problem.

They "just" need a friend - adjective.

By using adjective noun collocation, we might explore the concepts in their natural habitats, capturing the context.

What naturally emerges from using this linguistic construct is a transformation of lines into arrows.

Semantic mapping - static perspective on vocabulary

There is a "technique" for mapping out all the words and vocabulary - it is called semantic mapping or semantic maps.

Using it in the right context, brings clarity and understanding.

Various resources use something similar to explore and lay out vocabulary of the domain (for example: see in Object Thinking).

We, developers and architects, are pretty familiar with "entity relationship diagram", when it comes to "modeling" (modeling what?).

When we apply our knowledge about database tables design and semantic mapping - we might get something that resemble "entity relationship diagram".

"Lifeless" structures that "only" capture what is the best way of archiving them so that retrieval and searching will be optimized (here I am generalizing and putting some assumptions, but I hope you bear with the direction of thinking).

Behaviors, responsibilities, evolution and transformational nature are kept somewhere else (if any).

Concept Mapping - transformational perspective on vocabulary

As we saw in this little example, there is an informal way of capturing the essence of the language, used by human beings.

Each of the concepts, we explored, could potentially be a subject of a process.

With high probability, most of them have "CRUD"-like lifecycle and their evolution does not have any restrictions.

Looking at the rest of the concepts, from a Becoming perspective, might reveal very interesting properties of the system that we are trying to model.

Let's then focus on this transformational, processing aspects.

Even when we study "process" word definition, we might get interesting insights:

Sequential in nature, actions driving "a process" to the terminal state. Pretty straightforward.

But this is a "noun"-based definition, and nouns are bad because they anchor ourselves at the "entity"-thinking, right?

Let's check "verb"-based definition!

Again, serial nature, but the end of the sentence sheds some light upon our thinking - "to change or preserve it".

If we take our tiny tale and have "transformational" perspective in our head, a "workshop" is being processed in a serial steps and each step "transforms" it, in some way.

As mentioned before, we are not using "lines" but "arrows" to emphasize this aspect.

To distinguish such "mapping" from semantic map (which, in the scope of this tale, is considered capturing "only" static aspect), we could call it a concept mapping.

Those are just labels and we shouldn't cling to them - names can come and go, meaning might remain the same.

Change, change never changes

Imagine that our investor comes and gives flattering comments about precise "entity modeling" by using adjectives, next to nouns.

They forgot to include one important fact, when it comes to organizing workshops.

"Sometimes we need to cancel a workshop", said the investor.

As we have "various workshops" at our disposal, we can be very precise in asking what does it mean "cancel" and what are the consequences for:

• workshop idea?
• planned workshop?
• published workshop?
• workshop?
• rated workshop?

After a brief thinking, one can be pretty confident that "cancel" has many meanings and consequences. So not every "cancel" is the same "cancel".

When such a fact occurs, it might bring manifold of the effects - depending in which state a workshop currently is.

We could even say that a given workshop "changes" into another by transitioning from one state to another.

All this lingo around state, transitions, effects, facts - or if you like - events, can remind ourselves that we are talking about pretty well-established "pattern" of computation.

From concept maps to state machines

Imagine, based on our investigation, that those states and transitions between them are possible:

Could you name the "operations" that might happen between any two states?

I believe that in "entity relationship diagram" it would be a little bit harder.

Of course, we could argue that there are places and occurences where such a diagram shines.

No doubt on that.

But, more we go into the "processing" aspect of our little domain, the more it makes sense to use transformational-oriented modeling techniques.

It's very easy to jump on the "it is easy" wagon and model (or even worse - start implementing, immediately!) solutions to the problems with "simplicity" in mind.

The worst part of this kind of reasoning is we are misinterpreting "simple" with "naive".

With high chance, the most of the problems, we would need to find a solution to, will require CRUD-like model.

What about the rest?

Slow down, don't be afraid transitioning to "I don't know"-state (pun intended!) and pay attention to Language of the problem!

What's next?

It might sound trivial and simplistic approach but I find it useful - even when it "just" comes to thinking.

Concept mapping might give a new life for using "nouns" when modeling.

It's very common for "business" people too - they got "infected" (by "us" - technical people) with "Status-Driven Thinking" so it might be very interesting exercise to show an alternative.

Burying the transformational nature of the problems won't magically vanish, as essential complexity might involve such a trait.

And, as mentioned during this tale, it might seem we are inducing a lot of effort and complexity. The cost of modeling will still be there.

The question isn't "if" but "when" and "where".

Are you dare to pay, consciously?