Zehn Tipps für Enterprise-Architekturen

13.02.2007
Wer mit begrenzten Mitteln eine leistungsfähige und flexible IT-Organisation auf die Beine stellen will, kommt um das Architektur-Management nicht herum. Viele Unternehmen sind damit jedoch überfordert.
Enterprise-Architekten müssen die unterschiedlichen Informationen auf Anwendungs-, Daten-, Prozess- und Organisationsebene zusammenführen und mit allen Verantwortlichen im Unternehmen und dessen Umfeld teilen. Dazu gibt es eine Reihe von Tools meist kleinerer Anbieter, die überwiegend aus den Bereichen Modellierung oder Metadaten-Verwaltung stammen.
Enterprise-Architekten müssen die unterschiedlichen Informationen auf Anwendungs-, Daten-, Prozess- und Organisationsebene zusammenführen und mit allen Verantwortlichen im Unternehmen und dessen Umfeld teilen. Dazu gibt es eine Reihe von Tools meist kleinerer Anbieter, die überwiegend aus den Bereichen Modellierung oder Metadaten-Verwaltung stammen.

Beim Aufbau von Enterprise-Architecture-(EA-)Programmen sind Unternehmen nicht besonders erfolgreich. Gartner hat 250 IT-Manager nach ihren EA-Erfolgen befragt. Anhand von acht Kriterien konnten die Interviewten auf einer Skala von 1 (geringer Reifegrad) bis 5 (hoher Reifegrad) angeben, wie weit sie mit ihren Architekturanstrengungen gediehen sind. Die Antworten kamen von Unternehmen unterschiedlicher Branchen und Größe, die ihre Architekturprogramme zum Teil erst gerade aufgesetzt hatten, zum Teil aber schon seit Jahren betreiben. Der Durchschnittswert für den Reifegrad der EAs liegt demnach bei lediglich 2,3.

Hier lesen Sie ...

• welche Voraussetzungen erfüllt sein müssen, damit Enterprise-Architektur-Programme erfolgreich sind;

• warum Enterprise-Architekten sich beim Modellieren zurückhalten sollten;

• dass die IT-Vergangenheit nicht die Zukunft diktieren sollte;

• welche Talente für das Architektur-Management gebraucht werden und

• warum jeder Fortschritt zu dokumentieren ist.

Mehr zum Thema

www.computerwoche.de/

583366: Der Stadtplaner des CIO;

582910: Architektur-Management nutzt auch dem IT-Betrieb;

584308: EAM braucht oft mehrere Anläufe;

582201: Enterprise Architecture treibt SOA;

569662: In zehn Schritten zur SOA.

Defizite zeigten sich vor allem in den Kriterien "Effektivität der Architektur", "Business-Kontext" und "Einbindung der Stakeholder". Mehr als zwei Drittel der Antwortenden bestätigten, ein EA-Programm gestartet zu haben, doch in der Regel fehlt es noch an wichtigen Details.

Trotzdem gelangt Gartner zu der Erkenntnis, dass einige Unternehmen - unabhängig von Größe, Branche und Kultur - sehr nah daran sind, den Heiligen Gral zu finden. Ihre EA-Programme funktionieren und bieten ihren Unternehmen einen echten Wert. Auf der Hausmesse ITxpo präsentierten die Analysten folgende zehn Tipps für den Aufbau von Enterprise Architectures, die auf den Best Practices der identifizierten Vorreiter beruhen.

EA-Programme brauchen ein Statut

Wer eine EA plant, sollte zuerst in einer "Satzung" dokumentieren, welche Vorteile er sich davon verspricht und wie diese erreicht werden sollen. Ein solcher Grundsatzplan regelt auch, wer am Bau der Architektur beteiligt ist und was er beizusteuern hat. Er umreißt den Wertbeitrag und die Reichweite der EA für das Unternehmen. Festgelegt werden die Befugnisse des EA-Teams und wie Entscheidungen zustande kommen sollen. Außerdem wird der Zeitraum definiert, in dem Architekturbestandteile entstehen sollen. Je genauer festgeschrieben wird, wozu das EA-Programm da ist und was die Kriterien für seinen Erfolg sind, desto größer ist die Realisierungschance des verantwortlichen Teams.

Einen Kommunikationsplan entwickeln

In einem EA-Programm müssen viele Dinge kommuniziert werden. Das Spektrum reicht von der Reichweite und den Zielen der EA über die zu treffenden (und zu rechtfertigenden) Entscheidungen bis hin zu den Zwischenergebnissen, die im EA-Prozess erzielt werden. Dazu bedarf es eines formalen Kommunikationsplans und der Definition zentraler Schlüsselbotschaften an die Stakeholder - gemeint sind alle relevanten Anspruchsgruppen vom Manager über diverse Abteilungen und Mitarbeiter bis gegebenenfalls hin zu Lieferanten, Kunden und Gesellschaftern. Alle Gruppen müssen ständig über den Wertbeitrag der EA sowie über Fortschritte informiert werden, wobei so zu kommunizieren ist, dass die Adressaten verstehen, worum es geht.

Festzulegen sind ferner die Kommunikationsmedien, derer sich alle bedienen, sowie ein Aktionsplan mit Zeitvorgaben und Zuständigkeiten. Um sicherzustellen, dass der Kommunikationsplan funktioniert, sollte ein Feedback-Prozess etabliert werden.

Jede Iteration wie ein Projekt behandeln

Aufbau und Weiterentwicklung einer EA sind keine klassischen Projekte mit definiertem Anfang und Ende. Deshalb lassen EA-Teams häufig die sonst typische Projektdisziplin vermissen, was zu einem Verlust an Fokussierung und Ergebnisorientierung führen kann. Damit fehlt es den Initiativen an Professionalität; IT-Mannschaften und Unternehmensleitungen beginnen zu nörgeln. Gartner schlägt deshalb vor, Projektpläne für jede Iteration des Architekturprozesses zu entwerfen. So lassen sich Aufgaben planen und die nötigen Ressourcen bereitstellen. Zeitpläne und Meilensteine können identifiziert, gegenseitige Abhängigkeiten koordiniert werden. Erfolgreiche EA-Teams beschäftigen oft professionelle Projekt-Manager, um Disziplin in den EA-Prozess hineinzubringen.

Auf die Business-Strategie kommt es an

Wo keine Geschäftsstrategie existiert, ist der Aufbau einer EA sinnlos. Erstaunlicherweise beklagen die meisten EA-Verantwortlichen dieses Problem. Natürlich folgt nahezu jedes Unternehmen einer Strategie, doch ist diese in vielen Fällen nicht sorgfältig und für jedermann nachvollziehbar definiert. Folge ist, dass die EA-Verantwortlichen Schwierigkeiten haben, die Business-Ziele zu unterstützen und ihren Beitrag zum Unternehmenserfolg deutlich zu machen.

Die Business-Strategie legt im Idealfall knapp und genau fest, welche Ziele ein Unternehmen verfolgt und wie es das tut. Dabei sollten fünf Fragen beantwortet werden können:

• Womit will das Unternehmen sein Geld verdienen?

• Welche Märkte sollen bedient werden?

• Wo liegen dabei die geografischen Grenzen?

• In welchen Zeiträumen soll was erreicht werden?

• Wie werden die Ziele erreicht?

Der Status quo spielt keine Rolle

Wer ein EA-Programm aufsetzt, sollte sich nicht zu lange mit der Detailanalyse der bestehenden IT-Landschaft aufhalten. Vielmehr geht es darum herauszufinden, wie die künftige IT-Umgebung idealerweise aussehen sollte, um die Geschäftsziele des Unternehmens optimal zu unterstützen. Ein wichtiges Ziel von EA ist es, Unternehmen flexibler werden zu lassen, damit sie besser auf Marktanforderungen reagieren können. Die Analyse des Status quo ist nur insofern nötig, als Problemquellen aufgespürt werden müssen. Unternehmen sollten sich deshalb darauf beschränken, die Differenzen zwischen dem Status quo und der gewünschten IT-Landschaft herauszuarbeiten.

"Modellitis" - nein danke!

Unerfahrene EA-Teams tendieren dazu, gleich als erstes Ziel ihrer Tätigkeit eine umfassende Architektur zu definieren. Sie versuchen, das gesamte Unternehmen zu modellieren, und produzieren am Ende wenig oder gar nichts von Wert. Oft verlieren die Unternehmen dann ihr Interesse an EA und geben auf. Solche mit "Modellitis" infizierten EA-Teams machen das Modellieren zum Selbstzweck und vergessen, worauf es für ihr Unternehmen ankommt, nämlich so schnell wie möglich Informationen für die bessere Entscheidungsfindung beibringen zu können.

Besser ist es, sich auf pragmatische Ziele zu konzentrieren, die von den strategischen Notwendigkeiten für das Unternehmen herzuleiten sind. EA-Teams sollten sich um die wirklich wichtigen Dinge kümmern und möglichst früh einen konkreten Nutzen für das Unternehmen herbeiführen - bevor dieses sein Interesse verliert und der nächsten "großen Idee" hinterherjagt. EA ist ein niemals endendes Programm, das Ergebnisse in Iterationsschritten liefert. Was im ersten Schritt nicht modelliert wird, ist eben im zweiten oder dritten dran.

Zwei Augen auf die Governance

Im Zusammenhang mit EA geht es beim Thema Governance um Entscheidungen zur Architektur und zur Compliance, womit die Absicherung der Architektur im Sinne von Sicherheit und gesetzlichen Vorgaben gemeint ist. Beide Steuerungstypen erfüllen verschiedene Zwecke und erfordern differierende Organisationsstrukturen und -formate. Die effektivsten Architekturprogramme sind laut Gartner diejenigen, die eine breite Palette von Teilnehmern in beiden Governance-Typen vorsehen. Beispielsweise registrieren EA-Teams, die Implementierungsexperten für detaillierte Architekturentscheidungen auf der unteren Ebene an Bord haben, weniger Widerstand unter den Implementierern, wenn sie ihre Architekturstandards schützen wollen.

Wenn Designer und Implementierer an Architekturentscheidungen teilhaben, sind sie für diese mitverantwortlich und werden weniger Widerstand leisten. Am Prozess der Architekturabsicherung sollten Fachabteilungen mitwirken, da dann die Chancen steigen, Entscheidungen gegenüber der höchsten Ebene durchzusetzen. Außerdem bekommt das Business einen Sinn für die Architektur und wird vorsichtiger mit der Forderung nach Ausnahmeregelungen sein.

Messen, messen, messen

Es gibt keine Standards, nach denen sich der Wert einer EA messen lässt. Um ihn dennoch zu demonstrieren, sollten die potenziellen Einwände der verschiedenen Stakeholder bekannt sein. Messungen sollten hier ansetzen, um Fortschritte nachweisen beziehungsweise Kritiker verstummen lassen zu können. Die entscheidenden Fragen lauten also: Wer sind die Stakeholder? Welche Fragen werden sie stellen, um zu sehen, ob die Ziele erreicht wurden? Was muss gemessen werden, um diese Fragen beantworten zu können?

Je nach Geschäftsstrategie, Branche, Kultur und Reifegrad wird der Wertbeitrag von EA-Programmen unterschiedlich ausfallen - ein Grund dafür, dass es keine standardisierten Messverfahren gibt. Für die verantwortlichen Teams ist das eine schwierige Situation: Sind sie nicht überzeugend, wird ihnen nach einer Kulanzzeit häufig das Budget gekürzt, Ressourcen werden für andere Aufgaben mit nachweisbarem Wert abgezogen.

Die guten EA-Teams definieren deshalb den Wertbeitrag der EA und identifizieren Messgrößen, um ihn im Rahmen der einzelnen Iterationen zu demonstrieren. Sie berichten und messen regelmäßig im Rahmen des zuvor festgeschriebenen Kommunikationsprozesses.

Kontinuierlich besser werden

Oft verlieren Architekturprogramme nach starkem Beginn im Laufe der Zeit an Effektivität. Mit EA kommt eine strategische Disziplin ins Unternehmen, die irgendwann vorhanden und ausgereizt ist. Wähnt sich die EA am Ziel und entwickelt sich nicht weiter, wird sie zunächst belanglos und dann hinderlich für die Entwicklung der Company. Deshalb müssen EA-Programme als Prozesse behandelt werden, die dem Ziel der kontinuierlichen Verbesserung folgen. Der Reifegrad ist regelmäßig (jährlich) zu bewerten, die Ziele für den nächsten Bewertungszyklus sollten realistisch gesetzt und die kritischen Barrieren, die für den Effektivitätsverlust verantwortlich sind, analysiert und beseitigt werden.

Enterprise Architects brauchen besondere Skills

Das Kern-Architekturteam benötigt Eigenschaften, die von typischen IT-Skills abweichen. Beispielsweise müssen die Architekten EA-Dokumente erstellen, die EA-Prozesse managen und die Governance definieren können. Gartner nennt folgende Talente, die das Profil eines Enterprise Architect ausmachen:

• Konzeptionelle Fähigkeiten, um die erforderlichen Lösungen, Prozesse und Infrastrukturen zu visualisieren;

• Innovationskraft, um Chancen zu erkennen, wie sich der Wert für das Business steigern oder die Kosten senken lassen;

• Unternehmensperspektive, um die strategischen Implikationen über alle Business-Bereiche hinweg zu erkennen;

• Weitsicht, um kurz-, mittel- und langfristige Planungshorizonte im Blick zu behalten;

• Konsensfähigkeit, da sich eine Gruppe von Leuten mit unterschiedlichem Hintergrund und Erfahrungsschatz zu Beschlüssen durchringen muss;

• Führungseigenschaften, da Überzeugungskraft wichtig sein kann, andererseits aber auch Diskussionen geleitet werden müssen, ohne das Ergebnis vorwegzunehmen oder zu beeinflussen;

• logische Fähigkeiten, um die beste aller Optionen auszuwählen und

• Kommunikationsbereitschaft, da die Ergebnisse des Architekturprozesses und der daraus resultierende Wert ständig dargelegt werden müssen. (hv)