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
The System and Solution Architect/Engineering role is filled by an individual or small team that defines a shared technical and architectural vision for the Solution under development. These people participate in determining the system, subsystems, and interfaces; validate technology assumptions; and evaluate alternatives; all while working closely with the Agile Release Train (ARTs) and Solution Train.
These individuals, or cross-disciplinary teams, take a ‘systems view’ of solution development (SAFe Lean-Agile Principle #2). They participate in defining the higher-level functional and Nonfunctional Requirements (NFRs) by 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/Engineers play a critical role in aligning teams in a shared technical direction geared 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 personnel support solution development by providing, communicating, and evolving the broader technology and architectural view of the solution.
Architect/Engineering teams are found at both the Program and Large Solution Levels. System Architect/Engineering operates mainly in the context of the ART, where these personnel 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 roles engage in close collaboration with business stakeholders, teams, customers, suppliers, and third-party stakeholders to define the technology infrastructure, decompose it into components and subsystems, and define 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, thereby allowing a faster flow of work and better economics.
Architect/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
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, along with the solution intent information models and documentation requirements
Establish critical NFRs at the solution level, and participate in the definition of other NFRs
Operate within the Economic Framework to validate the economic impact of design decisions
Work with portfolio stakeholders—most 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 ART and Solution Train 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 capacity allocation for enablement work
Support technology/engineering aspects of Program and Solution Kanbans
Provide oversight and foster Built-In Quality
Architects routinely participate in software development efforts, and this function is part of SAFe. Architects work at the program and large solution levels, with their role often extending beyond the software domain to include responsibilities that enable value delivery in a technically diverse and heterogeneous multi-domain solution environment.
Enterprises building cyber-physical systems (e.g., embedded systems) 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 follows [1]:
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 preference is understandable because these solutions are big systems and someone has to know how to go about building them—and the BDUF model has the best available one in the past.
As noted in the SAFe Lean-Agile Principles, the BDUF approach is not supportive of product development flow, and it doesn’t produce the optimal economic outcomes. SAFe, by comparison, views software architecture and systems engineering as enabling functions for continuous product development flow. In the Lean-Agile Mindset, these roles focus on cross-disciplinary 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 Compliance chapter in Part 7 elaborates on the shift from traditional phase-gated governance models to a Lean-Agile process that enables flow while still meeting regulatory and compliance concerns.
Design decisions vary significantly regarding their impact, urgency, and frequency of occurrence. This diversity suggests a need to balance centralized and decentralized decision-making (see Principle #9, Decentralize decision-making). In terms of system design, this has two implications:
Certain larger-scale architectural decisions should be centralized. These decisions 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.
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, I&A workshops, and specification workshops.
In any case, Architect/Engineers exhibit the traits of Lean-Agile Leaders:
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)
The success of any solution development program also depends on the organization’s ability to embrace the learnings from empirical evidence. This paradigm can challenge the 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 for the initial design tend to defend the solution and ignore the evidence.
The Lean-Agile Architect/Engineering mindset relies on the firm belief that if a problem arises with the design, the problem does not lie 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 the 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?” http://www.incose.org/AboutSE/WhatIsSE.
[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.