Content-Bausteine

Ein Content-Baustein ist eine fachlich eigenständige Wissenseinheit mit stabiler Identität. Im Graphen ist er ein adressierbarer Knoten: Er kann gefunden, verlinkt, in der Struktur verortet und in verschiedenen Perspektiven wiederverwendet werden. Der Baustein steht für genau eine klar beschriebene Bedeutung und erhält dafür einen verbindlichen primären Typ.

• Concept, Method, Tool und Technology sind die vier fachlichen Kern-Wissenstypen.
• Name, Definition, Zweck, Grenzen, Beispiele, Quellen und Beziehungen beschreiben den Baustein.
• Katalog, Explorer, Overview, Learn, Explain und weitere Perspektiven greifen auf dieselbe fachliche Identität zu.
• Die fachliche Identität des Bausteins bleibt in jedem Anzeigekontext erhalten.

Der Content-Baustein trägt das wiederverwendbare Fachwissen. Strukturbausteine geben ihm einen fachlichen Ort. Beziehungen verbinden ihn semantisch mit anderen Knoten. Perspektivdaten ergänzen eine bestimmte Leserichtung, Bewertung oder Handlung. Diese Ebenen arbeiten zusammen und erfüllen jeweils eine eigene Aufgabe.

• Der Content-Baustein beantwortet: Was ist diese fachliche Einheit?
• Die Struktur beantwortet: In welchem Wissensbereich und Themenraum liegt sie?
• Die Relation beantwortet: Wie hängt sie mit einem anderen Baustein zusammen?
• Die Perspektive beantwortet: Wie hilft derselbe Baustein bei einer konkreten Nutzerfrage?
• Definitionen, Beispiele und Quellen gehören als Inhalt zum jeweiligen Content-Baustein.

Die Einordnungsebene beschreibt die fachliche Flughöhe eines Content-Bausteins. Sie ergänzt den Content-Typ: Der Typ erklärt, was ein Baustein ist; die Einordnungsebene erklärt, wie grundlegend, ordnend oder konkret er im größeren Wissenszusammenhang wirkt.

• Grundlage: Wissen, das du verstehen musst, um ein Themenfeld sinnvoll zu denken. Beispiele sind grundlegende Prinzipien, Begriffe und mentale Modelle.
• Struktur: Wissen, das Zusammenhänge ordnet, verbindet oder entscheidbar macht. Beispiele sind Architekturansätze, Ordnungsmodelle und übergreifende Vorgehensrahmen.
• Element: ein konkretes, klar abgrenzbares Rädchen im System, das in größeren Zusammenhängen wirkt. Beispiele sind ein bestimmtes Werkzeug, eine Technologie oder eine ausführbare Methode.
• Die Ebenen bilden keine Qualitäts- oder Reiferangfolge. Sie helfen, Bausteine auf der passenden Flughöhe zu lesen und miteinander zu verbinden.

Ein Concept ist ein dauerhaft nutzbares Denkmodell, Paradigma, Prinzip oder Architekturverständnis. Es schafft Orientierung im Problemraum, erklärt Motivation und Wirkmechanismen und verbindet mehrere mögliche Methoden, Tools und Technologien. Seine Form ist ein Orientierungsrahmen aus Prinzipien, Zusammenhängen und Zielbildern.

• Kernfrage: Welches Modell, Prinzip oder Zielbild hilft, den Problemraum zu verstehen?
• Typische Inhalte: Grundprinzipien, Charakteristika, Varianten, Trade-offs, Systemwirkung und Grenzen.
• Beispiele: Domain-Driven Design, DevOps, CI/CD, Observability, Cloud Computing und Event-Driven Architecture.
• Faustregel: Es könnte als dauerhaftes Kapitel in einem Strategie- oder Architekturbuch bestehen.

Eine Method ist ein strukturiertes Vorgehen, mit dem Menschen eine Aufgabe analysieren, entscheiden oder lösen. Sie kann gelehrt und wiederholt durchgeführt werden und besitzt erkennbare Regeln, Schritte, Phasen oder Schleifen. Häufig verarbeitet sie Inputs und erzeugt Ergebnisse, Entscheidungen oder Artefakte.

• Kernfrage: Wie wird die Aufgabe konkret und nachvollziehbar durchgeführt?
• Typische Inhalte: Ziel, Voraussetzungen, Rollen, Schritte, Inputs, Outputs, Erfolgskriterien und Stolperfallen.
• Beispiele: Event Storming, Incident Management, Root Cause Analysis, Impact Mapping und ATAM.
• Faustregel: Man kann es als Workshop, Technik oder Prozess durchführen und anschließend ein Ergebnis benennen.

Concept und Method liegen häufig nah beieinander, weil eine Methode meist innerhalb eines übergeordneten Denkmodells eingesetzt wird. Die Entscheidung folgt der Bedeutung des Knotens: Ein Orientierungsrahmen wird als Concept modelliert; eine konkrete, wiederholbare Durchführung als Method.

• Domain-Driven Design ist das Concept; Event Storming ist eine dazu passende Method.
• Observability ist das Concept; Incident Review oder Root Cause Analysis sind Methods zur konkreten Untersuchung.
• Product Discovery ist das Concept; Impact Mapping ist eine Method innerhalb dieses Denkrahmens.
• Prinzipien, Zusammenhänge und Zielbilder sprechen für Concept. Schritte, Rollen und Outputs sprechen für Method.

Eine Technology ist ein technischer Standard, ein Protokoll, eine Laufzeitumgebung, ein Framework, eine Infrastrukturkomponente oder eine Plattform. Sie bestimmt, worauf Systeme aufbauen, wie sie ausgeführt oder integriert werden und welche Architektur- und Betriebsfolgen entstehen.

• Kernfrage: Welche technische Grundlage wird implementiert, integriert, betrieben oder als Ausführungsrahmen verwendet?
• Typische Inhalte: technisches Prinzip, Schnittstellen, Standards, Integrationsmechanismen, Laufzeit, Skalierung und Betriebsrisiken.
• Beispiele: REST, OAuth 2.0, Kubernetes, Docker, Neo4j und React.
• Eine Technology kann einen konkreten Namen und Maintainer haben. Entscheidend ist ihre Rolle als technischer Unterbau im System.

Ein Tool ist ein konkretes Werkzeug oder Softwareprodukt, das Menschen aktiv bedienen, um eine Aufgabe zu unterstützen. Es bündelt Funktionen in einer nutzbaren Oberfläche oder Kommandozeile, besitzt Integrationen und gehört meist zu einem Hersteller- oder Produktökosystem.

• Kernfrage: Welches konkrete Arbeitsmittel benutzt eine Person für Analyse, Planung, Entwicklung, Kollaboration oder Betrieb?
• Typische Inhalte: Funktionsumfang, Bedienung, Integrationen, APIs, Rollen, Lizenzmodell, Grenzen und Fehlanwendungen.
• Beispiele: Jira, Miro, Postman, Docker Desktop, Grafana und GitHub Actions.
• Ein Tool unterstützt Arbeitsweisen und nutzt Technologien; seine Hauptrolle ist die direkte operative Benutzung.

Tool und Technology werden leicht verwechselt, weil viele Produkte sowohl eine Bedienoberfläche als auch technische Komponenten besitzen. Nexonoma typisiert nach der fachlichen Rolle, die der Knoten beschreibt: das direkt benutzte Arbeitsmittel ist Tool; der technische Unterbau oder Standard ist Technology.

• REST ist Technology; Postman ist ein Tool zum Entwerfen und Prüfen von APIs.
• Docker ist Technology für containerisierte Ausführung; Docker Desktop ist das direkt bediente Tool für lokale Arbeit.
• OpenTelemetry ist Technology für Telemetrieinstrumentierung und -austausch; Grafana ist ein Tool zur Analyse und Visualisierung.
• Kubernetes ist Technology für Orchestrierung; eine darauf aufsetzende Verwaltungsoberfläche wird als Tool betrachtet.

Ein Begriff kann in der Praxis mehrere Bedeutungen tragen. Nexonoma bestimmt den primären Typ anhand der fachlichen Aussage, die der Knoten dauerhaft repräsentiert. Dieser Typ bleibt über Ansichten und Perspektiven hinweg stabil.

• Kanban kann als dauerhaftes Organisationsprinzip ein Concept bezeichnen; ein konkret beschriebenes Kanban-Vorgehen mit Regeln und Ablauf wird als Method modelliert.
• CI/CD ist in Nexonoma immer ein Concept. Es beschreibt das dauerhafte Liefer- und Automatisierungsmodell; konkrete Pipelines und einzelne Abläufe sind technische Umsetzungen dieses Concepts.
• REST bleibt Technology, weil die technischen Constraints und die Implementierung im Vordergrund stehen, obwohl es häufig Architekturstil genannt wird.
• Wenn ein Name zwei eigenständige Bedeutungen bezeichnet, entstehen zwei klar benannte und miteinander verbundene Knoten mit jeweils stabilem Typ.

Lies die Fragen von oben nach unten und prüfe, welche primäre Bedeutung der Knoten dauerhaft erklären soll. Sobald eine Frage eindeutig passt, steht der Typ fest. Wenn mehrere Fragen passen, ist die beabsichtigte Bedeutung noch zu breit und muss zuerst präziser beschrieben werden.

• 1. Beschreibt der Knoten einen technischen Standard, Unterbau oder Ausführungsrahmen? Dann Technology.
• 2. Beschreibt er ein direkt bedientes, konkretes Arbeitsmittel? Dann Tool.
• 3. Beschreibt er ein wiederholbares Vorgehen mit Regeln, Schritten oder Outputs? Dann Method.
• 4. Beschreibt er ein dauerhaftes Denkmodell, Prinzip oder Warum? Dann Concept.

Die Typen werden besonders klar, wenn sie als zusammenhängendes System gelesen werden. Rund um Domain-Driven Design verbindet Nexonoma vier eigenständige Knoten, die jeweils ihre klare Bedeutung behalten.

• Domain-Driven Design – Concept: ordnet das Denken über Fachdomänen und Modelle.
• Event Storming – Method: beschreibt ein durchführbares Vorgehen zur gemeinsamen Modellierung.
• Miro – Tool: unterstützt den Workshop als direkt benutzte Kollaborationssoftware.
• Neo4j – Technology: kann als technischer Graph-Unterbau für vernetzte Domäneninformationen dienen.
• Die Relationen erklären anschließend, welche Methode das Concept unterstützt, welches Tool die Method ermöglicht und welche Technology eine technische Umsetzung trägt.