Improving architecture in SAFe with RCDA

It’s been over a decade since we bundled our experiences with agile architecture in our Risk and Cost Driven Architecture* approach. Since then, we have seen agile practices become mainstream. Agile scaling frameworks like SAFe helped ever larger organizations reap the benefits of agile working. Many organizations applying RCDA practices have also implemented agile scaling practices, often based on SAFe. In this post, I’ll share some of their experiences. They demonstrate how the combination of RCDA and SAFe helps to do architecture better.

Scaling architecture

Agile teams have a maximum viable size, often referred to as the two pizza rule. If a system, solution or organization has more work than can be accomplished by one team, the work between those teams needs to be somehow coordinated. Agile scaling frameworks comprise best practices to guide that coordination effort. Architecture plays a large role in this. Architectural styles like microservices are designed to minimize the need for inter-team coordination to a certain extent, but there will always be inter-team 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) and coordination across a whole business domain or enterprise (enterprise architecture). SAFe prescribes architect roles for each of these levels, called System Architect, Solution Architect and Enterprise Architect. The team level has no prescribed architect role, but that does not mean that there is no architecture work at that level: the self-organizing teams are responsible for their own design decisions.

Each of these levels has similar architecture responsbilities as described by RCDA: they all need to understand the business and technology context within their assigned scope, make decisions and models, validate the design and support the refinement and delivery of their architecture. The main difference between levels is not in the architecture tasks and responsibilities, but in the scope of the models and decisions, as illustrated in the umbrella diagram above (credits to Dana Bredemeyer). Due to this self-similar nature, RCDA practices support the architecture work on each of these levels.

Business value of architecture

“Take an economic view” is SAFe’s lean-agile first principle. When buidling systems, decisions about architecture and prioritization must be made in a proper economic context. That economic perspective on architecture has always been 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 helps to understand not just the business value of architectural epics, features and stories, but also the value of architecture documentation, models and decisions – in business terms. Below are three stories that illustrate this point.

Documenting solution intent

In a large public infrastructure organization, we were asked to help transform the architecture way of working. The architects’ focus had previously been on their deliverables, mostly up-front design documents, which played an important role in project governance. SAFe uses a ‘solution intent’ that leaves room for an architecture to emerge, 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 creating 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.

Ownership of enablers and technical debt

Implementation of architectural decisions is work, which is managed as stories on a backlog. Think of ?technical or infrastructure components, or work to reduce technical debt. Such stories are called ‘enablers’ in SAFe, because other features or stories often depend on them. Their implementation builds the ‘architectural runway’. Enablers typically create business value only indirectly; the enabler by itself has no direct value. For this reason, prioritization of enablers often leads to discussion, especially when organizations use SAFe’s WSJF (Weighted Shortest Job First) 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’s or product’s value development – positioning architecture stories in business terms, and serving as a guide for capacity allocation.

Changing role of architects

Implementing a scaled agile way of working has a lot of impact on architects. Even though SAFe’s role names (enterprise/solution/system architect) sound familiar, being an architect in a truly agile organization requires a different mindset and behaviour. Especially traditional architects used to preparing validated up-front design documents will have to get out of their comfort zone. The idea of ‘autonomous teams’ taking their own design decisions sometimes scares them. We placed particular emphasis on this aspect when we coached architects in the public sector and financial domains. Especially learning about RCDA modeling and delivery practices helped them gain confidence in sharing responsibility for architectural design decisions with agile teams. Risk and cost focus also helped to create guidance for central versus decentral level decision mandates (which architectural decisions should be made on which level).

Agile architecture: beyond the framework

Agile scaling approach like SAFe are large, and organizations implementing them often have trouble focusing on the business value beyond the training, 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, but is sparse on how to do architecture. We discovered that RCDA’s practices give a lot of 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.

* 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.