I recently posted an article describing the evolution of a single platform across the various investment horizons. After posting that, I found myself in conversations with a client around how this view maps to the work that’s being done inside the portfolio, and I realized there was an assumption that the Solutions on the solution horizons mapped directly to epics. This post clarifies the nature of this guard rail, and explores how work tends to align to solutions. Join the discussion on LinkedIn!

The second guard rail in SAFe’s set of portfolio guard rails is focused on ensuring you have a healthy mix of solutions in different stages of their lifecycles to protect the longer term viability of your technology platforms. A company that trends too heavily towards older, harder to evolve solutions will find itself trapped by momentum and suffering reduced business agility, while companies overly focused on new, shiny solutions may be over-investing in non-differentiating platforms and failing to reap the rewards of previous investments. The most reliable way to ensure the healthy blend is to regulate the amount of money being spent on solutions in the various lifecycle stages, and SAFe uses an adaptation of the horizons model [1] to represent those investments. This model should be easily understood by business executives familiar with Geoffrey Moore’s work.

Image overlaying work patterns on the SAFe Solution Investment Horizons guard rail

Explaining solution horizons

The key to understanding the solution horizon map is to understand the relationship between 1) business capabilities, 2) solutions, and 3) work that evolves the solutions. This matches closely with the relationship between operational value streams, solutions, and development value streams described here.

Business capabilities provide a common language for how a business actually functions – what it needs to do and how it does those. Business capabilities string together into operational values streams to capture how value is ultimately provided to customers. Every technologist should have a basic understanding of these two elements for their business. Business leaders likely have a deep, intuitive knowledge of these elements, but often need to practice articulating them. Good business architects can create clean, easy-to-understand visuals of these relationships and how they connect across different businesses.

Solutions are the things in a business that implement the business capabilities – the ‘how’ behind the ‘what’. The combination of solution and strategy is what brings clarity to the intent behind investments. Solutions can be defined in whatever way is convenient to the management of a business, but are at their best when they align to (sets of) business capabilities cleanly and have an easily understood identity. Often, these map to platforms. e.g. The capability “manage customer relationship information” is implemented by the solution “Salesforce with custom extensions.”

Work, or more specifically, investment into changing solutions, is what we often see in backlogs and what we track for most of the guard rails. In SAFe, work is generally tracked using epics and features for measuring this guard rail, and the costs associated with those artifacts’ completion becomes the input to validating our investment goals.

The solution horizon investment guard rail specifically looks at the second and third pieces: Show the solutions on a view of the intent for investing against them, and manage that investment using guidelines established in terms of the work to change them.

Intent and application of each horizon

Once the overall map is understood, it’s now possible to describe what to do with each horizon. The following section assumes you’ve already read the content following this image. Also, I find it useful to address the horizons out of order, so I’m doing so here.

Horizon 1: This represents the solutions that are an active, fully-relied-upon part of the the current landscape. They implement important capabilities for the business units and the business would suffer if they were failed. This horizon is sub-divided into two portions to help clarify investment intent.

Horizon 1 – Extracting: Solutions here are well-known, comfortable parts of your landscape. They’ve been around for a long time, and people are familiar with their use, behavior, and failings. They’re starting to show their age, but there isn’t any reason to replace them yet. At the same time, the company doesn’t often invest to build new features and capabilities on top of them, preferring to invest in newer adjacent solutions that are easier to evolve and offer users a more modern experience. Architecturally, many of these solutions have likely evolved to be platforms with clean APIs that are used by other solutions, and often tend to be systems of record for critical business data rather than system of engagement. Changes to these solutions tend to be features to expose new information, maintenance updates because of vendor platform updates, or performance updates to keep up with the scalability needs of a growing business. (Work item example F) The work associated with these platforms tends to be individual features or stories associated with other features. It’s quite possible that there are enabler features active to intentionally migrate aspects of the managed data elsewhere as part of applying a longer-term strangulation pattern.

Horizon 1 – Investing: Solutions here are very similar to the ones described above in “Horizon 1 – Extracting”, but tend to be newer. The majority of new feature development shows up in this horizon, and most of the actively used systems of engagement will live here. The work happening here tends to be quite visible to the business and the company’s customers, and is often seen in system demos across the portfolio. These solutions often experience significant architectural evolution as part of being extended to implement new capabilities, absorbing responsibility from older platforms, and replacing decommissioned systems from horizon 0. (Work item example F) The work associated with these solutions tends to be longer sequences of features or even entire program epics. Portfolio business epics will also drive significant change into these systems as part of launching new businesses, dramatically shifting engagement models, or other substantial changes to how the company engages with its market while attempting to gain the benefits of platform/solution reuse.

Horizon 0 – Retiring: Solutions in horizon 0 tend to one of two categories. First, they represent the oldest solutions in the portfolio that are actively dragging down the speed of technology investment. These need to be carefully intentionally unwoven from the rest of the solution landscape, as they tend to be very brittle after years or decades of service, and yet are foundational to many capabilities in the enterprise. Second, they represent extra systems as a result of M&A activity that lead to multiple systems providing very similar capabilities. It’s important to invest to rationalize these into a single platform to allow for faster, easier change later when the market demands it. (Work item example A) The work in this area is often encapsulated in a portfolio enabler epic focused on migrating a single core platform to new technology (first category) or migrating the data and customization from a range of related systems into the company’s standard system (second example). Often, all integration and rationalization work for a single M&A action will be part of a single epic for ease of tracking.

Horizon 3 – Evaluating: Solutions in horizon 3 represent the explorations the company is doing to figure how what new solutions could provide new, previously unavailable capabilities for the company, or provide significantly better platforms on which to deliver existing capabilities in a way that better supports the company’s strategy. These solutions will typically end up being used for core business activities by a small business unit, but have not been properly integrated into the ecosystem enterprise-wide. (Work item example D) Sometimes, this work is part of a portfolio enabler epic focused on bringing a significant strategic capability to fruition. In this case, the solution is typically horizon 3 for the MVP, and then moves to horizon 2 once the persevere decision is made. (Work item example E) Other times, there are a number of small features being explored in individual ARTs to find better ways of accomplishing local goals. The solutions emerging from those explorations then tend to be “shopped around” by architects or product leaders to see where else they’ll fit before being committed into horizon 2 as new epics. Occasionally, the shopping around results in a realization that the new capability could easily be implemented into existing solutions, and the exploratory solution is stopped instead of going into horizon 2.

Horizon 2 – Emerging: Solutions here have been tested and validated for their feasibility and viability, and need to become sustainable parts of the overall enterprise solution landscape. These new solutions are expected to become horizon 1 solutions in the near future, but require additional work to become ready for that horizon. The work generally falls into one of the following areas: 1) meeting all enterprise security, compliance, and operations requirements, 2) preparing for the scale of supporting multiple businesses, both architecturally (e.g. multi-tenant operation) and performance-wise (e.g. preparing for 1000x concurrent users), 3) decommissioning existing systems that can be absorbed into the new platform as part of ongoing rationalization efforts, 4) preparing an organizational home for the new solution (e.g. create and grow a new ART to house it) and 5) ensuring the operational costs are considered and budgeted into appropriate value streams going forward. (Work item examples B & C) This work tends to be part of either a portfolio enabler epic or a portfolio business epic depending on the immediate applicability of the new solution to various lines of business. Often, this will be the “persevere” portion of an epic that followed a solution out of horizon 3 into horizon 2.

Getting started with this guard rail

Generating the visualization for the guard rail requires some intentional data-gathering, and likely requires collaboration between solution management, business architecture, and enterprise architecture functions in order to have the right breadth of perspective. The key activities are:

  • List and group your business capabilities into meaningful clusters that tend to be realized together by a common implementation.
  • Identify the platforms, services, and/or organizations that implement each cluster. These become your Solutions. Note: This solution list will become very valuable when mapping value streams, identifying ARTs, and mapping investments elsewhere in your portfolio governance. It should be treated as a first-class asset, and should anchor your portfolio canvas.
  • Determine the current horizon categorization for each of your solutions based on the current implementation of the solution.
  • Determine how you’re treating each solution with your investments, and identify gaps between behavior and underlying platform. Note these gaps for when you prioritize your investments in H3, H2, and H0 work. E.g. “We’re investing significantly to add new capabilities to this platform, yet it’s a legacy technology that we should be abandoning in favor of modern, more effective platforms.” -or- “We’re investing quite a bit on this new platform, but we haven’t put the work in to bring it up to enterprise standards, and while we’re going fast, we’re introducing huge amounts of risk”
  • Build the diagram, using different colors for the “gap” solutions so they stand out.
  • If available, identify how much effort has been expended on each solution over the previous 4 PIs. This data can often be captured from your org structure, source control and story/feature linkages if you have your ALM configured with effective traceability. Otherwise, you may have to eyeball collections of features or epics to generate a high-level understanding. If you have a highly component-based org structure (not generally recommended) you can often substitute team cost.
  • Finally, identify as an LPM executive team how much you believe you should be spending on each of the categories, ensure ARTs are considering this in their investments, and manage your selection of epics appropriately to focus energy on the most important gaps/pain points.

[1] Baghai, Mehrdad, and Coley, Steve. The Alchemy of Growth: Practical Insights for Building the Enduring Enterprise. Basic Books, 2000