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

System and Solution Architect/Engineering

The Solution Architect/Engineering role represents an individual or small team that defines a shared technical and architectural vision for the Solution under development. They participate in determining the system, subsystems, and interfaces, validate technology assumptions and evaluate alternatives, working closely with the Agile Release Train (ARTs) and Solution Train. 

These individuals, or cross-disciplinary teams, take a ‘systems view’ on solution development (SAFe Lean-Agile Principle #2). They participate in defining the higher-level functional and Nonfunctional Requirements (NFRs). That includes analyzing technical trade-offs, determining the primary components and subsystems, and identifying the interfaces and collaborations between them. They understand the Solution Context and work with the teams, Customers, and Suppliers to help ensure fitness for purpose.

Collaborating with Solution and Product Management, Architect/Engineering plays a critical role in aligning teams to a shared technical direction toward the accomplishment of the Vision and Roadmap.

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


Architect/Engineering support solution development by providing, communicating and evolving the broader technology and architectural view of the solution.

Architect/Engineering teams occur at both the Program and Large Solution Levels. 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. Solution Architect/Engineering teams provide technical leadership for evolving architectural capabilities of the entire solution.

Both involve close collaboration with business stakeholders, teams, customers, suppliers, and third-party stakeholders in defining the technology infrastructure, decomposition into components and subsystems, and definition of interfaces between subsystems and between the solution and solution context.

While providing a general view of solution architecture, Architect/Engineering enables those who implement value by empowering them to make local decisions, allowing a faster flow of work and better economics.


Architect/Engineering teams are Lean-Agile Leaders who typically have the following responsibilities:

The Origin of the Roles in SAFe

Role of the System Architect

Architects are standard in software development, and this function is part of SAFe. They work at the program and large solution levels, often extending beyond the software domain to include responsibilities that enable value delivery in a technically diverse and heterogeneous, multi-domain solution environment.

Role of Systems Engineering

Enterprises building cyber-physical systems (e.g., embedded systems) however, also rely on systems engineering—which typically encompasses multiple disciplines, including hardware, electrical and electronic, mechanical, hydraulic, and optical, as well as the software elements. The International Council on Systems Engineering defines systems engineering as [1]:

…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

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 favor phase-gated, point-solution Big Design Upfront (BDUF) approaches. This approach is understandable because these are big systems and somebody has to know how to go about building them, and the BDUF model was the best available one 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 optimal economic outcomes. SAFe views software architecture and systems engineering as enabling functions for continuous product development flow. In the Lean-Agile Mindset, these roles focus on 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.

The SAFe article, Compliance, elaborates further on the shift from traditional phase-gated governance models to a Lean-Agile process that enables flow while still meeting regulatory and compliance concerns.

Decentralized Decision-Making

Design decisions vary significantly regarding their impact, urgency, and frequency of occurrence, which suggests a balance of centralized and decentralized decision-making (see Principle #9, Decentralize decision-making).

Concerning system design, this means that:

  • Certain larger-scale architectural decisions should be centralized. These include the definition of primary system intent, subsystems, and interfaces; allocation of functions to subsystems; selection of platforms; elaboration of solution-level NFRs; and elimination of redundancy.
  • However, most design decisions are the responsibility of Agile teams, who must balance applying emergent design in conjunction with intentional architecture (see Agile Architecture).

Frequent collaboration supports system design, 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, Architect/Engineering exhibits the traits of Lean-Agile Leaders. They:

  • Collaborate with, enable, and empower engineers and subject matter experts with decision-making
  • Educate team members in design-related disciplines and lead technical Communities of Practice that foster open exchange of ideas with practitioners across ARTs
  • Demonstrate Lean and Agile principles, as applied to system design, for example, Set-based Design (SBD)

An Empirical Approach

Also, the 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 the case where contrary evidence exists those responsible tend to defend the solution and ignore the evidence.

The Lean-Agile Architect/Engineering mindset relies on the firm belief that if there is a problem with the design, the problem is 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, based on frequent integration and objective evidence
  • Continuous exploration to identify alternatives for enablers necessary to support Minimal Marketable Features (MMFs) included in the Minimum Viable Product (MVP) of an epic
  • SBD, where a spectrum of possible solutions to a problem is considered, instead of a single idea picked too 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 business outcomes are made continuously and in collaboration with 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: 19 November 2017