Context is the key—from that comes the understanding of everything.
—Kenneth Noland
Solution Context identifies critical aspects of the operational environment for a Solution. It provides an essential understanding of requirements, usage, installation, operation, and support of the solution itself. The solution context heavily influences opportunities and constraints for releasing on demand.
Understanding the solution context is crucial to value delivery. It impacts development priorities, Solution Intent, Capabilities, Features, and Nonfunctional Requirements (NFRs). It provides opportunities, limits, and constraints for the Continuous Delivery Pipeline and other solution-level Release on Demand activities.
The solution context is often driven by factors outside the control of the organization that develops the solution. The level of coupling between the solution and its context generally represents an architectural and business challenge, that of finding the right balance between flexibility and tightly coupled interaction with the environment—interactions that often cross internal, Supplier, and Customer organizational boundaries.
Rarely are systems built for one’s own use; instead, they are built for others, whether those others be internal operational Value Streams or external customers. This means that no single person typically controls, or fully understands, the complete context for the system’s deployment and use. Rather, a system is shipped, deployed, installed, and maintained in an environment unlike that in which it was developed. Even in the case of internal IT systems, newly developed systems are typically hosted by the IT maintenance and operations teams. In this case, for many reasons, the production environment may not be the same as the development environment (see the DevOps chapter). Therefore, understanding the solution context is critical to reducing risk and achieving fitness for purpose.
Understanding and aligning the solution and solution intent with the solution context requires frequent interaction with the customer. The customer understands the Vision and has the decision-making authority with respect to solution context. As Figure 1 illustrates, collaboration is required, and the level of this collaboration depends heavily on the level of coupling between the solution and its environment.
To ensure this alignment, the customer should participate in Program Increment (PI) Planning (and Pre- and Post-PI Planning where applicable) and Solution Demos as frequently as possible. In addition, the customer should regularly integrate the solution in the customer’s own context. This regular cadence of interaction and integration allows for building solution increments based on correct assumptions and provides validation of the result within the customer’s environment. Both sides play a role in adapting the context to achieve the best economic result (see the Economic Framework chapter).
The customer’s context drives requirements and puts constraints on design and implementation decisions. Many of these contextual requirements are non-negotiable (often driven by Compliance concerns) and may render the solution unusable if not included. These requirements fall under the fixed category of the solution intent. Many aspects of the solution context surface as NFRs and need to be included as part of the Definition of Done for a solution increment.
The solution context may also stipulate specific content that the solution intent must address. In a hierarchical system of systems, the system intents may be hierarchically dependent (see the ‘System of Systems Intent’ section in the Solution Intent chapter). The system context defines how the solution intent must be organized, packaged, and integrated for use by the customer to meet any compliance, certification, and other objectives.
Some solution contexts are established customer environments that the solution must simply fit into (e.g., ‘This is the way our system works; you have to fit in right here’). In that case, all solution context requirements are imposed on the solution via the solution intent.
In many other cases, new solutions may require the evolution of the customer’s deployment environment, requiring those changes to be tracked. In such a case, it’s important to actively track those changes, as both the system and the deployment environment must evolve to a common state. Fixed versus variable thinking and the preservation of options via multiple potentially viable solution contexts (see the ‘Moving from Variable to Fixed Solution Intent’ section in the Solution Intent chapter) are tools to manage risk in these circumstances. Simply put, a more variable and evolving solution context requires more continuous collaboration.
Understanding the customer’s solution context helps determine how the customer’s system will be packaged and deployed in its ultimate operating environments. Examples of solution contexts might include environments such as the following:
System of systems (e.g., avionics system as part of the aircraft), product suite (e.g., word processor as part of an office suite)
IT deployment environments (e.g., cloud environment where the solution is deployed)
Single solution used in different usage models (e.g., a single airliner that can fly both domestic and international routes economically)
The solution supplier-to-customer relationship in large system-of-systems contexts is a unique and cascading thing, as Figure 2 shows.
Each organization in the supply chain delivers its solution to the customer’s context, which specifies how the solution is packaged, deployed, and integrated. That customer, in turn, provides a solution in context to its own customer, and so on. In Figure 2, for example, a vehicle navigation system supplier operates first in the infotainment supplier’s contexts, then in the vehicle manufacturer’s context, and finally in the consumer’s context. All these contexts can impact the viability of the solution, so one must be aware of the full end-to-end value chain.
When developing software solutions for internal use, the customer may be internal, but delivering solutions into the production environment still requires context. The deployment must consider specific interfaces, deployed operating systems, firewalls, APIs to other applications, hosted or cloud infrastructure, and other factors, as Figure 3 shows.
Making deployment as routine as possible is the primary purpose of DevOps and the Continuous Delivery Pipeline.
In the example shown in Figure 3, the new customer relationship management (CRM) system should reflect the required interfaces, as well as how the application is packaged, released, hosted, and managed in the end environment.
There is one final consideration. Generally, the products and services of an Enterprise must work together to accomplish the larger objectives of the solution. Therefore, most solutions do not stand alone; they are also a Portfolio Level concern. Thus, emerging initiatives, typically in the form of portfolio Epics, drive solution intent and impact the solution’s development and deployment.
For internally hosted systems, interoperability with other solutions is often required, further extending the solution context. For example, larger operational value streams (see the Value Streams chapter) often use solutions from multiple development value streams, as illustrated in Figure 4. Each of those subject solutions must collaborate and integrate with the others to provide the operational value stream with a seamless, end-to-end solution.
Ensuring that a solution will operate correctly in its context and deployed environment requires continuous feedback (see the Continuous Delivery Pipeline chapter). Cadence-based development frequently integrates the entire system-of-systems solution to demonstrate progress toward the top-level context’s Milestone and release commitments. Continuous collaboration helps ensure that the solution can be deployed in the ultimate customer’s context:
The customer raises and discusses context issues during PI planning and solution demos.
Solution Management and the customer continually ensure that the vision, solution intent, Roadmap, and Solution Backlog align with the solution context.
Issues discovered in the customer’s context are run through the Solution Kanban system to determine their impact and resolution.
The partners understand and share relevant solution context knowledge, environment, and infrastructure, such as interface mockups, test and integration environments, and test and deployment scripts.
Solution Architect/Engineering ensures technical alignment with the solution context—interfaces, constraints, and other aspects of the system.
Consequently, there are many collaboration points between the development teams and the various roles within the customer organization. Several SAFe roles carry that responsibility along with their customer counterparts, as shown in Figure 5.
In summary, effective collaboration between customer and SAFe roles helps ensure that the system meets the customer’s needs in the customer’s context.
