While we must acknowledge emergence in design and system development, a little planning can avoid much waste.

—James O. Coplien, Lean Architecture


Agile Architecture

Agile Architecture is a set of values and practices that support the active evolution of the design and architecture of a system while implementing new system capabilities.

This approach allows the architecture of a system (even a large solution) to evolve over time, while simultaneously supporting the needs of current users. This avoids the overhead and delays associated with the start-stop-start nature and redesign inherent in phase-gate methods. With Agile architecture, the system always runs, supporting a more continuous flow of value.

The Agile architecture principles support Lean-Agile development through collaboration, emergent design, intentional architecture, design simplicity, as well as designing for testability, deployability and releasability. It is further supported by rapid prototyping, domain modeling, and decentralized innovation.


Agile architecture enables incremental value delivery by balancing between emergent design and intentional architecture:

  • Emergent design – Provides the technical basis for a fully evolutionary and incremental implementation approach. This helps designers respond to immediate user needs, allowing the design to emerge as the system is built and deployed.
  • Intentional architecture – This is a set of purposeful, planned architectural initiatives, which enhance solution design, performance, and usability and provide guidance for inter-team design and implementation synchronization.

By balancing emergent design and intentionality, Agile architecture is a Lean-Agile approach to addressing the complexity of building enterprise Solutions. In turn, this approach supports the needs of current users while simultaneously evolving the system to meet near-term future needs. Used together, emergent design and intentionality continuously build and extend the Architectural Runway that provides the technical foundation for future development of business value.

Agile architecture is applicable to all levels of SAFe and is supported by the following principles:

  1. Design emerges. Architecture is a collaboration.
  2. The bigger the system, the longer the runway.
  3. Build the simplest architecture that can possibly work.
  4. When in doubt, code or model it out.
  5. They build it. They test it.
  6. There is no monopoly on innovation.
  7. Implement architectural flow.

#1 – Design Emerges. Architecture Is a Collaboration.

Traditional, phase-gate development methodologies often use Big Design Up-front (BDUF) to create a roadmap and the architectural infrastructure required to fully address the needs of the future system. The belief is that a one-time effort can capture requirements and architectural plans sufficiently to support the system for years to come.

However, the future-proofing approach of BDUF comes with many challenges. One is the delay in starting implementation. A second arises when the planned architecture—a large set of speculative, forward-looking designs—meets the real world. Soon enough, the designs become brittle and hard to change, and eventually, a big-branch-and-merge to a new set of speculative assumptions is the routine course of action. SAFe addresses this by combining emergent design and intentional architecture, driven by collaboration.

Emergent Design

Principle 11 of the Agile Manifesto is the primary driver behind the concept of emergent design: “The best architectures, requirements, and designs emerge from self-organizing teams [2].” This implies that:

  • The design is grown incrementally by those who are closest to it.
  • The design evolves hand-in-hand with business functionality. It is constantly tested and enabled by Continuous ExplorationRefactoring, Test-First, Continuous Integration, and Continuous Deployment.
  • Teams rapidly evolve the design in accordance with the currently known requirements. The design is extended only as necessary to implement and validate the next increment of functionality.

This new practice of emergent design is effective at the Team Level. However, emergent design alone is insufficient when developing large systems. For example:

  • It can cause excessive redesign for things that could have been anticipated. In turn, that drives bad economics and slows time-to-market.
  • Teams are not always able to synchronize with each other, thus creating untested assumptions and inconsistent technical architectures.
  • Teams may not even be aware of some of the larger, upcoming business needs; factors outside their scope of knowledge drive the need for future architectural redesign.
  • Lack of a common technical architecture, which can enhance usability, extensibility, performance, and maintainability of the larger system of systems.
  • New, crosscutting user patterns affect the future fitness of purpose.
  • Lack of planning and design for testing, deployment and releasing.
  • Mergers and acquisitions drive integrations and the need for commonality of infrastructure.

Intentional Architecture

Organizations must respond simultaneously to new business challenges with larger-scale architectural initiatives that require some intentionality and planning. Therefore, there comes a point at which emergent design is insufficient for large-scale system development. Simply put, it’s not possible for teams to anticipate changes that may well occur outside their environment, nor for individual teams to fully understand the entire system and thereby avoid producing redundant and/or conflicting code and designs. For this, some intentional architecture is needed to enhance solution design, performance, and usability and to provide guidance for cross-team design and implementation synchronization.

Architecture Is a Collaboration

Clearly, it’s best to have both: fast, local control of emergent design and applying systems thinking to provide a global view of intentional architecture. This combination provides the guidance needed to ensure that the system as a whole has conceptual integrity and produces the intended result. Figure 1 illustrates how to achieve the right balance of emergent design and intentional architecture.

Figure 1. Intentional architecture, emergent design, and collaboration support system evolution
Figure 1. Intentional architecture, emergent design, and collaboration support system evolution

Figure 1 also illustrates how intentional architecture constrains the emergent design, but at a high enough level of abstraction to allow the teams to effectively adapt the intentional part to their specific context. At the same time, emergent design influences and corrects intentional architecture and also feeds new ideas for future, centralized, intentional effort.

Such a deep reciprocity between emergent design and intentional architecture can occur only as a result of collaboration between Agile Teams, System and Solution Architects, Enterprise Architects, and Product and Solution Management to create an environment that encourages this collaboration.

#2 – The Bigger the System, the Longer the Runway.

An architectural runway exists when the enterprise’s platforms have sufficient technical infrastructure to support the implementation of the highest-priority Features and Capabilities in the backlog without excessive redesign and delays. In order to achieve some degree of an architectural runway, the enterprise must continually invest in extending existing platforms, as well as building and deploying the new platforms needed for evolving business requirements.

In the Lean enterprise, architectural initiatives are incrementally developed and committed to the main code base. Doing so means that architectural initiatives must be split into Enabler Features, which build the runway needed to host the new business features, as Figure 2 illustrates.

Figure 2. The architectural runway continuously evolves to support future functionality.
Figure 2. The Architectural Runway continuously evolves to support future functionality

Each enabler feature must be completed within a Program Increment (PI) such that the system always runs, at least at the PI boundaries. In some cases, this means that new architectural initiatives are implemented incrementally and may not even be exposed to the users in the PI in which they are implemented. In this way, the runway can be implemented and tested behind the scenes, allowing continuous deployment and then released to users when a sufficient feature or capability exists in the next PI or so.

The runway built by intentional architecture and emergent design effectively complement each other at scale: intentional, high-level ideas in support of future functionality are adapted and implemented by Agile teams; they are empowered to figure out the optimal emergent design.

#3 – Build the Simplest Architecture That Can Possibly Work.

“We welcome changing requirements even late in development [2].” Yes, we do, but surely enabling change is facilitated by systems that have understandable designs. As Kent Beck notes, “If simplicity is good, we’ll always leave the system with the simplest design that supports its current functionality [3].” Indeed, at scale, design simplicity is not a luxury but a survival mechanism. There are many considerations that help accomplish this. Here are a few:

  • Use a simple, common language to describe the system
  • Keep the solution model as close to the problem domain as possible
  • Refactor continuously
  • Ensure that object/component interfaces clearly express their intent
  • Follow good, old design principles [4], [5]

Domain-driven design [6], design patterns [4], and applying a system metaphor [3], simplify both the design and the communication between the teams. This social aspect of design simplicity is critical, as it enables collective code ownership, which in turn fosters feature—rather than component—orientation [7]. The dominant approach to evolving maintainable and extendable solutions is to consider the system as a set of collaborating entities. This prevents typical design flaws such as concentrating too much logic at the database layer, creating a thick user interface (UI), or ending up with large and unmanageable code classes. Simplicity requires design skill and knowledge. Communities of Practice help develop and spread these best practices.

#4 – When in Doubt, Code or Model It Out.

Coming to agreement on good design decisions can be difficult. There are legitimate differences of opinion about which solution is best. Often there is no one right answer. And while Agile teams and programs don’t mind refactoring, they surely want to avoid unnecessary rework.

In order to decide, Agile teams can typically just code it out, using Technical or Functional Spikes and even rapid prototyping. Iterations are short, and spikes are small; the result is fast feedback with objective evidence, which can then be subject to A/B testing by the teams, designers, and architects—or even end-users.

Modeling is a useful technique to understand the potential impact of significant scope changes prior to implementation, especially where spikes and prototypes do not provide the necessary learning to avoid excessive redesign. As illustrated in Figure 3, Domain Modeling and use-case modeling are two relatively lightweight Agile modeling techniques that are particularly valuable.

Figure 3. A domain model and a use-case model, supported by a system context diagram

Record Models in Solution Intent

Of course, the models aren’t useful if no one can find them. Therefore, models, technical knowledge, and even various design decisions are recorded in the Solution Intent, which provides a central point of communication. In practice, however,  technical information is represented in many forms, from documents to spreadsheets to the models described above. While documents and spreadsheets are easy for an author to create, they do not necessarily encourage the knowledge transfer or the continuous collaboration required for Lean systems engineering.

A better approach is Model-Based Systems Engineering (MBSE), where the solution intent will contain many different kinds of models, with many options for organizing and linking information. System and Solution Architects/Engineers are typically responsible for tasks ranging from specifying the model information and organization to ensuring its quality. Agile teams populate the model(s) with their respective knowledge and information.

#5 – They Build It. They Test It.

The responsibility for knowing whether a design actually works rests with those who collaborate on designing the architecture. Testing system architecture involves testing the system’s ability to meet its larger-scale functional and nonfunctional operational, performance, and reliability requirements. To do this, teams must also build the testing infrastructure and automate tests wherever possible to enable ongoing system-level testing. And as the architecture evolves, the testing approaches, testing frameworks, and test suites must evolve with it. Therefore architects, engineers, Agile teams, and the System Team actively collaborate in order to continuously Design for Testability.

#6 – There Is No Monopoly on Innovation.

Optimization of architecture is a collaborative effort of Agile teams, architects, engineers, and stakeholders. This can help create a culture of innovation, whereby innovation can come from anyone and anywhere.

Though such ideas come from anyone, capturing and knowledge requires some centralization via communication and recording in solution intent. One of the responsibilities of the Enterprise Architect is to foster an environment where innovative ideas and technology improvements that emerge at the team can be synthesized into the building blocks of the architectural runway. And as Agile can foster the “tyranny of the urgent iteration,” time for innovation should also be built into Innovation and Planning Iterations.

#7 – Implement Architectural Flow.

Enterprise-scale architectural initiatives require coordination across trains and Value Streams. Effective flow of these architectural initiatives is made visible via the Portfolio Kanban. In addition, the ‘pull’ nature of the Kanban system allows programs to establish capacity management based on Work in Process (WIP) limits. This helps avoid overloading the system.

Together with the portfolio Kanban, the Program and Solution Kanban systems provide a SAFe enterprise content governance model, which forms portions of the Economic Framework and helps Decentralize Decision-Making, both of which are vital to a fast, sustainable flow of value. In the Kanban systems, enabler features and capabilities follow a common workflow pattern of exploration, refinement, analysis, prioritization, and implementation.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Manifesto for Agile Software Development. http://agilemanifesto.org/.

[3] Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000.

[4] Bain, Scott. Emergent Design: The Evolutionary Nature of Professional Software Development. Addison-Wesley, 2008.

[5] Shalloway, Alan, et al. Essential Skills for the Agile Developer: A Guide to Better Programming and Design. Addison-Wesley, 2011.

[6] Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.

[7] Larman, Craig and Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010.

[8] Coplien, James and Gertrud Bjørnvig. Lean Architecture for Agile Software Development. Wiley and Sons, 2010.

Last update: 18 October, 2017