In the first part of this blog post, we discussed in general how the structure of the ArchiMate modeling language matches the structure of both component and feature teams. In this second part, we want to go a bit deeper into this topic.
Whichever way agile teams are structured, you always necessarily separate some concerns and combine some others. Knowing and understanding these dependencies is key in any multi-team setup. You want to avoid dividing things that are closely coupled, i.e. have a high degree of dependency, over different teams. That would result in an inordinate communication overhead between these teams. And knowing these dependencies is of course also the first step to reducing them.
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 bits relate to each other is where things should be standardized in some way, so that all teams have the same understanding.
A common technique to capture these dependencies is to use strings on a physical Kanban or Scrum board, but that won’t scale up well across larger numbers of teams and teams-of-teams (spanning these threads across your workspace from board to board would be interesting…), let alone when you have teams at different locations. Moreover, there are many different kinds of dependencies, and an analysis of those by just looking at different colors of string isn’t so easy.
An overview of your architecture in terms of the key structure and behavior elements (i.e. components and features), and of their dependencies, helps in defining team structure and supporting team communication. 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. Moreover, managing and sharing these with an appropriate tool is a lot more convenient than spanning strings across your workspace. An example of such an architecture landscape is shown below, anonymized and somewhat simplified from a true customer example in the insurance domain.
When the image cycles, you see the impact (highlighted) of a new feature having to do with online insurance claim submission. This affects the website, the INSUR system and its subsystems, and a number of information flows. The image then shows with colors which DevOps teams are responsible for which parts of this landscape, so you know who will have to collaborate on this specific feature.
Now the example above takes a component view of the world and has DevOps teams for the main systems, so such views would perhaps be most relevant if you have component teams. In case of feature teams, focusing first on the application services that provide these features to users may make more sense. Drilling down from these application services leads you to the application functions necessary for providing them, and next you can identify which application components are involved in performing these functions.
Using an architecture model can assist agile teams in several other ways too, such as:
This is something I will address in a future post in this blog series. More to follow!