I see confusion in how the various solution horizons apply in SAFe’s “Guiding investments by horizon” guard rail, so I thought I’d tell a story of how I see it play out in practice using a large scale enterprise platform as the backdrop. This framing is consistent with the original design of the SAFe for Architects course content (I was lead SME on the first course edition), although every enterprise I’ve worked with approaches this conversation differently. Join the discussion on LinkedIn!
Update: I published a post with more explanation and application details on how to use solution horizons effectively.
© Scaled Agile, Inc. Used with permission.
(Setting the stage) You’re considering investing in a large, common platform that is intended to make all new customer journeys and digital apps much faster to build across the board, while being customized for the types of business activities that customers of your unique business environment might need to consume.
(Horizon 3 – Exploring) Your architecture team and business owners start by exploring a variety of different potential platforms, approaches, technologies, etc, eventually selecting two major approaches to prototype within the company. They explore both, do some example implementations of how the platform would interact with new and existing solution assets, and get to a point where they identify one of them is the path to the future. They stop investing in the second one, and decide to move forward “for real” with the first choice.
Note: the decision to move forward and establish an ART is likely a Portfolio Epic that requires LPM approval and establishes the 2 businesses mentioned below using the platform as the MVP.
(Horizon 2 – Emerging) Moving that platform forward, a new small ART is created to be the platform group, while two other ARTs have a team (stream-aligned, collaboration stance) added to each to focus on integrating the platform into each of two businesses. That investment continues for 2-3 PIs, and the platform proves to be quite successful. In the 2nd and 3rd PIs, additional teams are pulled from elsewhere into the platform ART to focus on decommissioning legacy services that are now covered by what the platform does, and a small internal “consulting” service is created as part of that ART to prepare other groups around the company to adopt the platform components, especially those components that are now the “one way” to access the decommissioned capabilities.
Note: At this point, the Epic becomes “done” and the ongoing funding for the platform ART is part of the routine lean budgeting process. Ideally, the platform is generally operating as an internal product.
(Horizon 1 – Investing) After those three PIs, the platform is considered “ready” for general use, and the floodgates are opened for anybody in the company to start using it. The small consulting team focuses on enabling various groups around the company as they adopt the platform, while the platform ART continues to build new capabilities and expand the breadth and depth of the platform. An increasing portion of their work is helping to take new extensions to the platform that one business unit or another as created, generalizing them, and adding them to the shared service library on the platform for broader enterprise reuse. Because of the platform breadth, parts of the company are finding they can build entire new user flows just by aggregating the components on the platform, and the real payoff in terms of business agility is starting to be seen.
Meanwhile (Horizon 0 – Retiring), the teams that worked on decommissioning the services replaced by the first increments of the platform remain in the platform ART, but continue to identify legacy services that can be easily integrated into the platform, building the replacement services, and decommissioning the legacy services they replace. They coordinate closely with the internal consulting group to ensure the company is adopting the replaced services effectively, and they additional provide more focused coordination services to the groups most heavily impacted by the decommissioning to ensure there aren’t any unexpected outages.
(Horizon 3 – Exploring) As the platform gains significant capability, an enterprising tech lead realizes there is an opportunity and uses a hackathon week to organize a team to prototype an external facade and API for the platform. They aggregate existing enterprise components for partner identity and rights management with a new API gateway, filter the list of services based on information-only vs. restricted-data tags, add an open source usage metering service, and wow everybody a week later with their demo of what could be a revenue-generating partner gateway into the platform. The Chief Architect and a couple Business Owners see this in the demo, and takes it immediately into the next Portfolio Sync. The company builds the lean business case, approves the epic, and within the next PI has successfully reviewed the technology choices, performed a data protection pass, and is prototyping the access to real-time consumer offers with three different external partners. It’s expected to move into Horizon 2 in the next PI, and could be a game changer for the company’s ecosystem development efforts.
A few years later…
(Horizon 1 – Extracting) The platform is well-maintained and has great tests, but it’s starting to show its age, and there are newer technologies on the market that are proving even easier to use to aggregate capabilities for a global company. New feature creation on the existing platform reduces, but it’s still maintained carefully and drives significant value through its library of existing services and especially through the API it provides to the external partner ecosystem. The funding of the platform ART deceases to focus largely on supporting internal and external clients, updating the platform as underlying components are upgraded, and monitoring security and risk exposure.
