EA-SEMANTICS-LAYERED-KNOWLEDGE-001

Geschichtetes Wissens-Model#

Grundsatz#

Wissen folgt derselben Abstraktionshierarchie wie Architektur.

Wissen existiert unabhängig von der Architekturebene, auf der es betrachtet wird. Wissensartefakte besitzen jedoch eine Gültigkeitsebene und einen Scope. Die Ebene beschreibt, wie allgemein eine Aussage trägt und welche nachgelagerten Ebenen sie spezialisieren dürfen.

• Enterprise-Wissen gilt universell und lösungsübergreifend.
• Solution-Wissen gilt für einen bestimmten Lösungsraum.
• Solution-Design-Wissen gilt für konkrete Anwendungen, Komponenten oder interne Realisierungsstrukturen.
• Engineering-Wissen gilt für Materialisierung, Build, Test, Deployment, Verification und Evidence-Erzeugung.
• Execution-Wissen beschreibt konkrete Ausführung, beobachtete Ereignisse und die daraus entstandene ⌘EvidenceTechnical documentation artifact..

Niedrigere Ebenen dürfen Wissen der höheren Ebene spezialisieren. Sie dürfen dessen Semantik nicht stillschweigend neu definieren.

Wissen als Architekturartefakt#

Architekturwissen ist kein losgelöster Dokumentationstext. Es besitzt wie andere Architekturartefakte:

• eine stabile Identity,
• ⌘MeaningBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen.,
• einen fachlichen Scope,
• Beziehungen zu anderem Wissen und zu Artifacts,
• ⌘ProvenanceProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung.,
• Version und Historie,
• Review- und Freigabestatus,
• gegebenenfalls mehrere lokalisierte Repräsentationen.

Markdown, HTML, UI-Hilfe, Reports oder Publikationen sind mögliche Materialisierungen dieses Wissens. Sie erzeugen keine voneinander unabhängigen Wahrheiten.

Fachliche Heimat und Spezialisierung#

Jedes dauerhaft relevante Wissenselement besitzt eine fachliche Heimat auf der höchsten Ebene, auf der seine Aussage vollständig und korrekt gilt.

Beispiele:

• Ein universelles Architekturprinzip gehört in die Enterprise Architecture.
• Die Anwendung dieses Prinzips auf die multilinguale Engineering-Plattform gehört in die Solution Architecture.
• Die Realisierung durch eine Workbench-Komponente gehört in das Solution Design.
• Eine Erkenntnis über Build- oder Deployment-Verhalten gehört in den Engineering-Scope.
• Eine Beobachtung aus einem konkreten Lauf gehört zunächst zur Execution und Evidence.

Eine nachgelagerte Ebene referenziert und spezialisiert die führende Aussage. Unnötige Kopien sind zu vermeiden, weil sie konkurrierende Wahrheiten und unklare Gültigkeit erzeugen.

Knowledge Evolution#

Wissen entsteht und stabilisiert sich durch einen kontrollierten Kreislauf:

Semantic Model
                    ↓
                Execution Context
                    ↓
                Execution und Events
                    ↓
                Evidence
                    ↓
                Auswertung und Learning
                    ↓
                Konsolidierung in der fachlichen Heimat
                    ↓
                verfeinertes semantisches Modell

Evidence ist noch kein dauerhaftes allgemeines Wissen. Erst die Auswertung bestimmt, ob eine Beobachtung:

• nur für die konkrete Execution gilt,
• als wiederkehrendes Engineering ⌘FindingTechnical documentation artifact. festgehalten wird,
• eine Solution-weite Erkenntnis bildet,
• oder als universelles Enterprise Learning konsolidiert werden kann.

Nicht jede Beobachtung verändert die Architektur. Nicht jedes Learning gilt auf derselben Ebene wie seine Quelle.

Arbeitswissen und dauerhaftes Wissen#

Notizen, Skizzen, Analysen, Reports und andere Arbeitsartefakte dürfen frei entstehen. Sie sind notwendige Mittel für Erkenntnis und Entscheidung, aber nicht automatisch führende Wissensquellen.

Dauerhaft relevante Ergebnisse werden:

1. geprüft,
2. ihrem Gültigkeitsscope zugeordnet,
3. in die fachliche Heimat zurückgeführt,
4. mit Herkunft und Evidence verbunden,
5. dort konsolidiert und versioniert.

Der semantische Verbesserungszyklus vermehrt Wissen deshalb nicht unkontrolliert. Er verbessert bevorzugt bestehende Wissensartefakte und Relationships.

Learning Nuggets#

Learning Nuggets verwenden dieselbe Grundstruktur, werden jedoch entsprechend ihrer Ebene spezialisiert.

Enterprise Learning Nugget#

Universell gültige Erkenntnis, unabhängig von einer konkreten Solution.

Beantwortet:

Warum ist das grundsätzlich so?

Solution Learning Nugget#

Lösungsweite Erkenntnis für einen bestimmten Lösungsraum.

Beantwortet:

Warum gilt oder realisiert diese Solution das so?

Solution Design Learning Nugget#

Komponenten- oder applikationsweite Erkenntnis.

Beantwortet:

Warum ist diese Component oder Application so gestaltet?

Engineering Learning Nugget#

Erkenntnis zu Materialisierung, Build, Test, Verification, Deployment oder Evidence-Erzeugung.

Beantwortet:

Warum muss Engineering in diesem Zusammenhang so vorgehen?

Execution Learning#

Aus konkreter Execution und Evidence abgeleitete Erkenntnis. Sie bleibt zunächst an den beobachteten Context gebunden.

Erst durch Prüfung und Konsolidierung kann daraus ein Engineering-, Solution- oder Enterprise-Learning-Nugget entstehen.

Weitere Wissensartefakte#

Das Ebenenprinzip gilt ebenso für:

• Principles,
• Glossary Entries,
• Findings,
• Architecture Decisions,
• Requirements,
• Help Contexts,
• Documentation,
• Capabilities und ihre Erläuterungen,
• Knowledge Stories,
• Knowledge Patterns,
• Knowledge Reports und Publikationsartefakte.

Diese Artefakte erfüllen unterschiedliche Aufgaben. Eine konkrete Erfahrung ist keine allgemeine Regel; ein Report ist keine neue fachliche Wahrheit; eine Publikation ist keine zweite Architekturquelle.

Beziehungen zwischen Wissen und Architektur#

Relationships machen die Herkunft, Gültigkeit und Verwendung von Wissen nachvollziehbar. Wissensartefakte können unter anderem:

• Begriffe defines,
• Artifacts oder Meanings explains,
• auf Evidence refers-to,
• ein Beispiel example-for bilden,
• voneinander depends-on,
• eine allgemeinere Aussage specializes,
• die Herkunft über source-of abbilden.

Das verbindliche Relationship-Vokabular wird nicht in diesem Modell neu definiert. Dieses Modell beschreibt, warum typisierte Beziehungen für geschichtetes Wissen notwendig sind.

Mehrsprachigkeit#

Menschen müssen mit der Systemlandschaft vollständig in ihrer unterstützten Sprache arbeiten und lernen können.

Daher gilt:

• stabile IDs und Reason Codes werden nicht übersetzt,
• menschlich lesbare Texte, Erklärungen, Hilfen und Learning-Inhalte müssen lokalisiert werden,
• alle Sprachfassungen referenzieren dieselbe semantische Identity,
• Originalsprache und Provenance bleiben erhalten,
• Übersetzungen erweitern die Repräsentation und ersetzen nicht die Quelle,
• Übersetzung darf die Bedeutung nicht stillschweigend verändern.

Konsistenzregeln#

1. Jedes dauerhaft geführte Wissensartefakt besitzt einen erkennbaren Scope.
2. Universelles Wissen wird nicht in einer Solution neu definiert.
3. Execution und Evidence werden nicht ungeprüft als allgemeingültiges Learning behandelt.
4. Arbeits- und Publikationsartefakte werden nicht zu konkurrierenden fachlichen Wahrheiten.
5. Relevante Erkenntnisse werden in ihre fachliche Heimat zurückgeführt.
6. Sprachfassungen teilen dieselbe semantische Identity.
7. Provenance und Beziehungen müssen die Herleitung einer Aussage nachvollziehbar machen.