The Transformation Graph: Connecting Strategy to Execution
Updated: 4 minutes ago
Connecting strategy implementation: Execution in transformation requires a path from as-is to to-be: the Transformation Graph
A product-data capability is delayed. The delivery team understands the technical problem. The program manager sees a milestone at risk. Finance has a forecast for the investment. The business expects a new customer service to become available.
Which customer features now move? Can part of the release proceed? Does the delay extend the cost of operating the legacy platform? Which promised outcomes remain achievable?
The information needed to answer these questions may already exist. Establishing the connections can still require several meetings and another spreadsheet.
In the first article of this series, we examined the shift from repeatedly assembled management reports to maintained transformation information. Article 2 explained how transformation patterns can make experience reusable. This article addresses the connections that allow those practices to work together.
At LINNFOSS, we call that connected structure the Transformation Graph. Its purpose is to help leaders trace business intent through delivery and adoption to evidence of realised value—and understand the consequences when something changes.
What the Transformation Graph connects
A Transformation Graph represents important transformation information as identifiable objects with defined relationships. An objective describes an intended business result. A capability describes an ability the organisation needs. Features describe usable changes, while enablers provide supporting technical or organisational conditions.
These connect to systems, data, dependencies, investment decisions, delivery commitments, accountable owners and evidence. Relationships explain how the parts contribute to one another.
For example, a customer self-service objective may depend on a product-selection capability. A feature enables customers to select suitable products. It requires validated technical data and a selection service. A release commitment includes those elements, with evidence showing that the combined result works under agreed conditions.
This is a management model. It can be represented visually, but it does not require every stakeholder to navigate a large network diagram. Nor does it require a particular database technology. The useful property is that the relationships are explicit, maintained and available for questions about the transformation.
There are established foundations for this thinking. The Open Group describes ArchiMate as a language for analysing and visualising relationships across architecture domains.[1] Its guidance on ArchiMate and TOGAF also describes traceability from goals and capabilities through architecture to implementation work.[2] The Transformation Graph applies connected modelling to the wider management relationship among intent, investment, delivery, adoption and outcomes.
Relationships need a precise meaning
Putting two records next to each other does not establish a dependency. A link labelled “related to” leaves the reader to reconstruct its significance.
Consider a feature connected to a data service. Does the feature require the service before development can begin? Before integration testing? Only before release in a particular market? Could an interim solution satisfy the requirement?
Those differences change the management response.
A useful dependency states what is needed, by whom, under which conditions and by when. It identifies the people who can confirm the commitment and records whether the relationship is agreed or still an assumption.
Other relationships have different meanings. An investment funds work. A decision changes scope. A test validates a requirement. An operational measurement provides evidence about an outcome. Each needs a clear definition.
Without that discipline, a graph can produce an impressive list of affected items while leaving their actual consequences unclear. A connection identifies something to examine; it does not automatically prove that a delay propagates or that a benefit will be lost.
An illustrative example: product selection across two markets
Consider a manufacturer introducing digital product selection in two markets. The intended outcome is that customers can identify suitable products using reliable engineering information, reducing the need for manual assistance in the supported journeys.
The capability depends on several connected deliveries: product data, selection rules, a customer interface, translated content and an operational support arrangement. The business owner agrees the supported product families and acceptance conditions.
During validation, the data team discovers inconsistent units in an attribute used by the selection rules. The issue is recorded against the affected attribute and product families. Those records connect to the selection feature, its tests and the planned release.
The program manager can now identify which commitments require assessment. The engineering owner examines the selection consequences. The data owner defines the correction. The release owner reviews the available options with the business.
One option is to release unaffected families while correcting the others. Another is to postpone the complete capability. Each option is linked to its assumptions, delivery effort, operational implications and expected outcome.
Finance can assess any extension of legacy operation against the relevant cost items. The business owner can assess whether the reduced scope still provides a useful customer service. The graph brings those assessments together; it does not calculate them simply because records are connected.
Once the authorised decision is recorded, the affected scope and release commitments are updated. The earlier baseline remains available, so the next review can establish what changed and why.
After launch, evidence must extend beyond completed development and passed tests. Are customers using the supported selection journeys? Are they obtaining usable results? Has the need for manual assistance changed? Those observations connect back to the original objective, with an agreed measurement period and business owner.
The model can then show both what was delivered and what remains uncertain about its value.
Traceability must work in both directions
Forward traceability begins with intent. For a strategic objective, leaders should be able to identify the capabilities, changes, investments and acceptance evidence required to support it. Gaps reveal where the plan depends on an undefined contribution or an unconfirmed owner.
Reverse traceability begins with the work. For a feature, system change or funding request, teams should be able to explain which capability it supports and why that contribution matters.
Some work protects service continuity, reduces exposure or enables future change. Those are legitimate purposes and need their own rationale. A direct revenue claim should not be forced onto every technical item.
Traceability also needs history. A test result may validate an earlier version of a rule. A decision may have been approved against a scope that has since changed. W3C’s PROV-O provides a standard vocabulary for describing entities, activities and responsible agents, including how information was generated and derived.[3] It offers a foundation for recording where evidence came from and which version it concerns.
Even a complete chain of records does not prove causation. Realised value needs measurement and interpretation, including consideration of other changes that may have influenced the result.
Different views of the same maintained information
The chief executive needs to understand outcomes and investment choices. An architect needs to examine system and data dependencies. A delivery lead needs actionable commitments. A business owner needs readiness, adoption and performance evidence.
Each view should select and explain the information relevant to its audience. The underlying decision, dependency or capability should retain its identity across those views.
For the product-selection example, a leadership view might show the decision between a reduced release and a postponement. An engineering view would show the affected attributes, rules and validation. Finance would see the associated cost assumptions. All three should reference the same approved release decision.
Documents remain useful for communication and formal records. The work changes when preparing a presentation becomes selecting and explaining maintained information, with a dated snapshot of what was known and approved.
The Open Group’s explanation of architecture viewpoints and its distinction between modelling and governance provide useful precedents.[2] A representation helps people understand the situation; decision rights and working routines determine what happens next.
A practical foundation for risk analysis and AI
Defined relationships make targeted checks possible. A release depends on a dataset without an acceptance owner. Several features rely on a service scheduled after their integration tests. An investment has approved scope but no agreed outcome measure.
These checks identify conditions that deserve review. They can support earlier risk identification when the underlying information is current and sufficiently complete.
An AI assistant could use that context to prepare an impact assessment. In the selection example, it could read the issue and confirmed relationships, list affected commitments, retrieve the relevant decisions and draft questions for their owners.
It should distinguish confirmed dependencies from assumptions and state where information is missing. It should also show the records supporting its assessment. Approval of a release change remains with the authorised people.
NIST’s AI RMF Playbook provides context-dependent actions for governing and assessing AI risk.[4] W3C provenance can help describe the evidence trail.[3] Neither guarantees that an AI-generated assessment is correct. Access controls, validation and human accountability remain necessary.
Connected information also needs usable instructions and carefully selected context. Anthropic’s guidance on context engineering discusses curating relevant information, instructions and tools for agents.[5] A graph supplies part of that context; it still needs interpretation and appropriate permissions.
How to start with one decision
1. Choose a question that crosses workstreams
Ask the program manager and a business owner to select a real decision, such as whether a capability is ready for release. Define what an acceptable answer must include: affected scope, dependencies, evidence, options and authority.
2. Connect the minimum necessary records
Identify the objective, capability, features, critical enablers, commitments and evidence needed for that question. Reuse identifiers and records in existing systems. Agree which source is authoritative for each item and who maintains it.
3. Confirm the meaning of each relationship
Review critical dependencies with both sides. Record the required output, timing and acceptance condition. Mark unconfirmed relationships explicitly. Have the responsible business and delivery owners validate the chain in both directions.
4. Test a change and review the result
Use a real change to assess whether the model identifies the relevant owners and commitments. Preserve the approved decision and baseline. Compare the effort to reach an answer, missed consequences and maintenance work with the previous approach. Expand only where the resulting management value justifies the effort.
Keep the connections useful
This approach requires ownership across disciplines. Finance owns its figures, architects maintain relevant architecture, delivery teams maintain commitments and business owners assess adoption and outcomes. The program needs an agreed way to resolve inconsistencies between those sources.
It also requires restraint. Connecting every task to every other object creates maintenance work and misleading precision. Start at the level where relationships change a decision. Protect sensitive information and ensure each view respects the access rights of its audience.
The Transformation Graph is the direction informing our work on LINNFOSS software products and the workbench. The approach described here is a proposed management design; it does not imply that every capability is already implemented or integrated in our products.
At your next review, select one critical feature and trace it in both directions: to the business outcome that justifies it, and to the dependencies and evidence that make it usable. Then change one assumption.
Can the team identify which decisions and commitments need review? That is a practical test of whether your transformation information is connected enough to manage change.
References
The Open Group — The ArchiMate Enterprise Architecture Modeling Language Background on modelling relationships across architecture domains.
The Open Group — How the ArchiMate Language and the TOGAF Standard Complement Each Other Explains modelling, governance, traceability and impact analysis.
W3C — PROV-O: The PROV Ontology A standard vocabulary for provenance, including entities, activities, responsibility and derivation.
NIST — AI RMF Playbook Context-dependent guidance for governing, mapping, measuring and managing AI risks.
Anthropic — Effective context engineering for AI agents Guidance on selecting and maintaining useful context for agents.
Tags:
Comments