Whitepaper November Unterstützung von Architektur- Frameworks in planningit

Transkript

1 Whitepaper November 2007 Unterstützung von Architektur- Frameworks in planningit

2 2 November 2007 Einleitung Seit Jahren dienen Architektur-Frameworks Unternehmensarchitekten als Grundlage für den Umgang mit der stetig wachsenden Komplexität der IT-Umgebung sowie den immer anspruchsvolleren Anforderungen an ihren Zuständigkeitsbereich. Organisationen versuchen mittels Standard-Frameworks wie TOGAF und Zachman oder eigenen Frameworks die Architekturarbeit so zu strukturieren, dass sie verständlich ist und so leicht übermittelt werden kann. Dadurch gewinnt sie für das Unternehmen an Bedeutung und Wert. Frameworks haben sich auch in dem Bestreben nach einer Ausrichtung der IT am Geschäft des Unternehmens bewährt; dies allerdings nur bei korrekter Anwendung. Das Geschäft einer jeden Organisation ist etwas sehr individuelles. Deshalb sollten Unternehmen das ihren Ansprüchen am meisten gerecht werdende oder eigene Framework, den Bedürfnissen des Unternehmens unbedingt anpassen. Aufgrund der vielen beweglichen Elemente innerhalb einer Organisation ist der Erfolg eines Unternehmens von zu vielen Faktoren abhängig, so dass ein Standard-Framework nicht zum Dogma werden kann, ohne Gefahr zu laufen, dass die IT bei der Unterstützung des Unternehmens stark behindert werden würde. Die Norm IEEE Standard 1471 war der erste Versuch zur Standardisierung der EA-Entwicklung, bei dem berücksichtigt wurde, dass es für eine Ausrichtung der IT am Geschäft einer Entwicklung im Kontext der Organisation bedarf, da ansonsten jeglicher Nutzen für das Unternehmen verloren ginge. Auf diese Weise wird gleichzeitig der Grundsatz befolgt, dass verschiedene an der Organisation beteiligte Personen in der Beschreibung der Architektur berücksichtigt werden. Eine Einbindung aller Beteiligten ist gerade angesichts der dezentralisierten Strukturen der heutigen Mammutunternehmen im Sinne einer erfolgreichen Governance ein dringendes Erfordernis. Daher sind unterschiedliche Views (Ansichten) der Architektur Bestandteil der meisten Frameworks, wobei jeder View ein gekennzeichnetes Set von Systemanliegen umfasst. In einigen Frameworks sind auch Viewpoints enthalten.

3 Unterstützung von Architektur-Frameworks in planningit 3 Was ist ein Framework? Ein EA-Framework ist eine abstrakte, graphische Darstellung des Unternehmens oder, genauer gesagt, der IT-Landschaft des Unternehmens. Mittels EA-Frameworks werden Unternehmensarchitekten bei der Klassifizierung und Organisation verschiedener Modelle unterstützt, indem der Zugriff auf unterschiedliche Viewpoints und Details für ein breiteres Anwenderspektrum erleichtert wird. Durch die Einführung eindeutiger Grenzen und Verantwortlichkeiten, je nachdem ob sich die Unternehmen für dezentralisierte, zentralisierte oder föderierte Architekturgruppen entscheiden, wird durch EA-Frameworks auch die Kommunikation vereinfacht. EA-Frameworks geben die Hauptrichtung vor, doch die Landschaft bleibt facettenreich, Henry Peyret, Forrester, 26. Juli In IEEE 1471, V 4,0 werden Views und Viewpoints unter der Rubrik FAQ wie folgt erklärt: ein View ist eine Sammlung von Modellen, die das gesamte System in Bezug zu einem Set zugehöriger Anliegen darstellt. Ein View ist Teil einer bestimmten Architekturbeschreibung. Eine strukturelle Ansicht eines Systems kann beispielsweise ein Modell beinhalten, in dem Komponenten, deren Schnittstellen und die Klassen, in denen sie erfasst sind, dargestellt werden. Ferner kann auch ein Modell der Abhängigkeiten und Vererbungsbeziehungen dieser Komponenten enthalten sein.. Ein Performance View kann Modelle zur Nutzung von Ressourcen, Terminplänen und Ursache-Wirkungsdiagramme enthalten. In

4 4 November 2007 einem Viewpoint werden die Maßstäbe für den Aufbau und die Analyse eines bestimmten Viewpoints festgelegt. Er dient als Vorlage für einen View, der in vielen Architekturbeschreibungen wiederverwendet werden kann. Auch wenn in den meisten Frameworks die Views verschiedener Beteiligter berücksichtigt werden, mangelt es ihnen dennoch an Vielfalt und Genauigkeit, um das breite Anwenderspektrum in großen Organisationen präzise darstellen zu können. An dieser Stelle kommen Meta-Modelle ins Spiel, die die benötigten, detaillierten Ansichten bieten, um ein stimmiges Bild der Unternehmensarchitektur mit all ihren Facetten erzeugen und vermitteln zu können. Zusätzlich bieten Frameworks unumstrittene Vorteile hinsichtlich der Festlegung des Inhalts der EA und nützlicher Navigationskonzepte. Trotz allem belegen Erfahrungswerte, dass diese Frameworks als Business-Support-Prozesse unzureichend sind. Insbesondere mangelt es ihnen an den für die Unterstützung eines breiten Anwenderspektrums in einem gemeinsamen Planungsprozess zur Förderung der Unternehmensarchitektur nötigen Workflow-Konzepten. Als Anbieter eines Tools zur architekturbasierten IT-Planung und IT-Managements wird bei alfabet oftmals nachgefragt, welche Frameworks von uns unterstützt werden. Mit diesem Whitepaper möchten wir mit einem Blick auf die meisten der heute gebräuchlichen Standard-Frameworks die Positionierung von planningit in diesem Gebiet erläutern. Wie werden Frameworks in planningit unterstützt? Damit ein Framework von einem Tool unterstützt werden kann, muss man damit verschiedene Definitionen und Modelle mit einer Framework-Klassifizierung verknüpfen können und festlegen, welche Position ein Objekt in einem Framework einnehmen kann. Die Framework-Unterstützung, die von planningit geleistet wird, kann nicht nur als ergänzender, konzeptioneller Bezugspunkt für Anwender, sondern auch zur Navigation und tiefer gehenden Analyse verschiedener Aspekte der IT-Landschaft genutzt werden. Aufgrund der Vielschichtigkeit des planningit-meta-modells, können Frameworks außerdem auf einfachstem Wege in der Software abgebildet werden. Eine Vielzahl verschiedener Architektur-Frameworks und -Standards, wie COBIT, ITIL, TOGAF und Zachman wurden

5 Unterstützung von Architektur-Frameworks in planningit 5 überprüft und für die alfabet-methodik angewandt. Dazu zählen unter anderem Namenskonventionen, Ziele, Auswertungen und Prozesse. Bevor wir uns nun den individuellen Frameworks zuwenden, ist eine Beschreibung der EA-Prozesse, die von planningit unterstützt werden, und der Architekturelemente, derer es Bedarf, um die Prozesse wirksam durchzuführen, ratsam. In den folgenden Abschnitten wird es Ihnen möglich sein, planningit mit einem bestimmten Framework in Beziehung setzen zu können. Im Logical Inventory von planningit sind alle relevanten Informationen bezüglich der EA und des EAMs eines Unternehmens enthalten: Unternehmensstrategien und -ziele, mit dem Unternehmen verbundene Objekte, technische Informationen und Systemarchitekturen. Jedes Objekt enthält Informationen über die Relation zu anderen im System eingebundenen Objekten, so dass unterschiedliche Views auf die Architektur ermöglicht werden. Alle Objekte, sowohl aktuelle als auch geplante, sind außerdem mit Zeitrahmen verbunden. Dieser Aspekt ist besonders bei der Planung neuer Architekturlösungen und der Bewertung ihrer Auswirkungen auf andere Architekturelemente (und andersherum) zu bestimmten Zeitpunkten von besonders großer Bedeutung. Ferner ist dies insbesondere hinsichtlich der Transparenz und Kontrolle in einem Unternehmen, das mehrere, grundlegende Projekte parallel laufen hat, entscheidend. Foundation for decision Business functions Organization Locations Processes Products Business Architecture Information Architecture Information needs of the enterprise Ownership & accountability Business objects Information flows Interfaces Diagramm 1: In planningits Logical Inventory werden alle der mit den unterschiedlichen Views auf die Unternehmensarchitektur verbundenen Architekturelemente erfasst und gepflegt. Components Technical Platforms Architecture Deployments Technical infrastructure Standard components/platforms Application Architecture Applications Variants Versions Services Strategies, standards and methods for developing solutions View of how service bundles support the business architecture

6 6 November 2007 Informationen aus dem logischen Inventar versorgen die Prozesse, einschließlich planningits Prozessplattform. Prozesse werden in funktionalen Modulen gebündelt, die den allgemeinen Umfang bestimmter Aufgaben im EA-Entwicklungsprozess betreffen. Das Modul Value Management dient der Definition, Dokumentation und Ausrichtung von Geschäfts- und IT-Strategien sowie auch der Definition von KPIs, Rollen und Projektbewertungskriterien. Das Modul Enterprise Strategy and Master Planning dient der Analyse und Bewertung des Applikations-Portfolios (dessen Unterstützung von Business- Prozessen und verbrauchenden Organisationseinheiten, Redundanzen, Kosten und Nutzungsgraden), Soll-Architekturen zu konsolidieren und einen IT-Bebauungsplan samt Roadmaps zu erzeugen, in denen die Architekturentwicklungsstadien schrittweise dargestellt werden. Das Modul Enterprise Architecture Management dient der Definition von Unternehmensstandards und -richtlinien sowie der Sicherung der Standard- Compliance. Das Modul Business Demand Management dient der Dokumentation von Anforderungen im Zusammenhang mit ihrer technischen und strategischen Ausrichtung, um IT-Vorhaben zu definieren und Anforderungen innerhalb des Systems zu verfolgen. Das Modul Application Architecture Management ermöglicht sowohl detaillierte Analysen der Ist- und Plan-Architekturen, als auch den Vergleich von Lösungsszenarien und Business-Cases für definierte Projekte, die Durchführung Differenzanalysen sowie die Erstellung von Lösungsarchitekturen und Migrationsplänen. Im Modul Program Portfolio Management werden definierte Projekte Programmen zugeordnet und eine Bottom-Up- und Top-Down-Analyse von Budgets und Programmen durchgeführt. Im Modul Release Management werden operationale Anweisungen aus genehmigten Lösungsplänen für die Installation und Kommunikation mit CMDBs abgeleitet. Das Modul Compliance-Management dient der Definition eines zentralisierten Frameworks und der zugehörigen Daten, um die Compliance-Kontrollen

7 Unterstützung von Architektur-Frameworks in planningit 7 effizienter zu gestalten. Ferner können Compliance-Auswertungen durchgeführt und verwaltet werden und die Einhaltung der Kontrollstruktur und Richtigkeit der bewerteten Objekte überprüft werden. Value Management Enterprise Strategy & Master Planning Business Demands Business Demand Management Application Architecture Management Enterprise Architecture Management Program Portfolio Management Budgets and Projects Compliance Management Release Management Diagramm 2: In planningits Prozessmodulen werden Prozesse in funktionalen Modulen gebündelt, die den allgemeinen Umfang bestimmter Aufgaben im EAEntwicklungsprozess betreffen. Wenden wir uns nun der Frage nach der Unterstützung verschiedener Standard- Frameworks in planningit zu: TOGAF Das Architektur-Framework TOGAF ermöglicht eine Klassifizierung, mit der man die Konzepte, die die reale Welt beschreiben, mit denen, die ein Informationssystem und dessen Implementierung beschreiben in Beziehung setzen kann. Es wurde erstmals Mitte der 90er durch The Open Group eingeführt und ist mittlerweile in der Version 8 erhältlich. TOGAF enthält die Architecture-Development-Method (ADM), mittels derer die Erzeugung einer Unternehmensarchitektur beschrieben wird, die alle individuellen Anforderungen einer Organisation betrifft und alle damit verbundenen Aspekte berücksichtigt.

8 8 November 2007 Diagramm 3: Die Architecture-Development- Method (ADM) von TOGAF kann in planningit abgebildet werden. Prelim: Framework and Principles H Architecture Change Management A Architecture Vision B Business Architecture G Implementation Governance Requirements Management C Information System Architectures F Migration Planning E Opportunities and Solutions D Technology Architecture TOGAF verfolgt einen prozessorientierten Ansatz zur EA-Entwicklung und steht daher im Einklang mit planningit. planningit bietet eine umfassende Unterstützung der Architecture-Development-Method (ADM) von TOGAF. Im Folgenden wenden wir uns den Hauptzielen der einzelnen Phasen der ADM zu und werden dabei aufzeigen, wie planningit diesen gerecht wird. (Die hier erwähnten Hauptziele stellen nur eine Auswahl aller Ziele einer solchen Phase dar. Sie dienen der Hervorhebung der Schwerpunkte der jeweiligen Phase.)

9 Unterstützung von Architektur-Frameworks in planningit 9 Vorstadium: Diese Phase beinhaltet die Definition des Umfangs der Architekturarbeit, die Zuweisung der Verantwortlichkeiten für diese Aufgaben sowie jegliche Architekturprinzipien, die die Arbeit steuern sollten. Des Weiteren werden in dieser Phase die Frameworks und Methoden zur Entwicklung der EA definiert. Diese Phase zielt auf das Engagement all derer in der Organisation ab, die entweder Architekturarbeit leisten oder von dieser profitieren. Die ADM wird in dieser Phase von planningit dadurch unterstützt, dass die notwendigen Mittel zur Festlegung von Prinzipien und Richtlinien bereitgestellt werden, die mit dem EA-Programm verbunden sind. Organisatorische Informationen, die in Beziehung zu dem Programm stehen, werden in dem EA-Inventar des Produkts erfasst. Durch die Unterstützung von Domänen ist es möglich, das Architekturprogramm zunächst nur mit eingeschränktem Umfang einzuführen. Das Produkt selbst beinhaltet ein Framework und eine Methode zur Entwicklung der EA, die auf den langjährigen Erfahrungen der Entwickler sowie auf den best-practices der Kunden beruht. Phase A, Architekturvision: In dieser Phase werden die aktuelle Architektur dokumentiert und die Hauptanforderungen und -ziele des Unternehmens, die erreicht werden sollen, sowie die daran Beteiligten definiert. Eine Architekturvision, die eine Antwort auf die Anforderungen eines Unternehmens darstellt, wird formuliert. Diese Phase ist besonders im Hinblick auf die Beschreibung der Auswirkungen auf und von anderen parallel ablaufenden Entwicklungszyklen der EA von großer Bedeutung. planningit bietet eine Fülle von Möglichkeiten zur Förderung der Entwicklung der Architekturvision. Durch planningits Strategieableitungsprozess wird ein moderierter Prozess zur Übertragung von Geschäftsanforderungen in IT-Maßnahmen und zur Analyse der Auswirkungen einzelner Geschäftsanforderungen auf die Architektur unterstützt. planningits einzigartige Master Planning - Funktionalität ermöglicht den Architekten die Abbildung der operationalen (aktuellen) und der strategischen (visionären) Architekturen auf Business-

10 10 November 2007 Support-Matrizen. In diesen wird angezeigt, welche Architekturelemente welche Organisationen für welche Business-Prozesse unterstützen. Aufgrund des Zeitbezugs aller Inventarobjekte ist natürlich eine solche Anzeige für sämtliche Zeitpunkte möglich. Mittels Konfliktanalysen werden die Auswirkungen auf oder von Architekturen in anderen Domänen angezeigt. Phase B, Business-Architektur: In dieser Phase wird die aktuelle Business-Architektur beschrieben und eine Soll-Business-Architektur gemäß der Produkt- und/oder Service-Strategie entwickelt. Beide schließen sowohl organisatorische und funktionale Aspekte als auch Aspekte, die die Prozesse, die Informationen sowie auch die Geographie der Geschäftsumgebung betreffen, ein. Des Weiteren werden Differenzanalysen der Ist- und Soll-Architekturen durchgeführt. An dieser Stelle wird die Business- Architektur benötigt, um Beteiligten aus dem Business-Umfeld den Wert der darauffolgenden technischen Änderungen zu verdeutlichen und zwar in einer Form, die diesen zuspricht. Die aktuelle Geschäftsarchitektur wird in planningit einschließlich der Definitionen der Business-Produkte und -Services, der Prozesse und der Organisation erfasst und setzt diese mit den im Inventory enthaltenen Business-Strategien und -Drivers in Beziehung. Die Master Planning - Funktionalität spielt auch bei der Visualisierung des Soll-Zustands der Business-Architektur und dem Aufzeigen von Differenzen zwischen Sollund Ist-Zuständen eine bedeutende Rolle. Dadurch wird dem Unternehmen die Planung, die Diskussion und die Vermittlung von Veränderungen der Business-Prozessen und Business-Modelle ermöglicht, so dass die Planung von Business-Prozessen erheblich vereinfacht wird. Gleichzeitig wird auf diese Weise eine Anpassung aller Aspekte der EA an Veränderungen in den Business-Prozessen ermöglicht, so dass die Beständigkeit und Integrität des EA-Modells gewährleistet wird. Phase C, Informationssystemarchitekturen: In Phase C werden, ähnlich wie in Phase B, die Ist- und Soll-Architekturen für die Daten und Appliktionen erfasst. Mittels der Datenarchitektur werden die für die Unterstützung des Unternehmens wichtigsten Datentypen und -quellen defi-

11 Unterstützung von Architektur-Frameworks in planningit 11 niert. Anhand der Applikationsarchitektur werden die Hauptapplikationssysteme, die die in der Datenarchitektur beschriebenen Daten verarbeiten, definiert. In planningit wird der Informationsbedarf eines Unternehmens in der Informationsarchitektur erfasst. Hierin eingeschlossen sind Business-Objekte, Informationen über Eigentümerschaften und Verantwortlichkeiten sowie Informationsflüsse und Schnittstellen. Die Applikationsarchitektur dient der Darstellung der Unterstützung der Business-Architektur durch gebündelte Services. Phase D, Technologie-Architektur: Ziel dieser Phase ist die Entwicklung einer Technologie-Architektur, die als Grundlage für die darauffolgende Implementierung dienen soll. In dieser Phase geht es um die Konvertierung der Beschreibung des bereits bestehenden Systems in eine Service-Sprache, um... Kompatibilität mit der Aufschlüsselung der Standards und der Beschreibungen zu gewährleisten, die innerhalb der Basisarchitektur der Organisation Anwendung finden. (Quelle: TOGAF/MDA Mapping, The Open Group, September 2005) In planningits technischer Architektur-View werden Strategien, Standards und Methoden zur Lösungsentwicklung erfasst. Darin eingeschlossen sind Komponenten, Plattformen, Installationen, die technische Infrastruktur sowie Standardkomponenten und -plattformen. Diese Elemente enthalten Referenzmodelle zur Darstellung der unterschiedlichen Viewpoints der Beteiligten, um sicherzustellen, dass die Interessen aller korrekt in der technischen Architektur angezeigt werden. Phase E, Möglichkeiten und Lösungen: In dieser Phase werden Projekte ausgewählt, die die Architektur auf den Weg in Richtung Soll-Architektur bringen. Als Entscheidungsgrundlage fungieren hierbei die Auswirkungen auf die Architektur sowie die Kosten und Nutzen der betreffenden Projekte. Es wird eine Roadmap generiert, um die Veränderungen verfolgen zu können.

12 12 November 2007 In planningits operationaler Prozesskette - dem Demand-to-Budget-Workflow - werden Projektanforderungen sorgfältig bezüglich ihrer Ausrichtung an den Unternehmenszielen und -strategien sowie ihrer Auswirkungen auf die Architektur überprüft. Architekturlösungen werden für jedes Projekt erstellt und bezüglich ihrer Auswirkungen, Kosten und dem Entwicklungsgrad der Architektur hinsichtlich der Zielerreichung beurteilt. In Auswirkungsanalysen werden potentielle Konflikte in grundlegenden, parallel ablaufenden Projekten aufgezeigt. Durch Portfolio-analysen wird die Entscheidung für die tatsächlich zu budgetierenden Projekte gefördert. Durch den Planungsprozess von der Anforderungsaufnahme bis hin zur Budgetierung wird gewährleistet, dass die Projekte, in die investiert wird, nur ein geringes Misserfolgsrisiko in sich bergen und das Unternehmen bei der Erreichung der strategischen Ziele antreiben. Phase F, Migrationsplanung: In Phase F werden Projekte hinsichtlich ihrer Implementierung auf Grundlage von Abhängigkeiten, Kosten und Nutzen priorisiert. In planningit wird die Priorisierung durch das Modul Program Portfolio Management unterstützt, welches jegliche vorangegangene Bewertungen der IT-Vorhaben als Basis nutzt. Des Weiteren unterstützt dieses Modul Konfliktanalysen zwischen verschiedenen IT-Vorhaben und den zugehörigen Lösungsarchitekturen und trägt zum besseren Verständnis der benötigten Zeitpläne und Skill-Ressourcen bei. Nach Abschluss dieser Phase kann das Projekt dem Projektmanagement zur Projektplanung und -einführung übergeben werden. Phase G, Implementierungssteuerung: Anhand dieser Phase wird gewährleistet, dass Projekte entsprechend der Planung implementiert werden, bzw. dass notwendige Planänderungen korrekt dokumentiert und - wie die ursprüngliche Planung - hinsichtlich ihrer Auswirkungen bewertet werden. planningit ermöglicht die Dokumentation von Änderungen bezüglich des Umfangs sowie auch die Bewertung einer Alternativlösung. In solch einem Fall würde eine Änderung des Umfangs den gesamten Prozess von der Anforde-

13 Unterstützung von Architektur-Frameworks in planningit 13 rungsaufnahme hin zur Budgetierung erneut durchlaufen, um eine erfolgreiche Implementierung garantieren zu können. planningit unterstützt die Architekturübersicht der Implementierung mit Monitoren und Aufgaben, so dass die Verantwortung für alle Änderungen übernommen wird. planningit weist eine hohe Kompatibilität mit den gängigen PMO-Support-Lösungen auf, so dass eine beständige und kohärente Verfolgung der Ausführung sowie das Reporting für Management und Eskalation ermöglicht werden. Phase H, Architecture Change Management : In dieser Phase wird gewährleistet, dass Architekturänderungen auf eine geschlossene und strukturierte Weise durchgeführt werden. Des Weiteren wird in Phase H die implementierte Unternehmensarchitektur als eine dynamische Architektur, die schnell und flexibel auf mögliche Änderungen in der technischen und geschäftsorientierten Umgebung reagiert, eingeführt und unterstützt. planningit unterstützt zu 100 Prozent das Architecture Change Management auf Grundlage seines transaktionsbasierten Inventars der aktuellen und geplanten Architekturartefakte. Durch planningit wird eine Bewertung aller an der Architektur vorgenommenen Änderungen hinsichtlich ihrer Konformität mit definierten Standards ermöglicht. Die aktuelle und vollständige Abspeicherung aller Architekturartefakte ermöglicht eine schnelle Reaktion auf Änderungsanforderungen. Anforderungsmanagement: In dieser Phase wird ein Prozess definiert, durch den EA-Anforderungen identifiziert, gespeichert sowie in die entsprechenden ADM-Phasen ein- und ausgespeist werden. Im planningit-modul Business Demand Management werden alle eingehenden Anforderungen dokumentiert, so dass es dem Business-Demand-Analysten bereits in diesem frühen Stadium möglich ist, redundante Anforderungen zu konsolidieren, oder zu umfangreiche Anforderungen in kleinere Anforderungen aufzuteilen, die dann auf konstruktivere und realistischere Weise bewertet werden können. Zu diesem Zeitpunkt werden die Anforderungen auch hinsichtlich ihrer Durchführbarkeit und der Förderung der Unternehmensziele gefiltert, um

14 14 November 2007 Vorstadium - Phase C Phase D - Phase G Phase H - Anforderungsmanagement

15 Unterstützung von Architektur-Frameworks in planningit 15 die Liste der Anforderungen zu verkürzen. Das Modul BDM speist alle anderen ADM-Phasen zur Lösungsentwicklung, indem die Architekturänderungen/- projekte bis zu den Anforderungen hin zurückverfolgt werden. planningits Standard-Unterstützung der in der ADM von TOGAF definierten Architekturphasen gewährleistet, wie bereits erwähnt, eine hundertprozentige Unterstützung dieser Methode. Anmerkung: Da der Umfang von planningit und dessen Unterstützung des TOGAF-Frameworks bereits im Detail erläutert wurde, beschränken wir uns im Folgenden auf eine etwas allgemeinere Beschreibung der übrigen Standard-Frameworks, wobei besonderes Augenmerk auf die spezifischen Schwerpunkte dieser Frameworks gerichtet wird. Zachman Das Zachman-Framework für Unternehmensarchitektur wird häufig als das erste Architektur-Framework beschrieben, auf dessen Grundlage andere, wie beispielsweise DoDAF und MODAF entwickelt wurden. Das in den 1980er Jahren von John Zachman für IBM entwickelte Framework ist mittlerweile bei der Darstellung der Basiselemente einer Unternehmensarchitektur weltweit zur allgemeinen Norm geworden. Eine Unternehmensarchitektur ist ein sehr komplexes und facettenreiches System, das folgende zwei Aspekte umfasst: Inhalt und Prozesse. Im Vergleich zu dem stark prozessorientierten Framework TOGAF-ADM, liegt der Schwerpunkt des Zachmann-Frameworks auf den Inhalten. Inhalt wird mit den Views assoziiert, die jede mögliche Perspektive in der Organisation darstellen. Das folgende Diagramm zeigt das Zachman-Framework und wie darin Aktivitäten, Funktionen und Organisationen dargestellt werden.

16 16 November 2007 Diagramm 4: Das Zachman-Framework für Unternehmensarchitektur ist eine umfangreiche Beschreibung des Unternehmens, welche die Inhalte im Kontext aller Beteiligten erfasst Auf horizontaler Ebene sind Fragewörter aufgelistet, mittels derer eine Definition des Unternehmens vorgenommen wird. Auf vertikaler Ebene werden die Rollen angezeigt, die von verschiedenen Akteuren innerhalb des Unternehmens übernommen werden. Diesen Akteuren sind entsprechende Perspektiven zugeordnet, die als Umfang, Business-Modell, System-Modell, Technologie-Modell sowie als detaillierte Darstellungen definiert sind. Die Schnittstelle einer jeden Zeile und Spalte ist eine Zelle, in der ein bestimmtes Unternehmensartefakt enthalten ist. Laut Zachman hätte ein Unternehmen mit einer vollständigen EA eine eindeutige Darstellung, die die aktuellen und geplanten Aktivitäten, die mit dieser Zelle verbunden sind, beschreibt. Des Weiteren sollten - entsprechend Zachman - alle Modelle in angrenzenden horizontalen und vertikalen Zellen mit den Artefakten der anderen Zellen im Einklang stehen. Solch ein lückenlos beschriebenes Unternehmen würde über eine vollständige Gleichrichtung seines Geschäftsleitbildes (Business Mission) an den implementierten Systemen verfügen und den Einsatz von Ressourcen, Prioritäten und Prozessen ohne Verluste bestreiten. So ein Unternehmen gibt es in der Realität natürlich nicht, doch unter Nutzung des Zachman-Frameworks zur Analyse bestehender Probleme und zur Durch-

17 Unterstützung von Architektur-Frameworks in planningit 17 führung zukünftiger Planungen, könnten Organisationen diesem Idealzustand näher gebracht werden. (Quelle: Alex Hoffmann s blog, 21. Oktober 2004) Wie bereits erläutert, werden in planningits umfassendem IT-Inventory sämtliche für die EA relevanten Informationen über ein Unternehmen erfasst. Durch das Meta-Modell wird die Definition von Klassen zur Unterstützung des kontextuellen Aspekts des Frameworks ermöglicht. Alle weiteren Objekte, die zum Business-Modell, dem System-Modell, dem Technologie-Modell sowie zu den detaillierten Darstellungen gehören, werden von planningit einschließlich ihrer Verbindungen zueinander erfasst. So werden die Beziehungen zwischen angrenzenden Zellen im Framework dargestellt. Im Zachman-Framework wird die Tatsache betont, das in einer Unternehmensarchitektur immer mehrere Beteiligte vorkommen. Dies ist ein Aspekt, den auch wir von alfabet berücksichtigen und der von unserer Software planningit durch Bereitstellung unterschiedlicher Views innerhalb der Architektur unterstützt wird. Zachman fördert außerdem eine vollständige Dokumentation der EA sowie die Bedeutung einer Datenbasis, die sich im datengestützten, von planningit verfolgten Ansatz widerspiegelt. Die Prozess-Workflows, die von planningit bereitgestellt werden, dienen Organisationen dazu, die Notwendigkeit der Definition der eigenen Prozesse zur Unterstützung des Zachman- Frameworks, zu umgehen. Sowohl planningit als auch das Zachman-Framework sind aufgrund ihrer umfangreichen Methoden bemerkenswerte Beispiele; was manche Unternehmen wiederum davor zurückschrecken lässt, überhaupt mit einem EA-Programm anzufangen. In beiden Frameworks ist jedoch in jeder Zelle ein Anfang möglich. Dadurch können zunächst die Bedingungen in einem kleinen Schwerpunktbereich verbessert werden und dann Zelle für Zelle (in planningit Prozess für Prozess ) erweitert werden. IEEE Standard 1471 IEEE Standard 1471 ist die Recommended Practice for Architectural Description of Software-intensive Systems. Diese Norm wurde von der IEEE Architec-

18 18 November 2007 ture Working Group mit Unterstützung des IEEE Software Engineering Standards Committee entwickelt und wurde im Oktober 2000 veröffentlicht. Die Norm IEEE 1471 dient der Standardisierung eines Basis-Frameworks für die Inhalte einer Architekturbeschreibung. Eine Architekturbeschreibung ist mit der Norm IEEE 1471 konform, wenn Folgendes dadurch ermöglicht wird: Identifkation der am System Beteiligten und ihrer Architekturanliegen Auswahl und Definition von Viewpoints, um auf solche Anliegen einzugehen Dokumentation der Views auf die Architektur, die den Viewpoints, gerecht werden Aufnahme aller bekannten Inkonsistenzen zwischen Views Begründungen für bestimmte bei der Architekturbeschreibung getroffene Entscheidungen (Quelle: IEEE Standards 1471FAQs, V 4,0) Die Norm IEEE 1471 kann mit anderen Standard-Frameworks kombiniert werden, um bestimmte Inhaltsanforderungen an Architekturbeschreibungen bereitzustellen. Es werden keine eigenen Views, wie im Falle anderer Frameworks, vorgeschrieben, aber dennoch ist das Vorhandensein solcher obligatorisch. Die Norm betrifft keine Prozesse, sondern ausschließlich Inhalte. planningit stimmt insofern mit IEEE überein, als dass sein eigenes Framework auf mehrere Beteiligte und deren Bedürfnisse bei der Arbeit an der Architektur ausgerichtet ist. Da planningit rollenbasiert ist, stehen die entsprechenden Views für alle Beteiligten zur Verfügung. Die Dokumentation der Architektur erfolgt mittels verschiedener Views, wie beispielsweise Business-Architektur, Informationsarchitektur und technische Architektur. Diese sind alle miteinander verbunden, so dass mögliche Inkonsistenzen aufgedeckt und aufgenommen werden können. Sämtliche die Architektur betreffenden Entscheidungen können bis hin zu den Anforderungsaufnahmen, aus denen sie entstanden sind, zurückverfolgt werden. Dabei werden auch die Geschäfts- und IT-Ziele, sowie die Strategien, mit

19 Unterstützung von Architektur-Frameworks in planningit 19 denen sie übereinstimmen, die vollständige Auswertung von Architekturlösungen unter Beachtung anderer aktueller und geplanter Lösungen, andere Architekturen, die von Auswirkungen betroffen sein könnten, Bewertungen, die sich auf unterschiedliche Kriterien stützen, und Business-Cases berücksichtigt. DoDAF Trotz der Anfänge als vorgeschriebenes Framework zur Bestimmung der IT-Akquisitionen des Verteidigungsministeriums der Vereinigten Staaten, fand DoDaf (vormals Bekannt unter der Bezeichnung C4ISR, dem Akronym für Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) häufig auch in anderen Bereichen Anwendung. Es bietet sich insbesondere für die Anwendung in umfangreichen Systemen an, die sich komplexen Integrations- und Kompatibilitätsproblemen stellen müssen. Genau wie in den anderen Frameworks, werden unterschiedliche Viewpoints zur Beobachtung der Unternehmensarchitektur vorgegeben: All View (AV), Operational View (OV), Systems View (SV) und Technical Standards View (TV). Diagramm 5: Das DoDAF-Architektur-Framework besteht aus vier Haupt- Views, die alle problemlos in planningit abgebildet werden können.

20 20 November 2007 Im Viewset All View werden umfassende Beschreibungen der Gesamtarchitektur bereitgestellt und Architekturumfang und -kontext definiert: Umfang, Ziel, vorgesehene Anwender, Umgebungsdarstellung, Analyseergebnisse sowie die Definition aller Begriffe. planningit bietet eine Definition und Klassifizierung aller Architekturartefakte einschließlich der Business- und IT-Ziele und der Strategien, Eigentümer, aktueller und geplanter Business- und ITArchitekturen. Im Viewset Operational View werden die Beschreibungen und die Darstellung der Aufgaben und Aktivitäten, operationalen Elemente sowie den für die Durchführung der DoD-Aufgaben benötigten Informationsaustausch. Missions sind auf Geschäftsaktivitäten anwendbar. In planningit werden detaillierte High-Level-Informationen über Organisationen, Prozesse, Funktionen (Aktivitäten), Objekte (Inputs und Outputs), Standorte, Informationsflüsse im operativen Bereich und ihre Beziehungen zu einander erfasst. Dies sind die Objekte, die in planningits Business-Architektur- und Informationsarchitekturansichten enthalten sind. Im Viewset System View werden graphische und schriftliche Beschreibungen von Systemen sowie Systemabhängigkeiten bereitgestellt, die DoD-Funktionen bereitstellen oder unterstützen. In planningits Applikationsarchitektur werden Applikationen und Services sowie deren Unterstützung der Corporate Mission (Business-Prozesse und Organisationen) erfasst. Im Viewset Technical Systems View werden technische Standards, Implentierungskonventionen, Geschäftsrichtlinien und -kriterien, die die Architektur steuern definiert. Mittels planningits technischer Architekturansicht werden Standardplattformen und Komponenten definiert. Alle Standards verfügen über einen Zeitrah-

21 Unterstützung von Architektur-Frameworks in planningit 21 men und jegliche neue Entwicklungen werden mit den definierten Standards verglichen. Da die Interoperabilität ein Schlüsselelement des DoDAF-Frameworks darstellt, wird dieses durch planningit auf unterschiedliche Art und Weise unterstützt; die grundlegendste davon ist die Erfassung aller im EA-Inventory enthaltenen Objekte im Zusammenhang mit ihren Beziehungen zu anderen Objekten. Dadurch ist die Verlinkung unterschiedlicher Views, wie z.b. der Operational- und System-Views, ein inhärenter Feature von planningit. Dieser Aspekt wird besonders in planningits Bebauungsplan deutlich (siehe Grafik auf der nächsten Seite). Diagramm 6: In planningit werden mittels des Bebauungsplans die Beziehungen zwischen Geschäftsprozessen (auf der horizontalen Achse) und Organisationseinheiten (auf der vertikalen Achse) sowie den unterstützenden Applikationen dargestellt. Föderierte Unternehmensarchitektur (FEA) Vergleichbar mit der Unterstützung, die das DoDAF-Framework hinsichtlich des Erwerbs technischer Ausrüstung zu Verteidigungszwecken leistet, bietet die FEA eine einheitliche Methode für IT-Investitionen der Bundesregierung der Vereinigten Staaten. Hierbei handelt es sich um eine Initiative des Office of Management and Budget in Übereinstimmung mit dem Clinger-Cohen Act.

22 22 November 2007 Die FEA ist eine Sammlung von Referenzmodellen mit einer Klassifizierung und Ontologie zur Beschreibung von Architekturressourcen. planningit unterstützt dieses Framework gemäß der FEA-Referenzmodelle. Die Kennzeichnung der einzelnen Ressourcen und Domänen wie durch die FEA bereitgestellt, kann in planningit ohne Weiteres definiert werden. Diagramm 7: Die föderierte Unternehmensarchitektur nutzt Referenzmodelle, um Architekturelemente in Views anzuordnen. In planningit wurde das Modul Value Management unter derselben Voraussetzung wie das FEA-Performance-Referenzmodell entwickelt. Es dient der Leistungsmessung wichtiger IT-Investitionen und ihres Beitrags zur gesamten Programmleistung. In planningit werden KPIs und Balanced Scorecards sowie verschiedenste Bewertungsschemata genutzt, um verbesserte Leistungsinformationen vorzubringen und dadurch strategische und tägliche Entscheidungsprozesse zu erleichtern (Quelle: Wikipedia, FEA ) sowie Möglichkeiten der Leistungssteigerung zu erkennen, die traditionelle betriebliche Strukturen und Grenzen umfassen. Das Strategieableitungs-Framework und das Capability- Management erleichtern in planningit die Ausrichtung der IT am Unternehmen und bringen eine deutlichere Beschreibung des Beitrags von Inputs für Outputs und Ergebnisse hervor, wodurch eine verbesserte Visierlinie auf die gewünschten Ergebnisse ermöglicht wird.

23 Unterstützung von Architektur-Frameworks in planningit 23 planningits Business-Architektur View entspricht dem FEAF-Business-Referenzmodell (BRM), welches mittels Verfolgung eines funktionsgestützten Ansatzes eine Struktur zur Beschreibung der täglichen betrieblichen Prozesse der Bundesregierung der Vereinigten Staaten bietet. Das BRM begründet die oberste Ebene der FEA und stellt daher den Viewpoint der höchsten Ebene zur Analyse von Daten, Servicekomponenten und der Technologie dar. Im FEA-Servicekomponenten-Referenzmodell (SRM) werden Service-Komponenten gemäß ihrer Unterstützung von Business- und/oder Leistungszielen klassifiziert. Das SRM dient der Ermittlung von Business- und Applikationsservicekomponenten in IT-Investitionen und - Gegenstände im gesamten Unternehmen. Das SRM ist entlang horizontaler und vertikaler Servicedomänen ausgerichtet. Wie der IT-Bebauungsplan in planningit, dienen diese Matrizen der Erkennung von Wiederverwendungsmöglichkeiten von Applikations-Capabilities, Komponenten und Business-Services. Dies ist ein wichtiger Aspekt der SOA-Planung, da so eine Darstellung der Anwendungsbereiche von Applikationen und Services ermöglicht wird und dadurch aufgezeigt werden kann, an welchen Stellen Redundanzen auftreten, welche Wiederverwendungsmöglichkeiten es gibt und wie sie gleichmäßiger gestaltet werden können. Im FEA-Daten-Referenzmodell werden auf aggregierter Ebene Daten und Informationen beschrieben, die die Aufgaben des Programmes der Budnesregierung und operativen Geschäfts unterstützen. Diese Art der Beschreibung findet in der Information Architecture von planningit statt. Das technische FEA-Referenzmodell ist mit dem technischen System-View von DoDAF insofern vergleichbar, als dass es sich hierbei ebenfalls um ein komponentengestütztes, technisches Framework handelt, das zur Kategorisierung von Standards, Spezifizierungen und Technologien genutzt wird, die die zur Verfügungstellung von Servicekomponenten und Capabilities ermöglichen und fördern ; ganz so wie sie in planningits technischer Architektur erfasst werden.

24 24 November 2007 COBIT HIGH LEVEL CONTROL OBJECTIVES Plan and Organize PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 P10 Define a Strategic IT Plan and Direction Define the Information Architecture Determine Technological Direction Define the IT Processes, Organisation and Relationships Manage the IT Investment Communicate Management Aims and Direction Manage IT Human Resources Manage Quality Assess and Manage IT Risks Manage Projects Acquire and Implement A11 A12 A13 A14 A15 A16 A17 Identify Automated Solutions Acquire and Maintain Application SW Acquire and Maintain Tech. Infrastructure Enable Operation and Use Procure IT Resources Manage Changes Install and Accredit Solutions and Changes Deliver and Support DS1 DS2 DS3 DS4 DS5 DS6 DS7 DS8 DS9 DS10 DS11 DS12 DS13 Define and Manage Service Levels Manage Third-Party Services Manage Performance and Capacity Ensure Continuous Service Ensure Systems Security Identify and Allocate Costs Educate and Train Users Manage Service Desk and Incidents Manage the Configuration Manage Problems Manage Data Manage the Physical Environment Manage Operations Monitor and Evaluate ME1 ME2 ME3 ME4 Monitor and Evaluate IT Processes Monitor and Evaluate Internal Control Ensure Regulatory Compliance Provide IT Governance Source: Wikipedia COBIT

25 Unterstützung von Architektur-Frameworks in planningit 25 CoBIT CoBIT ist im eigentlichen Sinne kein Framework, doch viele Organisationen nutzen es als Grundlage für das Management der IT. Wie im Fall von TOGAF, ist planningits prozessorientierter Ansatz zur strategischen IT-Planung und -Verwaltung auch mit CoBIT hoch kompatibel. planningit unterstützt Plan and Organize insofern, als dass: ein Framework zur Erfassung der strategischen IT-Planung, dessen Übermittlung und der Abgleich mit sämtlichen Entwicklungen geboten wird die Informationsarchitektur erfasst wird der Organisation ermöglicht wird, die technologische Ausrichtung durch Bereitstellung eines Frameworks zur Bewertung aller neuen Anforderungen entsprechend der Business-Ziele, Business-Drivers, Business-Anforderungen, technologischen Ziele und Anforderungen und definierter Standards zu bestimmen eine Prozessplattform für die Architekturentwicklung bereitgestellt wird, mittels derer Organisationen und Beziehungen definiert werden der IT-Investitionsprozess samt der Demand to Budget -Methode definiert wird eine gemeinsame Kommunikationsplattform für alle Beteiligten bereitge stellt wird es die Verwaltung von Projekten und IT-Personal unterstützt, welches korrekte IT-Vorhaben und deren Vorbereitung bereitstellt Unterstützung hinsichtlich der IT-Qualität geboten wird, indem für eine intakte Architekturbasis sowie für eine Ausrichtung der IT-Investitionen an den Business-Zielen gesorgt wird Diagramm 8: planningit unterstützt CoBITs High Level Control Objectives Plan and Organize und Monitor and Evaluate

26 26 November 2007 Monitor and Delivery wird insofern unterstützt, als dass: alle neuen Anforderungen für Änderungen an der Architektur mit (ständig aktualisierten) Business-Zielen, Treiber und - Anforderungen verglichen werden es als Framework zur effizienteren Bewertung der Compliance dient es Strukturen und Beziehungen beschreibt, die die IT-Unterstützung eines Unternehmens darstellen und dabei die benötigte Abstrahierung und Aggregation der Informationen zur Governance-Zwecken wie z.b. Finanz- oder Risikosteuerung ermöglicht Für die vollständige Abdeckung von CoBIT und ITIL kann planningit in andere Produkte integriert werden. ITIL Das Information Technology Infrastructure Library -Framework dient der IT- Service-Delivery. Es handelt sich hierbei um eine Sammlung von Büchern, die vom Office of Government Commerce, einer britischen Regierungsorganisation, veröffentlicht wird. Zur Verwaltung von ITOperationen wird ein prozessorientierter Ansatz verfolgt. Von den durch ITIL beschriebenen Disziplinen wie Service-Unterstützung, Service-Delivery, Implementierungsplanung des Service-Managements, ICT- Infrastrukturmanagement, ICT-Entwurf und -Planung, Business-Perspektiven, Applikationsmanagement und Software-Asset-Management werden die durch Fettdruck hervorgehobenen in planningit unterstützt. Bereiche, die in ITIL das Operative zum Gegenstand haben, wie die Verwaltung von Störungen, Problemen oder Änderungen, die von speziellen Tools der CMDB-Umgebung abgedeckt werden, sind daher kein Schwerpunkt von planningit. ICT-Infrastrukturmanagement umfasst Anforderungsanalysen, Planung, Entwurf, Installation und aktuelles Operations-Management sowie technische Unterstützung. Durch planningit werden Anforderungsanalysen, Planung und Entwurf im Demand to Budget - Workflow abgedeckt; angefangen mit einer strengen Bewertung jeder eingereichten Anforderung bis hin zur Entscheidung hinsichtlich dessen Installation.

27 Unterstützung von Architektur-Frameworks in planningit 27 ICT-Entwurf und Planung kombiniert Business-Strategien mit technischen Entwürfen und Planungen. Dieser Aspekt wird auch durch den Demand to Budget -Prozess abgedeckt, in dem Investitionen mit Statements of Requirements (ITIL) verknüpft werden und somit eine Basis für Angebote bereitgestellt wird. Dies ist der für die Initiierung und Verwaltung von Programmen zur strategischen Veränderung des Unternehmens definierte Prozess. Gemäß The Business Perspective, werden Best Practices in planningit wie folgt unterstützt: Business Continuity Management : An den Business-Manager gerichtete Beschreibung der Möglichkeiten zur Verbesserung der IT-Unterstützung im Sinne einer Steigerung der Effizienz und Effektivität des Unternehmens Change Management : Zur Sicherstellung, dass der Business-Manager über Änderungen und deren mögliche Auswirkungen auf das Unternehmen informiert ist Umgestaltung des Geschäftskonzepts mittels tief greifender Änderungen: Unterstützung der IT-Kontrolle und der Integration der IT in das Unternehmen Partnerschaften und Outsourcing mittels Bereitstellung einer gemeinsamen Informations- und Kollaborationsplattform. Das Software-Asset-Management zielt darauf ab, dass die IT, in die das Unternehmen investiert hat, so gut wie möglich ausgenutzt wird. Zu diesen Assets zählen die gesamte Infrastruktur sowie die zur effizienten Verwaltung, Kontrolle und zum Schutz der angeschafften Software innerhalb einer Organisation notwendigen Prozesse; und zwar während aller Lebenszyklusstadien. In diesem Whitepaper wurde bereits ausführlich erläutert, wie dieser Aspekt in planningit umgesetzt wird. Zusammenfassung Es lässt sich feststellen, dass trotz der Tatsache, dass in jedem Architektur- Framework unterschiedliche Schwerpunkte gesetzt werden, dennoch stets wiederkehrende Themenstellungen auftauchen:

28 28 November 2007 Die Übereinkunft, dass die Architektur nicht nur die eigentliche technische Struktur ist, sondern vielmehr eine Darstellung der Funktionsweise des Unternehmens. Unterschiedliche Views, die verschiedene Beteiligte repräsentieren Die Gleichrichtung von Geschäftszielen und IT-Programmen Die Notwendigkeit des Vorhandenseins vollständiger Informationen Die Notwendigkeit verschiedener Risikobewertungen (Auswirkungsanalyse, Kostenanalyse, etc.) Durch diese Gemeinsamkeiten wird deutlich, dass eine eingehende Prüfung der einzelnen Frameworks bei der Auswahl eines solchen kaum lohnt. Für die Auswahl eines Frameworks empfiehlt Forrester, das Framework auszuwählen, dass: den anderen Anwendern in Ihrem Unternehmen einfach zu erklären ist. Das EA-Framework sollte sowohl für die an der IT direkt beteiligten als auch für alle Übrigen als Mittel zur Kommunikation dienen. Das Framework sollte ferner sowohl für die Architekten als auch für andere Anwender, einschließlich der Projektmanager, der CIOs, der Entwickler und Business-Analysten, leicht wiederzuverwenden sein. Sie Ihren organisatorischen Bedingungen exakt anpassen können. Dies gilt insbesondere für föderierte Organisationen, in denen die Abdeckung des EA-Frameworks entsprechend unterschiedlicher Grenzen und Verantwortlichkeiten einzelner Architektengruppen besonders wichtig ist. In diesem Fall ist es ratsam, die einzelnen Beteiligten in den Entscheidungsprozess mit einzubeziehen, um das EA-Framework gemeinsam auszuwählen. sich an die EA-Ziele im Laufe der Zeit anpasst. Es wäre falsch, das EA-Framework nur auf Grundlage langfristiger Anforderungen auszuwählen und zu modellieren. Unternehmen sollten ebenfalls kurz- bis mittelfristige Ziele berücksichtigen und die inhaltliche Entwicklung des EA-Frameworks von diesen steuern lassen * (*Quelle: EA Frameworks are Mainstream, but the Landscape Remains Diverse, Henry Peyret, Forrester, 26. Juli 2006)

29 Unterstützung von Architektur-Frameworks in planningit 29 Über planningit planningit unterstützt IT-Organisationen bei der Anzeige, Analyse und Kontrolle von IT-Projektvorhaben sowie bei deren Ausrichtung am Business. Diese modulare, skalierbare Lösung unterstützt alle Business-Tätigkeiten im Planungsprozess angefangen bei der Anforderung bis hin zum Budget. planningit umfasst: Logical IT Inventory Das Logical IT Inventory erfasst die Ist-Landschaft mit ausreichenden Details, um jedes IT-Projekt oder jede Planungsaufgabe zu unterstützen. Business Demand Management Das Modul Business Demand Management erfasst die Anforderungen nicht nur im Kontext ihrer technischen oder strategischen Ausrichtung, sondern auch ihrer zugehörigen Architekturobjekte, so dass die Anforderungen leicht miteinander verglichen und in Vorhaben konsolidiert werden können. Application Architecture Management Das Modul Application Architecture unterstützt die detaillierte Analyse der Ist- und Soll-Architekturen, und wird für die Entwicklung und den Vergleich von Soll-Szenarien für definierte Projektvorhaben, die Durchführung von Gap- Analysen und die Vorbereitung von Migrationsplänen verwendet. Enterprise Architecture Management Das Modul Enterprise Architecture Management wird verwendet, um Unternehmensstandards und -richtlinien zu definieren und um die Übereinstimmung mit den Standards zu gewährleisten. Enterprise Strategy and Master Planning Das Modul Enterprise Strategy and Master Planning wird für die Analyse und Bewertung des Applikationsportfolios (Redundanzen, Kosten und Nutzungsebenen), für die Konsolidierung lokal entwickelter Soll-Architekturen sowie für die Erstellung eines ITMasterplans verwendet.

30 30 November 2007 Program Portfolio Management Das Modul Program Portfolio Management wird für die Zuweisung definierter Projekte zu Programmen und für die Durchführung von Bottom-up- und Topdown-Analysen von Budgets und Programmen genutzt. Value Management Das Modul Value Management wird verwendet, um Business- und IT-Strategien zu dokumentieren und anzupassen und um KPIs, Rollen und Projektbewertungskriterien zu definieren und zuzuordnen. Release Management Das Modul Release Management dient zur Ableitung von operationalen Anweisungen für die Implementierung und für die Kommunikation mit CMDBs aus genehmigten Lösungsplänen.

31 alfabet AG, 1997 in Berlin gegründet, entwickelt und vertreibt mit planningit die erste integrierte Standardsoftware für eine automatisierte Unterstützung der IT-Planungsprozesse. Das Unternehmen bedient derzeit IT-Anwender aus den Branchen Automobil-, Finanzdienstleistungen-, Telekommunikation-, Energiewirtschaft-, Chemische-, Transport & Logistik und Tourismus Industrien. Zu den Kunden der alfabet AG gehören multinationale Konzerne wie Credit Suisse, Münchener Rück, BMW, AXA Winterthur, Deutsche Bahn, OCBC und T-Systems hat Gartner alfabet zum Cool Vendor im Enterprise Architecture Bereich ernannt und Forrester bezeichnete planningit von alfabet als das beste EA-Tool für das Change Management. EMEA Head Office alfabet AG Leibnizstraße 53, D Berlin T US Head Office alfabet Inc. One Broadway, CIC 14 th floor, Cambridge MA T APAC Head Office alfabet 16 Collyer Quay, #10-00 Hitachi Tower, Singapore T