Architektur digitaler Produkte: Die Kollision der gelben Linie

CDO-Illusion

Grenzen haben ihre Verantwortlichen. Kommerzielle digitale Produkte werden von vehementen Verfechtern verteidigt. Intern hegen wir Illusionen. Wir imaginieren Kunden und Eigentümer. Wir glauben, das Organigramm zeige uns stets die Entscheidungsbefugnis.

Engagierte Produktverantwortliche sind wichtige Stakeholder. Ihnen wurde ein Verantwortungsbereich übertragen – das Produkt. Sie haben sehr klare Vorstellungen. Richtungen – Erwartung, Einschränkung, Risikobereitschaft. Sie können den Wert von Änderungen einschätzen und formulieren oft sehr präzise Anforderungen. Ich habe mit einem Produktverantwortlichen für digitale Produkte zusammengearbeitet, der eine Reduzierung der Transaktionskosten um 95% auf seiner Plattform benötigte. Nicht nur um neue Funktionen oder Kostenverbesserungen. Er wollte die Plattformkosten um 95% senken, um wettbewerbsfähig zu bleiben.

Mit solchen Produktverantwortlichen Architektur-Governance Das ist ein Traum. Sie haben einen durchsetzungsstarken und kompetenten Stakeholder. Jemanden, der die ihm übertragene Befugnis und den gesamten Kontext dieser Befugnis versteht.

Dann haben wir unsere internen Produkte. Anfangs ist die Grenze zwischen Produkt und Daten noch nicht ganz klar. Oftmals haben wir Prinzipien, die Folgendes nahelegen: Daten teilen. Wir implizieren, dass die Existenz von Daten dazu führt, dass Enterprise ist der Eigentümer..

Wir schauen ins Organigramm und finden einen Chief Data Officer (CDO) oder ein Data Governance Office. Üblicherweise wendet man sich an den CDO, um Fragen zu stellen und Erklärungen abzugeben. Man geht fälschlicherweise davon aus, dass der CDO wie durch Zauberhand alle Daten besitzt. Besonders schädlich ist die Annahme, dass jegliche Bemühungen zur "Monetarisierung", Demokratisierung und Schaffung "besserer Entscheidungsfindung" nachweislich sinnvoll sind.

Gleichzeitig verwechseln wir in der Entwicklung oft das bloße Einfügen einer API oder das Ausführen eines Extraktionsvorgangs mit dem Speichern von Daten in der virtueller Datensee mit Veränderung verbessert unsere Organisation.

Wenn wir uns dem "Product Owner" zuwenden, finden wir einen aufgeblasenen Business-Analysten vor, der zwischen den Technikern und einer verärgerten Nutzergemeinschaft gefangen ist. Sie bezeichnen die Nutzergemeinschaft als Kunden – obwohl Marty uns erklärt, dass der Kunde zahlen muss und jederzeit gehen kann. Diese 'Product Owner' sind damit beschäftigt, Jira-Tickets zu bearbeiten. Sie haben keinerlei Befugnisse. Sie verstehen den Wert des Produkts überhaupt nicht. Stellen Sie sich vor, sie wüssten, dass die Rentabilität von einer Senkung der Betriebskosten (OpEX) um 95% abhängt, und würden diese Senkung im gesamten Digitalisierungsprogramm durchsetzen.

Mit solchen Produktverantwortlichen Architektur-Governance Er ist am Beatmungsgerät. Wir müssen alle Ressourcen nutzen. Architektur-Governance Instrumentarium, um die Einschränkungen im Zusammenhang mit dem Produkt, die Ziele des Produkts und die Erwartungen des Unternehmens an die Geschäftsfunktion des Konsumenten zu ermitteln.

Wir wissen, dass unsere Organisation ein komplexes Geflecht von Interaktionen ist. Navigieren, Um die Komplexität zu vereinfachen, stützen wir uns auf SABSAs Risikomodell und das Konzept der überlegenen Architektur, das sich in TOGAF.

Alles, was ich suche, ist das gleiche Wissen und die gleichen Anweisungen, die meinen ehrgeizigen Produktverantwortlichen im Geschäftsleben den Schlaf rauben – Markt, Positionierung, Preis, Wettbewerb.

Ich suche lediglich jemanden, der Aufwärtspotenzial, Abwärtspotenzial, Wert, Kosten und Risiko testen kann.

Ich möchte lediglich die Grundlagen guter Unternehmensführung kennen – das Ziel, die Leistungserwartungen, die Rahmenbedingungen und die Risikobereitschaft.

Und das wünsche ich mir für jedes digitale Produkt.

Die Kollision entlang der gelben Linie

Sobald die Governance-Struktur für das digitale Produkt festgelegt ist, beginnen die Spannungen.

Wir arbeiten meist intern. Sie werden von Ideen umgeben sein, die von Leuten stammen, die sich nicht an Marktregeln halten. Leute, die behaupten, jede Strategie, Initiative oder Führungsaussage zu unterstützen. Leute, die diese Unterstützung nutzen, um ihre Präferenzen oder lokale Verbesserungen zu rechtfertigen.

Sie kennen das Argument der verhängnisvollen Ausrichtung. Es geht einzig und allein darum, wie sie etwas unterstützen. Ohne einen sinnvollen Beitrag zu leisten. Wir wissen, dass Wert aus Nutzen besteht, der den Aufwand rechtfertigt. Insbesondere in Anbetracht der Unsicherheit, die mit der Nutzung des Nutzens und den damit verbundenen Kosten verbunden ist.

Intern liegt der Fokus auf der Technologie. Im Mittelpunkt stehen Themen wie die Mechanismen des Scrapings einer operativen Datenbank. Die Kosten werden so niedrig angesetzt wie bei einem eiligen Integrationsauftrag.

Die Grundlagen der Datenqualität und des Datenflusses gehen in der Eile, etwas zu tun, verloren.

Ihre Organisation nutzt die Sprache des Produkts, um gefährliche Wege zu beschreiten.

Betrachten wir zwei kritische Risiken im Zusammenhang mit Datenprodukten.

Was Sie gestohlen haben, können Sie nicht verkaufen.

Wer Datenprodukte verkauft, verkauft auch Methodik und Herkunftsnachweis.

Alle.

Wenn keine eindeutigen Nutzungsbedingungen die Wiederverwendung von Daten erlauben, werden diese gestohlen.

Gestohlene Daten weisen – aus Sicht der Datenarchitektur – niemals eine starke Herkunfts- und Methodiknachweisbarkeit auf: Datenquelle und Datenfluss.

Gestohlene Daten werden nicht 'monetarisiert', sondern verkauft. Hehler bieten massive Rabatte, weil gestohlene Güter im normalen Handel nicht verwendet werden können.

Im Unternehmen verunreinigen gestohlene Daten sogar virtuelle Datenseen. Auf den ersten Blick sehen minderwertige, methodenlose Daten genauso aus wie hochwertige Daten. Doch sie erfordern ständige Nachbearbeitung und weitere Aufbereitung, um überhaupt nutzbar zu sein.

Letztendlich führen die gestohlenen Daten zu Compliance-Problemen. Diese betreffen in der Regel personenbezogene Daten, Kundengeheimnisse oder geltende Rechtsvorschriften. Dann müssen Sie zusätzlich Geld ausgeben, um den ohnehin schon wertlosen und teuren Datenmüll zu bereinigen.

Wenn Sie etwas Spaß daran haben, schauen Sie sich doch einmal genauer an, wie Ihre Kompostbehälter genutzt werden. Wie bei den meisten privaten Kompostieranlagen werden Sie wahrscheinlich beobachten, wie die Leute pflichtbewusst Schalenreste in den Behälter werfen und dann im Gartencenter Dünger und Erde kaufen.

Die Sorgerechtsbeschränkung

Wir beheben diese Probleme durch gute Architektur.

Wir beginnen damit, Themen rund um Produktdaten zu entwickeln. Insbesondere Daten, bei denen unser digitales Produkt Kundeninformationen erfasst. Navigieren Wir verwenden eine Modelleigenschaft, um zu unterscheiden Verwahrungsdaten—Daten, die einer anderen Organisation gehören und nur in strikter Übereinstimmung mit dem Vertrag verwendet werden dürfen.

Dieses Grundstück ist der erste Pfosten Ihres Zauns. Diese Grenzen schränken die Integration stark ein und erfordern Sicherheitsmaßnahmen.

Letzte Woche habe ich ServiceNow kurz erwähnt. CIs sind offensichtlich Verwahrer, Sie werden zwar von der Anwendung verwendet, aber der Anwendungsanbieter hat nie einen Grund, sie zu überprüfen. Wie wäre es damit? Benutzernamen?

Ja, Benutzernamen. In einem SaaS-basierten IT-Betriebsmanagementsystem richtet der Kunde diese Funktionen ein, um Mitarbeiter in Prozessabläufe einzubinden, Genehmigungen zu ermöglichen und sogar Benachrichtigungen per Anruf auf die private Telefonnummer des Benutzers zu versenden. Kann ServiceNow diese Funktionen nutzen?

Die Verwendung für Zugriff und Lizenzierung ist offensichtlich praktisch. Sind die Rechte jedoch eingeschränkt, steht man wieder vor Apples Problem und muss möglicherweise einen Weg finden, um zu verhindern, dass Daten nach außen dringen. Kundenumgebung. Wir haben gesehen, dass Apple gute Dienste geleistet hat. Anwendung und Infrastrukturarchitektur mit Fokus auf Montagegrenzen. Sie garantieren die Vertraulichkeit Ihrer Erinnerungen, indem sie diese auf Ihrem Gerät verarbeiten. Denken Sie daran: Sie versprechen, nicht hineinzuschauen, auch wenn Sie sich dieses eine Mal darüber freuen.

Überlegen Sie sich die gleichen Überlegungen auch intern. Welche Daten gehören zum digitalen Produkt? Welche Schritte sind erforderlich, um sicherzustellen, dass Sie diese Daten innerhalb des Produkts, für das Produkt oder durch das Produkt verarbeiten?

Welche Daten stehen also zur Verfügung? Welche Daten benötigt das Unternehmen?

Einer unserer Kunden im Bereich digitaler Produkte verfügt über eine sehr schlanke Finanzabteilung. Jede Produktfamilie ist für ihre eigene Kostenrechnung und ihr Kostenmanagement verantwortlich. Die Finanzdaten, die in den zentralen Finanzbereich fließen, sind stark eingeschränkt.

Dieses scheinbar ineffiziente Design ermöglicht es den verschiedenen Produkten, ihre Geschäfts- und Steuerprozesse zu optimieren. Der CEO kann ungestört durch den Flur gehen und gezielte Fragen stellen. Von den Verantwortlichen für Gewinn und Verlust wird erwartet, dass sie Bescheid wissen und optimieren. Ausreden gibt es nicht. Diese Disziplin müssen wir auf alle unsere digitalen Produkte übertragen.

Architekturverteidigung: Empfehlung zur Nichteinhaltung

In diesem Gespräch habe ich hervorgehoben, wie man die Grenzen des Machbaren auslotet. Ich habe betont, dass digitale Produkte lediglich ein spezielles Governance-Problem darstellen.

Behandeln Sie sie als Thema, als Geschäftsbereich. Gleichzeitig sollten Sie sie als Risiko- oder Governance-Bereich betrachten. Ich gehe davon aus, dass Sie jedes betroffene Individuum auch als … sehen. Governance-Bereich. Ein Ort mit einzigartigen Zielen, Leistungserwartungen, Einschränkungen und Risikobereitschaft. Ein Ort mit soliden Grundlagen. wichtiger Interessensvertreter.

Ich habe nicht von einem einzelnen Entscheidungsträger gesprochen, sondern von einem solider Schlüsselakteur. Stakeholder agieren stets in Gruppen. Es gibt immer konkurrierende Interessen, sich überschneidende Zuständigkeiten und widersprüchliche Zielsetzungen. Wäre es einfach, bräuchten wir keine Unternehmensarchitektur.

Meine Beispiele waren allesamt Fälle, in denen wir das digitale Produkt schützen mussten. Fälle, in denen wir die Assemblierung zur Verarbeitung innerhalb oder außerhalb des Produkts verwenden. Das ist ein Fall, und Sie müssen wissen, wann er zutrifft.

Das gilt gleichermaßen für den anderen Fall, in dem dem Produktverantwortlichen – dem wichtigsten Stakeholder, Verantwortlichen für den Governance-Bereich und dem Fachverantwortlichen – gesagt wurde, er solle sich in ein größeres Ganzes einfügen. Ihm wird die Nutzung des gemeinsamen Finanzsystems empfohlen.

Beide Modelle sind richtig. Beide Modelle können Ihre digitale Produktarchitektur sein.

Wenn die Leute aufhören, Ihrer für Ihr Unternehmen und dessen einzigartige Markteintrittsstrategie optimierten Architektur zu folgen, überschreiten sie die Gelbe Linie. Früher oder später wird es Gegenverkehr geben.

Um eine Kollision entlang der gelben Linie zu vermeiden, haben wir, die Unternehmensarchitekten Stell dich in die Schusslinie.

Methodisch gesehen führen wir Folgendes durch: Umsetzungs-Governance und erstellen Sie ein Empfehlung bei Nichteinhaltung. Das Problem zu finden ist einfach, aber wenig hilfreich. Eine Empfehlung zeigt den Beteiligten, was sie tun müssen, um den Wert des Zielobjekts wiederherzustellen. Sie wissen bereits, welchen Nutzen die Nichteinhaltung bringt.

Jede Nichteinhaltung lässt sich letztlich auf Folgendes zurückführen:

1. Ziel durchsetzen: Änderungen zur Erreichung des erwarteten Zielarchitekturwerts.
2. Gewährung vorübergehender Erleichterungen: Die Behebung des Problems wird verschoben.
3. Architektur ändern: Akzeptiere den Verlust des ursprünglichen Wertes und schaffe eine neue Wertvorstellung mit einem neuen Ziel.

Wir gestalten die Entscheidungsoptionen so, dass die zuständigen Führungskräfte – die Stakeholder – eine fundierte Entscheidung treffen können. Und schon hat man die bestmögliche Organisation und den bestmöglichen Wandel. Ein wirklich angenehmer Zustand.

Abschluss der Kollision entlang der gelben Linie

Wir gehen oft davon aus, dass es eine Tugend ist, wenn mutige Interessengruppen an ihrer Linie festhalten, und Durchsetzung des Ziels. Das ist oft der Fall. Oft handelt es sich bei der Nichteinhaltung um eine lokale Optimierung. Oder ein Projektteam nimmt eine Abkürzung, um das Ziel zu erreichen. Go-Live-Tag. Oder ein agiles Team, das den Sieg für sich beansprucht. In all diesen Fällen zerstören sie den Wert, den das Zielunternehmen liefert.

Ich bin nicht so überheblich, allwissend zu sein. Ich weiß, dass die Welt sich bewegt und verändert. Neue Ansätze, neue Werkzeuge entstehen. Die gesamte schöpferische Kraft übertrifft mein sonstiges Wissen bei Weitem. großartiges Beratungsteam. Am wichtigsten ist jedoch, dass unser Unternehmen jeden Morgen ein neues Unternehmen in einer neuen Position ist.

Ich erschaffe dynamische Roadmaps Ich gebe meinen Stakeholdern die Kontrolle, damit sie die Dinge selbst in die Hand nehmen können. Jede Abweichung von den Vorgaben nutze ich als neue Chance. Sobald wir einen besseren Weg zu einem besseren Ziel sehen, ergreifen wir ihn. Sofort. Und dann feiern wir! Wir haben all unsere Kreativität und unser ganzes Potenzial ausgeschöpft. Meine Architektur ist grün und wächst. Hurra!

Hier ist meine Herausforderung für diese Woche: Wer kann die Verantwortung für Ihre digitalen Produkte übernehmen? Wer trägt die Vor- und Nachteile jeder Entscheidung? Wie ist die Marktposition (im Unternehmenskontext) und welche Erfolgskriterien (Zielsetzungen) gibt es für jedes Produkt? Welche übergeordnete Architektur schränkt diese Produkte ein?

Nutzen Sie dies, um die gelbe Linie zu erkennen. Und um die Metapher weiterzuführen: Um welche Art von Linie es sich handelt – die doppelten gelben Linien auf Bergstraßen mit Geschwindigkeitsbegrenzungen geben einen Hinweis. Finden Sie die wirklich relevanten Einschränkungen.

Nächste Woche, im letzten Teil dieser Reihe über Daten und digitale Produkte, beschäftigen wir uns mit Techniken – den Werkzeugen der Architekten. Konkret gehen wir auf zwei Aspekte ein: Erstens auf die Konstruktionen des logischen Dokumentmodells, um die Schnittstelle zwischen Unternehmen und digitalem Produkt zu überbrücken. Zweitens auf Architekturspezifikationen, die die Nutzungsbedingungen und die Datenzusammenstellung in konkrete Richtlinien übersetzen.

Wie immer freue ich mich über Ihre Gedanken und Ihr Feedback.

Ich wünsche ihnen einen wunderbaren Tag!

Grüße,

Dave

Dave Hornford
Conexiam