Diese Woche verabschieden wir uns also von Roadmaps und kehren zum digitalen Treibstoff zurück: Datenarchitektur.
Erinnern Sie sich an unsere Datenreihen vom letzten Herbst, Ich habe zugegeben, dass ich immer ein schwieriges Verhältnis zur Datenarchitektur hatte. Sie ist grundlegend. Keine große Sache. Unternehmensarchitektur existiert ohne Daten und Sicherheitsarchitektur. Doch die übliche trockene, schwerfällige Diskussion verliert meist den Kern der Sache aus den Augen.
Wir setzen stark auf das Enterprise-Datenmodell von DAMA, weil es einfach funktioniert. Diese wenigen Seiten des DMBOK sind Gold wert. Drei einfache Modelle –Subjektmodell, Themenbereichsmodell (SAM), und Logisches Datenmodell (LDM) Wir liefern Ihnen ein vollständiges Enterprise-Datenmodell. 8–20 Themen mit etwa 20 Entitäten im SAM bedeuten, dass Sie mit 160–400 Wörtern die Grundlage für das Verständnis von Daten-Governance, Datenfluss und Datenbedarf schaffen. Das ist alles.
Dann stießen wir auf ein digitales Produkt.
Sie kennen das digitale Angebot Ihres Unternehmens. Manchmal ist das gesamte Unternehmen darauf ausgerichtet, wie bei ServiceNow. Manchmal ist es tief integriert, wie bei Apple. Fotos. Manchmal gehört es zu den Dienstleistungen, die Ihr Unternehmen anbietet.
Wenn wir das klassische DAMA-Modell anwenden, stößt es an seine Grenzen – ehrlich gesagt, es versagt. Ein Subjekt ist eine Geschäftstätigkeit. Beginnen wir mit den Kerngeschäftstätigkeiten wie Verkauf, Versand, Fakturierung, und Unterstützung. Super. Hier haben wir absolute Klarheit über die zentrale Datenverwaltung. Der Chef des Versands besitzt Versanddaten. Der Chef von Verkäufe Sie sind für den Vertrieb verantwortlich. Sie planen, verkaufen, versenden, stellen Rechnungen aus und bieten Support. Die Daten fließen sequenziell über klare Organisationsgrenzen hinweg.
Natürlich stolpern die meisten Teams über Wörter wie „Kunde“. Denn sie haben mit Daten begonnen, nicht mit dem Geschäft. Wenn man mit dem Thema (der Geschäftstätigkeit) beginnt, entdeckt man, dass die Wörter … Käufer, Empfänger, Zahler und Operator. Jeder von ihnen hat eine andere Beziehung zu Ihrem Unternehmen – bilden Sie die richtige Beziehung ab, nicht einen vagen Begriff wie Kunde Und alles wird klar.
Hier sehen Sie eine Unternehmensdatenlandschaft. Wunderbar. Daten-Governance und Datenfluss sind sofort ersichtlich. Sie verfügen über eine klare, gemeinsame Sprache mit dem Unternehmen. Das "Produkt" ist lediglich eine Entität, die sich durch Ihre Themen zieht und zusätzliche Datenbeziehungen herstellt.
Dann erhalten Sie ein digitales Produkt. Ihr Kunde meldet sich in Ihrer Software an und teilt seine Hoffnungen, Ängste und Träume mit (Soziale Medien). Oder er verwaltet sein IT-Ökosystem (ServiceNow). Oder sein Smartphone macht Fotos mit Standort- und Datumsangabe und speichert diese in Ihrem Datenspeicher.
Wie passen der Ausdruck einer Hoffnung, die vom Browser verwendete IP-Adresse, die interne CI-IP-Adresse des Kunden und der Standort des Kundentelefons am Freitagabend um 23:25 Uhr in Ihr Unternehmensdatenmodell?
Ein verworrenes Durcheinander
Der Kampf mit digitalen Produkten
Ein digitales Produkt ist grundlegend anders, weil der Kunde innen die Maschine. Das Produkt Ist Eingebettet in die Aktivität. Der Kunde führt diese Aktivität oft ohne unser Zutun aus.
Nehmen wir ServiceNow als Beispiel – eine gängige IT-Betriebsplattform. Kunden nutzen sie, um ihre Konfigurationselemente (CIs) und ihr Anwendungsportfolio einzugeben. Wenn wir nicht zwischen Produkt und Anwendung unterscheiden und nicht mit den Themen beginnen, geraten wir in eine Endlosschleife. Wir können unsere Themen (Geschäftsaktivitäten) auch nicht innerhalb des Produkts anwenden.
CIs waren einfach. ServiceNow kann eindeutig eine CI verwenden, um das Produkt zu betreiben, ohne dass diese CIs mit den eigentlichen Produktinhalten in Verbindung stehen. Die Herausforderung liegt in den Daten, die diese Grenze überschreiten. Sobald ein Kunde in unseren Geschäftsprozess eingebunden ist – beispielsweise durch die Erstellung einer ServiceNow-ID zur Ticketverwaltung und zum Produktzugriff –, wird diese ID für ServiceNow relevant. Sicherheitsthema, Rechnungsgegenstand, Kundenservice-Thema.
Wir überschreiten den Ereignishorizont, wenn wir Datenmaterial für unsere Geschäftsprozesse im Produkt verwenden. Ab dem Ereignishorizont wird es sehr merkwürdig.
Ganz einfach: Überschreiten Sie nicht den Ereignishorizont.
Die Produktdatenarchitektur muss explizit von der Unternehmensdatenarchitektur getrennt werden. Sobald wir diesen Weg beschreiten, stoßen wir auf das offensichtliche Problem: Die Datennutzungsbedingungen.
Sind Sie die Post oder Facebook?
Die Trennung von Produktdaten und Unternehmensdaten wirft die grundlegende Frage auf: Wie lauten die Nutzungsbedingungen für die Daten? Wir verwenden Nutzungsbedingungen überall in Navigieren Denn es liefert uns eine wichtige architektonische Einschränkung. In den Zeiten der serviceorientierten Architektur nutzte ich den 'Bustest', um Nutzungsbedingungen zu erklären. Ein Bus ist ein gemeinsam genutzter Dienst mit strengen Nutzungsbedingungen. Ein Ticket berechtigt eine Person zur Mitfahrt. Ein Ticket an einer Bushaltestelle berechtigt eine Person zur Nutzung einer vorprogrammierten Route. Dieses Ticket, diese Route und diese Haltestelle sind nur zu den festgelegten Zeiten gültig.
Der Fahrer fragt weder nach Ihrem Ziel noch nach Ihrer Ankunftszeit oder ob Sie eine Mitfahrgelegenheit nach Hause wünschen. Auch darf ein Zebrastreifen nicht mit dem Ticket fahren. Klare Nutzungsbedingungen.
Wir verwenden in unserem Beratungsaufträge. Wenn Sie ein digitales Produkt entwickeln, Sind wir die Post oder sind wir Facebook?
Die Post bietet eine wichtige Dienstleistung: die Weiterleitung von Nachrichten vom Absender zum Empfänger. Dafür benötigt sie streng begrenzte Metadaten – die Zieladresse, die Absenderadresse und die gewählte Serviceklasse. Doch hier liegt die absolute Einschränkung: Sie schauen nie in den Umschlag. Ihre Architektur, ihre Governance und ihre Datenmodelle basieren auf der Annahme, dass die Inhalte ihrer Sendungen sie nichts angehen. Wenn ein Postangestellter Ihre Post öffnet, um Ihre Briefe zu analysieren und Ihnen gezielte Werbung zu verkaufen, ist das keine clevere Monetarisierungsstrategie. Es ist ein Verbrechen.
Nun zu Facebook. Facebook ist das genaue Gegenteil. Ja, genau wie die Post vermittelt Facebook die Kommunikation. Facebook speichert relevante Metadaten, um… den Dienst betreiben. Aber die Inhalt Ihrer Nachrichten Das ist der Hauptantrieb ihres Geschäftsmodells. Sie öffnen jede Nachricht und analysieren sie. Sie verfolgen, was der Empfänger tut. Sie vergleichen Empfänger, Absender, Themen und alles andere. Sie könnten genauso gut unsere Socken durchwühlen, um Inhalte, Marke, Typ und Kleidung zu monetarisieren. Denn die Nutzungsbedingungen erlauben es ihnen.
Jede Nutzungsbedingungen können funktionieren. Manche, wie die von WhatsApp, sind auf maximale Privatsphäre ausgelegt. Andere gewähren uneingeschränkten Zugriff. Vergessen Sie nicht: Das ist keine Privatsphäre – nicht einmal Facebook bietet sie. publizieren Deine Hoffnungen, Träume und Leidenschaften. Aber sie nutzen sie. Sie nutzen sie, weil die Produktbedingungen es ihnen erlauben. Wenn du gegen die Nutzungsbedingungen verstößt, begehst du einen massiven Systemfehler. Du hast es versäumt, die Grenzen festzulegen.
Die Nutzungsbedingungen werden immer vom Eigentümer. Serviceverantwortlicher, Produktverantwortlicher, Anlagenbetreiber, Geschäftsbereichsleiter – das spielt keine Rolle. Pragmatisch gesehen wenden wir uns an den Produktverantwortlichen. Nicht an irgendeinen unauffälligen Mitarbeiter in einem agilen Team, sondern an die Person, die für das Produkt verantwortlich ist, das wir unseren Kunden anbieten. Die Person, die die für die Kunden akzeptablen Nutzungsbedingungen mit den für das Unternehmen akzeptablen Bedingungen in Einklang bringen kann. Viele Fahrgäste wünschen sich einen Fahrer, der sie jederzeit pünktlich und zuverlässig an ihr Ziel bringt. Und genau diesen Service gibt es – zu einem anderen Preis.
Versammlung als ultimative Durchsetzung
Die Nutzungsbedingungen setzen einen kontrollierbaren Rahmen. An jeder Grenze entstehen Spannungen. Architektur lebt davon, sich mit diesen Randbedingungen auseinanderzusetzen.
Apples Foto-"Erinnerungen"-Funktion sorgt für Spannungen. Apple bietet plattformübergreifenden Speicherplatz und gemeinsames Teilen, was stark an Facebooks Community-Mediation erinnert. Apples zentrales Wertversprechen ist jedoch der Datenschutz. Das Unternehmen verteidigt seine Nutzungsbedingungen vehement. Apple geht sogar so weit, Dienste vom Markt zu nehmen, wenn es nicht garantieren kann, dass niemand Ihre Fotos einsehen kann. Sockenschublade von Apple ohne Ihre aktive Beteiligung.
Intern geben sie keinen Cent für die Verarbeitung von Kundendaten zur Vollstreckung eines Haftbefehls aus. Denn sie kann nicht hinsehen. Sie behaupten vor Gericht Es gibt keine Hintertür.
Dann bieten sie einen Service an, der Ihre Fotos – Erinnerungen – für Sie ansieht und kuratiert. Ihre Nutzungsbedingungen gewährleisten absolute Vertraulichkeit..
Sie begegnen diesen harten Einschränkungen – Apple kann nicht hineinsehen und Ihre Fotos werden kuratiert – mit starken Anwendungsarchitektur. In Navigate-Begriffen ausgedrückt bedeutet das einfach die Verwendung von Montagemodell.
Die Zusammenstellung von Funktionalität ist eine zentrale Aufgabe für Anwendungsarchitekten. Sie bestimmt Integrationsgrenzen, Lebenszyklus und Abhängigkeiten – sie stellt die entscheidende Herausforderung der Anwendungsarchitektur dar. Funktionalität kann prinzipiell überall platziert werden. Wirklich überall. Sie lässt sich in eine Unternehmensanwendung einbetten, in einem Microservice bereitstellen oder sogar fest in einen ASIC integrieren.
Um die Nutzungsbedingungen für Daten zu erfüllen, implementiert Apple die AI Worker-Funktionalität bewusst direkt auf dem Endgerät – Ihrem iPhone. Indem Apple Rechenleistung und Daten zusammenführt, trennt sich das Unternehmen physisch von den Daten. Apple verzichtet damit wissentlich auf die Möglichkeit, Kunden zu monetarisieren.
Ignoriert man die eigenen Aussagen, stürzt sich der Schaden wie ein Geier auf einen. Haftungsrisiken zwingen zu nachträglichem Schutz, führen zu Komplexität, steigenden technischen Schulden und Kosten – und lassen zusätzlich noch einen Haftungsfall in einer dunklen Ecke verschwinden.
Wenn Sie Nutzungsbedingungen für Ihr digitales Produkt haben, orientieren Sie sich an Apple. Erstellen Sie eine Anwendungs-, Technologie- und Sicherheitsarchitektur, die die Anforderungen erfüllt.
Fazit: Den Knoten durchschneiden
Wenn Sie nicht mit Produktdaten beginnen und Ihre Nutzungsbedingungen nicht kennen – Facebook, das beruflich Daten sammelt, die Post, die nur auf Anweisung Daten sammelt, oder Apple, das nicht Daten sammeln darf – driftet Ihre Architektur unweigerlich in Richtung Haftung.
Die größten Herausforderungen ergeben sich dort, wo Ihre Geschäftsprozesse durch die Nutzung von Produktdaten optimiert werden. Ein einfaches Beispiel ist die Verwendung der von Ihren Kunden in Ihrem SaaS-Produkt verwalteten Identitäten zur Unterstützung der Zugriffskontrolle oder Autorisierung.
Sie werden den Knoten niemals lösen, indem Sie an Ihren Themenbereichen "Vertrieb", "Support" oder "IT-Betrieb" herumdoktern. Das ist, als würden Sie stärker am Seil ziehen. Es macht den Knoten nur noch fester. Es ist genauso, als würde man noch ein weiteres Meeting abhalten. Wem gehört der Kunde?.
Meine Herausforderung diese Woche: Schauen Sie sich Ihre digitalen Produkte an. Trennen Sie diese klar und übersichtlich in Ihrer Anwendungsarchitektur? Wie sieht es mit Ihrer Datenarchitektur aus? Oder verschwimmt alles zu einem unübersichtlichen Datenwirrwarr? dein Geschäfts- und Anwendungsunterstützung dein Unternehmen? Dann sollten Sie Ihre digitalen Produkte als Themen verwenden. Legen Sie die Nutzungsbedingungen explizit fest. die Steuerung Ihrer Architektur indem Sie die Ihnen gegebenen Anweisungen befolgen.
Nächste Woche zeige ich Ihnen genau, wie wir den Knoten lösen. Wir werden uns ansehen, wie wir die Grenzen architektonisch gestalten und klare Einschränkungen festlegen. Wir beginnen einfach damit, das standardmäßige DAMA-Unternehmensdatenmodell zu erweitern und jedes digitale Produkt als DAMA-Subjekt zu behandeln.
Wie immer freue ich mich über Ihre Gedanken und Ihr Feedback.
Ich wünsche ihnen einen wunderbaren Tag!
Grüße,
Dave Dave Hornford Conexiam
PS. Wenn die Entwirrung Ihrer Datenarchitektur für Sie geschäftskritisch ist, schauen Sie sich unsere Lösung an. Workshop zur Grundlagen der Datenarchitektur. Wir helfen Ihnen dabei, Ihre Themenbereiche abzubilden, Ihre Datenverträge zu definieren und sicherzustellen, dass Ihre Nutzungsbedingungen Ihre Architektur steuern und nicht zerstören.