Transkript
Anja: Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und ich spreche heute mit Falk Hoppe. Hallo Falk. Ja, neben deiner Rolle als Principal Consultant berätst du Unternehmen zu Software Architektur und auch Frontend Architektur im Speziellen, stimmt das? Wie kommt es, dass du dich so spezialisiert hast auf Frontend Architekturen?
Falk: Hallo. Hallo Anja. Das stimmt. Das ist irgendwie historisch bedingt, dadurch, dass mir das immer sehr viel Spaß gemacht hat und ich tatsächlich als Hobby immer nebenbei viel mit CSS gearbeitet habe, mit JavaScript gearbeitet habe. Und das tatsächlich in meinem Arbeitsumfeld am Anfang gar nicht so eine Rolle gespielt hat. Aber das mir so viel Spaß gemacht hat, dass ich das einfach weitergetragen habe. Und in dem ganzen heraus von den letzten Jahren betrachte ich Frontend Architektur mal als eines der Probleme, die sehr schwer zu lösen sind. Und ja, da ist das irgendwie auch mein Arbeitsumfeld gewandert.
Anja: Hm, ja. Ich habe auch den Eindruck, dass du dich mit IT-Strategie auseinandersetzt. Zumindest höre ich das immer so nebenbei, wenn wir auf INNOQ-Events sind und du mit Kolleginnen sprichst. Dann hat es sehr viel mit Strategie zu tun. Und ich finde IT-Strategie sehr interessant. Hast du das Gefühl, dass in den Unternehmen, die wir beraten oder generell in Unternehmen, IT-Strategie richtig angegangen wird? Weil die IT-Strategie ist ja im Grunde abhängig von der Business-Strategie und machen das Unternehmen richtig?
Falk: Also ist natürlich jetzt schwer pauschal zu beantworten, ob das alle richtig oder alle falsch machen. Ich erlebe relativ häufig, dass unsere Ansprechpartner versuchen, Ziele zu erreichen und uns deswegen ansprechen, meistens ein konkretes Vorhaben haben. Ganz häufig sind unsere Ansprechpartner da schon im Lösungsbereich und Hinterfragen glaube ich manchmal die Ziele zu wenig oder beziehungsweise sind schon ein paar Stufen weiter und ich habe häufig den Eindruck, dass aber das dahinter liegende Business-Ziel vielleicht gar nicht von der Lösung zu erreichen ist oder dass vielleicht die Rahmenbedingungen eigentlich nicht passend sind. Und da kommen wir so ein bisschen in die IT-Strategie rein, dass ganz häufig im Grunde das Setup, wie die IT sich aufstellt, für die Business-Ziele geändert werden muss. Also ein ganz klassischer Themenkomplex, den wir häufig heute sehen, ist, dass viele Unternehmen noch klassische Projektarbeit haben oder Projektplanung haben. Und dass sie im Prinzip immer nur den nächsten Schritt als Iteration irgendwie als große Projektplanung vorplanen, durchführen und am Ende mit dem Ergebnis dastehen und dann die Organisation wieder umbauen für das nächste Projekt. Und wir sehen aber, dass eigentlich uns viele Kunden glaube ich schon eher mittlerweile digitale Produkte definieren wollen und da auch ein Lebenszyklus von einem Produkt eigentlich vorteilhaft wäre, um ihr Geschäftsziel zu erreichen. Ganz häufig ist eigentlich heute das digitale Produkt auch etwas, das Geld einbringt oder zumindest an der Wertschöpfungskette direkt beteiligt ist. Und dann ist dieser Projektansatz relativ häufig nachteilig für die Produktentwicklung. Da reden wir dann halt eben mit unseren Ansprechpartnern relativ schnell halt eben über die Gesamtstrategie und wie wir darin stattfinden, bzw. wie die Softwareentwicklung, der Softwareentwicklungslebenszyklus für so eine Digitalstrategie aussehen kann. Ja.
Anja: Okay, du redest jetzt schon von der Art und Weise, wie wir beraten würden. Und wir wollen ja heute über Architekturberatung sprechen. Und ich habe tatsächlich an zwei Dinge gedacht, und zwar, wie wir als INNOQ oder auch andere Beratungsunternehmen unterstützen, aber auch wie die interne Beratung aussieht. Beispielsweise, ich bin eine Architektin in einem Unternehmen, das hat mich angestellt und das ist mein täglicher Job meine Entwicklungsteams zu beraten oder mein Entwicklungsteam zu beraten. Wie siehst du da die Unterschiede?
Falk: Also in erster Linie finde ich das ja schon mal eine gute Definition. Ich glaube, die ist gar nicht so alltäglich, tatsächlich oder beziehungsweise die ist mittlerweile vielleicht alltäglicher, aber früher war die ja gar nicht der Standard. Also der Architekt, der sich wirklich als Enabler sieht und als Berater für den Rest des Unternehmens, das ist, glaube ich, eine Geisteshaltung, die ist sehr positiv. Also ich finde die sehr gut, aber das ist eine Entwicklung, die eigentlich stattgefunden hat. Ich sag mal, die klassischen Elfenbeintürme, die immer sehr verschrien sind, waren ja eher die Architekten als Durchregierer und Entscheider. Die haben von oben irgendwas geplant und das kann auch sinnvoll geplant gewesen sein, aber in der Regel wurde per Dekret verfügt, wie die nächsten Projektphasen aussehen und was erreicht werden soll. Und ein Buy-In der Leute, die dann entwickeln sollen oder die die Projektdurchführung oder die die Produktentwicklung weiterführen sollen, die ist dann irgendwie schwer zu etablieren und ich habe immer das Gefühl, dass das viel besser läuft, wenn man als Architekt ein Konzept hat, intern ist oder extern ist, da an der Stelle eigentlich egal, und wirklich zu den Leuten geht und denen das mitbringt und sagt, das hier ist mein Konzept, ich erkläre dir das mal, das habe ich eigentlich vor damit zu erreichen, hast du Feedback dazu, würdest du das mittragen? Und dann zu versuchen wirklich so einen Buy-In zu etablieren bei den Leuten. Und da sehe ich halt eben Architekten viel eher als Enabler und Berater. Und das heißt eben auch, zu verstehen, wie die Schmerzen von dem Publikum sind, dass man da beraten möchte und eben dann auch wirklich eine Strategie zu entwickeln, die zu diesen Schmerzen auch von den Leuten passen und halt eben zu den Architektur-Zielen und zu den Geschäfts-Zielen passt. Genau.
Und ja, dieser Unterschied zwischen intern und extern, das ist, glaube ich, eine echt schwere Frage erst mal, weil das auch so unterschiedlich gelebt wird. Für mich ist relativ wichtig eigentlich, dass wir in erster Linie versuchen, mit den Internen eigentlich Hand in Hand so zu arbeiten, dass es gar nicht unbedingt auffällt, dass wir von außen kommen. Aber es ist sicherlich ein Unterschied. Also wir sind natürlich in unserer Rolle, bekommen wir häufig ein Mandat, das uns sehr speziell in so einem Unternehmen eingliedert. Also allen Leuten ist klar, da kommt jemand, der hat folgende Aufgabe, der soll folgendes Ziel erreichen.
Und dann erledigen sich ganz häufig schon Absprache-Problematiken. Oder die Leute fügen sich ganz häufig schon dem und sagen, ach du hast ja diese Rolle oder diese Aufgabe bekommen, dann unterstütze ich dich da drin. Intern sind Architekten natürlich häufig in so einer Rolle, dass sie zu sehr vielen verschiedenen Themen beraten müssen.
Und da häufig gar nicht klar ist, zu welchem Ziel die jetzt gerade beitragen wollen. Und dementsprechend ist dann häufig auch eine Klärung erstmal vonnöten sozusagen, um in den verschiedenen Themenbereichen immer erstmal wieder zu etablieren, was soll gerade erreicht werden. Und wir als externe Berater sind, glaube ich, haben glaube ich ein sehr viel klareres Mandat häufig, wenn wir zu einer Beratung kommen.
Anja: Aber wie kommt das, dass Architektinnen, die tagtäglich für Unternehmen arbeiten, dass diese nicht so wirklich ein klares Mandat und nicht wirklich ein klares Ziel haben? Wie kommt das?
Falk: Ich glaube, das ist auch eine Frage von der Organisation. Das ist auch in jedem Unternehmen anders. Es mag das auch, also ich sage es jetzt wieder, sehr pauschale Aussagen zu sehr komplexen Landschaften. Ist auch bestimmt in vielen Landschaften ganz anders. Ich glaube tatsächlich, dass das auch damit zu tun hat, wie Architektur gesteuert wird und wie Architektur in Unternehmen verhaftet wird. Ist das eine Abteilung, die eher von außen kommt und quasi immer nur zu punktuellen Zeitpunkten im Entwicklungslebenszyklus an der Software dazukommt und den Senf dazugibt oder ob tendenziell das begleitend im Projekt verankert ist. Aber ganz häufig hat so eine Architektur auf Abteilungen oder haben Architekten und Architektinnen sehr oder sobald die im Prinzip sicher in so einem Unternehmen exponieren, sind die da und bekommen Aufgaben.
Und die bekommen immer mehr Aufgaben und solange die nicht nein sagen und gerade wenn sie ihre Arbeit gut machen werden sie immer mehr Arbeit bekommen und in verschiedene Themen reingezogen werden und da eine klare Abgrenzung zu bekommen über eine Zeit hinweg das fällt halt immer schwerer und das ist, was wo wir, glaube ich, als externe Berater das ein Stück weit leichter haben da mit einem klareren also wir sind irgendwie auch logischerweise teuer. Wir kommen erstmal von außen dazu. Jemand muss sich den Aufwand machen, uns irgendwie an Bord zu bringen. Und ein Teil dieser Aufgabe ist halt eben, uns die Aufgabe zu erklären, für die wir gekommen sind. Wobei das natürlich auch nicht immer so ist. Also wir sind in vielen Projekten, wo tatsächlich klar ist, wir haben Probleme, keine Ahnung. Wir haben Security-Probleme oder wir haben Angst davor, Security-Probleme zu haben. Wir wissen es eigentlich gar nicht mal.
Oder wir haben Betriebsprobleme oder wir haben ein großes Betriebsvorhaben und er hilft uns doch mal mit quasi DevOpsigen Entwicklern oder Architekten dazu, eine Strategie zu entwickeln. Und dann ist es natürlich so, der weiß der Kunde nur hat wahrscheinlich ein Problem und gibt uns quasi keinen richtigen Fokus. Aber wir sind dann halt eben trotzdem frisch dabei und können uns die Landschaft von außen angucken und sind auch erstmal aus der Organisation quasi ein Fremdkörper, der sich quasi eingebettet werden kann und frisch starten kann.
Anja: Es gibt ja immer diese Horrorvorstellung, IT-Beratungsunternehmen kommen in ein Unternehmen und kommen mit ihrem Schema F und kommen schon mit ihren Lösungen zu einem Problem, was angeblich alle anderen Unternehmen auch haben und das würde in jedem anderen Unternehmen halt richtig, also genau so gelöst werden. Welche, also diese Erwartung wird einem dann auch entgegengebracht als Consultant und ich habe das Gefühl, wir arbeiten anders.
Falk: Ja, tendenziell, glaube ich, versuchen wir gar nicht so ein Standardset mitzubringen. Wir sind bestimmt, wir haben bestimmt alle irgendwie eine starke Meinung und haben irgendwie schon starke Überzeugung. Aber tatsächlich ist es in der Regel so, dass wir bei einem Kunden ankommen und eigentlich erstmal versuchen, herauszufinden, wie funktioniert denn der Kunde und was will der erreichen, wenn wir den eigentlich erstmal kennenlernen. Wir sind halt, also wir jetzt explizit, sind eigentlich keine Produktfirmen, also wir bringen eigentlich relativ wenig Produkte mit, sondern wir reden, wollen eigentlich über Konzepte reden. Also wir wollen eigentlich in der Regel erstmal darüber reden, welches Konzept hilft dir denn gerade weiter.
Und was dann wirklich als Lösungsidee rausspringt, ob es ein konkretes Produkt ist, das eingesetzt wird oder Ähnliches. Das ist eigentlich eine Entscheidung, die wollen wir mit dem Kunden zusammentreffen.
Wir versuchen den Kunden dahin zu bringen, dass der eigentlich Entscheidungen treffen kann. Das ist, glaube ich, eine der Hauptarbeiten, die wir als externe Beratung machen. Und ich glaube halt tatsächlich, dass das aber was ist, was man auch als interner Architekt eigentlich machen möchte. Also man möchte in der Regel nicht der sein, der schuld ist. Also man möchte jetzt als Architekt nicht immer der sein, der alleine das Fallbeil über den Köpfen da schweben lässt und dann irgendwie sagt, ich finde eine gute Idee, ihr macht X und deswegen macht ihr das jetzt. Sondern eigentlich hat man als Architekt in der Regel ein gutes Gefühl, wenn man eine Sachlage oder eine Problematik soweit erarbeitet hat, dass man die gut beschreiben kann und gut vermitteln kann und den Leuten ein gutes Gefühl dabei geben kann, mit einem zusammen dann in eine gewisse Richtung zu laufen. Ich glaube, dann hat man seinen Job gut gemacht.
Anja: Ja, genau. Genau, und da gibt es auch keinen Unterschied zwischen einer externen Beratung und einem internen Architekten oder Architektin.
Falk: Ne genau, ich glaube, das ist auch, also natürlich gibt es den bestimmt hier und da, also das ist ja auch nicht jeder Tick gleich, aber tatsächlich ist es meine Wahrnehmung, dass das eigentlich der Job ist, wenn man die Architekturarbeit richtig macht, dass man eigentlich auf gleiche Weise arbeitet. Und ich glaube tatsächlich, dass wir häufig zu Kunden kommen und überhaupt erstmal eine Kultur von Architekturarbeit mitbringen. Oder zumindest mal zur Diskussion stellen, wie denn die Kultur für Architekturarbeit sein sollte.
Und dann findet sich irgendwo die Mischung. Also natürlich sagen wir nicht immer hier, ihr müsst unsere prima Kultur der Software-Architekturarbeit mitbringen, sondern da findet sich halt irgendwo eine Mischung und wir versuchen halt eben auch an diesem Prozess zu arbeiten.
Anja: Du sagst jetzt Kultur und ich hatte im Kopf eher Prozesse. Es gibt Prozesse für die Architekturarbeit. Man macht das so und so, wenn man die und die Anforderungen hat. Ich finde es spannend, dass du Kultur gesagt hast. Wie sieht denn die Kultur aus von Architekturarbeit?
Falk: Prozesse sind in der Regel sehr nüchtern und hilfreich oder nicht, abhängig davon, ob eine gute Kultur herrscht oder nicht. Also ein Prozess an sich, der kann so gut ausgefeilt sein, wie der will. Wenn er nicht wirklich akzeptiert wird und gelebt wird, dann bringt der meiner Meinung nach wenig. Dann steht auf dem Papier, dass man einen Freigabeprozess für Entscheidungsdokumente hat oder Ähnliches, oder dass man zu gewissen Problemen ein Entscheidungsdokument, also so was wie einen Architecture Decision Record verfasst.
Wenn man dann aber mal in die Decision Records reinguckt und die Leute nicht wirklich diesen Spirit leben, dass das auch ein Dokument sein soll, was Leuten wirklich offene und gleichberechtigte Informationen bereitstellt, dann sieht man, dass in solchen Dokumenten relativ häufig schon eine Entscheidung zum Beispiel favorisiert wird oder Ähnliches.
Oder dass in gewissen Lösungsstrategien halt nur sehr einseitig beleuchtet wird. Aber auch generell ist Kultur für mich halt in der Architekturarbeit sehr wichtig, weil gerade das Wie man miteinander redet und überhaupt der ganze Kommunikationsprozess an der Stelle sozusagen aufgebaut wird, hängt sehr stark davon ab eben, dass man das Persönliche sucht und da halt auch eine gute Ebene hinbekommt.
Und das halt eben auch natürlich nicht nur zwischen Architekten, sondern halt eben im Idealfall zwischen verschiedenen Stakeholdern. Also, dass man halt eben auch Entwicklungsteams mit an Bord bekommt. Also, ich kenne halt wahnsinnig viele Projekte, in denen haben Entwickler keinen Kontakt zu Architekten. Das findet nicht statt. Und ich finde das tatsächlich geradezu schädlich. Also, das ist eigentlich in der Regel die Peer Group, die mir das beste Feedback gibt, wenn ich ein Konzept geschrieben habe.
Ich kann das in einer, also ganz üblicherweise gibt es so Architecture-Communities und wenn die gut sind, dann sind da auch Tech-Leads aus den Teams mit drin. Oder sogar halt eben, ich sag jetzt mal, „der einfache Entwickler oder die einfache Entwicklerin darf auch mal mit reinspringen“, ja. Und ich finde das in der Regel schön, wenn solche Communities wirklich so offen sind, dass da eigentlich tatsächlich jeder gleichberechtigt irgendwie rein darf und mit lauschen darf und mitdiskutieren darf, weil tatsächlich so eine offene Feedbackkultur eben sehr viel dazu erzeugt, ob man wirklich weiß, ob man die schlimmen Randfälle gefunden hat oder nicht. Weil wenn ich eine Kultur etabliert habe, in der sich die Leute nicht trauen, mein Konzept wirklich zu kritisieren, dann passiert da eigentlich nur Folgendes, dass mein Konzept wahrscheinlich Randfälle nicht berücksichtigt, von denen ich gar nichts weiß.
Anja: Ja, und dir bringt es halt nichts, wenn du ein Architekturkonzept ausgearbeitet hast, was in der Realität nicht funktioniert. Und das Problem daran ist ja nicht nur, dass es nicht funktioniert, sondern dass die Entwicklungspersonen in den Entwicklungsteams sehr unglücklich damit sind und dann auch die Motivation verlieren. Und das kann alles dazu führen, dass am Ende dann ein Softwareprojekt schiefläuft, eben weil die Leute sagen, ja, mit dieser Kackarchitektur kann man doch eh nicht arbeiten. Deswegen braucht man dieses Feedback, um Architektur auch anpassen zu können, zu dem, wie es halt eigentlich sein sollte, damit die Motivation bleibt und natürlich auch die Software funktioniert, so wie sie funktionieren sollte.
Falk: Ich glaube auch tatsächlich, also man hat ja so verschiedene Phasen von sowas zum Beispiel, also Architekturprozess oder Architekturdokumentationsprozess und Spezifikationsprozess. Also in der Regel ist man irgendwann in der Phase, dass man ein Problem vorgespielt bekommt und sagt, okay, ich denke mir was aus. Dann diskutiert man erste Lösungen mit den Kollegen an und schreibt das mal irgendwie runter. Und was man im Prinzip verfasst, ist eigentlich eine Spezifikation für ein Problem, beziehungsweise für eine Problemlösung. Und die müssen wir jetzt irgendwie kommunizieren. Und wenn die kommuniziert ist, dann wandert das irgendwie in einen agilen Entwicklungsprozess oder in irgendeinen anderen Entwicklungsprozess. Das wird verschiedene Male durchgewalkt von Product Ownern, Requirements Engineers und so weiter und so fort, bis das in den verschiedenen Teams wirklich zu einem Ticket wird und dort abgearbeitet wird.
Und was die Teams dann daraus machen, das hängt super stark davon ab, ob die das mögen, was man da konzeptioniert hat und ob die damit, dass die verstanden haben, was man erreichen möchte und ob die die Lösung auch wirklich unterstützen. Das heißt nicht, dass die die toll finden müssen. Das heißt nicht, dass eine Lösung nur dann super ist, wenn die Developer Experience bei 100% ist und der Entwickler total schön abgeholt ist.
Da kann es natürlich auch so einen Disagree and Commit geben. Aber man muss den Leuten zumindest mal eine Chance geben, zu verstehen, was man da erreichen wollte. Und wenn das nicht passiert, also wenn man in diesem ganzen Prozess nicht so richtig, sage ich jetzt mal nah an der implementierenden Seite bleibt, dann hat man relativ häufig nach zwei, drei Jahren den Punkt, wenn man im Nachgang dann mal nachdokumentiert oder nachprüft, die Sachen geworden sind, dass man auf einmal feststellt, sag mal damals, das haben die ja ganz anders entwickelt, als ich denen das eigentlich mal irgendwie angeraten habe und man auf einmal so einen gewissen Gap sieht zwischen dem, was man in der Dokumentation hat und zwischen dem, was wirklich draußen implementiert ist.
Anja: Ja. Ja. Und das muss ja nicht so schlecht sein, weil die eigentliche Implementation kann ja viel besser sein, aber weil man eben nicht miteinander gesprochen hat, wurde diese bessere Implementierung nicht mit einbezogen. Und dann, genau, gibt’s diesen Gap.
Falk: Genau. Das heißt, in der Regel hat man ja verschiedene Entwicklungsteams, die man als Architekt betreut. Das heißt, im schlimmsten Fall hat man zwei Teams, die es sehr gut gelöst haben und zwei, die es vielleicht nicht so gut gelöst haben. Und jetzt kann man beliebig würfeln, ob die guten Teams das quasi zum eigenen Konzept passend gemacht haben oder nicht. Vielleicht waren das tatsächlich die, die sich nicht dran gehalten haben, die eine bessere Lösung haben. Vielleicht war es andersrum.
Im Idealfall sage ich mal, wäre man näher dran gewesen und hätte mitbekommen, was implementieren die, und hätte einen Kommunikationsprozess gehabt, bei dem die Leute, auch wenn die mit einer schlechten Idee um die Ecke kamen, eine Chance hatten, das zu äußern, zu sagen, wir würden das gerne so lösen, und man eine Chance hatte, mit denen zu reden, zu sagen, du, ich finde das super, dass du da eine andere Lösung vorgeschlagen hast, aber folgende Ziele werden damit zum Beispiel nicht erreicht, oder wir haben folgendes Problem, wenn wir das auf diese Weise angehen.
Und so eine Art von Kommunikationskultur möchte ich eigentlich in der Architekturarbeit sehen, wenn ich Architekturberatungen mache. Und deswegen ist für mich tatsächlich Architekturberatung auch viel ein kulturelles Problem.
Anja: Ja. Und welche Formate hast du da im Sinn? Du hattest jetzt gesagt, in einem Format wie in einer Community, man trifft sich regelmäßig und bespricht Architekturlösungen. Gibt es noch andere Formate? Ich kann mir vorstellen, dass in so einer großen Runde es vielleicht Schwierigkeiten geben könnte, dass die Entwicklerinnen sich äußern. Gibt es vielleicht so etwas wie Sprechstunden extra für Teams? Hast du da mit Erfahrung gemacht?
Falk: Ich glaube, das ist eine interessante Frage, gerade auch jetzt in Remote-Zeiten, wo man wirklich viele Jahre rein noch quasi aus Entfernung miteinander arbeitet. Tatsächlich finde ich den häufigen Austausch wichtig. Der kann auch remote stattfinden, aber es muss halt eben dann schon auch mal ein Platz sein, dass man nicht nur in der 30-Mann-Runde zusammen redet.
Tatsächlich finde ich wichtig, dass man auch mal streitet, zum Beispiel. Hoffentlich in der Sache. Ich rede jetzt nicht davon, dass man dem anderen vorwirft, dass einem die Frisur nicht passt oder Ähnliches, sondern ich möchte natürlich schon mit den Leuten eher über Ziele streiten oder über Lösungen streiten und über, ob die die Ziele erfüllen oder nicht oder ob irgendwelche anderen Probleme bestehen. Und das kann bestimmt auch mal einhergehen oder wirklich mal ein bisschen rasanter zu gehen. Aber tatsächlich, glaube ich, ist das in einer sozialen Gruppe relativ häufig so, dass man sich finden muss und dass man so ein Alignment hinbekommen muss, wie man kommuniziert und was denn eigentlich die Ziele sind, die man erreichen möchte. Und umso seltener man sich sieht, umso rasanter geht das üblicherweise einher, weil dieser Abgleich dann halt einfach eine größere Schlucht zu überwinden hat sozusagen. Und ich glaube halt deswegen, dass man nach und nach, wenn man enger zusammenarbeitet, eigentlich solche Schluchten auch überwinden kann und da Brücken bauen kann, muss man aber eben halt auch aktiv als Aufgabe begreifen. Das heißt, man kann durchaus streiten und in der Sache das tun, muss aber dann irgendwo auch halt eine Kultur etablieren, wie man wieder zusammenkommt. Und da ist halt tatsächlich, also dieses Community-Konzept hat meiner Meinung nach den Nachteil, dass viele Firmen die Architektur oder Socializing sozusagen damit abgehakt haben. Die dürfen doch einmal in der Woche zwei Stunden miteinander reden, die 40 Stück, die ich da habe. Und in der Regel ist es aber tatsächlich natürlich so, dass manche Leute in der Öffentlichkeit keine Lust haben zu streiten oder Angst haben, ihre Befürchtungen zu äußern oder Angst haben zu sagen, dass sie dem großen Plan eigentlich nicht anhängig sind.
Und ich bin großer Fan natürlich eigentlich am Anfang von Open Spaces und Ähnlichem gewesen, aber eigentlich bin ich gar kein Fan von Open Spaces, sondern von dieser Grundidee des Gesprächs in der Kaffeemaschine tatsächlich. Also ich glaube, tatsächlich sich das auf dem Flur gegenüberstehen und offen nochmal diskutieren können, beziehungsweise auch da erkennen zu können, hey, wir haben ja einen Dissens, wir verstehen uns ja eigentlich gar nicht.
Und wir haben wirklich eine unterschiedliche Meinung, sollten wir das nicht nochmal aufgreifen. Und dann halt eben wirklich auch Raum zu schaffen, dass man sich in der Architektur, aber halt eben auch mit Entwicklern, mit verschiedenen Entwicklungsteams nochmal treffen kann und sagen kann, passt mal auf, ich pack meine Konzepte in den Aktenkoffer, auch wenn es der virtuelle ist. Und ich komm bei euch vorbei und ich erklär euch nochmal, was ich meine und ihr sagt mir nochmal, warum ich doof bin. Und dann finden wir irgendwo in der Mitte was, wo ich hoffentlich nicht ganz so blöd bin.
Und also ihr macht mich schlau und ihr wisst aber danach auch zumindest mal was ich sagen wollte und das es auch keine persönlichen Angriffe sind, sondern dass ich halt eher und eher in der Materie eigentlich arbeiten wollte.
Anja: Ja. Ich finde diese Attitüde übrigens gut, genauso wie du es gerade beschrieben hast. Ich komme zu euch und ihr sagt mir, warum ich blöd bin. Ich finde diese Attitüde sehr wichtig, denn Entwicklungsteams sind ja eigentlich die Expertinnen, muss man sagen, für ihre Domäne. Und du kommst außerhalb und hast zwar irgendwie einen groben Überblick, aber kennst dich halt nicht mit ihrer konkreten Domäne aus und du kannst eigentlich gar nicht wissen, was die absolut perfekte Lösung ist. Deswegen sehe ich es auch so, dass es eher ein Miteinander ist und ein gemeinsamer Austausch, der regelmäßig stattfinden sollte und auf Augenhöhe stattfinden sollte.
Falk: Ich glaube, dass dieses Gefälle ja natürlich auch ganz natürlich entsteht. Wir sind als Architekten häufig in der glücklichen Lage, dass wir auch an der Unternehmens- und Architekturstrategie-Diskussion teilnehmen und an der IT-Strategie teilnehmen. Wir bekommen halt Informationen, die bekommen ganz viele andere nicht. Also ganz klassisch, gerade in deutschen Unternehmen ist der Informationsfluss in der Regel bottom up. Also wir alle müssen nach oben reporten, aber tatsächlich ist der Informationsfluss zurück häufig schwierig. Also jeder kennt die Entwicklungsteams, die noch nicht mitbekommen haben, dass gerade ein Riesensparvorhaben durch die Gänge treibt oder quasi, dass irgendein Architekturziel erreicht werden soll oder irgendein Business Ziel erreicht werden soll. Die haben dann vielleicht schon mal irgendein Buzzword gehört, irgendeinen Strategienamen oder Ähnliches. Sie wissen aber eigentlich gar nicht, was dahintersteckt. Und wir als Architekten sind häufig da, dass wir wissen, was dahintersteckt. Also wir haben dann schon mal eine Erklärung gehört. Und ich glaube tatsächlich, dass diese, ich habe immer gesagt, ein Architekt sollte eigentlich sein wie so ein Wanderlehrer.
Und ich sage mal, Wanderlehrer, früher waren nicht gut bezahlt. Die sind dann immer von Dorf zu Dorf gegangen und haben dann mal irgendwie ein Huhn oder ein Ei bekommen. Und ich glaube halt tatsächlich, dass das aber eigentlich eine ganz schöne, bescheidene Metapher eigentlich ist. Also ich glaube tatsächlich, als Architekt kann man quasi bescheiden von Team zu Team tapern, seine Ware mitbringen und sein Wissen mitbringen und halt auch die Informationen mitbringen. Also ich glaube, dass wir tatsächlich eine Aufgabe haben, auch diese Informationen durch das Unternehmen zu tragen und bekommen dafür aber eben was zurück. Also es mag halt auch noch mal ein Huhn sein, es mag auch noch mal ein Ei sein, aber tatsächlich bekommen wir halt eben hier und da Feedback, was für uns, für unsere Arbeit wichtig ist, damit wir auch in unserem Job überleben können tatsächlich.
Anja: Die ganze Zeit drängt sich bei mir der Gedanke auf, dass es ja sehr ähnlich zu Enabling Teams ist, was du gesagt hast. Also Enabling Teams, nach Team Topologies, sind Teams, die Entwicklungsteams unterstützen in ihrer Arbeit, aber nicht wirklich harte Vorgaben machen. Und so kann es auch ein Architektur Enabling Team geben.
Falk: Die Frage ist, sitzen die Architekten zusammen in einem Team? Sitzen die dezentral bei den Teams. Könnte natürlich auch eine Variante sein, dass man sowas hat wie Produktarchitekten, die eher bei den verschiedenen Fachdomänen sitzen. Wir treffen häufig beides an bei unseren Kunden. Es gibt irgendwie die einen und die anderen. Ich glaube tatsächlich, die Metapher von so einem Enabling-Team ist genau die richtige. Und das andere, das funktioniert schon auch mal. Aber ich muss gestehen, häufiger sehe ich das natürlich zum Scheitern verurteilt. Also ganz häufig ist so der Architekt, der so per Dekret von oben regiert, aus der Kanzel, ist der, der eigentlich denkt, dass seine Konzepte etabliert sind und auch funktionieren. Und wenn man dann mal genauer hinschaut, sieht man eigentlich, dass sie nach unten seit Jahren nicht gelebt werden. Und deswegen glaube ich tatsächlich, dass man aus dieser Enabling-Mannschaft, man viel eher in einen Dialog kommt und eine Kultur aufbauen kann, in der man auch sieht, dass die Konzepte halt auch etabliert werden.
Anja: Jetzt stellt sich mir eine neue Frage, weil du gesagt hast, dann werden die nicht gelebt. Was passiert dann zwischendrin? Irgendwie müssen diese Konzepte ja in Tickets gegossen werden. Wer macht das? Wer schreibt Tickets und wer nimmt die ab? Und werden die erweitert? Durch wen werden die erweitert? Werden die angepasst?
Weil ich hatte das in einem Projekt schon mal erlebt, da gab es eben eine konkrete Planung mit Architekturzielen. Diese Implementierung wurde dann in Tickets gegossen und dann kamen die in den Entwicklungsteams halt einfach rein und man konnte dann aber nichts anfangen, weil es halt hinten und vorne nicht für den eigenen Kontext gestimmt hat.
Falk: Ja, das ist eine superschwierige Frage. Ich glaube tatsächlich, dass das auch eine Riesenfrage aufmacht, wie sollte eine moderne Softwareentwicklungsorganisation aufgebaut sein. Und das ist natürlich auch gar nicht unbedingt so generisch zu beantworten. Früher habe ich immer gesagt, der Product Owner muss Tickets schreiben.
Also der ist dafür da, Tickets schreiben zu können. So, jetzt würden mir da irgendwie, also schon mal ganz viele Zuhörer wahrscheinlich nicht mehr zustimmen. Schon ad hoc. Ich glaube, dass das zumindest für fachliche Themen immer noch so sein sollte. Also zumindest muss der eine Idee haben. Also wenn der owned sozusagen, dann designt der sein Produkt eigentlich auch. Dann sollte der tatsächlich aber dieses Design auch manifestieren können in Schrift und Sprache. Ich glaube, das ist tatsächlich ganz gut, wenn sich das auch übt vor allen Dingen. Klassischerweise schreibt der vielleicht so einen Epic oder so. Der schreibt irgendwie mal so die grobe Rahmenrichtlinie mit und der muss das auch nicht alleine tun oder der oder die, also Owner als Rolle.
Ich glaube halt, dass das immer am besten funktioniert, tatsächlich in der realen Antwort, wenn Tickets zusammen geschrieben werden, kollaborativ geschrieben werden. Und umso technischer die Tickets sind, umso technischer sollten die Stakeholder sein, die die Tickets schreiben. Das heißt, hat man einen rein fachlichen Product Owner, der keinen digitalen Hintergrund hat, dann ist wahrscheinlich eher der Architekt, der Kollaborateur für das Schreiben der Tickets.
Und gerade wenn ich als Architekt, wenn ich jetzt in dieser Wanderlehrerfunktion unterwegs bin, entweder biete ich schon so gute Konzepte, dass man die einfach quasi auch textuell oder grafisch in Diagrammform oder Ähnliches kopieren und adaptieren kann.
Und dann ergänzen sozusagen die Ticketschreiber aus den Teams, also die Techniker, die sich gerade damit befassen, den Kontext so, dass das halt eben für alle anderen im Team auch passt und verstanden ist. Ich glaube halt tatsächlich ist es natürlich immer so, dass nicht immer das ganze Team jede Story vordiskutieren kann. Also die Chance gibt es meistens nicht. Es wäre natürlich unendlich viel Overhead, denn immer alle Leute was mitdiskutieren müssen. Deswegen ist, glaube ich, die Qualität von Tickets hier und da einfach auch entscheidend. Wobei man immer sagen muss, ich bin tatsächlich kein Fan davon unendlich lange Tickets zu schreiben. Also für mich ist tatsächlich ein Ticket ein Manifest für die Arbeitsorganisation und nicht für Konzeptverständnis. Ich erlebe bei vielen Kunden auch, dass Jira oder ähnliche Tools benutzt werden, um Produktdokumentation zu erzeugen, also um wirklich, also der Product Owner erzeugt wirklich da drin einfach nur die Beschreibung von dem, was er erreichen möchte. Es gibt quasi keine andere Produktdokumentation, erlebe ich leider immer wieder. Und das Gleiche bildet sich dann halt eben auch im technischen Konzeptbereich ab, das heißt technische Konzepte werden dann eigentlich eher im Ticket in Tiefe beschrieben.
Und dann werden die auch erarbeitet und das funktioniert für den Arbeitsprozess auch gut. Und dann ist das Ticket abgeschlossen und verschwindet im Nirwana. Ja, also das ist dann halt irgendwie natürlich in einer Suche rein theoretisch noch findbar. Aber kein Mensch weiß gegebenenfalls nach fünf Jahren, dass es dieses Ticket mal gegeben hat.
Anja: Ja, aber dann muss ich dazu sagen, aber nicht alles lohnt sich in der Architekturdokumentation niederzuschreiben. Die sollte ja so kurz wie möglich sein. Das kann ich schon verstehen, wenn man nicht alles noch anderweitig dokumentiert.
Falk: Ich glaube, da ist man relativ schnell in einer Tool-Diskussion drin und auch in einer Diskussion da drin, wie ausführlich die Dokumentation sein darf und in welchen Bereichen. Ich bin ein großer Fan davon, dass Decision Records schon relativ lange leben, aber auch die sind irgendwann natürlich nicht mehr wertvoll und ich glaube, auch solche Dinge sollte man ausblenden dürfen.
Aber ich finde halt eben so ein Ticketsystem als Architekturdokumentationshalde sozusagen ist für mich meistens ein Anti-Pattern.
Anja: Ja, das ist klar.
Falk: Genau. Aber dementsprechend Tickets schreiben, ich befürchte, die Antwort wird auch vielen nicht gefallen. Also ich glaube tatsächlich, dass Entwicklerinnen das nicht so gerne sehen, dass sie die Tickets schreiben sollen. Ich glaube, also ich erlebe das zumindest immer mal wieder als Feedback, dass sie sagen, ich erwarte doch von eigentlich hier, dass ich hier mein fertiges Ticket bekomme, dass ich dann einfach runter implementieren kann. Das ist irgendwie mal so ein bisschen die Wunschvorstellung. Ich kriege einfach gesagt, was ich tun muss und dann kann ich auch immer nine-to-five hier einfach mal runterschrubben.
Ich befürchte, meine Sicht auf die Softwareentwicklung ist anders. Also meine Sicht sagt eigentlich, ich sollte, also ich muss immer sagen, ich in der Entwicklerrolle habe mich immer sehr gerne damit auseinandergesetzt, dass ich was möglichst Sinnvolles entwickle und auch verstanden habe, was ich da entwickeln soll und dann hilft mir tatsächlich der Ticketprozess, also dieses Ticket zu schreiben, auch da drin Verstand zu haben, was ich denn tun soll. Ja.
Anja: Das hat viel mit Kultur zu tun, mit dem, was man gewohnt ist als Entwicklungsperson. Ich habe auch beides erlebt, aber in den Projekten, in denen INNOQ vollständig die Personen gestellt hat in diesem Team. Da war es eigentlich immer so, dass wir an dem Ticketschreiben selbst beteiligt waren. Ich fand das auch sehr gut, weil ich dann besser verstehen konnte, warum wir Dinge tun und vielleicht sogar noch Lösungen nochmal umschreiben konnten, weil wir gemeinsam darüber geredet haben, dass doch eine andere Lösung viel besser war oder wäre.
Falk: Witzigerweise, also ich habe schon in ganz verschiedenen Konstellationen gearbeitet, also schon ganz alleine beim Kunden, beim Kunden im gemischten Teams, also wo ich der einzige INNOQ-Consultant dabei war. Ich habe in so Pari-Pari-Teams gearbeitet, eben auch schon in reinen INNOQ-Teams, aber dann vielleicht mit anderen Teams in parallel. Jetzt in den letzten Jahren einfach primär natürlich eher in der Architekturrolle quasi außerhalb der Teams stehen konnte mir den Prozess von außen angucken. Und ich glaube tatsächlich, dass es häufig da schiefgeht, wo es viele agile Coaches gibt, die eigentlich so eine Idealvorstellung durch die Gegend treiben. Und diese Idealvorstellung, die so in einer Agilindustrie ist, ist glaube ich eigentlich, es ist ein Impediment, wenn der Entwickler nicht schon gut verfasste Tickets bekommt. Das ist eine Sache, die verursacht relativ viel Schaden. Ich bin natürlich dabei, dass der Entwickler sich nicht jedes Mal ausdenken muss, was er als Nächstes generell tun muss oder welche große Fachdokumentation da als Nächstes erzeugt werden muss. Aber ich muss sagen, ich habe in der Vergangenheit am liebsten mit Product-Ownern gearbeitet, die wirklich ein gutes Verständnis davon hatten, was das Produkt erreichen soll, um Geschäftsziele zu erreichen. Also um irgendwas sicherer zu machen, um mehr Geld einzubringen, um performanter zu sein und die Akzeptanz für den Kunden zu steigern, oder, oder, oder. Es gab dann immer ganz viele Dinge, die eigentlich erst mal generisch waren und keine Lösung mitgebracht haben und wir in der Entwicklungsrolle die Aufgabe hatten herauszufinden, was können wir denn tun, um dieses Ziel zu erreichen. Oder zumindest schon mal, vielleicht ist das auch schon mal mit Architekten vordiskutiert worden, aber dass wir da irgendwie die Arbeit haben, auch mit dem Product Owner herauszufinden, was man dann sinnvollerweise tun kann. Und tatsächlich ist das aber vielleicht auch nochmal ein ganz guter Punkt. Ich sehe natürlich tatsächlich die Rolle eines Entwicklers und eines Architekten gar nicht so unterschiedlich. Also wir haben das jetzt immer die ganze Zeit so, die Architektinnen und Architekten. Also persönlich muss ich gestehen, wenn ich nur Entwickler war, dann war ich in meinem Kopf immer auch Architekt, ob der Kunde das wollte oder nicht. Als Berater hat man natürlich auch ein bisschen den Auftrag vielleicht von außen auch mal Dinge aufzuwerfen, die der Kunde im Vorhinein nicht gedacht hat. Also der Kunde hat gedacht, ich entwickle nur Software und jetzt diskutiere ich mit ihm aber, ob denn das Team Setup generell so überhaupt passend ist oder Ähnliches. Ja, wir als Berater haben natürlich häufig die Aufgabe, generell Missstände auch anzusprechen und die Transparenz zu machen.
Anja: Oder zumindest unsere Meinung zu sagen.
Falk: Genau, ich finde Transparenz schaffen, ist da eigentlich häufig echt so unsere Aufgabe. Aber tatsächlich war aber immer für mich als Entwickler auch die Architekturarbeit ein ganz natürlicher Teil meiner Aufgabe. Ich glaube, das ist was, was ich auch gar nicht anders mehr machen wollen würde. Und dementsprechend, wenn ich natürlich jetzt zu einem Entwicklungsteam gehe, dann sehe ich da eigentlich mich als vielleicht in der Architekturrolle und ich sehe dann da fünf Architektinnen sitzen.
Und mit denen diskutiere ich dann halt meine Lösung. Und wenn dann jemand aus der hintersten Ecke, der vorher noch kein Wort gesagt hat, irgendwas schreit und platzt und aus dem Raum rennt und mir an den Kopf wirft, ich hätte das ja alles nicht verstanden, dann sag ich nicht, ach, der ist aber irgendwie doof drauf, sondern dann frag ich wirklich an mich zu fragen, okay, vielleicht hab ich wirklich irgendwas nicht verstanden. Und dann ist da vielleicht jemand, den ich vorher, der sich selber vielleicht auch gar nicht in der Architekturrolle sieht, der aber wirklich vielleicht eine Erkenntnis hat, die ich noch gar nicht hab.
Und deswegen finde ich tatsächlich, diese Architekturrolle macht natürlich Sinn aus einer Perspektive, wo wir Leuten exklusiv Zeit verschaffen, sich mit Themen auseinanderzusetzen und Konzepte zu schreiben und Ähnliches, weil das häufig im Mix zu kurz kommt. Also wenn ich nur Software entwickle, dann bin ich halt, dann ist es schwer, mich frei zu machen, um in Meetings zu gehen und um Anforderungsanalyse zu machen oder Ähnliches. Deswegen ist der Architekt als Rolle natürlich hier und da wirklich sehr sehr hilfreich. Trotzdem glaube ich immer, dass man das nicht zu überhöht sehen darf und dass eigentlich der Architekt eher nur der ist, der in einer Luxusposition Zeit zu haben, für die die anderen Architekten, nämlich die Entwicklerarchitekten sozusagen keine Zeit haben.
Anja: Kann es vielleicht sogar schädlich sein, diese Rollen so festzustricken, zu sagen, du bist jetzt Architekt, Architektin und du bist jetzt nur Entwickler oder Entwicklerin? In einem Unternehmen, das ich kenne, da war es so, dass alle Entwicklungspersonen auch Produktentwicklerin genannt wurden. Und damit sollte gesagt werden, du machst dir Gedanken, ob das Produkt, was du gerade technisch entwickelst, auch überhaupt Sinn hat. Das heißt, wenn du Tickets schreibst, dann überlegst du dir, hat das überhaupt Sinn, was ich gerade hier schreibe? Auch produktmäßig hat das Sinn. Hat das architektonisch Sinn? Hat das von der technischen Seite Sinn? Das hat man wirklich in den Rollen direkt so eingefasst, damit keiner auf die Idee kommt, nee, um Architektur kümmere ich mich gar nicht.
Falk: Ich glaube, die Welt ist halt komplexer und man kann das nicht so einfach beantworten.
Grundsätzlich finde ich das, was du da skizziert hast, total toll. Das ist was, was ich, glaube ich, grundsätzlich sehr, sehr, sehr großartig finde und das auch tatsächlich häufig gerne so sehen würde. Aber es heißt natürlich auch, dass ich als Entwickler immer aus meinem Flow gerissen werde, eigentlich. Also wenn ich jetzt ein neues Ticket mir nehme, muss ich natürlich alle Phasen durchlaufen.
Und das bedeutet glaube ich schon hier und da für meine persönliche Effizienz über so einen Tag hinweg, wenn ich immer wieder Dinge klären muss, weil die kein anderer vorgeklärt hat oder ich zumindest wie so ein Philosoph immer alles anzweifeln muss sozusagen, dann macht das natürlich auch was mit mir. Ich glaube, insgesamt ist das jetzt nicht so negativ. Also ich glaube insgesamt ist das auch was, was man einübt und dann auch wieder positiv sein kann. Aber ich glaube, das hat schon das Geschmäckle, dass man natürlich auch vielen Leuten diese Aufgabe aufzwingt, die vielleicht gar nicht so gut dafür gemacht sind. Also manche Leute wollen das auch einfach nicht tun. Beziehungsweise in gewissen Projektphasen ist das einfach auch, glaube ich, eine gute Trennung, dass manche Leute sagen, ich kümmere mich um die Vorbereitung der nächsten drei Monate und ihr macht das heute. Ihr macht das, was heute ansteht.
Ich glaube natürlich trotzdem, dieses, ich sag mal, gedankenlos einfach runterprogrammieren, das ist vielleicht auch das, wenn die Leute immer sagen, AI gefährdet unsere Jobs. Also diese Jobs, die sind hart gefährdet. Ja, das sehe ich auch so. Aber tatsächlich sehe ich die Hauptimplementierungsarbeit nicht da. Ich glaube tatsächlich, dass das nicht, also wenn das der Informatik-Job ist, dann löst man ja keine Probleme. Dann wiederholt man ja nur bestehende Dinge eigentlich.
Und da, wo wir arbeiten, da werden in der Regel fachliche Probleme gelöst. Auf der anderen Seite ist es aber natürlich so, dass man als Architekt in so einer Rolle häufig ist, weil man andere Aufgaben hat. Man stellt sich jetzt einen Kunden vor oder eine Organisation vor, wo zum Beispiel viele externe Dienstleister in der Entwicklung unterwegs sind. Oder generell, das ist eigentlich auch unabhängig auch bei anderen Entwicklungsteams. Dann ist ja immer so ein bisschen die Frage, was ist denn mit so cross-funktionalen Themen wie Security zum Beispiel oder mit Betriebskonzepten? Also wir haben, also viele von den Zuhörern werden im Prinzip so Site-Reliability-Engineering-Konzepte kennen oder von Google gelesen haben oder gehört haben. Oder aber auch andere cross-funktionale Architekturkonzepte, die man sich so ausgemalt hat.
Und da ist mir die Frage, wer guckt sich denn an, ob die eingehalten werden? Oder ob die in den verschiedenen Teams analog betrachtet werden? Und wer hat denn so das Umgreifen im Auge? Und das ist tatsächlich, wenn man jetzt nur Produktentwickler hätte, glaube ich ein Problem tatsächlich. Dann ist ja so ein bisschen die Frage auch, also wenn jetzt Team A aus fünf Superproduktentwicklerinnen besteht und Team B genauso, und Team A sagt, ich habe da was bei euch gesehen, das finde ich echt seltsam. Und wir machen das ganz anders. Und Team B sagt, ich finde aber eure Variante total seltsam. Wer trifft denn die Entscheidung? Also wer macht denn dann im Prinzip das Spiel unter sich aus?
Anja: Ja natürlich, es braucht natürlich Leute, die auch auf die Makroarchitektur schauen und dort schauen, ob es sozusagen Leitplanken geben kann, die man vorgeben kann oder bei denen man unterstützen kann. Das stimmt. Ich glaube, darum geht es nicht, das zu ersetzen. Also Leute, die sich um das große Ganze Gedanken machen, die sollte man damit natürlich nicht ersetzen. Da stimme ich dir zu.
Falk: Genau, wobei ich mir halt eben schon vorstelle, also in meinem Spirit natürlich schon vorstelle, dass viele von diesen Produktarchitektinnen in der Community aktiv wären und halt eben zum Beispiel diese Makroarchitekturvorgaben natürlich auch mit erarbeiten und eben selber dann sozusagen auch mit ihrem eigenen Blut unterschreiben. Also ich glaube tatsächlich,
Anja: Ja. Das will nicht jeder, ja.
Falk: Nee, nee, genau. Aber man muss halt natürlich sagen, ich rede jetzt nicht von großen Mengen, aber es wäre natürlich trotzdem schöner, die Leute würden auch mit einer gewissen Ownership an diese Konzepte rangehen. Also dass auch aus der Teamperspektive einer Entwicklerin sagen kann, dieses Konzept, das fühle ich total. Das ist total sinnvoll. Das möchte ich haben. Oder
Dieses Konzept, das ist aber total schmerzvoll, ich erkenne aber an, dass wir das brauchen. Ja, also auch das wäre ja irgendwie was. Und das erkennt man viel besser, wenn die Distanz halt eben klein ist. Genau, deswegen ist es wirklich für mich so eine Geschichte, der wieder, wir kommen wieder zur Kultur zurück, also eine gute Architekturrolle, auch in dieser Makroarchitektur-Ebene.
ist dann gegeben eigentlich, wenn die Distanz zu den anderen nicht so riesig ist eigentlich. Und das ist nicht immer einfach. Also ich glaube gerade in Riesenunternehmen, von großen Enterprise-Architektur-Abteilungen eigentlich krassischerweise reden, ich bin jetzt nicht so der Riesenfan von Enterprise-Architektur-Abteilungen, weil ich glaube, da ist die Distanz einfach naturgegeben riesig.
Aber die haben ja auch einen Job. Und das, was quasi so eine Enterprise-Architektur zu definieren und eben auch so auf Unternehmensebene zu entscheiden. Was muss denn auf Unternehmensebene entschieden werden? Und welche Konzepte sind quasi organisatorischen Einheiten vorbelassen? Wo möchten wir gar keine Synergie haben? Oder wo erlauben wir, dass keine Synergie getroffen wird?
Weil wir halt eine organisatorische Beweglichkeit erhalten möchten oder ähnliche Geschichten.
Anja: Kannst du da mal ein Beispiel geben?
Falk: Es gibt Kunden, die haben völlig getrennte Geschäftsbereiche eigentlich. Und trotzdem steht oben drüber in der Regel jemand, der sieht, dass er, keine Ahnung, sagen wir mal, es gibt jetzt acht verschiedene Geschäftsbereiche, der sieht, dass er achtmal Geld ausgibt, um, keine Ahnung, CI/CD Pipelines zu bauen, um eine Entscheidung zu treffen, welches Wiki für die Architektur-Dokumentation angezogen wird. Ob ich OpenShift als Kubernetes-Management-Plattform quasi einkaufe oder Ähnliches. Und er sieht im Prinzip Geld verschwinden für immer die gleiche Frage.
Ich glaube, dass gewisse Fragen in gewissen Geschäftsbereichen durchaus auch verschiedene Antworten verdienen. Genau diese Art von Arbeit sozusagen, genau diese Frage, ist das etwas, was man verschieden entscheiden können sollte oder nicht.
Das sehe ich halt viel bei der Enterprise Architektur. Tatsächlich. Aber die Distanz ist natürlich erstmal riesig. Also die Enterprise Architektur hat natürlich als Abteilung häufig das Problem, das die halt wirklich in keiner dieser Organisationseinheiten wirklich tief drin ist. Und deswegen vielleicht diesen Need nicht versteht. Also alles, was wir quasi vorher über Architektur, Rollen und Teams gesagt haben, stimmt vielleicht dann auch eben für Enterprise Architektur und Organisationseinheiten oder Domänen, Produkte, was auch immer.
Anja: Ich glaube, das ist ein gutes Schlusswort. Ich glaube, wir könnten noch Stunden darüber reden. Ich habe mir einige Sachen aufgeschrieben, die müssen wir ein anderes mal machen. Damit bedanke ich mich aber schon mal für dieses Gespräch. Danke, Falk.
Falk: Sehr gerne, vielen Dank
Anja: Ciao.
