Business Capabilities

A Business Capability is a stable statement of what the business does — the outcome it can deliver — independent of how it delivers it today. “Order Management”, “Customer Onboarding”, “Financial Reporting” are capabilities. The tools, processes, teams, and applications that make each one work are implementation; they change. The capability itself stays recognizable across reorganizations, vendor swaps, and multi-year transformations.

Capabilities are the spine Albumi uses to translate between business strategy and the application portfolio: they answer “which part of the business would be affected if this application went away” and “what business outcome has no system supporting it at all”.

What a capability is

Three rules settle most naming questions.

Outcome, not activity. A capability names something the business can do, not a task it performs. “Invoice Customers” describes a process step; Billing or Invoicing is the capability. The activity changes (paper, EDI, e-invoicing, real-time); the capability stays.
Stable over years. If the statement would need rewriting every time the operating model, a vendor, or a team changes, it is not a capability. “Use Salesforce for CRM” is not a capability. Customer Relationship Management is.
Business-literate, not IT-literate. The name should be recognizable to a line-of-business leader without translation. “Run Nightly Batch”, “Provision Cloud Tenants”, “Operate the ETL Pipeline” are IT jobs, not business capabilities.

Name capabilities as noun phrases. “Order Management” reads as a capability; “Manage Orders” reads as a process step. Keep names short — two or three words is enough — and avoid verbs, tool names, and organizational acronyms.

Capability versus process

This is the single most common confusion, so it gets its own line: a capability is what; a process is how. “Customer Onboarding” is a capability — the ability to take a new customer from first contact to being able to transact. The sequence of steps (collect identification, run KYC, open account, deliver welcome pack) is a process that realizes it. The same capability can be realized by different processes for different segments, channels, or regions, and those processes can be redesigned without the capability itself changing.

Albumi models capabilities. It does not model processes as a separate entity type. When you catch yourself writing a sequence of steps into a capability name or description, you have crossed the line; rewrite.

Hierarchy

Capabilities form a tree. Each capability has an optional parent; the capabilities with no parent form the top level of the map.

Level 1 is broad business domains — the language an executive would use to describe what the company does. Typical examples: Sales, Finance, Operations, Human Resources, Product Development.
Level 2 breaks each domain into its major capabilities. Under Finance, for example: Accounting, Treasury, Tax, Financial Planning.
Level 3 — and occasionally Level 4 — names specific capabilities inside a Level 2 group. Under Accounting: General Ledger, Accounts Payable, Accounts Receivable, Fixed Asset Accounting.

Useful capability maps live in the two-to-four levels range. Going deeper almost always means the leaf nodes have stopped being capabilities and started being process steps or system functions. Albumi caps the level at 4 for this reason.

Two practical points on structure:

parentId is the edge. The level attribute exists alongside it for filtering and reporting, but the actual parent/child relationship is the parentId pointer.
One parent per capability. Capabilities do not belong to two parts of the tree at once. If a candidate capability seems to sit under two parents, it is almost always two different capabilities that share a name — split them and give each a precise name.

Realization — applications to capabilities

Applications realize the capabilities they support. This is the edge that makes the capability map useful: once applications are linked to capabilities, the capability tree becomes a readout of what the business can do today and with what.

The link is many-to-many:

One capability is typically realized by several applications. “Order Management” may be supported by an order-entry front-end, an ERP, a pricing engine, and a fulfillment system.
One application typically realizes several capabilities. A CRM product realizes Lead Management, Account Management, Opportunity Management, and more.

The edge is owned by the Application side — each application carries the list of capabilities it supports, and that list is edited on the application’s page. The capability’s detail page shows the other direction of the same edge: which applications claim to realize it. To change which applications realize a capability, edit the applications, not the capability.

Data Objects may also carry capability links (a Customer object belongs to Customer Management, an Order object to Order Management). As with applications, the link is edited from the Data Object side.

Coverage and redundancy

Once capabilities and applications are in place, the capability tree becomes the view used to spot two opposite problems.

Gaps — capabilities with no application realizing them. Either the business lacks the capability, or the capability is supported by manual work, spreadsheets, or shadow IT that is not in the portfolio. Both outcomes are worth knowing.
Redundancy — capabilities with many applications realizing them. This is not automatically bad (a single capability may genuinely need several specialized systems), but a capability with five or more applications all claiming to support it is usually a sign of either duplicated investment or of a capability drawn too broadly.

Heat maps and coverage dashboards that summarize this across the whole tree are a reporting feature; this page’s job is to explain the data they read. Your capability tree earns its keep if it makes these two questions answerable at all.

Portfolio attributes

Two optional attributes drive portfolio-level views on capabilities. Both are opinion-based scores set by the capability’s owner — nothing else in the model computes them.

Strategic Importance — how much the business relies on this capability today. High for capabilities the business competes on (losing it materially weakens the organization); Medium for capabilities the business needs to be competent at but not world-class; Low for commodity or regulatory-minimum work. Heatmaps use this to rank where portfolio attention goes first.
Maturity Level — how well the business actually delivers the capability today, on the five-level CMMI scale:
- Initial — ad-hoc. Work gets done but outcomes depend on individuals; no consistent process.
- Developing — some discipline exists, typically within a single team. Not uniformly applied; results vary.
- Defined — a standard way of working is agreed, documented, and followed across teams.
- Managed — outcomes are measured (lead times, error rates, throughput) and the measurements drive decisions.
- Optimized — the process is continuously improved from the measurements. Deviation is investigated; feedback loops close.
Maturity is not a “push everything to Optimized” target — forcing high maturity on low-importance capabilities is waste. The model exists to reveal mismatches.

Read together, the two attributes give the portfolio its priority list:

High importance × Low maturity — the front-of-agenda items. The business relies on these, and it hurts most from poor delivery.
High importance × High maturity — strongholds. Protect them; keep measuring.
Low importance × High maturity — likely over-invested. Consider redirecting effort.
Low importance × Low maturity — leave alone unless regulation or risk forces a change.

Both attributes are optional. Set them on the capabilities the portfolio conversation covers; leave the rest blank rather than guessing. An unset attribute is treated as “not rated yet” in views and heatmaps.

Ownership and organization

A capability carries one owner (ownerUser) and one organization, and the two answer different questions.

ownerUser — the person accountable for the capability’s description in Albumi. This is the single human who decides what the capability means, what belongs inside it, and when it needs splitting or merging. Ownership is also the governance signal: a non-owner Contributor cannot edit the capability directly and must propose the change. See Permissions & Roles.
organization — the organizational unit the capability is classified under for reporting. A capability is not owned by a business unit in any permission sense; membership in the classifying organization grants no rights on the capability. Organization is there so you can filter, group, and report “capabilities relevant to Finance” — not to control who can edit them.

Every capability has an organization — if nothing more specific applies, it sits under the workspace root organization. ownerUser may be unset.

A common trap: do not use organization to model who operates the capability today. That belongs on the applications (and on the teams behind them), not on the capability itself. The capability is supposed to outlast the current organizational chart.

Status

Business Capabilities do not follow the five-stage dated lifecycle that Applications, Integrations, and IT Components use. A capability is something the business has or does not have, not something that is provisioned and retired on dates. Its status is a simple field with four values, set manually.

Draft — the capability is being defined and is not yet part of the current map. Use this while a capability is proposed but not yet confirmed as something the business actually has or intends to have.
Active — the capability is part of the current map. Applications realize it; reports count it.
Planned — the capability is not in the current map yet, but the business intends to introduce it. Useful for future-state capabilities that anchor roadmap conversations before any application is in place.
Deprecated — the capability is no longer part of the current map. Kept for historical reference and for incoming references from older data; not assigned to new work.

There is no enforced ordering or automatic transition between these values. Move a capability from Draft to Active when the business confirms it; from Active to Deprecated when it has been merged, split, renamed, or genuinely retired from the map; delete it only if it was a mistake in the first place.

Common modeling mistakes

Mapping the capability tree to the organization chart. Capabilities are the organization-independent view — they exist to be stable across reorganizations. If your Level 1 looks exactly like your current Chief-of-X layout (“Marketing Department Capabilities”, “Finance Department Capabilities”), you are modeling reporting lines twice. Use the Organization entity for who reports to whom; keep the capability map in business-outcome language.
Describing processes instead of outcomes. “Run Monthly Close”, “Process Payroll on the 15th”, “Onboard New Hires in Two Weeks” are processes. The capabilities are Financial Close, Payroll, Employee Onboarding. If a capability statement includes verbs, time boxes, or steps, rewrite it as a noun phrase naming the outcome.
Capability trees deeper than four levels. Every additional level exponentially multiplies nodes and cuts the signal-to-noise of the map. By Level 5, the leaves are almost always either process steps or features of a specific application. Keep the map to 2–4 levels; push the rest into the application description or into a separate process catalog outside Albumi.
Copying a reference framework wholesale. Industry reference maps (BIAN for banking, APQC for cross-industry process, the common insurance or telco capability maps) are useful starting points, not deliverables. Dropping a 300-node reference tree into the workspace unchanged produces a map nobody owns, full of capabilities the business does not actually describe that way. Use a reference framework to seed the top two levels, then rewrite in the language the business uses and trim everything that does not map to real applications or real decisions.
One application per capability as a goal. A clean 1:1 mapping looks neat but is rarely accurate and, when it is enforced, it pushes people to duplicate applications in the model to make the picture tidy. Capabilities and applications are separate concerns and the many-to-many edge between them is the truth; do not try to make it one-to-one.
Using organization as access control. Organization is classification. A user in the same organization as a capability has no special rights on it. Edit rights come from ownership and explicit entity grants; see Permissions & Roles.

Entities Overview — the entity map and how capabilities fit into it
Applications — the realization edge is owned here
Data Objects — data concepts the business works with, also linkable to capabilities
Organizations — why organization is classification, not governance
Permissions & Roles — how ownership drives edit rights