ADR-013

ADR-013 – Capability-Verankerung und semantische Governance#

Status#

Accepted

Context#

Die historische Gesamtarchitektur enthält eine ausgereifte Capability-Theorie und Regeln zur Bewahrung von Wissen. Im getrennten Enterprise-Repository waren ⌘CapabilityEine Capability beschreibt ein dauerhaft benötigtes fachliches Leistungsvermögen, nicht dessen technische Umsetzung. Model, Principles, Governance und Glossar bisher nur teilweise materialisiert. Ohne gemeinsame Regeln könnten Capabilities aus vorhandenen Components abgeleitet, Relationships zu generisch modelliert oder historische Bedeutungen bei Migrationen stillschweigend verändert werden.

Decision#

1. Capability ist ein ⌘MeaningBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen. und beschreibt ein fachlich bedeutsames Leistungsvermögen.
2. Jede Capability benötigt nachvollziehbare ⌘HerkunftProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung. aus mindestens einem Meaning.
3. Capability ist weder ⌘Building BlockEin Building Block ist ein abgegrenzter Baustein mit stabiler Verantwortung zur Realisierung von Capabilities., Component, ⌘ServiceEin Service ist eine abgegrenzte bereitgestellte technische oder fachliche Leistung mit klarer Verantwortung., API, Rolle noch Permission.
4. Capability Realization ist grundsätzlich viele-zu-viele.
5. Einzelne Artifacts tragen über contributes-to bei; in Gegenrichtung kann is-realized-by verwendet werden.
6. Meaning-zu-Capability-Beziehungen werden mindestens als justifies, requires, constrains, informs, refines oder conflicts-with unterscheidbar gemacht.
7. Capabilities können sich spezialisieren, voneinander abhängen oder aus Teilfähigkeiten bestehen.
8. Solutions spezialisieren Enterprise Capabilities, ohne deren universelle Bedeutung neu zu definieren.
9. Historische Architektur wird aussagenorientiert und semantisch migriert, nicht strukturell kopiert.
10. Identische Aussagen dürfen dedupliziert, zusätzliche Aussagen müssen konsolidiert und Widersprüche müssen sichtbar gemacht werden.
11. Begriffe besitzen eine fachliche Heimat und durchlaufen einen expliziten Terminologielebenszyklus.
12. Arbeitstitel werden nicht als stabile Terminologie behandelt.
13. Fehlende Dateien in einem Paket sind keine impliziten Löschaufträge.

Consequences#

• Capability-Dokumentation benötigt Meaning-Herkunft und Realisierungsbeziehungen.
• Reference- und Solution-Building-Block-Mappings werden nachvollziehbar statt besitzorientiert modelliert.
• Governance, Glossar und semantische Migration verwenden gemeinsame Preservation-Regeln.
• Automatisierte Werkzeuge und KI dürfen fachliche Konflikte nicht verdeckt entscheiden.
• Capability Coverage, KPI, Reifegrad und Runtime-Verfügbarkeit bleiben getrennte Bewertungsmodelle.

Related Architecture#

• ◆Capability ModelDefiniert Capability als Meaning, ihre fachliche Herkunft, Beziehungen, Spezialisierung und Realisierung. – decides
• Capability Governance – decides
• Semantic Migration Governance – decides
• ◆Capability Grounding PrincipleJede Capability benötigt fachliche Herkunft und nachvollziehbare Realisierung. – related-to