Hierarchical Structure
Architecture principles that provide enterprise design reuse and scale, and separate what the business needs from how it is met.
The rules that make a capability model impossible to fake, and the reason it holds still while everything around it changes.
Organizations are redrawn. Processes are resequenced. Applications are replaced. The ability the enterprise had before the change is still there after it. A capability is the governed statement of that ability, and every principle in this volume exists to keep the statement precise enough to reason over.
A normalized hierarchy keeps every ability in one place. The upper levels align the enterprise; the lower levels separate what the business needs from how that need is functionally met.
Anchors to the industry value chain. Product Management. Claims Management.
Applies across every line of business. Manage Renewals.
What the business needs. Ability to price a product.
How that need is functionally met. Ability to calculate a credit score.
Every business and functional capability is written the same way, so any two statements in the enterprise can be compared, joined, and scored.
The actor is omitted. The ability belongs to the enterprise, not to the role that happens to perform it today.
One statement, one action. A statement carrying several verbs is several abilities that cannot be scored or attributed.
Abstract verbs such as manage and administer belong at the upper levels. Concrete verbs such as calculate, approve, and transmit belong beneath them.
One distinct, irreducible business need per statement, written once and referenced wherever it occurs.
Each ability holds across roles, products, geographies, and channels. If it holds in only one context, it is a requirement.
Verbs are drawn from a governed reference and applied the same way everywhere, which is what makes the model measurable.
Ability to calculate a premium
Ability to transmit a payment
Underwriter calculates a premium
Tied to a role.Ability to auto-default home address on web form
Tied to a solution.The relational model brought set theory to data: one fact in one place, selected by predicate. The same discipline, applied one layer up, treats business capabilities as a normalized set and attributes each one across strategy, operations, and technology.
Which capabilities are performed by an underwriter, on workers' compensation, and carry revenue growth?
The answer is any region of the set, not only the center, and the question never had to be anticipated when the model was written.
Architecture principles that provide enterprise design reuse and scale, and separate what the business needs from how it is met.
Modeling principles, grounded in relational theory and predicate logic, that carry investment decisions from strategy through execution.
Language rules that give the enterprise a shared, measurable definition of itself, level by level and verb by verb.
Relational by discipline. Beyond relational by design.