Roles and Responsibilities: System Architect

 

Within the Scaled Agile Framework (SAFe), the System Architect emerges as a key player, wielding a unique blend of technical prowess and strategic insight. This blog embarks on an enlightening journey to unravel the multifaceted roles and responsibilities that define System Architects in the SAFe ecosystem.

Who is a System Architect?

Imagine the System Architect as an architect of dreams, crafting the blueprint for technological excellence. The System Architect is responsible for defining and communicating a shared technical and architectural vision for the solutions developed by an ART.

System Architects play a critical role in aligning Agile Release Train (ART) teams to a shared technical direction. In ARTs not part of a Solution Train, System Architects also perform many of the responsibilities of Solution Architects.

Roles and Responsibilities of System Architect

The System Architect’s responsibilities consist of the five areas shown in the following figure.

First Responsibility: Aligning Architecture with Business Priorities

The first responsibility can be further explained with the following sub-set responsibilities.

1. Define enablers and architectural runway

The System Architect defines the necessary enablers, and the ART progressively builds up the runway to support the intended features. It’s the System Architect’s responsibility to continuously define, adjust, and support the journey.

2. Participate in solution definition

As a part of Design Thinking, the architect is often closely involved in defining the solution. For solution ideation to be effective, it must occur in close connection with the reality of the technological and implementation capabilities of the train.

3, Define System NFRs

The SAs define system Nonfunctional Requirements (NFRs) for the solution and ensures that the architecture will support the NFRs. They also assist the train in determining specific measures and the necessary instrumentation to safeguard and monitor the NFRs.

4. Ensure capacity allocation for enablement work

The SAs work with the Product Management to allocate proper capacity for architecture work, which occurs while preparing for each PI boundary and during the PI Planning itself.

Second Responsibility: Defining and Communicating Architecture Vision

1. Present architectural vision to teams during PI Planning

The SAs update the architectural vision before every PI boundary. It is repeatedly updated to accommodate new and essential technical aspects relevant to the upcoming PI.

2. Provide guidance on implementing the vision

During the PI execution, the SA stays in sync with the teams and provides further guidance as needed. They ensure that all the system design issues team encounter during the implementation are addressed.

3. Architect for agility and change

The system design must enable flexibility to respond effectively to change and emnrace new facts that might emerge during development. Helpful tools that allow this include balanced, intentional use of abstraction in system design and Set-Based Engineering.

Third Responsibility: Evolving System Design with Teams

1. Support architectural experiments and spikes

The SAs work with the teams to define and realize crucial experiments to validate architectural ideas with the minimum development effort. This is crucial as untested architectural assumptions can be extremely costly when they turn out to be incorrect which in turn dramatically reduces the amount of rework.

2. Collaborate with teams on Optimal System Design

The SA must frequently interact with teams to provide new inputs and get feedback on the current architectural intent. This collaboration often occurs during events like PI planning, Systems Demos, and Inspect and Adapt. The SA provides ongoing coaching to help teams acquire a bigger-picture view of the system design and in increasing their expertise as they advance the runway to support new business features.

3. Align architectural intent with the reality of implementation

The architect must ensure that there is no substantial gap between the expectations expressed in the architectural vision and the reality of team capacities, skills, tools, etc. The SA must stay in close contact with both the teams and the solution assets for this alignment to occur and continue.

Fourth Responsibility: Fostering Built-in Quality and Attending to NFRs

1. Promote System Design that supports Built-in Quality

The SA defines architectures that help the ART shift learning left and discover problems early or prevent them in the first place. This results in improved testability and coding standards, and ongoing refactoring helps keep the system healthy.

Built-in Quality

2. Attend to the system NFRs

The SA must provide ongoing guidance to the train to help incrementally build and sustain NFRs. NFRs influence solution viability and sustainability significantly.

Fifth Responsibility: Supporting DevOps and the Continuous Development Pipeline

1. Participate in the release governance process

The SA helps the ART develop system architecture in a way that supports incremental value delivery. They also provide valuable input and assesses the technology impact for a specific release.

2. Support design of the CDP

SAs provide ideas for continuous delivery and the DevOps. As a part of this effort, the System Architect helps the ART determine suitable infrastructure configurations. This often includes using Cloud architectures to enhance the scalability and flexibility of the CDP.

3. Enable metrics instrumentation

The SA facilitates system design that supports the implementation of all necessary metrics. This involves special platforms and tools suitable for the task and proper integration with the solution. In LEAN UX, the SA often accepts responsibility for supporting experimentation and measuring user behavior by designing working prototypes or creating specific capabilities in the solution itself.