Enterprise-Architektur

Anja: Hallo und herzlich Willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und heute spreche ich mit André Aulich über Enterprise Architektur.

André, was machst du denn bei INNOQ und vor allem, was ist dein beruflicher Background?

André: Hallo Anja. Ich bin Senior Consultant, beschäftige mich gerne mit Enterprise Architektur Themen, insbesondere auch Enterprise Architektur Management und bin über die Jahre immer mehr in diese Rolle reingekommen. Ich habe ursprünglich mal Jura studiert, was vielleicht ungewöhnlich ist, weil die meisten Enterprise Architekten, die ich kenne, sonst eher aus dem Informatikbereich kommen. Und habe aber natürlich in der Zeit auch schon ganz viel in der IT gearbeitet und dann, als ich mit dem Studium fertig war, die IT-Karriere weiterverfolgt. Das war also nichts Neues und das lief sowieso parallel.

Und hab dann angefangen, viel im Fernsehumfeld zu machen, Kunden beraten in der Richtung Speicher-Systeme, was müssen sie tun, um Fernsehabläufe zu verwirklichen. Hab dann auch Software entwickelt und Vertrieb dafür aufgebaut, um die Dinge dann auch irgendwie unters Volk zu bringen sozusagen. Und hab dann innerhalb der Projekte gemerkt, es geht auch um ganz viele Dinge, die nicht nur mit der technischen Lösung zu tun haben, sondern auch damit, wie kriege ich die Dinge denn auch wirklich umgesetzt. Also nicht nur Projektmanagement, sondern auch, haben wir das richtige Budget, tun wir das Richtige, erreichen wir mit dem, was wir tun, denn auch die Ziele, die das Unternehmen erreichen möchte. Und dann kamen immer mehr Themen, die den Scope von der Technik dann halt ein bisschen erweitert haben.

Und im Laufe der Jahre, würde ich sagen, nannte sich das dann irgendwann Enterprise Architektur. Es gibt bestimmt verschiedene Bildungswege. Bei mir kam das halt aus der Praxis heraus sozusagen und hat dann zuletzt bei einem großen Tiernahrungshändler die Enterprise Architektur auch aufgebaut und ein paar Jahre geleitet. Und bin seit September 2023 bei INNOQ und bau das Beratungsthema dazu aus.

Anja: Du baust das Beratungsthema zur Enterprise Architektur aus?

André: Genau. Wir haben viele Kunden, würde ich sagen, die sehr gute Vorstellungen haben, was sie technisch bauen wollen. Und da machen wir auch ganz viel. Ich sehe am Markt insgesamt oft einen Bedarf, die Ziele des Unternehmens noch besser zu verbinden mit dem, was am Ende produktiv dann dabei herauskommt. Das heißt, wenn Software entwickelt wird, die vielleicht genau die Anforderungen erfüllt, die wir mal definiert haben, dann kann es schon mal sein, dass ein Stakeholder sagt, wir hätten aber ganz gerne noch ganz andere Ziele erreicht. Vielleicht ein Stakeholder, der im Unternehmen gar nicht die größte Rolle gespielt hatte bisher in einem Projekt, weil es halt in einem großen Konzern sehr viele Sichten gibt, sehr viele Zieloptimierungen. Abteilungen haben ja verschiedene, wie soll ich sagen, nicht nur Aufgaben, sondern sie sollen halt wirklich in ganz verschiedene Richtungen optimieren. Einen Einkauf zum Beispiel soll Kosten gering halten. Legal und auch Compliance müssen gucken, dass man die gesetzlichen Bestimmungen einhält. Andere wollen wieder die Kundenreichweite erhöhen und so. Und all diese Dinge sind halt teilweise so weit entkoppelt, dass wenn ein Auftrag aus einer Ecke entsteht, also auch intern, ohne dass man jetzt externe Beratungen hat, oft die Dimensionen der anderen Unternehmensteile gar nicht zur Berücksichtigung finden. Und Enterprise-Architekten haben, und da kommen wir jetzt schon zu der Frage, was machen wir eigentlich, eigentlich die Kernaufgabe zu sagen, wir versuchen, möglichst viel zu verstehen, was im Unternehmen auf allen Ebenen los ist, und aus diesen teilweise sich widersprechenden Zielen eine gemeinsame Handlung abzuleiten. Das ist aus meiner Sicht auch schon der Kern der Enterprise-Architektur.

Anja: Und aber schon auch mit einem technischen Fokus.

André: Ja. Also bei rein fachlichen Fragen macht es teilweise schon Sinn, wenn Enterprise-Architekten dabei sind, aber eher unter dem Aspekt, dass alles, was fachlich passiert wird, heute eigentlich IT-unterstützt ist. Und wenn du weißt, was dein Unternehmen technisch leisten kann, dann kannst du auch bessere Entscheidungen treffen. Und Enterprise-Architekten versuchen eben genau das, Informationen aus allen Richtungen einzusammeln und in Relation zueinander zu setzen. Das heißt, wenn ich eine fachliche Frage klären möchte, zum Beispiel möchte ich einen neuen Geschäftsbereich eröffnen oder möchte ich eine weitere Firma einkaufen, die mein Portfolio vielleicht ergänzt, dann kann es sehr helfen, wenn ich weiß, zum Beispiel die Integration einer weiteren Firma durch Merger and Acquisition ist einfach möglich, weil wir halt Abläufe haben, Technologien, die vergleichbar und integrierbar sind. Wir haben vielleicht auch Prozesse schon auf IT-Seite, die das umsetzen. Da gibt es natürlich auch ganz viele andere Abteilungen, die da mitsprechen. Und die Enterprise-Architektur ist jetzt nicht die einzige Abteilung im Unternehmen, die man braucht, weil die alles kann. Aber sie sollte von allem so ein bisschen mitbekommen haben, was eigentlich leistbar ist. Und das hilft dann auch bei Entscheidungen, wo vielleicht der IT-Anteil auch sogar manchmal gering sein kann. Einfach, weil dann halt bei der Entscheidung klar ist, die IT steht uns zum Beispiel jetzt nicht als Hindernis oder so im Weg.

Anja: Ab wann braucht man denn eine Enterprise-Architektur und Enterprise-Architekt?

André: Das ist eine sehr gute Frage. Ich würde fast sagen, es gibt keine Standardantwort darauf. Ab einer gewissen Unternehmensgröße wird es irgendwann schwierig, die verschiedenen Abteilungen zu einer gemeinsamen Sicht zusammenzuführen. Dann macht es irgendwann Sinn zu sagen, wir brauchen ein paar Leute, die Dinge, die von Interesse für Entscheidungen sind, irgendwie in Relation setzen. Das können ein paar tausend Mitarbeiter sein, die man hat. Es kann aber auch gut sein, dass man schon bei 100 Leuten sagt, wir brauchen jemanden, der eine gemeinsame Sicht entwickelt auf alles. Das muss vielleicht auch nicht mal unter dem Titel Enterprise Architektur geschehen, aber irgendjemand muss Dinge in Relation setzen und sagen, wenn ich zum Beispiel eine neue Geschäftsfähigkeit entwickeln möchte, weil sich das gut für mein Geschäft macht und ich möchte wissen, habe ich schon Leute und Technologien, die ich dafür nutzen kann oder muss ich was ganz Neues anschaffen, dann muss ich irgendjemanden damit beschäftigen. Und ich würde fast sagen, ich habe auch selbst schon in Unternehmen oder in Projekten gearbeitet, wo wir offiziell keine Enterprise-Architekten dabei hatten. Da waren wir eher so als Solution-Architekten unterwegs, haben dann aber komplette Fernsehsender mit einer Handvoll Leuten durchgeplant. Und da war das so, dass halt jeder wusste, was will denn der Kunde erreichen, was gehört grundsätzlich zu einem Fernsehsender dazu und wie greifen die Domänen ineinander. Wie sind die technisch und organisatorisch miteinander verbunden? Und dann konnten wir auch da halt aussagekräftige Informationen liefern, die dann gute Entscheidungen herbeiführen konnten bei anderen.

Ich glaube, also die Denke, die man als Enterprise Architekt mitbringen muss, ist ja eigentlich, dass ich sage, ich versuche ein Problem oder eine Fragestellung von möglichst vielen Perspektiven auszuleuchten, um dann eine bessere Entscheidung zu treffen. Und diese Herangehensweise hast du ja eigentlich auch schon, wenn du alleine bist, also als Einzelunternehmer.

Trotzdem ist es ja unwahrscheinlich, dass ein Einzelunternehmer sagt, der erste Mitarbeiter, den ich dazu nehme, wird ein Enterprise-Architekt sein. Genau. Also, jetzt habe ich weit ausgeholt. Also, dass es eine dedizierte Abteilung gibt an Enterprise-Architekten, da sind wir schon eher auf einer Konzern-Ebene, würde ich sagen, wo dann schon ein paar tausend Mitarbeiter vorhanden sind. Genau. Wenn man das so sieht. Entschuldigung.

Anja: Ja. Okay. Aber ich kann mir auch vorstellen, sobald Schmerzen da sind, die typischerweise eine Enterprise Architektin, ein Enterprise Architekt lösen könnte, da lohnt es sich darüber nachzudenken, in solchen Rollen zu denken oder solche Rollen zu suchen, oder?

André: Ja, also tatsächlich ist das spannend, warum, also unter welchen Umständen kommt man auf die Idee, einen Enterprise-Architekten dazu zu holen. Und oft ist es so, es gibt schon irgendwelche Schmerzen, irgendwelche Dinge, wo man denkt, da würde ich gerne mal ran. So wird es ja häufig sein, wenn ich noch niemanden habe, der im Unternehmen sofort hier schreit, wenn ich mit einem Problem komme. Dann werde ich weiter suchen, bis ich eine Lösung habe, wie mich dieses Problem dann halt zuführen kann sozusagen. Und ich glaube, es kursieren halt einfach Informationen, die halt, also im Netz und auch in den Unternehmen, Beratungsunternehmen kommen dann auch mit Vorschlägen. Und am Ende werden dann Dinge, die an der Grenze zwischen Strategie, Organisation und Technologie sind, häufig mit Enterprise-Architektur verbunden.

Das ist nicht die einzige Rolle, die da relevant ist, aber schon eine, die immer wieder erwähnt wird und auch einen guten Beitrag leisten kann. Und dann kommt halt ein Enterprise-Architekt ins Spiel.

Anja: Welche Rollen sind dann da noch interessant? Du hattest gesagt, das ist nicht die einzige. Welche sind da noch interessant?

André: Es hängt halt tatsächlich von den Ausgangsschmerzen ab sozusagen, also der Problemstellung. Es ist wirklich vielfältig. Also wenn ich zum Beispiel sage, ich möchte, mein Unternehmen wächst sehr stark und wir müssen jetzt, um vielleicht noch in weitere Märkte vorzudringen, noch weitere Unternehmen kaufen.

Dann wird sehr schnell die Frage aufkommen, natürlich welche Firmen sind das? Das sind rein fachliche Fragen, die da erstmal in Frage kommen oder aufkommen. Aber dann kommt irgendwann der Punkt, passt das kulturell? Kann ich mit den Firmen, die ich aufkaufe?

Kann ich die wirklich integrieren? Dann kommen Sachen wie Human Resources, vielleicht auch Transformationsmanagement und so, Projektmanagement und natürlich auch Leute, die über Kosten nachdenken und so was, wie wird so ein Unternehmen bewertet und so. Und Enterprise Architekten haben dann häufig die Rolle zu überlegen, kann man diese Dinge technisch integrieren? Wie sind auch die technischen Abläufe innerhalb der IT? Zusammenarbeitsmodell und Ähnliches. Und das sind dann die Standarddinge.

Und dann glaube ich, kommen aber auch noch Dinge wie, welche persönlichen Erfahrungen haben die jeweiligen Personen in den verschiedenen Rollen schon gemacht. Weil ich glaube, dass eine Enterprise-Architekturrolle schon dafür sich eignet, auch über den Tellerrand hinauszusehen. Je nachdem, wie man die Enterprise-Architekturrolle genau definiert, können auch rechts und links Aufgaben entstehen, die vielleicht jemand anders mehr oder weniger macht, wo dann Enterprise-Architektur vielleicht mehr oder weniger reingeht, wo sich Rollen dann ergänzen. Das ist grundsätzlich so ein Thema, dass Rollen nicht unbedingt Personen sind, sondern individuelle Stärken, Erfahrungen und so weiter auch dazu führen, dass man rechts und links vielleicht noch mehr oder weniger macht. Und insgesamt dann als Team von Beteiligten dann halt eine Aufgabenstellung löst. Aber diese Brücke halt zu leisten, dass jemand etwas geschäftlich erreichen will und ich gucken muss, kann ich das denn auch wirklich tun? Weil zum Beispiel Schnittstellen direkt so gebaut sind, dass ich gut integrieren kann. Da kann ein Enterprise-Architekt schon viel zu sagen.

Ja, das wäre jetzt aber ein Beispiel nur mit Merger & Acquisition Themen. Also ein anderes Beispiel, was auch immer wieder vorkommt, dass Unternehmen sagen, wir müssen jetzt auf Effizienz achten. Es gibt dann Zeiten, das Wachstum ist irgendwie gebremst, weil der Markt sich sättigt mit dem Modell, was ich gerade entwickelt habe. Und dann kommt der Punkt, wo ich sage, die Kosten müssen in den Griff zu bekommen sein. Und dann gibt es natürlich organisatorische Dinge, da sind dann halt ich sag mal normale Management-Aufgaben halt einerseits dabei, da sind auch People-Management-Aufgaben dabei. Insbesondere dann auch technische Konsolidierung und auch Dinge dann, die aus der IT entstehen, wo dann drüber nachgedacht wird, kann ich Dinge vor die Klammer ziehen und so. Da kommen wir dann schon schnell in den Bereich Enterprise-Architektur, aber insbesondere halt auch auf Dinge wie Solution-Architektur, Prozessmanagement vielleicht auch. Also gerade wenn ich übergreifende Themen habe, wo mehrere Teams beteiligt sind, sind sehr gerne Prozessmanager dabei, die halt oder auch Businessanalysten die sagen, dass ein Kunden-Workflow oder eine User Journey über mehrere Teams geht. Lass uns doch mal schauen, wie wir erstmal die User Journey optimieren und dann stellt sich raus, dass alle mit einer zentralen Kunden-ID arbeiten, wo wir vielleicht fünf haben bisher, können wir das nicht vor die Klammer ziehen oder so.

Also da sind dann, je nachdem, worum es genau geht, immer unterschiedliche Teams, die dann zusammenarbeiten müssen. Und wie gesagt, der Enterprise Architekt hat grundsätzlich oft die Aufgabe, diese Sichten zusammenzuführen und in Relation zu setzen, also insbesondere Organisation und Technologie.

Genau, die konkrete Aufgabe und auch die Artefakte sozusagen, der Liefergegenstand, das kann sich sehr, sehr stark unterscheiden, je nachdem, was ich gerade erreichen möchte. Das macht auch, glaube ich, den Beruf so schwer greifbar, weil je nach Aufgabenstellung so unterschiedlich ist, was man tut.

Anja: Lieferartefakt hast du gerade gesagt. Ich hatte jetzt im Kopf, dass Entscheidungen von Enterprise-Architekt gefällt werden dürfen. Erarbeiten sie nur Entscheidungspapiere?

André: Das ist auch wieder sehr unterschiedlich. Ich erinnere mich daran, dass ich in einem Umfeld mal das Mandat hatte, dass es hieß, wir verantworten die Gesamt-IT. Und da war auch die Erwartungshaltung, dass wir die finalen architektonischen Entscheidungen treffen könnten. Ich habe mich dagegen sehr gesträubt. Einfach deswegen, weil man ja auch möchte, dass die Entscheidungen, die dann getroffen werden, am Ende in die Umsetzung kommen.

Und meine Erfahrung war, dass Entscheidungen viel, viel mehr Anhänger finden und auch viel höhere Umsetzungswahrscheinlichkeiten haben, wenn man die Beteiligten halt gemeinsam entscheiden lässt. Das kann man jetzt ganz platt sagen. Das klingt total gut und schön. Aber geht das überhaupt? Kann man gemeinsam entscheiden? Sind die richtigen Informationen vorhanden und kommt dabei was Gutes raus? Und ich glaube, das geht. Aber man kriegt es halt nicht geschenkt. Es ist nicht so, dass man sagen kann, ich lasse andere entscheiden und kümmere mich nicht drum.

Anja: Ja, ich kann mir vorstellen, dass genau das Herbeiführen von Entscheidungen, dass die herausforderndste Arbeit daran ist. Hast du da ein paar Stories aus der Praxis?

André: Also ja, ich überlege gerade, welche da am besten passt. Also erinnere mich dran, falls ich jetzt abschweife. Also ich glaube, die Herausforderung ist genau das, was ich vorhin schon mal erwähnt habe.

Es geht nicht um Entscheidungen, die ein kleines Team alleine treffen kann, wo komplette Autonomie möglich ist, weil dafür brauche ich wenig Enterprise-Architektur oder auch besser gar keine. Es geht meistens um Dinge, die mehrere Teams treffen, vielleicht auch ganze Abteilungen und so.

Es gibt ja diesen Spruch, dass man sagt, eine Firma ist organisierter Konflikt. Und das muss nicht negativ gemeint sein. Konflikt muss ja nicht negativ ausgetragen sein, sondern es geht darum, dass Interessenkonflikte gewollt sind in einem großen Unternehmen.

Warum habe ich Marketing? Ich will Reichweite erhöhen. Warum habe ich jemanden, der aufs Accounting achtet? Weil ich die Kosten auch im Griff haben möchte. Das sind aber Zielkonflikte. Und wenn ich jetzt eine Seite alleine entscheiden lasse, habe ich entweder eine unglaubliche Reichweite zu unmöglichen Kosten oder ich habe ganz viele Kosten gespart, aber keinen einzigen Kunden. Also wenn man es jetzt mal ins Extrem treiben würde. Es geht also darum, diese Interessen in einem Unternehmen auszubalancieren.

Und das gehört aus meiner Sicht zu einer der Kernkompetenzen eines Architekten, zu sagen, ich soll ja das Problem, was ich lösen soll, von vielen verschiedenen Perspektiven erst mal erarbeiten, also beleuchten und dann also diese Ziele verstehen, die im Raum sind, erst mal gucken, wer hat überhaupt Interessen an einem Thema, welche Sichten gibt es da drauf und welche Dinge muss ich auch wirklich realisieren mit einer Entscheidung.

Und dann zu schauen, welche Entscheidung liegt irgendwo im Lösungskorridor. Weil auch da es gibt nicht den einen Weg, der geht und alle anderen sind schlecht, sondern es gibt meistens einen ganzen Weg voller Lösungen. Und das muss irgendwie zu den Leuten passen, die da beteiligt sind. Und da glaube ich, dass es auch zum Großteil eine menschliche Komponente ist. Also wir entwickeln Lösungen mit Menschen, für Menschen. Also von diesen drei Ebenen sind zwei Ebenen Menschen.

Und das ist, glaube ich, tatsächlich der größere Teil auch der Architekturarbeit, insbesondere auch der Enterprise-Architekten, rauszufinden, was ist eine Lösung, die in dem Umfeld erstmal machbar ist, also eine Entscheidung, die ich treffen kann und die ich dann auch umsetzen kann. Da ist sehr viel Kommunikation wichtig und dann aber auch, wie soll ich sagen, da können dann Dinge dabei rauskommen, wo jeder einzelne beteiligte Techniker sagt, ich hätte mir gerne noch mehr gewünscht, es würde auch jeder Manager wahrscheinlich irgendwie sagen, ich hätte mir aus meiner einzelnen Perspektive noch mehr gewünscht.

Aber die Frage ist immer, wie kann ich aus all diesen Perspektiven eine gemeinsame Handlung ableiten, die wirklich für alle am besten funktioniert und insbesondere die Unternehmensziele am besten realisiert. Und je nachdem von wo man guckt, sieht das besser oder schlechter aus, was man da macht.

Anja: Funktioniert das denn immer ganz gut? Ich kann mir vorstellen, dass es da auch politische Herausforderungen gibt.

André: Ja, das ist so. Also ich glaube, das hängt auch wieder sehr an den Beteiligten, wie gut sie halt einen Weg finden zu kommunizieren. Und es hängt auch sehr stark an der Firmenkultur. Also ich glaube, dass für mich die Firmenkultur sich auch zum großen Teil daran festmacht, wie wir gemeinsame Entscheidungen treffen. Also wir haben Interessenskonflikte, die gewollt sind. So ist ein Unternehmen aufgebaut in der Regel und müssen aber trotzdem uns auf eine gemeinsame Handlung einigen. Und da ist die Frage, ist dieser Weg dorthin total angenehm, weil allen klar ist, wir sind im selben Unternehmen und haben ein Ziel, was wir insgesamt verfolgen, oder versuchen wir, also unter allen Umständen, das ursprünglich definierte Ziel meiner Abteilung oder meiner eigenen Person irgendwie durchzusetzen und auch so, dass Spannungen entstehen. Und ja, ich glaube, eine richtig heile Welt, wo sich alle anlächeln auf dem Weg dorthin, die wird es nie geben. Das ist auch nicht total schlimm. Hauptsache, man kommt dorthin, dass man am Ende eine gute Entscheidung trifft, die die richtigen Dinge ermöglicht.

Ich war mal in einem Projekt, wo eine Person, sag ich mal, sich nicht vorstellen konnte, das Problem wirklich so zu lösen, wie es alle anderen wollten. Und es stellte sich dann raus, dass am Ende sehr persönliche Interessen halt eine Rolle spielten, die halt, also was heißt sehr persönlich, sie waren schon durch die Organisation bedingt, da ging es um Zielvereinbarungen und so.

Und dann halt zu merken, dass es gar nicht auf die Rollen oder Abteilungen ankommt, sondern wirklich auf die individuellen Bedürfnisse der Einzelperson. Das war in diesem Fall, also es war mein erstes Projekt, wo ich gemerkt habe, es reicht nicht auf Organisation, Rollen und definierte Ziele der Abteilung zu schauen. Ich muss mir auch anschauen, was die Individuen wollen.

Am Ende ging das gut aus, es war halt ein langer Weg dorthin, weil das ist halt einer der wichtigen Punkte auch bei Enterprise Architekten. Ich glaube, die Qualität einer Enterprise Architektur bemisst sich daran, wie viel sich in der Produktion ändert, also wie viele der guten Dinge, die irgendwo an Ideen entstehen, ändern wirklich das, was dann produktiv geht. Und damit man dorthin kommt, muss man schon sehr viel auf Machbarkeit irgendwie achten und insbesondere auch schauen, wie kriege ich denn vielleicht eine Lösung, die die Mehrheit will, die auch die Ziele des Unternehmens gut bedient, an jeden verkauft.

Also bei denen, die ursprünglich dabei sind, sollte man schauen, wie sind die individuellen Interessen und Vorlieben der einzelnen Personen? Wie passt das zu den Zielen des Unternehmens? Und dann findet man im Rahmen dieses breiten Lösungskorridors vielleicht eine Lösung, die die meisten sowieso gerne wollen, weil sie irgendwie sich selbst darin wiederfinden. Das ist schon sehr aufwendig. Und dann hat man halt noch den Punkt, dass es Leute gibt, die sich da nicht wiederfinden, aber die dann so in der Minderheit sind, dass man sagt, wir müssen das jetzt trotzdem tun, weil es das Richtige ist für das Unternehmen. Und auch da dann zu sagen, wie komme ich denn dahin, dass sie sich trotzdem irgendwie committen können, ohne es zu boykottieren, heißt halt auch wieder, persönliche Interessen irgendwie finden, die zum Unternehmen passen. Das finde ich sehr aufwendig.

Anja: Das heißt, zusätzlich zu diesem jetzt schon sehr breiten Aufgabenfeld muss ich auch noch Erfahrung im Change Management mitbringen als Enterprise Architekt.

André: Es wäre gut, wenn irgendjemand beteiligt ist, in dem Prozess, der das kennt. Man könnte es auch einfacher formulieren, vielleicht und sagen, man sollte sich für die Menschen, mit denen man arbeitet, interessieren.

Anja: Etwas, was ich in Unternehmen oftmals sehe, ist, dass beispielsweise das Ziel gibt, in die Cloud zu gehen. Es gibt Gründe dafür, aber die sind sozusagen eher nur so vage formuliert. Und oftmals fragt man dann nach einer Cloud-Strategie, nach irgendeinem Papier oder nach irgendeiner Definition, was jetzt die Cloud-Strategie ist. Und die fehlt dann oftmals. Und bevor man dann eigentlich in Umsetzung gehen kann, muss man erst einmal gemeinsam mit dem Unternehmen diese Cloud-Strategie erarbeiten, weil das gar nicht auf dem Schirm war. Und ich habe ja die Hoffnung, dass Enterprise-Architekten genau so etwas formulieren würden. So eine Cloud-Migration-Strategie oder so eine Cloud-Strategie.

André: Also ich finde die Frage sehr spannend, weil du hast jetzt das Wort Strategie beschrieben. Davor oder damit verbunden kommt auch noch das Thema Ziele halt auf und wie entstehen Ziele? Ich habe den Eindruck, es gibt immer wieder Projekte, die entstehen. Ich würde sie jetzt mal ein bisschen übertragen auf einen anderen Bereich, die in der Form gestaltet sind, dass man sagt, wir bauen hier ein Schwimmbad. Seht bitte zu, dass dieses Schwimmbad besonders gut geeignet ist für Schulsport. Und dann planen wir das alles durch und es ist wirklich perfekt geeignet für Schulsport. Dann wird es gebaut und wird dann eingeweiht und dann stellt sich heraus, die nächste Schule ist irgendwie 200 Kilometer entfernt.

Und genau, also das ist natürlich eine Sache, die ein bisschen überspitzt ist, um es nochmal deutlicher zu machen. Aber es kann passieren, dass wir vielleicht nicht das tun, was eigentlich das Unternehmen erreichen will, sondern dass wir irgendwas anderes machen, das dann gut machen, aber eigentlich nicht die richtigen Ziele erarbeiten. Und das ist das Gleiche für mich mit einer Cloud-Strategie. Es gibt halt manchmal Dinge, dass man sagt, wir wollen eine Multi-Cloud-Strategie vielleicht oder irgendwie ganz bestimmte Dinge, die für irgendjemanden gut klingen. Weil irgendjemand mal gesagt hat, das würde ja gut zu euch passen. Es gibt vielleicht auch einen Mitbewerber, der was Ähnliches vorhat oder sowas halt. Und ich glaube, es kommt immer darauf an, wirklich konkreter zu werden, zu überlegen, wo geht für dieses Unternehmen die Reise hin? Und was brauchen wir dafür?

Und das muss jetzt auch nicht zwingend die Enterprise-Architektur sein, die damit anfängt. Aber irgendjemand muss diese etwas abstrakteren Ziele mal definiert haben und vielleicht auch eine Strategie definiert haben. Und Strategie ist für mich dann, wenn die Ziele klar sind, wie kann ich diese, also ohne zu konkret zu werden, über ein paar Jahre formulieren, um halt schon mal zu überlegen, wo muss ich Arbeit und weitere Ressourcen reinstecken, also wie auch Geld und Ähnliches.

Und an der Stelle können Enterprise-Architekten dann dabei sein und sagen, also auch vielleicht bei der Zielentwicklung schon, aber spätestens bei der Strategieentwicklung und sagen, wir können halt mit dem, was wir haben, im Verhältnis zu dem, was wir haben wollen, mit folgenden Aufwänden irgendwie arbeiten. Und dann kann sowohl die Strategie als auch danach dann die taktische Planung, also Projekte und Ähnliches mit Unterstützung der Enterprise-Architekten erarbeitet werden. Und ich glaube, da ist auch für Entwickler einer der großen Mehrwerte, die eine Enterprise-Architektur leisten kann, wenn das so funktioniert.

Weil dann halt eben die Entscheidung, dass, also wenn ich ein Projekt beginne, ich damit rechnen kann, dass das wirklich das Richtige fürs Unternehmen ist, dass Budgets dann halt gesichert werden, dass es halt auch Erfolge bringt und so, weil diese Kette von den Zielen bis in die Entwicklung dann sichergestellt werden kann. Genau, und dann wäre halt bei der Cloud-Strategie die Frage, wer macht das jetzt konkret? Also es gibt Enterprise-Architektur-Teams, die sehr gut auch technisch versierte Architekten im Team haben, die können dann teilweise anfangen, Details halt auch zu planen. Eine typische Konstellation wäre aber auch, dass die Enterprise-Architekten zusammen mit anderen Architekten, zum Beispiel Domänenarchitekten oder Solution-Architekten, je nachdem, wie die Firma genau geschnitten ist, dann halt gemeinsam arbeiten und sich die Arbeit quasi teilen. Also ich glaube vielleicht so als Nebenbemerkung, auch wenn das vielleicht ein gutes Hauptthema wäre: Ich glaube, dass Architekturorganisationen grundsätzlich föderalistisch funktionieren sollten, ähnlich wie der Aufbau eines Staates, dass halt Entscheidungen möglichst nah am Problem getroffen werden sollten und Enterprise-Architekten jetzt nicht einfach bessere oder ältere oder erfahrenere Architekten sind, sondern einfach andere Themen übernehmen und sagen, das, was in einem Projektteam entschieden werden soll, muss kein Enterprise-Architekt machen. Sind es drei, vier Teams, gibt es vielleicht einen Domänenarchitekten, sind es ein paar Teams mehr und es hängt mit der Unternehmensstrategie zusammen, dann ist ein Enterprise-Architekt eine gute Abstraktionsebene, um diese Ebenen zu verbinden.

Anja: Und wie schafft man es, die Enterprise-Architektur oder die Enterprise-Architekten an der richtigen Stelle zu involvieren?

André: Das ist eine sehr gute Frage, weil in meinen letzten Positionen habe ich mich genau damit, glaube ich, mehrere Jahre beschäftigt und immer wieder nachgeschärft. Unternehmen haben ja in der Regel schon irgendwelche … also fangen wir auf einer grünen Wiese an am besten, sagen wir es gibt keine Architekturorganisation. Trotzdem haben Unternehmen ja schon Methoden, wie sie Ziele festlegen, eine Strategie umsetzen, wie sie diese Informationen übers Management dann halt verteilen, wie sie Teams zu Commitments bringen, wie sie Projektmanagement nutzen, Budgets dann da verteilen und Ähnliches. Da gibt es dann irgendwelche Gremien, wo Leute halt ihre Ideen einbringen, Budgets erbitten und so weiter.

Und jetzt gründe ich eine Enterprise-Architektur.

Und sage, ja, es gibt ja einen Grund dafür. Irgendjemand wird gesagt haben, wir haben jetzt drei Teams, die bauen alle ein Identity-Management und so, können wir es nicht vor die Klammer ziehen oder irgendwie sowas halt. Und so viele Dinge würden wir gar nicht bauen, wenn wir es früher gewusst hätten. Das sind so typische Dinge, warum man sowas anfängt. Und dann ist ein Weg zu sagen, ja, wir gucken uns diese Kette an, also im Prinzip den Lebenszyklus eines Projektes erstmal und schauen, wo wäre es sinnvoll, wenn ein Enterprise-Architekt irgendwelche Beiträge leisten könnte. Zum Beispiel Informationen zuliefert vor einer Budgetfreigabe oder Ähnliches. Und was muss ich, um eine Information zu liefern, wann muss ich vorher schon involviert gewesen sein, damit ich diese Informationen dann auch habe, die ich liefern soll. Und dann kann man sich an dieser Prozesskette quasi lang hangeln und schauen, wo der Mehrwert dann halt gebracht wird.

Genau. Und der andere Punkt dabei ist, eigentlich sind wir schon eine Ebene zu weit, weil da sage ich, ich will halt die Budgetierung, Planung verbessern, aber vielleicht geht es um ganz andere Ziele. Und das heißt, wenn ich so eine Abteilung neu gründe, wäre es am Anfang total sinnvoll herauszufinden. Erstens, wer braucht irgendwas? Also in der Regel gibt es irgendjemanden, der sagt, wir gründen eine Abteilung. Was hat diese Person für Interessen? Und was haben alle anderen, die Interessen haben könnten, genau für Interessen?

Und dann im Prinzip so eine Art Produktpaket zu formulieren und zu sagen, hey, hier ist so das Angebot, was wir leisten können, was dem Unternehmen helfen könnte. Das könnte sein, dass zum Beispiel Transparenz fehlt, was Machbarkeit von Projekten angeht. Sind wir total überladen und also mit dem Tagesgeschäft und können deswegen keine Projekte abschließen, haben wir nur Externe beschäftigt, die eigentlich super sind, aber trotzdem nicht arbeiten können, weil mit denen keiner reden kann und deswegen Informationen fehlen.

Oder haben wir externe Firmen angebunden, die für uns ein Kerngeschäft ausmachen, aber aus irgendwelchen anderen Gründen nicht in die Organisation, die Softwareentwicklungsprozesse eingebunden sind oder sowas halt? Oder nutzen wir Technologie, die eigentlich nicht mehr tut, was wir brauchen? Haben wir das gleiche auch fünfmal in verschiedenen Varianten und eigentlich nutzen wir nur ein Subset, was ein System nutzen könnte. Bei all diesen Dingen, das rauszufinden, will ich gerade Effizienz, will ich Innovation, brauche ich vielleicht auch etwas, also auch ein schönes Beispiel, wie gehe ich damit um, dass es auf einmal ganz viele Möglichkeiten mit AI gibt.

Ich habe jetzt keine Ahnung, zehn Abteilungen, wo ich mir vorstellen kann, die könnten irgendwas damit machen. Ich habe aber auch nur eine Abteilung, die sich mit Daten gut auskennt, wo ganz viel landet und die auch wissen, was man dann damit macht. Wie gehe ich jetzt damit um, dass ich eigentlich dezentral Entscheidungen treffen möchte, wie mir AI helfen kann? Und das kann auch ein Enterprise-Architektur-Thema sein, zum Beispiel.

Anja: Du hattest gesagt, dezentral. Warum sollte es dezentral entschieden werden?

André: Ich würde mich ein bisschen relativieren. Also ich bin großer Freund davon, in solchen Umgebungen zu arbeiten. Es gibt aber auch Situationen, wo das gar nicht sinnvoll ist, Dinge dezentral zu tun. Aber grundsätzlich, glaube ich, ist es ähnlich wie bei einem Staatenaufbau bei uns, dass es sinnvoll ist, Dinge halt vor Ort zu entscheiden, dort wo Probleme halt auftauchen und wo auch Wissen vorhanden ist. Das heißt, wenn ich jetzt zum Beispiel in einem Unternehmen, sagen wir mal, wir hätten einen Fernsehsender und jemand kümmert sich um die Vertragsgestaltung mit den Studios, die irgendwelche Inhalte anliefern. Dann wissen die Leute, die die Verträge machen und auch die Verhandlungen führen, sehr genau, was in diesem Bereich passiert. Und sie können auch ziemlich genau sagen, was sie gerne verbessert haben wollten.

Sie kennen aber vielleicht nicht die technischen Möglichkeiten, die wir heute mit verschiedenen LLMs oder sowas haben. Dafür gibt es eine andere Abteilung, zum Beispiel irgendwo ein Datencenter oder wie auch immer man das heute nennen möge in jeder Firma. Und dieses Wissen möchte ich eigentlich zusammenkriegen, weil der Fachbereich kennt sein Problem gut und der andere die technischen Lösungsmöglichkeiten. Und jetzt kann ich entweder sagen, ich zentralisiere all diese Fragen, also die fachlichen Fragen und schiebe sie quasi in ein zentrales Center, dann habe ich eine Handvoll Leute, die alle Fachlichkeit des Unternehmens irgendwie abbilden müssen oder ich sage, ich nehme dieses zentrale Wissen, transportiere das in die Fachbereiche, also dezentralisiere das Wissensmonopol sozusagen und gucke, dass sie zumindest zusammenkommen. Ich glaube, an dieser Stelle … Der Weg, wie es zumindest da, wo ich es gesehen habe, am besten funktioniert aktuell ist so eine Mischform. Also die Leute, die an den Daten nah dran sind und sich damit auskennen haben, wissen, was sie nicht einfach innerhalb kürzester Zeit den Fachbereichen beibringen können.

Aber sie können halt immer wieder sich treffen, so eine Art Roadshow machen im Unternehmen, die neuen Möglichkeiten zeigen. Das ändert sich alle paar Monate, was jetzt neu geht. Und die Fachbereiche können dann selbst überlegen, oh, damit können wir was anfangen und können dann halt irgendwie ein bisschen brainstormen, welche Möglichkeiten sie dadurch erarbeiten.

Und wenn dann tatsächlich in einzelnen Fachbereichen ganz viel passiert, dann kann man gucken, ob man da Dinge dann halt auch tatsächlich hinschiebt. Also auch Leute hat, die daneben nicht in einem zentralen Team sind, sondern dezentral sind.

Anja: In diesem Beispiel hängt es natürlich stark von der Kultur ab, die in einem Unternehmen vorherrscht, ob von unten grundlegende Ideen nach oben kommen können oder nicht.

André: Ja. Wobei ich sagen muss, ich glaube, das ist überall möglich, nur die Wege dorthin sind anders.

Anja: Oder vielleicht schwierig.

André: Genau.

Anja: Dann komme ich schon zu dem, was mich am meisten interessiert. Was sind denn die typischen Herausforderungen, die dir immer wieder begegnen und die auch gar nicht einfach sind?

André: Ich glaube, was ein Thema ist, das Positive, dass man versucht, alles zu verstehen, was im Unternehmen ist, ist gleichzeitig die Schattenseite, weil man halt in kein anderes Team wirklich so tief involviert ist, wie die Teams selbst intern arbeiten. Das heißt, ich kenne dann zwar Leute, die Legal- und Compliance-Themen haben, genauso wie Entwickler, POs, verschiedene Management-Positionen. Also irgendwo gibt es dann überall Kontakte.

Aber gleichzeitig ist man nicht Teil der Teams. Das heißt, jedes Team hat wahrscheinlich einen Backlog, egal ob die es entwickeln oder sonst was machen. Jeder hat einen Backlog, das größer ist als das, was an Zeit da ist. Und dann kommt noch jemand mit Fragen, die eigentlich nicht im eigenen Scope liegen.

Also ein Entwicklungsteam sagt, wir haben Backlog, das ist total voll. Wir haben P.O., der klar priorisiert hat. Wir wissen, was wir tun wollen. Und jetzt müssen wir noch mit jemandem reden, der Fragen hat, die irgendwie gerade überhaupt keinen Wert für uns haben. Ja, wäre schön, wenn wir irgendwie, keine Ahnung, ein zentrales CMS hätten oder sowas. Aber aktuell kommen wir damit irgendwie zurecht und dafür ganz viele Meetings zu haben, weil jemand Geld sparen will oder so. Das ist ja auch oft so ein Thema. Die kommen wegen der Effizienzkosten sparen oder so. Das ist dann nicht attraktiv.

Und dann trotzdem in die Teams hineinzukommen und den Mehrwert zu vermitteln. Warum sollte man mit einem Enterprise-Architekten sprechen? Das ist sicherlich oft eine Herausforderung. Und je nachdem, wie die Enterprise-Architektur positioniert ist im Unternehmen, sind das halt unterschiedliche Abteilungen, mit denen man eng oder nicht so eng arbeiten kann. Wenn ich jetzt als Enterprise-Architektur primär Informationen fürs Management liefere, die sagen, ja, jetzt haben wir eine viel transparentere IT, weil wir haben von euch alles erfasst und Relationen dargestellt bekommen, wir können Kosten zuordnen auf Fähigkeiten, die wir als Unternehmen brauchen und so, dann können wir tolle Entscheidungen treffen.

Dann wird man vielleicht dort offene Türen einrennen, aber gleichzeitig wird es immer schwieriger, diese Informationen aus den Teams rausholen, wenn sie das Gefühl haben, sobald ich mit dem rede, ist danach das Budget weg oder so was halt oder reduziert.

Und umgekehrt, wenn ich jetzt allerdings mehr Richtung einzelner Entwicklungsteams den Kontakt ausbaue, dann ist die Frage, wie viel Mehrwert dann noch für das Management vorhanden ist, wenn ich zu sehr in den Details versinke. Und da irgendwie das auszubalancieren, halt mit allen gut zurechtzukommen und den Mehrwert zu vermitteln, ist halt eine Kommunikationsfrage und man sollte vielleicht ein bisschen zugänglich sein.

Anja: Wunderbar. Ich glaube, ich habe einen guten Eindruck darüber bekommen, was Enterprise-Architektur so ausmacht und welche Fähigkeiten man braucht, um als Enterprise-Architektin vielleicht erfolgreich zu sein. Vielen Dank, dass ich mit dir sprechen durfte, André.

André: Danke, das war mir eine Freude.

Anja: Tschüss!

André: Tschüss.