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

NOTE! This site uses cookies and similar technologies.

If you do not change browser settings, you agree to it. Learn more

I understand

Privacy Statement


Your personal data (e.g. title, name, house address, e-mail address, phone number, bank details, credit card number) are processed by us only in accordance with the provisions of German data privacy laws. The following provisions describe the type, scope and purpose of collecting, processing and utilizing personal data. This data privacy policy applies only to our web pages. If links on our pages route you to other pages, please inquire there about how your data are handled in such cases.

Inventory data

(1) Your personal data, insofar as these are necessary for this contractual relationship (inventory data) in terms of its establishment, organization of content and modifications, are used exclusively for fulfilling the contract. For goods to be delivered, for instance, your name and address must be relayed to the supplier of the goods.
(2) Without your explicit consent or a legal basis, your personal data are not passed on to third parties outside the scope of fulfilling this contract. After completion of the contract, your data are blocked against further use. After expiry of deadlines as per tax-related and commercial regulations, these data are deleted unless you have expressly consented to their further use.

Web analysis with Google Analytics

This website uses Google Analytics, a web analysis service of Google Inc. (Google). Google Analytics uses cookies, i.e. text files stored on your computer to enable analysis of website usage by you. Information generated by the cookie about your use of this website is usually transmitted to a Google server in the United States and stored there. In case of activated IP anonymization on this website, however, your IP address is previously truncated by Google within member states of the European Union or in other states which are party to the agreement on the European Economic Area. Only in exceptional cases is a full IP address transmitted to a Google server in the United States and truncated there. On behalf this website's owner, Google will use this information to evaluate your use of the website, compile reports about website activities, and provide the website's operator with further services related to website and Internet usage. The IP address sent from your browser as part of Google Analytics is not merged with other data by Google. You can prevent storage of cookies by appropriately setting your browser software; in this case, however, please note that you might not be able to fully use all functions offered by this website. In addition, you can prevent data generated by the cookie and relating to your use of the website (including your IP address) from being collected and processed by Google, by downloading and installing a browser plug-in from the following link:

This website uses Google Analytics with the extension "anonymizeIP()", IP addresses being truncated before further processing in order to rule out direct associations to persons.

Information about cookies

(1) To optimize our web presence, we use cookies. These are small text files stored in your computer's main memory. These cookies are deleted after you close the browser. Other cookies remain on your computer (long-term cookies) and permit its recognition on your next visit. This allows us to improve your access to our site.
(2) You can prevent storage of cookies by choosing a "disable cookies" option in your browser settings. But this can limit the functionality of our site offers as a result.

Social plug-ins from Twitter

With Twitter and its Retweet functions, we use social plug-ins from, operated by Twitter Inc. 795 Folsom St., Suite 600, San Francisco, CA 94107. If you use Retweet, the websites visited by you are announced to third parties and associated with your Twitter account. Details about handling of your data by Twitter as well as your rights and setting options for protecting your personal information can be found in Twitter's data privacy policy:


According to the Federal Data Protection Act, you have a right to free-of-charge information about your stored data, and possibly entitlement to correction, blocking or deletion of such data. Inquiries can be directed to the following e-mail addresses: (


Complex vs. Complicated - Part II

1     Complex or Complicated - Basic Principles of Architectural Modeling - Introduction

In my last post, I argued that complexity is a necessary feature of an architecture to ensure stability, "agility". Complex models require complex models and solutions. At the same time, no user wants to have complicated, unmanageable models.

Important fundamental principles to achieve the necessary complexity while at the same time avoiding complexity and ensuring maintainability is the principle of "separation of concerns" and the introduction of defined levels of abstraction. I want to look at that later.

2     Separation of Concerns and Architecture Frameworks

Several architecture frameworks exist in the market, which help us to organize our models and to implement the principle of "Separation of Concerns".

The most important frameworks for me are the Zachman framework ( and the Archimate framework (see e.g.,, Both can help us which model elements are necessary and how they belong together. Both can be mapped to each other.

I am a fan of Zachman, because it is more diverse and at the same time, in contrast to Archimate, is method-neutral and can be used with all methods, of course also with Archimate or TOGAF.

It includes "the world" in various abstractions, the "what," the "how," the "where," the "who," the "when" and the "why." A good model in one of the categories addresses precisely one abstraction, different abstractions are connected. This comprehensively describes the subject of interest without mixing the various aspects and rendering them difficult to maintain. Thus, processes will be described in one abstraction (the how), used concepts in another (the what).

3     Which abstractions should we choose?

A question that arises from this in practice is which abstractions we need, how we present this content and how it is linked? If we want to represent business processes, we are sure to talk about the abstraction "how?", We talk about the concepts used about the "what?" But what about business rules and business decisions? One argument is that these artifacts are composite objects that are used in particular to connect different abstractions. On the other hand, the question arises what we are aiming for with the respective content. The main purpose of a decision model is usually to give guidance, so we would associate such a model with the abstraction "how?".

4     Several models in an abstraction

That is, in an abstraction we find several models that are interconnected. An example are process models and decision models. It is well known that we should separate both aspects and not mix the description of the processes with the specification of the decisions. Processes require the description of decisions too; both are connected.

5     Abstraction levels

A problem of the assignment of models to abstractions is the question of considering abstraction levels. Often attempts are made to define too many levels of abstraction, contents are unclear and described too detailed. John Zachman emphasized in describing the original framework to be described in detail. Users often ask for help in determining abstraction levels. I think the magic number is THREE. This can be derived just from the number of elements (just think how many elements are created depending to the complexity of the levels of abstraction). Different theories refer to the abstraction levels purely numerical, Level 1, Level 2, Level 3, etc. I do not think much of that. It is better to name the levels by purpose. Then it's easier to decide if we need the detail level or not.

For the basic levels Business Concepts and System Logic (see I use e.g., the following abstraction levels:


Reminder: This is a Framework to be adopted. If we consider business process optimization in general, we may need all abstraction levels in "business concepts". Currently, many projects underway are to introduce the GDPR Directive. The focus is on the operator view (with the "Procedures of Operation") and the connection to "System View" in "System View" and maybe other views.

6     Tool Support

We also need support from the tools used. We need functions to refine models and model elements (we stay in the same type of model, e.g. we refine a subprocess into a process description) or link models and model elements (we change the model type to represent different views, eg we link Business process model with a decision model). Good tools support these types of linking. Qualiware or Visual Paradigm support this, for example.

Complex or complicated - Make complexity your friend

We live in a world of slogans which are just empty. Frequently prominent voices are used for such slogans. E.g., Steve Jobs is often used with his quotes about "creating user interfaces as easy as possible". Many of these quotes are of context and doesn't tell a lot.

Do you think about these examples, everybody agrees, that using a system should be as easy as possible. But in the same way, everybody agrees, that controlling a nuclear power plant with an iPod is not a good idea. The solution has to be in sync with the problem. Sometimes a complex problem has a complex solution.

The slogan sometimes heard in the Business Analysis community "Complexity is the enemy" is not comprehensible to me as our example, that it should be possible to control a nuclear power plant with an iPad. We describe Business Processes taking different views. Sometimes the Flow of Activities, the collaboration of different participants in the Business Process, conformity with legal requirements, automation of parts of the process or complete Business Process are frequent questions. We describe the different views on different abstraction level.

For me, the meaning of complex is different to the word complicated. Complexity is a precondition for the development of organizations, the stability of solutions. The human organism is complex by reason more complex (and more complicated) as the organism of an amoeba.

We speak a lot about Agility, Agile Development, Business Agility, Agile Innovation, ... These are buzzword everybody connects an own meaning. A connecting element is the request to be able to react fast to changing requirements and change in the business context. But not only fast, but with less effort as in the past, conform to legal requirements.

Complexity can be a blocking point. A more complex solution can be difficult to maintain, it is more difficult to recognize improvements and to realize them. But this means that we should avoid complicated solutions if possible and do them only when necessary, and that also complex solutions must be maintainable, adaptable and ready for improvement.

In model-driven engineering, I experience frequently the request, that a certain "thing" (system, collaboration, business process, business decision) must be described "on one page". Such models are simple and not complicated. But often such models are not easy to maintain. Possibly they miss important aspects. We speak about "Separation of Concerns" for a long time to make also complex models easy to maintain and complete. E.g., we argue that Business Rules and Business Decisions should not be mixed with Business Processes. How are these artifacts connected is an essential question we have to answer in our Business Architecture. How does the Business Strategy influence the design our Business Processes? Which Business Rules are relevant for which Business Activity? Which Systems are needed for which Business Processes?

So I change my statement to "Embrace complexity - make it your friend!".