System Architect

The System Architect is responsible for defining and communicating a shared technical and architectural vision for the solutions developed by an ART.

This helps ensure that the system or solution under development fits its intended purpose.

Details

System Architects play a critical role in aligning Agile Release Train (ART) teams to a shared technical direction. They partner with their teams to:

• Elaborate the system architecture
• Validate technology assumptions
• Evaluate implementation alternatives
• Create the Continuous Delivery Pipeline

In ARTs not part of a Solution Train, System Architects also perform many of the responsibilities of Solution Architects.

To navigate the complexities of system architecture productively, an ART may have multiple System Architects steering different aspects of the system architecture, working together toward a common business goal.

Key Collaborations

System architecture significantly impacts the solution, the teams that develop it, and the broader enterprise ecosystem. Consequently, a critical responsibility of the System Architect is collaborating with various roles, teams, and stakeholders within and outside the ART. The primary goal of these interactions is to ensure that the ART advances a system architecture that supports the evolving business need and enables fast reliable implementation. The key collaborations of the System Architect are shown in Figure 1.

The most critical interactions appear in the following areas:

• Steer the ART – The System Architect works with Product Management and the Release Train Engineer (RTE) to provide the necessary guidance to the train. In this association, Product Management helps define business priorities, the architect ensures that the architecture supports the need, and the RTE provides the necessary facilitation of the train’s core processes. Additionally, the System Architect—as well as the RTE and Product Management—work with the ART’s Business Owners to ensure alignment with the organization’s higher strategic intent. Many of these interactions occur around PI boundaries in preparation for and during PI Planning. Besides steering the solution development effort, the three roles lead Value Stream Management activities for the ART.
• Align on solution/enterprise architecture – The System Architect works proactively with the Enterprise Architect to ensure that the ART is aligned with the organization’s technology landscape. However, when the train is working on a larger solution that involves other ARTs and suppliers, the System Architect interacts with the Solution Architect (as well as other System Architects from the Solution Train). This work includes defining and supporting the implementation of enabler capabilities, consistent choice and use of technologies, regulatory compliance, standards, and higher-level Nonfunctional Requirements (NFRs).
• Evolve system architecture – The System Architect routinely interacts with Agile Teams (including Product Owners and Scrum Master/Team Coaches) to ensure that system design evolves in line with a shared architectural intent and the practical reality of implementation. Some of these interactions happen at PI Planning, where the architect ensures teams’ alignment with the architectural vision. However, the collaboration continues throughout the PI execution. Here, the architect and teams work together to learn and adjust the course of action based on new facts that arose from implementation.
• Work with other groups – The System Architect addresses other concerns with groups like the System Team and Shared Services. The goal of interacting with the System Team is usually to establish optimal architectures and processes for system integration and testing. Often the System Team is significantly involved in implementing critical architectural enablers, which usually results in a close working relationship with the System Architect. Depending on the context, interactions with Shared Services may involve having the System Architect aid the design of the deployment pipeline, as well as information architecture, regulatory compliance issues, information security, metrics instrumentation, and so on.

Responsibilities

The System Architect’s responsibilities consist of the five areas shown in Figure 2.

This article further describes each of the areas.

Aligning Architecture with Business Priorities

The purpose of every solution architecture is to support the development and delivery of business value. Aligning with the business intent is a multi-faceted area of the System Architect’s responsibilities, which include:

• Define enablers and architectural runway – The System Architect will define the necessary enablers, and the ART will progressively build up the runway to support the intended features. The architect’s role is to continuously define, adjust, and support the journey. Defining new enabler features and advancing the runway happens progressively, with critical checkpoints at every PI boundary.
• 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. The architect provides critical insights in this regard.
• Define system NFRs – The System Architect defines Nonfunctional Requirements (NFRs) for the solution and ensures that the architecture will support the required NFRs. System Architects also assist the train in determining specific measures and the necessary instrumentation to safeguard and monitor NFRs.
• Ensure capacity allocation for enablement work – Advancing architectural capabilities requires the teams’ time and effort. The System Architect works with Product Management to allocate proper capacity for architecture work, which occurs while preparing for each PI boundary and during the PI Planning itself.

Defining and Communicating Architecture Vision

The complexity of today’s technology solutions can be overwhelming; to reduce its impact on teams and maintain productivity, the architect embraces a vital role of communicating a clear technology intent to the teams and the rest of the ART. This creates alignment with the system design and the implementation strategy, ultimately resulting in a faster, more sustainable flow of customer value. In achieving this goal, the System Architect will do the following:

• Present architectural vision to teams during PI planning – The System Architect updates the architectural vision before every PI boundary. During PI planning, the architect presents the vision as a part of the briefings and stays available to the teams during the rest of the planning activities. The architectural vision is repeatedly updated to accommodate new and essential technical aspects relevant to the upcoming PI.
• Provide guidance on implementing the vision – During the PI execution, the System Architect stays in sync with the teams and provides further guidance as needed. It’s common for the initial architecture vision to change due to new insights that occur during implementation. The architect ensures that all the system design issues teams encounter during the implementation are addressed.
• Architect for agility and change – To respond effectively to change and embrace new facts that emerge during development, the system design must enable flexibility (see Agile Architecture for additional detail). Helpful tools that allow preserving options include balanced, intentional use of abstraction in system design and Set-Based Engineering.

Evolving System Design with Teams

Any architecture requires ongoing adjustment. So, a critical role of the architect is to establish sustainable interactions with teams that will help reveal inconsistencies in the architectural intent and assist the ART in making necessary improvements. This is a continuous process, a loop of adjusting the intent and learning from the implementation. In this regard, System Architects focus on the following areas:

• Support architectural experiments and spikes – The System Architect works with teams to define and realize crucial experiments to validate architectural ideas with the minimum development effort. Because untested architectural assumptions can be extremely costly when they turn out to be incorrect, this dramatically reduces the amount of rework.
• Collaborate with teams on optimal system design – The architect frequently interacts with teams to provide new inputs and get feedback on the current architectural intent. This collaboration often occurs as part of PI planning, Systems Demos, and Inspect and Adapt. Additionally, the architect may participate in individual team events whenever significant architectural developments are needed. The System Architect provides ongoing coaching to help teams acquire a bigger-picture view of the system design and increase their expertise as they advance the runway to support new business features. To promote a shared understanding of the architectural approach and the technologies involved in solution development, it’s common for a System Architect to participate in technical Communities of Practice (CoPs).
• Align architectural intent with the reality of implementation – The architect makes sure that there is no substantial gap between the expectations expressed in the architectural vision and the reality of team capacities, skills, tools, etc. For this alignment to occur and continue, the architect must stay in close contact with both the teams and the solution assets. This is often achieved by having the System Architect participate directly in creating solution assets or peer reviews. Additionally, it’s helpful for the architect to be directly involved in architectural research spikes that teams undertake.

Fostering Built-in Quality and Attending to NFRs

In many ways, architecture determines how easy or hard it will be to implement new solution features that support quality standards for the new functionality without breaking the old. Likewise, architecture significantly impacts the ART’s ability to implement and sustain the solution’s NFRs. To support these areas of concern, System Architects do the following:

• Promote system design that supports Built-in Quality – the System Architect defines architectures that help the ART shift learning left and discover problems early or prevent them in the first place. Loosely coupled architectures, diligently followed design and coding standards, and ongoing refactoring help keep the system healthy. This results in improved testability and maintainability of code and other solution assets.
• Attend to the system NFRs – NFRs influence solution viability and sustainability significantly. If not adequately attended to throughout development, they may create a large volume of rework or even thwart the entire solution development effort. The System Architect provides ongoing guidance to the train to help incrementally build and sustain NFRs. The architect often assists teams in devising an effective implementation strategy for new NFRs and helps create standards for maintaining the existing ones (some of which are reflected in the corresponding Definition of Done).

Supporting DevOps and the Continuous Delivery Pipeline

System architecture is intricately connected to customer value delivery. This is because architectures can either make value delivery a fast, incremental process the team and stakeholders can control or a nightmare with unpredictable timelines and harsh consequences for the customer and the business. Additionally, the Continuous Delivery Pipeline (CDP) has a structure that needs to be defined in a manner that best supports the needs of the ART.

• Participate in the release governance process – The System Architect helps the ART develop system architecture in a way that supports incremental value delivery. Additionally, the System Architect provides valuable input and assesses the technology impact for a specific release.
• Support design of the CDP – System Architects promote ideas for continuous delivery and DevOps. They also help the teams define the specific architecture of the deployment pipeline, the environments, their procurement, and the necessary tools involved. 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.
• Enable metrics instrumentation – The System Architect 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 addition, System Architects often accept responsibility for supporting experimentation and measurement of user behavior in LeanUX by designing working prototypes or creating specific capabilities in the solution itself.

---

Learn More

[1] Lehman, M. M., J. F. Ramil, P. D. Wernick, D. E. Perry, and W. M. Turski. “Metrics and Laws of Software Evolution—The Nineties View.” Proceedings Fourth International Software Metrics Symposium (METRICS ’97), 1997.

Last update: 5 July 2023