Informationsarchitektur gestalten: von Daten zu Wissen
- Daten als Informationen und Wissen nutzbar machen
- Die fachliche Bedeutung mit Erfahrungen systematisch verbinden
- Informationsmodelle als Grundlage für Entscheidungen
Warum Daten allein nicht die richtige Steuerungsebene für Unternehmen sind
In vielen Unternehmen beginnt die Diskussion über Datenarchitektur mit Tabellen, Datenbanken, Schnittstellen und Datenflüssen. Diese Sichten sind wichtig für ein vollständiges Modell, aber für Enterprise Architecture Management nicht die richtige Steuerungsebene. EAM muss erklären, welche Informationen ein Unternehmen braucht, um seine Fähigkeiten auszuführen, Entscheidungen zu treffen, Kunden zu bedienen, regulatorische Anforderungen zu erfüllen und digitale Geschäftsmodelle weiterzuentwickeln.
Dazu muss man sich zunächst die verschiedenen Ebenen vergegenwärtigen. Auf unterster Ebene geht es um Zeichen. Im Falle der Datenverarbeitung sind das 0 und 1. Ordnet man diese in einer bestimmten Form an, so kann man damit Zahlen, Mengen, Bilder, Zeitspannen und weitere Bedeutungsformen assoziieren. Zeichen und Format ergeben ganz allgemein Daten. Durch die Interpretation, d.h. im Kontext von Herkunft, Qualität, Zweck und Aktualität werden daraus Informationen. Wissen entsteht, wenn Informationen mit Erfahrung, Fachverständnis, Regeln, Interpretation und Bewertung verbunden werden. Diese Unterscheidung ist in der Literatur als DIKW-Logik bekannt: Data, Information, Knowledge, Wisdom. Daten, Information, Wissen und Weisheit entsprechen unterschiedlichen Ebenen menschlichen Verstehens. Auch in der Unternehmensarchitektur ist es wichtig, diese Ebenen zu unterscheiden.
Für EAM bedeutet das: Eine reine Datenarchitektur reicht nicht aus. Sie muss in eine Informations- und Wissensarchitektur eingebettet werden. EAM darf also nicht nur fragen, wo Daten gespeichert werden. Es muss fragen, welche fachlichen Begriffe gemeint sind, welche Entscheidungen unterstützt werden, welche Erfahrungen in Regeln und Kennzahlen stecken und wie dieses Wissen in Prozessen, Anwendungen und Technologien wirksam wird.
Daten, Information und Wissen im Architekturkontext
Daten bilden die technische Grundlage, Informationen schaffen fachliche Bedeutung, Wissen macht Handeln möglich. Diese Ebenen müssen im EAM gemeinsam betrachtet werden, weil digitale Transformation nicht an Datenspeichern scheitert, sondern häufig an fehlendem Verständnis: Was bedeutet eine Kennzahl? Wer darf sie nutzen? Welche Annahmen stecken in ihr? Welche Erfahrung wurde bei ihrer Interpretation berücksichtigt?
Diese Unterscheidung verändert die Architekturarbeit. Ein Data Catalog allein beantwortet noch nicht, ob eine Kennzahl fachlich verstanden wird. Data Lineage allein erklärt noch nicht, ob eine Entscheidung richtig ist. Und ein führendes System allein garantiert noch nicht, dass Erfahrungswissen, Geschäftsregeln und Ausnahmen berücksichtigt werden. Deshalb muss EAM dafür sorgen, dass die Unternehmensarchitektur, die Datenarchitektur, Informationsarchitektur, Wissensmanagement und Data Governance zusammenführt.
Typische Herausforderungen im Kontext der Informationsarchitektur
Informationsarchitektur als Lösung
Um die Komplexität beherrschbar zu machen, wird, wie in jeder Architekturdomäne, das zu beschreibende System klassifiziert. Die Datenarchitektur fokussiert sich darauf, Wissen und Information einer Repräsentation, also Daten, zuzuordnen. Diese Daten können datenverarbeitende Systeme nutzen, um die Transparenz bis auf die Technologieebene fortzuführen.
Der wichtigste Schritt ist dabei, Daten zu klassifizieren. Die Unterscheidung reduziert die Komplexität erheblich und vereinfacht die Kommunikation. Aus Datenschutz- und IT-Security-Sicht ist es zum Beispiel wichtig, sensible, persönliche und öffentliche Daten zu differenzieren.
Aus Betriebssicht werden fachliche, anwendungsspezifische, zum Beispiel Einstellungen, und persistente Daten, in der Regel Daten in Datenbanken, Dateien oder ähnlichen Speichern, unterschieden. Anwendungsspezifische Daten kann man weiter in Anwendungskonfiguration, Fehlerinformation, Anwendungsmetriken und weitere Kategorien aufteilen. Letztere sind wiederum für Reports und Business Intelligence und damit auch für den Fachbereich interessant.
Wissensmanagement
Eine moderne Architektur beginnt nicht bei Datenbanken, sondern bei fachlichen Fragen: Welche Fähigkeiten benötigt das Unternehmen? Welche Entscheidungen müssen getroffen werden? Welche Informationen werden dafür gebraucht? Welche Erfahrung und Regeln beeinflussen die Bewertung? Erst danach werden Datenquellen, Systeme, Schnittstellen und Technologien eingeordnet.
- Fachliche Informationsobjekte: zentrale Begriffe wie Kunde, Produkt, Vertrag, Asset, Risiko, Angebot oder Bestellung mit Definition, Verantwortlichkeit und Beziehungen
- Entscheidungs- und Wissensobjekte: Kennzahlen, Geschäftsregeln, Bewertungslogiken, Entscheidungsmodelle, Erfahrungswerte und dokumentierte Ausnahmen
- Datenobjekte und führende Systeme: technische und fachliche Datenquellen, Ursprung, Pflegeort, Autorität, Qualität und Lebenszyklus
- Business Glossar: gemeinsame Sprache zwischen Fachbereich, IT, Data Governance und Enterprise Architecture
- Lineage und Kontext: Herkunft, Transformation, Nutzung, Qualitätsindikatoren und Einschränkungen von Informationen
- Data Catalog und Knowledge Graph: leicht zugängliche, vernetzte Beschreibung von Daten, Informationen, Beziehungen und Nutzungskontexten
- Governance: Data Owner, Information Owner, Data Stewards, Fachverantwortliche, Architekturprinzipien und Entscheidungsrechte
Unser Ansatz für Informationsarchitektur ist ganzheitlich und pragmatisch
1. Von Entscheidungen und Fähigkeiten ausgehen
Wir starten nicht mit allen Datenbeständen, sondern mit konkreten fachlichen Entscheidungs- und Steuerungsfragen: Welche Informationen braucht das Management? Welche Informationen benötigen Prozesse? Welche Informationen sind für Regulierung, Kundeninteraktion, KI oder Automatisierung kritisch?
2. Informationsobjekte modellieren
Zentrale Begriffe, Kennzahlen, Regeln und Entscheidungslogiken werden fachlich beschrieben. Dabei wird sichtbar, welche Bedeutung ein Objekt hat, wer es verantwortet und wie es mit Capabilities, Prozessen, Anwendungen und Datenquellen verbunden ist.
3. Datenquellen, führende Systeme und Lineage klären
Erst danach werden Informationsobjekte mit Datenquellen, Systemen, fachlichen Schnittstellen und Datenflüssen auf Anwendungsebene detailliert.
4. Informationen und Wissen verfügbar machen
Wir identifizieren, wo kritisches Fachwissen in Personen, Regeln, Workarounds, Ausnahmen oder historischen Entscheidungen steckt. Relevantes Wissen wird in Glossar, Data Catalog, Regelwerken, Entscheidungsmodellen und Knowledge Graphs explizit auf technischer sowie personeller Ebene allen Stakeholdern zugänglich gemacht.
5. Skalierung und kontinuierliche Verbesserung
Informationsarchitektur ist kein einmaliges Modellierungsprojekt. Sie wird iterativ erweitert, überprüft und mit Governance, Data Management, IT-Architektur und den fachlichen Zielbildern verzahnt.
Ihr Ansprechpartner für Informationsarchitektur
Daniel Adam
Telefon: 0336 31 40 30 11
E-Mail: info@trusted-advisor.com
Vereinbaren Sie jetzt eine kostenlose Erstberatung!
Buchen Sie ein unverbindliches Erstgespräch, in dem wir uns Ihre Herausforderungen anschauen und erste Lösungsansätze definieren.Mehr zu unseren Schwerpunkten im Enterprise Architecture Management
Das sagen unsere Kunden
Häufige Fragen rund um Informationsarchitektur und Wissensmanagement
EAM berücksichtigt nicht nur Daten, sondern entwickelt Unternehmensfähigkeiten. Jede Ebene arbeitet mit Werkzeugen aus der IT und hat damit mit Daten zu tun. Für eine holistische Sicht ist das jedoch nicht ausreichend, sondern nur eine Perspektive. Erst Kontext, Erfahrung, Handlungsbezug und fachliche Interpretation machen aus Daten nützliche Informationen, die dank Digitalisierung und EAM auch maschinell verarbeitet werden können.
Daten sind Werte oder Fakten. Information entsteht, wenn Daten Bedeutung, Kontext und Zweck erhalten. Wissen entsteht, wenn Information mit Erfahrung, Regeln, Interpretation und Handlungskompetenz verbunden wird.
Ein Business Glossar schafft eine gemeinsame Sprache. Es definiert Begriffe, Kennzahlen und Verantwortlichkeiten und reduziert Missverständnisse zwischen Fachbereich, IT, Data Governance und Enterprise Architecture.
Knowledge Graphs können ein Baustein sein, wenn Beziehungen, Semantik und Kontext zwischen Informationen sichtbar und maschinenlesbar gemacht werden sollen. Sie ersetzen aber keine Governance und kein fachliches Modell.
Der Einstieg erfolgt über kritische Entscheidungen, Capabilities oder Use Cases. Daraus werden Informationsobjekte, Datenquellen, Verantwortlichkeiten, Regeln, Lineage und Roadmap-Schritte abgeleitet.