Glossary

Architectural integrity constraint

Also called: integrity constraint

A rule defining what is methodologically valid, beyond what is structurally possible.

A rule defining what is methodologically valid, beyond what is structurally possible. The ten constraints (R1 to R10) are verifiable against the repository and constitute the formal conformance criterion for an implementation.

The distinction between what is structurally possible and what is methodologically valid is what makes the model useful. A database will happily store a process with no objective; the methodology will not, which is why the repository can reject it.

On this site: Executable Architecture →

Related terms

Cardinality

A rule defining how many instances of one object may or must relate to another. It is not a modelling technicality: it encodes business decisions, such as every offering executing exactly one…

Governance by design

The principle that when a methodological rule can be implemented as a native platform control, the control is preferred over the procedure.

Impact matrix

The analysis of which artifacts a change affects, which tests must be repeated and what must be re-approved.

Metamodel

The formal definition of which object types exist in the architecture, how they may relate, with what cardinalities, and which configurations are invalid.

Methodological conformance

A property of an implementation whose repository satisfies the ten integrity constraints.

Referential integrity

The condition ensuring relationships between entities remain valid and free of broken references.

Requestable offering

The condition met when an offering is visible, current, and its process has an operational entry point.