1.1 Objective

The objective of this document is to provide guidance to architects, developers, and others involved in Agile initiatives about the value and use of architecture models to support their work.

1.2 Overview

The scope of this document is the use of architecture models in an Agile context. Specifically, it addresses the use of the ArchiMate modeling language for Enterprise Architecture and describes how it may be used to support enterprise agility, decision-making, and collaboration within and across Agile teams.

The document is not intended to provide general guidance on (Enterprise) Architecture in an Agile context. Other standards and guides address this topic including the O-AA Standard [1] and White Papers such as [2] and [3].

Experience from Agile practitioners suggests that an Agile approach benefits from using models. In this chapter we will describe the reasons for adopting a modeling approach and also the specific benefits of the ArchiMate modeling language [4] in this context.

2.1 Agile and Architecture in General

Agile methodologies are based on the notion of embracing change over following detailed plans; to quote the Agile Manifesto [5]: working software over comprehensive documentation. The future is uncertain. Customer needs change and so do external conditions; any plans you draw up will need to be altered anyway. This means that the role of architecture in an Agile context is different from the “waterfall” approach, where you first draw up plans and then execute them. In an Agile context the plans themselves, and hence the architecture, are constantly being adapted to match changing circumstances and requirements. This does not mean that architecture is no longer relevant in Agile. On the contrary, architecture captures the shared vision needed by Agile teams.

In Agile methodologies, the architecture is supposed to be created or incremented “when needed”. One of the principles behind the Agile Manifesto [5] states that the best architecture arises from Agile teams. This is a naturally “emerging” architecture. However, this is focused on software development and software architecture, not Enterprise Architecture.

Software or system architecture, which is closest to a daily changing reality, needs to be created by the experts directly in touch with that reality; i.e., the members of Agile teams realizing that system. 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 Unified Modeling Language™ (UML^®) models. While this is not the target user group of ArchiMate models, using a subset of the ArchiMate language and notation may come in handy as it helps ensure that people understand each other’s diagrams, and enables a continuum in the architecture description, whether drawn or modeled.

Solution architectures for larger systems with lots of connections and interactions do require a more thorough architecture focus. Keeping track of these dependencies can no longer be done with sketches on whiteboards or pieces of string on your Agile planning board. It is just too easy to lose track of crucial dependencies, let alone of the changes in them.

It is important to stress the value of models over just pictures. Models can be analyzed, transformed, and visualized in different ways, so they can be the basis for much more than just communicating the essence of an architecture. Moreover, models are much easier to maintain and keep consistent than pictures. Imagine you express an architecture of a complex system in Microsoft^® PowerPoint or Visio and some fundamental aspects are changed. You will then need to change that manually, and check and fix all inconsistencies arising from such a change. With models and appropriate modeling tools, this is far easier.

Moreover, for true business agility you need to take care of much more than “working software” as the sole measure of progress (as advocated by the Agile Manifesto). This starts from a solid understanding of the business at hand, the challenges that need to be answered, the various constraints ranging from resources, cost, and risk to regulatory compliance, competitive pressures, and much more.

In addition, you need to ensure that the results developed (the working software, but also the organizational structure, capabilities, business processes, and possibly down to physical infrastructure) are also flexible and not an “instant legacy” that will be hard to change in the future. These aspects of understanding the broader context and impact are where Enterprise Architecture and solution architecture add real value and can help increase the agility of an enterprise. Key in avoiding this “instant legacy” problem is deferring decisions for as long as possible, since deciding too early without sufficient information increases the risk of that decision being wrong. Moreover, you should explore alternatives and not rush into a specific solution too soon.

To understand this broader context and to evaluate alternative solutions to your business challenge, architecture models are extremely useful, and even more so in a fast-moving Agile organization. We see three key issues standing in the way of true business agility:

1. Ensuring that everyone involved has a shared understanding of the direction of the enterprise and can work together to achieve their goals. The faster you want to change, the more important this becomes. In a slow-moving organization, there may be time for the “stragglers” to catch up and for the rest of the organization to compensate, but when time is of the essence you cannot afford misunderstandings about goals and direction.
2. Understanding the (side-)effects of changes to avoid nasty surprises. All too often, we have seen mishaps when some system was changed or replaced because a connection to another system was not known or documented sufficiently. In a fast-changing and highly automated world, these kinds of failures and roll-backs, and the delays they cause, are even more undesirable.
3. Balancing short and long-term changes, and making considered decisions about them. This is where a narrow focus on Agile software development instead of true business agility is most harmful. Yes, software can be changed more easily than physical infrastructure, but a major redesign necessitated by a lack of understanding of context and constraints is still costly and time-consuming. In a worst-case scenario, if you do not consider this broader context sufficiently, you may leave yourself with little room to maneuver and without enough time to escape before some competitor beats you in the marketplace.

The ArchiMate language can help in modeling this architecture. A graphical visualization is a powerful way to convey ideas and concepts, and using an ArchiMate model is more efficient than producing a long textual explanation. Furthermore, since the ArchiMate language is intentionally relatively simple and not too detailed, the effort in creating and maintaining models is reasonable and will not slow down an Agile team. It also offers a mechanism for defining stakeholder-oriented viewpoints that capture specific parts of the architecture to address particular concerns of these stakeholders, something not offered by domain-oriented languages like UML or Business Process Modeling Notation™ (BPMN™). During the incremental phases of Agile, it can be quicker and easier to make a modification to an ArchiMate model than to a lengthy descriptive document. Moreover, ensuring the consistency of models is a lot easier than with text.

Note that such models are explicitly not intended as big, up-front designs created by a small team of experts. Rather, they should be built and owned collectively by everyone involved in change in the enterprise. Different roles contribute their parts and can see how these are connected to the parts of others. This shared understanding then greatly facilitates the agility and speed that any adaptive enterprise needs.

2.2 Using Models to Capture Architecture Intent

As mentioned, Agile methodologies are based on the notion of embracing change over following detailed plans, because the future is uncertain. This uncertainty increases the further into the future you look. This implies that the longer-term direction of the enterprise should be given in general terms rather than in detailed plans, since those will be overtaken 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 does not change on a daily basis, and translating that into action is where intentional architecture comes into play. A key role of Enterprise Architects is to convey that intent.

In addition to emerging architecture, Agile methodology requires some intentional architecture – architecture that is created beforehand. Intentional architecture may consist of both enablers (e.g., a data storage system should be in place before data storage features can be implemented by application components) and constraints (e.g., data storage must comply with the European General Data Protection Regulations (GDPR)). In addition, and perhaps more importantly, intentional architecture should describe the intention: the vision, purpose, goals, and targets of development. Some elements of intentional architecture can be realized by running code and infrastructure; by creating an environment where enablers exist and constraints are followed by default. Other elements need to be designed and communicated in a way that they are easy to understand by all participants.

The ArchiMate language provides ways of communicating both intentional and emerging architecture. Although a modeling notation requires some initial learning, shared concepts and structures soon become essential parts of communication between people from different backgrounds.

In large multi-team projects, it is useful to start with some intentional (but limited) architecture. Here, again, an ArchiMate modeling strategy is the perfect way to have a global view across teams on the initial concepts and work/responsibility split between the teams.

For large projects, an ArchiMate modeling strategy and Business Layer architecture might clarify and guide multiple Agile teams. Architects need to express the desired effects of the architecture; such as the value you want to deliver, business capabilities you need to develop, fundamental principles you should apply, and constraints that must be fulfilled. The motivation and strategy concepts are very useful in expressing this 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. Perhaps the capability concept is the most important intentional notion that the ArchiMate language offers, and certainly one of the most popular. It expresses what an enterprise is able to do, or wants to be able to do, rather than how it does it. Section 3.3 addresses how you can model this business intent in detail using ArchiMate concepts.

2.3 Using Models for Decision-Making

An important use-case for architecture models in an Agile context is evaluating alternatives and priorities. Modeling the business intent as mentioned in Section 2.2, and linking that to key architectural choices, helps decision-makers to analyze the impact of those choices and obtain a high-level impression about the budgets that need to be allocated to the various Agile value streams.

Based on an analysis of the Enterprise Architecture, you can see how different epics and features are related to business processes, capabilities, business goals, and associated stakeholders. Tracing through your architecture models, you can find out which business goals or stakeholders an epic or feature supports and decide whether that is more important than other features. Objective information like this may help product owners put a stop to “decibel-driven” prioritization; for instance, where the users that complain the loudest get their wishes granted.

2.4 Using Models to Improve Enterprise Agility

In creating Agile organizations, it is not enough to focus on Agile change processes and teams. The solutions themselves that these teams develop should also be easy to change. Microservice “spaghetti” is an example of the “instant legacy” problem you want to avoid. Using models can also help to uncover and avoid unwanted dependencies that will later on harm your agility. A key consideration in architecture, still valid in an Agile world, is the separation of concerns. This is often expressed in terms of coupling and cohesion: ensure that unrelated concerns are separated in loosely-coupled components so you end up with a set of relatively independent, internally cohesive components.

Architecture models are a great instrument to show and analyze this. If you see that two components communicate in 25 ways, perhaps these are so dependent on each other that they should be treated as one. Keeping in mind Conway’s Law,[1] giving each of these components to a different component team will likely require a lot of coordination between these teams about all this communication between the components.

There are various metrics you can apply to your architecture to calculate coupling, cohesion, and other aspects of complexity. These are useful to help you partition systems (and whole enterprises) into parts that can evolve independently, thereby increasing your enterprise agility. An interesting perspective (including a method to help you partition your architecture) is given by Roger Sessions [6]. He advocates establishing autonomous business capabilities that own their own IT systems and communicate through services, rather than having them share the same IT landscape. Business-driven IT change can then be localized, and dependencies reduced. It may introduce some inefficiencies – for example, because data needs to be stored in and synchronized between different systems – but it greatly improves the speed of change. Since in today’s winner-takes-all economy, speed often trumps cost, such an approach could offer important advantages.

On a smaller scale, this thinking also applies to microservices: they should address specific and limited business requirements in order to minimize dependencies and impact of change. Analyzing your architecture models could uncover, for instance, services that have a scope that is too broad, because they are used by a great many different systems in different contexts.

Similarly, by analyzing models you can find single points of failure, communication bottlenecks, resource constraints, and other issues impeding agility and resilience. Many of these issues are not easily visible at code level (let alone in presentations or text documents), and simple, informal pictures (e.g., sketches on whiteboards) don’t lend themselves to any kind of formal analysis; you can follow the lines with your finger but that is about it. Moreover, managing these kinds of dependencies and constraints over time requires a solid foundation. This is where architecture models add great value.

2.5 Using Models to Record Technical and Architectural Debt

Agile methodology includes the concept of technical debt. Sometimes, for example, in the interest of time-to-market, a short-term solution has to be implemented in the knowledge that this will need to be brought in line with the architecture with a better/cleaner/more elegant technical solution later on. This causes a “debt” that needs to be paid off later.

Similarly, and at a higher level of aggregation, there is the concept of architectural debt: short-term choices that have to be fixed later in order to avoid growing complexity that will hamper future changes and therefore reduce enterprise agility. Architecture models are a good way to record this technical and architectural debt and the eventual longer-term solution that needs to be put in place. The model can be re-visited during an Agile iteration and, once updated, modifications needed to the product can be detailed as new stories, features, and enablers.

2.6 ArchiMate Modeling – Value-Added at Each Level

Following the Agile philosophy, artifacts should be created only if they add value. An ArchiMate model can help and add value at each level of an Agile initiative. This includes, for instance:

• Documenting the business intent in the form of intentional architecture, to convey the overarching vision to the different teams and support decision-making on priorities and alternatives
• Clarifying the requirement chains (from business stakeholder to implementation)
• Ensuring that the different teams have a coherent view of the desired state (integration challenges)
• Helping to improve enterprise agility by managing dependencies and coordinating between and across Agile teams, to avoid undesirable complexity
• Helping to track the ever-changing ideal architecture and the corresponding technical debt
• Helping to conceive and create test scenarios above the level of unit testing; developers need a global view of the product they create to design tests across several modules and systems, often across different Agile teams (integration testing)
• Helping to ensure the non-functional requirements (security, high availability, speed, compatibility, maintainability, flexibility, etc.) are respected by the end-product
• During fault investigation, helping to identify the most probable root cause of the fault/issue

These are just some of the benefits of using architecture models expressed in the ArchiMate language in an Agile context. In the next chapters, we will explore in more detail how models can help individual Agile teams (Chapter 3) and support the collaboration between teams (Chapter 4).

In every team working long enough on a subject there will be a point where one of the team members will draw some sketches on the whiteboard to enable a shared understanding by the team. They will use blocks and arrows, possibly with some form of color-coding. This marks the appearance of the emerging architecture. Instead of simply letting this process happen randomly, it can be anticipated, controlled, and fueled. Once a modeling standard is adopted, it will be easier for the entire team to convey ideas via the model or make/request modifications to it. Business requirements can also be modeled, greatly reducing the risk of misinterpretation or miscommunication between the business(es) and the execution team.

The ArchiMate approach is a good fit for the needs of an Agile team or organization; it allows models to be created very quickly, it is flexible enough to adapt to any context, and the level of detail is fully up to the architect/modeler. In the first part of this chapter, you will find a description of a Minimum Viable Architecture (MVA) model and how to determine the layers and level of detail.

ArchiMate models can cover each stage, all the way from business early thinking, to user stories and daily operation (fault root cause analysis, security reviews, disaster recovery preparation and execution, audit, etc.). ArchiMate models can work hand-in-hand with Agile; its concepts can be easily cross-linked, enabling valuable synergies. In this chapter we explore this in detail.

3.1 Mapping of Terms from Agile to the ArchiMate Language

Figure 1 is an example of how the ArchiMate concepts can be used at different levels of detail; in this case for the Scaled Agile Framework^® (SAFe^®) [8], a common example of a layered Agile methodology. This is just to inspire you to define your own mapping to whatever Agile method you use in your own organization. Moreover, there are other possible mappings and you always need to adapt and tailor the use of ArchiMate models to the needs of your own organization.

The example shows some of the ArchiMate core and strategy concepts on the right. As you can see, there is a progression from more abstract to more concrete from top to bottom. At the top, a course of action provides the general direction of the enterprise. This requires certain capabilities. These capabilities are realized by, among others, various services. In Figure 1 we use only application services but this could also include Business and Technology Layer concepts.

Services abstract from the inner workings of the processes, applications, or technology elements. These inner workings are modeled as functions and are closer to implementation. A feature roughly corresponds to a service; i.e., something that the underlying implementation will need to do for its environment. A story, in turn, corresponds to one specific way of using that service, requiring specific functions “behind” that service which are performed by, in this case, the application components implementing these functions. Agile teams building these components can now see what behavior they need to perform, which services they offer, and how these services relate to the bigger picture of the enterprise. A similar progression from abstract to concrete would hold for business services, implemented by business processes that are in turn performed by business roles and actors (e.g., organization units), and for technology elements.

Figure 1: ArchiMate Concepts Used Across SAFe Layers

3.2 Which ArchiMate Layers to Focus On?

There are two approaches which can bring added value and help develop consensus. The choice will depend on the immediate concerns of the team creating the models. The first approach is to focus on the motivation and strategy elements, thus ensuring the business requirements and reasons are clearly articulated. This “intentional architecture” is discussed in more detail in Section 3.3. A complementary approach is to focus in the lower layers, mainly the Application and Technology Layers. This will show benefits for teams trying to understand and evolve a complex product. This is discussed in Section 3.4.

Of course, ideally a model covering both intent and result will bring the highest value, but you can start from one end or the other, depending on the needs of your stakeholders and where you think the use of models will add most value.

3.3 Modeling the Intent: Themes, Epics, Features, and Stories as ArchiMate Motivation Elements

On the left of Figure 1, 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 from 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, etc. Architecture work is typically also expressed in terms of enablers.

An example high-level architecture intent is shown in Figure 2. This is from the ArchiSurance Case Study [9] and provides insight into the reasoning behind the development of new capabilities by this fictitious but realistic insurance company. The two outcomes mentioned, “Best-in-Class Online Customer Experience” and “Detailed Insights in Customer Behavior”, are the key top-level epics the company wants to pursue.

Figure 2: ArchiSurance Architecture Intent

Drilling down from the capabilities at the bottom of Figure 2, we can see that these new capabilities are positioned within existing higher-level capabilities “Customer Management” and “Policy and Claim Management”, respectively. They also have several sub-capabilities, which in turn need specific resources. This is shown in Figure 3.

Figure 3: Capabilities and Resources

Figure 4 gives a high-level concept of the solution to be developed in support of this architecture vision, again expressed in ArchiMate motivation and strategy concepts, specifically how the resources needed to support the capabilities as shown in Figure 3 work together to realize these epics (on the left) and more detailed features (on the right), expressed as ArchiMate requirement elements.

Figure 4: Solution Concept

Not shown here is a further level of detail where features are refined into stories, which would again be expressed as ArchiMate requirement elements.

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 the ArchiMate “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 an Agile Release Train, or Scrum of Scrums; i.e., a coordinated team of teams. At the portfolio level these releases form a product roadmap, which delivers the requisite capabilities to the enterprise.

3.4 Modeling What You Build: ArchiMate Core Elements

In the ArchiMate language, plateaus are used to aggregate architecture elements that are valid in a specific timeframe. On the right in Figure 1 we see the constituents of these different plateaus, expressed in elements from the ArchiMate core. At the lowest level, these are the most concrete. Note that, for the example, we have just used a few of these concepts, but all ArchiMate core concepts can play a role here.

In the middle-right, we see the application service concept. In general, ArchiMate service concepts are a good way of expressing what the solution needs to offer its users, while abstracting from implementation detail.

Next, we have used the application function concept. This describes (part of) the behavior of a component: what should this thing do to be able to offer the required services? Similarly, you can model processes and functions from the ArchiMate Business or Technology Layers 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 the ArchiMate so-called “active structure” elements. In this case, we have used application components; i.e., software building blocks being created or used. There are, of course, various other concepts you could use here; for example, to model the technology infrastructure, organizational resources, and other concrete elements of the solution.

An example of such a high-level solution architecture, spanning the Business, Application, and Technology Layers, is shown in Figure 5 and Figure 6.. In Figure 5 we see the linkage back to the resources from Figure 4. Now we see how these are to be realized, expressed in ArchiMate core elements.

Figure 5: Resource Realization by Core Elements

A further refinement of some of these elements is shown in Figure 6, which provides a high-level solution architecture. This also includes business processes and technology infrastructure that were not shown in the previous figures but can be described analogously. Most importantly, in the center we see the services provided by application components that need to fulfil specific requirements.

A next step in refining this Agile model would be to define the concrete user stories that each of these application services needs to implement in order to support the two business processes mentioned, and the functionality (i.e., the application functions) that then needs to be implemented by these application components. There may also be other requirements that are not captured in this view; for example, on the technical infrastructure, security, compliance, etc.

Figure 6: High-Level Solution Architecture

More detailed solution architecture models could zoom in on, for instance, the implementation of the ArchiSurance Back Office Suite. We will see some examples of this in Chapter 4. Such detailed models are typically 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. What they do not own are the motivation elements; i.e., what is needed by the users, the intent, as described in Section 3.3.

With models like this, they can immediately see how their work supports these requirements, which helps in prioritization and planning. For instance, the two sub-requirements on the left (below “Shared Back Office Application for All Products”) are both needed for this shared back office application to be a viable solution. Implementing only one of these or postponing one to some future iteration will have a direct impact on the success of the implementation.

3.5 Summary

To summarize, Agile architects can use ArchiMate models at different levels of abstraction:

• To convey the why, the vision, and the intent with ArchiMate motivation and strategy concepts
• To specify what the solution needs to do with behavior concepts (first services, then processes, and functions)
• To model how the solution is constructed with structure concepts (e.g., business actors, application components, nodes, devices)

Note that these models are not intended to capture implementation details. Those are left to the Agile teams and whichever tools and methods they choose to use.

A key challenge in any larger organization that applies an Agile methodology is scaling up from small two-pizza teams to hundreds of developers and other disciplines collaborating on large and often highly complex systems (or systems-of-systems). In this chapter, we want to address the use of models to support the communication, coordination, and cooperation between and across Agile teams, and the use of models to support and promote enterprise-level agility. Having a shared set of views on your enterprise, its context, capabilities, processes, systems, etc. gives Agile organizations a great instrument with which to coordinate their work.

4.1 Team Structure versus Architecture Structure

Dealing with large, complex systems requirement is difficult in any methodology, and is perhaps the biggest challenge in adopting Agile ways of working. By their very nature, these large systems are not very Agile because the large number of dependencies they exhibit slows down change.

Some Agile methodologists would say you simply have to break down those systems into chunks that are each manageable by a single team. Microservices are an example of such an approach but, as anyone who has seen them in action knows, the result is often that the complexity that used to be hidden within the single large system now shows up in the connections and communication patterns between these microservices.

As Conway’s Law [7] states, organizations design systems that mirror their communication structures. This is quite obvious since if your system architecture cuts across these communication structures, the extra effort of communicating between these teams often leads them to redesign the system structure so that each team has their own area of responsibility in the system architecture (e.g., a microservice), or to restructure teams to align with the architecture components.

From an agility point of view, such component teams are not always optimal though. If you have, for example, a three-layer architecture with a web front end, business logic layer, and database, you may be tempted to have three corresponding teams. Many features, however, then require all three teams to collaborate, since features often need something in the interface, some business logic, and some storage. This will lead to teams having to wait for each other, lowering your speed of change and agility.

Agile methods therefore tend to favor cross-component, cross-disciplinary feature teams consisting of experts on each of the parts of the architecture that are potentially touched by a feature, and often also including, for example, experts on User Experience (UX), testing, and DevOps. Such feature teams can tackle a feature end-to-end, at the expense of some efficiency. Moreover, if some specialized expertise (on security, database technology, etc.) is scarce and needed by multiple teams, you run into limitations.

Since both approaches have their pros and cons, most organizations tend to have a combination of feature and component teams based on the specifics of their solutions. Deciding what works best strongly depends on your architecture.

With ArchiMate models, you can serve both approaches. In fact, the subdivision between (active) structure and behavior in ArchiMate models is quite similar to that between components and features. In the end, you need both, but you can choose to start with one or the other in organizing the work.

For a newly to-be-developed solution we recommend starting your models from a feature perspective, expressed in ArchiMate behavior concepts and using, for example, services, functions, and processes. Which application components (or business roles and actors in case of a non-IT-based part of the solution) perform that behavior, and via which interfaces you can get these services, are next steps. On the contrary, when creating models of an existing solution, it is often easier to start with the components and their interfaces, since those are often more “visible” and concrete than services and functions, which are somewhat more abstract and may require some deeper analysis of these components.

4.2 Communication Between Agile Teams

However you structure your teams and architecture, in all cases there is a need for communication that increases with organization (and system) size. On the one hand, this is “vertical”, to convey the enterprise vision so that teams align in the same direction, and to provide feedback and contribute innovative ideas up the food chain from development to management. A clear line of sight helps ensure that goals are clear to everyone involved and priorities are aligned with these goals. Although organizations may use all kinds of tools to keep track of their development initiatives, architecture modeling is the most efficient way to illustrate the connections between strategy, capabilities, and development portfolio items.

And vice versa, feedback on the feasibility and desirability of those goals comes from the “boots on the ground” in Agile teams, who are in direct contact with users, know about the possibilities and limitations of technology, and provide improvements, innovations, and refinements to adapt to local circumstances. Architecture models provide such an unambiguous connection between motivation and realization, and allow you to trace dependencies and effects of changes in priorities, planning, etc.

Equally important is the lateral communication between teams that work on parts of the solution that need to communicate, provide an integral user experience, share resources, and in general depend on each other. A common technique to draw these dependencies is using red woolen strings on a Kanban or Scrum board, but that will not scale up across larger teams and teams of teams (although spanning those threads across your work floor from board to board would be interesting!). Moreover, you cannot easily use this in any remote setting. Again, architecture models are of help here, clearly showing how different components are interconnected, how business processes rely on IT systems, which users are working with which applications, where the data is stored, etc.

Most Agile methodologies include well-defined ceremonies. Some of them, like Program Increment (PI) planning, are a good moment to share and build common understanding. Architecture models can be used to prepare such ceremonies and keep track of key information and decisions. Of course, such architecture views should be designed for and with key team members such as the product owner to ensure that the visualizations produced will be adopted and used inside the teams. An example is shown in Figure 7, providing teams with high-level scoping information for a PI, focused on a specific feature, an application service of a risk assessment application that is to be updated to support new and updated business functions.

Figure 7: Example Input for PI Planning

Next to supporting the communication between different groups to achieve a common understanding, you can also analyze these models at a deeper level. Dependency analysis is one example; for instance, how does a change in the sprint planning of one team (for example, pushing a feature out a few sprints) impact other teams, the Agile Release Train, and possibly up to important business goals and stakeholders? Cost or resource analysis might be another; for example, are we putting our efforts where the highest strategic or customer value is to be captured?

4.3 Using Models for Vertical Communication

The vertical communication in an Agile organization is considered on the one hand, aligning the work being done with the overall vision of the enterprise, and on the other with providing a feedback loop from practice back into that vision.

This vision is important to define priorities and planning. What are the areas in which the organization wants to invest? What are the main epics to evolve?

As discussed in Section 3.3, the architectural intent can be expressed in the ArchiMate motivation concepts. In addition, strategy concepts such as capability and resource can be used to express a high-level solution structure in terms of what the enterprise wants to be able to do, and the means it needs to do it.

This way, you can define a high-level solution architecture that gives a general direction to the Agile teams without constraining them too much in the specifics of their implementation. Drilling down from capabilities and resources gets us to the level of the ArchiMate core elements, such as business process and application component. These can be used to provide more concrete direction and models at this level are typically the purview of roles like domain and system architects. Using these models, they can provide a more concrete and detailed shared architectural vision to the teams, and ensure coherence within an Agile Release Train.

These models can also be used by teams to validate their own designs and, if they deviate, to discuss why this is. Perhaps the system architecture is not feasible; some parts will take more time than expected so the sprint and release planning need to be revised, or there is a new technology available that provides important benefits. This feedback, in turn, may lead to refinements or changes to the system architecture and/or backlog planning, and could potentially even influence higher-level goals and priorities.

4.4 Using Models for Lateral Communication

To support the lateral communication between teams, architecture models can be helpful in a number of ways.

First of all, an important consideration is the division of work between teams. Some of this is about clustering features into sensible groups that can be tackled coherently. Having a good overview of the various parts of the system on which the teams are working is an immense help in structuring the work.

For both component and feature teams, knowing who is working on which parts of a solution is essential to avoid conflicts, gaps, overlaps, and rework. Typically, each team is fully responsible for the inner workings of what they build; i.e., its software architecture and design. They can use whatever they choose to design that, ranging from sketches on whiteboards to some simple ArchiMate models, and different teams may work differently. How these relate to each other is where things should be standardized in some way, so that all teams have the same understanding. This is where, for example, a set of ArchiMate views of the communication between application components in your landscape can be a central design artifact. An example of this is shown in Figure 8.

Figure 8: Target Application Landscape with Flow Relationships

In such an overview, you could also use colors to show which teams are responsible for which parts of the landscape, and to identify gaps or overlaps that need to be addressed.

Zooming in brings us at the level where individual teams are responsible. They may want to express, for instance, more detail about the expected internal behavior of the components for which they are responsible. In Figure 9 we see an example of that, with the data processing performed by the “Data Warehousing Solution” in support of the epic of “Detailed Insights in Customer Behavior” and the “Data Driven Insurance Capability” mentioned in Figure 2.

Figure 9: Data Warehousing Functionality

Zooming in on a specific application component or technology element, showing the services it provides, and how it communicates with its environment can help teams to define connections to such a component. This can potentially be used to define interface agreements between providing and receiving teams, so that both sides know exactly how their work is going to connect.

In Figure 10, we see an example that illustrates how the “Data Acquisition” technology function from Figure 9 is implemented, the “Communication” services this function provides to the “Internet of Things (IoT) Device” that provides this data, and the “Representational State Transfer (REST) Application Programming Interface (API)” that is used to offer these services. These devices collect data on customer behavior that is used to fine-tune the insurance premiums of ArchiSurance. An illustrative example is a black box in your car that monitors your driving behavior, so that if you drive smoothly and do not speed, you may get a discount on your auto insurance.

Figure 10: Data Acquisition API

Figure 10 starts from a component perspective of the world, so this would perhaps be most relevant if you have component teams. In the case of feature teams, focusing first on the application services that provide these features to users may make more sense. Drilling down from the application services leads you to the application functions necessary for providing them, and then you can identify which application components are involved in performing these functions.

4.5 Communicating Architecture Models

Since in Agile development 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, the ArchiMate modeling notation 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 the ArchiMate active structure, behavior, and passive structure concepts.

Some may object that ArchiMate 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 this 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 describes a viewpoint mechanism to support the creation of such viewpoints. However, given the breadth of stakeholders out there, it would not 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 pictures to formally precise specifications. This is where the expertise of the architect comes in, creating the appealing visualizations of underlying models that best serve their audience.

Important in any kind of modeling endeavor, and certainly also in an Agile context, is the evolution of your models. Some may be created as one-shot views intended to be used for a small audience and then thrown away, but many models have a longer life. In this chapter, we want to address this lifecycle.

5.1 Creating Models in an Agile Way

First and foremost, the modeling process itself is something that should be done using the same Agile principles that you use for developing software. That means that the creation of models is itself an iterative process that starts small and gradually extends models with content needed for specific purposes. This process should move in lock-step with the evolution of what these models describe.

Some models are used as input for the design of some piece of software (or business process, product, etc.) and therefore need to be “one step ahead”. As we know from Agile ways of working, you want to postpone decision-making to the latest possible moment, when you have the best available information. That also holds true for models in an Agile context. They are developed with a “just in time” mindset; for example, to provide context for developers in the next few sprints, for portfolio managers to decide on priorities of the next epics, etc. This also means that the further ahead a model aims to look, the less concrete it will be. In ArchiMate terms, this translates into:

• Models that only provide the longer-term, high-level intent in motivation and strategy elements (see also Section 3.2)
• Medium-term and medium-level models with more concrete details; for example, to express main features as services, and to define concepts like an Architectural Runway
• Short-term, detailed models that are used; for example, to describe application components and their services and interfaces for developers who need to connect to them

All these models should be created by and with those who are directly involved, so the intent and ideas are captured at the source.

A second category of models are those that are created to comprehend the pre-existing, current situation. Most development is “brownfield” and you need to understand this context. Models are helpful to get a handle on the complexity of such a current situation. For example, complicated communication patterns between microservices are very difficult to understand by just looking at the code. A model can clarify this.

Now, having to create those models of the current situation from scratch might be an inordinate effort. Ideally, those models would have been created and maintained by previous teams, but that is often not the case. The second-best option is to automate some of the model creation with more and more of the tools that exist to discover, for example, software components communicating on your network and that information can be used to build up a bottom-up view of the current state. The automated creation of, for example, ArchiMate models of the IT infrastructure based on information from those discovery tools, often linked to modern Configuration Management Data Base (CMDB) software, is how state-of-the-art teams work nowadays. At a business level, process mining tools can be used to discover the business processes of an organization. And we can expect more and more data analysis and techniques based on Artificial Intelligence (AI) that help gain these kinds of insights and build up your models.

However, what you cannot reconstruct from just looking at the world out there is the intent behind what you see. What were the key design decisions and trade-offs? What alternatives were rejected and why? Who were the main stakeholders and what were their drivers? This is the main reason that you do need to document what you design and not just try to reverse-engineer after the fact. This is again an argument for modeling intentional architecture in (ArchiMate) models.

That leads us to the third type of models, those that are intended to document what has been created after the fact so that others understand it. Those models are typically “one step behind” in the development and realization process. Agile methods recommend that you document late (but not too late!) so you capture what has actually been realized and you can incorporate relevant learning experiences; for example, feedback from customers, peer reviews, or retrospectives. Moreover, the solution as realized may deviate from the solution as designed, and these differences are important to be understood and discussed.

5.2 Leverage Existing Methods and Practices

Agile (and especially Agile at scale) often comes with methods (such as domain-driven design or event storming) or even emerging documentation practices (like documentation or model as code approaches such as Simon Brown’s C4 Model[2]). These methods and practices should be leveraged and used as starting points for architecture viewpoints based on the ArchiMate Specification. Doing so will help to establish the ArchiMate notation as a standard for everyone and will also make it easier to share information between team members and architects.

For example, a typical business-level data model (Figure 11) can serve as an input for a workshop whose goal is to clarify the product domain model (Figure 12), which can then be added to the ArchiMate model.

Figure 11: Business-Level Data Model

Figure 12: Product Domain Model

In the same vein, event storming sessions come with their own conventions, mostly based on the color of the physical sticky notes used. Such conventions can be used in the model to keep track of the information gathered during the workshop, as shown in Figure 13.

Figure 13: Event Storming Model

The overall advantage of creating architecture viewpoints based on existing methods and practices is that people will be used to them and can reuse them in their own documents. This is usually a very good sign when some of your architecture views appear in someone else’s presentation or in the wiki maintained by a team, as it will help show the value of architecture work and will provide you with more feedback. To help this but also to avoid potential misunderstandings, you should make sure that some basic information is always added in your views, such as a title, a legend, and the date of the last update to the view.

5.3 Recommended Level of Detail

One of the most commonly asked questions in modeling is: “What is the right level of detail for my models?” However, this is something you cannot simply define up-front. There is no single, “right” level of detail. This strongly depends on the context and objectives of your modeling effort.

Of course, it is not a good idea to document everything in excruciating detail, but models do need to be precise enough for their intended purpose; for example, to help team members understand a solution going forward, DevOps experts to deploy it and resolve issues (also think of integration testing, for instance), and other teams to reuse components and services. Perhaps most importantly, the models need to be available to anyone who needs to make changes in the future without having access to the original designers and builders. This is again where the intent of the architecture is especially important.

Having models that are too detailed often leads to problems in maintaining them, simply because you cannot spare the effort needed to keep everything up-to-date. That in turn leads to models that age quickly, and sometimes results in people turning away from modeling altogether because the models they need to work with are always outdated anyway. This is clearly not the way to go.

So, you should never model more than you are able to maintain (unless it is a one-shot, throwaway model). But how do you then decide on the level of detail?

There are two complementary approaches to take. First of all, arriving at a good, useful level of detail is an iterative process in itself. You can use the Agile process itself to improve this. In a retrospective review you can discuss this and thus finetune your approach. Did you have the right information at the right time? Was the effort needed to create or update your models feasible and worth it? Like any other activity in an Agile approach, modeling should be subject to this continuous improvement of your way of working.

Secondly, you can use a risk-based approach to decide where you need more detail. Most Agile methods are not very specific on this, but some of their predecessors like the Unified Process [10] are explicitly risk-focused and aim to address the most critical risks early on in the process. In line with this, you should create more detailed models for those areas of an architecture or design where the risks are greatest, and include less detail where you can make decisions with some spontaneity and the consequences of an error are limited. For example, deciding on an infrastructural technology is often high-risk because of the cost involved and the need to avoid the time and effort it will take to reverse a decision that turns out to be the wrong choice after all. Other common high-risk areas are health and safety, security, and compliance; for example, Personally Identifiable Information (PII) risk, financial transaction handling, manufacturing process control, etc.

This also implies that your models will not have a single, uniform level of detail. Moreover, even aiming for such a standardized level of detail may lead you to spend effort where it is not really needed and, conversely, to lack the time for those areas where it really counts. So any modeling approach that tries to tell modelers up-front what the “right” level of detail is will most likely result in models that are nearly all at a “wrong” level, either too detailed or not detailed enough.

To make this more concrete, these are some guidelines to help you decide when to add an element to your architecture model:

• When this element is largely different from the other components (in functionality, type, etc.)
• When this element will be connected to numerous separate entities
• When this element is crucial for some desired characteristics (like non-functional requirements such as high availability, performance, etc.)
• When this element is crucial in the overall orchestration (controlling component)
• When this element is associated with high-risk or high-cost operations of the enterprise
• When this element itself or its implementation is costly (or risky)
• When this element needs to comply with specific regulatory guidelines; e.g., on the use of personal data

As mentioned before, this means that your Agile architecture models will have different levels of detail in different areas, depending on the importance and risk associated with each area. This also lets you spend your modeling efforts where they count most, rather than adding details just because someone has decided for you what the “right” level of detail should be.

5.4 Minimum Viable Architecture Model

In the O-AA Standard [1], the concept of an MVA is mentioned. This is the “least/smallest” architecture that provides value. Likewise, an MVA Model (MVAM) can be envisaged: the smallest model that adds relevant value. The guidelines in Section 5.2 offer a useful starting point to create such an MVAM. As stated, you cannot define up-front how large or small this needs to be; rather its development will be an iterative process, alongside the iterative Agile process itself. Some additional guidelines that may help you in such an effort are:

• Value will be found at all the Agile levels as described in Chapter 2 – explore these to see what could be helpful in your own context
• Start from a high-level view (principles, technologies, standards, and patterns) and add detail as and when required, in line with the discussion in Section 5.2
• Experiment with scope breadth and depth to properly partition the architecture and the model; do not overthink it, just try and see what works
• Avoid highly complex and high-effort designs: “fail fast”, there should be a balance between the day-to-day work of the Agile team and the effort of maintaining and evolving this architecture

As we have demonstrated in this document, architecture models expressed in the ArchiMate language can play various useful and important roles in an Agile context. We see three main types of use:

• Expressing the business intent, to help prioritize epics and features, and to convey the architecture vision to Agile teams
• Fostering enterprise agility, complexity reduction, and managing architectural and technical debt
• Facilitating the communication within, between, and across Agile teams to support collaboration and alignment

We did not discuss in detail how ArchiMate models could be used outside and beyond an IT-oriented scope, but its concepts also support the wider business world and modeling physical technology. Using Agile ways of creating and evolving non-IT results fits equally well with the use of such models.

The work set out in this document is part of a broader set of initiatives within The Open Group ArchiMate and Architecture Forums, focused on the relationships between Agile and architecture. The O-AA Standard [1] is another result of these activities, as are various white papers and guides on the topic. For more information, please visit The Open Group Library.

If you are interested in using ArchiMate models in an Agile context and are looking for tool support, please check the ArchiMate tool certification register: https://certification.opengroup.org/register/archimate-tool.

---

Glossary

AI

Artificial Intelligence

API

Application Programming Interface

BPMN

Business Process Model and Notation

CMDB

Configuration Management Data Base

CRM

Customer Relationship Management

GDPR

General Data Protection Regulations

IoT

Internet of Things

MVA

Minimum Viable Architecture

MVAM

Minimum Viable Architecture Model

PaaS

Platform as a Service

PI

Program Increment

PII

Personally Identifiable Information

REST

Representational State Transfer

UML

Unified Modeling Language

UX

User Experience

[1] “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” [7]

[2] https://c4model.com.