The Value of Architecture Models for Agile Organizations

The Value of Architecture Models for Agile Organizations

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.

Design models in software development

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.

Architecture models for business agility

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:

1. Ensuring that the people involved have a shared understanding of the direction of the enterprise and work together to achieve their goals. The faster you want to change, the more important this becomes. In a slow-moving organization, there may be time for the ‘stragglers’ to catch up and for the rest of the organization to compensate, but when time is of the essence you cannot afford misunderstandings about goals and direction.
2. Understanding the (side-)effects of changes to avoid nasty surprises. All too often, I have seen mishaps when some system was changed or replaced because a connection to another system wasn’t known or documented sufficiently. In a fast-changing and highly automated world, you don’t want these kinds of failures and roll-backs, as well as all the delays they cause.
3. Balancing short- and long-term changes and making considered decisions about these. This is where a narrow focus on agile software development instead of true business agility is most harmful. Yes, software can be changed more easily than physical infrastructure, but a major redesign necessitated by a lack of understanding of context and constraints is still costly and time-consuming. Worst case, if you don’t consider this broader context sufficiently, you may paint yourself into a corner without enough time to escape before some competitor beats you in the marketplace.

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:

• analyze the contribution of change initiatives to the enterprise’s strategic goals and prioritize investments accordingly
• understand possible business benefits of technology innovation
• optimize your customers’ experience by having a 360-degree view of their customer journey and what affects it
• define an architectural backbone or ‘runway’ that speeds up future developments and ensures long-term agility
• ensure that agile teams are aware of the dependencies between their work
• analyze where Personally Identifiable Information (PII) is used to ensure regulatory compliance
• address the business continuity impact of IT risks and define mitigating measures

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.

Of course, you’ll need a solid platform for this shared space. If you want to know how our HoriZZon product supports this, you can watch our webinar or request a demo.