While we must acknowledge emergence in design and system development, a little planning can avoid much waste.
—James O. Coplien, Lean Architecture
Agile Architecture
Note: This article is part of Extended SAFe Guidance and represents official SAFe content that cannot be accessed directly from the Big Picture.
Agile Architecture is a set of values, practices, and collaborations that support a system's active, evolutionary design and architecture.
This approach embraces the DevOps mindset, allowing the architecture to evolve continuously while supporting current users’ needs. It avoids the overhead and delays associated with the start-stop-start nature and large-scale redesign inherent in phase-gate processes and Big Design Up Front (BDUF).
Agile architecture supports Agile development practices through collaboration, design simplicity, and balancing intentional and emergent design. It enables designing for testability, deployability, and releaseability, supported by rapid prototyping, domain modeling, and decentralized innovation.
Details
The architecture of a system can either accelerate or impede the ability to provide frequent, independent releases that allow the business to meet its objectives. Agile architects support business alignment by optimizing the architecture to support the value stream end-to-end. This optimization enables the company 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 identify where to refactor, eliminating bottlenecks. Architects 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 while supporting the needs of current users
- Avoids overhead and delays associated with phase-gate and BDUF methods
- Ensures the system always runs
- Balances emergent and intentional design
- Takes a systems view across the entire 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.
Collaborating Design with Architect Roles
SAFe defines three architect roles: Enterprise, Solution, and System, which address these concerns at their respective levels (Portfolio, Large Solution, and Essential). These architects regularly collaborate across and among levels to ensure alignment and address issues and concerns as they arise. Figure 1 illustrates all the skills architects need to make technical decisions. It’s often the case that more than one architect is required to ensure sufficient knowledge and prevent architecture decisions from bottlenecking teams.
The interdependent nature of business and technical strategy requires collaboration between architects and other SAFe roles to ensure that the architecture meets the organization’s and its customer’s current and evolving needs. Within the Agile Release Train (ART), System Architects communicate the technical path through the architectural runway, Nonfunctional Requirements, and the design and support of the Continuous Delivery Pipeline (CDP). Architecture also enables Built-in Quality. The Systems Team helps realize the architectural vision by building the supporting infrastructure that allows 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 responsible for mentoring teams and enhancing the overall capabilities of teams.
Balancing Intentional and Emergent Design
Traditional architecture approaches led to extensive early architecture work. This can create overly comprehensive documentation and unvalidated decisions. An alternative approach is designing the architecture to better align with the business needs, which requires the following combination of intentional and emergent design:
- Intentional architecture – Defines a set of purposeful, planned architectural strategies and initiatives that enhance solution design, performance, and usability, guiding cross-team design and synchronized implementation.
- 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 structure 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 evolving the system to meet near-term future needs. Used together, emergent and intentional design continuously develop and extend the architectural runway that provides the technical foundation for the future development of business value.
To implement a balanced approach to design, architects, and teams should prioritize the following:
- Understand the system’s goals and requirements before designing the system
- Identify the areas where intentional design is necessary to build a solid foundation
- Be willing to adapt and evolve the design as the system is developed
- Encourage experimentation and learning to discover new and innovative solutions
- Strive for consistency and cohesion in the design to maintain the system’s quality
By balancing intentional and emergent design, the team can build a flexible, adaptable, and responsive system to changing business needs while maintaining a clear direction and vision for future development.
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 CDP 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 standard annotations, attributes, and naming conventions. Agile architecture also provides built-in quality by automating architectural compliance tests.
To support continuous deployment, Agile architecture decouples deployment from release. Functionality is continuously deployed to a production environment but only available to end-users on demand. Deploying frequently builds trust in the CDP pipeline and reduces delays caused by more traditional release governance practices. This trust enables individual teams and ARTs to explore and test ideas in an actual production environment independently.
The CDP begins and ends with a benefit hypothesis, defining it in Continuous Exploration and eventually measuring it in Release on Demand. The system architecture provides the telemetry to measure hypotheses to support innovation accounting and other usage data for teams and ARTs to validate their assumptions. Agile architecture supports the CDP by considering other system factors as critical 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 provide it must change. Figure 2 shows an example Operational Value Stream for a customer order and product delivery. It illustrates the operational steps with the systems and applications that support them below. Those supporting applications and systems realize any business changes to the customer experience. Architects work closely with Business Owners and Product Managers to ensure those systems can recognize current and future business goals.
Strategic Themes and the Portfolio Vision influence architecture and drive the architecture runway. They provide the constraints, direction, and overall context for technology 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, Intent, and Roadmaps
Aligning architecture with business strategy accelerates achieving business goals. Architects realize these goals by translating strategic themes into solutions. These solutions are defined by their Vision, Solution Context, and Solution Intent. The solution intent includes the decisions, patterns, models, and additional technical information to serve as minimally sufficient documentation, such as design constraints, including Nonfunctional Requirements (NFRs).
Roadmaps define a plan to realize the solution. Architects and teams collaboratively define Enablers in the roadmap to support exploring technical options and building the architectural runway, providing early feedback on achieving those milestones. Teams provide feedback on architectural decisions as they implement features balancing intentionality and emergence.
The roadmap drives backlogs, which define work for an ART. Architects collaborate with Product Management on prioritizing and balancing new functionality with technical work. They anticipate technical debt and help implement Principle #6–Make value flow without interruptions, advocating changes to the architectural runway and ensuring they have high priority.
Prioritizing Features and Enablers for PI Planning
With 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, helping define and scope current features with acceptance criteria. They also consider future features and define enablers in the backlog for teams to explore and gain knowledge that ensures viability.
Architects also consider technical dependencies with other ARTs or Solution Trains, acting as critical collaborators in these Coordination activities. They collaborate with teams to reduce dependencies during PI Planning, helping teams make the necessary decisions and adjustments.
Coordinating Agile Architecture in PI Planning
During PI Planning, architects support the teams by presenting the architectural briefing as part of the planning agenda. As teams make their plans during breakouts, architects help ensure they plan technical work properly and account for the ART’s enabler work. 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
Adopting Agile architecture is critical to support ARTs and Solution Trains to implement technical and exploration with enablers, and, as such, architects often guide teams on their execution. For example, architects may attend various teams’ Iteration Planning and System Demos to review architecture progress, address issues, and adjust direction. They are also generally available to the teams for coaching and mentoring, ensuring problems and issues are addressed quickly so that architecture is not a bottleneck.
With each increment, architects ensure teams balance intentional and emergent design by reviewing the results of enabler work, including new knowledge, additions to the architecture runway, and CDP. For Large Solutions, architects stay aligned and share progress at the Architect Sync event 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, through the Portfolio Canvas, translate into new or modified solutions and 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 the solution vision, intent, and roadmap.
Enterprise Architects coordinate architectural work across the portfolio, ensuring alignment across solutions and value streams. They provide technical guidance for the long-term evolution of the technologies and platforms and the more extensive 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 significant technological shifts remain in line with business strategy.
Leading the Lean-Agile Transformation
Due to their knowledge and experience, architects are often respected and highly regarded by the development community. Therefore, architects play a vital 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
[1] Manifesto for Agile Software Development. http://AgileManifesto.org/ [2] Crispin, Lisa, and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009. [3] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011. [4] Gregory, Janet, and Lisa Crispin. More Agile Testing: Learning Journeys for the Whole Team. Addison-Wesley, 2015.
Last update: 27 February 2023