Assume variability; preserve options.
—SAFe Principle #3
Solution Intent Abstract
Building large-scale software and cyber-physical systems is one of the most complex and challenging endeavors in industry today. System builders must continuously align on “what, exactly, is this thing we are building?” as well as on “how are we going to build it?” They need sufficient and timely knowledge and decisions with respect to both questions. Further, these two questions are related. If system builders don’t know how to build it in an economically or technically feasible manner, then the what may need to be revisited in the context of the how. For example: current technology, capability, and capacity of the teams; and Customer context aligned with the required time frame and Economic Framework.
SAFe calls this critical knowledge pool the Solution Intent and uses it as the basic understanding of the current and evolving requirements, design, and intent—that larger purpose—of the Solution being constructed. System builders also recognize that some of the system understanding is fixed, with nonnegotiable requirements for what the solution must do or already does; and some is variable, subject to further discussion and exploration as facts surface. Understanding and navigating these differences, and allowing variability to proceed even late into the time line, is key to unlocking agility in large-scale solution development.
This article addresses one other critical item as well: Until now, many builders of critical, large-scale solutions have shied away from Agile methods because of the apparently lightweight treatment of system design and documentation. Scaling Lean-Agile development to the needs of those building the world’s most critical systems will be addressed in this article as well.
Solution Intent Details
When building systems that have an unacceptably high cost of failure, one significant barrier to Agile adoption is the need for a more rigorous definition and validation of system behavior. While many practitioners resonate with the Agile Manifesto  value statement of working software over comprehensive documentation, those can become conflicting priorities for enterprises that need both.
Engineering of complex and highly reliable Solutions requires and creates large amounts of technical information. Much of this information reflects the intended behavior of the solution—Features and Capabilities, Stories, Nonfunctional Requirements, system Architecture, domain-level models and designs (e.g., electrical and mechanical), interfaces, Customer specifications, tests and test results, traceability, etc. Other relevant information records some of the key decisions and findings about the system. This may include information from trade studies, results of experiments, the rationale for design choices, and other items. In many cases, this information must become part of the official record, whether out of necessity or regulation.
Introducing Solution Intent
Solution Intent is a critical knowledge repository to store, manage, and communicate what system builders are building and how they are going to build it. It serves many purposes:
- Provides a single source of truth as to the intended and actual behavior of the solution
- Records and communicates requirements, design, and system architecture decisions
- Facilitates further exploration and analysis activities
- Aligns the Customer, the system builders, and Suppliers to a common purpose
- Supports compliance and contractual obligations
Figure 1 illustrates the compound nature of solution intent:
- Current and future state. Builders of complex systems must constantly know two things: what exactly, the current system does now, and what changes are intended for a future state.
- Specifications, designs, and tests. Knowledge of both the current and future states can be captured in any form suitable to the solution builder, but it includes the three primary elements: specifications (documented definition of system behavior), design, and tests.
When building systems for which behavior must be ensured, including life-critical systems, mission-critical systems, and other systems governed by regulatory standards for documents, traceability is a means to help ensure that the system behaves as intended. Traceability connects the elements of solution intent to each other, and to the components of the systems that realize the full system behavior. (Note: For more on building high-assurance systems with Lean-Agile development, refer to the Guidance white paper Agile Development in High-Assurance and Regulated Environments.) Figure 1 illustrates this concept.
The specific elements of solution intent can be realized in many forms, from documents, spreadsheets, and whiteboard sessions to formal requirements and modeling tools, as described in Model-Based Systems Engineering. But as solution intent is a means to the end of building the solution, methods for capturing solution intent should be sufficient but not create unnecessary overhead and waste (see the sufficiency discussion below).
The Dynamic Nature of Solution Intent
Traditionally, the proxy for solution intent has existed largely as a fixed set of requirements, defined up front and often imposed on the solution builder by the Customer, or defined by the system builder. Indeed, the very word “requirements” often implies waterfall thinking, biased by the assumption that requirements all need to be identified up front.
SAFe Principle 3 – Assume variability; preserve options describes the evidence that defining requirements and designs too tightly up front leads to less successful outcomes.
A different approach is needed, one that supports understanding the knowns and allows the unknowns to emerge over the course of development. Therefore, solution intent is not a one-time statement, frozen in time; it must support and evolve throughout the entire development process, as illustrated in Figure 2.
Fixed and Variable Solution Intent
As mentioned earlier, system builders use solution intent for a variety of purposes. However, none of these mandate creating fully defined up-front “point-solution” specifications. Such early decisions restrict exploration of better economic alternatives and often lead to waste and rework . In support of this, SAFe describes two elements of solution intent, fixed and variable, that support the general adaptive requirements and design philosophy that creates the best economic benefit.
Fixed intent represents the knowns. They may be nonnegotiable, or they may have emerged during the course of development. Examples include certain performance specifications (e.g., “the pacemaker waveform must be as follows”), or the need to adhere to compliance standards (“comply with all PCI compliance credit card requirements”), or core capabilities that define the solution (“the Baja Adventure Ride holds four adult riders”).
Variable intent represents the elements for which system builders are free to explore the economic trade-offs of requirements and design alternatives that could meet the need. Once established, these new understandings will eventually become fixed requirements (e.g., “The ride vehicle has a maximum passenger load of 400 KG”). Even then, optionality should be preserved for as long as possible (e.g., “The current design supports 350 KG; let’s discuss that with the Customer”).
Developing Solution Intent
SAFe’s Lean-Agile approach to developing system knowledge differs from the traditional waterfall approach. Figure 3 illustrates the artifacts and processes used to develop solution intent via a more emergent approach.
Solution intent begins with a Vision that describes, at a high level, the purpose and key capabilities of the intended solution, along with the critical nonfunctional requirements. This knowledge, along with an emerging Roadmap and critical Milestones, can provide sufficient guidance to the teams for initial PI Planning and execution. Features, capabilities, Stories, and Enablers are used to further define and realize the solution behavior.
In more complex and/or regulated environments, substantially more investment in solution intent documentation is required. Compliance needs may mandate the creation of standards-based or other technical specifications. Some even require recording the results of exploration and decisions. Others mandate traceability to support analysis, efficacy, and demonstration of solution compliance to approved requirements. In these cases, some elements of solution intent will be formally documented. In the spirit of Lean, this documentation is a compiled result, rather than an up-front mandate.
Collaborating on Solutions Intent
Product and Solution Management, typically working with a Solution Architect and Systems Engineering team and the Customer, is often responsible for the highest-level, system-wide decisions, such as system decomposition, interfaces, and allocations of requirements to various subsystems and capabilities. Solution engineering also establishes the solution intent’s organizational structure and may define where various types of information are managed to support analysis and compliance needs.
Although solution intent is depicted at the Value Stream Level, ARTs build the capabilities and subsystems and make significant contributions to solution intent. Figure 4 shows how the collaboration between the Customer, Product and Solution Management, and ARTs contribute to solution intent; this assigns further behaviors to the ART components by influencing the Program and Value Stream Backlogs.
Solution Management and Solution Architect/Engineering often delegate some solution intent requirements directly to the ARTs that build the capabilities and subsystems of the solution. ARTs also provide feedback on solution-level decisions and raise issues and ideas to solution engineering. And finally, the Customer’s Solution Context has a material impact on solution intent.
Moving from Variable to Fixed Solution Intent
Building and deploying a solution often requires system builders to eventually know exactly what the system does and validate that it does exactly that and nothing else. In other words, at the time of final construction, requirements must all be fixed. Moving from variable to fixed is a process of exploring options and keeping optionality present, as long as possible, within the Economic Framework. This is supported by Set-Based Design practices and the use of enablers, all intended to resolve uncertainty and mitigate risk. At the same time, teams build the system based on their current understanding; as more is known, they implement new features, as Figure 5 illustrates.
Fixed knowledge doesn’t start off at zero, because even at the left end of Figure 5, a lot is known. Systems builders build systems because they have expertise in doing so, and they can reuse elements from previous systems. Then, through the course of development, more becomes known as fast as Iterations, Program Increments, and Solution Demos show what the system is capable of. In this way, variable intent becomes fixed over time and a solid understanding of what the system does, and what it needs to do, emerges.
System of Systems Intent
A system’s solution intent does not necessarily stand alone. Many solutions are systems that participate in a higher-level system of systems. In that case, other systems, as well as Suppliers, provide system builders with unique knowledge and solution elements that accelerate development. Suppliers, for example, will often have separate and independent requirements, designs, and other specifications for their subsystem or capability. From their perspective, that is their solution intent. The ultimate (top-level) solution intent must therefore include the relevant Supplier knowledge and information necessary to communicate decisions, facilitate exploration, align builders, and support compliance. The result is a “daisy chain” of requirements and design decisions that move up and down the system hierarchy, as illustrated in Figure 6.
Minimal but Sufficient Documentation
Solution intent is a means to an end—a means to guide system builders, communicate decisions, and demonstrate compliance. Planning the solution intent’s content, organization, and documentation strategies should begin with those ends in mind. But more is not necessarily better. The Lean-Agile community recommends keeping it light with respect to documenting requirements, design, and architecture . Best practices include:
Favor models over documents. An environment of continuous change challenges a document-centric approach to organizing and managing solution intent. When applied properly, models can provide a more easily maintained way to managing solution intent, as is further discussed in Model-Based Systems Engineering.
Solution intent is a collaboration. There is no monopoly on innovation, and solution intent is not the exclusive domain of the Product and Solution Managers, Architects, and Engineers. Many team members participate in the creation, feedback, and refinement of solution intent information.
Keep options open. Defer decisions to local concerns. Make them as late as possible. An adaptive approach to requirements and design keeps promising options open as long as that is economically feasible. Set-based design practices help avoid committing too early to design and requirements.
Document items in only one place. Record any requirements and design decisions in only one place, a single source of truth that serves as the repository of record for all.
Keep it high level. Communicate at as high a level of abstraction as possible. Don’t over-specify. Provide a range of acceptable behaviors. Describe solution behavior with intent, not specificity. Decentralize requirements and design decision-making authority.
Keep it simple. Only record what is needed. Solution intent is the means to the end of building a product and meeting compliance and contractual obligation. Less is more.
 Ward, Allen and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute, 2014.
 Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
 Leffingwell, Dean and Don Widrig. Managing Software Requirements: A Use Case Approach. Addison-Wesley, 2003.
 Ambler, Scott. “Agile Architecture: Strategies for Scaling Agile Development.” Agile Modeling, 2012. http://agilemodeling.com/essays/agileArchitecture.htm.
Last update: 30 March 2016