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

—Kenneth Noland

Solution Context

Solution Context identifies the critical aspects of the environment in which a solution operates.

It provides an essential understanding of the solution’s requirements, usage, installation, operation, and support. 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 organization’s control that develop the solution. The level of coupling between the solution and its context generally represents an architectural and business challenge: finding the right balance between flexibility and tightly coupled interaction with the environment—interactions that often cross internal, Supplier, and Customer organizational boundaries. Product and Solution Management seek to influence the solution context in ways that benefit both the customer and the enterprise.

Details

Rarely are systems built for one’s use; instead, they are made for others, whether internal operational Value Streams or external customers. This means no single person typically controls or fully understands the full context of the system’s deployment and use. Instead, a method 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, the production environment may differ from the development environment (see the DevOps article). 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 a customer-centric mindset. As Figure 1 illustrates, collaboration is needed. The level of cooperation depends heavily on the level of coupling between the solution and its environment.

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

To ensure this alignment, the customer (or a proxy) should participate in PI Planning (Pre-Plan and Coordinate and Deliver for Solution Trains) and Solution Demos as frequently as possible. As solutions increase in size and complexity, the customer should be increasingly involved in integrating the solution into their often unique and specialized context. Ideally, the customer is aligned with the release cadence of the ART, as cadence-based interaction and integration allow for building solution increments based on correct assumptions and provides validation of the result.

Solution Context Drives the Solution Intent

The customer’s context drives requirements and puts constraints on design and implementation decisions. Many of these contextual requirements are non-negotiable (often caused 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 require specific content that the solution intent must address. In a hierarchical system of systems, its intent may also be hierarchically dependent. 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.

Fixed versus Evolving Solution Context

Some solution contexts are established customer environments the solution must support, such as legacy systems containing critical customer data or older hardware models still in production. In that case, some or all of the previous and current solution context requirements are imposed on the solution via solution intent.

However, in many cases, new solutions may require the evolution of the customer’s deployment environment. The changes must be actively tracked, as the system and deployment environment must evolve to a common state. In this latter case, 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 Solution Intent) are tools to manage risk. Increasing variability and rapidly evolving solution contexts motivate more continuous collaboration.

Types of Solution Contexts

Understanding the customer’s solution context helps determine 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 (ex., avionics system as part of the aircraft), product suite (ex., word processor as part of an office suite)
  • IT deployment environments (ex., cloud environment where the solution is deployed)
  • A single solution used in different usage models (ex., a single airliner that can fly both domestic and international routes economically)

Solution Context for a System of Systems

The solution supplier-to-customer relationship in significant system-of-systems contexts is typically unique and cascading, as Figure 2 shows.

Figure 2. Solution contexts wrap into a system of systems
Figure 2. Solution contexts wrap into 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 context, then in the vehicle manufacturer’s context, and finally in the consumer’s context. All these contexts can impact the solution’s viability, so one must know the entire end-to-end value chain.

Solution Context for IT Deployment Environments

The customer may also be internal when developing software solutions for internal use, 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 so on, as Figure 3 shows.

Figure 3. Solution context for internal IT deployment
Figure 3. Solution context for internal IT deployment

Making deployment as routine as possible is the primary purpose of DevOps and the continuous delivery pipeline.

In this example, the new customer relationship management (CRM) system should reflect the required interfaces and how the application is packaged, released, hosted, and managed in the end environment.

Solution Context Includes Portfolio-Level Concerns

Generally, the products and services of an Enterprise must work together to accomplish the larger objectives of the solution. Therefore, most solutions are also a Portfolio Level concern. As such, emerging initiatives, typically in 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, more significant 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
Figure 4. Solutions work together to support the full operational value stream

Each solution must collaborate and integrate to provide the operational value stream with a seamless, end-to-end solution.

Continuous Collaboration Ensures Deployability

Ensuring a solution will operate correctly in its context, and deployed environment requires continuous feedback (see the Continuous Delivery Pipeline article). 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 Train Backlog align with the solution context
  • Issues discovered in the customer’s context run through the Solution Train Kanban system for impact and resolution
  • Understanding and sharing relevant solution context knowledge, environment, and infrastructure, such as interface mock-ups, test and integration environments, and test and deployment scripts
  • The Solution Architect ensures technical alignment with the solution context—interfaces, constraints, etc.

Consequently, there are many collaboration points between the Agile teams and the various roles within the customer organization. Several SAFe functions carry that responsibility along with their customer counterparts, as shown in Figure 5.

Figure 5. Collaboration between SAFe and customer roles
Figure 5. Collaboration between SAFe and customer roles

Therefore, effective collaboration between customers and SAFe roles helps ensure that the system meets the customers’ needs in their context.

 

Last update: 7 March 2023

 

The information on this page is © 2010-2023 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.

Author