An ability that enables value delivery
A capability is an abstract statement of what a business is able to do, named without reference to how it does it, who owns it, or which system runs it. "Process a refund," "onboard a merchant," "forecastForecastSales & RevenueA revenue forecastView reference → demand": each is a capability, stable even as the team, tool, and process underneath it churn. That stability is the whole point and the whole difficulty. A capability is useful precisely because it outlives its implementation, and it is hard to write because the temptation is always to smuggle the implementation back in.
Capability-based thinking grew out of the enterprise and business architecture communities through the 2000s, where teams needed a way to plan investment that did not break every time the org chart or tech stack changed. The clearest early articulation came from Ulrich Homann at Microsoft in his February 2006 paper A Business-Oriented Foundation for Service Orientation. He defined a business capability as "a particular ability or capacity that a business may possess or exchange to achieve a specific purpose," and stressed that it describes what a business does without explaining how, why, or where.
The idea was formalised by the Business Architecture Guild in its BIZBOK Guide, where the business capability map became the discipline's central artefact: a stable, layered picture of everything an organisation can do, used as a shared reference for strategy, technology, and operating-model decisionsDecisionStrategyA recorded decision with context, rationale, and consequencesView reference →. Practitioners began calling it the "Rosetta Stone" of business and IT alignment, because a capability name means the same thing to a strategist and an engineer.
A second lineage runs through Simon Wardley's mapping work, which placed capabilities on an evolution axis from genesis to custom-built to product to commodity, and on a visibility axis from invisible infrastructure to user-facing anchor. Wardley's contribution was to argue that the same capability should be managed differently depending on how evolved it is. A genesis capability deserves exploration; a commodity capability deserves outsourcing. The contemporary view holds both: a capability is a stable noun for what you can do, and its maturity and evolution are properties you track over time.
A logistics startup maps its capabilities before its next funding round. One leaf reads "real-time shipment tracking," rated at maturity developing with a target of managed, and placed at visibility 0.8 because customers see it directly. Beneath it sits "geospatial event ingestion" at visibility 0.2, the infrastructure no customer names but everything depends on.
The map changes the investment conversation. A competitorCompetitorMarket IntelligenceA competing product or companyView reference → analysis shows three rivals already offer tracking as a commodity, so the team stops trying to differentiate there and instead invests in a genesis-stage capability, predictive delay alerts, where no competitor has anything. The capability frame let them separate "what we do" from "how well the market already does it," and route money to the genesis edge instead of polishing a commodity.
In the Unified Product Graph, capabilityevolution_stage, visibility) alongside a maturity model (maturity_level, target_maturity, gap). It is enabled from above by strategic_pillar_enables_capabilitystrategic_theme_requires_capabilitycapability_implemented_by_featurecapability_enables_value_streamcapability_depends_on_capability
Type-specific fields on BaseNode
maturity_levelstringCurrent maturity
target_maturitystringTarget maturity
gapstringGap between current and target
evolution_stagestringWardley evolution axis: where this capability sits on the genesis → custom → product → commodity spectrum. Used by frameworks like `wardley-map`; generally useful as a maturity-of-the-domain signal independent of `maturity_level` (which measures the team's internal capability practice). @example "product"
visibilitynumberPosition on the visibility axis from `0.0` (deepest dependency, infra the user never sees) to `1.0` (user-visible anchor). Used by `wardley-map` for the y-axis position of each capability in the value chain. @example 0.8
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
4 phases — initial: planned
10 edge types connected to this entity.
strategic_pillar_enables_capabilitycapability_depends_on_capabilityneed_fulfilled_by_capabilitycapability_depends_on_capabilitycapability_implemented_by_featurecompetitor_offers_capabilityproduct_develops_capabilitycapability_enables_value_streamcapability_enables_value_propositionstrategic_theme_requires_capability4 frameworks use this entity type.