Model-Based Business Engineering, Blog by Dr. Juergen Pitschke, +49 351 30935193 This email address is being protected from spambots. You need JavaScript enabled to view it.g

Current Read finished - Summary

I finished my recent reading of "Business Knowledge Blueprints" by Ron Ross. I have been a supporter of the ideas by Ron Ross and Gladys Lam for many years. Therefore, the statements were not entirely a surprise to me. In my workshops, I present Concept Models not as a standalone model, but in relation to the development of other models: business process models, business rules, business decisions, business requirements, and others. Concept Models are associated with many working techniques of business analysis.

Where did I want more/new ideas?

  • Language Communities
  • "Serialization"  

Language Communities

Fortunately, in the EU, we now have a number of "mixed" teams. People of different nationalities, speaking different natural languages, which are influenced by very different cultures, work together. In addition to a precise definition, we must keep this context in mind when defining concepts (nouns and verbs). In Ron's book, you find the statements

"Providing a definition doesn't necessarily mean you will understand how an instance acts, looks, or feels."

"Descriptions add details that help you form a mental image."

In my workshops, I often talk about "secondary model content". This is model content that is by no means "secondary" but does not reflect the "real" model content (as opposed to "primary model content"). "Secondary Model Content" helps us to capture the context more quickly and to improve understanding. In the book, for example, Ron has the concept of an "Umpire". This concept and this word would not come to my mind in the first moment. Other sports are popular in Germany. Therefore, the concept of "Referee" or "Schiedsrichter" is more familiar to the mental image of a German.

Serialization / Transitive Relationships

In practice, we often have transitive relations. The "shipment" is "stowed" in a "container", the "container" is loaded onto a specific "ship." The "ship" is "booked" for a specific "route" on a given "departure day T". The "route" has a specific "destination". Serialization offers the possibility to be exact but is often complicated for daily business communication. For example, we say the shipment for destination O. To be exact, it is more precise to say: "The shipment S stowed in container C, loaded onto the ship S, booked for the route R on departure day T with the destination O. 

We often ask about the concepts in the transitive path. Example: What shipments are on ship S? We often ask independently of the starting point of the path. For example, "What shipments are on the ship S?" but also "On which ship is shipment No. 123?"

Serialization is accurate. A simpler/more comfortable solution is desirable.

 

More Brain food.

Juergen Pitschke