Lesezeit: 4 Minuten
Ist Enterprise Architecture das Gegenteil von DevOps und agilem Mindset?
Ein renommierter Experte der IT-Architektur sagte kürzlich in einem Vortrag, den ich besuchte, dass Enterprise-Architekten Fitnessfunktionen für die CI/CD-Pipeline schreiben sollten, wenn sie das Ziel effizienter und evolutionärer Software-Architekturen vor Augen haben. Dies würde den Output ihrer Arbeit messbar und direkt anwendbar machen. Könnte das für Enterprise-Architekten in kleinen und großen Organisationen Sinn machen?
Aus der Sicht der Softwareentwickler wird in vielen großen Organisationen die Rolle des Enterprise-Architekten als hochgradig komplex wahrgenommen, da man bei der Fülle an Aufgaben leicht den Überblick über den Umfang und die Ziele des Projekts verlieren kann. Dies kann einerseits als übermäßige Verschwendung von Ressourcen angesehen werden, andererseits aber auch zu kulturellen Konflikten durch politisierte Silos innerhalb der Organisation führen. Aus dieser Perspektive gesehen kann all das im Gegensatz zu modernen, effektiven, agilen und DevOps-zentrierten IT-Organisationen stehen.
Ist diese Sichtweise gerechtfertigt? Was ist Enterprise-Architektur überhaupt und können sie gute Softwareentwicklung betreiben?
Gartner Consulting definiert Enterprise Architecture in seinem eigenen Glossar wie folgt:
Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve targeted business outcomes that capitalize on relevant business disruptions. [Quelle]
Enterprise Architecture (EA) ist demnach eine Disziplin, die unternehmerisches Handeln proaktiv und ganzheitlich auf disruptive Kräfte lenkt, indem sie die entstehenden Veränderungen identifiziert und im Hinblick auf Geschäftsstrategie und -Erfolg analysiert. EA liefert somit einen Mehrwert, indem sie Geschäfts- und IT-Führungskräften unterschriftsreife Empfehlungen für die Anpassung von Richtlinien und Projekten präsentiert, um zielgenaue Geschäftsergebnisse zu erreichen, die von relevanten Störungen in den Geschäftsprozessen profitieren.
Das ist eine ziemlich komplizierte Definition, nicht wahr? Brauchen wir das alles für eine moderne Softwareentwicklung?
Von Rollen und Teams
Betrachten wir diese Frage einmal aus der Perspektive einer IT-Organisation. Es gibt keine einheitliche Klassifizierung für die Jobrollen, die mit IT-Architektur verbunden sind. Viele Unternehmen definieren die gleichen Rollen innerhalb von IT-Bereichen mit unterschiedlichen Bezeichnungen. Einige Evangelisten der Agilität vertreten sogar die Meinung, dass ein agiles Team überhaupt keine Architekten braucht. Im Allgemeinen werden jedoch drei Arten bzw. Rollen von Architekten im IT-Bereich unterschieden: Technical-, Solution- und Enterprise-Architekten.
Die Experten für technische Architektur konzentrieren sich in der Regel auf den Implementierungsprozess und den Betrieb von Softwarelösungen. Sie sind auf bestimmte Bereiche und Technologien spezialisiert, in denen sie auch Blueprints und Best Practices für Softwareentwickler definieren. Ihr Hauptziel ist es, technische Implementierungsprozesse zu etablieren und umzusetzen. Dies erfordert tiefgreifendes technisches Fachwissen. Daher spezialisieren sich technische Architekten oft auf einige wenige Technologien wie Java, .Net oder Plattformen wie AWS oder GCP. Man hört oft auch Bezeichnungen wie Java- AWS- oder .Net-Architekten, wenn sie diese speziellen Technologien favorisieren.
Die Aufgabe von Lösungsarchitekten (Solution Architects) besteht darin, Geschäftsanforderungen zu bewerten und Lösungen für bestimmte geschäftliche Herausforderung zu entwickeln. Ihr Fokus liegt weniger auf technologischen Details, sondern auf Geschäftsprozessen. Sie benötigen aber durchaus technisches Verständnis auf hohem Niveau, um die Umsetzung der Architektur steuern zu können. Lösungsarchitekten begleiten oft aktiv ein Softwareprodukt von der Vision bis zur erfolgreichen Realisierung, sodass sich in der agilen Welt der Aufgabenbereich oft mit der Rolle des Product Owners überschneidet.
Ziele von Enterprise Architecture aus unternehmerischer Sicht
Die Enterprise Architektur ist dagegen oft auf einer höheren Managementebene angesiedelt, auch wenn das Unternehmen die damit verbundenen Tätigkeiten nicht so benennt. Ziel der EA ist es, strategische Richtungen zu definieren und die Lücke zwischen Geschäftszielen, -Treibern, Sichtweisen und Anforderungen zur Implementierung von Technologielösungen, sowie Unternehmensprozessen zu schließen. Der Schwerpunkt liegt dabei auf der strategischen Ebene und deckt einen mittel- bis langfristigen Horizont ab.
Dabei muss die EA die Markttrends berücksichtigen und disruptive Veränderungen vorhersehen beziehungsweise darauf reagieren. Strategieentscheidungen müssen in jeder Organisation getroffen werden. Wenn wir EA entsprechend definieren, dann beschäftigt sich jedes Unternehmen - selbst ein kleines Start-up – mit einer Art von Enterprise Architektur.
Vergleichen wir eine IT-Organisation mit einer Stadt, dann besteht die Aufgabe des Enterprise Architekten darin, die Infrastruktur der Stadt zu definieren. Sie zeigen auf, wo Kommunikationsadern verlaufen sollen, wo Parks entstehen können und wo man Industriegebiete ansiedeln würde - kurz gesagt, wie sich eine Stadt entwickelt und wie sie wachsen sollte. Die Lösungsarchitekten kann man mit Gebäudearchitekten vergleichen, die Pläne für die unterschiedlichsten Gebäudenutzungen, Parkanlagen, Schulen oder Krankenhäuser entwerfen, damit diese optimal genutzt werden können. Die technischen Architekten beschäftigen sich mit der technischen Umsetzung. Um bei unserem Bild der Stadtplanung zu bleiben, planen sie Wasserleitungen, Kanalisation, Strom- und Gasversorgung und sorgen dafür, dass alle Details fachgerecht umgesetzt werden.
Für eine große Stadt mit mehreren Millionen Einwohnern sind diese Tätigkeiten sehr komplex und erfordern fundierte stadtplanerische Kenntnisse und eine gute Organisation. Für eine kleine Stadt, ein Dorf oder eine Nachbargemeinde könnte eine "agile" Gruppe von Menschen, die sich mit Hilfe sozialer Medien selbst organisiert, durchaus gute Ergebnisse ohne unnötige Kosten und Organisationsstrukturen erreichen. Allerdings unterliegt auch diese agile Selbstorganisation den gesetzlichen Vorschriften, kommunalen Vorgaben, der Gesetzgebung und allgemeinen Architekturregeln und ist an streng vorgegebene Rahmen gebunden. Diese Analogie funktioniert auch in der Welt der agilen IT-Projekte, die viel Freiraum für die Selbstorganisation bieten, aber nur innerhalb eines Rahmens, der auf der einen Seite durch agile Regeln und auf der anderen Seite durch die Erkenntnisse der Solution- und Enterprise Architektur definiert ist.
Enterprise Architecture im Mittelstand
Für die meisten kleinen und mittleren Unternehmen besteht keine Notwendigkeit, ein eigenes Team oder eine eigene Organisationseinheit für EA einzurichten. Häufig nutzt das Management jedoch die Beratungsdienste spezialisierter EA-Experten, die bei Strategieentscheidungen unterstützen, oder mittel- und langfristige Roadmaps skizzieren.
Bei besonders komplexen oder schwierigen Entscheidungen beauftragt das Management manchmal mehrere Beratungsunternehmen, um unterschiedliche Sichtweisen und Erfahrungen verschiedener Branchen- oder IT-Experten zu nutzen. Mehrere Meinungen und Ideen sind oft hilfreich, um optimale Entscheidungen auf strategischer Ebene treffen zu können. Im Extremfall kann die Enterprise Architektur in großen Organisationen teil eines komplexen politischen Prozesses mit vielen Beteiligten sein, bei dem unterschiedliche Ziele, Anliegen und Standpunkte aufeinanderprallen und unter einen Hut gebracht werden müssen.
Frei nach Winston Churchill ist dies das schlechtestmögliche System, abgesehen von allen anderen Systemen. Es mag als Verschwendung von Ressourcen empfunden werden, aber ist nicht auch die Demokratie als System in Bezug auf die Entscheidungsfindungsgeschwindigkeit alles andere als perfekt?
Ist das EA-Skillset also nützlich für uns Softwareentwickler und Architekten?
Mit der Ausnahme sehr großer Unternehmen, wo EA – wie wir gesehen haben - durchaus seine Daseinsberechtigung als eigene Disziplin hat, trifft man in den meisten IT-Unternehmen auf so genannte IT-Architekten, die alle drei oben genannten Kompetenzbereiche abdecken. Ein IT-Architekt muss oft verschiedene Interessengruppen verstehen und mit ihnen kommunizieren. Das Spektrum reicht dabei von Entscheidungsträgern auf strategischer Ebene über Softwareentwickler bis hin zu Art-Directors und Infrastrukturadministratoren. Daher passen die Fähigkeiten der Enterprise-, Solution- und Technical-Architektur gut in den Werkzeugkasten eines vielseitigen IT-Architekten oder eines agilen Produktentwicklungsteams.
