ARCH-FOUNDATION-WISSENSARCHITEKTUR-GRUNDLAGEN

Wissensarchitektur der Netzwerksolution – Grundlagen#

Eine gemeinsame Wissensbasis für Menschen, Rollen und Systeme.

Arbeitsstand

Dieses Dokument wird kapitelweise gemeinsam neu geschrieben. Die ⌘VisionEine Vision beschreibt eine langfristig gewünschte Wirkung und gibt der Weiterentwicklung eine gemeinsame Richtung., die Präambel, die Grundbegriffe, die Dokumentationsphilosophie und die vollständige Zielgliederung sind verbindlich gesichert. Noch nicht gemeinsam ausgearbeitete Kapitel sind ausdrücklich als Arbeitsauftrag gekennzeichnet. Der frühere englische Resttext wurde entfernt und ist keine fachliche Grundlage mehr.

Dokumentauftrag#

Dieses Grundlagenpapier erklärt die Erfahrungsbasis, Sprache und tragenden Grundsätze der Wissensarchitektur. Es schafft Verständnis und begründet die Architektur, ersetzt jedoch keine normativen Detailkonzepte, Domain Models oder ADRs.

Nicht Bestandteil#

Verbindliche Detailregeln zu UAM, ⌘MeaningBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen., ⌘CapabilityEine Capability beschreibt ein dauerhaft benötigtes fachliches Leistungsvermögen, nicht dessen technische Umsetzung., ⌘RelationshipEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext. Types, Persistenz oder ⌘MetamodellEin Metamodell beschreibt die zulässigen Kategorien, Eigenschaften und Beziehungen, mit denen Wissen modelliert wird. stehen in den jeweils verlinkten Konzepten, Domain Models und ADRs. Dieses Dokument fasst diese Inhalte nur soweit zusammen, wie es für das gemeinsame Verständnis der Wissensarchitektur erforderlich ist.

Die Vision#

Stell dir eine Organisation vor,

in der Wissen nicht mehr in Dokumenten verloren geht.

In der jedes Wissenselement genau eine fachliche Heimat besitzt.

In der Menschen in ihrer eigenen Sprache sowie in ihrem fachlichen und kulturellen Kontext arbeiten können.

In der unterschiedliche Werkzeuge genutzt werden dürfen, ohne dass dadurch mehrere widersprüchliche Wahrheiten entstehen.

In der Wissen von allen beteiligten Menschen erweitert, geschärft und gemeinsam verstanden werden kann.

In der klar unterschieden wird zwischen dauerhaftem Wissen, temporären Arbeitsartefakten und zielgruppengerechten Publikationen.

In der Zusammenarbeit nicht durch Hierarchien, Anwendungen oder Dokumentformate bestimmt wird, sondern durch gemeinsames Verständnis.

In der dieselbe fachliche Wahrheit von der Reinigungskraft bis zum CIO sichtbar sein kann – jeweils in dem Kontext und in der Tiefe, die für die eigene Aufgabe erforderlich sind.

Genau diese Wissensarchitektur beschreibt dieses Dokument.

Leitbild

Die Netzwerksolution schafft eine gemeinsame Wissensbasis, auf der Menschen und Systeme unabhängig von Werkzeugen, Rollen, Sprachen und Organisationsstrukturen zusammenarbeiten können.

1. Präambel#

Die Idee der Netzwerksolution entstand nicht am Reißbrett. Sie entstand aus mehr als 25 Jahren Arbeit als Projektleiter, Agile Coach, Berater, Entwickler sowie Solution- und Enterprise-Architekt in sehr unterschiedlichen Unternehmen.

Unabhängig von Branche, Größe oder Organisationsform zeigte sich immer wieder ein ähnliches Bild: Unternehmen besitzen Hierarchien, unterschiedliche Wissensmanagement-Werkzeuge, unterschiedliche Arbeitsweisen, unterschiedliche Denkweisen und unterschiedliche Ziele. Mitarbeitende, Zulieferer und Beratende verwenden für dieselben Problemstellungen verschiedene Vorgehensweisen, Dokumentationsformen und Strukturen. In multinationalen Unternehmen kommen Sprachbarrieren und kulturell unterschiedliche Arten hinzu, mit Problemen, Verantwortung und Zusammenarbeit umzugehen.

Das Problem ist dabei nicht, dass Organisationen verschiedene Werkzeuge verwenden. LeanIX, Sparx Enterprise Architect, WordPress, Confluence, Jira, Notes, Dateien, Datenbanken und zukünftige Systeme dürfen nebeneinander bestehen. Menschen arbeiten unterschiedlich und benötigen Werkzeuge, die zu ihrer Aufgabe passen.

Problematisch wird es, wenn dasselbe fachliche Wissen an mehreren Stellen unabhängig gepflegt wird. Dann entstehen mehrere Wahrheiten. Dokumente laufen auseinander. Übersetzungen ersetzen unbemerkt das Original. Arbeitskopien werden zu vermeintlich verbindlichen Quellen. Marketing, Entwicklung, Betrieb und Management kommunizieren unterschiedliche Stände desselben Sachverhalts.

Grundsatz

Das Problem ist nicht, dass Wissen an vielen Orten sichtbar ist. Das Problem beginnt, wenn es an vielen Orten unabhängig gepflegt wird.

Die Netzwerksolution soll deshalb nicht alle Werkzeuge durch ein einziges Werkzeug ersetzen. Sie schafft eine gemeinsame Wissensbasis oberhalb der Werkzeuge. Ein Wissenselement besitzt genau eine fachliche Heimat. Es kann in unterschiedlichen Systemen, Sprachen, Rollen- und Nutzungskontexten repräsentiert werden. Diese Repräsentationen müssen jedoch auf dieselbe fachliche Identität und Bedeutung zurückgeführt werden können.

Wissen entsteht außerdem nicht nur in Architekturteams, Wikis oder Datenbanken. Es entsteht im Handeln der Menschen. Mitarbeitende kennen die Gründe, warum ein Prozess tatsächlich anders abläuft als dokumentiert. Sie wissen, wo Übergaben scheitern, welche Abkürzungen notwendig sind, welche Begriffe missverstanden werden und welche Entscheidungen aus früheren Erfahrungen entstanden sind. Dieses Wissen muss sichtbar, diskutierbar und weiterentwickelbar werden.

Zusammenarbeit beginnt deshalb nicht mit einem Prozessmodell oder einem neuen Werkzeug. Sie beginnt mit gemeinsamem Verständnis.

Architekturprinzip

Wissen darf von allen beteiligten Menschen erweitert und geschärft werden. Seine fachliche Identität und seine fachliche Heimat bleiben dabei eindeutig.

Transparenz ist ein wesentlicher Teil dieses Verständnisses. Nicht jeder Mensch benötigt dieselbe Detailtiefe. Aber jeder Mensch soll den für seine Aufgabe relevanten Teil verstehen können. Dieselbe fachliche Wahrheit kann einer Reinigungskraft ein erkennbares Risikosignal geben und einem CIO die Grundlage für eine Entscheidung liefern. Unterschiedlich sind Rolle, Kontext und Tiefe – nicht die zugrunde liegende Wahrheit.

Menschen arbeiten am besten in ihrem eigenen sprachlichen und fachlichen Kontext. Dabei ist nicht nur die Muttersprache wichtig. Ein Entwickler, eine Köchin, ein Controller, eine Architektin oder ein externer Partner verwenden jeweils eigene Fachbegriffe, Sichtweisen und Erwartungen. Die Wissensarchitektur muss diese Vielfalt ermöglichen, ohne die gemeinsame Bedeutung aufzugeben.

Daten, Dokumente, Diagramme, APIs und Anwendungen bleiben wichtig. Sie sind jedoch nicht das Wissen selbst. Sie sind Träger und technische Repräsentationen von Wissen.

Grundsatz der Wissensarchitektur

Daten sind Träger von Wissen, aber nicht das Wissen selbst.

Dieses Dokument beschreibt daher nicht zuerst die Software der Netzwerksolution. Es beschreibt die Wissensarchitektur, aus der sich ihre Softwarearchitektur ableitet.

2. Warum die Netzwerksolution existiert#

Wiederkehrende Beobachtungen statt theoretischer Überlegungen#

Die Netzwerksolution entstand nicht am Reißbrett und nicht aus der Idee, ein weiteres Architektur- oder Wissensmanagementwerkzeug zu entwickeln.

Ihre Grundlagen entstanden aus mehr als 25 Jahren praktischer Arbeit als Projektleiter, Agile Coach, Softwareentwickler sowie Solution- und Enterprise Architect in Unternehmen unterschiedlichster Größe und Branchen.

In dieser Zeit wurden zahlreiche Organisationen, Projekte und Transformationen begleitet. Jedes Unternehmen verfügte über eigene Strukturen, Werkzeuge, Dokumentationsformen und Arbeitsweisen. Auf den ersten Blick unterschieden sich diese Unternehmen erheblich. Mit zunehmender Erfahrung wurde jedoch deutlich, dass sich hinter den unterschiedlichen Werkzeugen und Organisationsformen immer dieselben grundlegenden Herausforderungen verbargen.

Nicht die Werkzeuge waren das eigentliche Problem. Nicht die Dokumente. Nicht die Modellierungssprache.

Das eigentliche Problem war der Umgang mit Wissen.

Die hier beschriebenen Architekturprinzipien wurden nicht theoretisch entwickelt. Sie entstanden aus wiederkehrenden Beobachtungen unterschiedlichster Unternehmen und wurden über viele Jahre hinweg bestätigt, hinterfragt und weiterentwickelt.

Wissen statt Dokumente#

Während nahezu jedes Unternehmen über umfangreiche Dokumentationen verfügte, zeigte sich immer wieder dieselbe Beobachtung: Nicht die Menge der Dokumente entschied über den Projekterfolg. Entscheidend war, ob alle Beteiligten dieselbe fachliche Wahrheit verstanden.

Aus dieser Erkenntnis entstand einer der wichtigsten Grundsätze der Netzwerksolution:

Die Netzwerksolution verwaltet keine Dokumente. Sie organisiert Wissen.

Dokumente bleiben wichtig. Sie dienen der Kommunikation und Veröffentlichung. Ihre Aufgabe besteht jedoch darin, Wissen zu repräsentieren – nicht dessen fachliche Heimat zu bilden.

Wissen entsteht gemeinsam#

Wissen entsteht in Gesprächen, Projekten und gemeinsamen Erfahrungen. Jeder Mensch erweitert das gemeinsame Verständnis einer Organisation. Wissensmanagement bedeutet deshalb, gemeinsames Verständnis entstehen zu lassen, dauerhaft zu erhalten und kontinuierlich weiterzuentwickeln.

Eine fachliche Wahrheit#

Von jedem Wissenselement existiert genau eine fachliche Wahrheit. Alle anderen Darstellungen sind Repräsentationen dieser Wahrheit. Gute Zusammenarbeit entsteht dadurch, dass alle Beteiligten über dieselbe fachliche Wahrheit sprechen – unabhängig davon, welches Werkzeug sie verwenden.

Wissen kennt keine Hierarchie#

Eine funktionierende Wissensarchitektur richtet sich an alle Beteiligten einer Organisation. Je transparenter der aktuelle Wissensstand sichtbar wird, desto leichter können Zusammenhänge verstanden, Probleme erkannt und Entscheidungen gemeinsam getroffen werden.

Menschen arbeiten am besten in ihrer eigenen Sprache#

Die Netzwerksolution betrachtet Sprache als Bestandteil des fachlichen Kontextes. Originalinformationen bleiben dauerhaft erhalten. Übersetzungen erweitern das Wissen, ersetzen jedoch niemals das Original.

Motivation der Netzwerksolution#

Die Aufgabe der Netzwerksolution besteht darin, Wissen dauerhaft an seiner fachlichen Heimat zu organisieren und von dort aus in unterschiedlichste Werkzeuge, Dokumente und Kommunikationskanäle zu übertragen.

Überleitung#

Wenn Wissen die eigentliche Grundlage einer Organisation bildet, stellt sich unmittelbar die nächste Frage:

Was ist Wissen überhaupt?

3. Wissen in der Netzwerksolution#

Vom Dokument zum Wissen#

Nach vielen Jahren in unterschiedlichsten Unternehmen stellte sich immer wieder dieselbe Frage: Warum entstehen trotz guter Werkzeuge, sorgfältiger Dokumentation und engagierter Mitarbeiter immer wieder dieselben Missverständnisse?

Zu einer fachlichen Fragestellung existierten oft zahlreiche Dokumente. Fachkonzepte, Architekturdiagramme, Präsentationen oder Schulungsunterlagen beschrieben denselben Sachverhalt – und doch unterschieden sie sich. Mit jeder zusätzlichen Kopie entstand ungewollt eine weitere Wahrheit.

Irgendwann wurde deutlich, dass das eigentliche Problem nicht in den Dokumenten lag. Das Problem bestand darin, dass Dokumente und Wissen unbewusst gleichgesetzt wurden.

Wissen lebt unabhängig von seiner Darstellung#

Ein Dokument kann Wissen beschreiben, erklären oder veröffentlichen. Es ist jedoch niemals das Wissen selbst. Die eigentliche fachliche Wahrheit kann deshalb nicht in einem einzelnen Dokument liegen.

Wissen besitzt eine fachliche Heimat. Dokumente besitzen sie nicht.

Wissen verändert sich#

Wissen entwickelt sich ständig weiter. Neue Erfahrungen erweitern bestehendes Wissen, Diskussionen schärfen Begriffe, Übersetzungen machen Wissen weiteren Menschen zugänglich. Die Aufgabe der Wissensarchitektur besteht darin, diese Kontinuität sicherzustellen.

Wissen entsteht im Zusammenhang#

Erst das Zusammenspiel von Identität, Bedeutung, Kontext, Beziehungen und Fähigkeiten macht aus Informationen ein Wissenselement. Die Netzwerksolution betrachtet Wissen deshalb immer als fachliches Ganzes.

Zwei Grundelemente und zwei Artefaktfamilien#

Das Unified ⌘ArtifactEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. Model definiert zwei universelle Grundelemente: Artifact und Relationship. Innerhalb der Artifacts unterscheidet die aktuelle Modellversion die Arbeitsfamilien Artifact und Meaning.

Die Familie Artifact beschreibt handfeste oder konkret behandelbare Elemente der Lösung. Meaning beschreibt Bedeutung, Begründung, Leistungsvermögen, Zielzustände, Lücken oder gesicherte Erfahrungen. Relationships beschreiben die fachlich bedeutsamen Zusammenhänge zwischen allen Artefakten.

Die aktuell bestätigte Einordnung umfasst ⌘Building BlockEin Building Block ist ein abgegrenzter Baustein mit stabiler Verantwortung zur Realisierung von Capabilities., Component, Container, Use Case, Documentation Structure, Domain Model, Scenario und Constraint als Artifacts sowie Capability, Vision, ⌘PlateauEin Plateau ist ein zeitlich eingeordneter, freigegebener Reife- oder Materialisierungsstand., Gap, Knowledge Story, Architecture Decision, Glossary Term, Principle, Risk und Requirement als Meanings. Weitere Typen werden erst in einer späteren Modellversion eingeordnet.

Eine besondere interne Struktur rechtfertigt kein weiteres grundlegendes Modellierungselement. Eine Documentation Structure kann deshalb als Artefakttyp einen umfangreichen Baum, Kapitel, begrenzten Prosatext und Kompositionsregeln besitzen. Über Relationships bindet sie die fachlichen Artefakte ein, aus denen Betriebs-, GAMP-, arc42-, Release- oder andere Dokumentationen entstehen.

Die zugrunde liegende Praxiserfahrung ist in ◈Ein Text für Architektur, Betrieb und ReleasePraxiserfahrung zur gemeinsamen Wissensquelle für Architektur-, Betriebs-, Incident-, Problem- und Release-Dokumentation. gesichert. Die vollständige Ausarbeitung steht in CON-012-UNIFIED-ARTIFACT-MODEL-CORE und CON-013-MEANING.

Das Wissensmodell der Netzwerksolution#

Aus diesen Beobachtungen entstand schrittweise das Wissensmodell der Netzwerksolution. Es bildet die Grundlage sämtlicher Architekturentscheidungen.

Überleitung#

Wenn Wissen unabhängig von Dokumenten existiert und eine eigene fachliche Heimat besitzt, stellt sich unmittelbar die nächste Frage: Wo befindet sich diese fachliche Heimat und wie bleibt sie über unterschiedliche Werkzeuge, Sprachen und Veröffentlichungen hinweg erhalten?

Capability als nachvollziehbarer Übergang zur Lösung#

Meaning erklärt, warum ein Leistungsvermögen bedeutsam ist. Eine Capability beschreibt, was durch das Zusammenwirken der Lösung möglich werden soll. Die konkrete Lösung wird erst durch Architekturentscheidungen festgelegt.

Eine Capability wird deshalb nicht zu einem Building Block, ⌘ServiceEin Service ist eine abgegrenzte bereitgestellte technische oder fachliche Leistung mit klarer Verantwortung. oder anderen Lösungsartefakt umgewandelt. Sie bleibt Meaning. Lösungsartefakte tragen über Relationships zu ihrer Realisierung bei.

Für die erste Anwendung genügt ein einfaches Netz aus fachlicher ⌘HerkunftProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung., Capability und beitragenden Lösungsartefakten. Dieses Netz macht nachvollziehbar, warum Elemente existieren und welchem Leistungsvermögen sie dienen.

Ob eine Capability ausreichend oder vollständig realisiert ist, lässt sich daraus nicht automatisch ableiten. Coverage, Reifegrad, KPI, OKR, Test- und Betriebsnachweise gehören zu einer späteren Bewertungsschicht. Die Wissensarchitektur trennt damit bewusst Nachvollziehbarkeit von Bewertung.

3. Sprache der Wissensarchitektur#

Die SolutionArchitecture unterscheidet bewusst zwischen fachlicher und technischer Sprache. Beide Ebenen sind notwendig; sie dürfen jedoch nicht unbemerkt miteinander vermischt werden.

Fachliche Sprache#

Die fachliche Sprache beschreibt, worüber gesprochen wird und welche Bedeutung ein Sachverhalt besitzt.

Dazu gehören insbesondere:

• Wissen
• Wissenselement
• Identität
• Bedeutung
• Kontext
• Beziehung
• Fähigkeit beziehungsweise Capability
• fachliche Heimat des Wissens
• Arbeitsartefakt
• Publikationsartefakt

Technische Sprache#

Die technische Sprache beschreibt, wie Wissen in einem konkreten System gespeichert, übertragen oder dargestellt wird.

Dazu gehören insbesondere:

• Datensatz
• Tabelle
• Datei
• API
• JSON
• Datenbank
• Connector
• Adapter
• Synchronisation
• technische Quelle
• technisches Zielsystem

Sprachliche Trennung#

Die technischen Begriffe bleiben richtig und notwendig. Das Foundation-Dokument beginnt jedoch auf der fachlichen Ebene und wechselt erst dann zur technischen Sprache, wenn die Umsetzung beschrieben wird.

4. Grundbegriffe#

4.1 Daten#

Daten sind technische Werte. Ohne fachliche Einordnung besitzen sie keine eigenständige Bedeutung.

Beispiel:

status = released

4.2 Information#

Informationen ordnen Daten einem fachlichen Sachverhalt zu.

Beispiel:

Dieses Artefakt besitzt den Status „Released“.

4.3 Wissen#

Wissen entsteht, wenn Informationen mit Identität, Bedeutung, Kontext, Fähigkeiten und Beziehungen verbunden werden. Wissen ist unabhängig von einer einzelnen technischen Repräsentation.

4.4 Wissenselement#

Ein Wissenselement beschreibt einen fachlich identifizierbaren Sachverhalt innerhalb der Wissensarchitektur. Es kann durch unterschiedliche technische Repräsentationen dargestellt werden.

4.5 Fachliche Heimat des Wissens#

Die fachliche Heimat ist der Ort, an dem ein Wissenselement fachlich gepflegt, verantwortet und weiterentwickelt wird.

Die fachliche Heimat ist nicht automatisch eine bestimmte Datenbank oder Anwendung. Ein technisches System kann die Pflege ermöglichen; die fachliche Verantwortung bleibt davon zu unterscheiden.

Architekturprinzip

Jedes dauerhaft relevante Wissenselement besitzt genau eine fachliche Heimat.

4.6 Technische Repräsentation#

Eine technische Repräsentation ist die Darstellung eines Wissenselements in einem konkreten System, Format oder Kanal.

Beispiele sind eine WordPress-Kategorie, ein Jira-Vorgang, ein Sparx-Element, ein LeanIX-Fact-Sheet, eine Datenbankzeile, ein PDF oder eine Webseite.

4.7 Repräsentationsreplikation#

Wissen selbst wird nicht kopiert. Repliziert werden technische Repräsentationen eines Wissenselements.

Architekturprinzip

Replikation erzeugt keine neue fachliche Wahrheit.

4.8 Arbeitsartefakt#

Ein Arbeitsartefakt unterstützt Denken, Zusammenarbeit und vorläufige Abstimmung. Es darf unvollständig, lokal, kreativ und wegwerfbar sein. Dauerhaft relevantes Wissen muss aus dem Arbeitsartefakt in seine fachliche Heimat zurückgeführt werden.

Beispiele sind handschriftliche Notizen, Whiteboards, temporäre Diagramme, Präsentationsentwürfe oder lokale Dokumentkopien.

4.9 Publikationsartefakt#

Ein Publikationsartefakt vermittelt Wissen für eine bestimmte Zielgruppe oder einen bestimmten Kanal. Es darf gekürzt, persönlicher formuliert, visualisiert oder für Suchmaschinen aufbereitet werden. Es besitzt jedoch keine unabhängige fachliche Wahrheit.

Beispiele sind WordPress-Artikel, Newsletter, LinkedIn-Beiträge, Vorträge, PDF-Berichte oder Schulungsunterlagen.

5. Die Bausteine des Wissens#

Die Netzwerksolution beschreibt Wissen durch fünf grundlegende Bausteine:

1. Identität
2. Bedeutung
3. Kontext
4. Beziehungen
5. Fähigkeiten beziehungsweise Capabilities

Diese Bausteine werden in den folgenden Kapiteln einzeln hergeleitet. Sie sind keine voneinander isolierten Datenfelder. Erst ihr Zusammenspiel macht aus Informationen ein fachlich verwendbares Wissenselement.

Merksatz

Identität beschreibt, worüber gesprochen wird. Bedeutung beschreibt, was gemeint ist. Kontext beschreibt, unter welchen Bedingungen es gilt. Beziehungen beschreiben, wie es mit anderem Wissen zusammenhängt. Capabilities beschreiben, was dadurch geleistet werden kann.

6. Capability Model#

Artifacts beschreiben, woraus die Lösung besteht und wie sie sich verhält. Relationships beschreiben ihre Zusammenhänge. Capability ergänzt die Frage, welches fachlich bedeutsame Leistungsvermögen durch ihr Zusammenspiel möglich werden soll.

Grundsatz

Eine Capability ist ein Meaning, das ein fachlich bedeutsames Leistungsvermögen beschreibt und den Übergang vom Begründungsraum zur Lösungsarchitektur bildet.

Eine Capability kann durch unterschiedliche Meanings begründet, gefordert, begrenzt oder informiert werden. Lösungsartefakte tragen über Relationships zu ihrer Realisierung bei. Die Existenz solcher Beziehungen schafft Nachvollziehbarkeit, bewertet aber noch nicht die vollständige Realisierung.

Die fachlichen Heimaten sind:

• CON-013-MEANING für Meaning und die Typzuordnung,
• CON-014-CAPABILITY-MODEL für Definition, Beispiele und Konsistenzregeln,
• CON-009-RELATIONSHIP-TYPE-SYSTEM für das verbindliche Relationship-Vokabular.

7. Zielgliederung und gemeinsamer Arbeitsstand#

Die folgenden Kapitel sind verbindlicher Bestandteil des Foundation-Dokuments. Sie werden kapitelweise gemeinsam ausgearbeitet. Bis zur gemeinsamen Ausarbeitung werden keine alten Übersetzungs- oder Resttexte als Ersatz verwendet.

1. Präambel
2. Warum die Netzwerksolution existiert
3. Sprache der Wissensarchitektur
4. Grundbegriffe
5. Die Bausteine des Wissens
6. Wissen statt Daten
7. Wissen statt Dokumente
8. Identität
9. Bedeutung
10. Kontext
11. Wissen entsteht und wächst durch Kontext
12. Sprachföderation und Originalsprache
13. Beziehungen erzeugen Bedeutung
14. Capability Model
15. Connectoren als Übertragung von Informationen und Bedeutung
16. Adapter Configuration
17. Arbeitsartefakte und Rückführung von Erkenntnissen
18. Knowledge Stories und erfahrungsgetriebene Architekturentwicklung
19. Knowledge Patterns
20. Knowledge Reports und Publikationsartefakte
21. Publication Profiles
22. Architekturwissen und Dokumentationsphilosophie
23. Modellierungshilfe
24. Positive Beispiele
25. Negative Beispiele und typische Fehlmodellierungen
26. Auswirkungen auf Domänenmodell, Building Blocks und Governance
27. Offene Fragen
28. Ausblick auf die Connector Foundation
29. Historie

8. Dokumentationsphilosophie#

Architekturwissen besitzt selbst Identität, Bedeutung, Kontext, Beziehungen und Historie. Die SolutionArchitecture dokumentiert deshalb nicht nur fertige Entscheidungen.

Grundlegende Themen werden, soweit sinnvoll, nach folgendem Muster beschrieben:

1. Ziel
2. Ausgangslage
3. Problem
4. Herleitung
5. Grundsatz
6. Architekturprinzip
7. Architekturentscheidung
8. Modell
9. Positive Beispiele
10. Negative Beispiele und typische Fehlmodellierungen
11. Warum die Fehlmodellierung problematisch ist
12. Auswirkungen
13. Konsequenzen
14. Offene Fragen
15. Historie

Grundsatz, Prinzip und Entscheidung#

Grundsatz bezeichnet eine grundlegende Annahme der Wissensarchitektur.

Architekturprinzip leitet das architektonische Handeln.

Architekturentscheidung dokumentiert eine konkrete Wahl zwischen mehreren möglichen Lösungen.

Diese Begriffe werden nicht synonym verwendet.

Praxisbeispiele#

Grundlegende Architekturkonzepte sollen, soweit möglich, durch anonymisierte Praxisbeispiele erläutert werden. Positive und negative Erfahrungen sind gleichermaßen wertvoll. Eine Fehlentwicklung wird nicht nur benannt; es wird erklärt, weshalb sie plausibel erschien und welche Folgen daraus entstanden.

Leitsatz

Eine gute Geschichte erklärt ein Architekturprinzip besser als zehn Seiten Theorie.

9. Knowledge Lifecycle#

Die Netzwerksolution sichert Erfahrung und entwickelt daraus wiederverwendbares Wissen.

Praxisgeschichte
                        ↓
                Knowledge Story
                        ↓
                Knowledge Pattern
                        ↓
                Architekturprinzip und SolutionArchitecture
                        ↓
                Knowledge Report
                        ↓
                Publikation über ein Publication Profile

Die einzelnen Stufen haben unterschiedliche Aufgaben:

• Die Knowledge Story bewahrt die konkrete Erfahrung.
• Das Knowledge Pattern abstrahiert ein wiederkehrendes Muster.
• Die SolutionArchitecture verankert belastbare Grundsätze, Prinzipien und Entscheidungen.
• Der Knowledge Report bereitet Wissen für eine Zielgruppe auf.
• Das Publication Profile definiert Struktur, Tonalität, Metadaten, Bilder, Diagramme und Kanalregeln.

Nicht jede Story führt zu einem Pattern. Nicht jedes Pattern verändert die Architektur. Nicht jede Architekturentscheidung benötigt eine Publikation.

10. Positive und negative Leitbeispiele#

Eine Wahrheit, viele Repräsentationen#

Positiv: Ein Wissenselement wird an seiner fachlichen Heimat gepflegt. Mehrere Systeme zeigen passende Repräsentationen. Änderungen werden nachvollziehbar zurückgeführt.

Negativ: Mehrere Abteilungen pflegen eigene Fassungen desselben Wissens. Niemand kann verbindlich feststellen, welche Fassung gilt.

Sprache als Kontext#

Positiv: Das Original bleibt erhalten. Übersetzungen erweitern das Wissenselement und werden mit ihrer Herkunft und Originalversion verbunden.

Negativ: Eine Übersetzung überschreibt das Original oder wird ohne Bezug auf ihre Quelle als neue Wahrheit behandelt.

Arbeitsartefakte#

Positiv: Notizen und Skizzen dürfen frei entstehen. Dauerhaft relevante Erkenntnisse werden anschließend geprüft und in ihre fachliche Heimat übernommen.

Negativ: Ein Ausdruck mit handschriftlichen Ergänzungen wird beim Kunden zur verbindlichen Produktzusage, ohne dass die Erkenntnisse zurückgeführt und abgestimmt wurden.

Publikation#

Positiv: Ein WordPress-Artikel wird aus einem Knowledge Report erzeugt und verweist auf denselben fachlichen Stand wie weitere Publikationen.

Negativ: Marketing formuliert Produktfunktionen unabhängig von der Entwicklung und erzeugt dadurch eine zweite Produktwahrheit.

11. Auswirkungen#

Dieses Grundlagenpapier wirkt auf alle nachgelagerten Architekturteile:

• Das Domänenmodell muss Identität, Bedeutung, Kontext, Beziehungen und Capabilities abbilden können.
• Das Dimensionsmodell ist die technische Umsetzung des allgemeinen Kontextmodells.
• Sprache bleibt eine besonders wichtige Dimension, ist jedoch kein separates Wissensmodell.
• Originalinformationen bleiben erhalten; Übersetzungen erweitern und ersetzen nicht.
• Semantische Zuordnungen werden als normale Artefaktbeziehungen modelliert.
• Connectoren übertragen Daten und Informationen zwischen technischen Repräsentationen.
• Adapter Configuration beschreibt die technische Interpretation und Umsetzung.
• Building Blocks implementieren Capabilities und referenzieren die Wissensarchitektur.
• Dokumentation, Reports und Publikationen dürfen keine unabhängigen Wahrheiten erzeugen.
• Governance schützt fachliche Heimat, Historie, Nachvollziehbarkeit und gemeinsame Begriffe.

12. Ausblick#

Nach der gemeinsamen Fertigstellung der noch offenen Kapitel wird Sprint 6B.1 an der Connector Foundation fortgesetzt.

Der nächste fachliche Einstieg ist:

Adapter Configuration als technische Implementierung semantischer Relationships.

Dabei bleibt die Trennung verbindlich:

• Semantische Zuordnungen sind Beziehungen zwischen Wissenselementen.
• Ein eigenes Connector-Mapping-Modell existiert nicht.
• Die technische Beschreibung externer Typen und ihrer Verarbeitung gehört in die Adapter Configuration.

13. Verweise#

• Die Plattformvision ist der vorgelagerte Einstiegspunkt dieses Grundlagenpapiers.
• Wie die Netzwerksolution Wissen versteht
• Knowledge Engineering
• Schreibcharta der Foundation-Dokumente
• Verworfene Architekturkonzepte
• Capability- und Relationship-Konzepte

14. Historie#

• 2026-07-10: Deutscher Titel und neuer Dateiname beschlossen.
• 2026-07-10: Vision, Präambel, Fachsprache, Knowledge Lifecycle, Praxisorientierung sowie positive und negative Beispiele als Grundlage beschlossen.
• 2026-07-10: Alter englischer Resttext entfernt; das Dokument wird kapitelweise vollständig neu geschrieben.
• 2026-07-11: Artifact und Relationship als universelle UAM-Grundelemente präzisiert; Documentation Structure als fachlicher Artefakttyp ergänzt.
• 2026-07-11: Das Arbeitsmodell um die vorläufigen Artefaktfamilien Artifact und Meaning erweitert; die bislang gemeinsam bestätigten Typen eingeordnet.
• 2026-07-11: Capability als semantischen Übergang vom Meaning-Begründungsnetz zur Lösungsarchitektur ausgearbeitet; fachliche Relationship-Semantiken und Konsistenzregeln ergänzt.

Dokumentation folgt dem Reifegrad#

Dokumentation soll Entscheidungen unterstützen. Sie entsteht gemeinsam mit der Architektur und wächst mit dem Wissensstand. Weder möglichst wenig noch möglichst viel Dokumentation ist das Ziel. Ziel ist eine dem aktuellen Reifegrad angemessene Dokumentation.

Semantischer Verbesserungszyklus#

Arbeitsartefakte, Sichten, Analysen und Publikationen dienen nicht der unkontrollierten Vermehrung von Artefakten. Sie unterstützen Erkenntnis und Entscheidung. Relevante Ergebnisse werden anschließend in die fachliche Heimat zurückgeführt und verbessern dort bevorzugt bestehende Artefakte und Relationships. Der vollständige Zusammenhang ist in CON-026-NETZWERKSOLUTION-DOMAIN-THEORY beschrieben.