Bei der Einführung eines Enterprise Architecture -Programms denken viele zunächst an bekannte Rollen wie den CIO, CTO oder CDO. Doch gibt es noch zwei weitere wichtige Akteure, die über den Erfolg des Programms entscheiden können: der Alligator und der Richter. In diesem Artikel werfen wir einen Blick auf diese beiden Verhaltensweisen und ihre Auswirkungen auf den Start eines EA-Programms. Oftmals legen wir den Fokus auf komplexe Frameworks, Metamodelle und Rollenbeschreibungen, doch dies kann zu einem holprigen Start und einem frühen Scheitern. Anstatt nur auf die üblichen Empfehlungen zurückzugreifen, wollen wir hier eine psychologische Trickkiste öffnen.
Vorhang auf also für Alligator und Richter! Wer sind die Beiden und wie beeinflussen Sie die Einführung von Enterprise Architecture ?
- Schnelles, fast intuitives Verhalten (wobei Intuition sich später als falsch herausstellen kann)
- Einfache Entscheidungen im Sinne von leichter Beute, sofortiger Gefahr, ignorieren (das Meiste wird ignoriert)
- Eher unbewusstes Verhalten
- Bequemes Verhalten / bequeme Entscheidungen bevorzugt (weil die auch „billiger“ sind)
- Entscheidungen die Konzentration benötigen, daher ermüdend sind
- Energieintensiv, daher „teuer“. Dieses „Verhalten“ wird nur einzelfallbezogen eingesetzt, wird also eher vermieden
- Immer bewusstes Verhalten
- Entscheidungen sind immer schon vorbeeinflusst durch den Alligator, der Richter sucht eher nach den Entscheidungsgrundlagen, die die Vorbeeinflussung bestätigen (als umgekehrt). Nach dem Motto: “Habe ich doch gesagt”
Im Prinzip handelt es sich hierbei um die beiden kognitiven Prozesse des menschlichen Gehirns – darüber gibt es weitgehend Einigkeit unter den einschlägigen Experten. Übertragen auf die Welt von Enterprise Architecture bedeutet das nun folgendes: Per Se ist Enterprise Architecture aus o.g. Gründen ein Thema für den Richter, denn es ist einigermaßen komplex. Das kann zu folgendem Schluss führen:
Weil es eben so komplex ist, muss es auch gut und detailliert erklärt werden – mit all seinen unterschiedlichen Facetten wie eben verfügbare Frameworks, Reifegradmodelle und weiteres. Das führt dann häufig zu EA-Missionspapieren, vielseitigen Erläuterungen, umfassenden PowerPoint Präsentationen, Erklärungen mit vielen guten Detailargumenten – und all das ist… ermüdend für jeden. Es spricht den Richter an, der sich hineindenken, darauf konzentrieren, genau hinhören und abwägen muss.
Aber ist es überhaupt der Richter, der die erste maßgebliche Entscheidung trifft?
Sehen wir uns das doch einmal am Beispiel der Einführung von Enterprise Architecture an. Wenn man Zoe Chance glaubt, einer Schriftstellerin und Forscherin zum Thema zwischenmenschlicher Einfluss, dann ist es nicht der Richter. Sondern es ist der Alligator, der die meisten und immer die ersten Entscheidungen trifft. Der Alligator aber ist schnell und bequem und auf leichte Beute aus.
So gesehen ist es also wichtig, dass Enterprise Architecture ein leichter Happen ist und direkt in der Beißzone landet. Will man also Enterprise Architecture erfolgreich einführen (und hier geht es primär um die frühe Phase der Einführung), muss man es pragmatisch, einfach und direkt angehen und erklären. Man muss zuallererst den Alligator ansprechen. Wichtig hier nochmal: Alligator und Richter sind nicht zwei unterschiedliche Personen. Die Frage ist also nicht, wen Sie im Unternehmen zuerst ansprechen. Sondern es ist ein Vorstellungsmodell über Verhaltenspräferenzen derselben Person oder Personen, die Sie ansprechen wollen.
Was aber ist ein leichter Happen? Wie beurteilt man den „zu erleidenden“ Aufwand des Anderen (z.B. des Entscheiders oder Stakeholders) wenn man möchte, dass er sich mit Enterprise Architecture befasst, um z.B. sein Go für das Projekt zu geben oder zumindest erstes Interesse zu äußern? Eingängigkeit, Vertrautheit und Informationsmenge sind erste Hinweise. Damit gemeint ist jeweils folgendes:
Eingängigkeit
Es wird jedem sofort einleuchten, ein gutes Beispiel ist sicherlich der übliche Sommerhit: Jeder kennt ihn, kann mitsingen, im Takt wippen. Was auch meistens geschieht: Es ist ein eher „intuitives“ Verhalten, angestoßen durch einen leichten Happen wie eine bekannte, wohlklingende Melodie. Wohingegen beispielsweise die Reaktion auf einen sich nähernden Krankenwagen eher Richterverhalten auslöst. Laut Zoe Chance* sind hier mehrere Optionen abzuwägen: Kann ich nach links ausweichen? Rechts sind Fußgänger, nach vorne geht auch nicht, was also tun? Abwägungen, die man treffen muss. Das alles ist Aufwand, und Aufwand ist immer teuer und daher unerwünscht.
Wie soll man also die Einführung eines Enterprise Architecture Programms begründen bzw. einleiten, um Andere schon sofort dafür zu gewinnen?
Das ist ein relativ schwieriger Punkt: Wie macht man Enterprise Architecture zu einem Ohrwurm, zu einem Sommerhit? Am ehesten wahrscheinlich durch Konkretes, häufiges Wiederholen oder auch eingängige, leicht verständliche Ergebnisttypen, die sich etabliert haben: Dazu gehören beispielsweise Capability Maps, Gantt-Charts und Portfolioanalysen. Man würde am ehesten mit diesen argumentieren und erklären, was genau sie zeigen und inwiefern sie etwas zeigen, was man in dieser oder ähnlicher Form bisher nicht hatte und sie in den geschäftlichen Kontext des eigenen Unternehmens stellen. Idealerweise würde man nicht unbedingt Folien oder Illustrationen verwenden, die Enterprise Architecture konzeptionell erläutern wie beispielsweise Ebenenmodelle, Metamodelle oder Ähnliches. Sie sind oft zu schwer verdaulich für diesen Zweck. Wie gesagt, es geht weniger darum, dass abstrakte, konzeptionelle Darstellungen nicht auch korrekt sein können als vielmehr darum, einer Person, die möglicherweise dem Thema zunächst eher skeptisch gegenüber steht den ersten Einstieg leicht zu machen.
Vertrautheit
Bei aller Neugier auf Neues und Unbekanntes mögen viele Menschen doch das Vertraute / Bekannte, und gerade das fällt ihnen oft am meisten auf, dort schauen sie am ehesten hin: „Komisch, seit ich selbst einen habe fällt mir plötzlich auf, wie viele Golf IV noch fahren.“
Was heißt das genau für Enterprise Architecture?
Ich erinnere mich gut an die ersten 10 Fragen, die seinerzeit mein erster Kunde für Enterprise Architecture durch EA beantwortet haben wollte: Dies war auch die Aufgabenstellung an uns während des Startprojektes, aber eben auch ein Marketinginstrument nach innen: „Seht her, dass genau wird EA für uns tun“ – jedem in der Organisation waren diese 10 Fragen vertraut und auch der Umstand, dass Antworten darauf bisher schwer zu finden waren. Zu diesen Fragen zählten unter anderem:
Abhängigkeitsanalysen
Anwendung <X> muss ablöst oder modifiziert werden:
- welche Organisationseinheiten sind davon betroffen?
- welche Schnittstellen und Umsysteme sind betroffen?
Schwachstellenanalysen und Bebauungspläne
- Welche Systeme sind im Bereich <Rollmaterialbewirtschaftung> im Einsatz?
- Welche funktionalen oder datenmäßigen Überlappungen gibt es?
Bedarfs- und Projektkontext
Ein neuer IT-Bedarf wird gemeldet
- Soll eine neue Anwendung gebaut oder kann dieser Bedarf in eine bestehende Anwendung integriert werden?
Informationsmenge
Dies ist sicherlich der offensichtlichste Aspekt und dennoch sind viele Folien, die man zur Vorstellung einer Sache heranzieht, überladen. Es scheint oft eher so zu sein, dass man beim Erstellen der Folien eher sich selbst vergewissern möchte auch wirklich alles zu berücksichtigen als Mut zur Lücke zu haben. Das unterdrückt im Übrigen auch jede Phantasie und die anstehende Aufgabe ist es ja nicht, den Detailgrad einer Gebrauchsanweisung zu erreichen.
Weniger ist also mehr – wie beherzigt man das im Fall von Enterprise Architecture?
Lesen, Erfassen, Verstehen, Abwägen, Sortieren – sind relativ teure Vorgänge, die immer den Richter aktivieren würden. Am besten stellt man sich also vor, eine erste Präsentation für eine Person zu liefern, die an einem Donnerstag einer anstrengenden Woche um 16:00 bereits 5 Präsentationen und mehrere Meetings hinter sich hat. Der Alligator denkt dann schon: „Oh nein“, unwahrscheinlich, dass der Richter dann noch zum „ja“ schwenkt. Also: Eher weniger und mehr nur zum richtigen Zeitpunkt (sehr wahrscheinlich später).
Wer mehr über Alligator und Richter wissen möchte, dem kann ich das Buch „Influence is your Superpower“ von Zoe Chance empfehlen. Es war meine Hauptinspiration für diesen Blogartikel. Wenn ich das Gelesene mit meiner eigenen EA-Erfahrungswelt in Bezug setze und auch mit den von uns angewandten Einführungsmethoden abgleiche, finde ich viel Übereinstimmung. Das freut mich!
Diese oben vorgetragenen Grundgedanken spiegeln sich nämlich sehr gut wider zum Beispiel in unserem eigenen EA-Einführungsmodell, dass wir bereits seit einigen Jahren erfolgreich anwenden und das regelmäßig aktualisiert wird. Die Idee hierbei ist auch:
- Alles zunächst unnötig Komplizierte erstmal in die Zukunft schieben
- Davon ausgehen, dass Enterprise Architecture für viele andere erstmal Zusatzaufwand ist, mit dem sie sich befassen sollen (aber vielleicht nicht unbedingt wollen)
- Nutzen über Prinzipien – also eher weniger als mehr Frameworkorientierung in der ersten Phase
- Liefern für etwas, was vertraut ist: Idealerweise ein konkretes wichtiges Projekt
- Etwas liefern, das vertraut ist: Einschlägige EA-Sprache vermeiden, sondern verständlich und „nah am Mann“ bleiben
- Optimierung kommt später früh genug
Natürlich können wir das auch konkreter sagen. Unser Einführungsmodell spiegelt Erfahrungen vieler Projekte wider und wir wissen sehr gut, was man in den einzelnen Aufbauphasen jeweils tun und liefern sollte.
Wichtig: Dieses Modell ist natürlich immer noch generisch genug und somit leicht anpassbar an die jeweilige Situation. Wenn wir dieses Modell eingangs vorstellen ist es immer so, dass sofort unsere Ansprechpartner dies auf ihre jeweilige Situation übertragen, es startet immer eine (gewollte) Diskussion darüber, was als nächstes Sinn macht und nicht, was ein Framework vorgibt. Es ist kein Frontalunterricht, sondern ein Ideenauslöser.
Wer mehr darüber erfahren möchte (jetzt wird der Richter angesprochen): Wir bieten für alle EA-Anwendungsfälle sogenannte Playbooks, die immer noch einfach genug zu verdauen sind und trotzdem sehr gute erste Einblicke, Tipps und typische Lieferergebnisse zeigen – und die sich sehr gut in unser Vorgehensmodell einbauen lassen. Wenn Sie das interessiert, kontaktieren Sie mich gerne per mail pbruenenberg@mega.com oder buchen Sie ein kurzes Meeting mit mir:
Zusammenfassend kann gesagt werden, dass sowohl der "Alligator" als auch der "Richter" eine entscheidende Rolle beim Start eines EA-Programms spielen. Um erfolgreich zu sein, sollte man den Alligator ansprechen, indem man das Thema pragmatisch, einfach und direkt präsentiert. Eingängigkeit, Vertrautheit und die richtige Informationsmenge sind dabei wichtige Aspekte. Durch konkrete Beispiele, wiederholte Kommunikation und bekannte Ergebnistypen kann Interesse geweckt und erste Erfolge sichtbar gemacht werden. Es geht darum, den Alligator zu erreichen und ihn mit leicht verständlichen Informationen zu gewinnen, um den Erfolg des EA-Programms von Anfang an zu fördern.
*Chance, Zoe (2022): Influence is your superpower. Random House (p.29)
