In the most recent post in our ongoing series on agile and architecture, I argued why architecture models are valuable for agile organizations. That post concentrated on the ways in which you can use these models to foster business agility at the enterprise level. In this post I want to zoom in a bit and discuss how architecture models and ArchiMate in particular can support agile teams.
Dealing with large, complex systems is difficult in any methodology, and is perhaps the biggest challenge in adopting agile ways of working. Due to 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 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, though, such component teams are not always optimal. If you have, say, a three-layer architecture with a Web front end, a business logic layer, and a database, you may be tempted to have three corresponding teams. Many features, however, will require all three teams to collaborate, since these features often need something in the interface, some business logic, and some storage. This will lead to teams having to wait on each other, and hence lowers 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 also including e.g. experts on UX, testing, and DevOps. Such feature teams can tackle a feature end-to-end. This comes at the expense of some efficiency. Moreover, if some specialized expertise (say 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 the active structure and behavior aspects in ArchiMate 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. Below, you see the full ArchiMate framework, with one application-layer example that illustrates these aspects.
For a newly to be developed solution you typically start thinking from a feature perspective. In ArchiMate, you start with motivation concepts to capture the goals, requirements and planned outcomes for the enterprise and its stakeholders.
Next come ArchiMate’s behavior concepts, with services, functions and processes. As the standard explains, an application service is explicitly defined as exposed application behavior that is meaningful from the point of view of the environment. In short, it represents what an application does for its users. This is the key concept for modeling software features in the agile sense. You shouldn’t confuse this with the use of ‘service’ in a technical sense, e.g. as in a microservice actually being a kind of software component. Rather, ArchiMate’s service notion has a business-oriented background, of one party providing a service to another.
Application functions and processes are used next, to model the internal behavior needed to provide these services, i.e. what happens behind the scenes. Which application components (or business roles and actors in the case of a non-IT-based part of the solution) perform that behavior, and via which interfaces you can get these services, are the final steps in this design process.
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. The latter are somewhat more abstract and may require some deeper analysis of these components. Given that most solutions are ‘brownfield’ and live in a larger landscape of existing systems, in practice you will typically use a combination of behavior-to-structure and structure-to-behavior modeling.
In the next part of this post, we will look in more detail at how the collaboration of agile teams can be supported with ArchiMate models. Stay tuned!