By The Open Group
This blog, the third in a series with Marc Lankhorst, Managing Consultant for BiZZdesign, looks at how architecture in general and the ArchiMate language in particular can add a lot of value to agile approaches.
How do you consider the ArchiMate modeling language can support and leverage agile practices in the organization and support the delivery of an Agile Enterprise Architecture (EA) Capability?
For the individual Agile teams, it is not that important. ArchiMate models may provide them with some context, but they do not create these themselves. However, for coherence between teams and at higher levels, EA is important in at least two ways: 1) to ensure that what you create is in line with the enterprise strategy and goals, and 2) to coordinate across different teams. For example, if one team decides to postpone some feature, what will the impact be on the others and on the overall goals and outcomes? Having the big picture and overall priorities helps to ensure the different teams and sprints are aligned.
Having a detailed plan far ahead into the future is not a good idea but just in time, just enough architecting is key, having in mind the minimum viable product philosophy also for architecture products. Without such coordination, you easily end up with ‘agile silos’, and the final result is not agile at the end. Good architecture helps you make it easier to change things later on.
One of the key considerations and principles in Agile is for the different teams to deliver fast but keeping the proper coordination and alignment. One of the key challenges in this approach is that Architecture models can become out-of-date if changes are delivered too fast. How do you consider the ArchiMate standard could be used to address this issue?
This balance is not easy. Important is to avoid creating too much architecture up front; better to have less and then add more when (or rather just before) it is needed, for example for coordination purposes. Architecture products can quickly go out-of-date when they are too detailed. Moreover, the effort to keep them up to date may not be worth it, especially at the level of individual agile teams.
Architects need to be focused on creating the future, since that is where they add most value, but of course it is also important to know what you have today. Increasingly I see that keeping track of the current state architecture is partially automated, for example by CMDBs monitoring which applications are present on your network.
At higher levels, architecture descriptions are something to be maintained and used to support and coordinate teams. It is also important to keep in mind the agile concept of shared responsibility: architecture is not just something the architects create and own; it is collectively owned and evolved by the agile teams.
Most Agile techniques and tools are related with team organization in sprints, backlogs, user stories, and implies a lot of dynamic interaction between teams, so dynamic is going beyond architecture descriptions. How can ArchiMate as a modeling notation support this approach?
One of the main principles of EA as a discipline is to continuously iterate based on a set of capability architectures, connected with segments and with a strategic architecture, as stated in the TOGAF® standard, a standard of The Open Group. In agile approaches like the Scaled Agile Framework (SAFe), this notion of iterative, capability-focused architecture development is also important at the upper levels of that framework. Many of the concepts of SAFe can easily be mapped to the ArchiMate language, as I explained in my blog post on that: https://bizzdesign.com/blog/using-archimate-in-an-agile-context/.
One of the ways to increase the agility of your enterprise is to make these capabilities more independent with well-defined interfaces between them. That makes it easier to adapt things locally, thus speeding up change.
Another important characteristic of agile approaches is that they have a strong bottom-up character, feeding ideas, improvements, and innovations from agile teams back into the architecture and possibly even your strategy. Implementation governance should therefore not just be a top-down activity but also a reality check on the architecture, harvesting feedback from teams to adjust and improve that architecture.
In conclusion, I think that architecture in general and the ArchiMate language in particular can add a lot of value to agile approaches, and we already see this in practice at many of our own customers.
The first blog in this series can be found here.
The second blog in this series can be found here.
Find out more about Marc on LinkedIn here.
The ArchiMate® Specification is a standard of The Open Group.
www.opengroup.org @opengroup.org