But how does that work when scaling up the number of teams when applying the Scaled Agile Framework (SAFe)? In this blog my brief view on the interpretation of the role of systems architect introduced within SAFe, with the main goal being “to define a shared technical and architectural vision for the System under development. To participate in determining the system, subsystems, and interfaces, validate technology assumptions and evaluate alternatives while working closely with the Agile Release Train.”
What does that mean in daily practice for the person in question? And for those involved in the “program” layer of the framework? As SAFe states, architecture is primarily a collaborative effort in the agile context.
To begin with, much effort should focus on communication and collaboration. Indeed, the principle of decentralized decision-making is preferred within SAFe, but certain design decisions are better managed centrally. Consider the definition of the high level design, dividing it into subsystems and components and interfaces, choosing certain platforms, establishing the system NFRs and avoiding redundant components. To make that choice properly, the architect must coordinate with many stakeholders. Starting with the teams, of course, who have ideas about this. After all, the teams apply emergent design every day, while the architect must monitor the intentions with the system as a whole. But alignment with the environment is also necessary; with customers, suppliers, portfolio management and especially product management and the release train engineer to identify the necessary enablers. After all, product management must continuously balance between features (value first) and enablers (architecture first). The architect must ensure that attention remains on the necessary foundations to build the features and thus work on the architectural runway.
Because the systems architect cannot be in all places at once, it is necessary to secure the architecture role along several avenues in SAFe. On the one hand by attending events such as PI planning, product management meetings, system demo and inspect & adapt. But also by giving the framework to the teams in the description of the DoR and DoD of user stories or features to be built. Subsequently, those teams themselves should check whether they have delivered complete (for example, including necessary architecture documentation).
In my experience, forming an architecture community with members from the teams can ensure support, feasibility and understanding and is the best guarantee that the proposed architecture will be implemented without the need for the system architect to be constantly present as a guardian. By integration on the front end, analogous to what the systems team does on integration on the back end. By ensuring that the overarching design issues and enablers are multidisciplinary before they get on the backlog as enablers. Not as a “Big Design Up Front” but as an ever-growing “intentional architecture.”
The architect thus works within SAFe less in a prescriptive and controlling role on the solution but more in a coaching and connecting role, working from the overview he can provide. That overview we previously called “the architecture” SAFe has renamed “Solution Intent”; a critical knowledge repository to store, manage, and communicate “what is being built” and “how it will be built.
For as W. Edwards Deming states, “Quality begins with the intent.”
