Complex vs. Complicated - Part II
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.
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 (https://www.zachman.com/about-the-zachman-framework) and the Archimate framework (see e.g., https://en.wikipedia.org/wiki/ArchiMate), 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).
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?".
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.
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 www.zachman.com) 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.
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.