The position of Enterprise Architecture
Change has become a fact of life for most organizations. Even more, the speed of change is also increasing at a near exponential pace. We’ve learned to accept that the days of slowly moving from one stable plateau to the next are long gone. In order to survive and be successful, it is crucial for any organization to embrace this as a way of life. If you don’t, then you’ll fall behind with huge risks for survival.
Enterprise Architecture has emerged as one of the key disciplines to help face the challenge of dealing with this continuous state of flux, and keeping sufficient levels of control to thrive. With roots in business/IT alignment, IT strategy, operating models, and attempting to show a holistic, coherent view of the “point on the horizon” that the organization is working towards, we now see a changed role and benefit of EA in practice:
Architecture is still used to steer the organization by aligning perspectives: business and IT, long and short term, strategy and execution, function and construction, and so on. We also see that Architecture is used as a governance mechanism, enabling management to make hard decisions about topics such as:
We have several programs that will hit the same area (process, system, department) of the organization, how will we deal with this?
We have limited budgets, how can we make sure we achieve as many of our goals as possible?
How do we make sure that projects and programs are aligned, moving in the same direction?
How do we stay on track with our chosen business model, operating model, strategy?
How do we make sure we continue to align with developments in our immediate environment: the supply chain, partners, customers?
How do we deal with disruptive technologies (big data, cloud computing, social, mobile) and ever changing legislation?
The list goes on and on. Increasingly, organizations recognize that Enterprise Architecture is both a “philosophy” (in order to consider these challenges holistically), a structured process, and a visualization that can be mounted on a wall. This blog series is about the latter aspect: it deals with ArchiMate as a standard for crafting, analyzing, and using architecture models as an important “weapon” to help face business challenges.
The role of models
Before we dive in, it is important to note that the way we consider these models has changed over time as well. The notion of agile architecture is rapidly getting traction among practitioners. We’ve learned that it is pointless to craft detailed future-state architecture diagrams, while some direction is essential. This paradox is in line with the mindset that is captured by the following diagram:
In other words: we learned that architecture models are a means to an end, and that “just enough architecture” is what we should strive for.
Models in different situations
This is further illustrated by the fact that not all situations in which ArchiMate models are used are alike. To illustrate this, we will use the Cynefin framework illustrated below:
While the Cynefin framework is much more elaborate, and ideally should not be used as a ‘mere’ classification framework, it does make a very interesting point: different situations require a different approach, a different strategy for success. This means that the role of architecture (and therefore: models) is different.
The right side of the framework (simple and complicated domains) is said to be stable: the problem space can be analyzed, we understand cause and effect and links between all the elements in the domain under consideration, different solution alternatives and their effects can be weighed, in order to figure out what a good/ best practice is in the given situation.
Here, models can be used to facilitate communication, for formal analysis, for weighing one option against another. Models give an accurate description of most of the variables.
Typical examples are application portfolio rationalization, developing a new layout for a production plant, and so on
Note that while this can still be difficult and by no means straightforward, this is not yet complex in the Cynefin sense of the word. In the complex domain, the role of models is completely different. Here, there is no apparent cause and effect. The problem space can by its very nature not be analyzed in order to come up with a good/best practice. The response mechanism changes to intervention, monitoring the effect, and either dampening or strengthening this effect depending on what actually happens.
Here, models help to attempt to capture the ‘knowns’ from the problem space. The goal is to get a shared understanding, and a common ground to formulate hypotheses and potential strategies to get a grip on what must be done. Typical examples are more in the social and strategic space: repositioning the firm, launching a new product, restructuring teams and processes.
To complete the picture: in the chaotic domain there is no use for (formal) models: we’re in a crisis, there’s a panic, and action is required now. This will hopefully bring us back to a stable / complex domain and then we’ll worry about what we can do to get back on track.
The discussion above shows a wide spectrum of use for enterprise models. We strongly believe that ArchiMate is the language to be used in all of these situations. It is a language, and it is up to us as practitioners to use it with caution when helping our organization to thrive in the face of change. ArchiMate is a practical and pragmatic language by design: everyone can participate in the development of the language through The Open Group. Even more, the language is designed with the 80/20 rule in mind: ArchiMate makes common enterprise modeling challenges easier, and complex (modeling) challenges possible. To put it differently, it allows modelers to capture the most important aspects of the enterprise, without creating a huge language that no one fully understands.
Conclusion & outlook
In the next posting we will dive into the world of modeling. More specifically, we will look at the definition of ‘architecture’ to get a clearer understanding of what it means to craft an architecture model. If you have any questions or suggestions: feel free to drop us a note! Stay tuned!