Agile Architecture: Using ArchiMate® with the Scaled Agile Framework (SAFe®)
Jan 9, 2019
In the past I’ve written several blog posts on enterprise architecture in an agile world, most recently together with my colleague Fabian on our Enterprise Architecture and Agile/DevOps: Adaptive Enterprise Cornerstones tool support for Agile and DevOps, and a bit longer ago on the use of Creating Architecture Models in an Agile Way. In this blog post, I want to revisit the latter subject and add some newer insights and ideas with SAFe®.
Again, I will use the Scaled Agile Framework (SAFe) as the backdrop. It is the most popular (but by no means the only) framework for doing agile-in-the-large and we encounter it at many of our customers. It provides enterprises with the structure to coordinate the efforts of many agile teams around shared goals and common, large-scale solutions. Below, you see a simplified version of the full, four-layer incarnation of SAFe.
This is mostly relevant for very large organizations that need to coordinate the work of hundreds or thousands of developers; say a major bank, insurance company, or government agency. Smaller organizations may not need the Large Solution layer, and the smallest ones, with just a few teams, may only need the bottom two layers. One of the salient aspects of this layering is that the higher up you go, the more the focus moves to the intent, rather than the construction of the solution.
Below, you see an example of how this can be reflected in the use of ArchiMate concepts across these layers, in this case for a three-layer version of SAFe (without the Large Solution layer).
On the left, high-level strategic themes are modeled as ArchiMate goals. This expresses the business intent of the enterprise. These themes are detailed out in epics (modeled as outcomes), which in turn are realized by features (modeled as requirements), which are themselves aggregated of individual stories (also modeled as requirements). Note that all of these can also be “enablers” in SAFe terms, i.e., they are not necessarily of direct use to end-users, but may provide support for future business functionality, ensure regulatory compliance, improve infrastructure, enhance maintainability, et cetera.
Epics, features and stories are prioritized by means of backlogs at their respective levels. These, in turn, are organized in iterations, which we model with ArchiMate’s “plateau” concept. At the lowest level, we have product increments (or “sprints” in Scrum terms) delivered by individual agile teams. Several increments together constitute a release, delivered by SAFe’s Agile Release Train, a coordinated team-of-teams. At the portfolio level, these releases form a product roadmap.
In ArchiMate, plateaus are used to aggregate architecture elements that are valid in a specific timeframe. On the right, we see the constituents of these different plateaus, expressed in elements from ArchiMate’s Core. At the lowest level, these are the most concrete.
First I have used the application function concept. This describes (part of) the behavior of a component: what does (or should) this thing do? Similarly, you can model processes and functions belonging to ArchiMate’s business or technology layer here. This is also linked to the stories on the left, since this behavior needs to realize that story.
Such functions and processes need to be executed by concrete elements from ArchiMate’s so-called “active structure” elements. In this case, I have used application components, i.e., software building blocks being created or used. There are, of course, various other concepts you could use here, say to model the technology infrastructure, organizational resources, and other concrete elements of the solution.
Note that this level is owned by the agile teams; they, and not some upper-level architect, are responsible for the detailed design of the product being developed, and they might (or might not) use more detailed specifications in standards like UML or BPMN, as fits their needs. (Linking ArchiMate models to such more detailed models is quite easy but beyond the scope of this blog post).
One level up I have used the application service concept. Services abstract from the internal structure and behavior and only describe what something does for its environment. ArchiMate’s service concept (across the three B/A/T layers) is therefore a great match with the notion of ‘feature’ in SAFe. Each service of course needs to fit its environment, which can be expressed in various other ArchiMate concepts not shown here.
This level is where solution architects play a key role, employing concepts like SAFe’s Architectural Runway. This is developed in a just-in-time manner and provides teams with intentional architecture that provides the guardrails to ensure that the results from different agile teams fit well together, comply with non-functional requirements, regulatory demands and other constraints.
ArchiMate concepts are a great way to express this intentional architecture. That’s because ArchiMate is not developed for detailed solution design. Its concepts are aimed at expressing the essential structural and behavioral aspects of solutions, and the motivation behind these. Moreover, ArchiMate spans across business and IT, and thus provides agile teams with context and clarity beyond just software development concerns. For example, in which business processes is this going to be used? Who are the prospective users and other stakeholders? What is the customer journey we envisage? How does it relate to other products in our portfolio? How does it contribute to key business goals? For any organization (but especially in an agile context), everyone should understand the purpose of their efforts.
This then brings us to the upper part, where you see the capability concept. A capability is something an organization is (or wants to be) able to do, and here it expresses that the solutions developed provide the enterprise with certain new or improved capabilities. These capabilities, in turn, realize the epics that were defined before. Furthermore, they contribute to the course of action that the enterprise takes to execute on its strategic themes and fulfill its goals.
To give a concrete example, take our fictitious but realistic toy company BiZZbank. One of its strategic themes 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, such as customer relationship management, customer analytics and a great mobile app. Below is a simplified model of this, also using ArchiMate’s stakeholder and value concepts to provide a bit more context to the course of action in the center.
From this high-level contextual picture, we could drill down into, for example, the specific services that this mobile app needs to provide, how it fits the customer journey, what its functionality and software architecture is, its integration with the back-end systems of the bank, et cetera. Much more of BiZZbank is shown in our On-Demand Demo.
But my main message here is that providing this kind of higher-level context and intent is essential for agile development. In traditional waterfall environments, you might have had business analysts, information analysts and other roles with the specific task to translate strategic intent into concrete requirements. In agile development, however, much of this responsibility rests upon the shoulders of agile teams and product owners. Without a clear understanding of the context, how can you expect them to take the right design decisions?
This notion of intentional architecture is a great match to our vision of the Business Resilience, where enterprise-wide visibility of the information needed to delegate decision making is key. If you’d like to know more about our view on agile architecture, don’t hesitate to contact us!
