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

—Kenneth Noland

Solution Context

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 heavily influences opportunities and constraints for releasing 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. 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 own use; instead, they are built for others, whether they 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 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. In this case, the production environment may not be the same as 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 required. The level of collaboration depends heavily on the level of coupling between the solution and its environment.

Figure 1. Solution intent and context inform each other

To ensure this alignment, the customer, or customer proxy, should participate in Program Increment (PI) Planning (and Pre- and Post-PI Planning where applicable) 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/or specialized context. Ideally, the customer is aligned with the release cadence of the ART, as cadence-based interaction and integration allows 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 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. 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 that the solution must simply support, such as legacy systems containing critical customer data or older models of hardware that are still in production. In that case, some or all of the previous and or 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 both 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/or 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)
  • 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 large system-of-systems contexts is typically unique and cascading, as Figure 2 shows.

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 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.

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. The deployment must consider specific interfaces, deployed operating systems, firewalls, APIs to other applications, hosted or cloud infrastructure, etc., as Figure 3 shows.

Figure 3. Solution context for internal IT deployment

Making deployment as routines 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, as well as 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 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 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 Backlog align with the solution context
  • Issues discovered in the customer’s context run through the Solution 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
  • Solution Architect/Engineering ensures technical alignment with 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 roles carry that responsibility along with their customer counterparts, as shown in Figure 5.

Figure 5. Collaboration between SAFe and customer roles

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

Last update: 10 February 2021

  

The information on this page is © 2010-2024 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.