“While we must acknowledge emergence in design and system development, a little planning can avoid much waste.”
—James O. Coplien, Lean Architecture
Agile Architecture in SAFe
Agile Architecture is a set of values, practices, and collaborations that support the active, evolutionary design and architecture of a system. This approach embraces the DevOps mindset, allowing the architecture of a system to evolve continuously over time, while simultaneously supporting the needs of current users. It avoids the overhead and delays associated with the start-stop-start nature and large-scale redesign inherent with phase-gate processes and Big Up Front Design (BUFD).
Agile architecture supports Agile development practices through collaboration, emergent design, intentional architecture, and design simplicity. Like Agile development practices, Agile architecture also enables designing for testability, deployability and releaseability. It is further supported by rapid prototyping, domain modeling, and decentralized innovation.
The architecture of a system can either accelerate or impede the ability to provide frequent, independent releases for the business to meet its objectives. Agile architects support business alignment by optimizing the architecture to support the end-to-end value stream. This enables the business to achieve its goal of continually delivering ‘value in the shortest sustainable lead time’. Agile architects lead this process by supporting “just enough” architectural runway to support evolving business needs. They continually invest in legacy modernization initiatives and know where to refactor to eliminate bottlenecks. They communicate the need for these ongoing technical objectives in clear business terms.
To support the continuous flow of value through the Continuous Delivery Pipeline, Agile architecture:
- Evolves over time while supporting needs of current users
- Avoids overhead and delays associated with phase-gate and BUFD- methods
- Ensures the ‘system always runs’
- Balances emergent design and intentionality
- Takes a systems view across the full value stream
SAFe’s Lean-Agile Principles inform Agile architecture practices. While all apply, three are particularly relevant to architecture. Before committing to a specific design, Agile architects use fast learning cycles (Principle #4) to explore alternatives (Principle #3) and arrive at the optimal solution. They also create the environment for decentralized decision making (Principle #9) by defining and communicating the architectural vision and strategy and then collaborating with and coaching the teams who build it.
Roles and Collaborations
SAFe defines three architect roles: Enterprise, Solution, and System architect, that address these concerns at their respective levels (portfolio, program, and solution). They collaborate regularly across and among levels to ensure alignment and address issues and concerns as they arise. As shown in Figure 1, the roles require all the necessary architectural skills to make technical decisions. Therefore, the role may be filled by more than one person to ensure sufficient knowledge and prevent architecture decisions from bottlenecking teams.
The interdependent nature of business and technical strategy requires the collaboration between architects and other SAFe roles to ensure that the architecture meets the current and evolving needs of the business and the customers it serves. Within the Agile Release Train, System Architects communicate the technical path through the Architectural Runway, Non-Functional Requirements, and the design and support of the Continuous Delivery Pipeline (CD pipeline). Architecture also enables Built-in Quality. The Systems Team realizes the architecture vision by building the supporting infrastructure that enables Agile Teams to design, implement, test, and deliver value. System Architects coordinate with Enterprise and Solution Architects to ensure their solutions are aligned with the larger vision. Finally, architects in any role are also Lean-Agile leaders with a responsibility for mentoring teams and enhancing the overall capabilities of contributors.
Balance Intentionality and Emergence
Traditional architecture approaches led to extensive early architecture work. This can create copious documentation and unvalidated decisions. An alternative method for designing architecture to better align with the business needs is a combination of intentionality and emergent design, where architecture emerges from developers creating the system to see what works. Agile architecture balances intentionality and emergence:
- Intentional architecture – Defines a set of purposeful, planned architectural strategies and initiatives, which enhance solution design, performance, and usability and provide guidance for inter-team design and implementation synchronization.
- Emergent design – Provides the technical basis for a fully evolutionary and incremental implementation approach. This helps developers and designers respond to immediate user needs, allowing the design to evolve as the system is built and deployed.
With this balance, Agile architecture is a Lean-Agile approach to addressing the complexity of building enterprise solutions. It 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 production of business value.
Architecting for DevOps and Release on Demand
Agile architecture fosters a DevOps culture by ensuring Solutions are architected for continuous delivery. Architects participate in the design and execution of the CD pipeline and evangelize and exemplify SAFe’s CALMR principles (see the DevOps article for a complete description of SAFe CALMR principles) . They allow decisions to emerge by defining minimum viable (‘just enough’) architecture, ensuring loose coupling between system elements, supporting the creation and evolution of interfaces, and fostering architecture as code through common annotations, attributes, and naming conventions. Agile architecture also builds quality in by automating architectural compliance checks.
To support continuous deployment, Agile architecture decouples deployment from release. Functionality is deployed to a production environment continuously but only made available to end-users on-demand. Deploying frequently builds trust in the CDP pipeline and reduces delays caused by more traditional governance practices (e.g., release management). This trust enables individual teams and Agile Release Trains (ARTs) to independently explore and test ideas in a true production environment.
The CD pipeline begins and ends with the value hypothesis, defining it in Continuous Exploration and eventually measuring it in Release on Demand. The system architecture provides the necessary telemetry to measure hypotheses to support innovation accounting and other usage data for teams and ARTs to validate their assumptions. Agile architecture also supports the CD pipeline through considering other system factors as first-class architectural concerns, such as test architecture and test data management.
Aligning Architecture with Business Value
In the Digital Age, businesses rely on technology to deliver value to their customers. As business strategy changes, the technology, systems, and business applications that deliver that strategy must change with it. Figure 2 shows an example operational value stream for a customer order and product delivery. The operational steps are shown in green with the systems and applications that support those steps below. Any business changes to the customer experience are realized by those supporting applications and systems. Architects work closely with Business Owners and Product Managers to ensure those systems are capable of realizing current and future business goals.
Strategic Themes, portfolio canvas, and Portfolio Vision influence architecture and drive the architecture runway. They provide the constraints, direction, and overall context for technical investments in a portfolio. Looking more broadly, architecture must also consider the larger enterprise strategy, including awareness across portfolios, especially for Enterprise Architects.
Developing Solution Vision, Solution Intent, Roadmaps
Aligning architecture with business strategy accelerates business goal achievement. Architects realize business objectives by translating strategy from strategic themes into solutions. Those solutions are defined by their Vision, Solution Context, and Solution Intent. The solution intent is a living repository of knowledge representing the system’s single source of truth on requirements, design, structure, behavior, and all other architectural concerns. Solution intent includes the decisions, patterns, models, and other technical information to serve as minimally sufficient documentation. And the solution intent captures system constraints including Non-Functional Requirements (NFRs). Like all other requirements, NFRs are validated continuously with automated tests to ensure quality and compliance.
Roadmaps define a plan to realize the solution. Architects and teams collaboratively define enablers in the roadmap that explore technical options and build the architecture runway, providing early feedback on achieving those milestones. Teams provide feedback on architectural decisions as they build feature on top of it, balancing intentionality and emergence.
The roadmap drives the Backlog which defines all work for an ART. Architects collaborate with Product Management on prioritizing and balancing new functionality with technical work. They anticipate technical debt impediments to flow and architectural runway needs and advocate for their prioritization.
Preparing Architecture for Program Increment Planning
Each increment, teams build the highest priority Features and Enablers. Architects collaborate with Product Management to define and prioritize these near-term work items. They provide feasibility insights that help define and scope current Features and their acceptance criteria. They also consider future Features and define Enablers in the backlog for teams to explore and gain knowledge that ensures the future Feature’s viability.
Architects also consider technical dependencies outside their ART, either with other ARTs on a Solution Train or with other ARTs in the enterprise, acting as a key collaborator in these Coordination activities. They collaborate with teams to reduce discoveries during PI Planning and help ensure teams can make the necessary decisions during PI Planning.
Coordinating Architecture Through PI Planning
During PI Planning, architects support the teams creating the next increment’s plans. They present the architectural briefing as part of the planning agenda. As teams create their plans during breakouts, architects roam the room to ensure teams plan technical work properly and ensure they are accounting for Program Enabler work properly. And they address any questions and concerns.
Architects support the Management Review to address architectural and technical issues on potential adjustments. They also participate with Business Owners as they assign value to the teams’ PI Objectives. They explain, in business terms, how enablers and other technical work support their overall objectives and lobby for their need and importance.
Supporting Continuous Delivery Through PI Execution
Architects own the Program/Solution-level technical and exploration work in Enablers and, as such, guide teams’ progress on their execution. They may attend those teams’ Sprint Planning and/or Sprint Demo events to track progress, address issues, and adjust direction. They are also generally available to the teams for coaching, mentoring, and to ensure problems and issues are addressed quickly so that architecture is not a bottleneck.
Each increment, architects ensure teams demonstrate the results of enabler work including new knowledge, architecture runway additions, and any additions to the Continuous Delivery Pipeline. For large solutions, the Architect Sync event ensures architects stay aligned and share progress at the Large Solution level, Architects meet regularly in the Architecture Sync as shown in Figure 3.
Supporting New Strategic Themes and Value Streams
Architecture must evolve to meet changing business needs and opportunities. Otherwise, technology becomes the bottleneck for business execution. Changes in business strategy are reflected in new or modified strategic themes which, though the portfolio canvas, translate into new or modified solutions and/or value streams. Enterprise Architects support and influence this process by providing input, attending Value Stream Mapping workshops, and setting expectations on technical feasibility. Once the new direction is made, Enterprise Architects collaborate with System and Solution architects to realize the new business direction. They communicate the new strategy and show how it changes solution vision, intent and roadmap.
Enterprise Architects also coordinate architectural work across the portfolio, ensuring alignment across solutions and values streams. They provide technical guidance for the long-term evolution of the technologies and platforms and the larger nonfunctional requirements (security, compliance, performance, and more) for the portfolio solution set. And they often serve as Epic Owners for portfolio level Enablers to ensure large shifts in technology remain in line with business strategy.
Leading the Lean-Agile Transformation
Due to their knowledge and experience, architects are often respected and held in high regard by the development community. Therefore, architects play a key role in any SAFe transformation. Architects are Lean-Agile Leaders and, as such, model leaner ways of thinking and operating so developers learn from their example, coaching, and encouragement. They enable autonomy and encourage mastery to grow the development community’s knowledge base and skill set. SAFe architects embody the new way of working, participate in creating the organization’s (Implementation) Roadmap, and help accelerate the adoption as Lean-Agile leaders.
Learn More Manifesto for Agile Software Development. http://agilemanifesto.org/.  Crispin, Lisa and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009.  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Gregory, Janet, and Lisa Crispin, More Agile Testing: Learning Journeys for the Whole Team, Addison-Wesley, 2015.
Last update: 24 February 2020