In previous blog posts, we talked about the use of architecture models in the context of agile development, and the ‘right’ level of detail for such models. But how do you go about creating models in an agile context?
Agile models from an agile modeling process
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.
Defining the future
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 last 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, or to help portfolio managers decide on priorities for 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;
- 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 these.
All of these models should be created by and with those who are directly involved, so the intent and ideas are captured at the source.
Understanding the present
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 that model creation. More and more tools exist to discover e.g. software components communicating on your network and that information can be used to build up a bottom-up view of the current state. Automated creation of, for example, ArchiMate models of the IT infrastructure based on information from those discovery tools, often linked to modern 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 AI-based techniques 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 that after the fact. This is again an argument for modeling intentional architecture in (ArchiMate) models.
Modeling what was created
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 to document late (but not too late!) so you capture what has actually been realized and you can incorporate relevant learning experiences, say 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 understand and discuss.
The lifecycle of models
All of these three kinds of models are useful, but they should be created and treated in different ways. The longer a model needs to live, the more thorough its development and maintenance should be. As I argued in a previous blog post, don’t model more than you can reasonably maintain. Outdated information is often more dangerous than no information at all.
And there is a fourth kind of models not discussed here, of temporary models created during the creative design process. Those models often have a short lifespan and mainly serve to inspire, come up with new ideas, explain and let your peers validate your ideas. I would be very interested to know how you use models in this creative process. Please get in touch if you have interesting examples to share!