System Architect Using Scaled Agile Framework (SAFe®) - News, tips & guidance for agile, development, Atlassian-Software (JIRA, Confluence, Bitbucket, ...) and Google Cloud

This article was first posted on the Agile Hive blog. Click here to read the original.

The Responsibilities and Collaborations of System Architect (SysArch)

The System Architect (SysArch) summarizes their varied responsibilities according to SAFe® version 6.0, released March 15, 2023, in the following graphic:

In addition, SAFe® identifies the Key Collaborations of the System Architect in this graphic:

This SAFe® 6.0 article articulates the details of these responsibilities and collaborations. We will examine these one by one, along with an explanation of how Agile Hive supports and enables the System Architect (or architecture team) to not only accomplish these responsibilities but also accomplish them in the most impactful way possible.

Our Example System

In our example, the fictional Enterprise is HiveFlier Inc., a company that builds personal aircraft. Our Agile Release Train (ART), we call FlyByHive, builds and maintains the navigation system for the personal aircraft. The ART is adopting agile and SAFe® practices, and is preparing for their first Planning Interval, PI1. Agile Hive will support Archie in his role as System Architect and fulfill the responsibilities and collaborations articulated by SAFe®

Leverage a Single Source of Truth for the Agile Release Train (ART)

For each of the responsibilities and collaborations articulated for SysArch there is one consistent efficiency multiplier. This efficiency multiplier is a single source of truth (SSOT) for the artifacts – directly called out as part of SAFe® – as well as supporting any related information and artifacts. These are key for the core values of transparency and alignment.

Note that these two core values have not changed since the inception of SAFe®. In version 6.0, these core values are now also part of the 4 Core Values that include Respect for People and Relentless Improvement. Built-in Quality and Program Execution have not gone away; they have been allocated to more appropriate areas of the framework.

What Is Agile Hive?

Agile Hive was born from the need to have an intuitive add-in to Jira to support SAFe®, at all levels of scaling. In the sections below, we highlight how Agile Hive helps with specific responsibilities and collaborations. We have highlighted key elements to keep this article at a manageable length. Agile Hive supports all the details provided in this article in some way.

Aligning Architecture with Business Priorities

We will give very concise representations of the complex domain of architecture, considering the type of system being developed. The key value of this responsibility of SysArch is to help ensure that the technical decisions, both at the highest level (architecture) down to the component-level design decisions are all working in harmony with the business guardrails.

Here we see the Enabler for SysArch to create reference models tied to the business goal Strategic Theme of expanding the product lines.

Also, because the SysArch takes an overall view of the system from a technical point of view, Archie connects the dots between these two seemingly disparate pieces of work at the ART level – planned for the coming PI.

As a result of analyzing these work items and discussing with the owners and teams involved, Archie creates a new Story for the System Engineering Team to ensure they are involved and that the architecture guidelines are updated properly because of this work. See Story SEI-7 now captured as a child of the Enabler FLYB-6.

Defining and Communicating Architecture Vision

While maintaining the Architecture Vision is work the SysArch will perform as needed on an ongoing basis, we recommend creating visibility across the ART for every PI. To that end, here is an example of a PI Objective the SEI team creates. This keeps the architecture Vision in the forefront of everyone’s mind as work that is essential to the system.

The easier it is for ART participants to find the Architecture Vision, the easier it is to help ensure understanding, adherence, and collective ownership. If the SysArch maintains the Architecture Vision in a Confluence page, linked to the objectives of each PI, then our SSOT in Agile Hive is a key resource for efficiency and integrity.

Architecture Vision example from the Open Group Architectural Framework (TOGAF)

Managing Evolving System Design with Teams

Our SysArch, Archie, has defined the overall design of the solution, for example, common communication protocols, data encryption requirements and services used. As each component team implements their part of the PI 1 Features, they may realize limitations or opportunities for improvements in these architectural decisions. If our SysArch function mandates architectural decisions as immutable, the risk is sub-optimization of the system over time. To foster collaboration for the benefit of the overall system, SysArch makes the current and planned architecture information easily visible to team-level designers as well as other stakeholders.

The SAFe® Lean Agile Principles support experimentation and alignment, for example principle #3 Assume variability; preserve options. When a team member has an idea for a change in design, rather than arguing theoretically or a System Architect leveraging seniority to squelch a potentially viable solution, the teams, ART, and other leadership should embrace experimentation and learning. Scheduling technical experiments into the iterations with clear objectives fosters collaboration and relentless improvement on the technical underpinnings of the system.

For this reason, Agile Hive provides issue types for Enablers, Improvements, and Impediments. The SSOT also captures the history of experiments that were tried, and the learnings gained from them.

Fostering Built-in Quality and Attending to NFRs

A key attribute of Architecture Vision, covered in the previous responsibility section, is responsibility to ensure that non-functional requirements (NFRs) are articulated, prioritized, and implemented consistently across the system. A great description of NFRs is here.

Every complex system has a unique set of NFRs influenced by the type of system, safety and security, compliance etc. While articulated the NFRs is valuable, the SysArch function accelerates system delivery by helping create reusable services, platform foundation and capabilities in the architecture to support consistent and compliant application of NFRs.

Using the Enabler construct to address design constraints as well as system attributes realizes the architecture vision for NFRs. Techniques such as looking at flow distribution, that is the number and percentage of the types of work implemented in each PI, help ensure the balance of customer-facing value and architectural needs. Here is an example Enabler that requires SysArch support to help ensure efficiency in how the automation supporting built-in quality is provided and used.

Supporting DevOps and the Continuous Delivery Pipeline

The SysArch role must always research newest technologies and how they can leverage them in the organization to provide value to the customer and the Enterprise. If the SysArch allows DevOps practices, for example, to be decided and implemented without consideration of existing and potentially new technologies for the Enterprise, then the technologies could work against one another.

We must consider all the work together for the system. The SSOT of Agile Hive provides the vehicle of transparency and alignment required to keep all technology decisions to be considered, experimented and decided together with the many perspectives and choices available.

Key Collaborations

As depicted in the second graphic in this article, there are four key types of collaborative partnerships the SysArch function leverages to help ensure flow of value in the system, as best supported by the technical architecture. In this section, we describe how Agile Hive supports these key collaborations.

Work with the Release Train Engineer and Product Management to Steer the ART

While the System Architect is responsible for defining and protecting the technical integrity of how the underlying solution works, the Product Management represents the needs of internal and external customers, and the Release Train Engineer (RTE) helps facilitate and coach the success of the ART toward those outcomes. In a complex system, as represented in our example FlyByHive, the harmony between how the user uses the system and how the “under the hood” product is designed, and works is critical to balancing needs at all levels. A successful technique used to capture usage and implementation information is the use of graphical models.

One can most effectively steer when they have a view of where they are, where they intend to go, and how they will get there. Using an analogy of taking your family on a driving trip across the country, you must plan a route, meet your family members’ goals for the trip and most importantly ensure that your mode of transportation is reliable. We must address all concerns to reach the goals.

A critical part of steering is reacting to change along the route. The collaboration between the PM, System Architect, and the RTE will rely on the understanding of the impact of a change, each from their own responsibility perspective, along with a holistic view of the impact to teams, customers, timelines, and commitments. All these integrated moving parts must be represented in the SSOT for that triad of roles to respond quickly and thoroughly to the need to make a steering change.

Align on Solution/Enterprise Architecture with Solution Architects and Enterprise Architects

Just as SysArch has the responsibility of aligning with business priorities, articulated above, in a complex organization structure that includes Enterprise Architects and Solution Architects, the SysArch must also collaborate and align at all levels of architecture. This collaboration mirrors the collaboration between teams on an ART and SysArch. The higher-level architecture must defend or dispute technical decisions at the ART level for the good of the ART system.

Therefore, this alignment is not just application of decisions coming “from above”. The SysArch has the awesome responsibility of defending the system he represents. The SSOT in Agile Hive provides the data and supporting information the SysArch needs in this collaboration.

Evolve System Architecture with Teams

In the responsibility listed above, Managing Evolving System Design with Teams, we describe how the SysArch, and teams collaborate. Without a SSOT where the teams and SysArch can easily find information from each other, comment asynchronously, and manage the complexity of designs aligned with architecture, the efforts sub-optimize the system.

We demonstrate how to enhance an interaction model from SysArch to show where a system demo will pick up the basic navigation, ensuring alignment both bottom-up and top-down.

The System Architect and PM work together to update this model for the addition of GPS L5 data:

This viewpoint is valuable for

Identifying the work (e.g. Stories) each team needs to supply in the PI
Identifying changes from previous versions of the system
Describing the steps of the System Demo for the relevant iterations and for the PI

Work with Special Teams

Special teams often include those that deal with user experience, integration testing and implementing DevOps practices across one or more ARTs and often an entire Enterprise. The SysArch function must understand all the implications and opportunities of these efforts from a technical point of view.

Agile Hive as a SSOT for an ART and connecting across ARTs and to the Enterprise is a key tool for managing complexity across the organization and other dimensions, like the timing of technology assessments and adoptions.

A Few Final Words

Imagine that you, as an individual, need to assemble a complex piece of furniture. You need to obtain a parts list and assembly instructions to assemble the piece of furniture quickly and correctly. This furniture analogy emphasizes that even more so is the need for transparency, alignment, and clarity in building complex systems in an organization. With many different parts, many teams participating in construction and assembly, a multitude of stakeholders with different perspectives, as well as the opportunity for learning and adjusting as the work proceeds, complex system development requires digital representation to help drive best outcomes.

Putting the pieces of the solution together to realize the outcomes requires a number of teams and many contributors. Product Management works with the Product Owners of the contributing teams to help ensure that the parts will ultimately integrate and work together to realize the outcomes. Agile Hive provides the “one-stop-shop” for seeing how the work of the various teams is progressing and contributing to the outcomes. We can more easily evaluate and communicate changes needed across the ART than relying on unreliable ad-hoc meetings and one-off conversations.

Agile Hive provides a Single Source of Truth for complex systems development, supporting the critical role of System Architect and the harmony between the architecture and features of the system.

Let’s Talk

To learn more about a software-supported implementation of SAFe®, and specifically how Agile Hive can get you there, as a System Architect, or whatever your role, we would be happy to discuss your requirements with you and your team.

Scaled Agile Platform has certified Seibert Media, the developer of Agile Hive, as a Scaled Agile Platform Partner. Scaled Agile, Inc., developer of SAFe®, exclusively awards this status. The worldwide SAFe® partner network officially accredits Seibert Media and Agile Hive’s further development benefits from it. We’d love to tell you more about it!

Get in touch with us today and let us demonstrate how Agile Hive brings it all together.