Falle #67 Verwirrende Rollen

Der Spezialist steht da, spricht und geht davon aus, dass seine Sicht der Welt endgültig ist und wir uns ihm anschließen und nach seiner Pfeife tanzen. Normalerweise gibt es eine ernsthafte Diskussion über den Weg zur Umsetzung der Veränderungen des Spezialisten. Dann passiert nichts.

Der frustrierte Spezialist beruft erneut ein kleineres Meeting ein, das den gleichen Verlauf nimmt, ohne dass etwas passiert. Innerhalb kurzer Zeit schließt sich der Spezialist einer ruhigen Gruppe an, die sich gegenseitig über die ein wahrer Weg. Keiner von ihnen kann herausfinden, warum niemand zuhört – sie haben ihre Rolle als Fachexperte mit der Entscheidungsbefugnis von Interessenvertreter.

Rollenverwirrung ist einer der Hauptgründe für die Erfindung der Enterprise Architecture. Wenn lokale Interessen oder Expertenmeinungen tatsächlich zu einer besseren Welt führen würden, bräuchten wir den Aufwand einer Enterprise Architecture nicht. Echte Architekten sprechen mit Entscheidungsträgern und liefern die Informationen, die sie für eine fundierte Entscheidung benötigen. Anschließend unterstützen sie die Steuerung und Kontrolle des daraus resultierenden Veränderungsprogramms.

Eng verbunden mit Falle 1: Entscheidungsrechte besitzen ist die Rollenverwirrung. Das Ergebnis ist dasselbe: Es wurde keine ernsthafte Architekturentwicklung durchgeführt – der eigentliche Schaden liegt darin, Kompromisse und die Nachvollziehbarkeit der Spezifikation zu vernachlässigen. Wir bringen das Änderungsprogramm durcheinander; typischerweise sieht sich die Organisation mit willkürlichen Prioritätenänderungen und Diskussionen über die Eignung von Entscheidungen konfrontiert, ohne dass ein Entscheidungsrahmen vorhanden ist, der auf nachhaltigen Wert hindeutet.

Rollenverwirrung ist in schlecht funktionierenden EA-Teams weit verbreitet. Die Klärung der verschiedenen Rollen, die an der Erstellung und Nutzung der Architektur beteiligt sind, ist einer der wichtigsten Schritte in Entwicklung eines hochfunktionalen EA-Teams.

Im Grundlagen der Architektur-Governance, und in der TOGAF Enterprise Architect's Guide Wir haben eine Reihe von Schlüsselrollen identifiziert, die an der Architekturentwicklung beteiligt sind:

• Interessenvertreter
• Stakeholder-Agent
• Entscheidungsträger
• Fachexperte
• Implementierer
• Wirtschaftsprüfer

Die häufigste Rollenverwirrung tritt auf, wenn ein Praktiker, der Fachexperte oder Implementierer beanspruchen Genehmigungsrechte, indem sie die Rolle von Stakeholder-Agent. Sie präsentieren ihre Pfarrpräferenzen als vollendete Tatsachen mit der Kraft bewährter Architektur.

Gute Architekten wissen, dass Unternehmensarchitektur ist nicht für ein einzelnes Anliegen optimiert. Gute Architektur erfüllt die Präferenzen der Stakeholder durch aktiven Kompromiss zwischen Architekturalternativen im Kontext der Ziele und Strategie der Organisation. Die Architekturentwicklung berücksichtigt explizit die Anliegen der Stakeholder, die sich in der Entwicklung von Ansichten.

Eine gute Architekturentwicklung gleicht die Präferenzen der Stakeholder durch Kompromisse aus. Ein großer Teil des Wertes einer guten Architektur entsteht durch den Kompromissprozess, bei dem der potenzielle Wert des Ziels mit den Auswirkungen und Kosten der Veränderung verglichen wird. Wenn die Genehmigungsrolle künstlich beansprucht wird, wird der Kompromiss kurzgeschlossen. Schlimmer noch: Alle Analysen werden aus der Perspektive der Fachexperten Spezialgebiet oder Implementierungs- und Betriebsherausforderungen.

Normalerweise Fachexperten und Implementierer verwirrende Rolle denken, sie handeln als Architekt, unter dem Missverständnis, dass Architekt eigene Entscheidungen trifft. Ein klassisches Zeichen dieser Rollenverwirrung ist das Versäumnis, eine Architektur bereitzustellen (Siehe Falle #16 Nur das Diagramm). Bei der Architektur-Governance kommt es leicht zu Rollenverwirrungen, wenn derjenige, der die Bedenken der Stakeholder, sorgen Sie für eine klare Ausrichtung auf Ziele und Strategie oder identifizieren Sie den eingegangenen Kompromiss.

Die gefährlichste Ausprägung dieser Falle ist, wenn die Enterprise-Architekt wird durch ihr Wissen und ihre Erfahrung aus früheren Kompromiss- und Implementierungs-Governance-Aktivitäten verführt und fungiert als Stakeholder-Agent. Theoretisch testen wir immer mit Interessengruppen. Wir müssen die Architekturentwicklung regelmäßig abkürzen und mit *Stakeholder-Agenten* zusammenarbeiten.

Wenn er verführt wird, eignet sich der kämpfende Unternehmensarchitekt die Stakeholder exklusive Entscheidungsrechte. Angesichts der Tatsache, dass *Architekten* regelmäßig als Stakeholder-Agenten Wenn man die Implementierungs-Governance abkürzt und taktisch durchführt, schleicht sich diese Falle auch an die sorgfältigsten Praktiker heran. Wenn sie mehr Erklärungen im Namen von Interessengruppen, Der *Architekt* wird selbstbewusster und identifiziert sich mit den Prioritäten der Schlüssel Interessengruppen.

Die Lösung für diese Falle ist effektive Governance des Architekturentwicklungsprozesses. Selbst das informelle Durchgehen der Governance-Checkliste wird guten Praktikern zeigen, wann sie verführt wurden: wenn sie keinen Kompromiss zwischen konkurrierenden Präferenzen formulieren können, wenn sie keinen Standpunkt für mehr als eine *STaker.

In der realen Welt ist das Ziel nie perfekt auf ein einzelnes Ziel, eine einzelne Zielsetzung, eine einzelne Interessenvertreter Präferenz oder Fachexperten Veranlagung. Ist es ein Kompromiss, der die beste Übereinstimmung mit den Zielen, Zielsetzungen und Interessenvertreter Präferenzen; alles informiert durch Fachexperten’ Beratung. Wir erreichen diese optimale Übereinstimmung, indem wir genau wissen, welche Rolle im Spiel ist.

Normalerweise Fachexperten und Implementierer verwirrende Rolle denken, sie handeln als Enterprise-Architekt, unter dem Missverständnis, dass der Architekt eigene Entscheidungen trifft. Ein klassisches Zeichen dieser Rollenverwirrung ist das Versäumnis, eine Architektur bereitzustellen (Siehe Falle #16 Nur das Diagramm). Bei der Architektur-Governance kommt es leicht zu Rollenverwirrungen, wenn derjenige, der die Bedenken der Stakeholder, sorgen Sie für eine klare Ausrichtung auf Ziele und Strategie oder identifizieren Sie den eingegangenen Kompromiss.

Die Lösung für diese Falle ist effektive Governance des Architekturentwicklungsprozesses. Schon das informelle Durchgehen der Governance-Checkliste wird guten Praktikern zeigen, wann sie verführt wurden: wenn sie keinen Kompromiss zwischen konkurrierenden Präferenzen formulieren können, wenn sie keine Ansicht für mehr als eine Interessenvertreter*.

Wenn Sie damit Probleme haben, empfehlen wir Ihnen, eine Stakeholder-Workshop um festzustellen, wer welche Rolle spielt, und um den Unterschied zwischen Beratung und Entscheidung zu verdeutlichen.