Architecture Models in an Agile Context

ArchiMate Concepts Used Across SAFe Layers 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 ArchiMate Concepts Used Across SAFe Layers 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.

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 Modeling the Intent: Themes, Epics, Features, and Stories as ArchiMate Motivation Elements. 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 Modeling What You Build: ArchiMate Core Elements.

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.

On the left of ArchiMate Concepts Used Across SAFe Layers, 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 ArchiSurance Architecture Intent. 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.

Drilling down from the capabilities at the bottom of ArchiSurance Architecture Intent, 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 Capabilities and Resources.

Solution Concept 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 Capabilities and Resources work together to realize these epics (on the left) and more detailed features (on the right), expressed as ArchiMate requirement elements.

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.

In the ArchiMate language, plateaus are used to aggregate architecture elements that are valid in a specific timeframe. On the right in ArchiMate Concepts Used Across SAFe Layers 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 Resource Realization by Core Elements and High-Level Solution Architecture. In Resource Realization by Core Elements we see the linkage back to the resources from Solution Concept. Now we see how these are to be realized, expressed in ArchiMate core elements.

A further refinement of some of these elements is shown in High-Level Solution Architecture, 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.

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 Supporting Collaborating Agile Teams. 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 Modeling the Intent: Themes, Epics, Features, and Stories as ArchiMate Motivation Elements.

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.

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