Recently, more and more companies and organizations have been working to adapt their collaboration models to the requirements of the current environment (VUCA world). The increasingly frequent and significant changes in the demand and supply profiles of international markets make these adjustments necessary. In contrast to this are decisions that are long-lasting and difficult to change. An example of this is the target architecture of a software system. IT architecture is basically divided into two parts: intentional architecture, i.e., the target architecture specified before development, and emergent design, i.e., the architectural decisions made during development. So if you want to forge plans in iterations in an agile way and, if necessary, also adapt them, how does that fit in with the concept of "intentional architecture"?
Fortunately, the most well-known agile scaling frameworks have an approach for reconciling these conflicting views on product development. As a rule, architectural tasks and responsibilities are divided among several people in different teams. This makes it possible, for example, to have one architecture agent per team or per topic, so that architectural tasks in a specific context can be assigned to the person who is best suited to tackle the challenge at hand. Many challenges in the field of intentional architecture are covered by the application of a Definition of Done (DoD). The largest parts of intentional architecture are mapped in the DoD. In this way, the specifications of intentional architecture are applied in every story.
Architecture and agility – where could the contradiction lie?
Agile architecture is the way in which enterprise architects, system architects, and/or software architects apply architectural practice in agile software development. A number of commentators have identified a tension between traditional software architecture and agile methods along the axis of adaptation (postponing architectural decisions until the last possible moment) and anticipation (planning ahead).
The tension lies between spending too little time planning an architecture in advance, which increases the risk of architectural adaptation, and spending too much time, which has a negative impact on the delivery of value to the customer.
Agile architecture is particularly affected by the following six factors:
- Instability of requirements
- Technical debt
- Premature value creation
- Team culture
- Customer agility
- Experience
There are measures in place to ensure that these do not become a problem:
- Responding to change
- Risk management
- Emergent architecture
- Big design in advance
- Use of frameworks and architecture templates.
In classic software development, it was common practice to define and document the necessary adjustments to the architecture in the "design" step, i.e., during the design of the software, after the technical requirements had been specified. In agile or iterative work, the "design" step is performed for each work element within the iteration or sprint. Of course, proportionally smaller changes to the architecture can be defined here. However, experience has shown that it is difficult to obtain major approvals from architecture boards during this time, so in order to document architectural adjustments, it is important to reduce delays and handovers at these points. More on this later under "Best Practices for Agility from Frameworks." One might also assume that it is sufficient to no longer pursue intentional architecture. The Agile Manifesto states, "The best architectures, requirements, and designs emerge from self-organizing teams."
This principle cannot be applied to all systems, which is why additional principles have been developed for agile architecture:
- Evolutionary collaboration instead of blueprints
Instead of developing an architecture design with a long service life, as is the case in classic software development, one can try to view architecture as a product within the development process. According to this approach, architecture design is an incrementally expandable artifact that can be used later in the development process.
- Communication instead of perfection
In line with the Agile Manifesto and the Pareto principle, it makes sense not to perfect architectural documentation and requirements according to the Pareto principle, but to focus on communication between team members and those responsible for architecture.
- Active stakeholder participation
Part of architectural design involves deriving non-functional requirements from the ideas of the stakeholder(s). To improve the architecture, it is therefore helpful to closely involve stakeholders.
- Enterprise architects are active participants in development teams
In line with Scrum, teams are designed to have all the necessary skills required to design, develop, test, and deliver a piece of a product to customers. Since the "design" step also includes architectural design, it is therefore necessary to integrate architects into the team.
- Empowerment instead of inspection
Delays due to handovers occur in particular when expertise is not built up within a development team. Therefore, in order to decentralize decision-making, it is helpful to empower team members instead of merely inspecting and evaluating their proposals.
- Abstraction of models
Similar to the application of "adaptation instead of perfection," it is also helpful to develop the architectural design in less detail the more complicated the component under consideration becomes.
- Capturing details with working code
True to the agile principle of "working software over comprehensive documentation," architectural specifications should also be written in code or pseudocode according to this principle.
- Lean guidelines without bureaucratic procedures
Focusing on added value for users or customers requires that architectural work not get bogged down in producing documentation and bureaucratic overhead. In this sense, it is important to reduce delays and handovers. Here, too, decentralized decisions are used.
- Do you have a dedicated team of experienced enterprise architects?
Last but not least, it is important to remember that work is most effective when you build committed and experienced teams.
- Architectural requirements for products in a VUCA world are also VUCA.
Agile working models were developed to deliver products in a VUCA world. This raises the question: Is architecture something that should be developed in an agile way at all? Is it part of the complex problem horizon? Or is it part of the complicated (see
A Architecture is also in a VUCA environment, because our architecture may need to change because...
…technical fundamentals change
Research and development enable faster changes to technical components (hardware or software), which are often not backward compatible.
…Customer needs are changing
Customer needs are changing as a result of new competition and new technical possibilities.
…new competition emerges
In a free market, customers generally have a free choice of suppliers for their products. If new competitors emerge, this can have a negative impact on an organization.
Best practices for agility from frameworks
Some agile scaling frameworks offer ways to incorporate agility into agile collaboration in a structured manner. One example of this is the Scaled Agile Framework (SAFe), which offers the following models for mapping architectural requirements:
Architectural Runway
The Architectural Runway consists largely of existing code, components, and the corresponding infrastructure required to implement functions quickly but with sufficient quality. According to SAFe, it is therefore necessary for the continuous delivery pipeline, as it enables continuous value flow.
Intentional Architecture describes proactively improving everything that customers find appealing about a system or product. From the design of systems that come into direct contact with customers to the fundamentals of design strategies on which the product or system is developed.
Emergent Design makes it possible to keep existing designs up to date while still being able to adapt when customers or customer requirements change.
Types of architecture
When considering architecture in an agile organisation, it is important to remember that architecture occurs at various levels. For example, there is organisational architecture, business architecture, building architecture and, of course, IT architecture. The latter can be divided even further.
When pursuing architectural goals, these types of architecture should be considered equally, even if an architectural runway is difficult to predict in some cases (e.g. building architecture).
Architectural Enabler
To implement intentional design, SAFe uses the concept of enablers. Enablers make work on the architectural runway transparent by existing at every level of the artefacts (story, feature, etc.) and providing a measure for improving the architectural runway.
← back to list