Netzwerksolution Documentation Report

EA-METAMODEL-ONTOLOGY-001

Kernontologie der Unternehmensarchitektur#

Enterprise Solution Engineering Runtime Beziehung: derived-from; Pfeilrichtung: EA-METAMODEL-ONTOLOGY-001 → EA-DOMAIN-ABSTRACTION-001derived-from Beziehung: constrained-by; Pfeilrichtung: EA-METAMODEL-ONTOLOGY-001 → PRINCIPLE-TYPED-RELATIONSHIPSconstrained-by Beziehung: related-to; Pfeilrichtung: EA-METAMODEL-ONTOLOGY-001 → EA-METAMODEL-EXECUTION-001related-to Beziehung: related-to; Pfeilrichtung: EA-METAMODEL-ONTOLOGY-001 → EA-SEMANTICS-LAYERED-KNOWLEDGE-001related-to Beziehung: decided-by; Pfeilrichtung: EA-METAMODEL-ONTOLOGY-001 → ADR-012decided-by Beziehung: derived-from; Pfeilrichtung: PRINCIPLE-TYPED-RELATIONSHIPS → EA-METAMODEL-ONTOLOGY-001derived-from Beziehung: realized-through; Pfeilrichtung: EA-DOMAIN-ABSTRACTION-001 → EA-METAMODEL-ONTOLOGY-001realized-through Beziehung: derived-from; Pfeilrichtung: EA-METAMODEL-EXECUTION-001 → EA-METAMODEL-ONTOLOGY-001derived-from Beziehung: derived-from; Pfeilrichtung: EA-RELATIONSHIP-TYPE-CATALOG-001 → EA-METAMODEL-ONTOLOGY-001derived-from Beziehung: derived-from; Pfeilrichtung: EA-SE-0039-MEANING-KONSOLIDIERUNG → EA-METAMODEL-ONTOLOGY-001derived-from Beziehung: decides; Pfeilrichtung: ADR-012 → EA-METAMODEL-ONTOLOGY-001decides Beziehung: derived-from; Pfeilrichtung: GLOSSARY-ENTERPRISE-CORE → EA-METAMODEL-ONTOLOGY-001derived-from Beziehung: specializes; Pfeilrichtung: SA-ENTERPRISE-SPECIALIZATION-001 → EA-METAMODEL-ONTOLOGY-001specializes Unternehmensabstraktion und Lösungsspezialisierung — Bedeutung (meaning) · EnterpriseBedeutung (meaning)Unternehmensabstraktionund Lösungsspezialisie… Prinzip typisierter Relationships — Bedeutung (meaning) · EnterpriseBedeutung (meaning)Prinzip typisierterRelationships Execution-Kontext- und Ereignis-Model — Kontext & zeitliche Einordnung (context-time) · EnterpriseKontext & zeitliche Einordnung (context-time)Execution-Kontext- undEreignis-Model Geschichtetes Wissens-Model — Bedeutung (meaning) · EnterpriseBedeutung (meaning)GeschichtetesWissens-Model ADR-012 – Universelle Enterprise-Ontologie und Execution-Theorie — Bedeutung (meaning) · EnterpriseBedeutung (meaning)ADR-012 – UniverselleEnterprise-Ontologie u… Katalog der Beziehungstypen der Unternehmensarchitektur — Beziehung (relationship) · EnterpriseBeziehung (relationship)Katalog derBeziehungstypen der Un… SE-0039 — Meaning-Konsolidierung — Bedeutung (meaning) · EnterpriseBedeutung (meaning)SE-0039 —Meaning-Konsolidierung Kernbegriffe der Unternehmensarchitektur — Bedeutung (meaning) · EnterpriseBedeutung (meaning)Kernbegriffe derUnternehmensarchitektur Enterprise Theory Specialization — Bedeutung (meaning) · SolutionBedeutung (meaning)Enterprise TheorySpecialization Beziehung der zweiten Ebene: constrained-by; Pfeilrichtung: EA-KNOWLEDGE-GRAPH-001 → PRINCIPLE-TYPED-RELATIONSHIPSconstrained-by Beziehung der zweiten Ebene: liefert Praxiserfahrung für die Unterscheidung von Zustandsinstanzen, Events und Snapshots; Pfeilrichtung: KS-0008 → EA-METAMODEL-EXECUTION-001liefert Praxiserfahru… Beziehung der zweiten Ebene: derived-from; Pfeilrichtung: EA-LN-EXP-002 → EA-SEMANTICS-LAYERED-KNOWLEDGE-001derived-from Beziehung der zweiten Ebene: derived-from; Pfeilrichtung: OBSERVABILITY-BY-DESIGN → EA-METAMODEL-EXECUTION-001derived-from Beziehung der zweiten Ebene: realized-through; Pfeilrichtung: PRINCIPLE-TYPED-RELATIONSHIPS → EA-KNOWLEDGE-GRAPH-001realized-through Beziehung der zweiten Ebene: related-to; Pfeilrichtung: PRINCIPLE-TYPED-RELATIONSHIPS → EA-CAPABILITY-MODEL-001related-to Beziehung der zweiten Ebene: realized-through; Pfeilrichtung: EA-DOMAIN-ABSTRACTION-001 → EA-CAPABILITY-MODEL-001realized-through Beziehung der zweiten Ebene: constrained-by; Pfeilrichtung: EA-DOMAIN-ABSTRACTION-001 → PRINCIPLE-ARCHITECTURE-DERIVATIONconstrained-by Beziehung der zweiten Ebene: constrained-by; Pfeilrichtung: EA-METAMODEL-EXECUTION-001 → OBSERVABILITY-BY-DESIGNconstrained-by Beziehung der zweiten Ebene: realized-through; Pfeilrichtung: EA-METAMODEL-EXECUTION-001 → EXECUTION-EVIDENCE-MODELrealized-through Beziehung der zweiten Ebene: produces-evidence-for; Pfeilrichtung: EA-METAMODEL-EXECUTION-001 → RP-KNOWLEDGE-EVOLUTIONproduces-evidence-for Beziehung der zweiten Ebene: related-to; Pfeilrichtung: EA-SE-0039-MEANING-KONSOLIDIERUNG → EA-CAPABILITY-MODEL-001related-to Beziehung der zweiten Ebene: derived-from; Pfeilrichtung: EA-SEMANTICS-EKEL-001 → EA-SEMANTICS-LAYERED-KNOWLEDGE-001derived-from Beziehung der zweiten Ebene: uses; Pfeilrichtung: EA-HISTORICAL-CURRENT-VALIDITY-NETWORK-001 → EA-RELATIONSHIP-TYPE-CATALOG-001uses Beziehung der zweiten Ebene: constrained-by; Pfeilrichtung: EA-TEMPORAL-CONTEXT-001 → EA-SEMANTICS-LAYERED-KNOWLEDGE-001constrained-by Beziehung der zweiten Ebene: derived-from; Pfeilrichtung: EXECUTION-EVIDENCE-MODEL → EA-METAMODEL-EXECUTION-001derived-from Beziehung der zweiten Ebene: derived-from; Pfeilrichtung: EA-REF-MODEL-EXPLAINABILITY-001 → EA-METAMODEL-EXECUTION-001derived-from Beziehung der zweiten Ebene: specializes; Pfeilrichtung: KNOWLEDGE-REFERENCE-MODEL → EA-SEMANTICS-LAYERED-KNOWLEDGE-001specializes Beziehung der zweiten Ebene: materializes; Pfeilrichtung: RP-KNOWLEDGE-EVOLUTION → EA-SEMANTICS-LAYERED-KNOWLEDGE-001materializes Beziehung der zweiten Ebene: derived-from; Pfeilrichtung: GOVERNANCE-TERMINOLOGY-LIFECYCLE → EA-SEMANTICS-LAYERED-KNOWLEDGE-001derived-from Beziehung der zweiten Ebene: constrained-by; Pfeilrichtung: EA-PLATEAU-MODEL-001 → EA-SEMANTICS-LAYERED-KNOWLEDGE-001constrained-by Beziehung der zweiten Ebene: related-to; Pfeilrichtung: ADR-011-OBSERVABILITY-BY-DESIGN → EA-METAMODEL-EXECUTION-001related-to Beziehung der zweiten Ebene: uses; Pfeilrichtung: EA-STD-EXTERNE-EVIDENZ-001 → EA-RELATIONSHIP-TYPE-CATALOG-001uses Beziehung der zweiten Ebene: uses; Pfeilrichtung: EA-STD-RELATIONSHIP-LEDGER-001 → EA-RELATIONSHIP-TYPE-CATALOG-001uses Beziehung der zweiten Ebene: derived-from; Pfeilrichtung: GLOSSARY-ENTERPRISE-CORE → EA-CAPABILITY-MODEL-001derived-from Beziehung der zweiten Ebene: governed-by; Pfeilrichtung: GLOSSARY-ENTERPRISE-CORE → GOVERNANCE-TERMINOLOGY-LIFECYCLEgoverned-by Beziehung der zweiten Ebene: derived-from; Pfeilrichtung: GLOSSARY-ENTERPRISE-CORE → EA-REF-MODEL-EXPLAINABILITY-001derived-from Beziehung der zweiten Ebene: derived-from; Pfeilrichtung: GLOSSARY-ENTERPRISE-CORE → EA-REF-MODEL-KNOWLEDGE-LEVEL-LOGGING-001derived-from ADR-011 – Überwachbarkeit by Design — zweite Beziehungsebene, Bedeutung (meaning) · EnterpriseBedeutung (meaning)ADR-011 –Überwachbarkeit by … Enterprise-Capability-Model — zweite Beziehungsebene, Bedeutung (meaning) · EnterpriseBedeutung (meaning)Enterprise-Capability-Model Gültigkeitsnetz für historische und aktuelle Aussagen — zweite Beziehungsebene, Kontext & zeitliche Einordnung (context-time) · EnterpriseKontext & zeitliche Einordnung (context-time)Gültigkeitsnetz fürhistorische und akt… Wissensgraph der Unternehmensarchitektur — zweite Beziehungsebene, Beziehung (relationship) · EnterpriseBeziehung (relationship)Wissensgraph derUnternehmensarchitektur Lokalisierung darf den Grund nicht verändern — zweite Beziehungsebene, Bedeutung (meaning) · EnterpriseBedeutung (meaning)Lokalisierung darfden Grund nicht ver… Plateau-Modell — zweite Beziehungsebene, Kontext & zeitliche Einordnung (context-time) · EnterpriseKontext & zeitliche Einordnung (context-time)Plateau-Modell Erklärbarkeitsreferenzmodell — zweite Beziehungsebene, Bedeutung (meaning) · EnterpriseBedeutung (meaning)Erklärbarkeitsreferenzmodell Wissensebenen-Protokollierungsmodell — zweite Beziehungsebene, Kontext & zeitliche Einordnung (context-time) · EnterpriseKontext & zeitliche Einordnung (context-time)Wissensebenen-Protokollierungsmodell Erklärbarkeits-, Wissens-, Evidence- und Lernstruktur — zweite Beziehungsebene, Bedeutung (meaning) · EnterpriseBedeutung (meaning)Erklärbarkeits-,Wissens-, Evidence-… Externer Evidenzvertrag — zweite Beziehungsebene, Beziehung (relationship) · EnterpriseBeziehung (relationship)ExternerEvidenzvertrag Beziehungsledger — zweite Beziehungsebene, Unklassifiziert (unknown) · Enterprisecontrol (control)Beziehungsledger Zeitlicher Kontext — zweite Beziehungsebene, Kontext & zeitliche Einordnung (context-time) · EnterpriseKontext & zeitliche Einordnung (context-time)Zeitlicher Kontext Engineering-Execution- und Evidence-Modell — zweite Beziehungsebene, Kontext & zeitliche Einordnung (context-time) · EnterpriseKontext & zeitliche Einordnung (context-time)Engineering-Execution-und Evidence-Modell Governance des Terminologie-Lebenszyklus — zweite Beziehungsebene, Unklassifiziert (unknown) · Enterprisecontrol (control)Governance desTerminologie-Lebenszyklus Wissensreferenzmodell — zweite Beziehungsebene, Beziehung (relationship) · EnterpriseBeziehung (relationship)Wissensreferenzmodell KS-0008 – Die Zustandsklassen waren keine Stationen — zweite Beziehungsebene, Bedeutung (meaning) · EnterpriseBedeutung (meaning)KS-0008 – DieZustandsklassen war… Überwachbarkeit by Design — zweite Beziehungsebene, Bedeutung (meaning) · EnterpriseBedeutung (meaning)Überwachbarkeit byDesign Architekturableitungsprinzip — zweite Beziehungsebene, Bedeutung (meaning) · EnterpriseBedeutung (meaning)Architekturableitungsprinzip Wissensevolutionsprozess — zweite Beziehungsebene, Kontext & zeitliche Einordnung (context-time) · EnterpriseKontext & zeitliche Einordnung (context-time)Wissensevolutionsprozess Kernontologie der Unternehmensarchitektur — Bedeutung (meaning) · Enterprise. Strukturkontext öffnen.Bedeutung (meaning)Kernontologie derUnternehmensarchitektur
Übersicht · 2: zweite Ebene · Ziehen/Klicken: navigieren

Zweck#

Dieses Modell extrahiert die universelle Ontologie aus dem historischen Unified Model, ohne dessen solution-spezifische Realisierung zu ersetzen.

Die historische Gesamtarchitektur hat bereits zwischen Elementen unterschieden, die eine Lösung, ihre Struktur oder ihr Verhalten beschreiben, und Elementen, die , Begründung, Ziel, , Erfahrung oder Bewertung ausdrücken. Sie hat Relationships als fachlich bedeutsame Verbindungen zwischen diesen Elementen modelliert.

Die Enterprise Architecture hebt diese bestehende Unterscheidung auf ihre universelle Abstraktionsebene und präzisiert sie als drei gleichrangige fundamentale Familien.

Fundamentale Familien#

Die Enterprise-Ontologie besteht aus:

Meaning
                Artifact
                Relationship

Die drei Familien sind keine technischen Datentypen. Sie sind universelle semantische Kategorien, die von jeder Solution für ihren Lösungsraum spezialisiert werden können.

Meaning#

Meaning beschreibt Bedeutung, Begründung, Ziel, Leistungsvermögen, Erfahrung oder Bewertung.

Meaning beantwortet insbesondere:

Capabilities, Principles, Requirements, Findings, Decisions und Learning können Meaning Types sein.

Capability als Meaning#

Capability beschreibt ein Leistungsvermögen. Sie ist deshalb ein Meaning und kein Bestandteil, oder einer Lösung.

Eine Capability kann auf mehreren Architekturebenen mit unterschiedlichem Scope spezialisiert werden:

Die Familie bleibt gleich; Scope und Spezialisierungsgrad ändern sich.

Ein Artifact kann zu einer Capability beitragen oder sie teilweise realisieren. Es wird dadurch nicht selbst zu dieser Capability.

Artifact
                    contributes to
                Capability

Artifact#

Artifact beschreibt ein konkret identifizierbares und behandelbares Element.

Artifact beantwortet insbesondere:

Building Blocks, Components, Services, Dokumente, UI-Elemente und konkrete fachliche Gegenstände können Artifact Types sein.

Die interne Struktur eines Artifacts wird durch seinen konkreten Typ bestimmt. Unterschiedliche Payloads oder Darstellungsformen begründen keine neue fundamentale Familie.

Ein Artifact kennt nur sich selbst. Aussagen, die ein anderes Element betreffen, werden als Relationships modelliert.

Relationship#

beschreibt einen fachlich relevanten und bedeutungsvollen Zusammenhang zwischen zwei Elementen.

Relationship ist kein bloßer Pfeil, kein Darstellungsdetail und keine Hilfsstruktur. Sie ist eine eigenständige fundamentale Familie und der semantische Klebstoff zwischen Meaning und Artifact sowie zwischen Elementen derselben Familie.

Eine Relationship kann beispielsweise bedeuten:

Wissen entsteht nicht nur aus Elementen, sondern aus ihren bedeutungsvollen Relationships.

Eigenschaften einer Relationship#

Eine Relationship besitzt mindestens:

Relationships können Meaning und Artifact verbinden, Elemente derselben Familie verbinden und später ausdrücklich zugelassene Execution-Elemente einbeziehen.

Das kanonische Vokabular und seine Regeln stehen im . Zeitliche Gültigkeit, Reihenfolge und Evolution werden dort als typisierte Relationships modelliert und nicht in Pfaden, Namen oder unstrukturiertem Freitext verborgen.

Identity#

Identity ist keine vierte Familie. Sie ist eine universelle Eigenschaft von Meaning, Artifact und Relationship.

Identity beantwortet:

Welches Element ist das?

Ein Identifier ist lediglich eine technische Repräsentation dieser Identity. Identifier-Strategien, Formate, Speicher- und Auflösungsmechanismen gehören in die jeweilige Solution und ihr Design.

Gemeinsame universelle Eigenschaften#

Meaning, Artifact und Relationship sind:

Diese Eigenschaften beschreiben die universelle Erwartung. Ihre konkrete technische Realisierung ist Sache der jeweiligen Solution.

Didaktische Abgrenzung#

Beschreibt es Bedeutung, Begründung, Ziel, Leistungsvermögen,
                Erfahrung oder Bewertung?
                → Meaning

                Beschreibt es ein konkret identifizierbares und behandelbares Element?
                → Artifact

                Beschreibt es den fachlich bedeutsamen Zusammenhang zwischen Elementen?
                → Relationship

Diese drei Fragen bilden einen stabilen Einstieg in das Modell. Grenzfälle werden nicht stillschweigend vereinfacht, sondern anhand ihres fachlichen Zwecks geprüft.

Verhältnis zum Unified Artifact Model#

Das historische und solution-spezifische Unified Artifact Model bleibt als Realisierung bestehen. Es konkretisiert, wie eine Solution die Enterprise-Ontologie technisch organisiert, typisiert, persistiert und auflöst.

Die Enterprise-Ontologie ersetzt diese Realisierung nicht. Sie definiert die universelle Theorie, auf die das Unified Artifact Model verweist.

Damit gilt:

Enterprise Ontology
                    defines
                Meaning, Artifact, Relationship and Identity

                Solution Unified Artifact Model
                    realizes
                these concepts for a concrete solution space

Herkunft und Konsolidierung#

Dieses Modell konsolidiert insbesondere die semantischen Kernaussagen aus:

Die historischen Dokumente bleiben Wissensquellen. Ihre universelle Theorie wird hier semantisch normalisiert; solution-spezifische Typ-, Payload-, Persistenz- und Darstellungsentscheidungen verbleiben in der Solution Architecture.