...und am Anfang steht dieGeschäftsanforderung, oder?Enterprise Architecture Management (EAM) ist ein Begriff, der heutzutage von vielen Unternehmen in den Mund genommen wird.Aber was bedeutet dieser Begriff eigentlich? Warum machen wir Enterprise Architecture Management? Wie wichtig sindStakeholder und eine Unternehmenskultur bei der Einführung eines Enterprise Architecture Management? In diesemZusammenhang kommen, fast automatisch, Antworten, wie: „bringt die Geschäftsstrategie und Informationstechnologie zusam-men (Business-IT-Alignment)“. Das beantwortet aber immer noch nicht unsere Fragen. Was ist mit den Geschäftsanforderungen?Was sind eigentlich Geschäftsanforderungen und wie kommt man von diesen zu einer Unternehmensarchitektur, welche dieGeschäftsanforderungen unterstützt und sich auf sogenannte „Business Outcomes“ konzentriert? Das Konzept des „Capability-Based Planning“ vom TOGAF 9 Framework bietet hier eine sehr gute Methode, anhand von Business Outcomes eineUnternehmensarchitektur umzusetzen. Mittels realistischer Praxisbeispiele zeigt dieser Beitrag, wie man diese Methode anwen-den kann und was man dabei beachten sollte.

Implementierung einer Unter neh mensarchi -tektur bereits vor gewaltige Herausfor -derungen, da oft auch Bereiche undOrganisationen unterschiedliche Ziele oderauch eine „Hidden Agenda“ verfolgen.

als Organisation, die wiederum andereOrganisationen und Bereiche (externe undinterne) umfasst, die gemeinsame Zielehaben. Genau dieser letzte Punkt „gemein-same Ziele“ stellt viele Unterneh men bei der

Was ist EnterpriseArchitecture Management(EAM)?Jeder wird es mit Sicherheit kennen. Allereden von einem Begriff und keiner hat wirk-lich eine Ahnung, was dieser Begriff bedeu-tet. Am Ende des Tages reden alle darüberund wundern sich dann, dass die handelndenPersonen in den Unternehmen eigentlich nuraneinander vorbeireden und folglich nichtzum erwünschten Ziel kommen. Nun, dieskann man in verschiedensten Lebenslagenwiederfinden. Im Fall von EAM kommt nocherschwerend hinzu, dass es eine Vielzahl vonniedergeschriebenen Begriffs defi nitionengibt, die von noch mehr beteiligten Personenin die Welt getragen werden. Wozu diesführt, kann man sich wohl gut vorstellen underleben wir auch tagtäglich.

Die aktuelle Version vom TOGAF 9Frame work bietet hier eine gute und auchlogisch nachvollziehbare Beschreibung, diemit Sicherheit vielen helfen wird, dasThema überhaupt erst einmal zu greifenund zu verstehen.

Betrachtet man diese Beschreibung etwasnäher, reden wir hier über ein Unternehmen

der au tor

Danny Weinberger

(E-Mail: danny.weinberger@architecting-the-enterprise.com)hat mehr als 10 Jahre Erfahrung als Projektmanager, Architekt, Berater und Trainer für das FrameworkTOGAF. Zusätzlich entwickelt er im Rahmen der Tätigkeiten innerhalb der Organisation „The Open Group“das Framework TOGAF weiter und ist Mitglied in verschiedenen Working Groups, wie TOGAF-FRAMEWORX(ehemals NGOSS) Mapping und TOGAF-Lokalisierung. Weiterhin hält er Vorträge auf Konferenzen.

1 www.objektspektrum.de

fachartikel

Abb. 1: Begriffsdefinition nach TOGAF 9

Die Architektur ist im Grunde die Be -schreibung und die Struktur von Kompo -nenten und ihren Beziehungen über diegesamte Organisation, sprich das gesamteUnternehmen. Somit geht es also um denAufbau und um das Managen von„Brücken“ und ihren „Beziehungen“ imgesamten Unternehmen. EAM beschränktsich also nicht nur auf IT, sondern umfasstmehrere Systeme und funktionale Gruppenim Unternehmen. Abbildung 2 verdeut-licht das sehr gut.

Warum EAM? – ErfolgsfaktorUnternehmenskulturEine Frage, die oft gestellt wird und schonviele in Argumentationsnöte gebracht hat.Haben die Unternehmen zudem nochschlechte Erfahrungen mit EAM – vielleichtgar in Verbindung mit serviceorientierterArchitektur (SOA) – gemacht, führt daszwangsläufig zu einer Grundsatzfrage imUnternehmen. Prinzipiell kann man sagen,dass EAM das im Unternehmen umsetzt, wasdie Geschäftsstrategie entwickelt bzw. dieGeschäftsanforderungen aus dem „DailyBusiness“ einfordern. Die Kunst bestehtjedoch darin, die richtige Balance zwischendiesen Geschäftsinnovationen und der IT-Effizienz zu finden, siehe auch Abbildung 3.

Um dem Ganzen einen praktischenBezug zu geben, ein kurzes Beispiel. EineFirma A unterhält geschäftliche Bezieh -ungen zu einer Firma B. A verkauft in die-sem Fall eine Lösung an B, woraufhin B

eine Preisreduzierung nachfragt. Gleich -zeitig ist B Lieferant und verkauft Produktean A. Hier hat B jedoch Probleme imService und die Aktivitäten der Geschäfts -beziehung 1 sind hier nicht bekannt. Zuguter Letzt ist B auch noch ein Partner vonA. Er fungiert hier als Vertriebs- und alsTechnologiepartner. Der Vertrieb läuftjedoch schleppend und die Produkte lassensich nur schwierig integrieren. InAbbildung 4 sind diese Beziehungen nocheinmal grafisch dargestellt.

Wie man an diesem Beispiel deutlichsehen kann, sind in diesen dreiGeschäftsfällen zwei Akteure in unter-

schiedlichen Rollen involviert. DiesesKonstrukt ist mit Sicherheit nicht immerder Fall und auch nicht immer so komplex,aber gerade im B2B-Geschäft sind dieseoder ähnliche Beziehungen zwischenUnternehmen sehr häufig anzutreffen.Auch bedeutet es nicht automatisch, dassdie Beteiligten eines Geschäftsfalls von denAktivitäten eines anderen GeschäftsfallsKenntnis haben bzw. haben wollen. Dasmag jetzt weit hergeholt klingen, ist aberdurchaus häufiger der Fall, als man denkt.Aber warum eigentlich? Ganz einfach, alledrei Parteien haben für sich unterschiedli-che Ziele. So hat der Vertrieb imGeschäftsfall A das Ziel, Umsatz mit demKunden (Akteur B) zu generieren, derEinkauf soll mit seinem Lieferanten (gleich-er Akteur B, aber andere Rolle) Ein kaufs -kosten einsparen und der Partner-Managerliegt irgendwo dazwischen. Ein gemeinsa-mes Ziel, wie eingangs in der Begriffs -definition beschrieben, sieht anders aus.

Was hat das Ganze jetzt mit EAM zutun? Bisher wurden EAM-Projekte meistdurch Anforderungen von einzelnenGeschäftsbereichen initiiert, die den Fokusauf bestimmte Geschäftsprozesse und diediese unterstützenden IT-Anwendungenlegten. Hinzu kam, dass der Erfolg maß-geblich von den Erfahrungen und Fähig -keiten des EAM-Teams abhängig war. Hierbietet TOGAF 9 mit dem ArchitectureSkills Framework z. B. eine gute Methode,das Wissen der Architekten zu bewertenund entsprechend weiterzuentwickeln.

Das Beispiel oben und die folgenden, sichdaraus ableitenden, Fragestellungen zeigen

2Online-Themenspecial EAM 2010

Online-Themenspecial EAM 2010 fachartikel

Abb. 2: Domänen der Architektur

Abb. 3: Darum EAM

die Rei bungspunkte nicht frühzeitig erkennt.Man sollte nicht vergessen, es gibt in jedemEAM-Projekt Stakeholder, die gewinnen undandere verlieren. Wer möchte schon gern ver-lieren? Weiterhin sollte die Unter nehmens -architektur (Geschäftsprozesse und IT) aufdie sich ständig ändernden Marktbedin -gungen reagieren können, ohne gravierendeÄnderungen vornehmen zu müssen – zumalunternehmensübergreifende Geschäftsmo -delle in der Zukunft noch viel stärker eineRolle spielen werden als bisher.

Capability-Based PlanningViele haben davon gehört und einige wissenes: „Capability-Based Planning focuses onbusiness issues and outcomes” [TOG09].

Wie bereits erwähnt, konzentrieren sichviele EAM-Projekte mehr auf die IT undderen Architektur sowie auf ein paarGeschäftsprozesse davor und dahinter. Vielegehen sogar davon aus, dass dieGeschäftsprozesse die Geschäftsanfor derun -gen an die IT oder sogar an die Architekturdarstellen. Das kann man erst einmal imRaum stehen lassen. Hier greifen wir dafürzunächst eines unserer Beispiele auf.

Der Geschäftsbereich Produktmanage -ment möchte, oder auch muss, ein neuesProdukt entwickeln und entsprechend ein-führen, um auf geänderte Marktbedin -gungen reagieren zu können. DieseAbsichts erklärung vom Produktmanage -ment, ein neues Produkt entwickeln zuwollen, stellt gewissermaßen das Ge -schäfts ziel dar, welches die Unternehmens -strategie unterstützt und kann auch als„Business Capability“ (Geschäftsfähigkeit)bezeichnet werden.

Eine Fähigkeit (Capability) ist nachTOGAF 9 die Fähigkeit, die eine Organi -sation, eine Person oder ein System besit-zen. Um das Geschäftsziel erreichen zukönnen, ist eine Kombination von unter-schiedlichen Organisationen, Personen,Prozessen und Technologien erforderlich.Wird also ein neues Produkt entwickelt,wird das Produktmanagement das Pro -dukt, dessen Aufbau und vor allem dieMerkmale in Richtung des Kunden definie-ren. Im Nachgang wird festgelegt, wie mandas Produkt vermarkten, beauftragen, her-stellen, betreiben und verrechnen kann. Indiesem Zusammenhang werden die jeweiliginvolvierten Organisationen, Bereiche undPersonen betrachtet und die entsprechen-den Geschäftsartefakte (Geschäftsprozesse,Kataloge und Matrizen (RACI)) erstellt.

IT das unterstützt und wie der externePartner integriert werden bzw. dieZusammenarbeit aussehen soll.

Bei all diesen praktischen Beispielen, be -kommen Begriffe von TOGAF, wieBoundaryless Information Flow, Stake -holder-Management, Bereitschaft zurVeränderung im Unternehmen und Rollenund Verantwortlichkeiten eine tiefereBedeutung als bisher und zeigen sehr deut-lich, dass man Enterprise ArchitectureManagement benötigt. Eines dürfte hierjedem einleuchten: Der Erfolg einesArchitekturprojektes in diesen Situationenhängt maßgeblich davon ab, wie die einzel-nen Mitspieler, oder besser Stakeholder, ausden einzelnen Geschäftsbereichen und dieexternen Partnern miteinander arbeiten,Veränderungen und einhergehende Trans -parenz durch den EAM-Ansatz im Geschäftakzeptieren und gemeinsam tragen. Dies istein wesentlicher Teil der EAM- Unterneh -menskultur, die von der Ge schäftsführungetabliert und vor allem (vor)gelebt werdensollte. Selbst wenn ein EAM-Team das ent-sprechend positive „Standing“ bei denGeschäftsbereichen hat, sollte es den Fokusauch verstärkt auf das Stakeholder-Management der Ge schäfts bereiche legen.Diese haben mitunter einen größerenEinfluss auf den Erfolg von EAM-Projektenals man denken mag und das EAM-Projektkann schnell eine „Mission Impossible“ wer-den, wenn man dies vernachlässigt und somit

aber, dass EAM sehr viel weiter gefasstwerden muss:

■ Was passiert, wenn eine Geschäfts -führung wissen möchte, wie lukrativdie Geschäftsbeziehung zwischen A(mir) und dem Geschäftspartner B,über alle drei Geschäftsfälle gesehen,wirklich ist?

■ Was passiert, wenn im Partnermanage -ment ein neuer Partner-Typ definiertwird, sich daraus neue Geschäfts -anforderungen an Prozesse und IT erge-ben und sich dann zum Beispiel dieFrage stellt, wer in diesem neuenProzess die Partnerverhandlung führt,wie dieser Partner in die Prozesse undIT integriert wird, wie man in den ope-rativen Prozessen zusammenarbeitetund wer die Verantwortung für diesePartnerschaft hält, das Partnermanage -ment oder der Einkauf?

■ Was passiert, wenn das Produkt -management in Abstimmung mit derGeschäftsstrategie Produkte weiterent-wickelt oder neue Produkte entwickelnmöchte bzw. muss, um neue Kundenund Märkte zu bedienen? Dazu sindeventuell noch externe Partner und/oder Anpassungen der internenbereichs übergreifenden Geschäfts -prozesse und IT-Landschaft notwendig.Folglich muss die Frage geklärt werden,wer in der neuen Zielarchitektur fürwelche Aufgaben zuständig ist, wie die

fachartikel

3 www.objektspektrum.de

Abb. 4: Beispielfälle im Unternehmen

Eventuell müssen bestimmte Personen oderPersonengruppen speziell ausgebildet wer-den, um den neuen Anforderungen gerechtzu werden.

Auf einer anderen Ebene muss identifi-ziert werden, wie „fähig“ die IT und dieInfrastruktur sind, diese Prozesse und letzt -endlich die Bereitstellung des neuenProduktes zu unterstützen. Aktivitäts -diagramme, Applikationskataloge oderMatrizen können z. B. die entsprechendenArtefakte darstellen. Wird in diesem Fallein neues Datacenter mit neuen Applika -tionen benötigt, spielen die Konsolidierungder gesamten Daten und die Bereitstellungder neuen Services eine große Rolle. DieseBeschreibung verdeutlicht sehr gut, dass dieeinzelnen Fähigkeiten nicht isoliert zubetrachten sind, sondern eine engeBeziehung untereinander haben, wie inAbbildung 5 dargestellt.

Die Kernelemente der fähigkeitsbasiertenPlanung (Capability-Based Planning) sindein konzeptionelles Framework, ein analy-tisches Framework und ein Ansatz vonModulen bzw. Bausteinen (Building BlockApproach), um die Frameworks anzuwen-den.

■ Ein konzeptionelles Framework erlaubtbei einer ungewissen Geschäftsplanung,die Flexibilität, die Robustheit und dieadaptive Fähigkeit hervorzuheben.

■ Das analytische Framework gibt einemdie Möglichkeit die Optionen der

Geschäftsfähigkeiten auf der operati-ven Ebene abzuschätzen und entspre-chende alternative Fähigkeiten auszu-wählen.

■ Ein Bausteinansatz erlaubt individuelleFähigkeiten innerhalb ihrer eigenenGeschäftsdomäne zu definieren, zu ent-wickeln und zu testen.

Die einzelnen Fähigkeiten in diesem Bei -spiel der Produktneuentwicklung könneninnerhalb einzelner, kleiner Architektur -domänen der Geschäfts-, Informations-und Technologiearchitektur (Phasen B, Cund D im TOGAF ADM) evaluiert undentwickelt werden. Die Geschäftsprozesseund die handelnden Personen sind dann inder Geschäftsarchitektur zu betrachten,während die IT-Anwendungen und dieInfrastruktur in der Informations- undTechnologiearchitektur zu finden sind.Durch die engen Beziehungen dieserFähigkeiten ist es in diesem Fall auch not-wendig, mehrere Architekturdimensionengleichzeitig zu betrachten. Ein fortlaufen-der Iterationszyklus über diese einzelnenArchitekturdimensionen ist an dieser Stellesehr nützlich.

Gemeinsam beschreiben sie die Gesamt -heit aller Fähigkeiten für diese Produkt -entwicklung, die dann mittels kleinerer undüberschaubarer „Transition Architectures“den Weg zu einer neuen Zielarchitekturebnen. Diese werden dann während derMigrationsplanungsphase (Phasen E und Fim TOGAF ADM) identifiziert.

Die fähigkeitsbasierte Planung dreht sichalso um die Etablierung einer Fähigkeit, umeine bestimmte Anzahl von generischenAuf gaben zu erfüllen. Dadurch entsteht einerheblicher Nutzen, vor allem wenn mandie Migrationsplanung dieser Vorhabenangeht. Man hat dabei immer denGeschäfts nutzen und ein entsprechendesGeschäftsresultat (Business Outcome) imAuge und fokussiert alle Aktivitäten in derUnternehmensarchitektur (EnterpriseArchitecture) auf diesen Punkt hin.

FazitCapability-Based Planning vom TOGAF 9stellt mit Sicherheit einen guten Weg dar,um auf der Basis von geplanten Ge -schäftsresultaten eine Architektur aufzu-bauen und zu managen. Selbst wenn mandiese Methode nicht in der Gesamtheitanwendet, sollte man immer einenGeschäftsnutzen und ein entsprechendesResultat für die Geschäftseinheit und diedaraus schlussfolgernden Architekturak -tivi täten zugrunde legen. Geschäftsprozessesind in diesem Fall weniger als Geschäfts -anforderungen an das EAM-Team geeignetund stellen eigentlich „nur“ die erste Phaseder Architektur – Geschäftsarchitektur derPhase B nach TOGAF – dar.

Als Pionier und weltweiter Experte imBereich Enterprise Architecture Manage -ment und TOGAF, bietet Architecting theEnterprise langjährig erprobte Trainings-und Beratungsangebote, wie zum BeispielTOGAFTM 9 for Practitioners Zertifi -zierungs kurs, Enterprise ArchitectureAssessment Services (EAAS) oder Enter -prise Architecture Development Work -shops zu verschieden Themenfeldern. Vorallem der EAAS-Service ist bei der Defi -nition der Baseline-Architecture äußersthilfreich, da hier bereits viele ihre erstengroßen Herausforderungen haben. DieEnterprise Architecture DevelopmentWork shops begleiten die Unternehmenbeim Aufbau einer Unternehmens -architektur und konzentrieren sich dabeiauf kritische Erfolgsfaktoren und Schwer -punkte des Architekturprojektes.

Referenz:[TOG09] TOGAF 9 Specification Docu -ment of „The Open Group“, Februar2009. ■

4Online-Themenspecial EAM 2010

Online-Themenspecial EAM 2010 fachartikel

Abb. 5: Capability Increments and Dimensions – TOGAF 9