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
Unverbindliches Erstgespräch anfragen Vorgehensweise ansehen

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?

Ebene
Bedeutung
Architekturfragen
Beispiel
Daten
Technische oder fachliche Werte ohne ausreichenden Kontext
Wo entstehen Daten? Wo werden sie verändert? Wo werden sie genutzt?
Kundennummer, Transaktionsdatum, Betrag, E-Mail-Adresse, GUID
Informationen
Daten mit fachlicher Bedeutung, Kontext, Zweck und Qualität
Was bedeutet der Wert und für welche Entscheidung ist er relevant?
Aktiver Kunde, Deckungsbeitrag, Lieferstatus
Wissen
Information verbunden mit Erfahrung, Regeln, Interpretation und Handlungsfähigkeit
Welche Konsequenz folgt daraus und warum?
Abwanderungsrisiko erkennen, Kulanzentscheidung treffen, Lieferung priorisieren

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

Fachbereiche verwenden Begriffe wie Kunde, Vertrag, Umsatz oder Risiko unterschiedlich. Technisch sind Daten vorhanden, fachlich aber nicht eindeutig. Ohne Business Glossar, fachliche Informationsobjekte und gemeinsame Definitionen entstehen widersprüchliche Berichte und unnötige Abstimmungen.

Viele Kennzahlen enthalten Annahmen, Filter, Ausnahmen, Gewichtungen und historische Entscheidungen. Dieses Wissen steckt oft in Excel-Dateien, ETL-Strecken, SQL-Abfragen, Anwendungslogik oder in den Köpfen erfahrener Mitarbeitender. Wenn diese Logik nicht dokumentiert und fachlich verantwortet wird, werden Daten zwar verarbeitet, aber falsch interpretiert.

Analytics- und KI-Initiativen benötigen mehr als Datenbestände. Sie benötigen Semantik, Herkunft, Qualität, erlaubte Nutzung, Geschäftsregeln und fachliche Interpretation. Ohne diese Ebene entstehen Modelle, die zwar technisch funktionieren, aber fachlich nicht nachvollziehbar und somit nicht vertrauenswürdig sind.

Im Nonaka-Takeuchi (SECI) Model unterscheidet man implizites und explizites Wissen. Explizites Wissen ist sichtbar und zugänglich. Implizites Wissen ist oft bei einzelnen Personen gebunden. Das stellt ein erhebliches Risiko für das Unternehmen dar: Das Unternehmen skaliert nicht, weil die Person nur begrenzt Zeit hat, das Wissen einzusetzen. Das Wissen ist verloren, wenn der Kollege das Unternehmen verlässt.

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.

Datentransparenz

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

Von Entscheidungen und Fähigkeiten ausgehen

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?

Informationsobjekte modellieren

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.

Datenquellen, führende Systeme und Lineage klären

3. Datenquellen, führende Systeme und Lineage klären

Erst danach werden Informationsobjekte mit Datenquellen, Systemen, fachlichen Schnittstellen und Datenflüssen auf Anwendungsebene detailliert.

Informationen und Wissen verfügbar machen

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

EAM-Berater Daniel Adam

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.


  • Ich bin damit einverstanden, dass Trusted Advisor Kontakt mit mir aufnimmt. Die Bestimmungen zum Datenschutz habe ich gelesen und akzeptiert.

Mehr zu unseren Schwerpunkten im Enterprise Architecture Management

Enterprise Architecture Management

Enterprise Architecture Management

Bringen Sie ihre Daten auf ein neues Level. Steuern Sie ihr Unternehmen auf Grundlage von Wissen, Erfahrung und Informationen und nutzen sie das volle Potential der Digitalisierung

IT Bebauungsplan

IT-Bebauungsplan erstellen

Machen Sie bis auf die Technologieebene Sichtbar, welche Anwendungen welche Informationen liefern, verarbeiten, nutzen, speichern und erfüllen Sie – ganz nebenbei – alle Anforderungen der DSGVO und des IT-Grundschutz.

Application Portfolio Management

Anwendungsportfolio optimieren

Nutzen Sie die Klassifikation Ihrer Daten, um eine detailliertere Sicht auf die Anwendungen im Unternehmen zu bekommen. Nicht nur die Kosten sind entscheidend, sondern auch deren Rolle in Punkto Informations- und Datenverarbeitung.

Unternehmensarchitektur

Roadmap entwickeln

Planen Sie Informations- und Wissensmanagement, als entscheidendes Erfolgskriterium der digitalen Transformation ihres Unternehmens, von Anfang an mit ein.

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.