I was completing a self-retrospective after delivering the SAFe Lean Portfolio Management course and part of that was the satisfaction I felt that the students had obtained the LPM Competency with the wealth of information and a set of practices and techniques to implement LPM. I then turned my attention to preparations to deliver SAFe for Architects (S4Arch). With Enterprise Architect role as a significant course component of S4Arch, I realized there was not a clear view of how the artifacts in LPM would be used as the Enterprise, Solution and System architects perform their roles.
How would those LPM students use their new knowledge to interact with the enterprises/organizations they were returning to? Taking this a step further, I wondered how I would connect these two courses if a participant took both courses?
This problem took me back to a recent engagement where the creation of a Solution Intent Concept of Operations was needed to move the understanding of Solution Intent from concept to operational model. To describe a Concept of Operations for the SAFe Solution Intent we have to start with some foundation – a Domain Model. The Solution Intent domain model I am using is adopted from IBM ELM tools that is based on SAFe guidelines and Model-Based System Engineering practices. This domain model will be used as a guide for the all artifacts created for the SAFe Portfolio, Large Solution and/or Agile Release Trains.
The Solution Intent domain model contains
- System Specification Artifacts
- Architecture and Systems Engineering Artifacts
- Lean-Agile Artifacts
- Verification and Validation Artifacts
- Relationships between these artifacts between the desired state and the known current set of artifacts and practices.
The Solution Intent Domain Model consists of the four domains with three primary relationships. All of these will be described in detail in the following sections. The System Specification artifacts will drive the creation and update of Architecture & Design artifacts. The Lean-Agile artifacts are created to implement the System Specifications in alignment with the Architecture and Design artifacts. The Verification and Validation artifacts are created to validate the System Specifications as they are implemented by the Lean-Agile artifacts.
Another aspect of the domain model is how they act while the Solution Intent is progressing from Variable to Fixed and representing Current state and Future State of the Solution. We need to reconcile these sets. To do so, we note the following:
- The Enterprise Specifications, Design and Architecture and Validation Artifacts are persistent artifacts. These artifacts delivery system compliance requirements.
- The lean-agile artifacts are transient, in that they are created to describe the work that moves the Solution Intent from Variable to Fixed and move the Solution from the Future state to the Current state.
With those foundational concepts I will move onto the question of LPM artifacts in the Solution Intent. As a thought exercise, we will begin with the Lean Portfolio artifacts and Portfolio Epics in the Portfolio Kanban Funnel – and thread up through various artifacts, and how follow-on artifacts and concurrent artifacts arise. Along the way, we will uncover a “Definition of Ready” that encompasses both the Lean-Agile and the System Specification artifacts.
First, I will start with the allocation of the artifacts that were generated in the Strategy and Investment exercises (Lesson 3) that form the basis of how a Portfolio will generate value/profits for the enterprise. The result is a set of Epics that are identified and in the Funnel state of the Portfolio Kanban. The key used in all future graphics will be new artifacts identified in RED.
A notation that Enterprise Architects will already be engaged at this point with identification of missing architecture elements in the Solution Vision and the necessary Enabler Epics.
The following slide show demonstrates how artifacts are created and matured through the Portfolio Kanban stages of a SINGLE EPIC resulting in the movement from a Future State vision to a Current State that supports the Enterprise Strategy through Strategic Themes (OKRs.) This is a representative set of artifacts to communicate the process with the specifics to be determined for each Portfolio. A single enterprise may have different compliance requirements in each portfolio which would drive differences in each Solution Intent.
I will highlight the Done State for the Epic – the Lean-Agile Artifacts are Closed and have been removed as they are no longer relevant. The Enterprise Specification, Design and Architecture and Verification/Validation artifacts representing the Current Solution Intent.
I am requesting your thoughts and questions to mature and refine this ConOps as well as your interest in other aspects to elaborate in future blogs.
Enterprise Agility 