Falle #195 – Dem Gespräch nicht folgen
Architekturaspekte sind die Kriterien zur Beurteilung der Akzeptanz. Unternehmensarchitekten' Der größte Nutzen liegt darin, den Stakeholdern dabei zu helfen, den besten Weg zur Verbesserung ihrer Organisation zu finden. Stellen Sie den Stakeholdern anschließend das Governance-Tool zur Verfügung, um die erwartete Verbesserung zu erzielen.
Zu viele EA-Teams sind schlecht aufgestellt. Sie hängen buchstäblich am Boden. Wenn Sie solche Praktiken beobachten, hören Sie auf! Hören Sie sofort auf!
Werfen Sie aus, solange Sie noch können.
Friedhof der Unternehmensarchitektur
Tests für ein schwieriges Problem
- Wir verstehen das Problem erst nach der Formulierung einer Lösung
- Das Problem hat keine Stoppregel
- Lösungen für das Problem sind weder richtig noch falsch
- Problem und Lösungen sind grundsätzlich neuartig und einzigartig
- Jede Lösung ist eine 'One-Shot-Operation’
- Wir können die gegebenen Alternativlösungen nicht vergleichen
Werden Sie ein besserer Architekt
Kostenloser 90-tägiger Personal Enterprise Architect Kickstart, um ein besserer Architekt zu werden.
Wöchentlich aufgezeichnetes Webinar mit Downloads
Starten Sie noch heute
Wir erleben es ständig. Der erfolglose Enterprise-Architekt beschwert sich, dass die Entscheidungsträger ihre Meinung geändert haben. Schon wieder. Frustriert erklärt der erfolglose Enterprise-Architekt, dass er wieder ganz von vorne anfangen muss. Er überarbeitet die Arbeit und verwendet dabei die neueste, kurzlebige Idee. Wiederholter Prozess. Frustration entsteht.
Das Schlimmste an dieser Falle ist die Wiederholungstaktik des kämpfenden Unternehmensarchitekten. Normalerweise beginnen sie mit dem anfänglichen Fehler, die Priorität zu ermitteln.
Unternehmensarchitektur existiert, um komplexe Probleme mit mehreren widersprüchlichen Zielen zu lösen. Es existiert, um Lösungen für die schwierigen Probleme unserer Stakeholder zu finden. Wir brauchen keine Unternehmensarchitektur, um Fragen mit einfachen Kriterien zu beantworten.
Unser erfolgloser Enterprise-Architekt verschlimmert seinen Fehler meist noch, indem er annimmt, es sei seine Aufgabe, eine Antwort zu liefern. Nichts könnte ferner von der Wahrheit sein. Ein hochfunktionaler Enterprise-Architekt steuert den Entscheidungsprozess. Kurz gesagt: Er unterstützt die Stakeholder dabei, die bestmögliche Entscheidung zu treffen. In der Regel die am wenigsten schlechte.
Nehmen wir uns eine Minute Zeit, um diese Fehler zu analysieren – indem wir eine Antwort geben und davon ausgehen, dass die Beteiligten ihre Meinung geändert haben.
Die Ursache liegt in einem unzureichenden Verständnis dafür, wie wir komplexe Entscheidungen treffen. Wir gehen gerne davon aus, dass Entscheidungen einfach linear verlaufen. Wir beginnen mit einem Problem, sammeln Daten, führen Analysen durch, formulieren eine Lösung und haben die Antwort.
Dieser Ansatz mag für die Entscheidung gelten, welche Zahnbürste man kauft. Er hat keinen Platz in der Unternehmensarchitektur. Er hat keinen Platz bei der Adressierung eines Böses Problem.
Enterprise-Architekten werden gebeten, an komplexen Problemen zu arbeiten. Wir orientieren uns an den Anliegen der Stakeholder, um widersprüchliche Kriterien zu vermeiden. Wir verwenden Architekturansichten um die Architektur zu beschreiben.
Wie können wir sonst feststellen, ob die Zielarchitektur ausreichend ausgerichtet, kosteneffizient, mit geringen Änderungen verbunden und agil ist? Im Ernst. Mein Stakeholder möchte 1) an der Strategie ausrichten, 2) Änderungen und Betriebskosten kontrollieren, 3) die Auswirkungen von Änderungen minimieren und 4) die Fähigkeit bewahren, auf eine erwartete Zukunft zu reagieren. Ich wünschte, sie wollten nur den Weltfrieden.
Da kommt der Unternehmensarchitekt ins Spiel, der sich abmüht. Er hat hart gearbeitet und eine kostengünstige Lösung gefunden. Im Gespräch mit den Stakeholdern kommt jedoch die Frage nach der Agilität oder Ausrichtung auf, und die kostengünstige Lösung wird verworfen. Der frustrierte Unternehmensarchitekt kommt heraus und schwört, dass er ganz von vorne anfangen muss. Nachdem er hart an einer Lösung gearbeitet hat, kommt er zurück und präsentiert eine weitaus agilere Lösung.
Sie wissen, was passiert. Während des Gesprächs denkt der Stakeholder über die Auswirkungen der Veränderung nach. Die Antwort bleibt aus. Der schwächelnde Enterprise-Architekt stürmt hinaus und beschwert sich, dass der Stakeholder schon wieder seine Meinung geändert hat.
Man weiß, dass sie dasselbe wieder tun werden. Es ist so vorhersehbar. Man sieht es schon von weitem kommen. Absturz und Vernichtung.
Alles nur, weil der schwächelnde Enterprise-Architekt seine Aufgabe nicht verstanden hat. Oftmals haben ihm genau die Fähigkeiten, die den Absturz verursacht haben, den Job verschafft. Planung und Umsetzung sind nach architektonische Entscheidung.
Der Kontrast zwischen einem hochfunktionalen und einem schwächelnden Unternehmensarchitekten ist eklatant.
In unserem Beispiel möchte der Stakeholder 1) die Strategie einhalten, 2) Veränderungen und Betriebskosten kontrollieren, 3) die Auswirkungen der Veränderungen minimieren und 4) die Fähigkeit bewahren, auf zukünftige Erwartungen zu reagieren. Diese Aussagen führen zu vier Anliegen.
- Ausrichtung
- Änderungskosten / Betriebskosten
- Auswirkungen der Änderung
- Beweglichkeit
Hochfunktionale Architekten wissen, dass sie nicht für ein einzelnes Problem optimieren können. Hochfunktionale Architekten wissen, dass sie das Problem ihren Stakeholdern vor Augen führen und einen Kompromiss ermöglichen müssen.
Die Kämpfe Architekt beginnt mit der Systementwicklung. Testen des Systems anhand der Prioritäten. Diese Prioritäten sind in der Regel konkret und messbar, wie z. B. Kosten oder Zeitaufwand für die Änderung.
Der hochfunktionale Architekt betrachtet das System und versucht zu verstehen, welche Elemente die Kosten verursachen. Welche Teile sind schwer zu ändern? Welche Arten von externen Änderungen treten auf? Welche Defizite weist das System im Hinblick auf die Strategie auf? Der hochfunktionale Architekt erledigt seine Arbeit und analysiert ein System im Hinblick auf die Anliegen der Stakeholder.
Der Architekt, der sich schwer tut, präsentiert eine Änderung, die anhand eines einzigen Kriteriums optimiert ist. Normalerweise handelt es sich dabei um ein Systemdiagramm. Er erklärt die neue Architektur anhand der Vorteile für die Kriterien. Im Gespräch scheitert er jedoch. Er lässt den Stakeholder im Unklaren darüber, wie er einen komplexen Kriterienkatalog angehen soll.
Genau aus diesem Grund gibt es Unternehmensarchitektur. Helfen Sie den Stakeholdern, im Kontext widersprüchlicher Anliegen die beste Entscheidung zu treffen. Helfen Sie den Stakeholdern, ein komplexes System zu ändern. Helfen Sie den Stakeholdern, die Änderung so zu verwalten, dass der erwartete Nutzen erzielt wird.
Der hochfunktionale Architekt präsentiert ein praxistaugliches Modell, das den Stakeholdern die Auswirkungen einzelner Änderungen sichtbar macht. Der Stakeholder versteht die Änderungen. Wo entstehen Kosten? Wo geht die Agilität verloren? Wo geht die Ausrichtung verloren? Woher kommen die Auswirkungen der Änderungen?.
Der hochfunktionale Architekt hat Ansichten. Zumindest kann der hochfunktionale Architekt die Auswirkungen verschiedener Änderungsoptionen interaktiv erklären. Er kann praktisch als Modell fungieren.
Leitfaden für Unternehmensarchitekten
Laden Sie die Leitfaden für Unternehmensarchitekten Ein Leitfaden der TOGAF-Reihe zur Entwicklung nützlicher Unternehmensarchitektur.
Wenn ich mit Architekten arbeite, verbringen wir viel Zeit mit dieser Falle. Ich frage die Stakeholder nach ihren Anliegen. Ich frage, wie sich diese Anliegen auf das untersuchte System auswirken. Ich frage, wo sich die Kurven kreuzen – wo die Optimierung eines Anliegens einem anderen schadet.
Was ich tue, ist effektive Governance des Architekturentwicklungsprozesses. Stellen Sie die Fragen in der Governance-Checkliste:
- Nennen Sie Ihren Stakeholder
- erzählen Sie mir ihre Sorgen
- Erläutern Sie Ihre Architektur im Hinblick auf Anliegen
Ich bin auf einen Kampf mit den Architekten vorbereitet, die sich schwertun. Man sagt mir, dass es Priorität gibt! Man sagt mir, dass der Stakeholder eine Antwort erwartet! Ich bleibe immer standhaft. Ich kenne mich mit guter Unternehmensarchitektur aus.
Allzu oft muss ich ihnen zeigen, dass die Entwicklung der Architektur die Stakeholder einbezieht. Dass gute Enterprise-Architekten das System kennen. Sie wissen, welche Auswirkungen Veränderungen auf die wichtigsten Anliegen haben und welche Auswirkungen Nichtveränderungen haben. Dass wir die Stakeholder durch schmerzhafte Kompromisse führen müssen.
Vor ein paar Jahren hatten wir ein tägliches Meeting mit wichtigen Stakeholdern. Das EA-Team geriet in Panik. Wir hatten einen unangenehmen Kompromiss, der das Unternehmen mehrere Jahre lang vor Rätsel gestellt hatte.
Mein Team aus neuen Enterprise-Architekten geriet in Panik. Jeden Tag suchte mein Team nach einem Ausweg. Sie versuchten, eine Option zu finden, die der Realität trotzte. Jeden Tag gingen wir mit denselben Informationen an die Sache heran. Jeden Tag führten wir die gleichen Gespräche mit den Stakeholdern. Jeden Tag versuchten die Stakeholder, die Realität zu überwinden. Wir kamen zu einer Antwort. Sie war nicht schön.
Auf ein schwieriges Problem gibt es keine schöne Antwort.
Ich habe nie den Fehler gemacht, mit einer Änderung aufzutauchen, die nur auf ein einziges Kriterium optimiert war. Meine Änderung scheiterte nie, wenn wir ein zweites oder drittes Kriterium betrachteten. Aus diesem Grund hatte ich nie das Problem, dass die Stakeholder ihre Meinung änderten.
Stattdessen halfen wir unseren Stakeholdern, den besten Weg zur Verbesserung ihrer Organisation zu finden. Sie verstanden die Kompromisse und Auswirkungen ihrer Entscheidung. Sie konnten die folgenden Veränderungen steuern.
Enterprise-Architektur-Methoden wie TOGAF sind aus gutem Grund komplex. Sie helfen uns, das komplexeste Problem unserer Organisationen anzugehen: wie wir besser werden können.
Hochfunktionale Unternehmensarchitekten verfolgen die Diskussion stets. Normalerweise, weil sie sie leiten. Ohne eine künstliche Antwort kommt es nie dazu, dass die Stakeholder ihre Meinung ändern und neue Kriterien wählen.
