Agile Software Architecture: From Idea to System – but Never Quite as Planned

Holidays are great. I had been looking forward to it for weeks and spent days planning the route and booking hotels. Now I’m standing in front of our house with my family, the taxi isn’t coming, and my five-year-old son is whining about the heat and how boring it is to wait.
When the taxi finally arrives, the child seat we ordered is missing, but somehow we make it to the train station. We arrive at our holiday desti­nation much too late, only to find out on site that the accom­mo­dation is not usable due to last-minute renova­tions. We quickly look for a hotel and are no longer quite so sure how great holidays really are…

Of course, holidays are great. But you sometimes have to admit: they’re not always as smooth and relaxing as expected. With enough travel experience, you develop a certain calmness and learn how to deal with surprises. Not every­thing can be controlled – and comedy is, after all, just drama plus time.

Software architecture is also great. I would argue that holidays and archi­tec­tures have a lot in common. Architecture plans rarely survive the first encounter with reality. What we end up building is never what we initially drew up on the white­board. That’s not an exception – it’s the normal mode of operation for designing software.

Modern software devel­opment is fast, distributed, and charac­terized by constant change. New frame­works, tools, platforms, and paradigms emerge all the time, decisions have unexpected side effects, and technologies reveal unforeseen problems. Couldn’t we have done it right from the start? Shouldn’t we have figured that out beforehand?
Actually: No. With some devel­opment experience, you develop a certain calmness and learn how to deal with surprises. Not every­thing can be controlled – and comedy is, after all, just drama plus time.

Architecture and Agility as Ideal Partners

Modern defin­i­tions of software architecture have one thing in common: they describe the disci­pline as being concerned with the core elements of a system – the ones that are difficult to change later on. Martin Fowler puts it this way:

“To me, the term architecture conveys a notion of the core elements of the system, the pieces that are difficult to change. A foundation on which the rest must be built.”

In the 1980s, these founda­tional, hard-to-change decisions were mostly struc­tural in nature. How should our system be broken down into compo­nents? What inter­faces should it have? How should we store data?

In the 1990s, more programming languages, networking, and virtu­al­ization of systems became increas­ingly important choices. IBM mainframes and Unix worksta­tions had previ­ously been the only real options. Now, new server technologies emerged. In 1995 alone, Windows NT, the Apache HTTP Server, and programming languages like Java, PHP, JavaScript, Ruby, and Delphi saw the light of day. These also brought new patterns and imple­men­tation strategies. With the rise of the internet, software users became more numerous and geograph­i­cally dispersed. Software had to be not only maintainable, but also secure, reliable, usable, and scalable – all under more complex technical conditions.

Today, the number of programming frame­works, environ­ments, and tools is immense. In the field of AI alone, new frame­works appear daily. It’s difficult to maintain an overview of all relevant technologies – let alone be an expert in all of them.

As a result people with different areas of expertise must collab­orate dynam­i­cally to create good software and design tasks have become increas­ingly inter­woven. Since the Agile Manifesto in 2000, agility has supported the necessary networking of roles and feedback-driven work on software. It has become the ideal partner for the modern disci­pline of software architecture.

Figure 1: The Manifesto of Agile Architecture Work [1]

Figure 1 shows the “Manifesto” for modern architecture work, with its four central value pairs: continuous improvement, goal-oriented design, collab­o­ration, and widely distributed respon­si­bility are identified as most important. This is based in part on the work of David J. Snowden [2]. In his writings on handling complex problems, he recom­mends an approach optimized for exper­i­men­tation: probe – sense – respond. These broadly defined theoretical founda­tions transfer well to software architecture. The manifesto illus­trates core ideas and promotes the tight integration of software design and imple­men­tation work.

The Two Modes of Agile Architecture Work

Anyone practicing software architecture in an agile environment ideally moves between two working modes.

Mode 1: Guardrails provide orientation
Part of architecture work is to establish guardrails to steer software devel­opment over time into a desired direction. These guardrails could be funda­mental decisions about programming languages, infrastructure, data storage, or security models, such as:

• Technical principles: “All external calls must be encrypted.”
• Non-functional requirements: “Latency must always remain under 200 ms.”
• Reference imple­men­ta­tions: “Always use these Docker base images.”
• Automated checks: “In the CI/CD pipeline, depen­dencies on third-party libraries are verified.”

Guardrails prevent chaos and are meant to provide teams with orien­tation, reduce the cognitive load during imple­men­tation, and create space for focused creativity.
If architecture work remained solely in this mode, it would soon seem tradi­tional and eventually be perceived as rigid or obstructive. That’s why in agile contexts, guardrails must be contin­ually challenged and evolved. They should be light­weight and never bind resources excessively.

Mode 2: Architecture evolves continuously
If a service truly scales, whether an imple­men­tation idea is viable, or whether a change holds up over time is hard to tell at design time. Dependable Feedback is more common during imple­men­tation or after deployment. Instead of detailed planning, we need experience and evidence. In this second mode, architecture is seen as a hypothesis, that needs to be (in)validated:

• through small exper­i­ments (spikes),
• through telemetry and log analysis,
• through feature flags or shadow deployments,
• through conscious commu­ni­cation of insights (e.g., in commu­nities or ADRs).

This kind of architecture work thrives on obser­vation, exper­i­men­tation, and learning. The best ideas don’t come from meeting rooms – they arise while debugging, reflecting on system behavior, or grappling with difficult problems.
Working on real problems gradually creates new guardrails, softens existing ones, or leads to an architectural practice that gently guides teams — more effec­tively than hard rules do.

To enable this bottom-up architecture approach, teams need a solid under­standing of goals and context, enough oppor­tu­nities for cross-team exchange, and fine-grained feedback mecha­nisms on a technical level. This part of architecture work has been growing steadily in impor­tance since 2000. Most practices labeled “agile architecture” aim to make this mode effective and practical.

Figure 2: The Two Modes of Modern Architectural Work

Practices to inter­weave the two modes

Success­fully estab­lishing emergent architectural practices (mode 2) as a complement to classical guardrails (mode 1) requires specific techniques. If you are inter­ested, take a look at [1] where practices for these modes and their synergy are discussed in detail. Here a few concepts to convey the core ideas:

• Continuous Architecture: Architecture is under­stood as a continuous, measurable series of exper­i­ments rather than a one-time design activity. Exploratory spikes with feedback loops test new ideas realistically.
• Quality Goals as Drivers: Quality goals are central to architecture and visible to all stake­holders. They also effect team backlogs.
• Feedback First: Health checks and telemetry are central, and architectural rules are contin­u­ously verified through them.
• Soft Standards, Hard Limits: Not every­thing is mandated. There are binding principles and best practices alongside freedom for innovation.
• Light­weight Reviews and Decision Formats: Low-barrier formats like peer reviews, architecture office hours, or decision-making workshops foster reflection without bureaucracy.
• Organi­za­tional-Architectural Alignment: Good architecture also requires organi­za­tional support. For example, team bound­aries should align with domain bound­aries, and team respon­si­bil­ities should match the expected level of innovation.

Sources

[1] Toth, Stefan: “Vorge­hens­muster für Software­architektur. Kombinierbare Praktiken in Zeiten von Agile und Lean”; Carl Hanser Verlag, 2025
[2] Snowden, David J.; Boone, Mary E.: “A Leader’s Framework for Decision Making”; in: Harvard Business Review, 2007

Author

Stefan Toth is the founder of embarc GmbH and author of numerous articles and the books “Vorge­hens­muster für Software­architektur” and “Software-Systeme reviewen”. As a consultant, he supports startups, SMEs, and large corpo­ra­tions in realigning their organi­za­tions, methods, and technologies.