“I don’t spend my time pontificating about high-concept things; I spend my time solving engineering and manufacturing problems.”

– Elon Musk, SpaceX Chief Engineer/Designer

Solution Architect/Engineering

Solution Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision across a Solution Train to help ensure the system or Solution under development is fit for its intended purpose.

These individuals play a critical role in the Enterprise Solution Delivery (ESD) core competency by aligning the many solution builders across multiple Agile Release Trains (ARTs) and Suppliers to a shared technical direction. To do this, they collaborate with the Agile teams within their solution train and those across the supply chain to elaborate the solution, validate technology assumptions, evaluate implementation alternatives, and converge on the final solution.

Solution AEs define the Solution Context and collaborate with Solution Management to develop the Solution Vision, Solution Roadmap, and the Capabilities required to meet them. They also work with Solution Management to align the Solution Train’s ARTs and Suppliers on what to build and how to build it by establishing the Solution Intent repository. And they play a critical role in solution train events, including Pre- and Post-PI Planning, Solution and System Demos, the Solution Train Sync, and the ART and solution train Inspect and Adapt (I&A) Workshops.

This article describes the role Solution AEs play in SAFe. It guides those building large-scale IT systems as well as those building large, cyber-physical, engineered systems. In fact, many large systems—satellites, vehicles, robotics, medical devices, and more—have both cyber-physical and large-scale IT elements. In practice, the Solution AE role is most likely a team rather than one individual, with the team typically operating under the auspices of a ‘Chief Architect’ or ‘Chief Engineer’.

Details

A large solution is characterized by the size and complexity of the solution itself as well as the technical coordination required across all those who participate in building it. These dimensions can include:

• The number, size, and complexity of the system’s components
• The number of custom and standard interfaces between components
• The extensive use of custom cyber-physical components and other long-lead-time components
• The number of internal and external suppliers
• The rigor of compliance and certification
• The extensive organizational and supply chain support required to build and evolve these systems

Not every large solution requires a solution train. Indeed, many solutions can be built independently by a single ART, integrating other commercial and open-source products through standard interfaces, and supported by a System Architect/Engineering (System AE) function.

In contrast, these large solutions are composed of many bespoke components built by ARTs and suppliers. Consequently, solution trains require additional coordination for co-development, compliance, and long-term support (Figure 1). In addition, their development and integration efforts are substantial, necessitating continuous technical alignment and adjustment.

As shown in Figure 2, the Solution AE role has a primary collaboration with two other SAFe roles. They work with System AEs to design the solution and support Solution and Product Management efforts to define it. Of course, even that is an oversimplification as this role collaborates with many others within the solution train.

Solution AE’s responsibilities fall into the eight categories shown in Figure 2 and detailed below.

Design for Customer and Stakeholders

To survive in the digital age, the enterprise must master the design of innovative, large-scale, digitally-enabled systems. This requires an understanding of the customer as well as the environment in which the solution operates:

• Understand the customer – Solution AEs support Solution Management to understand the customer and the broad set of stakeholders interacting with these large systems, including manufacturing, operations, and maintenance.
• Understand and design for the Solution Context – Solution AEs address the solution’s operational environment by understanding and specifying the physical and environmental constraints and interactions with other systems that live in the same environment.

Assure Feasibility and Sustainability

Solution AEs collaborate with Solution Management on the solution design and apply Design Thinking to assure its feasibility and sustainability over its long life. This requires:

• Evaluating emerging technology – Solution AEs are responsible for tracking the technology innovations applicable to their solutions. In addition, they define Enablers to explore technical alternatives, create new knowledge, and drive optimal technology decisions to achieve the Solution’s Vision.
• Partnering with relevant suppliers — Solution AEs know what capabilities suppliers can offer and how they can contribute to the overall solution.
• Creating a Continuous Delivery Pipeline (CDP) – Sustainability requires continuous delivery. Solution AEs create a vision for the solution’s CDP and ensure the solution is architected to support it, including the ability for teams and ARTs to Release on Demand.

Design and Evolve the Technological Solution

Solution AEs ensure the technical design supports current and future needs by defining the Solution Intent’s structure and evolving its contents through collaboration with ARTs and teams. The resulting information specifies and communicates the broad, system-level decisions that guide development and provide the necessary governance for teams to make localized decisions responsibly. To define and communicate system specifications, Solution AEs:

• Use models to describe and visualize the system – Both IT and cyberphysical systems have significant design elements, constraints, and decisions that AEs need to communicate to teams. Document-centered approaches to system specifications cannot keep pace with the frequent changes of Agile development. Instead, AEs use modeling (Model-Based Systems Engineering) to define, evolve, and communicate decisions. Common elements include:
  • Context – Defines the scope of the system and the interactions with elements in its external environment
  • Structure – Decomposes the system into discrete components and defines the interfaces between them
  • Behavior – Explains how the system responds to external stimuli, describing the needed behaviors that may span one or more Epics during implementation.
  • System allocations – Allocates the system’s resources (e.g., bandwidth, power, weight, space) to components
  • Communications– Defines and communicates common interaction patterns between system components

These elements represent a portion of the larger systems engineering body of knowledge. For more details, see the INCOSE Systems Engineering Body of Knowledge (SE Bok) [1] and the many Architecture Frameworks defined by the engineering community (TOGAF, DoDAF, and SysML).

• Apply digital engineering to cyber-physical systems – As modeling technology matures, digital engineering provides increasing opportunities to accelerate and reduce the costs for learning through analysis and simulation in the virtual world. These virtual models, also called ‘digital twins’, are validated by information collected from the physical and operational environments, as shown by the feedback loops in Figure 3. Solution AEs work across functional domains and organizational boundaries to create this digital engineering environment. They ensure systems in the manufacturing and operational environments provide the necessary data to evolve the virtual models.

• Collaboratively specify the system – Good technical specifications require the deep knowledge held by teams, suppliers, operators, other architects, manufacturers, and many other sources. Instead of reaching decisions in silos, AEs can host collaborative Specification and Design Workshops (Figure 4). These events bring together all relevant stakeholders around a specific topic to quickly and effectively create a shared understanding and arrive at decisions.

• Decompose the solution – Solution AEs decompose the solution into components that reduce the teams’ and ARTs’ cognitive load [2]. In addition, the decomposition leverages existing solutions from internal and external suppliers, which accelerates development and reduces costs.
• Manage interfaces between components – Solution AEs manage interfaces to facilitate independent design iterations. Interfaces apply to both software (commonly APIs) and hardware. See the Design for Change section in SAFe’s hardware development article for more information on hardware interfaces.
• Define the solution context – Solution AEs define the solution’s operational environment whose constraints might include:
  • Supported technologies, interfaces, and APIs
  • Packaging and deployment requirements
  • Physical connections (e.g., power, communication)
  • Resource allocations (e.g., size, weight, capacity, bandwidth, thermal, etc.)

Like other specifications, the solution context evolves based on learning.

• Ensure implementation flexibility – While some requirements are known upfront, many can vary as new knowledge emerges and is subject to further discussion. To support this, AEs can use ranges (e.g., The vehicle’s recharging time is within 20 to 30 minutes) in system specifications that become fixed based on the knowledge gained as teams explore alternative designs. Requirements can also be expressed in the ‘language of intent’ instead of ‘shall statements’ that often constrain the implementation. For example, the statement ‘The vehicle shall support SAE J1772 and CHAdeMO charging standards’ could be expressed as ‘The vehicle can be recharged using the electric standards in all targeted countries’ to communicate intent.
• Perform technology tradeoffs – Solution AEs collaborate with teams, System AEs, and others to evaluate the broad technology landscape and perform tradeoff analysis to arrive at optimal design decisions.
• Manage risks – Large, innovative systems have inherent technological uncertainty, which Solution AEs help address through risk management. For example, they ensure solution train Backlogs contain risk-mitigation work that explores alternatives while validating assumptions. And they support the teams who perform this work.
• Participate in team and ART organization – Solution AEs contribute architectural knowledge when Identifying Value Streams and ARTs to create organizational structures that promote the desired future-state architecture (Conway’s Law [3]).

Manage Nonfunctional Requirements and Compliance

Managing requirements is a collaboration between Solution AE and Solution Management. Solution AEs have the following responsibilities in this collaboration:

• Define Nonfunctional Requirements (NFRs) – Solution AEs are primarily responsible for understanding and managing NFRs that constrain the system’s design and implementation. They document them in the solution intent and define the enablers to address them.
• Address compliance concerns – Solution AEs work with teams and ARTs to create and maintain the objective evidence that demonstrates the solution meets all relevant functional and nonfunctional requirements and that the development processes comply with all regulatory, industry, and other applicable standards.

Define and Prioritize Enablers

Solution AEs collaborate with Solution Management to define and prioritize new exploration work and technical debt reduction. They do this by:

• Defining enablers – Solution AEs are primarily responsible for defining the enablers that explore alternatives and build the architectural runway that support the solution’s future functionality. Enablers are also used to refactor the system and reduce the technical debt inherent in evolving systems.
• Shepherding enablers through the solution Kanban – Solution AEs guide technical enablement work through the Solution Kanban. They represent enablers during prioritization and assist teams and ARTs in implementing them.

Enable Continuous Delivery

Lean-Agile practices require continuous delivery for fast feedback and adjustment, no matter the scale or scope of the solution. To achieve these goals, Solution AEs:

• Architect the solution for continuous delivery – Solution AEs ensure the system’s architecture facilitates continuous delivery practices for ARTs and teams.
• Facilitate CDP development – Solution AEs collaborate with the Agile teams and the System Team to define and build the CDP environments for the solution’s varying component technologies.
• Ensure backlogs build the CDP – Solution AEs help prioritize and communicate the value of CDP enablers to Solution Management, Product Management, and other stakeholders during solution train and ART backlog prioritization activities.

Maintain the Architectural Runway

The Architectural Runway supports a continuous flow of value by providing the technical foundation that allows teams and ARTs to create new functionality quickly and reliably. To build the runway, Solution AEs:

• Create an architectural vision and roadmap – Solution AEs define the future, to-be solution architecture, and show milestones and deliverables in the Solution Roadmap to evolve from the current architecture.
• Manage the architectural runway – Solution AEs collaborate with System AEs and teams to define and build the architectural runway. They ensure that enablers are defined and prioritized in the appropriate solution train and ART backlogs.

Manage Suppliers

To accelerate delivery and reduce costs, large system builders often rely on Suppliers for their unique capabilities. In SAFe, strategic suppliers behave like ARTs and operate as another development value stream in the supply chain. Solution AEs have the following responsibilities with supplier relations:

• Track technology across the supplier landscape – Solution AEs continually track technology innovations across the broad domain of vendors and assess their value to accelerate business needs.
• Evaluate and select suppliers – Solution AEs evaluate each supplier’s technical and cultural fit and provide input to the selection process. For example, they might assess the supplier’s Continuous Integration practices and ability to support the solution’s continuous delivery objectives.
• Align the technical solution across the supply chain – Solution AEs align suppliers through relevant parts of the solution intent, solution context, and solution roadmap.

Learn More

[1] INCOSE Guide to the Systems Engineering Body of Knowledge (SEBoK) version 2.2. May 2020. https://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK)

[2] Skelton, Mathew, and Manuel Pais. Team Topologies. IT Revolution Press, 2019.

[3] Conway’s Law. https://en.wikipedia.org/wiki/Conway%27s_law

[4] Inside Elon Musk’s plan to build one Starship a week. ARS Technica, 2020. https://arstechnica.com/science/2020/03/inside-elon-musks-plan-to-build-one-starship-a-week-and-settle-mars

 

Last update: 9 June 2021