JavaSPEKTRUM: Ihr Unternehmen erklärte kürzlich, dass es Softwareunternehmen helfen kann, die Auswirkungen der Covid-19-Pandemie zu überwinden. Wie sieht diese Unterstützung aus?
Christ: Bei den Kosten, Business Continuity und Employee Experience. Im Bereich Kosten geht es darum, mithilfe von Architekten das Applikationsportfolio zu durchforsten und zu entscheiden, an welchen Stellen am einfachsten rationalisiert werden kann, also die Applikationen zu identifizieren, die am wenigsten benutzt werden. Im Sektor Business Continuity helfen Architekten mit unserer Software dabei zu entscheiden, auf welche Applikationen Mitarbeitende auch im remote Office unbedingt Zugriff haben müssen. Außerdem haben wir erst kürzlich ein neues Tool herausgebracht – und das betrifft das Thema Employee Experience –, das allen Mitarbeitenden in Form eines Katalogs aller freigegebenen Applikationen zeigt, welche Tools für sie verfügbar sind. Diese können sie dann im Selfservice beziehen.
Gehören die Funktionen, die Sie gerade beschrieben haben, wie Monitoring, Kostenkontrolle und Repository, nicht eher zum traditionellen Werkzeugkasten von EAM und der Wächterfunktion, die Enterprise-Architekten in den Augen vieler IT- und Business-Mitarbeiter ausgezeichnet haben?
Auf den Kontext Covid-19 trifft das teilweise zu. Allerdings weist der letzte Bereich, das Bereitstellen von Applikationen für alle Mitarbeitenden, schon deutlich auf die modernere Rolle von Enterprise Architecture Management (EAM) hin. Da geht es eher um aktive Begleitung und Collaboration mit der IT und der Fachseite. Das sehen wir vor allem bei Kunden, die sich zurzeit mit Cloud-Transformationen beschäftigen oder mit anderen großen Projekten wie dem Umstieg auf SAP HANA. Da geht es nicht in erster Linie um Controlling und Governance, sondern darum, Abteilungen übergreifend miteinander zu verbinden oder darum, dass Fachabteilungen die Transformations-Roadmap verstehen und auch Feedback dazu geben können. Mit einer restriktiven Enterprise Architecture kann man solche Projekte gar nicht mehr bewältigen.
››Unternehmen, die architekturell schon gut aufgestellt waren, konnten während der Pandemie schneller über die passenden Einkäufe entscheiden‹‹
Hat die Pandemie auch dazu geführt, dass Mitarbeiter die Architekturfunktion stärker wahrnehmen?
Ja. In einigen Unternehmen entscheiden Architekten in Gremien mit, in denen sie vorher nicht vertreten waren. Zum Beispiel im Einkauf, um von Anfang an zu besseren Entscheidungen zu gelangen. Die Unternehmen, die architekturell schon gut aufgestellt waren, konnten während der Pandemie aufgrund der besseren Datenbasis schneller über die passenden Einkäufe entscheiden.
Fungiert die Mehrzahl der Architekturabteilungen noch als Wächter über das Portfolio oder haben sie sich mehrheitlich bereits anders aufgestellt?
Ich kann nur aus der Erfahrung sprechen, die wir mit unseren Kunden gemacht haben, die mit unserem auf Kollaboration ausgelegten Produkt arbeiten. Im Durchschnitt arbeiten in den Kundenunternehmen 50 aktive Nutzer pro Monat mit unserem Tool. Wenn Sie jetzt noch berücksichtigen, dass es pro Unternehmen in der Regel zwei bis drei Architekten gibt, dann wird sehr deutlich, dass in diesen Unternehmen sehr kollaborativ auch mit anderen Abteilungen gearbeitet wird. Bei denen, die viel selbst entwickeln, nutzen neben den Architekten Business Engineers, Softwareentwickler und Projektleiter unser Tool. Bei denen, die mehr auf Standardsoftware setzen, finden wir unter den Nutzern zum Beispiel IT-Controller, Einkäufer, Prozessanalysten.
Differenziert sich die Enterprise Architecture weiter aus und hilft diese Ausdifferenzierung beim Verlassen der klassischen Wächterrolle?
Eine Ausdifferenzierung, die sich an den Bedürfnissen des Unternehmens orientiert, hilft sicher. Wie weit sich die Funktion aufgliedert, hängt jedoch stark vom Reifegrad der Architektur und von der jeweiligen Aufgabe ab. Ich hatte kürzlich ein Gespräch mit einem Chefarchitekten, dessen Unternehmen zurzeit einen sehr großen Merger bewältigen muss. Der sieht eine Ausdifferenzierung in Technology- und Security-, in Business-Application- und Data- sowie in Experience- und Product-Architecture.
Gibt es noch weitere Entwicklungen, die zu einer moderneren Interpretation der EA-Rolle beitragen?
Der Wandel von einer Projekt- in eine Produktorganisation. In der ersten wird am Anfang eines großen Projekts eine Zielarchitektur definiert, die mehrere Jahre Bestand haben soll. Danach wird entwickelt und Architektur und Entwicklung haben nur noch wenig miteinander zu besprechen. Beim Produktansatz ist das anders. Da beginnt man mit einem Minimal Viable Product, das sowohl vom Design und der Funktionalität, aber eben auch von der Architektur her weiterentwickelt wird. Allein schon deshalb, weil ein Pilotprodukt nur von wenigen Leuten benutzt wird, ein Massenprodukt aber auf viele Nutzer zielt und deswegen eine ganz andere Architektur braucht. Das heißt, in einer Produktorganisation muss man sich viel öfter austauschen. Der Dialog zwischen Architektur, Entwicklung und Fachseite ist nötig, weil das Produkt sonst nicht funktionieren kann.
››Beim Produktansatz beginnt man mit einem MVP, das sowohl vom Design und der Funktionalität, aber eben auch von der Architektur her weiterentwickelt wird‹‹
Hat sich die Mehrheit Ihrer Kunden bereits als Produktorganisationen aufgestellt?
Die Mehrheit ist das noch nicht – aber einige Kunden machen das bereits sehr erfolgreich und bei vielen steht dieser Wandel an.
Sie beschreiben moderne Architektur in etwa wie einen ständigen Revisionsprozess der eigenen Arbeit. Während das Produkt entwickelt wird, schreibt die Architektur nicht vor, wie es aufgebaut wird, sondern stellt mehr oder weniger zu jedem Entwicklungsschritt die passende Architektur bereit. Wenn die Entwicklung des Produkts voranschreitet, stellt sich jedes Mal die Frage, ob die momentane Architektur noch die richtige ist. Hat die EA in Unternehmen diese Aufgabe tatsächlich angenommen?
Sie sprechen den Planungsprozess an. In den vergangenen acht Jahren lag unser Fokus ganz klar auf dem Ist-Zustand. Wir wollten zunächst dazu beitragen, dass die Unternehmen den Ist-Bestand ihrer IT-Bebauung möglichst transparent und automatisch zur Verfügung haben, das kommunizieren und mit anderen Abteilungen kollaborativ zusammenarbeiten können. In der Vergangenheit kannten die Unternehmen diesen Ist-Zustand nicht. Deshalb kam es oft zu komplexen Planungsszenarien, die nicht umgesetzt werden konnten, weil häufig die Voraussetzungen fehlten oder die Annahmen bezüglich des Ist-Zustands falsch waren. Jetzt, mit wachsender Reife, beschäftigen wir uns intensiver mit der Frage, wie man agiler planen kann.
Uns scheint das Vorgehen bei Änderungen in der Softwareentwicklung das richtige Vorbild dafür zu sein. Nehmen Sie GitHub als Beispiel für ein Code-Repository. Dort nutzen Entwickler ein „Branch“, um gemeinsame Änderungen an Software vorzunehmen. Dort kann man auch verschiedene Änderungen gegenüberstellen, bevor man sie produktiv stellt. Wir glauben, dass man solche Branches auch zur Planung von Architekturveränderungen gut einsetzen kann, um mit ihnen zu zeigen, wie sich Veränderungen mit einem Zeithorizont von drei bis 12 Monaten auf eine aktuelle Architektur auswirken können.
››Wir sind davon überzeugt, dass eine solide und möglichst automatisierte Erfassung des Ist-Zustands die Grundlage ist für jeden Plan, der auch realisiert werden kann‹‹
André Christ beim New York CIO Executive Summit
Stichwort Cloud. Es werden immer mehr Services Cloud-native oder „serverless“ entwickelt und das häufig auf der Plattform eines Hyperscalers. Spielt in solchen Szenarien Architekturmanagement überhaupt noch eine Rolle? Stellen diese Anwenderunternehmen, die sehr eng mit einem Cloud-Provider arbeiten und dessen Platform-as-a-Service nutzen, überhaupt noch Architekturüberlegungen an?
Architektur bleibt zum einen wichtig, weil viele Unternehmen eine Multi-Cloud-Strategie verfolgen, und zum anderen, weil es selten Cloud in Reinform gibt, sondern meistens hybride Ansätze greifen, also nur ein Teil der Workloads in der Cloud residiert und andere Teile weiterhin on-premises sind. Dabei spielt Architektur eine wichtige Rolle, denken Sie da nur an die Themen Security und Authentifizierung oder Datenmanagemen.
Unsere Analysen zeigen, dass erst 26 Prozent der Business-Anwendungen in der Cloud sind. Und in dieser Transformation spielt Architektur eine zentrale Rolle. Es müssen Fragen nach der Auswahl der Cloud-Services oder Fragen nach der Transformation der Applikation selbst beantwortet werden. In den seltensten Fällen ergibt es Sinn, einfach eine On-prem-Applikation per Lift and Shift auf eine virtuelle Instanz in die Cloud zu verlagern. Deshalb: Die Architektur wird nicht verschwinden, aber die Architekten müssen sich stark verändern. Ohne ein Verständnis dafür, was die verschiedenen Cloud-Architekturen bieten, können Enterprise-Architekten ihre Unternehmen nicht mehr ausreichend unterstützen.
Konzentriert sich LeanIX stärker darauf, seinen Kunden eine solide Ist-Basis zu geben, oder darauf, sie möglichst gut bei der Planung zu unterstützen?
In den letzten acht Jahren haben wir uns in erster Linie auf die Ist-Basis konzentriert. Mit unserem Business-Transformation-Management-Modul, das wir im September dieses Jahres auf den Markt gebracht haben, bieten wir unsere Kunden genau diese Veränderungsplanung an. Wir sind allerdings weiterhin davon überzeugt, dass eine solide und möglichst automatisierte Erfassung des Ist-Zustands die Grundlage ist für jeden Plan, der auch realisiert werden kann.
Aber wird Planung von Veränderung nicht immer wichtiger? Schließlich werden die Zeiten, in denen Unternehmen sich nicht verändern müssen, immer kürzer.
Ja, das ist so. Deshalb ist Automatisierung so wichtig, damit man viel weniger Aufwand in die Pflege des Ist-Zustands stecken muss.
Sie bieten Ihre Services in Europa und den USA an. Existieren große Unterschiede in den Architekturansätzen zwischen der alten und der neuen Welt?
Wir machen heute rund 40 Prozent unseres Umsatzes in den USA. Dort herrscht eine viel ausgeprägtere Experimentierfreude. Die Bereitschaft zwischen Anwender und Anbieter, Dinge gemeinsam weiterzuentwickeln, ist deutlich größer. Das passt auch viel besser zu der Produktdenke, die ich bereits erwähnt habe. Die amerikanischen Kunden sind außerdem sehr viel vertrauter mit Collaboration-Lösungen und erwarten das auch von einem EA-Tool, was uns sehr entgegenkommt.
André Christ
ist Gründer und Geschäftsführer von LeanIX. Sein 2012 in Bonn gegründetes Unternehmen bietet Software-as-a-Service (SaaS) zur Verwaltung von Enterprise-Architektur und Multi-Cloud-Umgebungen an. Dadurch können Unternehmen schneller datengetriebene Entscheidungen für ihre IT treffen. Vor der Gründung seines Unternehmens hat Christ mehrere Jahre als Inhouse Consultant bei der Deutschen Post/DHL gearbeitet. Dort beriet er das Top-Management zu strategischen Themen. Schon während seines Studiums der Wirtschaftsinformatik entwickelte Christ als freier Mitarbeiter Softwarearchitekturen für Start-ups und internationale Unternehmen.
Das Interview führte Christoph Witte, E-Mail: cwitte@wittcomm.de
