Agile ArchiMate®: Intentional Architecture
Aug 14, 2019
In my previous blog post on Agile Architecture: Using ArchiMate® with the Scaled Agile Framework (SAFe®), I briefly mentioned the need for modeling the intent of the enterprise. In an agile context, this notion of intent and intentional architecture is quite important. In this blog, I want to explore that further.
Agile methodologies are based on the notion of embracing change over following detailed plans. The future is uncertain, customer needs change and external conditions as well, so any plans you draw up will need to be altered anyway. This uncertainty increases the further into the future you look. This implies that the longer-term direction of the enterprise should be given in fairly general terms rather than in detailed plans, since those will be obviated by the world changing around you.
Architecture models, especially those with a longer-term outlook, should therefore express intent rather than detailed design. This intent is usually quite stable: the strategy of an organization doesn’t change on a daily basis, and translating that into action is where intentional architecture comes into play. The key role of architects is to convey that intent. This has important implications for the architecture discipline, with a different impact depending on the scope of the architect.
First of all, software or system architecture, which is closest to a daily changing reality, needs to be performed by the experts that are directly in touch with that reality, i.e., the members of agile teams realizing that system. And we see that in practice. Classical software architect roles are increasingly being performed by experienced agile team members rather than by separate experts. This kind of architecture is often expressed in sketches on whiteboards or perhaps simple UML models (although UML seems to be in decline under the influence of agile development). This is not the target user group of ArchiMate models, although occasionally it may come in handy.
The next level up in scope, solution architecture, is still quite close to concrete, day-to-day change, but its scope spans across multiple teams. At this level, architecture becomes more concerned with coordination between parts of the solution, with concepts like SAFe’s Architectural Runway. This provides a backbone for the agile teams to align their contributions with, in order to make all pieces fit together, in alignment with the intent of the enterprise. Often, such a solution is defined to serve a specific capability of the enterprise.
At this scope, ArchiMate models are a very useful instrument. Expressing the main elements (e.g. key business processes, services, components, and data elements) of an Architectural Runway is often easier in ArchiMate than in more detailed modeling languages such as UML or BPMN. Those languages stimulate (or sometimes force) you to put in details that will likely change anyway. Moreover, these details can obscure the essence of what the architecture is about. ArchiMate’s so-called Core – its Business, Application and Technology layers – offers useful concepts that provide the right level of detail for expressing this kind of architecture, where coordination is key.
Additionally, at this solution level we already can and want to express the intent of the architecture as much as the construction of solutions. For example, the notion of ‘service’, which is central to ArchiMate’s design, is intentional in nature: it expresses what some part of a solution should do for its environment rather than how this is achieved (N.B.: The term ‘service’ is used in all kinds of ways. ArchiMate’s service notion is rooted in business terminology and shouldn’t be confused with e.g. a piece of code as in a microservice).
The Capability concept is another intentional notion. It expresses what an enterprise is able to do, or wants to be able to do, rather than how it does that. The figure below, from our fictitious but realistic toy company BiZZbank, gives an example. We see a capability Customer Behavioral Insights and its supporting business processes, systems, and data. A view like this could be used to coordinate between the teams supporting individual systems to ensure that, for instance, they use customer data in the right way, resolve data synchronization problems, plan changes, and in general ensure their systems work together to optimally serve the business processes and capabilities of the enterprise. This is of course a very high-level picture, but we could zoom in on individual processes or applications and see more detail.
Expanding our scope beyond individual solutions and capabilities, we get to domain and enterprise architectures. This is where intentional architecture is the most important. We need to express the desired effects of the architecture, such as the value we want to deliver, business capabilities we want to develop, fundamental principles we want to apply, and constraints we must fulfill. Furthermore, this is where budgets are allocated and initiatives are prioritized based on the strategic direction of the enterprise and expected return on investments.
ArchiMate Motivation and Strategy concepts are very useful in expressing this level of intentionality. Concepts such as Stakeholder, Driver, Value, Goal, Principle, Capability, and Course of Action let you express what the enterprise wants to achieve, where it wants to go, and which steps it intends to take to get there. This is where you express the linkage between the strategy, business model, and the underlying core architecture of the enterprise.
The figure below, reused from my previous blog post, gives a simple example of such an intentional view for BiZZbank, our hypothetical company. One of its strategic goals is to significantly increase its digital banking revenues by targeting the Millennials segment. To that end, it aims to develop the #1 digital banking user experience. This, in turn, requires various capabilities and resources. One of these capabilities is Customer Analytics, and if we were to drill down into this, we would find the previously mentioned Customer Behavioral Insights as a sub-capability.
Now this view may look a bit technical. But this is not the only way to depict ArchiMate models; you can use different depictions of the same concepts, such as the SWOT analysis below, which is based on ArchiMate assessment concepts. This is the analysis that preceded the formulation of the strategy depicted in the previous picture. Based on the assessments mentioned here, management has decided to focus on this Millennials segment and develop a great digital banking experience for them.
In previous blog posts and otherwise I have intentionally told the story of BiZZbank backwards, starting from more detailed architectures towards the high-level intent, since most architects are more familiar with the concepts of the ArchiMate core. In practice, of course, intent should come first. In the words of the Cheshire cat in Alice in Wonderland: “If you don’t know where you are going, any road will get you there.”
Since in agile development clear communication is more important than detailed documentation, the use of models should be focused on expressing the ideas behind an architecture rather than the details of a design. This is a great fit with the principles behind the ArchiMate language. From the start, ArchiMate was designed as a lean-and-mean language with minimal overhead, aimed at expressing the essence rather than the details of an enterprise. Its focus on communication can even be seen in the construction of the language, which intentionally mimics the structure of human language with its subjects, verbs, and objects, reflected in ArchiMate’s active structure, behavior, and passive structure concepts.
Now some may object that ArchiMate’s symbols look too technical for non-IT audiences. The language was designed to resemble other modeling languages with boxes, arrows and icons, to make it easy to learn for anyone with some modeling experience, and that makes it look a bit ‘techy’. But the definition of the language also separates the content from the visualization of a model, and stresses the importance of stakeholder-oriented viewpoints. The standard even describes a viewpoints mechanism to support the creation of such viewpoints. However, given the breadth of stakeholders out there, it wouldn’t be feasible to standardize these viewpoints themselves. Different audiences need different depictions of architecture content, from simple lists to detailed diagrams, and from simple, colorful views like the SWOT analysis shown above to formally precise specifications.
As an example, when an agile team is involved with the design of the interaction between the organization and its customers, visualizations like Customer Journey Maps come in handy. They can capture where a journey needs to be improved, again focusing more on intent than on construction. Below is an example of such a map, again for BiZZbank, showing its current customer journey for mobile payments and clearly there is much to be improved if they want to achieve their strategic goals. This was part of the assessment show in the SWOT analysis, where it says “Lack of a good digital experience”.
Everything you see here is expressed in ArchiMate concepts. For example, the blue circles that denote customer touch points are modeled with ArchiMate business services, and the channels you see in the form of swim lanes are modeled as business interfaces. And behind these, there will of course be all kinds of processes and systems.
Customer-centricity is key nowadays and has a deep impact on all aspects of your enterprise. To ensure everyone is focused on that target, visualizations like this can be extremely helpful in conveying architectural intent; in this case to provide an optimal digital banking experience that improves the customer journey shown here.
Moreover, since such views are not merely pictures but are part of an integrated model, you can perform all kinds of cross-cutting analyses, see the impact of changes, prioritize investments and assess the effects on your customers and strategy. This makes them infinitely more useful than the typical stand-alone pictures made by people who think it has to be done in PowerPoint or Visio because otherwise their audience will not understand it. This is a grave misunderstanding and underestimates what a modern modeling platform can do.
If you would like to know more about using ArchiMate in an agile context, please be in touch. And if you want to see more examples of how Horizzon and Enterprise Studio support architecture visualizations like the ones above, join our free webinar!
