Digitalisierung, Digitale Transformation, Industrie 4.0, Agilisierung - wenige andere Begriffe haben Fachseite und IT in Unternehmen in den letzten Jahren gleichermaßen intensiv beschäftigt. Dieser Artikel betrachtet das Thema Agilität aus der Sicht des Enterprise Architektur Managements (EAM) und erklärt, warum der Wirkungsgrad (bzw. die Reichweite) einer Unternehmensarchitektur deutlich ausgebaut werden muss. Mit zwei konkreten Ansätzen lässt sich den damit einhergehenden Herausforderungen gut begegnen.
Agiles Business
Die Digitalisierung findet in zwei Hauptbereichen von Unternehmen statt: in der Produktentwicklung von "smarten" Produkten und in den Unternehmensvorgängen selbst. Beispielsweise bei der Optimierung der Produktion (der digitale Zwilling oder Industry 4.0 lassen grüßen) oder etwa dem Partnering, der Zusammenarbeit mit anderen Unternehmen zur Bereitstellung neuer Dienstleistungen und Produkte.
Produkte werden "smart". Durch Hinzufügen neuer Technologien werden Bohrmaschinen und Akkuschrauber intelligent, passen ihre Betriebsparameter den aktuellen Bedingungen an und melden Verbrauchswerte und Verschleiß. Die Hersteller bieten nun neben den Geräten selbst Serviceleistungen an, welche versprechen, die Geräte zu warten, bevor sie ausfallen.
Der Reinigungsmaschinenhersteller Kärcher beispielsweise plant, Maschinen zu vermieten und lediglich die gereinigten Quadratmeter abzurechnen, die direkt durch die Maschinen gemessen werden. Ein weiteres Szenario ist, dem Gebäudereiniger Nutzungsinformationen der Aufzüge von Gebäuden aufbereitet anzubieten, die Verschmutzung der einzelnen Etagen zu prognostizieren, damit entschieden werden kann, ob und mit welchem zu erwartenden Aufwand einzelne Gebäudebereiche zu reinigen sind.
Es lassen sich folgende Merkmale der Digitalisierung ableiten, die für unsere Betrachtung wesentlich sind:
- Die Digitalisierung der Produkte verändert die in einem Unternehmen benötigten Fähigkeiten wesentlich. Der Hersteller von Akkuschraubern, welcher nun in seinen Produkten "Intelligenz" verbaut und mit Hilfe der Daten der Geräte neue Services anbietet, wird von einem reinen Werkzeugmaschinenhersteller zu einem konkreten IT Dienstleister.
- Die Fachbereiche treten vermehrt als Technologietreiber auf. Insbesondere im Produktdesign ist es wichtig, den Marktanschluss durch innovativere Produkte und insbesondere "smarte" Services nicht zu verlieren. Neue Technologien, neue Produkte und Synergien mit anderen Unternehmen wollen entwickelt und evaluiert werden. Die Zeiten, in denen die Einführung neuer Technologien durch die Unternehmensarchitektur von langer Hand geplant und eingeführt werden, sind vorbei. Die Fachseite tritt nun ihrerseits an die Unternehmensarchitektur heran und stellt sie vor neue Herausforderungen. Und nicht nur das - sie klopfen immer häufiger an die Tür der Unternehmensarchitekten. Fachbereiche beeinflussen so einen immer größeren Teil der IT Ausgaben. Laut einer Studie von PWC sind es bereits zwischen 30% und 70%.
- Die Zyklen, in denen die Produkte oder Services sich ändern oder neue Technologien eingeführt werden, werden immer kürzer. Der Wunsch nach einer agilen Arbeitsweise wird, und das ist nicht wirklich überraschend, ebenfalls zunehmend von der Fachseite geäußert. Diese neue Qualität von Änderungen insbesondere gepaart mit deren Häufigkeit stellt die IT vor große Herausforderungen. Die Prozesse erweisen sich als zu schwerfällig und unflexibel. Die Produktionssysteme der IT sind oft nicht auf kurze Release Zyklen ausgelegt. Ein gutes Beispiel sind die Bereitstellungssysteme der Telekommunikationsdienstleister, auch bekannt als Operations Support Sytems (OSS), die über Jahrzehnte hinweg gewachsen sind und mit den Ziel der höchstmöglichen Stabilität designed, betrieben und bewirtschaftet werden. Zur Bereitstellung von Produkten werden diese Systeme oftmals angepasst, was zu langen Vorlaufzeiten und Releasezyklen führt.
Selbst wenn Fachbereiche und Produktmanagement in der Lage sind, in Rekordzeit neue Produkte zu entwerfen und zur Marktreife zu bringen, so wirken diese Vorteile erst durch eine technische Bereitstellung, die diese Geschwindigkeit mitgehen kann.
"Stay in the race" und "Win the race"
Der von Gartner eingeführte Begriff der "bi-modalen" IT ist somit eine Zwischenstufe, nicht jedoch ein Endzustand. Die IT muss derzeit die Balance halten zwischen dem stabilen Betrieb der wichtigsten Infrastruktur und Systeme eines Unternehmens (Stay in the race) und der Fähigkeit, auf die verstärkt eintreffenden Anforderungen der Fachseiten zeitnah bedienen und produktiv bereitstellen zu können (Win the race). Zielszenario und absoluter Traum jedes Produkt Managers ist ein Release on Demand Szenario, indem neue Produkte und Änderungen quasi ad-hoc bereitgestellt werden können.
Wie begegnen Unternehmen diesen Herausforderungen?
Gemäß einer Studie, die DETECON in Kooperation mit der Bitkom durchgeführt hat, erwarten Unternehmen in der Zukunft, dass die wesentlichen organisatorischen Änderungen in folgenden Bereichen stattfinden werden: IT, Service, Produktion, Sales, Logistics. In dieser Reihenfolge.
Doch mit organisatorischen Änderungen allein ist es nicht getan. Die Herausforderung liegt darin, die im Unternehmen nun benötigte Agilität herzustellen, die es erlaubt, die Innovationskraft der Fachseiten zeitig auf die Straße zu bringen.
Agile IT
Ohne in diesem Artikel auf die Details agiler Methoden eingehen zu wollen, muss doch anerkannt werden, dass die Vorzüge agiler Methoden erkannt worden sind. Mit Hilfe agiler Methoden rückt man von dem klassischen Phasenmodell Anforderungskonzeption-Spezifikation-Entwicklung-Test-Abnahme ab.
Der wesentliche Treiber hierbei ist die Möglichkeit, in kurzen Zyklen den Status des Vorhabens zu kennen und dabei kurzfristig Änderungen vornehmen zu können. Das Risiko, dass der Auftraggeber erst zum Ende des Vorhabens erkennt, dass er nicht das bekommt, was er benötigt, wird mit Hilfe agiler Methoden eliminiert.
Für die IT hat ein agiles Business folgende Konsequenzen:
- hohe Änderungsrate aus verschiedenen Bereichen des Unternehmens
- höhere Anforderung an die Flexibilität der Systeme und Prozesse. Ein neues oder geändertes Produkt wird irgendwann auch durch die Kernsysteme des Unternehmens (System of Records) prozessiert
- die Architekturfunktion muss in den agilen Teams repräsentiert werden. wenn auch nicht in Form von ständiger Präsenz, so doch zumindest bei wichtigen Planungs- und Reviewmeetings
- Ein steigender Grad an Koexistenz von agiler und Wasserfall Methodik
- die technische Bereitstellung muss sich auf kürzere Lieferzyklen umstellen. Release on Demand und Continuous Integration haben in der Regel einen erheblichen Einfluss auf die Art und Weise der technischen Bereitstellung. Erst durch sie entfalten agile Vorgehen erst ihre gewünschte Wirkung für das Geschäftsergebnis des Unternehmens.
Der Reifegrad in der Unternehmensarchitektur, das merken wir in unseren TOGAF Schulungen, ist in den letzten Jahren stark gewachsen. Enterprise Architektur Management (EAM) ist in den Unternehmen angekommen, toolgestütztes Architekturmanagement verbessert die Kenntnis über Systeme und Infrastruktur und erleichtert die Planung von Vorhaben.
Reichweite ist der Schlüssel
Doch ein hoher Reifegrad der Enterprise Architektur Management Praktiken führt nicht zwangsläufig auch zu einer besseren Wirkung. Diese lässt sich in erster Linie durch eine verbesserte Reichweite des Architekturmanagements erreichen. Mit Reichweite ist hier der Einflussbereich der Unternehmensarchitektur gemeint. Findet Architekturarbeit nur in einem kleinen, „erlauchten“ Kreis statt oder gibt es ein weitreichendes evtl. gar kollektives Verständnis von Unternehmensarchitektur? Es wird angenommen, dass die typische Reichweite des Architekturmanagement bei etwa 10% liegt. Als Grundlage für eine dezentrale Entscheidungskultur ist dies zu wenig.
Neben der Akzeptanz ist eine große Reichweite bzw. ein großer Wirkungsbereich eines der Hauptanliegen eines EAM.
Die klassischen Strukturen der Unternehmensarchitektur mit ihren Standards, Gremien, Prozessen und Formularen sollen sicherstellen, dass überall im Unternehmen die richtige Architektur für den jeweiligen Kontext angewandt wird. Alle Entscheidungen - insbesondere die kritischen - werden kanalisiert und zentral entschieden.
Die Notwendigkeit, Architekturentscheidungen durch zentrale Prozesse zu führen, hat den unerwünschten Nebeneffekt, dass die Unternehmensarchitektur häufig als „Verhinderer“ oder „Bremser“ wahrgenommen wird und entsprechend mehr Überzeugungsarbeit leisten muss, um die "richtigen" Ergebnisse zu erreichen.
Für die Fachseiten welche nach agilen Methoden vorgehen, ist ein direkter Zugang zur Unternehmensarchitektur von hoher Bedeutung. Die Entwicklung in kurzen Zyklen wird idealerweise durch Vertreter der Architektur begleitet, welche die technischen Leitplanken setzen und helfen, die Machbarkeit von Änderungen schnell und konform zu ermöglichen.
Es ist jedoch nicht möglich, jedem Vorhaben einen geeigneten, dedizierten Architekten zur Seite zu stellen. Dafür ist in der Regel die Organisationsstärke nicht ausreichend. Zusätzlich sind die Themen in den einzelnen Vorhaben zu unterschiedlich und erfordern bei Innovationsvorhaben in der Regel spezielle Kenntnisse. Dennoch wäre es, mit Blick auf die erwähnte Reichweite der Unternehmensarchitektur, ideal, wenn die Teams Architekturkompetenz hätten.
Merkmal agilen Vorgehens: dezentrale Entscheidungen
Ein wichtiges Merkmal der agilen Methoden ist die Eigenverantwortung der Teams. Sie entscheiden und priorisieren die Aufgaben selbst, welche im anstehenden Entwicklungszyklus durchgeführt werden.
Für eine Entscheidungshoheit in den Teams spricht, dass Entscheidungen somit dort getroffen werden, wo sich die dazu nötige Kompetenz befindet. Teams organisieren sich selbst und besorgen sich Zugriff auf die benötigte Expertise. Dies ist einer der Gründe, warum die hohe Verfügbarkeit der Rolle des Product Owners in SCRUM von so hoher Wichtigkeit ist.
Bei Fragen zur Unternehmensarchitektur verhält es sich in der Regel etwas anders. Hier geht es vorrangig um Konformität und Prozesse, die einzuhalten sind. Somit sind Unternehmensarchitekten als ständige Mitglieder etwa eine SCRUM Teams nicht sinnvoll.
Architectural Thinking
Architectural Thinking beschreibt ein kollektives Verständnis von Architekturqualität. Es geht dabei darum, innerhalb eines Unternehmens ein möglichst weitreichendes und dabei einheitliches Verständnis von "guter" Architektur zu etablieren. Dies gilt natürlich umso mehr für diejenigen Bereiche in denen Architekturentscheidungen getroffen werden sollen.
Es drängt sich der Vergleich mit Themen wie Mülltrennung und Anschnallen im Auto auf - in manchen Ländern finden diese fast schon unbewusst statt, bzw. es fällt sofort auf, wenn es nicht stattfindet. Man fühlt sich unwohl, wenn man im Urlaub den Joghurtbecher zum Teebeutel entsorgen muss, weil es nur einen Mülleimer gibt; oder wenn der Taxifahrer nicht angeschnallt ist. Es gibt hier ein kollektives Bewusstsein von Richtig und Falsch.
Ähnlich, wie es eine kollektive Vorstellung im Unternehmen für ein "gutes Produkt", wie etwa "ein guter Akkuschrauber" gibt, beschreibt der Begriff Architectural Thinking, wie das Verständnis von einer "guten Architektur" etabliert ist.
Nach Prof. Dr. Aier von der Universität St Gallen richtet sich Architectural Thinking an Mitarbeiter außerhalb der Unternehmensarchitektur mit dem Ziel, Architekturkonzepte und -pläne des Unternehmens zu verstehen und sie zu befähigen, entsprechend zu handeln.
Das formalisierte und gremiengesteuerte Architekturmanagement soll erst dann greifen, wenn lokale, autonome Entscheidungen nicht mehr ausreichen. Dies wäre beispielsweise bei Projekten der Fall, in denen über mehrere Unternehmensteile hinweg gearbeitet wird und Architekturentscheidungen Auswirkungen auf Bereiche außerhalb des eigenen Kompetenzbereiches haben.
Das Konzept des Architectural Thinking ist also kein Ersatz für das traditionelle EAM, sondern ein Konzept zur Erhöhung dessen Reichweite bzw. Vergrößerung des Wirkungsbereiches.
Architekturdomänen
Eine weitere Möglichkeit, die Reichweite der Unternehmensarchitektur zu erhöhen und zu steuern, bietet das Konzept der Architekturdomänen. Es unterteilt die Unternehmensarchitektur in Segmente/Domänen, platziert dort Domänenarchitekten und stattet diese mit Entscheidungskompetenz aus. Dies bringt mehrere Vorteile mit sich. Architektur findet somit näher am Ort des Geschehens statt.
Der Umfang der Unternehmensarchitektur reduziert sich nun darauf, den Umgang der Domänen untereinander zu regeln. Während die Domänenarchitekten jeweils autonom agieren, gelten für domänenübergreifende Aktionen Regeln und Standards, die durch die Unternehmensarchitektur bestimmt sind.
Letzteres kommt insbesondere dem oben erwähnten Umstand zugute, dass Innovationen und Technologien jeweils domänenspezifisch sind. Während in der Produktentwicklung beispielsweise die Themen IOT und Analytics dominieren, sind es im Bereich der Backendsysteme etwa die Cloud Services. Die Domänenarchitekten sind somit Experten in den für ihre jeweilige Domäne typischen Themen.
Domänenarchitekturen sowie die Rolle des Domänenarchitekten sind bereits in vielen Unternehmen anzutreffen. Beide werden jedoch in Regel noch von einem zentralen Architekturmanagement gesteuert. Neu an der hier dargestellten Idee ist die Autonomie der Domänen bei gleichzeitiger Entschlackung des zentralen Architekturmanagements und die Pflege eines kollektiven Verständnisses von "guter Architektur".
Skalierung Agiler Methoden
Dass agile Projekte nur schwer skalieren ist mittlerweile bekannt. Insbesondere in Unternehmen die eine bestimmte Größe überschreiten, kommt es zu Konflikten mit den etablierten Prozessen und Gremien. So muss etwa zur Freigabe des Projektbudgets in der Regel erst eine detaillierte Planung des Gesamtvorhabens zur Kostenermittlung vorliegen. Für agile Projekte, die zu Beginn des Vorhabens noch nicht im Detail wissen, was zum Schluss tatsächlich geliefert wird, ist dies nicht darstellbar.
Mit der Skalierung agiler Methoden auf Programm und Portfolioebene befasst sich unter anderem das Scaled Agile Framework SAFe. SAFe ist das am weitesten verbreitete Framework und wird ständig durch eine große, aktive Community verbessert, indem Erkenntnisse aus dem Praxisalltag einfließen.
Eine Diskussion dieses Frameworks geht über den Rahmen dieses Artikels hinaus. Es lohnt sich jedoch, einen Blick auf die Rolle der Unternehmensarchitektur in diesem Framework zu werfen.
Zusammenfassung
Agilisierung, Digitalisierung und technologischer Innovationsdruck kommen verstärkt aus Bereichen außerhalb der IT, erhöhen den Druck und stellen höhere Anforderungen an die Lieferfähigkeit. Die zentralen Prozesse und Gremien, welche eine einheitliche Gestaltung der Unternehmensarchitektur gewährleisten sollen, erweisen sich als zu schwerfällig und hinderlich.
Eine dezentrale Entscheidungskompetenz in Architekturthemen würde die Situation entlasten. Der EAM Funktion macht hierbei insbesondere eine mangelnde Reichweite von Architekturwissen zu schaffen, eine personelle Unterstützung direkt in den Projekten ist in der Regel nicht zu stemmen.
Das Etablieren eines kollektiven Architekturverständnisses (Architectural Thinking) in Kombination mit der Unterstützung durch Domänenarchitekten etabliert lokale Entscheidungskompetenz und ermöglicht eine Entschlackung des zentralen EAM. Erfolgt parallel die Befähigung der Bereitstellungssyteme in Richtung Release on Demand, sind damit die Voraussetzungen für eine optimale Unterstützung agiler Vorhaben geschaffen.
