Context is the key—from that comes the understanding of everything.
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. Solution context also heavily influences opportunities and constraints for Release on Demand.
Understanding 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 do systems builders build systems for their own use; instead they build them for others, whether they be internal operational value streams, or external Customers. This means that system builders do not typically control, and may not always fully understand, the full context for deployment and use. Rather, a system is shipped, deployed, installed, and maintained in an environment that is 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. There, for many reasons, the production environment is not the same as the development environment (See DevOps). In any case, understanding the solution context is integral to reducing risk and achieving fitness for purpose.
Understanding and aligning the Solution and Solution Intent with the solution context requires continuous interaction with the Customer. They understand the Vision and have the requisite decision-making authority with respect to solution context. As Figure 1 illustrates, collaboration is required; its level depends heavily on the level of coupling between the solution and its environment.
To ensure this alignment, the Customer should participate in PI Planning (and Pre- and Post-PI Planning where applicable) and Solution Demos as frequently as possible. And the Customer should regularly integrate the solution in their 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 Economic Framework).
Solution Context Drives the Solution Intent
The Customer’s context drives requirements and constrains design and implementation decisions. Many of these contextual requirements are nonnegotiable (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 Nonfunctional Requirements (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 also be hierarchically dependent (see the “System of Systems Intent” section in Solution Intent). The system context defines how the system builder’s system intent must be organized, packaged, and integrated for use by the Customer to meet any compliance, certification, and other objectives.
Fixed vs. Evolving Solution Contexts
Some solution contexts are established Customer environments that the solution must simply “fit into” (“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 solution intent.
However, in many cases new solutions may require evolution of the Customer’s deployment environment. In that case, the system builders play an active role in tracking those changes, as both the system and deployment environment must evolve to a common state. In this latter case, fixed vs. variable thinking and the preservation of options via multiple potentially viable solution contexts (see the “Moving from Variable to Fixed Solution Intent” section in Solution Intent) are tools to manage risk. Simply, a more variable and evolving solution context requires more continuous collaboration.
Types of Solution Contexts
System builders use the solution context to understand how their system will be packaged and deployed in its ultimate operating environments. Examples of solution contexts might include environments such as:
- System of systems (e.g., avionics system as part of the aircraft), product suite (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)
- There are other contexts as well, and combinations are also possible.
Solution Context for a System of Systems
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 their 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 viability of the solution, so the system builder must be aware of the full end-to-end value chain.
Solution Context for IT Deployment Environments
When developing software solutions for internal use, the Customer may be internal, but delivering solutions into the production environment still requires context. Deployment must consider specific interfaces, deployed OSs, firewalls, APIs to other applications, hosted or cloud infrastructure, etc., as Figure 3 shows. Making deployment as routines as possible is the primary purpose of DevOps and the Continuous Delivery Pipeline.
In this example, the new CRM system should reflect the required interfaces, as well as how the application is packaged, released, hosted, and managed in the end environment.
Solution Context Includes Portfolio-Level Concerns
There is one final consideration. Generally, the products and services of an Enterprise must work together to accomplish the system builder’s larger objective. Therefore, most solutions do not stand alone; they are also a Portfolio Level concern. As such, emerging initiatives, typically in the form of portfolio Epics, also drive solution intent and impact the solution’s development and deployment.
For internally hosted systems, interoperability with other solutions is also often required, further extending the solution context. For example, larger operational value streams (see Value Streams article) often use solutions from multiple development value streams, as Figure 4 illustrates.
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.
Continuous Collaboration Ensures Deployability
Ensuring that a solution will operate correctly in its context requires continuous feedback. Solution builders need feedback that their solution will work properly in the deployed environment (see Continuous Delivery Pipeline). 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 run through the Solution Kanban system for impact and resolution
- System builders and the Customer share relevant context knowledge, environment, and infrastructure, such as interface mock-ups, test and integration environments, test and deployment scripts, etc.
- Solution Architect/Engineering ensures technical alignment with solution context—interfaces, constraints, etc.
Consequently, there are many collaboration points between the system builder and the various roles within the Customer organization. Several SAFe roles carry that responsibility along with their Customer counterparts, as shown in Figure 5.
Thereby, effective Customer/system builder collaboration helps ensure that the system meets the Customers’ needs, in their context.
Last update: 17 June, 2017