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

The System Architect/Engineering role represents an individual or small team that defines a common technical and architectural vision for the Solution under development. They participate in defining the system, subsystems, and interfaces; validate technology assumptions; and evaluate alternatives. They help align the Solution Train and the Agile Release Train (ART) to a common technological and architectural vision.

These individuals, or cross-disciplinary teams, truly “take a system 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 major components and subsystems, and defining the interfaces and collaborations between them. They understand the Solution Context and work with the teams, Customers, and Suppliers to help ensure fitness.

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

And, of course, SAFe System/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.

Details

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 Large Solution 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.

Responsibilities

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

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 large solution 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.

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

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 that foster open exchange of ideas with practitioners across ARTs
  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
  • Continuous exploration to identify alternatives for enablers necessary to support Minimal Marketable Features (MMF) included in the MVP of an epic
  • 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? http://www.incose.org/AboutSE/WhatIsSE.

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

Last update: 17 June, 2017