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.

—Herbert Hoover (1874 – 1964)

System and Solution Architect/Engineering Abstract

The SAFe System and Solution “Arch/Eng” icon represents the individuals and teams who have the technical responsibility for the overall architectural and engineering design of the system and solution, respectively.

Architect/Engineering are cross-discipline teams that truly “take a system view” on solution development. They participate in the definition of the higher-level functional and Nonfunctional Requirements, analyze technical trade-offs, determine the major components and subsystems, and define the interfaces and collaborations between them. They understand the Solution Context and work with the teams, Customers, and Suppliers to help ensure fitness for use in the Customer’s environment.

In cooperation with Solution and Product Management, Architect/Engineering play a critical role in helping align teams in a common technical direction toward accomplishment of the mission, Vision, and Roadmap.

And, of course, they are Lean-Agile Leaders who understand the complexities of large-scale solution development, and they apply Lean and Agile practices to address them.


Architect/Engineering align the Value Stream and Agile Release Trains to a common technological and architectural vision of the Solution under development. They participate in defining the system and subsystems, validate technology assumptions, and evaluate alternatives. They support Solution development through providing, communicating, and evolving the larger technological and architectural view of the solution.

Arch/Eng teams occur at both the Program and Value Stream Levels. System Arch/Eng operates mainly in the context of the Agile Release Train, where they work with Agile Teams and provide technical enablement with respect to subsystems and capability areas under the purview of the ART. Solution Arch/Eng teams provide technical leadership for evolving architectural capabilities of the entire solution.

Both involve tight collaboration with business stakeholders, teams, Customers, Suppliers, and third-party stakeholders in defining the technology infrastructure, decomposition into components and subsystems, and the definition of interfaces between subsystems and between the solution and Solution Context.

While providing a general view on solution architecture, they enable those who implement value by empowering them to make local decisions in order to provide a faster flow of value and better economics.


Architects and Systems Engineering teams are Lean-Agile Leaders who typically have the following responsibilities:

  • Participate in planning, definition, and high-level design of the solution and explore solution alternatives
  • 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; help establish the solution intent information models and documentation requirements
  • Establish critical Nonfunctional Requirements at the solution level; participate in the definition of others
  • Operate within the Economic Framework to validate the economic impact of design decisions
  • Work with portfolio stakeholders, particularly the Enterprise Architect, to develop, analyze, split, and realize the implementation of enabler Epics
  • Participate in PI Planning and Pre- and Post-PI Planning, System and Solution Demos, and Inspect and Adapt events
  • Define, explore, and support the implementation of value stream and program Enablers to evolve solution intent; work directly with Agile Teams to implement, explore, or support them
  • Plan and develop the Architectural Runway in support of upcoming business Features/Capabilities
  • Work with Product and Solution Management to determine capacity allocation for enablement work
  • Support technology/engineering aspects of Program and Value Stream Kanbans
  • Supervise and foster Built-in Quality

The Origin of the Roles in SAFe

Role of the System Architect

The role of an Architect is common in software development and has been included in SAFe as one of the critical roles at the program and portfolio levels. Also, the role of an Architect often extends beyond just the software domain to include responsibilities that enable value delivery in a technologically diverse and heterogeneous, multi-domain solution environment, so SAFe takes a fairly expansive view of that role.

Role of Systems Engineering

Enterprises building cyber-physical systems, however, also rely on Systems Engineering—a group of people who perform the systems engineering aspects of solution development. These teams typically encompass multiple disciplines, including hardware, electrical and electronic, mechanical, hydraulic, and optical and other aspects of a complex solution, as well as the software elements. INCOSE [1] defines Systems Engineering as:

” . . . an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem, including operations, performance, test, manufacturing, cost and schedule, training and support, and disposal. Systems Engineering integrates all the disciplines and specialty groups into a team effort, forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.”

A Leaner Approach

Clearly, it is impossible to reason about how to build complex solutions without including the roles of software Architecture and Systems Engineering. However, a significant note of caution is warranted. The dominant, traditional methods for both strongly gravitate toward phase-gate, point-solution, Big-Up-Front-Design approaches. This is understandable because a) these are big systems and somebody has to know how one is supposed to go about building them, and b) the stage-gate waterfall model was the best model available at that time.

However, as described extensively in the SAFe Lean-Agile Principles, this approach is not supportive of product development flow, and it doesn’t produce the best economic outcomes. SAFe views software Architecture and Systems Engineering as enabling functions for continuous product development flow. In the Lean-Agile Mindset, these functions focus on frequent cross-discipline collaboration, building systems incrementally through fast, feedback-driven learning cycles, understanding and leveraging the inherent variability of the product development process, and decentralizing control.

Decentralized Decision-Making

Design decisions vary significantly in terms of their impact, urgency, and frequency of occurrence. This suggests a balanced combination of centralized and decentralized decision-making (Principle #9 of SAFe). The basic rule of decentralized decision-making is to centralize only those decisions that are not urgent and long lasting and that have significant economies of scale. Decentralize everything else.

With respect to system design, this means that:

  • Certain larger-scale architectural decisions should be centralized. These include definition of primary system intent, subsystems and interfaces, allocation of functions to subsystems, selection of common platforms, definition of solution-level nonfunctional requirements, elimination of redundancy, and more.
  • However, the rest, and thereby most, of the design decisions are delegated to Agile Teams. The balance is achieved by applying practices of emergent design in conjunction with intentional architecture (see Agile Architecture).

This is supported by frequent collaboration, whether in the form of informal and continuous face-to-face discussions or, more regularly, in PI planning, system and solution demos, inspect and adapt workshops, and specification workshops.

In any case, Arch/Eng exhibits the traits of Lean-Agile Leaders. They:

  1. Collaborate with, enable, and empower engineers and subject matter experts with decision-making
  2. Educate team members in design-related disciplines; lead technical Communities of Practice
  3. Demonstrate Lean and Agile principles, as applied to system design, by example

An Empirical Approach

In addition, success of any solution development program depends on the organization’s ability to embrace the learnings from empirical evidence. This paradigm can challenge traditional mindsets that support detailed, committed early design based on reasoned but unverified hypotheses and implementation strategies. In that case, when the evidence belies the design, those responsible for design may see it as a personal affront and exhibit a tendency to defend the design, not the evidence.

The Lean-Agile Arch/Eng mindset relies on the firm belief that if there is a problem with the design, the problem is with the design, and not with the people who created it. No one could have anticipated the new learnings; it’s research and development, after all. Everyone learns together. This belief is further fostered by:

  • Fact-based governance, where the facts are produced by frequent integration and objective evidence
  • Set-based engineering, where a spectrum of possible solutions to a problem is considered, instead of a single idea picked early
  • Learning Milestones that are planned and executed with the specific purpose of validating the technical and business hypotheses
  • A bias toward economic decision-making, where trade-offs between architectural capabilities of the system and economic outcomes are made continuously and in collaboration with business stakeholders

Learn More

[1] International Council on Systems Engineering. What Is Systems Engineering?

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last update: 20 April 2016