Magnus HedemarkandGitHub
8174e820e2
Add capability and portfolio mapping, state transitions, operating models, decision rights, stakeholder information, templates, evals, and neighboring-owner routing.\n\nAI-assisted: Jasper orchestrated implementation and verification with OpenCode. Signed-off-by: Magnus Hedemark <magnus919@pm.me>
2.4 KiB
Capability, Value-Stream, and Portfolio Mapping
Use this reference when an enterprise question concerns what the organization does, how value moves, or which applications and information support it.
Map in layers
- Name the outcome or stakeholder need. A capability is an enduring ability, not a project, team, system, or slogan.
- Describe the value stream as a sequence of stakeholder-visible stages that turns a need into an outcome. Keep it outcome-oriented; do not confuse it with an internal process map.
- Decompose capabilities only until owners can assess health and investment. Stop before the map becomes an implementation work breakdown.
- Link each capability to applications, information assets, technology dependencies, owners, consumers, lifecycle status, cost evidence, and known risks.
- Record confidence and provenance for every relationship. A plausible relationship is not observed evidence.
Portfolio questions
For each capability, ask: How important is it to the stated outcome? How differentiated or commodity is it? What is its health and change pressure? Which applications support it, and are they authoritative, duplicative, overlapping, or merely adjacent?
Treat duplication as a hypothesis requiring comparison of scope, users, data authority, lifecycle, integration cost, and contractual constraints. Do not recommend consolidation merely because two systems have similar names. A shared capability may legitimately have multiple implementations when jurisdictions, risk, latency, or customer commitments differ.
Minimum portfolio fields
| Field | Question |
|---|---|
| Capability | What enduring ability is being assessed? |
| Value-stream stage | Which stakeholder-visible outcome stage needs it? |
| Application | Which product or system supports it? |
| Authority | Which system or role owns the authoritative decision/data? |
| Relationship | Supports, consumes, duplicates, constrains, or depends on |
| Health | Evidence of fitness, risk, cost, or change pressure |
| Owner | Accountable business and technology roles |
| Decision | Invest, contain, converge, replace, retain, or investigate |
| Confidence | High, medium, or low with a reason |
Keep application architecture and API contract detail with their specialist owners. This view is for enterprise alignment and investment conversation, not low-level solution design.