You think that because you understand ‘one’ that you must therefore understand ‘two’ because one and one make two. But you forget that you must also understand ‘and.’

—Donella H. Meadows, Thinking in Systems [1]

Ready to start learning?

Use our finder to explore current offerings or learn more about a specific course

Solution Architect

The Solution Architect is responsible for defining and communicating a shared technical and architectural vision for a Solution Train to help ensure the solution under development will be fit for its intended purpose.

This article describes the role Solution Architects play in SAFe. It guides those building large-scale IT systems as well as those building large, cyber-physical, engineered systems. Many large systems—satellites, vehicles, robotics, medical devices, and more—have both cyber-physical and large-scale IT elements. In practice, the Solution Architect role is typically filled by a small team rather than one individual.


Solution Architects 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 various Solution Train roles and Agile Teams to elaborate the solution, validate technology assumptions, evaluate implementation alternatives, and converge on the final solution.

Key Collaborations

Designing a successful large solution is a highly collaborative process that requires ongoing communication, coordination, and cooperation across different people and teams involved in large solution development. This process is led by the Solution Architect and involves the key collaborations depicted in Figure 1.

Figure 1. Key collaborations of the Solution Architect
Figure 1. Key collaborations of the Solution Architect

The most critical interactions appear in the following areas:

  • Steer the Solution Train – The Solution Train’s forward momentum is guided by three key roles. The Solution Architect provides an architecture that supports the business direction. Solution Management determines the solution’s direction; the Solution Train Engineer (STE) facilitates the solution development process. These roles intersect and collaborate at PI boundaries and during PI execution. The architect collaborates with the Solution Management to develop the Solution Vision, Solution Roadmap, and the Capabilities required to meet them. They also collaborate with the STE to eliminate the Solution Train’s technology impediments and provide better synergy between the solution architecture and the Solution Train structure and process. As a critical role in steering the Solution Train, the architect participates in various aspects of Coordinate and Deliver.
  • Align on enterprise architecture – In addition to delivering on its purpose for the intended customer, every large solution must also align with the requirements of the rest of the organization and business ecosystem. Much of this pertains to enterprise architecture and requires close interaction of the Solution Architect with the Enterprise Architect. Some of these collaborations occur naturally in the context of the Portfolio Kanban system. Often, the Solution Architect may perform the role of the Epic Owner for an architectural epic in portfolio kanban. Aligning with the rest of the organization may also involve interactions with Solution Architects from other Solution Trains.
  • Evolve solution architecture – With Agile, large solutions are not designed one time, top-down. Instead, the high-level architectural evolves in the context, reality, and constraints of what the trains can deliver. This involves close interactions between the Solution Architect, the System Architects, and the Suppliers within the Solution Train. Their continuous collaboration culminates at every PI boundary.
  • Work with special teams – The Solution Architect works with the teams responsible for the different functions required to support the solution development work. The System Team is one such example. There may be a System Team at the Solution Train level, or select ART-level System Teams participate in the work critical to the solution. This often entails enabling solution integration and testing or providing the optimal development infrastructure. Additionally, the Solution Architect may be involved with Shared Services responsible for other concerns, such as deployment, system reliability engineering, user experience design, data management, compliance, etc.


The Solution Architect’s responsibilities can be categorized into the following responsibility areas, as shown in Figure 2.

Figure 2. Areas of responsibility of a Solution Architect
Figure 2. Areas of responsibility of a Solution Architect

Each of these responsibility areas is described in the sections below.

Implementing Lean Systems Engineering

The architect has a crucial role in evolving the way of building large cyber-physical systems that usually involve a highly diverse technology stack and multiple ARTs and suppliers. The practices for implementing Lean Systems Engineering define how this is approached in Enterprise Solution Delivery. For reference, the practices are as follows:

  1. Specify the solution incrementally
  2. Apply multiple planning horizons
  3. Design for change
  4. Frequently integrate the end-to-end solution
  5. Continually address compliance concerns
  6. Use Solution Trains to build large solutions
  7. Manage the supply chain
  8. Build an end-to-end Continuous Delivery Pipeline
  9. Evolve deployed systems
  10. Actively manage artificial intelligence/machine learning systems

The architect has a vital role in implementing these practices. Some of these are specific architect responsibilities that are discussed further in this article.

Establishing Solution Intent and Context

Successful solution development requires a clear understanding of what it is to be developed and delivered. The Solution Architect plays a crucial role in the solution definition providing the technology direction. This is achieved in an Agile manner where the Solution Intent and Context are progressively explored based on the learning milestones. The Solution Architect does the following:

  • Identify and respond to technology-enabled business opportunities – Succeeding in the digital age requires much more than simply designing technology solutions that meet predefined business requirements. Instead, solution definition happens at the intersection of technological capability and business opportunity. Here, the crucial role of the Solution Architect is to ideate practical, technical possibilities that represent value to the business.
  • Participate in solution definition – Defining solution Capabilities requires an understanding of the underlying architecture and technological strategies for implementation. For this reason, the Solution Architect is usually very involved in the solution definition as captured in Solution Intent. In addition to offering insights into the technical aspects of the solution, this involvement allows the architect to plan the necessary architectural Enablers to support the business value.
  • Evaluate technology tradeoffs – The choice of technology for large solution development has significant implications. The Solution Architect assesses various possible technology alternatives and implementation approaches. In close collaboration with Solution Management, the Solution Architect makes strategic technology decisions, seeking a productive balance between the implementation cost and business value. Experimentation often informs such decisions.
  • Formulate architectural intent for the solution – Solution Architects are responsible for defining the architectural concept of the solution. This includes critical technologies and their use, the structure of the solution in terms of its subsystems, and so on. This is one of the core aspects of the Solution Architect’s role. The architect must define the architectural direction while fully understanding that the actual system design will evolve due to the implementation and that the original architectural ideas will undergo multiple adjustments. It is the task of the Solution Architect not only to define architectures but also to see them validated in practice.
  • Define compliance requirements and solution NFRs – The Solution Architect helps define the Nonfunctional Requirements (NFRs) for the solution based on the business need and the necessary technology tradeoffs. In addition, large solutions are often subject to regulatory compliance and standards, whose architectural and technological impact is managed by the Solution Architect.
  • Understand and communicate Solution Context – Customer solutions live in an ecosystem that includes the execution environment, adjacent solutions, and other vital parameters. Collectively, this is known as Solution Context. The solution context informs architectural decisions for the solution, its supporting infrastructure, and lifecycle processes. The Solution Architect communicates the solution context to the Solution Train and works with ARTs, suppliers, and shared services to design and implement a viable solution.

Defining and Communicating Architecture Vision

Solution architecture is constantly evolving to support the ongoing flow of business capabilities. The architectural changes need to be defined, their impact must be assessed, and all of this must be communicated to the many solution builders involved in the development effort. The Solution Architect achieves this via the following activities:

  • Prepare and update the architecture vision and roadmap – To inform the direction of the Solution Train in the PI, the Solution Architect regularly updates the vision and strategy for solution architecture. The architect also continually updates the solution Roadmap with the architectural capabilities that guide the progression of the Solution Train over time.
  • Define architectural enablers and runway – To support the Solution Train’s business priorities, the System Architect defines the Architectural Runway, comprised of enabler capabilities. It’s a rolling-wave process that creates reasonable certainty, clarity, and detail for near-term needs while supporting flexibility for the future.
  • Participate in Pre- and PI Planning – In Pre-Planning and PI Planning events, the Solution Architect communicates the architecture vision and works with System Architects and Suppliers to transform the high-level architecture intent into a realistic, actionable set of steps factored into the Solution Train’s PI plan. While pre-planning occurs at the Solution Train level, the Solution Architect participates in the PI planning events with the constituent ARTs, as needed.
  • Ensure capacity allocation for enablement work – Evolving and refactoring architectural capabilities require team implementation effort. The Solution Architect works with the Solution Management to define a productive capacity allocated for business capabilities vs. capacity for technology enablement.

Evolving Solution Architecture with ARTs and Suppliers

With Agile, the evolution of the solution’s architecture does not happen in a top-down manner. Instead, the Solution Architect ensures that the high-level architectural intent evolves hand-in-hand with the hands-on implementation by the Agile Release Trains and suppliers. The following is done to support this process:

  • Support exploration and experimentation – The architectural runway contains numerous unknowns that need to be resolved to enable the intended business capabilities. The Solution Architect participates in the most critical explorations and experimentation aiming to address such unknowns. They often work with specific ARTs, suppliers, and individual Agile Teams in technical experimentation.
  • Apply modeling and simulation – To approximate the critical aspects of the solution design in a timely and cost-efficient way, modeling and simulation are used—guided by the Solution Architect and implemented by the ARTs and suppliers. Solution Architects apply Model-Based Systems Engineering (MBSE) and simulation to progressively uncover and address the intricacies of near-term architectural advancements.
  • Regularly review solution increments – The most convincing evidence of successful architecture is the functionality of the solution it enables. To this end, the Solution Architect regularly participates in System and Solution Demos and ensures that the architectural enablers achieve their purpose. SAFe recommends that a fully (or at least partially) integrated solution increment is produced multiple times in the PI (see Enterprise Solution Delivery for more detail on frequent integration).
  • Collaborate with ARTs and suppliers on solution design – To build a viable solution, architectural intent needs to be balanced against the reality of implementation. To achieve this, the Solution Architect regularly interacts with System Architects and technology leads from ARTs and suppliers to collaborate on solution design and familiarize ARTs and suppliers with an end-to-end view of the solution.
  • Participate in establishing Solution Train flow – Solution architecture is intricately connected with the structure of the development organization, each influencing the flow of customer value. The Solution Architect participates in establishing Solution Train Flow via the value stream mapping process and helps the Solution Train define improvements to the value delivery process. In this process, the architect often utilizes the ‘Inverse Conway Maneuver’ by helping teams apply Team Topologies.

Fostering Built-in Quality and the Continuous Delivery Pipeline

With large solutions, the impact of quality issues mounts up very quickly. Additionally, if done infrequently, solution delivery creates substantial disruption and rework for the Solution Train. The Solution Architect is well-positioned to assist the train in establishing effective quality practices and building the continuous delivery capability through the following activities:

  • Foster solution design that supports frequent integration and testability – Architectural choices influence how easy or hard it is to leverage Built-in Quality practices. The solution NFRs may further constrain the choices. Assisted by System Architects and Suppliers, Solution Architects help navigate the tradeoffs that enable frequent integration and testability of solution assets. Additionally, the Solution Architect is well-positioned to suggest specific implementation paths that leverage incremental development by supporting frequent integration and improved testability.
  • Participate in the design of the CDP – The architect supports the creation and evolution of the Continuous Delivery Pipeline. They typically provide guidance regarding technologies and tools to power the CDP. In addition, the Solution Architect directs solution design towards improved deployability by reducing and mitigating coupling across solution components and improving interfaces with other systems.
  • Define and evolve development and deployment infrastructure – To ensure built-in quality practices are applied effectively and enable the CDP, the architect helps understand and define the infrastructure required to develop and deliver customer value. This work is often performed in close collaboration with the System Architects, Suppliers, System Team, and Shared Services responsible for deployment operations. Due to the complexity of the solution context, this may be a task with a high impact on the productivity of the development process.
  • Participate in release governance – Based on their deep understanding of solution architecture and technology impact, the Solution Architect provides essential guidance regarding release governance. Their effort often involves determining the technology impact of specific releases and infrastructure implications. In addition, based on their understanding of the Solution Roadmap, the Solution Architect helps architecture evolve to support low coupling and improved deployability of subsystems and components where the change is most frequent.

Evolving Live Solutions

Once the initial version of the solution has been delivered to the customer, the development work usually doesn’t end. Additionally, the solution context is often evolving, driven by increasing usage characteristics, etc. All of this needs continuous architectural effort in supporting the usage stage of the solution and requires the following from the Solution Architect:

  • Evolve architecture to support new business priorities – The architectural work does not stop after the initial version of the solution has been developed and released. New business capabilities will be planned, requiring architectural enablement to continue to be built into the solution progressively. To address this, the architect continuously updates and refines the architectural runway.
  • Advance and support NFRs – As the solution goes live, matures, and undergoes various usage milestones, the landscape of applicable NFRs changes. The Solution Architect defines and communicates changes to existing NFRs and defines new NFRs needed to support evolving uses of the system.
  • Ensure continuous compliance – The Solution Architect ensures that the new releases of the live solution adhere to regulatory requirements. This work may involve incorporating new compliance regulations. Additionally, the ones supported in the past are often affected by ongoing development and may require further work to ascertain compliance. Approaches include incorporating enablement for some compliance requirements into the solution design and using automated methods for compliance verification.

Learn More

[1] Meadows, Donella H. Thinking in Systems: A Primer. Chelsea Green Publishing, 2008.

Last Update: 30 June 2023