Das Management komplexerUnternehmensarchitekturen:Lösungsorientierung und Werte alszentrale Erfolgsfaktoren„Enterprise Architecture Management” (EAM) bringt Strategie und Informationstechnologie zusammen. Durch professionellesArchitekturmanagement 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 Erwartungenzurü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 stabilenWertefundament für die Mitarbeiter in Architektur- und Planungsabteilungen und einem konsequent lösungsorientiertenVorgehen überraschende Erfolge erzielen lassen.

Verhandlungen mit den Banken speziali-siert und die Mitarbeiter in seinem Bereichsind in ihre jeweiligen Kon ten vertieft. Inunzähligen Meetings und in wochenlangerArbeit synchronisieren sich die Mitar beiterder Buchhal tung schließlich und führenihre einzelnen Konten zu einem stimmigenGesamt bild zusammen. Das erlaubt eineDar stellung, aus der sich eine Ergebnis -prognose ableiten lässt und in der dieFinanzströme sichtbar werden. DerFinanzvorstand befürchtet mittlerweile,dass der Konzern hier nicht gut aufgestelltist. Aber leider interessieren sich seineMitarbeiter mehr für Details der Konten alsfür die Steuerung der Finanzströme.

Erscheint Ihnen das absurd? Zu Recht!Niemand kann sich ernsthaft eine solcheSituation für die Finanzabteilung vorstel-len – außer vielleicht in einer Parodie derSchwachstellen für das Businesstheater aufder Weihnachtsfeier. In der IT aber hat mansich vielfach mit solchen Zuständen abge-funden. Häufig werden immer nochZustände akzeptiert, die in jedem anderenUnternehmensbereich seit Jahren bzw.

ment. Hieraus erwächst auch die Haupt -aufgabe für das Enterprise ArchitectureManagement (EAM) – die nahtloseVerknüpfung sämtlicher Architekturen einesUnternehmens, um die Komplexität be -herrschbar zu machen (siehe Abb. 2).

Versetzen wir uns für ein kurzesGedankenexperiment in die Finanz -abteilung eines internationalen Konzerns.Der Finanzvorstand muss eine Gewinn -prognose für den Vorstand erarbeiten. DerVorstand möchte die strategische Planungdes Konzerns mit der Finanzplanung syn-chronisieren und für verschiedene Zu -kunfts szenarien geeignete Finanzierungs -konzepte erarbeiten lassen. Mit diesemAuftrag versehen, machen sich 200Mitarbeiter aus der Buchhaltung auf denWeg. Jeder von ihnen kennt einige wenigeder mehreren tausend Konten desKonzerns, diese aber dafür sehr detailliert.Es gibt allerdings niemanden in derFinanzabteilung, der einen aggregiertenund umfassenden „High-Level-Blick” überdie gesamten Finanzströme des Konzernsbesitzt. Der Finanz vorstand hat sich auf die

EAM: wichtiger denn jeWie kaum ein anderer Begriff prägt„Agilität” seit Jahren die Diskussion zuEnterprice Architecture Management(EAM), Service Oriented Architecture (SOA)und Business Process Management (BPM).Der Terminus wird zum Mantra all jener, dieversuchen, mehr Dynamik in das bisweilenso träge Verändern von Geschäftsabläufen zubringen. Die Überlebensfähigkeit von Un ter -nehmen wird mehr denn je durch dieAnpassungs fähig keit an sich änderndeMarkt bedingungen be stimmt und vieleFirmen unternehmen große Anstrengungen,ihre noch immer monolithisch geprägtenAnwen dungs land schaften zu flexibilisieren.Mit BPM rollt aktuell die nächsteInnovationswelle auf die Unternehmen zu.Auch hier zählt Agilität zu den Haupt zielenund -treibern. In diesem Zusam men hangwerden massive strukturelle Eingriffe inbestehende IT-Landschaften nötig, um diegewünschten Ergebnisse zu erzielen. DasManagement komplexer Unternehmens -archi tekturen wird so zum zentralenErfolgsfaktor im strategischen IT-Manage -

der au tor

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 dasSegment IT-Consulting innerhalb der Gruppe. Er hat unter anderem als Interimsmanager das EAM derSchwei zerischen Bundesbahnen (SBB) konzipiert und aufgebaut.

1 www.objektspektrum.de

fachartikel

Jahrzehnten professionalisiert sind. DasManagement komplexer Unternehmens -archi tekturen wird in der Praxis mehr undmehr zum zentralen Erfolgsfaktor im stra-tegischen IT-Management, ohne dass diemeisten EAM-Teams diesen hohenAnspruch wirklich umsetzen können.

Viele Unternehmen haben in den vergan-genen Jahren Teams oder Abteilungen fürEAM ins Leben gerufen und dort dieVerantwortung für das Management derUnternehmensarchitektur angesiedelt.EAM stellt im Idealfall einen Prozess bereit,der die Geschäftsstrategie eines Unterneh -mens in eine Soll-IT-Architektur übersetztund damit die informationstechnischenGrundlagen zur Umsetzung dieser Strategieschafft. EAM ermittelt aus den Schlüssel -anforderungen und den künftig benötigtenGeschäftsfähigkeiten zur Umsetzung dergeplanten Strategie die bestehendenAbweichungen, die das Delta zwischen derheute vorhandenen und der zu implemen-tierenden Soll-Anwendungslandschaft dar-stellen. In der Folge profitiert nicht nur dieIT selbst von erfolgreich betriebenemEAM, sondern vor allem auch das Businessin seiner Gesamtheit (siehe Abb. 3).

In vielen Fällen bleibt jedoch dieWirksamkeit der EAM-Teams hinter denErwartungen zurück. In den meistenUnternehmen gibt es eine Menge begabterArchitekten und Analysten, die sich in eini-gen wenigen Anwendungen hervorragendauskennen. Noch immer gibt es IT-

Abteilungen, in denen niemand einenGesamtüberblick über die Anwendungs -land schaft besitzt. Wir treffen in unsererBeratungstätigkeit immer noch auf großeund sehr große Unternehmen, die ihreAnwendungslandschaft gar nicht kennenund die nicht wissen, welche Anwendungensie konkret betreiben und wie dieAbhängigkeiten zwischen diesen Anwen -dungen aussehen.

In den meisten Unternehmen haben wirnoch immer nicht genügend aggregierteInformationen über die zentralen Infor -

mationsflüsse. Vor allem aber wissen wirnicht, wie sich diese Informationsflüsse imUnternehmen verändern müssen, um einenin der Strategie definierten Sollzustandabzubilden. Partiell wissen wir das natür-lich immer für bestimmte Anwendungen,Produkte oder Komponenten. Aber wirverfügen in immer noch viel zu vielenUnternehmen über kein schlüssigesGesamtbild. Dieser Zustand wird seitLängerem diskutiert: Gartner spricht indiesem Zusammenhang von der „EACrisis” und prominente Vertreter der EA-

2Online-Themenspecial EAM 2010

Online-Themenspecial EAM 2010 fachartikel

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

Abb. 2: Enterprise Architecture Management – die Verzahnung aller Architektureneines Unternehmens.

verlangsamen oder erschweren dieProjektdurchführung erheblich. DieProjektverantwortlichen suchen sichSchleichwege in der Organisation. Eineaufkeimende Schatten-IT konterkariertdas ordnende Element einer EA-Strategie. Häufig geht eine anfänglicherreichte Transparenz über die Gesamt -landschaft wieder verloren, weil dieNachführ-Prozesse unterlaufen werdenund sich das EA-Repository nicht aufdem aktuellen Stand befindet.

Die Summe aller Probleme in gewachsenenLandschaften tendiert ab einer gewissenUnternehmensgröße gegen unendlich. EA-Teams laufen Gefahr, dieses Problemfeld zuanalysieren, zu kommentieren und letztlichzu verwalten. Nicht selten verbrauchen siedabei so viele Ressourcen, dass für dieeigentliche Problemlösung wenig Raumbleibt. Wenn nicht mit einer kulturell tiefverankerten Kultur der Lösungsorien -tierung konsequent gegengesteuert wird,droht deshalb eine „Analysis Paralysis”.

Trotz großer Anstrengungen bleiben alsodie sichtbaren Resultate der Enterprise-Architekten in vielen Fällen weit hinter denhoch gesteckten Erwartungen zurück. Diebisher angebotenen Lösungen für die skiz-zierten Problemfelder zielen häufig aufStrategien und Prozesse, auf Templates undWerkzeuge. Sie artikulieren Forderungenan die Architekten mit appellativemCharakter. Gartner etwa fordert: „Stopdoing technical architecture!” Die Gründe

Implementierungsvorhaben ergebendeGesamtlandschaft wieder ungeordnetund ungerichtet aus den Partikular-Interessen der einzelnen Projekte ent-wickelt.

■ Die Bürokratisierungs-, Perfektions-und Governance-Falle droht: DieEnterprise-Architekten sehen ihre wich-tigste Aufgabe in der Implementierungeiner möglichst präzisen EA-Gover -nance, die kontinuierlich weiterentwi -ckelt und ausgebaut wird. Damit bele-gen sie die Projekte nach und nach mitimmer höheren Zusatzaufwänden und

Szene (Enterprise Architecture), wie JohnWu, von der „EA Identity Crisis”. Wiemanifestiert sich jedoch diese EA-Krise? Inder Praxis beobachten wir drei immer wie-der auftretende Zustände:

■ Das „Big Picture” fehlt: EAM bleibtweit hinter den ursprünglich hochgesteckten Erwartungen zurück. StattEAM im Wortsinn zu betreiben, wer-den einzelne Systeme entwickelt, oder,wie John Wu es ausdrückt: „The valueof Enterprise Architects is to identifythe big picture of the enterprise and toprovide the enterprise definition for thesubject area expert, so they can designthe IT architecture from the aspect ofenterprise consideration. Stove-pipe-systems are created due to lack of thebig picture. The enterprise is large andeveryone only touches a part of theenterprise” (vgl. [Wu06]).

■ Die Umsetzung der vereinbarten Soll-Architektur scheitert: EAM liefert zwareine 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 derEnterprise-Architekten im Unterneh -men zu gering ist, als dass eine wirksa-me Steuerung der vielen einzelnenArchitekturentscheidungen in den IT-Projekten durchsetzbar wäre. Die Soll-Architektur ist dann zwar als Ziel defi-niert, sie wird aber letztlich nie wirklicherreicht, weil sich die aus den einzelnen

fachartikel

3 www.objektspektrum.de

Abb. 3: Ein ganzheitliches EAM stiftet Mehrwert für das gesamte Business und nichtnur für die IT.

Abb. 4: EAM und PPM.

für das Scheitern sind aber jenseits der gän-gigen und oft zitierten Ursachen zu finden,sie liegen im Verhalten der handelndenPersonen begründet. Eine Verhaltensän -derung der in EA-Prozessen agierendenMenschen erreichen wir aber nicht, indemwir For derungen aufstellen, sondern indemwir ihnen ganz konkret den Weg zur einererfolgreichen Verhaltensänderung aufzei-gen und sie bei den dabei nötigen Schrittenbegleitend unterstützen. Das Konzept derlösungsorientierten Beratung bietet genaudas: ein einfaches und dennoch sehr wirk-sames Instrument, mit dem mittels kleinerVerhaltensänderungen schnell und effektivgroße Veränderungen in der Performancevon EA-Teams erreicht werden können.

LösungsorientierungDas Konzept der lösungsfokussierten Inter -vention (Solution Focussed Brief Therapy,vgl. [DSh90]) wurde in den 80er Jahrenvon Steve de Shazer und Insoo Kim Berg ander University of Milwaukee entwickelt.Ursprünglich für die Familientherapie ent-worfen, kombiniert es viele Einflüsse ausdem radikalen Konstruktivismus mit derKommunikationstheorie von Watzlawickund Arbeiten von Wittgenstein (vgl.[Pit67]). Durch ein weltweit stark gewach-senes Interesse an lösungsorientierterPraxis in den 80er und 90er Jahren erfolg-te die Übertragung aus dem Thera pie -bereich in die Management- und Organisa -tionsberatung, in die Supervision und indas Coaching. In Deutschland haben insbe-sondere Insa Sparrer und Prof. MatthiasVarga von Kibéd lösungsorientierte Kon -zepte für die Organisations- und Manage -mentberatung entwickelt. In der Orga -nisationsforschung hat sich insbesondereStobbe (vgl. [Sto08]) intensiv mit denKonzepten von Steve de Shazer befasst unddiese in die Führungslehre von Malik inte-griert.

Stark vereinfacht zusammengefasst, liegtder Schwerpunkt der lösungsfokussiertenArbeit in den vorhandenen oder zu finden-den Ressourcen und Fähigkeiten der Klien -ten (Organisationen wie Personen) undnicht auf ihren Problemen und Defiziten(Lösungs- statt Problemfokus). Der lö -sungs orientierte Ansatz nach De Shazer(vgl. [DSh02]) fokussiert also nicht, wasProbleme verursacht, sondern wieLösungen konstruiert werden.

Ein lösungsorientiertes Managementbeschreibt eine Vorgehensweise, die

■ 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 Erfolgserlebnisseanalysiert, um die dahinter stehendenErfolgsstrategien und Kompetenzen aufdie nächsten Schritte zu übertragen.

Um in komplexen Situationen und Syste -men erfolgreich zu sein, ist es nicht immerhilfreich, sie modellieren und verstehen zuwollen. Häufig ist es hilfreicher, unvorein-genommen zu beobachten, was alles wiegewünscht funktioniert, um in kleinenSchritten mehr davon zu tun (vgl. [Kib09]).Lösungsorientierung geht davon aus, dass

■ positive Veränderungen in komplexenSituationen auf Basis kleiner Schrittegeschehen,

■ für diese Schritte nur wenige Infor -mationen über das, was bisher schonetwas besser funktionierte, genügen,

■ bei Analysen nicht die Frage „wie ist esbzw. wie kam es dazu?”, sondern dieFrage „was macht den Unterschied zwi-schen besser/schlechter aus?” insZentrum rückt,

■ anstelle des „theoretisch umfassendVerstehen 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 esist, wenn es besser ist!

■ Setze auf Interaktion statt auf isolierteIndividualitä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ückezwischen „Ist” und „Soll” ermittelnsondern das, was – wenn auch nur sel-ten – heute bereits etwas besser ist.

■ Sieh die Chancen im Gestern, Heuteund Morgen! Chancen in der Zukunftund im Heute zu überlegen, ist ein ver-trauter Gedanke. Eher unüblich ist es,auch im „Gestern” bewusst das zu

erkunden, was sich früher bereits alsChance 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-Architekteneines internationalen Logistikunterneh -mens hat den Auftrag, für eine bestimmtefachliche Domäne im Unternehmen einZielbild, also einen zukünftigen Bebau -ungs plan der Anwendungslandschaft zuentwickeln. Gemäß der mit den Fach -bereichen abgestimmten Vorgehens weisesollen dafür aus der Business-Strategie diestrategischen Handlungsfelder und dieerfolgsrelevanten Geschäftsfähig keitenabge leitet werden. In einer Gap-Analysewerden die strategischen Hand lungs felderund die relevanten Geschäfts tätigkeiten mitden Fähigkeiten der Systeme der heutigenAnwen dungs landschaft verglichen. Ausdem Ergebnis werden dann die erstenSchlüsse auf die künftige Soll-Bebauunggezogen. In einem Kick-Off-Meeting mitdem Fachbereich sichten die Architektendie vorhandenen Unterlagen. Dabei bemer-ken, sie, dass die Business-Strategie nur auseinigen unzusammenhängenden Folienbesteht und keine wirklich verwertbarenDokumente existieren. Zu allem Überflusssind auch die Kerngeschäftsprozesse desBereichs nicht dokumentiert und nicht inARIS hinterlegt, obwohl hier eigentlich alleProzesse erfasst sein müssten – von einerAbbildung der Kernprozesse auf dieModule der Kern anwendungen ganz zuschweigen.

Die Architekten notieren akribisch alleDefizite und fordern beim Leiter dieserSparte eine konkret ausformulierte Busi -ness-Strategie und eine Dokumentation derKerngeschäftsprozesse an, wie es imStrategieentwicklungsprozess vorgeschrie-ben ist. Die Verantwortlichen im Businessfühlen sich bevormundet, empfinden dieetwas forsch vorgetragenen Anliegen alswenig hilfreich und finden, die IT über-schreite mit diesen Forderungen ihreBefugnisse als Dienstleister. Die Reaktionfällt entsprechend gereizt aus. Nach demAustausch einiger langsam eskalierender E-Mails landet die Angelegenheit schließ-lich beim Gesamtvorstand, der sich schnellauf die Seite des Bereichsvorstands schlägtund der Bewältigung der aktuellen Nach -frage schwäche in Zeiten der Wirtschafts -krise absoluten Vorrang einräumt – vor der

4Online-Themenspecial EAM 2010

Online-Themenspecial EAM 2010 fachartikel

manage ment (in Projekten) und EAM (aufDomänen- oder Unternehmensebene).Enter prise-Architekten ziehen ihre Repu -tation, ihre Designkompetenz und ihreAutorität gegenüber den Projekten nur ausregelmäßigen Einsätzen in relevantenBusinessprojekten. Unterbleibt diesesWechselspiel, d. h. dieser Dialog mit denProjekten, verkommt das Archi tektur -management zu einer klassischen „Elfen -beinturm-Stabsabteilung”, die über wenigAnsehen gegenüber den anderen Abtei -lungen verfügt und keinen relevantenEinfluss auf das reale Architekturgeschehenin den Projekten und im Unternehmenbesitzt. Ineffektive Architekturstäbe dieserArt lassen sich leider in vielenUnternehmen beobachten. Wie lässt sichdas ändern? Durch einen permanentenProjekteinsatz der Enterprise-Architektenund durch ein mit allen Mitarbeitern zuerarbeitendendes Selbstverständnis: Einegut 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 Aufgabeund versucht nicht, ein Monopol aufdas Erbringen von IT-Leistungen zuerrichten,

■ setzt dennoch konsequent Rahmenbe -dingungen unter dem Gesichtspunktvon Gesamtarchitektur, Betriebs -sicherheit, Dokumentationsgrad undSchnittstellenkonformität,

■ behält die Zügel in der Hand, indem siedie Freiheitsgrade an die nachgewieseneProfessionalität der unterschiedlichenProjektteams anpasst,

■ hilft den Projekten beim Aufbau kom-petenter Teams mit informatischemWissen und unterhält zu diesen einepartnerschaftliche, kollegiale Bezieh -ung.

Um ein professionelles EAM zu betreibenund somit die Unternehmensstrategie undIT in Einklang zu bringen, müssen sichUnternehmen deshalb verstärkt auf einlösungsorientiertes Vorgehen unter Berück -sichtigung eines stabilen Werterahmenskonzentrieren. Erst dann kann EAM einenwichtigen Beitrag dazu leisten, um die vor-gegebene Geschäftsstrategie zu unterstüt-zen und umzusetzen. Eine professionelleEA ist dabei nicht als Selbstläufer, sondern

Projektliste zu erstellen. Der Bereichsvor -stand zeigt sich beeindruckt und verpflich-tet sich dazu, für eine weitere und präzisereIteration des Bebauungsplans nun docheinen Mitarbeiter abzustellen, der dasEAM-Team künftig unterstützen wird.Inspiriert vom Erfolg dieser erstenMaßnahmen beschließen die Architekten,diesen Weg auch auf die anderen fachlichenDomänen anzuwenden. Die Strategie wirdzunächst aus den wenigen vorhandenenQuellen und einigen Interviews mitSchlüsselpersonen in Thesenform formu-liert und dann in mehreren Iterationenimmer weiter präzisiert und verfeinert.Nach wenigen Monaten hat die IT eineVersion 0.8 einer Enterprise-Roadmap fer-tiggestellt und sich nebenbei noch vielRespekt und Vertrauen in den Fachbe -reichen zurückerobert.

Die Lösungsorientierung stellt also einenwichtigen Bezugsrahmen für eine wirksameVerhaltensintervention bei Enterprise-Architekten zur Verfügung. Idealerweisewird sie flankiert durch ein stabilesWertefundament.

Mechanistisches Prozess -verständnis statt InteraktionEA-Teams tendieren dazu, im EA-Prozess,in den Standards und in den Richtlinien diealleinige Lösung des Problems zu suchen.Lösungen für die Unternehmensarchitekturvon morgen entstehen aber nicht (nur)durch die Einführung von TOGAF-inspi-rierten (The Open Group ArchitectureFramework) EA-Prozessen. Lösungen ent-stehen als Ergebnis vieler erfolgreicherkommunikativer, sozialer Interaktionenzwischen den EA-Teams und den Projekt -teams in der IT, mit der Anwendungs -entwicklung, mit externen Partnern sowiemit den Fachbereichen oder, wie John Wues ausdrückt: „The enterprise architectfacilitates the collaboration. It is easy tounderstand the concept of collaboration,but it is very difficult to do. The secret isthat the architect must know how to intri-gue the stakeholders to raise their curiosityand interest similar to the magic stones inthe story of Stone Soup” (vgl. [Wu06]). Aufdie Gestaltung dieser Interaktionen müssenwir vermehrt achten – in ihrer Effektivitätliegt der Schlüssel für ein erfolgreichesEAM.

Kultur und WerteGutes EAM entsteht nur im permanentenWechselspiel aus operativem Architektur -

Dokumentation von Prozessen undStrategien. Die Architekten reagieren ent-täuscht und beleidigt – mit fehlendemManagement-Support und so eklatant ver-weigerter Unterstützung im Business seiEAM in diesem Konzern ein aussichtslosesUnterfangen und werde nie die gewünsch-ten Ergebnisse liefern.

Nach einem intensiven lösungsorientier-ten Coaching des gesamten Teams erfolgtein Neuanfang. Die Architekten durchfors -ten dabei zunächst auf eigene Faust dasIntranet des Unternehmens sowie alleöffentlich verfügbaren Dokumente desfraglichen Bereichs und formulieren darausein Thesenpapier mit einer Handvoll Kern -thesen zur Strategie des Bereichs. Mit die-sen Thesen ausgerüstet, werden „auf demkleinen Dienstweg” operative Mitarbeiterdes Geschäftsbereichs befragt und um eineVerifikation oder Falsifikation der Thesengebeten. Nach einigen unaufwändigen undschnell vereinbarten Gesprächen ergibt sichschon ein deutlich konkreteres Bild derStrategie. 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, wirddie Stimmung schnell konstruktiver, derBereichsvorstand kommentiert ausgiebig dieThesen zur Bereichsstrategie und ergänzt dienoch fehlenden oder falsch verstandenenAussagen. Aus einem auf 1,5 Stun den 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 eineAbleitung der erfolgsrelevanten Geschäfts -fähigkeiten in der Zukunft und eine ersteAussage, inwieweit die Anwen dungs -landschaft heute bereits in der Lage ist,Teile davon zu leisten. Getreu dem Mottoder Lösungsorientierung, „Wenn etwasfunktioniert, tue mehr davon”, wird dieserpragmatische Entwurf auch auf dieGeschäftsprozesse angewandt. Die Archi -tekten interviewen zunächst alle Anwen -dungsentwickler aus der IT, die mitWartung und Betrieb der Anwendungendes Geschäftsbereiches befasst sind. Ausden Gesprächen entsteht ein erster Entwurfeiner Prozesslandkarte, die lange nochnicht perfekt ist, aber immerhin einenguten ersten Überblick verschafft.

Mit diesen beiden Artefakten gelingt esder IT einen ersten Vorschlag zur Soll-Bebauung und eine daraus abgeleitete

fachartikel

5 www.objektspektrum.de

vielmehr als ein andauernder Prozess zu ver-stehen. Sie entsteht nur aus dem permanen-ten Wechselspiel von operativemArchitekturmanagement in Projekten undEAM auf Domänen- oder Unternehmens -ebene. Der wichtigste Treiber für den Erfolglässt sich letztlich in dem Ratschlag manife-stieren, dass sich Unternehmen nicht auf dieUrsachen der Probleme konzentrieren soll-ten, sondern auf die Frage, wie angemesseneLösungen geschaffen werden können.

Literatur & Links

[DSh02] S. De Shazer, Der Dreh: überra-schende Wendungen und Lösungen in derKurzzeittherapie (7. korrigierte Auflage),Carl-Auer-Systeme-Verlag, 2009

[DSh90] S. De Shazer, Wege der erfolgrei-chen Kurztherapie. 2. Aufl. Stuttgart: Klett-Cotta, 1990[Göt03] A. Götz, J. Liddle, „Process DrivenArchitecture” und „Business ProcessManage ment”, in: OBJEKT spektrum 6/2003[Kib09] M. Varga von Kibéd, Ganz imGegenteil (6. überarbeitete Auflage), CarlAuer Verlag, 2009[Moo08] L. Mooney, Aligning Strategywith Business Processes , Ebiz – TheInsider's Guide to Business and IT Agility,2008, siehe: www.ebizq.net/topics/human_centric_bpm/features/ 10378.html[Ora09] A. Oram, J. Viega, BeautifulSecurity, O'Reilly, 2009[Öst96] H. Österle, Business Engineering:Prozeß und Systementwicklung, Band 1,Springer Verlag, 1996

[Pit67] G. Pitcher, Die PhilosophieWittgen steins. Eine kritische Einführung inden Tractatus und die Spätschriften, Alber,1967[Sha09] A. Sharma, P. Loh, Emergingtrends in sourcing of business services, in:Business Process Management Journal2/2009[Spa07] I. Sparrer, Einführung in Lösungs -fokussierung und Systemische Strukturauf -stellungen, Carl Auer Verlag, 2007[Sto08] M. Stobbe, LösungsorientiertesManagement: Malik trifft de Shazer, Bookson Demand, 2008[Wu06] J. Wu, Light EnterpriseArchitecture (LEA), siehe: http://it .tool-box.com/blogs/lea-blog/ the-ea-identity-crisis-8590

6Online-Themenspecial EAM 2010

Online-Themenspecial EAM 2010 fachartikel