Warum Prozesse, Frameworks und abstrakte Richtlinien für EAM nicht ausreichen

Enterprise Architecture Management nachhaltig einführen

Sven Guyet, Jose Uzquiano, Steffen Fischer

© iStockfoto.com/270770

Enterprise Architecture Management (EAM) ist eines der zentralen Themen in der IT, um die immer weiter steigende Komplexität im Griff zu behalten. Unternehmen haben dies erkannt und Projekte aufgesetzt, um EAM einzuführen. Viele dieser Vorhaben sind jedoch gescheitert, bzw. haben ihre Ziele nicht erreicht. Dieser Artikel zeigt einen Ansatz auf, EAM nachhaltig im Unternehmen zu etablieren und die richtigen Prioritäten zu setzen.

Die Informationstechnik nimmt im täglichen Leben exponentiell an Bedeutung zu. Wo vor fünf Jahren jeder Haushalt vielleicht einen PC hatte, sind es heute schon mehrere intelligente Endgeräte (TV, Tablet, Smartphone, Laptop, Spielekonsole …) mit der Leistungsfähigkeit von Supercomputern aus der Zeit um die Jahrtausendwende. So, wie mit diesem rasanten Tempo die IT im privaten Umfeld Platz ergreift, ist es auch bei Unternehmen der Fall. Geschäftsprozesse werden nicht mehr nur von einer Anwendung auf einer Plattform unterstützt, vielmehr werden Geschäftsprozesse über mehrere Zugangskanäle auf unterschiedlichen technischen Plattformen (Cloud, Internet, Mainframe, PC) umgesetzt. Die Komplexität der so gewachsenen Anwendungslandschaften ist enorm und wächst stetig weiter. Es müssen unterschiedlichste Programmiersprachen und Technologien gemanagt und vor allem beherrscht werden, um die geschäftlichen Anforderungen umzusetzen. Gleichzeitig werden die Anforderungen an das durch die IT unterstützte Kerngeschäft immer größer. Produkte müssen in immer kürzerem Zeitraum mit entsprechender IT-Unterstütztung auf den Markt gebracht werden. Zwei Beispiele sollen dies plakativ aufzeigen. Früher wurden von Modelabels pro Saison eine Kollektion auf den Markt gebracht, also vier im Jahr. Diese Saisonbindung gibt es heute nicht mehr; alle sechs bis acht Wochen gibt es eine neue Kollektion. Versicherungen brachten zwei Kfz-Tarife pro Jahr, einen Herbsttarif für die Wechsler und einen Frühjahrstarif für die Neuwagen. Heute sollen monatlich neue Tarife die Kunden zum unterjährigen Wechsel bewegen.

All diese Produkte können nur mit der entsprechenden Unterstützung durch IT-Anwendungen auf den Markt gebracht werden. Unternehmen sind somit in besonderem Maße abhängig von der Qualität ihrer Informationsverarbeitung. Es treffen nun zwei widerstrebende Ziele aufeinander: Der notwendige kurzfristige geschäftliche Erfolg von Projekten zur direkten Umsetzung wettbewerbs- und marktorientierter Projekte und die auf mittelfristige bis langfristige Kostenoptimierung ausgerichtete IT-Organisation. Dieser Zielkonflikt wird nicht automatisch gelöst; ganz im Gegenteil entsteht ein Spannungsfeld, das nur durch aktive Zusammenarbeit zwischen Geschäft und IT- Abteilung gelöst werden kann. Die dafür notwendige Managementfunktion wird als Enterprise Architecture Management, kurz EAM bezeichnet (Abb. 1).

Abb. 1: Spannungsfeld zwischen marktorientierten Entwicklungen und IT-Kostenoptimierung

Abb. 1: Spannungsfeld zwischen marktorientierten Entwicklungen und IT-Kostenoptimierung

EAM hat die evolutionäre und bedarfsgerechte Weiterentwicklung der Anwendungslandschaft durch Abwägung der kurzfristig marktorientierten Interessen des Geschäfts und der durch Kostenoptimierung geprägten Interessen der IT zum Ziel. Wenn diese Managementfunktion so wichtig für ein Unternehmen ist, warum sind dann viele EAM-Einführungs- und Umsetzungsprojekte nicht erfolgreich und bleiben in den Anfängen stecken? EAM wird (zu) häufig ausschließlich durch Einführung von Prozessen, Architekturframeworks und Richtlinien aufgesetzt. Das kann nicht funktionieren; es wäre so, als ob durch die Nutzung von Baurichtlinien, Normen und CAD-Werkzeugen automatisch gute Häuser entstünden. Ein nachhaltig erfolgreiches EAM muss den Schwerpunkt auf die Menschen, deren Fähigkeiten und Fertigkeiten sowie die Architekturinhalte legen. Wenn dazu dann noch ein schlanker Prozess mit wenigen und guten Lieferergebnissen implementiert wird, dann entsteht ein EAM, das durch effiziente und effektive Unterstützung der Geschäftsziele Mehrwert für Geschäft und IT-Organisation stiftet.

Ein weiterer Grund, weshalb EAM in der Praxis nicht funktioniert, ist die naheliegende, aber falsche Zusammenführung der Architekten in einer Abteilung. So entsteht die Keimzelle des Elfenbeinturms. Die Mitarbeiter der Architekturabteilung wissen zu wenig vom Geschäft und machen die falschen bzw. viel zu allgemeingültigen Vorgaben, mit denen die Projekte nichts anfangen können. Die Projekte werden durch diese Vorgaben behindert und arbeiten um diese herum. Dadurch werden Projekte verlangsamt, der Geschäftsnutzen kommt zu spät und die IT-Architekten werden frustriert. Die Architekten in den Projekten erkennen den Wert eines EAM und akzeptieren weder die Vorgaben noch die EAM-Verantwortlichen, da diese eher als Verhinderer denn als Förderer richtiger Architekturen wahrgenommen werden. Besser ist es, die Architekten direkt in den Projekten verantwortlich mitarbeiten zu lassen und zu einem geringeren Anteil nicht direkt geschäftsbezogene Arbeiten durchführen zu lassen.

Vorstellung des Lösungsansatzes

Für eine erfolgreiche Einführung eines nachhaltig wirksamen Enterprise Architecture Managements ist es nach Ansicht der Autoren unerlässlich, drei Ebenen gezielt in Einklang zu bringen: Prozesse, Technologie (Assets im Rahmen definierter Plattformen) und die agierenden Menschen (Abb. 2). Viele EAM-Vorhaben konzentrieren sich nahezu ausschließlich auf die Definition neuer Prozesse wie z. B. die Einführung von Architektur Quality Gates und Gremienstrukturen, versäumen es aber, die in den Projekten für die Lösung verantwortlichen Architekten mit entsprechenden Kompetenzen (Fähigkeiten und Verantwortungen) auszustatten und ihnen über professionell betriebene Enterprise-Application-Plattformen die erforderliche Standardisierungsbasis bereitzustellen. Demgegenüber steht ein gleichfalls vielbeobachteter Ansatz, mit hohem Anfangsaufwand Referenzarchitekturen und wiederverwendbare Bausteine aus erfolgreichen Projekten herauszuziehen und zu verallgemeinern, ohne aber im weiteren Verlauf gleichermaßen in eine konsequente Pflege und Weiterentwicklung, eng gekoppelt an die Bedürfnisse und Anforderungen neuer Projekte, zu investieren. Eine solche „Asset-Bibliothek“ fristet nach kurzer Zeit ein Schattendasein, wird den aktuellen Aufgabenstellungen der IT-Projekte nicht mehr gerecht und daher meist auch nicht mehr genutzt. Damit sinkt schnell die Akzeptanz und Verbindlichkeit. Der in diesem Artikel skizzierte Lösungsansatz zur nachhaltigen EAM-Stärkung basiert auf einer austarierten und ausgewogenen Betrachtung aller drei Wirkungsfelder – Menschen, Prozesse und Assets.

Abb. 2: Drei Säulen einer nachhaltigen EAM-Einführung

Abb. 2: Drei Säulen einer nachhaltigen EAM-Einführung

Der Mensch als Erfolgsfaktor für das Architekturmanagement

Die Umsetzung und Einhaltung unternehmensweiter Architekturvorgaben beginnt in den Köpfen der handelnden Personen in den Projekten. Neben dem Projektleiter kommt dabei dem Lösungsarchitekten die maßgebliche Rolle zu. In typischen Projektorganisationen konzentriert sich jedoch die Verantwortung nahezu vollständig auf den Projektleiter. Für IT-Architekten existiert in den meisten IT-Unternehmen kein definierter Karrierepfad; Karriere machen Projektleiter oder Manager. Das interne Ausbildungsprogramm ist nicht spezifisch an den Bedürfnissen der Architekten ausgerichtet. Ein wesentlicher Eckpfeiler zur Stärkung des EAM liegt somit in der Etablierung der Rolle des Architekten und der Verbindung mit einem eigenen Karrieremodell. In dieses Karrieremodell muss ein bedarfsgerechtes Schulungs-Curriculum integriert sein, um parallel zur Gewinnung von Erfahrungen über Projektarbeit auch den Erwerb notwendiger Techniken und Skills für Architekten sicherzustellen. Um der Rolle des IT-Architekten mehr Gewicht zu geben und die Kriterien zur Erreichung einer bestimmten Karrierestufe zu objektivieren, empfiehlt sich der Aufbau eines formalen Zertifizierungsprogramms. Dieses kann organisationsintern (wie z. B. bei IBM seit den 1990er Jahren etabliert) umgesetzt oder in die Architektenzertifizierung der Open Group integriert werden, einem globalen Konsortium von mehr als 400 Mitgliedsorganisation mit dem Ziel der Entwicklung offener, herstellerneutraler IT-Standards und Zertifizierungen. Eine erfolgreiche Zertifizierung als Architekt ist Voraussetzung für die Erreichung einer Karrierestufe im Unternehmen. Dabei sind verschiedene Ausprägungen von Architekten zu unterscheiden, z. B. Anwendungs-, Infrastruktur-, Plattform-, Fach- und Unternehmensarchitekten. In der Praxis hat sich zudem ein dreistufiges Karrieremodell mit den entsprechenden Zertifizierungen bewährt. Auf höheren Stufen kommt neben der zunehmenden Projekt- und Technologieerfahrung den Aspekten Fachwissen, Methodenkompetenz und vor allem Leadership wachsende Bedeutung zu (Abb. 3). Die unterschiedlichen Erfahrungsebenen finden sich in allen weiteren Modellen (Curriculum, EAM-Prozesse) wieder und sind auch wesentliches Kriterium für die Zuordnung von Architekten zu Projekten bzw. Reviews: Je komplexer das Thema, desto höhere Qualifizierung muss der bearbeitende Architekt mitbringen.

Abb. 3: Anforderungen an die Erfahrungen und Fähigkeiten von Architekten

Abb. 3: Anforderungen an die Erfahrungen und Fähigkeiten von Architekten

Um den Einsatz entsprechend qualifizierter Architekten bestmöglich an den Projektanforderungen auszurichten, sollten die zertifizierten Architekten in einer zentralen Organisationseinheit zusammengeführt werden. Diese Einheit ist zum einen für eine adäquate Besetzung von Architekten verantwortlich und steuert zudem die Aktivitäten im Rahmen der unternehmensweiten EA-Prozesse. Die Zuordnung der Mitarbeiter kann formal (im Sinne der Aufbauorganisation mit direkter Personalverantwortung) oder auch informell (Matrixorganisation) erfolgen. In beiden Fällen ist es wichtig, das richtige Verhältnis zwischen Projekttätigkeiten und zentralen Architekturaufgaben zu finden. Wenn die besten Architekten ausschließlich in Projekten unterwegs sind, können sie die unternehmensweite Architektur nur sehr begrenzt gestalten. Umgekehrt fördert ein ausschließliches Agieren in zentralen Architekturaufgaben das Entstehen eines Architektur-„Elfenbeinturms“, der zunehmend die „Erdung“ durch das Projektgeschäft verliert. Das empfohlene Verhältnis zwischen diesen Tätigkeitsfeldern des Architekten verschiebt sich mit zunehmender Qualifikation in Richtung Unternehmensarchitektur, z. B. von 80:20 bei Architekten der untersten Zertifizierungsstufe bis hin zu 60:40 bei den Architekten der höchsten Stufe (vgl. Abb. 4). Die Einhaltung dieser Balance muss aktiv gesteuert werden, um die zentralen Architekturaufgaben gegenüber dem Tagesgeschäft nicht dauerhaft zu vernachlässigen und die Unabhängigkeit von singulären Projektinteressen sicherzustellen. Dies kann insbesondere durch die oben angesprochene zentrale organisatorische Zuordnung und entsprechende ausgewogene Zielvorgaben innerhalb dieser Einheit unterstützt werden.

Abb. 4: Aufteilung der Tätigkeiten von Architekten

Abb. 4: Aufteilung der Tätigkeiten von Architekten

Unsere Kernbotschaft lautet also: Die besten Architekten müssen in den komplexesten Projekten eingesetzt werden und gleichzeitig die strategische Architekturausrichtung des Unternehmens gestalten. Im Rahmen der Projekttätigkeiten obliegt den Projektleitern die Verantwortung für Zeit und Budget, den Architekten jedoch die technische Ende-zu-Ende-Verantwortung für die IT-Lösung, insbesondere für die Einhaltung der nicht funktionalen Anforderungen. Zu den zentralen Aufgaben und Verantwortlichkeiten gehören:

• IT-Strategie, IT-Bebauungsplanung und Architekturberatung
• Asset-Entwicklung und -Pflege im Rahmen der definierten Enterprise-Application-Plattformen
• Training und Förderung von Architekten, Coaching, Mentoring
• Weiterentwicklung des EAM-Prozesses
• Aktivitäten innerhalb des EAM-Prozesses, z. B. Teilnahme an Architektur Boards und Durchführung von Architektur Quality Gates
• Aktive Beteiligung in und Führen von technischen Communities, z. B. Arbeitskreise

Schlanke und verständliche Prozesse

Die Praxiserfahrung zeigt, dass möglichst pragmatische EAM-Prozesse definiert und etabliert werden müssen, damit diese nachhaltig gelebt werden können: Schlank, aber praxisnah und von allen handelnden Personen verstanden und angewendet. Die in vielen Unternehmen definierten EAM-Prozesse werden oft nicht gelebt, vielfach auch gar nicht gekannt. Architekturgremien, falls diese überhaupt definiert sind, agieren häufig losgelöst vom aktuellen Projektgeschäft („Elfenbeinturm“) und sind daher in der Regel „zahnlose Tiger“. Konkrete Verfahren zur Überprüfung und Sicherstellung der Architekturkonformität fehlen. Zeit- und Budgetdruck der IT-Projekte führen zu einer hohen Zahl von Ausnahmen, die in Projektsteuerungskreisen und nicht in den für die Architekturausrichtung verantwortlichen Einheiten entschieden werden. Die Granularität der Entscheidungen ist zumeist sehr unterschiedlich, da klare Kriterien fehlen, in welchen Fällen Architekturentscheidungen erforderlich und auf welcher Ebene diese zu treffen sind. Um dem Anspruch pragmatischer und funktionierender EAM-Prozesse gerecht zu werden, muss aus Sicht der Autoren der folgende Weg beschritten werden:

1. Definition und Etablierung von vier Kernprozessen des Architekturmanagements: Weiterentwicklung, Kommunikation, Überprüfung und Eskalation
2. Besetzung von architekturrelevanten Projekten mit entsprechend qualifizierten (zertifizierten) Architekten
3. Etablierung der notwendigen (!) Gremien (und nicht mehr!)
4. Integration der AM-Kernprozesse in die Anwendungsentwicklungsmethodik (speziell Verankerung der Architekturüberprüfung in Form von Quality Gates im Projektlebenszyklus)
5. Erstellen eines Kriterienkatalogs für die Überprüfung der Architekturkonformität von Projekten im Rahmen von Architektur Quality Gates
6. Kommunikation der Prozesse, um sicherzustellen, dass diese verstanden und gelebt werden

Um eine entsprechende Steuerung und Kontrolle von Architekturstrategie und -entscheidungen zu gewährleisten, reicht es im Sinne eines schlanken Architekturmanagements aus, zwei Gremien zu etablieren: Ein „Architekturbüro“ und ein Governance Board. Das Architekturbüro umfasst alle zertifizierten Architekten. Diese erbringen einen Teil ihrer Arbeitszeit (vgl. oben) für die AM-Prozesse Weiterentwicklung, Kommunikation und Überprüfung. Im Architekturbüro werden alle diejenigen Architekturentscheidungen getroffen, die über einen reinen Projekt-Scope hinaus Relevanz haben. Das Governance Board bildet die Eskalationsinstanz bei Konflikten zwischen Architekturbüro und Projekten und ist darüber hinaus für strategische Architekturentscheidungen verantwortlich. Mitglieder des Boards sind neben Vertretern der Geschäftsführung die Architekten der obersten Qualifizierungsstufe.

Zur Überprüfung und Sicherstellung der Architekturkonformität von Projekten dienen Architektur Quality Gates (Abb. 5). Bereits in der Anbahnungsphase werden im Rahmen des Projektportfoliomanagements Architekten eingebunden, um die Auswirkungen zwischen neuen Projektvorhaben und der Unternehmensarchitektur (z. B. notwendige Erweiterungen der Enterprise-Application-Plattformen) zu bewerten. Die in den Projekten durchzuführenden Quality Gates haben je nach Projektfortschritt unterschiedliche Schwerpunkte zum Inhalt.

Abb. 5: Architektur Quality Gates im Projektlebenszyklus

Abb. 5: Architektur Quality Gates im Projektlebenszyklus

Angelehnt an die Phasenstruktur des IBM Rational Unified Process sind dies:

• Am Ende der Konzeptionsphase: Überprüfung der High-Level-Lösungsarchitektur anhand der funktionalen und nicht funktionalen Anforderungen, Auswahl der geeigneten Technologie/Plattform, frühzeitige Aufnahme von Änderungsanforderungen bzw. notwendigen Erweiterungen der unternehmensweiten Architektur
• Am Ende der Ausarbeitungsphase: Konformitätsüberprüfung der Lösungsarchitektur zu unternehmensweiten Architekturprinzipien und -richtlinien, Aufdeckung von Architekturrisiken
• Am Ende der Konstruktionsphase: Verifikation der entwickelten Lösung hinsichtlich Einhaltung der Architekturvorgaben und Betreibbarkeit

Die Prüfungen erfolgen anhand entsprechender Checklisten; aus den Prüfungen resultierende Auflagen an die Projekte sind bindend, die Erfüllung der Auflagen Voraussetzung für den Eintritt in die nächste Projektphase. Abweichungen sind nur über bewusste Ausnahmeentscheidungen des Architekturbüros möglich. Bei Konflikten zwischen den Interessen des Projekts (bzw. dessen Lenkungsausschusses) und dem Architekturbüro entscheidet das Governance Board als oberste Instanz.

Technologieplattformen als Managementinstrument

Wie bereits weiter oben beschrieben sind die zentralen Aufgaben eines Architekturmanagements die strategische Weiterentwicklung der IT-Architektur und die Sicherstellung der Einhaltung dieser Vorgaben, also der Architekturkonformität. Dies klingt zuerst sehr einfach, ist aber in der Praxis mit einer der schwierigsten Punkte. Oft sind IT-Strategien, Vorgaben und Architekturprinzipien schlicht und ergreifend zu generisch formuliert („Systeme sind lose gekoppelt zu entwickeln“) und verfehlen demzufolge ihren Zweck, da grundsätzlich jedes Projekt Konformität nachweisen kann. Der Nutzen dieser Leitplanken bleibt beschränkt, da konkrete Aufgabenstellungen in den Projekten von dieser Ebene wenig profitieren. Es bleibt also bei so genannter Paperware. Aus unserer Erfahrung ist die beste Möglichkeit, Architekturkonformität herzustellen (und nicht nachträglich in Projekte hineinzuprüfen), den Projekten sehr konkrete Arbeitsmittel an die Hand zu geben und diese technisch verfügbar zu machen. Die Autoren fassen diese Konzepte unter dem Begriff  „Enterprise-Application-Plattformen“ (EAP) zusammen. Eine EAP ist eine Sammlung von erprobten Assets eines Unternehmens, die der Entwicklung und dem Betrieb von Anwendungssystemen dienen (Abb. 6).

Abb. 6: Enterprise-Application-Plattformen ordnen sich in die Cloud-Architektur ein

Abb. 6: Enterprise-Application-Plattformen ordnen sich in die Cloud-Architektur ein

Unter Plattform verstehen wir konkrete Ausschnitte der IT-Architektur eines Unternehmens, die in einer gemanagten Art und Weise weiterentwickelt und betrieben werden. Beispiele sind Java-Plattformen, Mainframe-Plattformen, SAP-Plattform oder auch eine System-Management-Plattform. Kern der Idee ist, unter diesem Ordnungsrahmen alle wiederverwendbaren Artefakte in einer strukturierten Art und Weise in die Projekte zu geben. Artefakte reichen in diesem Fall von Referenzarchitekturen und (konkret auf die Plattform ausgerichteten) Architekturprinzipien über Programmierleitfäden, Designrichtlinien und Betriebsverfahren bis hin zu direkt verwendbaren Implementierungen in Form von Frameworks, Werkzeugen, Installationsskripten etc. Je konkreter und feiner die Artefakte sind, die den Projekten bereitgestellt werden, desto architekturkonformer sind letztendlich dann die Projekte.

Es versteht sich von selbst, dass eine solche EAP nicht als Selbstzweck dient und über einen langen Vorlauf vor den nutzenden Projekten konzipiert und entwickelt werden kann. Genau so gilt, dass sich eine EAP über die Jahre weiterentwickeln muss. Treiber für die Weiterentwicklung sind hierbei der Markt bzw. die Technologie und die Anforderungen, die aus den Projekten entstehen. Um der EAP einen Vorlauf gegenüber den Projekten zu verschaffen, ist es immens wichtig, die verantwortlichen Mitarbeiter für die EAP (in unserem Modell den Plattformarchitekten und Plattformmanager) früh in die Portfolioplanung des Unternehmens einzubinden. Dies ermöglicht, dass die EAP Weiterentwicklungsposten in die Portfolioplanung einbringen kann, um die Plattform frühzeitig an den kommenden Anforderungen auszurichten. Die EAP stellt somit ein wichtiges Instrument dar, die IT-Architektur des Unternehmens zielgerichtet zu steuern.

Wir haben in vielen Unternehmen Ansätze hierzu gesehen („unternehmensweites Framework“, Referenzarchitekturen etc.) und sind überzeugt, dass diese ohne gezieltes Management zu kurz greifen. Unsere Kunden, die eine EAP-Strategie erfolgreich betreiben, haben organisatorische Maßnahmen flankierend eingesetzt. Hierzu gehört beispielsweise eine klare Verantwortlichkeit im Rahmen der Organisation, d. h. ein Team, das als Linienfunktion (ob als Teil des Architekturmanagements oder als Stabsstelle in der Entwicklung oder im Betrieb) die EAP ein Stück entkoppelt vom Projektgeschäft als unternehmensweites Produkt für die Anwendungsentwicklung und den Betrieb weiterentwickeln kann. Dieser Produktcharakter einer EAP ist entscheidend und erlaubt erst eine zielgerichtete Weiterentwicklung, die ihre strategische Bedeutung auch in der teilweisen Entkopplung von Projektbudgets gewinnt. Richtig gemacht sind EAP-Ansätze ein sehr wichtiger Faktor in einem erfolgreichen Architekturmanagement und helfen nicht nur, Architekturkonformität zu erzeugen (die für sich alleine genommen noch keinen Wert darstellt), sondern Qualität in die Projekte zu bringen und greifbaren Nutzen in Anwendungsentwicklung und Betrieb zu erzeugen, ohne ein Hemmschuh für den Projektfortschritt zu sein. Dies erfordert die richtige und zugleich pragmatische Strategie sowie Architekten und Führungskräfte, die diese nachhaltig verfolgen.

Zusammenfassung und Fazit

Die nachhaltige Stärkung des Architekturmanagements ist ein äußerst anspruchsvolles Projekt mit einer Reihe kritischer Erfolgsfaktoren:

• Ein Management-Sponsorship, das einen langen Atem hat und behält, kurzfristige Erfolge sind eine Illusion
• Identifikation und Integration aller relevanten Stakeholder: Architektenmeinungsmacher, Betriebsrat, Kunde, Projektleiter, Entwickler, Führungskräfte …
• Überzeugung durch inhaltliche Substanz und ein sehr erfahrenes Team
• Intensives Change Management auf allen Ebenen
• Transparente und zeitgerechte Information

Unterstützung durch das Management klingt wie eine Plattitüde, die bei nahezu jedem kritischeren Projekt angebracht wird. Grundsätzlich stimmt das. Im Falle eines Projekts zur Stärkung des Architekturmanagements gilt dies aber in besonderem Maß. Gefordert ist hier nicht nur ein Managementsupport, der hinter den Inhalten steht und mit am Change Management arbeitet, sondern ein Management, welches einen (sehr) langen Atem behält. Erfolge in einem Projekt zur Veränderung des Architekturmanagements stellen sich nachhaltig erst nach Jahren ein. Selbstverständlich gibt es Zwischenschritte und Erfolge auf dem Weg dahin. Bis zur Umsetzung und Etablierung eines wirklich funktionsfähigen Architekturmanagements mit allen Facetten sind jedoch schnell einige Jahre vergangen. Wichtig ist, dass das Management transparent über die Zwischenerfolge Bescheid bekommt und sieht, dass sich das Projekt in die richtige Richtung entwickelt. Ein Veränderungsprojekt hat typischerweise mehr Stakeholder als anfänglich erwartet. Es gilt, diese zu identifizieren und in das Projekt einzubinden. Das heißt, es sind auch solche Stakeholder zu informieren und ihre Bedenken einzuholen und zu berücksichtigen, die nicht offenkundig zum direkten Projektkontext gehören. Ein Beispiel hierfür sind die Projektleiter, die typischerweise in den Unternehmen die zentrale Rolle in den Projekten ausgeübt haben. Wird der Architekt gestärkt, so verliert der Projektleiter ein Stück seiner Entscheidungs- und Richtlinienkompetenz. Es ist wichtig, den Projektleitern diese Veränderung positiv nahezubringen, um deren „Buy-in“ früh zu gewinnen.

Es versteht sich von selbst, dass alle organisatorischen Maßnahmen auch die Einbindung von Mitbestimmungsgremien und Personalabteilungen erfordern. Dies muss früh erfolgen, und es ist ausreichend Zeit hierfür einzuplanen, da ohne Abstimmung mit den Mitbestimmungsgremien eine Kommunikation in das Unternehmen nicht funktionieren kann. All diese Aspekte laufen unter dem neudeutschen Begriff „Change Management“ respektive Veränderungsmanagement. Dies wird bei den Aufwänden und den Zeiten, die für die Einführung eines Unternehmensarchitekturmanagements benötigt werden, häufig eklatant unterschätzt. Unsere Erfahrungswerte zeigen, dass hierfür gut und gerne 30–50 Prozent des Gesamtaufwands eines Veränderungsprojekts eingeplant werden müssen. Im Change Management werden die Stakeholder des Projekts abgeholt und für das Projekt gewonnen. Hierfür sind kreative und nachhaltige Maßnahmen erfolgsentscheidend. Es hat sich z. B. bewährt, frühzeitig zu beginnen, regelmäßige Newsletter bereitzustellen. Selbstverständlich ist man nicht in der Lage, jeden Zwischenstand direkt zu verteilen. Es ist jedoch wichtig zu informieren, an welchen konkreten Themen gerade gearbeitet und wann es eine Kommunikation dazu geben wird. Solche Kommunikationstermine müssen dann natürlich eingehalten werden, um die Vertrauensbasis zu erhalten. Weitere Maßnahmen sind Informationscafes, Vorträge, Beiträge in Mitarbeiterzeitungen, Videos, bilaterale Informationen im Rahmen von Sprechstunden etc. Die Erfahrung zeigt: Mehr Kommunikation hilft!

Um glaubwürdig zu bleiben, muss der Erfolg eines Projekts zur Stärkung des Architekturmanagements nachgewiesen werden. Dies muss so erfolgen, dass dies schon früh im Projekt geschieht. Das Projekt muss aber auch Metriken einführen, um sicherzustellen, dass der Erfolg auch nachhaltig ist. Gerade in diesem Punkt zeigt unsere Erfahrung, dass viel mit zweifelhaften Verfahren und Kennzahlen gearbeitet wird, die unter dem Strich einer tiefen Prüfung nicht standhalten. Es ist nicht so einfach, den Erfolg des Vorhabens nachzuweisen, da die Problematik vielschichtig ist und an vielen Stellen eine Wirkung erzeugt – positiv wie auch negativ. Wird im Unternehmen beispielsweise parallel zur Stärkung des Architekturmanagements auch eine Maßnahme zur Verbesserung der Anwendungsentwicklungsmethodik durchgeführt, wer kann sich dann am Ende eine Verbesserung der Fehlerstatistiken auf die Fahne schreiben? Architekturmanagement oder Methodik? Vermutlich beide. Wir schlagen daher ein zweistufiges Verfahren vor. Zum einen sollte das Projekt vor dem Start ein objektive Einschätzung der Fähigkeiten des Architekturmanagements vornehmen, z. B. nach der in TOGAF vorgeschlagenen Methode „Architecture Capability Maturity Model“ (ACMM). Auf Basis dieser Einschätzung sollten Zwischenziele in den einzelnen Dimensionen festgelegt werden, die man auf der Zeitstrecke erreichen will. Abbildung 7 zeigt eine exemplarische Einordnung der Architekturmanagementfähigkeiten nach ACMM (Ist- und Soll).

Verwandte Themen:

Geschrieben von
Sven Guyet
Sven Guyet ist IBM Senior Certified Architect und berät seit einem Vierteljahrhundert Kunden vornehmlich in der Versicherungsbranche in den Bereichen Anwendungsentwicklung, Methodik und Architekturmanagement.
Jose Uzquiano
Jose Luis Uzquiano ist Associate-Partner in der Beratungssparte IBM Global Business Services und verantwortet für den Bereich Applikationsinnovation bei Versicherungskunden. Er hat eine Vielzahl von Projekten zu Architekturmanagementthemen durchgeführt.
Steffen Fischer
Steffen Fischer ist IT-Architekt bei der Provinzial Rheinland Versicherung AG. Seine inhaltlichen Schwerpunkte sind im Bereich Enterprise-Architekturen und Architekturmanagement. Er hat langjährige Erfahrung als Chefarchitekt in komplexen IT-Projekten im Finanzdienstleistungssektor und ist zertifiziert als Open Group Certified Distinguished Chief IT Architect.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: