Solution Context

Context is the key—from that comes the understanding of everything.

—Kenneth Noland

Solution Context Abstract

The Solution Context identifies critical aspects of the target Solution environment and its impact on usage, installation, operating, support, and even marketing, packaging, and selling. Understanding solution context is critical to value delivery; it impacts development priorities, Capabilities, Features, and Nonfunctional Requirements, and it sets the focus for DevOps and other solution-level functions.

The solution context is often driven by factors that are outside of 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 of finding the fine balance between flexibility and interaction with the environment—an interaction that often crosses internal, Supplier, and Customer organizational boundaries.

Details

Rarely do systems builders build systems for themselves; they build them for other people. This means that system builders do not typically control, nor deeply understand, the 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. In both cases, the Solution Context is integral to the solution efficacy. This adds risk to the process; an understanding of that context is required.

Understanding and aligning the Value Stream’s Solution and Solution Intent with the solution context requires continuous interaction with the Customer stakeholders. 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.

Figure 1. Solution intent and solution context inform each other
Figure 1. Solution intent and solution context inform each other

To ensure this alignment, the Customer should participate in the Pre- and Post-PI Planning meetings 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 that are described in the solution intent. Many of these contextual requirements are nonnegotiable 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 Non-Functional 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 have to 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 environment. 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)

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.

Figure 2. Solution Contexts Wrap in System of Systems
Figure 2. Solution contexts wrap in a system of systems

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 of these contexts have the ability to 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.

Figure 3. Solution context for internal IT deployment

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.

Figure 4. Solutions work together to support the full operational value stream

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 DevOps). Cadence-based development frequently integrates the entire system-of-systems value stream 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 Value Stream Backlog align with the solution context
  • Issues discovered in the Customer’s context run through the Value Stream 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. A number of SAFe roles carry that responsibility along with their Customer counterparts, as shown in Figure 5.

Figure 5. System builder role collaboration with Customer roles
Figure 5. System builder role collaboration with Customer roles

Thereby, effective Customer/system builder collaboration helps ensure that the system meets the Customers’ needs, in their context.


Last update: 31 March 2016