A product through its lifecycle
The question people ask: what problem is this product solving, for whom, what did we decide, what is built and tested, and is it delivering the value we said it would?
What feeds the graph: the problem statement, interviews and journeys, requirements, architecture decisions, the API and event contracts, test reports, deployment records, and the KPI reviews. Most of it exists already, in six different tools, and none of it is connected.
The six phases, one graph
| Phase | What enters the graph |
|---|---|
| Envision | the problem statement, the opportunity, the stakeholders, the outcome and its target |
| Discover | personas, journeys, use cases, requirements including the non-functional ones, policies |
| Design | bounded contexts, the context map, the system design, the decisions, APIs and events, upstream and downstream systems |
| Build | components, integrations, agents, tests and test data, the gates a release passes |
| Operate | deployments, incidents, runbooks, what changed in production and when |
| Realize | the KPIs and OKRs, the value realised against the target, the go-forward decision |
Each phase mints its own nodes, and the traceability runs the whole way: an outcome is realised by a journey, a journey by use cases, a use case by requirements, a requirement by components, a component by tests. When the target is missed, the graph says which link is missing.
An internal tool is a product
A platform team's deployment tool, a data team's report factory, an operations team's intake portal: each has users, journeys, requirements, decisions and a value it was built to deliver. Treating them as products with the same graph is what makes the mesh answer across the company rather than only across the products it sells.
Studio
The front page shows each phase in Studio for one product of a sample insurer: the problem statement with its sources, a journey told as an arc, the architecture of the Design phase with its contexts, decisions, components and stack, the acceptance tests, and the value realised. Studio is the face; the graph underneath is an oto project per product.
How it is used
- The product owner asks which requirements have no test, and which outcome has no journey that realises it.
- The architect records a decision once; the spec skill reads it into the next design instead of re-deciding it.
- The sponsor reads the Realize phase: the value against the target, rolled up from the graph, with the source of every number.
The commands and the skills
The product-delivery ontology is in preparation; until it is in the catalog, the software-architecture and organization-process ontologies merged cover Design, Build and Operate:
oto init --name "Report Factory" --ontology software-architecture,organization-process --project factory
Skills: build-knowledge-base, spec, evaluate. The report automation example is the first pack built on it.