Is multi-dynamic architecture a binary trap?

During the past months, I have had many discussions with fellow architects about the topic of multi-dynamic architecture. Multi-dynamic architecture recognizes that within one organization more than one architecture regime may be required. Simply because the dynamics within an organization are too diverse to successfully apply one and the same approach to architecture governance, development, application and content to all parts of the organization. Instead, the idea is to identify sub-systems within the organization, describe these in terms of the dimensions variability, development approach, governance, reach, data and reliability, categorize them according to the similarity in these dimensions and define an architecture regime for each of these clusters. For some organizations you may end up with only one architecture regime, for some there may be two, while for others there may be three or even four.

Key in multi-dynamic architecture is the idea that the number of architecture regimes is not fixed beforehand. This is important to realize, as it is my experience that once we have accepted the idea that there may be more than one architecture regime, it is very easy to come to the conclusion that there are two. Two is still manageable and even in a one-architecture-regime situation we often include two options in our architecture principles (for instance allowing two DBMSes or distinguishing between differentiating and non-differentiating processes). This binary thinking is also fuelled by concepts such as Gartner’s bimodal IT.

By focusing on two architecture regimes, however, I fear we fall into the binary trap. The binary trap works as follows:

• If we have only one architecture regime within an organization, we will occasionally encounter situations where the architectural prescriptions just do not fit. Because we are dealing with exceptional circumstances, for instance. If that is the case, we usually make an exception and allow a project to deviate from the architecture. In a mature organization, such deviations are registered, put on the backlog of an architecture board and managed. This is an accepted practice.
• Now, imagine that we have two architecture regimes. If one of these regimes does not fit a situation, it automatically follows the other regime must be applied. There is no other sensible conclusion. You belong to the one or to the other. There is no in-between and no room for exceptions. And if you do not fit in either of the two, you are in big trouble. You will be squeezed into one of them, no matter what. If you are lucky, you fall within the favorable regime, but if you are unlucky you are placed under the unfavorable regime. For with two regimes, there always is a favorable and an unfavorable one. This is the binary trap.
• As soon as you allow more than two regimes, things change again. You are not forced to choose between fast or slow, or modern or old-fashioned. Instead, there is a third way that you may fit in. But that is not all. The option of a third way, also psychologically opens up the perspective of maybe a fourth way, if necessary. Naturally, we do not want things to become more complicated than needed with a proliferation of architecture regimes. We cannot just go on introducing new architecture regimes just as we please. That would undermine the very purpose of having an enterprise architecture. But I do not fear that this will happen. I expect most organizations will do fine with three architecture regimes, and probably often even with only two. However, the possibility of adding another regime, prevents organizations from being pushed into an antithesis. It offers differentiation where needed while still allowing architecture to fulfill its purpose of providing the direction that leads an organization into the future.

I firmly believe in multi-dynamic architecture as the world is not uniform. As the world is not bipolar either, however, let’s not fall into the binary trap when applying it, but let the right number of architecture regimes emerge from the differentiation in subsystem characteristics an organization truly possesses.