With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc...
In any organization, the system architect is responsible for maintaining a high level of understanding of the needs of users. Further, professionals in this position should be aware of the business benefits of a Release Train and system requirements. These professionals guide teams on redesigning, system-level refactoring, intentional architecture and Agile. Further, they foster architectural flow, emergent design and non-functional requirements. Above all, they assist with understanding dependencies and interfaces and also help with correlated team design decisions.
According to SAFe, “An Engineer/Architect is responsible for explaining and sharing of architectural vision and shared technical vision for an Agile Release Train”. A System Architect does it to make sure that the solution or system that is being developed rightly suits the intended purpose.
A Scaled Agile System Architect will be responsible for explaining solution intent and solution context. Further, this professional will evaluate technical trade-offs and will identify the basic subsystems and components. Also, they will identify the collaborations and interfaces between them and will explain non-function requirements. The other roles include guiding Enablers via the solution and Program Kanban Systems. Further, these professionals work with different teams for ensuring the suitability and healthy existence of the purpose.
Also, a SAFe Agile System architect will play a crucial role in team alignment. They do this on the Solution and Agile Release Trains to a shared technical direction. They associate with these teams in explaining the solution, validating technology assumptions, and evaluating and implementing alternatives. Their association is also for the creation of the Continuous Delivery Pipeline. When you take the case of Agile Release Trains, System Architects are not a part of the solution train. Further, they take up many responsibilities of solution engineers/architects.
A Scaled Agile Framework System Architect takes a key position in the program tier. As one of the three key program roles, a system architect in this framework has to work closely with the Product Manager and a Release Train Engineer.
Here, the Release Train Engineer is responsible for supporting and facilitating and also improving all the communication between teams. An engineer in this position does it for enabling ART to deliver what it promised.
A Product manager explains why, when and what the ART does and what it should do.
Similar to challenges in other roles, the role of System Architect in SAFe Agile also faces a few challenges. The most important challenge is to manage several teams working on the delivery of a single vision. When this is the case, the chances of each team coming up with an approach that works in line and harmoniously with all teams are very low.
In this case, all teams should consent to a sole approach. Also, all of them should have a common understanding of how they intend to do things. They should also understand how they wish to design or architect the solution. They also should support the teams such that they can give consent to the technologies that they will be using. All teams should understand how the solution and the components communicate with each other at a high level. They should know the system constraints and any functional requirements that they should have. For instance, they might have some security requirements. They might need data encryption or support for concurrent users. This is something referred to as the last responsible moment. It will be possible to gain a better understanding of these aspects with an example. Let us consider that a property owner is engaged in building construction. In the first instance, he needs to decide whether it is going to be a commercial or a residential building. The number of stories should be decided in advance. Only then, the foundation can be laid accordingly to support the entire structure. Otherwise, it is hard to update later.
In short, a System Architect should be clear on what should be understood and what to and what not to include in the design upfront. This is something to be included in what is called an architectural runway. This runway should encompass things that cannot be iterated at the moment. But, things that can be iterated and incremented can be part of the last responsible moment.
The Scaled Agile System Architect should work on maintaining the architectural runway. They should know that there are a couple of elements to this runway. The first element is that the architect should have a high-level overview of what is required. He should be aware of the type of interactions, technologies and key architectural requirements. The second element is that the architects should prove the Agile teams with sufficient detail at the right time. In turn, the teams can deliver on the needs and can complete any detailed designs that they require for time and User Stories.
When talking about the role of SAFe Agile System architect, there are great chances that they will come across two main hindrances. The first is called vertical drift and the other is horizontal drift.
Vertical drift is where the system architects get deep down rather than staying in the high level of architecture. They try and conclude by engaging in what is called a detailed design. This is one of the two key issues that architects should handle.
Horizontal drift is different from vertical drift. This is where the system architect work at the PI level. Nevertheless, detailed designers not only look at the work that is required at the present Sprint. They will look far ahead too. Here, the difference between the high-level architectural runway and the detailed design is lost. The designers try to design things far too early as well.
Scaled Agile Framework System Architects are Lean-Agile leaders with the following key responsibilities:
Serving an engineering/architect role is a lean enterprise that generally needs the adoption of new habits and mindsets of people on the outlook for their work. This outlook modified how architects apply their technical expertise and need a systems-thinking mindset. These new attitudes towards work fall under five areas as given below:
A SAFe Agile System Architect also functions on the human system that helps with the generation of technology for making sure greater effectiveness and agility. As they are Lean-Agile leaders, these professionals make sure that the organization functions effectively by taking part as members of the Lean-Agile Center of Excellence. They give their share to value stream mapping workshops and coach and train engineers in the achievement of technical agility.
A Scaled Agile Framework System Architect is a Lean-Agile leader. So, professionals in this role tend to function more through influence as compared to authority when it comes to a Lean Enterprise. They create a greater impact by mentoring, teaching and helping with improving the effectiveness of Agile teams. But, they do not directly specify the solution designs. They contribute to the Roadmap and vision for the creation of a course for the solution.
Making effective decisions in the face of unknown or changing requirements need Agile teams to get quicker feedback on the effectiveness of the solution. Architects support this requirement by advocating for and quickening the development and improvement of the ongoing delivery pipeline. Even, they do this by aiding with the Release on Demand.
When it comes to the traditional approach, architects arrive at critical design decisions comparatively early in solution development. By doing this, they expect teams to work on varied elements for following their designs. On the other hand, when it comes to the Agile approach, much technical information is left for improving overtime on the basis of learning. In this approach, decisions are made later in the lifecycle. Companies using this approach follow a set-based design approach. As an outcome, teams are relied upon for making the local design decisions. These decisions are made in such a way that they adapt to the modifying requirements without waiting for architects to generate new designs.
The choices that architects make will have a considerable effect on the usability and utility of systems. A customer-centric approach makes sure that the requirements of the users are the focus when it comes to arriving at architectural choices. Here, design thinking offers a common set of practices and tools for helping architects work with Solution and Product Management in making sure that the proposed solutions meet not only market but also customer and user requirements.
When the responsibilities of System Architects differ in the context of Agile Release Trains, in the case of large solutions that need multiple Agile Release Trains, these professionals gain additional responsibilities. In turn, they support alignment that includes the following:
These professionals work actively with the Agile teams. They do this for making sure that the upcoming design choices are made with complete knowledge of the entire solution and reduce technology hardships and prevent unrequired duplication of capabilities.
In large-scale systems, Release Management also plays a crucial role. Here, System Architects work with key stakeholders and product management on the releasability, release strategy, budget and progress of elements of the solution.
These professionals takes part in the solution demos. At this participation, they generally explain the capabilities that their Agile Release Train has contributed. Even, they review the contributions of the other Agile Release Trains taking a system’s view with a focus on fitness for purpose.
A Scaled Agile Framework System Architect take part in the Architect Sync for making sure of consistency on how upcoming tradeoffs and designs are taken care of across the Solution Train. By doing this, they permit frequent opportunities for steering implementation techniques without turning out to be sources of delays.
Further, a system architect will also take part in the pre-PI planning event. At this event, they work with the Solution Train stakeholders. They do this for identifying the architectural approach, high-level objectives and capability roadmap for the approaching PI Planning event. After PI Planning event, these professionals aid with the summarization of the readings into a set of solution PI objectives previously agreed upon and evaluates the alignment of different ART technical paths.
When talking about the role of System Architect in SAFe Agile, they associate with solution architects for making sure that discrete solutions are created by every Agile Release Train and suppliers go inline into and underwrite the larger capabilities and direction of the entire solution. They take part in the refinement of solution backlog and prioritization. Together they define enabler capabilities and non-functional requirements. They also assign architectural roles to different subsystems and components.