Was Enterprise Architekten können müssen

DB-Systel stellt Architekten ein, die ein technisches Studium absolviert haben, mehrere Jahre Berufserfahrung als Softwareentwickler und/oder Projektleiter haben sowie gute Kommunikationsfähigkeiten bis hoch zur C-Level-Ebene besitzen. Die wünschenswerten Eigenschaften eines Architekten beschreibt Gerberding mit: "zielstrebig, strukturiert, offen für Neues, Lern- und Kommunikations- sowie Kritikfähigkeit."

Ihm sind tiefe Kenntnisse in der Software-Architektur wichtig und Erfahrungen als Architekt in (großen) IT-Projekten. "Dabei lege ich auch Wert darauf, dass die Leute gelernt haben, welche der entworfenen Architekturen sich in der Praxis bewähren." Projektmanagement-Erfahrung findet der DB-Systel-Architekt bei Software-Architekten als hilfreich, bei Enterprise Architekten erachtet er sie als Muss.

Auch Gerberding sieht viele Veränderungen in der Arbeitsweise. Zum einen werde das benötigte Skillset größer, weil von Architekten Kenntnisse benötigt würden, um Eigenschaften in der entwickelten Software zu realisieren, die früher von der Rechenzentrums-Infrastruktur bereitgestellt wurden. "Da musste sich der Architekt weder um Hochverfügbarkeit noch um Netzwerksicherheit kümmern. In der Public Cloud, für die wir in Zukunft viele unserer Systeme entwickeln werden, muss er darüber nachdenken, wie sich das am besten realisieren lässt." Außerdem ändere sich gerade das Vorgehen: weg vom Wasserfall-Modell hin zu agilem Vorgehen. "Die Architekten müssen sich umorientieren. Sie werden zum Teil direkt in DevOps-Teams mit ihren Kollegen in der Entwicklung zusammenarbeiten und schon hier an der Architektur mitarbeiten."

Laut Gerberding wird sich die Rolle der Enterprise Architecture insgesamt von einer eher kontrollierenden zu einer mitentwickelnden Organisation verändern. Ihm zufolge werden das Architekturwissen und die Sensibilität dafür in der IT deutlich ansteigen, sodass es weniger zentraler Governance bedarf.

"Natürlich wird es weiter Guidelines geben, und in besonders sensiblen Bereichen wie Sicherheit werden wir sehr aktiv mitarbeiten. Aber dieses Schwergewicht auf Governance des Gesamtsystems wird es nicht mehr geben. Diese Ansätze haben sich in der digitalen Welt als zu langsam herausgestellt. Unser Ziel ist, sehr viel mehr Verantwortung in die Teams zu übertragen und sie mit genügend Architektur-Know-how und -Sensibilität auszustatten."

Schweizer SBB: Strikte Governance stört agile Entwicklung

Laut Yannis Baillet, Enterprise Architekt bei der Schweizer SBB, veränderten sich die Rahmenbedingungen für EA auch im Schweizer Konzern. Plötzlich waren Systemstabilität und Redundanzfreiheit nicht mehr die wichtigsten Kriterien für die IT, sondern Agilität und Flexibilität. "Und da ist eine strikte Governance, die sich über die gesamte IT erstreckt, eher störend", erläutert Baillet.

Da sich die Architektur aber sehr früh fragte, wie sie den Wunsch nach mehr Agilität unterstützen kann, wurde EAM bei den Schweizern nicht grundsätzlich in Frage gestellt. Im Gegenteil. Da die IT den Digitalisierungsprozess steuern soll und die "alte" Architekturtruppe dabei eine führende Rolle spielen soll, hat EAM auch heute einen sehr hohen Stellenwert. "Die traditionelle Rolle der Architektur als Governance-Instanz ist heute weniger gefragt", so Baillet.