It’s been more than a decade since we developed our Risk and Cost Driven Architecture* approach. Since then, agile practices, like agile scaling, have become mainstream, and agile scaling frameworks, such as the Scaled Agile Framework (SAFe), are helping organizations reap the benefits of agile development.
Many organizations that apply RCDA practices also are implementing agile scaling practices, often based on SAFe. In this post, I’ll share some of their experiences, which demonstrate how the combination of RCDA and SAFe can help any organization better build and manage architecture.
Scaling architecture
Agile teams have a maximum viable size, often referred to as the two pizza rule, and are most commonly capped at 10 people. If an organization has more work than can be accomplished by one team, the work between multiple teams needs to be coordinated. Agile scaling frameworks comprise best practices to guide that coordination effort, and architecture plays a large role in this.
Architectural styles like microservices are designed to minimize the need for interteam coordination to a certain extent, but there will always be interteam dependencies to coordinate, on top of architectural policies, decisions, and trade-offs across teams. Depending on the size and structure of the organization, there might be multiple levels of architectural coordination:
- Coordination across teams working on the same system (system architecture)
- Coordination across multiple systems that solve a business problem together (solution architecture)
- Coordination across a whole business domain or enterprise (enterprise architecture)
SAFe prescribes architect roles for each of these levels: system architect, solution architect and enterprise architect. For single teams, there is no coordinating architect role. Instead, each team is responsible for its own design decisions.
Each of the levels shown in the diagram above (credit to Dana Bredemeyer) has similar architecture responsibilities as described by RCDA. Each needs to understand the business and technology context within its assigned scope, make decisions and build models, validate the design, and support the refinement and delivery of its architecture. The main difference between these levels is not in the architecture tasks and responsibilities, but in the scope of the models and decisions, as illustrated above. RCDA practices support architecture work at each of these levels.
Figure 1: Architecture levels in SAFe
Business value of architecture
“Take an economic view” is SAFe’s lean-agile first principle. When building systems, decisions about architecture and prioritization must be made in a proper economic context. An economic perspective on architecture is RCDA’s primary tenet as well. RCDA practices have proven to be especially strong in supporting this principle; for example, by articulating the business value of architecture. RCDA provides an understanding of the business value of architectural epics, features, and stories, as well as the value of architecture documentation, models and decisions—in business terms. Below are three case studies that illustrate this point.
Documenting solution intent
A large public infrastructure organization asked us to help transform how it builds architecture. The focus of its architects had been on deliverables, mostly upfront design documents, which played an important role in project governance. SAFe relies on “solution intent” to drive intentional architecure and emergent design, but does not prescribe a format or granularity level to document that intent.
In this case, RCDA’s risk and cost focus was very helpful in developing new ways to assure business owners that their investment was sufficiently under control. Focus shifted from extensive design documents to architectural decisions with high risk and cost implications. Less risky decisions were postponed, and business approvers stopped complaining about incomplete designs. RCDA’s value driven architecture documentation approach was particularly useful here. We later repeated this approach in many other organizations. The approach fits nicely with SAFe’s “communicate with models” guidance.
Ownership of enablers and technical debt
Implementing architectural decisions is work, and this work is managed as features and stories on backlogs. Such stories are called “enablers” in SAFe because other features or stories often depend on them. Their implementation builds the architectural runway.
Figure 2: Krutchen's value model for backlog items
Enablers typically create business value only indirectly; the enabler by itself has no direct business value but provides the foundation for business features and stories. For this reason, prioritization of enablers often leads to discussion, especially when organizations use SAFe’s Weighted Shortest Job First (WSJF) for backlog prioritization.**
A common pitfall is that business stakeholders often see enablers as technical nice-to-haves for which they do not feel ownership, even though the integrity of their products often depends on them (“Why don’t you pay for this from your maintenance budget?”). In a large passenger transport organization, we addressed this issue by introducing Philippe Kruchten’s model for reasoning about backlog value. This model plays an important role in RCDA’s delivery support practices and helps create transparency in a portfolio or product’s value development, positioning architecture stories in business terms and serving as a guide for capacity allocation.
SAFe defines “capacity allocation” as the process of distributing a team’s available time and resources among different types of work. By allocating capacity for both business stories and system health activities, organizations can ensure that they are not only delivering new features but also maintaining the stability, reliability, and performance of their systems. This balance is essential for providing a high-quality user experience and avoiding costly disruptions or failures.
Changing role of architects
Implementing a scaled agile way of working has a significant impact on architects. Even though SAFe’s architect roles (enterprise/solution/system architect) sound familiar, being an architect in a truly agile organization requires a different mindset and behaviour. Traditional architects who are used to preparing validated upfront design documents will need to move out of their comfort zone. The idea of autonomous teams making their own design decisions sometimes worries them.
We placed particular emphasis on this aspect when we coached architects in the public sector and financial domains. Learning about RCDA modeling and delivery practices helped them gain confidence in sharing responsibility for architectural design decisions with agile teams. It helped them move away from the Architectural Review Board antipattern, which conflcts with SAFe principles like “decentralize decision-making” and “unlock the intrinsic motivation of knowledge workers.”
Architectural decision-making became teamwork across organizational levels, where risk and cost focus helped to create guidance for centralized versus decentralized decision mandates (i.e., which architectural decisions should be made on which level).
Agile architecture takes more than a framework
Agile scaling approaches like SAFe encompass a large knowledge base, and organizations implementing them often are challenged in focusing on the business value beyond the training, as well as the new roles, cadences, and rituals. Becoming a truly agile architect requires much more change than SAFe’s familiar sounding architect roles seem to imply—and not just for the architects. SAFe offers architect role descriptions, responsibilities, and a framework for cooperation, while RCDA provides guidance on how to do architecture.
We discovered that RCDA’s practices provide practical support to architects and team members that want to do more than change their rituals. They have proven to be especially useful in focusing on business value and getting business stakeholders’ engagement in architecture.
Learn more about RCDA. Also, feel free to contact me for further discussion.
* RCDA also means Responsive, Collaborative Digital Architecture; both meanings are equally valid.
** WSJF should never be used to prioritize enablers mixed with non-enabler stories; use capacity allocation instead, one of SAFe’s lean budget guardrails.
