Engineering is a great profession. There is the satisfaction of watching a figment of the imagination emerge through the aid of science to a plan on paper. Then it moves to realization in stone or metal or energy. Then it brings homes to men or women. Then it elevates the standard of living and adds to the comforts of life. This is the engineer’s high privilege.
System Architect/EngineeringSystem Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision for an Agile Release Train (ART) to help ensure the system or Solution under development is fit for its intended purpose.
System Architects describe the Solution Context and Solution Intent, analyze technical trade-offs, determine the primary components and subsystems, identify the interfaces and collaborations between them, define Nonfunctional Requirements (NFRs), guide Enablers through the Program and Solution Kanban systems, and work with Product Management, Solution Management, customers, and Suppliers to help ensure fitness for purpose.
They play a critical role in aligning teams on the Agile Release Train (ART) and Solution Train to a shared technical direction and partner with those teams in elaborating the Solution, validating technology assumptions, evaluating implementation alternatives, and creating the Continuous Delivery Pipeline. In ARTs that are not part of a Solution Train, System Architects also perform many of the activities of Solution Architect/Engineers (Solution AE).
This article describes the roles that System Architect/Engineering play in SAFe. While the roles are similar in most respects, they manage different levels of concern. In some cases, there is more than one System Architect for an ART, thus these roles can be realized by an individual or a small team of people (see the Agile Architecture article for more information).
System Architect/Engineering support solution development by providing, communicating, and evolving the broader technology and architectural view of the solution.
System Architect/Engineering operates mainly in the context of the ART, where they work with Agile Teams and provide technical enablement concerning subsystems and capability areas for an ART. They collaborate closely with business stakeholders, teams, customers, suppliers, and third-party stakeholders in defining the technology infrastructure, decomposing solutions, and systems into components and subsystems, and defining and managing their interfaces and APIs. While providing a general view of solution architecture, Architect/Engineering enables those who implement value by empowering them to make local decisions, allowing faster flow of work and better economics.
An Agile Approach to Designing and Building Systems
Serving in an Architect/Engineering role in a Lean Enterprise often requires adopting new mindsets and habits in how people approach their work. This approach changes how architects apply their technical expertise and requires a systems-thinking mindset. These new habits fall into five areas, described below. For a more complete view of designing system and solutions in an agile manner, see Agile Architecture.
- Customer-Centricity and Design Thinking – The choices made by architects have profound effects on the utility and usability of systems. A customer-centric mindset ensures that the needs of the users are first and foremost when making architectural choices. Design Thinking provides a common set of tools and practices to enable architects to collaborate with Product and Solution Management in ensuring that proposed solutions meet user, customer, and market needs.
- Decentralize decision-making – In a traditional approach, Architect/Engineering make critical design decisions relatively early in solution development, expecting teams working on different components to follow their designs. In the Agile approach, however, many technical details are left to evolve over time based on learning, with decisions finalized later in the lifecycle following a Set-Based Design approach. As a result, teams are trusted to make the local design decisions that adapt to changing needs without waiting for architects to produce new designs.
- Enable the Continuous Delivery Pipeline and DevOps – Making effective decisions in the face of changing or unknown needs requires Agile teams to receive fast feedback on the solution’s effectiveness. Architect/Engineering support this need by advocating for, and steering the development and improvement of, the Continuous Delivery Pipeline, as well as helping to enable Release on Demand.
- Embrace a Leadership role – Architect/Engineering are Lean-Agile Leaders who tend to operate more through influence than authority in a Lean enterprise. They have the greatest impact by teaching, mentoring, and helping improve the effectiveness of the Agile teams, rather than directly specifying the solution designs. And they contribute to the Vision and Roadmap in order to chart a course for the solution.
- Act as change agents – Architect/Engineering also acts on the human system that creates the technology to ensure greater agility and effectiveness. As Lean-Agile Leaders, Architect/Engineering ensure the organization operates effectively by participating as members of the Lean-Agile Center of Excellence (LACE). contributing to Value Stream Mapping workshops, and training and coaching engineers in achieving Technical Agility.
Responsibilities of System/Architect Engineering
System Architect/Engineering are Lean-Agile Leaders who typically have the following responsibilities:
- Participate in planning, definition, and high-level design of the solution and exploration of solution alternatives
- Enable the Continuous Delivery Pipeline through appropriate design guidelines and investment advocacy
- Actively participate in the Continuous Exploration process as part of the Continuous Delivery Pipeline, especially with enabler Epics
- Define subsystems and their interfaces, allocate responsibilities to subsystems, understand solution deployment, and communicate requirements for interactions with solution context
- Work with customers, stakeholders, and suppliers to establish high-level solution intent, and the solution intent information models and documentation requirements
- Establish critical NFRs for the solution and participate in the definition of others
- Operate within an economic framework when analyzing the impact of design decisions
- Work with portfolio stakeholders, notably the Enterprise Architect, to develop, analyze, split, and realize the implementation of enabler epics
- Participate in Program Increment (PI) Planning and Pre- and Post-PI Planning, System and Solution Demos, and Inspect and Adapt(I&A) events
- Define, explore, and support the implementation of enablers to evolve solution intent, working directly with Agile teams to implement them
- Plan and develop the Architectural Runway in support of new business Features and Capabilities
- Work with Product and Solution Management to determine the capacity allocation for enablement work
- Support technology/engineering aspects of program and solution Kanbans
- Provide oversight and foster Built-In Quality and Team and Technical Agility
System Architect/Engineering’s Participation in Large Value Streams
The above section highlights the role of System Architect/Engineering in the context of the ART. For Large Solutions that require multiple ARTs, System Architect/Engineering gains additional responsibilities that support alignment, including:
- Collaborate with Solution Architect/Engineering – System Architect/Engineering collaborate with Solution Architect/Engineering to ensure discrete solutions created by each ART and supplier fit into and support the larger capabilities and direction of the overall solution. This involves participation in Solution Backlog refinement and prioritization, defining enabler capabilities and NFRs, and assigning architectural responsibilities to the various components and subsystems. A description of the relationship between these roles and the role of the Enterprise Architect can be found in the Enterprise Architect article.
- Participate in Pre- and Post-PI Planning – System Architect/Engineering participates in the pre-PI planning event, working with the Solution Train stakeholders to define the architectural approach, capability roadmap, and high-level objectives for the upcoming PI planning. In the post-PI planning event, System Architect/Engineering helps summarize findings into an agreed-to set of solution PI objectives and validates alignment of the various ART technical directions.
- Participate in the Architect Sync – System Architect/Engineering participates in the Architect Sync to ensure consistency in how emerging designs and tradeoffs are managed across the Solution Train, allowing frequent opportunities to steer implementation approaches without becoming a source of delays.
- Participate in the Solution Demo – System Architect/Engineering participates in the solution demo, often demonstrating the capabilities that their ART has contributed and reviewing the contributions of the other ARTs, taking a systems view with an eye toward fitness for purpose.
- Collaborate with release management – In larger-scale systems, release management also plays a significant role. System Architect/Engineers collaborate with Product Management and key stakeholders on progress, budget, release strategy, and releasability of elements of the solution.
- Aligning technology approaches across ARTs – System Architect/Engineering works actively with the Agile teams to ensure that emergent design choices are made with an understanding of the overall solution and minimize technology complexity and avoid unnecessary duplication of capabilities.
Learn More International Council on Systems Engineering. What Is Systems Engineering? https://www.incose.org/systems-engineering  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.
Last update: 27 September 2021