In the past, I have written extensively on the combination of enterprise architecture and agile development, most recently about the notion of intentional architecture. It is clear that for any organization or system of some size, a solid architecture practice is needed next to agile ways of working.
On the one hand, for true business agility you need to take care of much more than ‘working software’ as the sole measure of progress (as advocated by the original Agile Manifesto). This starts from a solid understanding of the business at hand, the challenges that need to be answered, various constraints ranging from resources, cost and risk to regulatory compliance and competitive pressures, and much more.
Moreover, you need to ensure that the results developed (working software but also organizational structure, capabilities, business processes, possibly down to physical infrastructure) are also flexible and not ‘instant legacy’ that will be hard to change in the future. These aspects of understanding the broader context and impact are where enterprise and solution architecture and models thereof add real value.
As mentioned in my previous blog, I see a decline in the use of formalized (UML) models of software under the influence of agile development. Creating and maintaining such models is a substantial effort and often duplicates what is already visible in the software code, just represented in a different way. This is no surprise, since the main aim of such models is to provide a complete specification of the design that can be translated into working code. This was also the goal of the Object Management Group’s Model-Driven Architecture, which envisaged a sequence of transformations from high-level to detailed models and eventually generating software code.
In practice, however, this turned out to be rather cumbersome. What is the value of a detailed UML class diagram if the code itself contains exactly the same details? Of course, there are software tools that can (more or less) keep these in sync, but the issue remains that these models often do not add much to the knowledge you can gain from looking at the code itself. Moreover, specifying the behavior of software in a model turns out to be at least as much work as simply writing the algorithm in code. There are some specialized use cases that analyze models, for example for formal verification, but most developers that I meet (including my software development colleagues at BiZZdesign) rarely create detailed UML models anymore. Sketches on whiteboards are the main way to start and discuss a design, and then it quickly moves into code. So detailed models of software are often not very useful in agile.
A different direction is taken by low-code platforms. These facilitate rapid application development by a combination of simple models and visual, drag-and-drop development on top of a smart platform, often without any coding involved. Again, no detailed models of software design are created here but models are key, for example using BPMN to specify the application’s behavior. The focus is still on the application itself though, and not the broader architecture around it.
To understand this broader context mentioned above, architecture models are extremely useful, and I would argue even more so in a fast-moving agile organization. I see three key issues standing in the way of true business agility:
These three issues are where architecture models have much to contribute to business agility. Whereas software models capture all the details needed to create code, architecture models focus on communicating the essence of context, direction and intention of the enterprise, and on the coherence between its various bits and pieces. Understanding these connections is crucial in fostering business agility. Using such models, you can for example:
And the list could go on and on. All of this would be impossible to do with just textual documents or sketches on whiteboards (let alone by just looking at software code).
Such models are explicitly not some big, up-front design created by a small team of experts in an ivory tower. Rather, they should be built and owned collectively by everyone involved in change in the enterprise. Different roles contribute their parts and can see how these are connected to the bits of others. This shared understanding then greatly facilitates the agility and speed any adaptive enterprise needs. And as I mentioned in my previous blog referred to above, ArchiMate, with its lean and mean nature focusing on the bare essentials, is ideally suited for use in an agile environment.