Blog • 02.08.2022

Enterprise Architecture thinking – from modeling theory to models in practice

Enterprise Architecture thinking – from modeling theory to models in practice

In the previous blog post of the Enterprise Architecture series, I discussed the role Enterprise Architecture plays on various levels of management and how architecture-oriented thinking can be found embedded in all managerial activities. In this final post of the series, let’s move this to a bit more concrete level by discussing the special role of conceptual modeling in facilitating architecture-oriented thinking. We’ll also take a practical look at how architecture-oriented approaches and Enterprise Architecture deliverables can help managers in tackling real-life organisational concerns across managerial levels.

Enterprise Architecture is essentially about applying systems thinking in order to structure the reality – making the complex world around us just a little bit more understandable. Various Enterprise Architecture models have always been a core part of the Enterprise Architecture practice, to a point that they sometimes tend to get viewed as almost a synonym to the Enterprise Architecture itself. The variety of modeling aspects suggested by certain Enterprise Architecture frameworks makes it easy to quickly become overwhelmed. At the same time, the Enterprise Architecture practice has repeatedly been accused of being too much about “drawing pretty diagrams that don’t really matter in practice”.

In fact, when discussing modeling, we should perhaps start putting more focus on the journey instead of the destination. The process of modeling is all about making the real-world complexity more understandable by conceptualising, abstracting and ultimately making things easier to process and communicate in a certain context. In a way, modeling enforces approaching the real-world complexity in a systematic and a holistic manner, facilitating both individual-level cognitive processes and dialogue between parties involved in a modeling effort. As a result, the modeling process has hopefully led to something that is a lot more than a diagram. It should have created a mental model, enabling an increased level of shared understanding about the reality – providing a baseline for further analysis, ideation and problem-solving. Modeling should therefore be approached more as a social rather than a technical process.

The systems modeling process described above could be summarised in a simple framework, such as the following:

  1. Identify the concern that we want to address. What is it that we want to understand better?
  2. Identify and define the things that we’re dealing with. Which entities play a role in our context? Depending on the concern, these can be anything from abstract concepts (an organisation within its environment or a system within the organisation comprising people, processes, information and technology) to tangible entities (the actual individuals, procedures, data objects and devices involved in making the system work).
  3. Identify and define the relationships between the things. How do these entities interact in our context? Depending on the concern, these relationships can be anything from structural (a thing is a part of another thing or encompasses other things) to behavioral (a thing interacts with or depends on another thing somehow).
  4. Use the gathered understanding in order to address our concern. What does the system look like currently? What do we need to change in the system in order to achieve our end goals? Do we need to add some new entities to the mix, modify some existing ones or get rid of some of them completely? Do we need to make the entities work together in a different way by adding new relationships, altering existing ones or removing redundant ones? What could the system look like in the future and would it make any sense in terms of our goals?
  5. Review, refine and repeat for any further concerns.

By iterating the above process for a set of concerns of interest, architecture-oriented thinking should ultimately produce actionable insight and support decision-making through an incrementally improved understanding of the holistic system of systems that is an organisation. The role of Enterprise Architecture deliverables is then packaging this understanding so that it can be used to address various managerial concerns. These will obviously vary in both their perspectives and levels of detail depending on the managerial context.

How can Enterprise Architecture help simplifying the complexity?

There is a long list of potential use cases for Enterprise Architecture deliverables, addressing a diverse set of managerial concerns:

  • Describing the current state of things – where are we now?
  • Defining the target state of things – where do we want to be heading?
  • Identifying and evaluating alternatives – what options do we have and how are they different?
  • Selecting, prioritising and sequencing activities – what activities should we initiate and in what order?
  • Assessing impact – what will be affected if things change?
  • Managing risks – what can potentially go wrong and how that could be mitigated?
  • Ensuring compliance – what needs to be done in order to meet various requirements?
  • Maintaining operations – what is essential for business continuity?

The deliverables don’t carry much value by themselves, which is why “model-obsessive” approaches to Enterprise Architecture work tend to fail. The key of successful Enterprise Architecture work lies in applying the Enterprise Architecture understanding at the appropriate time in various managerial contexts – exploring and formulating strategies and tactics, managing development activities in project portfolios, undertaking development initiatives and designing operative solutions, among others. These are all highly collaborative processes that require the participation of a diverse group of stakeholders coming from various backgrounds and levels of understanding. The central role of Enterprise Architecture models is providing a common language that can be used to address complex organisational concerns – convey ideas, discuss issues, solve problems and ensure commitment.

How not to make Enterprise Architecture sound too simplistic?

We have discussed applying conceptual modeling to facilitate sense-making using a systems approach. This is something Enterprise Architecture thinking can help organisational management with in a very concrete way. The role of an Enterprise Architect in this context is not resolving all the issues that are raised, “architecting the perfect organisation”, but providing a structured method to enable the inquiry. By doing so, we are able to reduce the complexity of the problem area – making it literally more manageable.

An issue we might face with such model-driven Enterprise Architecture work is that, if misunderstood or misused, this can paint a picture of an unrealistically linear process that starts from the strategy, proceeds towards tactics and operations and eventually results in the perfect architectural outcome. This can misleadingly imply that we could prescribe every single aspect of an organisation by creating a bunch of diagrams – just like for a building, we could create an architectural plan of the foundations, the walls, the roof, the doors, the windows, the piping and the wiring even before starting the build. As we know, in most situations, this is hardly the case with organisations.

This might also have a theoretical backdrop. Traditional systems thinking is in many ways based on the General Systems Theory (GST), carrying an assumption that everything can ultimately be split into systems and sub-systems and that by understanding the hierarchy of these systems, we should have a complete picture of the reality. Unfortunately, this does carry a risk of oversimplifying things a bit. Already earlier, we discussed architecting in the context of a building as a rather bad metaphor for architecting in the context of an enterprise. This is because as a socio-technical system, an enterprise is in fact much more like a dynamic living organism than like a static structure. The architecting process itself changes things by generating new understanding and creating new connections. The demand for agile approaches in Enterprise Architecture work is not a coincidence, but a result of the fact that the waterfall approach has often been found to be a suboptimal way of approaching complex organisational problems.

Perhaps, more multifaceted systems theories, such as the Complex Adaptive Systems (CAS) theory and the Viable System Theory (VST) would provide better explanations of the complexity of socio-technical systems that we call enterprises. Such theories are better at recognising the fact that the interaction between the heterogeneous actors in a system plays a significant role in how the system as a whole evolves through the emergence of new relations. As opposed to the traditional systems thinking, the system becomes something more than just a sum of its parts. As models are essentially static representations of the reality at a certain point in time, this dynamic feature actually manifests better in the modeling process itself, through the evolution of thinking with every iteration and increment.

We at Gofore are at your service to help you manage complexity and tackle your organisational needs using architecture-oriented approaches. Please read more about our architecture consulting capabilities and feel free to contact us for more! Or, if you’re as passionate about architecture as we are, maybe you’ll wish to join us at Gofore.

Vladislav Ivanov

Vladislav is a Business Process Management, Process Architecture and Enterprise Architecture professional passionate about architecture-oriented thinking. He has several years of experience in method development and supporting organisational practices in these areas. He is currently researching the state of Enterprise Architecture thinking in Finnish organisations at the University of Jyväskylä.

Do you know a perfect match? Sharing is caring