fachartikel der autor

Holger Wolff
(E-Mail: holger.wolff@mwea.de)
ist Mitgründer der beck et al. Gruppe und verantwortet als Geschäftsführer bei MaibornWolff et al das
Segment IT-Consulting innerhalb der Gruppe. Er hat unter anderem als Interimsmanager das EAM der
Schweizerischen Bundesbahnen (SBB) konzipiert und aufgebaut.

Das Management komplexer

Unternehmensarchitekturen:
Lösungsorientierung und Werte als
zentrale Erfolgsfaktoren
„Enterprise Architecture Management” (EAM) bringt Strategie und Informationstechnologie zusammen. Durch professionelles
Architekturmanagement kann die Informationstechnologie eines Unternehmens alle wichtigen Geschäftsprozesse effizient unter-
stützen – soweit die Theorie. In der Praxis bleiben viele EAM-Implementierungen weit hinter den hoch gesteckten Erwartungen
zurück – der Begriff der „EA Crisis” macht die Runde. Die realen Ursachen für die Probleme im EAM liegen häufig jenseits gängi-
ger Patentrezepte. Dieser Beitrag liefert einen praxiserprobten Bezugsrahmen und zeigt, wie sich mit einem stabilen
Wertefundament für die Mitarbeiter in Architektur- und Planungsabteilungen und einem konsequent lösungsorientierten
Vorgehen überraschende Erfolge erzielen lassen.

EAM: wichtiger denn je
Wie kaum ein anderer Begriff prägt
„Agilität” seit Jahren die Diskussion zu
Enterprice Architecture Management
(EAM), Service Oriented Architecture (SOA)
und Business Process Management (BPM).
Der Terminus wird zum Mantra all jener, die
versuchen, mehr Dynamik in das bisweilen
so träge Verändern von Geschäftsabläufen zu
bringen. Die Überlebensfähigkeit von Unter-
nehmen wird mehr denn je durch die
Anpassungsfähigkeit an sich ändernde
Marktbedingungen bestimmt und viele
Firmen unternehmen große Anstrengungen,
ihre noch immer monolithisch geprägten
Anwendungslandschaften zu flexibilisieren.
Mit BPM rollt aktuell die nächste
Innovationswelle auf die Unternehmen zu.
Auch hier zählt Agilität zu den Hauptzielen
und -treibern. In diesem Zusammenhang
werden massive strukturelle Eingriffe in
bestehende IT-Landschaften nötig, um die
gewünschten Ergebnisse zu erzielen. Das
Management komplexer Unternehmens-
architekturen wird so zum zentralen
Erfolgsfaktor im strategischen IT-Manage-
ment. Hieraus erwächst auch die Haupt-
aufgabe für das Enterprise Architecture
Management (EAM) – die nahtlose
Verknüpfung sämtlicher Architekturen eines
Unternehmens, um die Komplexität be-
herrschbar zu machen (siehe Abb. 2).
Versetzen wir uns für ein kurzes
Gedankenexperiment in die Finanz-
abteilung eines internationalen Konzerns.
Der Finanzvorstand muss eine Gewinn-
prognose für den Vorstand erarbeiten. Der
Vorstand möchte die strategische Planung
des Konzerns mit der Finanzplanung syn-
chronisieren und für verschiedene Zu-
kunftsszenarien geeignete Finanzierungs-
konzepte erarbeiten lassen. Mit diesem
Auftrag versehen, machen sich 200
Mitarbeiter aus der Buchhaltung auf den
Weg. Jeder von ihnen kennt einige wenige
der mehreren tausend Konten des
Konzerns, diese aber dafür sehr detailliert.
Es gibt allerdings niemanden in der
Finanzabteilung, der einen aggregierten
und umfassenden „High-Level-Blick” über
die gesamten Finanzströme des Konzerns
besitzt. Der Finanzvorstand hat sich auf die
Verhandlungen mit den Banken speziali-
siert und die Mitarbeiter in seinem Bereich
sind in ihre jeweiligen Konten vertieft. In
unzähligen Meetings und in wochenlanger
Arbeit synchronisieren sich die Mitarbeiter
der Buchhaltung schließlich und führen
ihre einzelnen Konten zu einem stimmigen
Gesamtbild zusammen. Das erlaubt eine
Darstellung, aus der sich eine Ergebnis-
prognose ableiten lässt und in der die
Finanzströme sichtbar werden. Der
Finanzvorstand befürchtet mittlerweile,
dass der Konzern hier nicht gut aufgestellt
ist. Aber leider interessieren sich seine
Mitarbeiter mehr für Details der Konten als
für die Steuerung der Finanzströme.
Erscheint Ihnen das absurd? Zu Recht!
Niemand kann sich ernsthaft eine solche
Situation für die Finanzabteilung vorstel-
len – außer vielleicht in einer Parodie der
Schwachstellen für das Businesstheater auf
der Weihnachtsfeier. In der IT aber hat man
sich vielfach mit solchen Zuständen abge-
funden. Häufig werden immer noch
Zustände akzeptiert, die in jedem anderen
Unternehmensbereich seit Jahren bzw.

1 www.objektspektrum.de
Online-Themenspecial EAM 2010 fachartikel

Abb. 1: Enterprise Architecture Management – Einordnung und Abgrenzung.

Jahrzehnten professionalisiert sind. Das Abteilungen, in denen niemand einen mationsflüsse. Vor allem aber wissen wir
Management komplexer Unternehmens- Gesamtüberblick über die Anwendungs- nicht, wie sich diese Informationsflüsse im
architekturen wird in der Praxis mehr und landschaft besitzt. Wir treffen in unserer Unternehmen verändern müssen, um einen
mehr zum zentralen Erfolgsfaktor im stra- Beratungstätigkeit immer noch auf große in der Strategie definierten Sollzustand
tegischen IT-Management, ohne dass die und sehr große Unternehmen, die ihre abzubilden. Partiell wissen wir das natür-
meisten EAM-Teams diesen hohen Anwendungslandschaft gar nicht kennen lich immer für bestimmte Anwendungen,
Anspruch wirklich umsetzen können. und die nicht wissen, welche Anwendungen Produkte oder Komponenten. Aber wir
Viele Unternehmen haben in den vergan- sie konkret betreiben und wie die verfügen in immer noch viel zu vielen
genen Jahren Teams oder Abteilungen für Abhängigkeiten zwischen diesen Anwen- Unternehmen über kein schlüssiges
EAM ins Leben gerufen und dort die dungen aussehen. Gesamtbild. Dieser Zustand wird seit
Verantwortung für das Management der In den meisten Unternehmen haben wir Längerem diskutiert: Gartner spricht in
Unternehmensarchitektur angesiedelt. noch immer nicht genügend aggregierte diesem Zusammenhang von der „EA
EAM stellt im Idealfall einen Prozess bereit, Informationen über die zentralen Infor- Crisis” und prominente Vertreter der EA-
der die Geschäftsstrategie eines Unterneh-
mens in eine Soll-IT-Architektur übersetzt
und damit die informationstechnischen
Grundlagen zur Umsetzung dieser Strategie
schafft. EAM ermittelt aus den Schlüssel-
anforderungen und den künftig benötigten
Geschäftsfähigkeiten zur Umsetzung der
geplanten Strategie die bestehenden
Abweichungen, die das Delta zwischen der
heute vorhandenen und der zu implemen-
tierenden Soll-Anwendungslandschaft dar-
stellen. In der Folge profitiert nicht nur die
IT selbst von erfolgreich betriebenem
EAM, sondern vor allem auch das Business
in seiner Gesamtheit (siehe Abb. 3).
In vielen Fällen bleibt jedoch die
Wirksamkeit der EAM-Teams hinter den
Erwartungen zurück. In den meisten
Unternehmen gibt es eine Menge begabter
Architekten und Analysten, die sich in eini-
gen wenigen Anwendungen hervorragend Abb. 2: Enterprise Architecture Management – die Verzahnung aller Architekturen
auskennen. Noch immer gibt es IT- eines Unternehmens.

Online-Themenspecial EAM 2010 2

 fachartikel

verlangsamen oder erschweren die

Projektdurchführung erheblich. Die
Projektverantwortlichen suchen sich
Schleichwege in der Organisation. Eine
aufkeimende Schatten-IT konterkariert
das ordnende Element einer EA-
Strategie. Häufig geht eine anfänglich
erreichte Transparenz über die Gesamt-
landschaft wieder verloren, weil die
Nachführ-Prozesse unterlaufen werden
und sich das EA-Repository nicht auf
dem aktuellen Stand befindet.

Die Summe aller Probleme in gewachsenen

Landschaften tendiert ab einer gewissen
Unternehmensgröße gegen unendlich. EA-
Teams laufen Gefahr, dieses Problemfeld zu
analysieren, zu kommentieren und letztlich
zu verwalten. Nicht selten verbrauchen sie
Abb. 3: Ein ganzheitliches EAM stiftet Mehrwert für das gesamte Business und nicht
dabei so viele Ressourcen, dass für die
nur für die IT.
eigentliche Problemlösung wenig Raum
bleibt. Wenn nicht mit einer kulturell tief
Szene (Enterprise Architecture), wie John Implementierungsvorhaben ergebende verankerten Kultur der Lösungsorien-
Wu, von der „EA Identity Crisis”. Wie Gesamtlandschaft wieder ungeordnet tierung konsequent gegengesteuert wird,
manifestiert sich jedoch diese EA-Krise? In und ungerichtet aus den Partikular- droht deshalb eine „Analysis Paralysis”.
der Praxis beobachten wir drei immer wie- Interessen der einzelnen Projekte ent- Trotz großer Anstrengungen bleiben also
der auftretende Zustände: wickelt. die sichtbaren Resultate der Enterprise-
■ Die Bürokratisierungs-, Perfektions- Architekten in vielen Fällen weit hinter den
■ Das „Big Picture” fehlt: EAM bleibt und Governance-Falle droht: Die hoch gesteckten Erwartungen zurück. Die
weit hinter den ursprünglich hoch Enterprise-Architekten sehen ihre wich- bisher angebotenen Lösungen für die skiz-
gesteckten Erwartungen zurück. Statt tigste Aufgabe in der Implementierung zierten Problemfelder zielen häufig auf
EAM im Wortsinn zu betreiben, wer- einer möglichst präzisen EA-Gover- Strategien und Prozesse, auf Templates und
den einzelne Systeme entwickelt, oder, nance, die kontinuierlich weiterentwi- Werkzeuge. Sie artikulieren Forderungen
wie John Wu es ausdrückt: „The value ckelt und ausgebaut wird. Damit bele- an die Architekten mit appellativem
of Enterprise Architects is to identify gen sie die Projekte nach und nach mit Charakter. Gartner etwa fordert: „Stop
the big picture of the enterprise and to immer höheren Zusatzaufwänden und doing technical architecture!” Die Gründe
provide the enterprise definition for the
subject area expert, so they can design
the IT architecture from the aspect of
enterprise consideration. Stove-pipe-
systems are created due to lack of the
big picture. The enterprise is large and
everyone only touches a part of the
enterprise” (vgl. [Wu06]).
■ Die Umsetzung der vereinbarten Soll-
Architektur scheitert: EAM liefert zwar
eine konsistente Soll-Architektur, schei-
tert aber in der Überführung der Ist-
Architektur in diese Soll-Architektur
(siehe Abb. 4). Das passiert insbeson-
dere dann, wenn die Akzeptanz der
Enterprise-Architekten im Unterneh-
men zu gering ist, als dass eine wirksa-
me Steuerung der vielen einzelnen
Architekturentscheidungen in den IT-
Projekten durchsetzbar wäre. Die Soll-
Architektur ist dann zwar als Ziel defi-
niert, sie wird aber letztlich nie wirklich
erreicht, weil sich die aus den einzelnen Abb. 4: EAM und PPM.

3 www.objektspektrum.de
Online-Themenspecial EAM 2010
für das Scheitern sind aber jenseits der gän-
gigen und oft zitierten Ursachen zu finden,
sie liegen im Verhalten der handelnden
Personen begründet. Eine Verhaltensän-
derung der in EA-Prozessen agierenden
Menschen erreichen wir aber nicht, indem
wir Forderungen aufstellen, sondern indem
wir ihnen ganz konkret den Weg zur einer
erfolgreichen Verhaltensänderung aufzei-
gen und sie bei den dabei nötigen Schritten
begleitend unterstützen. Das Konzept der
lösungsorientierten Beratung bietet genau
das: ein einfaches und dennoch sehr wirk-
sames Instrument, mit dem mittels kleiner
Verhaltensänderungen schnell und effektiv
große Veränderungen in der Performance
von EA-Teams erreicht werden können.
Lösungsorientierung
Das Konzept der lösungsfokussierten Inter-
vention (Solution Focussed Brief Therapy,
vgl. [DSh90]) wurde in den 80er Jahren
von Steve de Shazer und Insoo Kim Berg an
der University of Milwaukee entwickelt.
Ursprünglich für die Familientherapie ent-
worfen, kombiniert es viele Einflüsse aus
dem radikalen Konstruktivismus mit der
Kommunikationstheorie von Watzlawick
und Arbeiten von Wittgenstein (vgl.
[Pit67]). Durch ein weltweit stark gewach-
senes Interesse an lösungsorientierter
Praxis in den 80er und 90er Jahren erfolg-
te die Übertragung aus dem Therapie-
bereich in die Management- und Organisa-
tionsberatung, in die Supervision und in
das Coaching. In Deutschland haben insbe-
sondere Insa Sparrer und Prof. Matthias
Varga von Kibéd lösungsorientierte Kon-
zepte für die Organisations- und Manage-
mentberatung entwickelt. In der Orga-
nisationsforschung hat sich insbesondere
Stobbe (vgl. [Sto08]) intensiv mit den
Konzepten von Steve de Shazer befasst und
diese in die Führungslehre von Malik inte-
griert.
Stark vereinfacht zusammengefasst, liegt
der Schwerpunkt der lösungsfokussierten
Arbeit in den vorhandenen oder zu finden-
den Ressourcen und Fähigkeiten der Klien-
ten (Organisationen wie Personen) und
nicht auf ihren Problemen und Defiziten
(Lösungs- statt Problemfokus). Der lö-
sungsorientierte Ansatz nach De Shazer
(vgl. [DSh02]) fokussiert also nicht, was
Probleme verursacht, sondern wie
Lösungen konstruiert werden.
Ein lösungsorientiertes Management
beschreibt eine Vorgehensweise, die
Online-Themenspecial EAM 2010
■ basierend auf den Bildern einer erfolg-
reichen Zukunft,
■ Ziele mit dem Arbeitsumfeld abgleicht,
■ sich permanent mit kleinen Fort-
schritten den Zielen annähert, die klei-
nen Erfolge kontinuierlich überprüft
■ und dabei stets die Erfolgserlebnisse
analysiert, um die dahinter stehenden
Erfolgsstrategien und Kompetenzen auf
die nächsten Schritte zu übertragen.
Um in komplexen Situationen und Syste-
men erfolgreich zu sein, ist es nicht immer
hilfreich, sie modellieren und verstehen zu
wollen. Häufig ist es hilfreicher, unvorein-
genommen zu beobachten, was alles wie
gewünscht funktioniert, um in kleinen
Schritten mehr davon zu tun (vgl. [Kib09]).
Lösungsorientierung geht davon aus, dass
■ positive Veränderungen in komplexen
Situationen auf Basis kleiner Schritte
geschehen,
■ für diese Schritte nur wenige Infor-
mationen über das, was bisher schon
etwas besser funktionierte, genügen,
■ bei Analysen nicht die Frage „wie ist es
bzw. wie kam es dazu?”, sondern die
Frage „was macht den Unterschied zwi-
schen besser/schlechter aus?” ins
Zentrum rückt,
■ anstelle des „theoretisch umfassend
Verstehen Wollens” das konkrete Han-
deln in kleinen Schritten tritt.
Die Regeln des lösungsorientierten Ansat-
zes sind (vgl. [Spa07]):
■ Repariere nicht, was nicht kaputt ist!
■ Finde heraus, was gut funktioniert und
passt -- und mache mehr davon!
■ Fokussiere Lösungen und nicht Prob-
leme! Vertiefe nicht das Problem-
verständnis, sondern erkunde, wie es
ist, wenn es besser ist!
■ Setze auf Interaktion statt auf isolierte
Individualität! Unser Verhalten entwi-
ckelt sich in der Interaktion mit ande-
ren.
■ Beachte und nutze das, was da ist –
nicht das Fehlende: Nicht die Lücke
zwischen „Ist” und „Soll” ermitteln
sondern das, was – wenn auch nur sel-
ten – heute bereits etwas besser ist.
■ Sieh die Chancen im Gestern, Heute
und Morgen! Chancen in der Zukunft
und im Heute zu überlegen, ist ein ver-
trauter Gedanke. Eher unüblich ist es,
auch im „Gestern” bewusst das zu
fachartikel
erkunden, was sich früher bereits als
Chance zeigte – um auch das zu nutzen.
Ein Beispiel aus der Praxis
Ein konkretes Beispiel aus der Praxis illu-
striert die lösungsorientierte Herangehens-
weise an Aufgabenstellungen im EAM.
Ein Team aus Enterprise-Architekten
eines internationalen Logistikunterneh-
mens hat den Auftrag, für eine bestimmte
fachliche Domäne im Unternehmen ein
Zielbild, also einen zukünftigen Bebau-
ungsplan der Anwendungslandschaft zu
entwickeln. Gemäß der mit den Fach-
bereichen abgestimmten Vorgehensweise
sollen dafür aus der Business-Strategie die
strategischen Handlungsfelder und die
erfolgsrelevanten Geschäftsfähigkeiten
abgeleitet werden. In einer Gap-Analyse
werden die strategischen Handlungsfelder
und die relevanten Geschäftstätigkeiten mit
den Fähigkeiten der Systeme der heutigen
Anwendungslandschaft verglichen. Aus
dem Ergebnis werden dann die ersten
Schlüsse auf die künftige Soll-Bebauung
gezogen. In einem Kick-Off-Meeting mit
dem Fachbereich sichten die Architekten
die vorhandenen Unterlagen. Dabei bemer-
ken, sie, dass die Business-Strategie nur aus
einigen unzusammenhängenden Folien
besteht und keine wirklich verwertbaren
Dokumente existieren. Zu allem Überfluss
sind auch die Kerngeschäftsprozesse des
Bereichs nicht dokumentiert und nicht in
ARIS hinterlegt, obwohl hier eigentlich alle
Prozesse erfasst sein müssten – von einer
Abbildung der Kernprozesse auf die
Module der Kernanwendungen ganz zu
schweigen.
Die Architekten notieren akribisch alle
Defizite und fordern beim Leiter dieser
Sparte eine konkret ausformulierte Busi-
ness-Strategie und eine Dokumentation der
Kerngeschäftsprozesse an, wie es im
Strategieentwicklungsprozess vorgeschrie-
ben ist. Die Verantwortlichen im Business
fühlen sich bevormundet, empfinden die
etwas forsch vorgetragenen Anliegen als
wenig hilfreich und finden, die IT über-
schreite mit diesen Forderungen ihre
Befugnisse als Dienstleister. Die Reaktion
fällt entsprechend gereizt aus. Nach dem
Austausch einiger langsam eskalierender
E-Mails landet die Angelegenheit schließ-
lich beim Gesamtvorstand, der sich schnell
auf die Seite des Bereichsvorstands schlägt
und der Bewältigung der aktuellen Nach-
frageschwäche in Zeiten der Wirtschafts-
krise absoluten Vorrang einräumt – vor der
4
 fachartikel
Dokumentation von Prozessen und
Strategien. Die Architekten reagieren ent-
täuscht und beleidigt – mit fehlendem
Management-Support und so eklatant ver-
weigerter Unterstützung im Business sei
EAM in diesem Konzern ein aussichtsloses
Unterfangen und werde nie die gewünsch-
ten Ergebnisse liefern.
Nach einem intensiven lösungsorientier-
ten Coaching des gesamten Teams erfolgt
ein Neuanfang. Die Architekten durchfors-
ten dabei zunächst auf eigene Faust das
Intranet des Unternehmens sowie alle
öffentlich verfügbaren Dokumente des
fraglichen Bereichs und formulieren daraus
ein Thesenpapier mit einer Handvoll Kern-
thesen zur Strategie des Bereichs. Mit die-
sen Thesen ausgerüstet, werden „auf dem
kleinen Dienstweg” operative Mitarbeiter
des Geschäftsbereichs befragt und um eine
Verifikation oder Falsifikation der Thesen
gebeten. Nach einigen unaufwändigen und
schnell vereinbarten Gesprächen ergibt sich
schon ein deutlich konkreteres Bild der
Strategie. Mit einer etwa fünfseitigen Prä-
sentation über die „Thesen zur Bereichs-
strategie” wird die Leitung der Business-
Einheit um einen erneuten Termin gebeten.
Beeindruckt von der Vorarbeit der IT, wird
die Stimmung schnell konstruktiver, der
Bereichsvorstand kommentiert ausgiebig die
Thesen zur Bereichsstrategie und ergänzt die
noch fehlenden oder falsch verstandenen
Aussagen. Aus einem auf 1,5 Stunden anbe-
raumten Termin werden fast 4 Stunden –
und nach einer intensiven Nacharbeit ver-
fügt die IT schließlich über ein knapp 20-
seitiges Positionspapier zur Bereichs-
strategie. Mit diesem Papier gelingt eine
Ableitung der erfolgsrelevanten Geschäfts-
fähigkeiten in der Zukunft und eine erste
Aussage, inwieweit die Anwendungs-
landschaft heute bereits in der Lage ist,
Teile davon zu leisten. Getreu dem Motto
der Lösungsorientierung, „Wenn etwas
funktioniert, tue mehr davon”, wird dieser
pragmatische Entwurf auch auf die
Geschäftsprozesse angewandt. Die Archi-
tekten interviewen zunächst alle Anwen-
dungsentwickler aus der IT, die mit
Wartung und Betrieb der Anwendungen
des Geschäftsbereiches befasst sind. Aus
den Gesprächen entsteht ein erster Entwurf
einer Prozesslandkarte, die lange noch
nicht perfekt ist, aber immerhin einen
guten ersten Überblick verschafft.
Mit diesen beiden Artefakten gelingt es
der IT einen ersten Vorschlag zur Soll-
Bebauung und eine daraus abgeleitete
5 www.objektspektrum.de
Projektliste zu erstellen. Der Bereichsvor-
stand zeigt sich beeindruckt und verpflich-
tet sich dazu, für eine weitere und präzisere
Iteration des Bebauungsplans nun doch
einen Mitarbeiter abzustellen, der das
EAM-Team künftig unterstützen wird.
Inspiriert vom Erfolg dieser ersten
Maßnahmen beschließen die Architekten,
diesen Weg auch auf die anderen fachlichen
Domänen anzuwenden. Die Strategie wird
zunächst aus den wenigen vorhandenen
Quellen und einigen Interviews mit
Schlüsselpersonen in Thesenform formu-
liert und dann in mehreren Iterationen
immer weiter präzisiert und verfeinert.
Nach wenigen Monaten hat die IT eine
Version 0.8 einer Enterprise-Roadmap fer-
tiggestellt und sich nebenbei noch viel
Respekt und Vertrauen in den Fachbe-
reichen zurückerobert.
Die Lösungsorientierung stellt also einen
wichtigen Bezugsrahmen für eine wirksame
Verhaltensintervention bei Enterprise-
Architekten zur Verfügung. Idealerweise
wird sie flankiert durch ein stabiles
Wertefundament.
Mechanistisches Prozess -
verständnis statt Interaktion
EA-Teams tendieren dazu, im EA-Prozess,
in den Standards und in den Richtlinien die
alleinige Lösung des Problems zu suchen.
Lösungen für die Unternehmensarchitektur
von morgen entstehen aber nicht (nur)
durch die Einführung von TOGAF-inspi-
rierten (The Open Group Architecture
Framework) EA-Prozessen. Lösungen ent-
stehen als Ergebnis vieler erfolgreicher
kommunikativer, sozialer Interaktionen
zwischen den EA-Teams und den Projekt-
teams in der IT, mit der Anwendungs-
entwicklung, mit externen Partnern sowie
mit den Fachbereichen oder, wie John Wu
es ausdrückt: „The enterprise architect
facilitates the collaboration. It is easy to
understand the concept of collaboration,
but it is very difficult to do. The secret is
that the architect must know how to intri-
gue the stakeholders to raise their curiosity
and interest similar to the magic stones in
the story of Stone Soup” (vgl. [Wu06]). Auf
die Gestaltung dieser Interaktionen müssen
wir vermehrt achten – in ihrer Effektivität
liegt der Schlüssel für ein erfolgreiches
EAM.
Kultur und Werte
Gutes EAM entsteht nur im permanenten
Wechselspiel aus operativem Architektur-
management (in Projekten) und EAM (auf
Domänen- oder Unternehmensebene).
Enterprise-Architekten ziehen ihre Repu-
tation, ihre Designkompetenz und ihre
Autorität gegenüber den Projekten nur aus
regelmäßigen Einsätzen in relevanten
Businessprojekten. Unterbleibt dieses
Wechselspiel, d. h. dieser Dialog mit den
Projekten, verkommt das Architektur-
management zu einer klassischen „Elfen-
beinturm-Stabsabteilung”, die über wenig
Ansehen gegenüber den anderen Abtei-
lungen verfügt und keinen relevanten
Einfluss auf das reale Architekturgeschehen
in den Projekten und im Unternehmen
besitzt. Ineffektive Architekturstäbe dieser
Art lassen sich leider in vielen
Unternehmen beobachten. Wie lässt sich
das ändern? Durch einen permanenten
Projekteinsatz der Enterprise-Architekten
und durch ein mit allen Mitarbeitern zu
erarbeitendendes Selbstverständnis: Eine
gut funktionierende Architekturgruppe:
■ ist nicht überheblich, obwohl sie weiß,
dass sie durch ihre umfassende Kennt-
nis von übergreifenden Geschäfts-
prozessen eine erhebliche Macht-
stellung hat,
■ drängt sich nicht nach jeder Aufgabe
und versucht nicht, ein Monopol auf
das Erbringen von IT-Leistungen zu
errichten,
■ setzt dennoch konsequent Rahmenbe-
dingungen unter dem Gesichtspunkt
von Gesamtarchitektur, Betriebs-
sicherheit, Dokumentationsgrad und
Schnittstellenkonformität,
■ behält die Zügel in der Hand, indem sie
die Freiheitsgrade an die nachgewiesene
Professionalität der unterschiedlichen
Projektteams anpasst,
■ hilft den Projekten beim Aufbau kom-
petenter Teams mit informatischem
Wissen und unterhält zu diesen eine
partnerschaftliche, kollegiale Bezieh-
ung.
Um ein professionelles EAM zu betreiben
und somit die Unternehmensstrategie und
IT in Einklang zu bringen, müssen sich
Unternehmen deshalb verstärkt auf ein
lösungsorientiertes Vorgehen unter Berück-
sichtigung eines stabilen Werterahmens
konzentrieren. Erst dann kann EAM einen
wichtigen Beitrag dazu leisten, um die vor-
gegebene Geschäftsstrategie zu unterstüt-
zen und umzusetzen. Eine professionelle
EA ist dabei nicht als Selbstläufer, sondern
Online-Themenspecial EAM 2010
vielmehr als ein andauernder Prozess zu ver-
stehen. Sie entsteht nur aus dem permanen-
ten Wechselspiel von operativem
Architekturmanagement in Projekten und
EAM auf Domänen- oder Unternehmens-
ebene. Der wichtigste Treiber für den Erfolg
lässt sich letztlich in dem Ratschlag manife-
stieren, dass sich Unternehmen nicht auf die
Ursachen der Probleme konzentrieren soll-
ten, sondern auf die Frage, wie angemessene
Lösungen geschaffen werden können.
Literatur & Links
[DSh02] S. De Shazer, Der Dreh: überra-
schende Wendungen und Lösungen in der
Kurzzeittherapie (7. korrigierte Auflage),
Carl-Auer-Systeme-Verlag, 2009
Online-Themenspecial EAM 2010
[DSh90] S. De Shazer, Wege der erfolgrei-
chen Kurztherapie. 2. Aufl. Stuttgart: Klett-
Cotta, 1990
[Göt03] A. Götz, J. Liddle, „Process Driven
Architecture” und „Business Process
Management”, in: OBJEKTspektrum 6/2003
[Kib09] M. Varga von Kibéd, Ganz im
Gegenteil (6. überarbeitete Auflage), Carl
Auer Verlag, 2009
[Moo08] L. Mooney, Aligning Strategy
with Business Processes , Ebiz – The
Insider's Guide to Business and IT Agility,
2008, siehe: www.ebizq.net/topics/human_
centric_bpm/features/ 10378.html
[Ora09] A. Oram, J. Viega, Beautiful
Security, O'Reilly, 2009
[Öst96] H. Österle, Business Engineering:
Prozeß und Systementwicklung, Band 1,
Springer Verlag, 1996
fachartikel
[Pit67] G. Pitcher, Die Philosophie
Wittgensteins. Eine kritische Einführung in
den Tractatus und die Spätschriften, Alber,
1967
[Sha09] A. Sharma, P. Loh, Emerging
trends in sourcing of business services, in:
Business Process Management Journal
2/2009
[Spa07] I. Sparrer, Einführung in Lösungs-
fokussierung und Systemische Strukturauf-
stellungen, Carl Auer Verlag, 2007
[Sto08] M. Stobbe, Lösungsorientiertes
Management: Malik trifft de Shazer, Books
on Demand, 2008
[Wu06] J. Wu, Light Enterprise
Architecture (LEA), siehe: http://it .tool-
box.com/blogs/lea-blog/ the-ea-identity-crisis-
8590
6