MANAGEMENT VON IT ARCHITEKTUREN

Transkript

1 Westfälische Wilhelms Universität Münster MANAGEMENT VON IT ARCHITEKTUREN WORKFLOWS UND INITIALISIERUNG DER ARCHITEKTURENTWICKLUNG Ausarbeitung im Rahmen des Seminars: Software Management von Alexander Serowy Themensteller: Prof. Dr. Herbert Kuchen Betreuerin: Susanne Gruttmann Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 INHALTSVERZEICHNIS Abbildungsverzeichnis... II Tabellenverzeichnis... III 1 Architekturintegration in Unternehmen Architekturen in Unternehmen Nutzen für Unternehmen Treiber und Hindernisse Initialisierung der IT Architekturentwicklung Rahmeneinordnung in das Gesamtkonzept Workflow der Initialisierung Rollen im Workflow Eigenschaften und Ablauf Mögliche Problemfelder Schlussteil Glossar... A Anhang... C Activity Diagramm: Workflow Initialisierung Architekturentwicklung... C Activity Diagramm: Beschreibung der Aktivitäten nach Dern... D Literaturverzeichnis... F I

3 ABBILDUNGSVERZEICHNIS Abbildung 3.1: Prozesskette Einleitung und Umsetzung einer Architektur... 9 Abbildung 3.2: Rollen im Workflow Abbildung 3.3: Workflow Initialisierung Architekturentwicklung Abbildung 3.4: Abgrenzung im Acitivity Diagramm Abbildung 3.5: Auftragsklärung im Activity Diagramm Abbildung 3.6: Planung im Activity Diagramm II

4 TABELLENVERZEICHNIS Tabelle 2.1: Treiber und Hemmnisse für IS Strategieprozesse... 6 III

5 1 ARCHITEKTURINTEGRATION IN UNTERNEHMEN Die Integration von IT ist in heutigen Firmenstrukturen kaum mehr weg zu denken. Jedoch leiden viele Unternehmen unter schlechter Umsetzung, kurzfristiger Planung und dem daraus resultierenden geringen Handlungsspielraum. Aus diesen Gründen werden IT Architekturen immer wichtiger, da Flexibilität erreicht werden kann wo sie gebraucht wird. Trotz den Vorteilen, die Architekturen mit sich bringen können, und die damit verbunden Chancen sich wirtschaftlicher und reaktiver am Markt positionieren zu können, scheitern viele Architekturumsetzungen in Unternehmen. Es stellte sich die Frage nach Gründen, warum, trotz diverser Möglichkeiten Architekuren in die eigene Struktur zu integrieren und nicht bei null anfangen zu müssen, viele Unternehmen den Weg scheuen neue Denkweisen und Technologien aufzunehmen. Auf der einen Seite bedeutet dieser Weg natürlich große Veränderungen und kann so zu einer vorrübergehend großen Belastung des Unternehmens führen. Auf der anderen Seite jedoch gibt es viele Versuche, die mit guten Ansätzen anfingen, dann aber nicht konsequent umgesetzt wurden. Diese Inkonsequenzen mussten unternehmensinterne Gründe haben, da durch die Vielzahl der Fälle externe Einflüsse ausgeklammert werden konnten. Ein Lösungsversuch stellte DERN durch die entwickelten Workflows vor, die von dem Erkennen der Notwendigkeit bis hin zur Umsetzung der Architekturentwicklung Struktur in die Einführung bringen sollen. Da in seiner Arbeit jedoch nicht explizit auf Probleme und deren Lösung innerhalb der Workflows eingegangen ist, wird in diesem Paper eine Analyse anhand eines einzelnen Workflows versucht, um gegebenenfalls Schwachstellen und Verbesserungsvorschläge geliefert werden können. 1

6 Als Grundlage für die Treiber und Hemmnisse wird der Nutzen von Architekturen im Allgemeinen erklärt, um Erwartungshaltungen der Unternehmen gegenüber dieser Strukturen nachvollziehen zu können. Danach wird direkt auf Hindernisse eingegangen, die durch Umfrageergebnisse anderer Autoren nachgewiesen werden konnten. Es stellte sich heraus, dass die Hindernisse in drei grobe Problemfelder eingegliedert werden können: Mangelnde Topmanagementunterstützung, Probleme mit der IS /IT Strategie und die Organisationsstruktur der Architektur. Als nächster Schritt wird als kleine in DERNS Workflows die Rahmeneinordnung des Initialisierungsprozesses erörtert. Die anschließende Analyse des Workflows Initialisierung Architekturentwicklung wird in zwei Teile untergliedert. Im ersten Teil werden die beteiligten Rollen erläutert und anhand deren Sichten und Aufgaben analysiert. Der zweite Schritt befasst sich mit dem eigentlichen Ablauf des Prozesses. Die Analyse findet im Rahmen des Activity Diagramms von DERN statt. Abschließend werden die behandelten Problemfelder nochmals aufgegriffen und nicht lösbare Hindernisse herausgearbeitet. Darüber hinaus wird versucht für bestimmte Probleme Lösungsanstöße zu liefern, um diese innerhalb der Workflows oder aber extern zu realisieren. Im Schlussteil werden weitere von dem Grundgedanken dieses Papers ausgehende Arbeiten vorgeschlagen, um die Konsistenz und Nachhaltigkeit des Gesamtkonzepts der Workflows herausarbeiten zu können. 2

7 2 ARCHITEKTUREN IN UNTERNEHMEN In diesem Abschnitt wird erläutert, warum Architekturen in Unternehmen Einzug finden und auch Bestand haben. Es wird verdeutlicht, welche Chancen sich durch die Einführung und Umsetzung einer Architektur für das Unternehmen ergeben. Im Anschluss wird herausgestellt, mit welchen Herausforderungen die Initialisierung verknüpft sind, die von den Beteiligten für eine sinnvolle Integration und Weiterentwicklung einer IT Architektur gelöst werden müssen. Darüber hinaus werden kurz Lösungsansätze gegen einige Hindernisse skizziert. 2.1 NUTZEN FÜR UNTERNEHMEN Grundlegend für die Umsetzung einer Architektur ist die Chance Risiken bei tiefgreifenden Veränderungsprozessen im Unternehmen zu minimieren, da eine vereinfachte Planung dieser Prozesse ermöglicht wird. Weiterhin wird auf den Ebenen Geschäftsprozesse, Applikationen und Technologien die Komplexität für langfristige Handlungsoptionen gesteuert. 1 Diese Vorgaben können auf Teilziele herunter gebrochen werden, die im Speziellen bei richtiger Umsetzung positiv auf die Effizienz und Flexibilität des Unternehmens wirken. Die Ausrichtung der IT Strategie an die Unternehmensstrategie kann das Erreichen der geforderten Geschäftsziele durch IT Lösungen adäquat unterstützen. Es wird ein größerer Handlungsspielraum in der Umsetzung der Applikationslandschaft geschaffen und in speziellen Fällen sogar eine Reduktion der Landschaft herbei geführt, die kostensenkend wirken. Die Einführung von Standards, Diensten und Richtlienen schafft eine allgemeine begriffliche Basis für die oben angesprochenen Veränderungsprozesse und ermöglicht darüber 1 Dietzsch,

8 hinaus nachhaltiges Business Process Management. 2 Damit einher geht die systematische Dokumentation aller Elemente und deren Wechselwirkungen mit der Unternehmensarchitektur 3, welche auch entscheidend ist, um Konflikte zwischen verschiedenen Interessengruppen zu ermitteln und diesen entgegenwirken zu können. Aufgrund dieser Basis kann durch die Speicherung grundlegender Informationen über das eigene Informationssystem vorausschauend und somit sinnvoll in diesen Bereich investiert werden. 4 Entscheidend für das Erreichen der oben genannten Ziele der Architektur in einem Unternehmen ist die Akzeptanz der Mitarbeiter, das Bestehen von Definitionen der entscheidenden Prozesse und weiterhin auch deren Anwendung. Die Wirksamkeit hängt außerdem vom Umfang der Architektur im Unternehmen ab und ist deshalb bei einer unternehmensweiten Umsetzung am stärksten TREIBER UND HINDERNISSE Wie im Unterkapitel Nutzen für Unternehmen beschrieben, ist die Ausrichtung der IT Stratgie an die Unternehmensstrategie grundlegend. Leider besteht schon hier ein Problem sinnvolle Ziele für die Zielarchitektur zu erarbeiten. Viele Unternehmen sind nicht in der Lage konkrete Ziele zu formulieren, die über eine beeindruckende Bandbreit von allgemein gehaltenen hohlen Phrasen hinaus gehen und in einen konsistenten Ablaufplan zu überführen. Sollte ein solcher Ablaufplan existieren, kann ein Schlüsselleitmotiv für IT bzw. IS Investitionen aus Unternehmenssicht abgeleitet werden, um mit dem Topmanagement abgestimmt Unternehmensziele zu verwirklichen. 6 Eine grundlegende Voraussetzung für die Umsetzung der IS und IT Strategie ist, nach LEDERER UND MENELOW, die Unterstützung durch das oben erwähnte Topmanagement. In einer Studie über Treiber und Hemmnisse von 2 Göransson, et al., Knackstedt, et al., Dietzsch, Dietzsch, Ward, et al.,

9 IT Architekturintegration in 20 Unternehmen in den USA wurden fünf Faktoren von ihnen ermittelt, die, vom Topmanagement ausgehend, eine sinnvolle Umsetzung verhinderten. Häufig war das Management über die Wirkung und die strategischen Vorteile im Unklaren und darüber hinaus wurde nur der riesige Abstand zwischen den teils illusorischen Vorstellungen und der Wirklichkeit festgestellt. Auch wenn Nutzen festgestellt worden war, wurde dennoch oft eine direkte finanzielle Auswirkung erwartet oder Information nicht als Langzeitinvestition gesehen. Auf der anderen Seite stand vielfach die Ausrichtung des Managements der Umsetzung im Wege, da ein kurzzeitiger Firmenfocus gerade bei IS und IT eine langfristige Planung verhinderte. 7 TEO UND ANG stellten weitere Kriterien auf, die über die Managementunterstützung hinaus gingen. Sie teilten den Integrationsprozess in drei Phasen auf die Einführungsphase, die Planungsphase und die Implementierung und ermittelten für die ersten beiden grundlegende Probleme (siehe Tabelle 2.1). In der ersten Phase sind eingeschränkte Kommunikationsabläufe und das Fehlen von Fachpersonal fundamentale Problemstellungen gewesen. Die Planungsphase wurde durch das Vernachlässigen von Unternehmenszielen bzw. durch Transformationen in falsche Ablaufpläne und die mangelnde Einbeziehung von Akteuren nachhaltig beeinträchtigt. 8 Der zweite große Problembereich ist die Ausrichtung der IS und IT Strategie an die Unternehmensstrategie. Hier stellten LUFTMAN UND BRIER in ihrer Studie entscheidende Treiber und Barrieren heraus. Es zeigte sich, dass sowohl das Verständnis der IT vom Unternehmen, die Unterstützung durch die Exekutive als auch die IT Unternehmensbeziehung fördernd, aber auch hindernd auf die Ausrichtung gewirkt haben. 9 7 Lederer, et al., Teo, et al., Ward, et al.,

10 Problems in launching the IS strategy process 1. Failing to get top management support 2. Not having free communication and commitment to change throughout the organization 3. Being unable to obtain sufficiently qualified personal to do a proper job 4. Delegating responsibility to an individual without sufficient experience, influence or time to do a thorough job 5. Not investing sufficient front end time to ensure that all strategy and planning tasks and individual responsibilities are well understood 6. Not having a steering committee that is highly committed 7. Not having a clear cut business strategy to guide the IS strategy effort 8. Failing to anticipate new developments in IT that might affect the strategy 9. Ignoring the people and politics side of strategy formulation and planning Problems with the IS strategy process 1. Failing to involve top management sufficiently 2. Ignoring business objectives 3. Failing to translate business objectives and strategies into action plans 4. Failing to involve users sufficiently 5. Relying exclusively on user wish lists for application ideas 6. Neglecting to assess realistically internal weaknesses of the IS function in determining capabilities to implement the recommended strategy 7. Not performing a top down analysis to identify critical functional areas that the IS strategy has to support 8. Failure to consider and explicitly evaluate alternative IS strategies in order to give top management a meaningful choice 9. Failing to review the IS strategy with all managers so as to obtain support and cooperation for its implementation Tabelle 2.1: Treiber und Hemmnisse für IS Strategieprozesse 10 Weiter können zwei unterschiedliche Herangehensweisen an die Wirkungsweise der IT Architekturen unterschieden werden: Auf der einen Seite steht die passive Organisationsstruktur, in der versucht wird über die Formulierung von Vorgaben auf Projekte im Bereich der Informationstechnik Einfluss zu nehmen. Die daraus folgenden Ergebnisse werden nicht in Zusammenarbeit mit der Architektur geschaffen, sondern werden im Anschluss lediglich mit den Vorgaben in Form von Richtlienen, Standards und Strategien beurteilt, ob eine Umsetzung in diesem Rahmen stattgefunden hat. In dem Beispiel von DIETZSCH, der die schweizerische Mobiliar in ihrer IT Architekturbildung begleitet hat, werden die klaren Schwächen heraus gestellt. Im Großteil findet nur eine geringe Verankerung der IT Strategie in den Projekten statt und verhindert so eine an die Bedürfnisse der Nutzer ausgerichtete Architektur. Es folgt mangelnde Akzeptanz und im Endeffekt ein Scheitern des Architekturansatzes Teo, et al., Dietzsch,

11 Die aktive Organisationsstruktur versucht hingegen direkt am Gestaltungsprozess vorausschauend und nachhaltig mitzuwirken. Darüber hinaus sollen Projekte auch in ihrer Lösungsfindung und Umsetzung unterstützt werden. Dabei muss dafür gesorgt werden, dass geschaffene Artefakte architekturkonform umgesetzt und projektübergreifend ausgerichtet sind, um die Nachteile der passiven Lösung zu verhindern. Außerdem muss eine starke Anwenderbezogenheit realisiert werden, um die Architektur in dem Unternehmen zu positionieren. Diese, mit der Unternehmensstrategie einhergehende, Ausrichtung muss dem Anwender Leistungen zum geforderten Zeitpunkt in geforderter Qualität bereit stellen, um eine hohe Akzeptanz im Unternehmen zu bewerkstelligen. 12 Die Nachteile der aktiven Struktur liegen in der Projektbezogenheit, die zu einer Architektur aus lokal optimierten Einzelelementen führen kann. Um diesem Problem entgegen zu wirken, ist eine Einteilung des Weges zur Zielarchitektur notwendig. Diese Zeitscheiben bilden die schrittweise zu erreichenden Soll Architekturen ab, die richtungsweisend für die Projekte sein sollen und als Meilensteine zu verstehen sind. In Ausnahmen können natürlich Projekte auch ohne Ausrichtung realisiert werden, wenn bestimmte Grundannahmen realisiert werden können. Der wirtschaftliche Nutzen solcher Konzepte muss trotz Realisierung, Betrieb und Entsorgung gegeben sein, damit die Verwirklichung neben dem laufenden Tagesgeschäft sinnvoll ist. 13 Weiter müssen die gebildeten Soll Architekturen Inkonsistenzen zwischen dem Planungshorizont und dem jeweiligen Ist Zustand durch Evolutionsvorgaben in Form von Zeitplänen entgegenwirken, damit ein Stocken des Fortschritts verhindert werden kann. Genauso kann das Streben nach einer vollkommenen Architektur bzw. nach riesigen Projekten eine Analyse Paralyse 14 auslösen, die nur durch eine schrittweise Entwicklung und Einbindung durch Architekturteile gelöst werden kann. 12 Dietzsch, Dietzsch, Dietzsch,

12 3 INITIALISIERUNG DER IT ARCHITEKTUR ENTWICKLUNG Nachdem das Warum?, das Wie? und das Wie nicht? auf allgemeiner Ebene erläutert wurde, wird in diesem Abschnitt der Arbeit eine Übertragung auf den Prozess der Initialisierung einer Architekturentwicklung nach DERN vorgenommen. Es wird versucht, diesen Prozess auf Grund der oben genannten Grundlagen zu erklären und gegebenenfalls Schwachstellen aufzuzeigen. Im ersten Teilabschnitt wird der Initialisierungsprozess in den Gesamtrahmen von DERN eingeordnet. Es wird erläutert, durch welche Prozesse die Initialisierung ausgelöst wird und welcher Verlauf nach diesem Schritt folgt. Der zweite Teil befasst sich dann mit dem eigentlichen Prozess der Initialisierung und dessen Beschreibung, bewertet mit den Ergebnissen aus dem Kapitel Architekturen in Unternehmen. Dabei findet eine Aufschlüsselung des Rollenmodells und dem Activity Diagramm statt. 3.1 RAHMENEINORDNUNG IN DAS GESAMTKONZEPT Veränderungen im Umfeld eines Unternehmens oder steigende Anforderungen bedingen häufig auch interne Anpassungen der Unternehmensstruktur. Der Workflow Analyse und Planungs IS Portfolio analysiert solche Veränderungen und löst bei Notwendigkeit größerer Anpassungen der IS Architektur beziehungsweise der übergreifenden Architekturplanung den Workflow Übergreifende Architekturplanung aus. Entscheidende Vorgaben sind geschäftliche und technische Anforderungen sowie Unternehmenstreiber. Bei Auslösung wird dem folgenden Workflow das IS Portfolio übergeben. 8

13 Abbildung 3.1: Prozesskette Einleitung und Umsetzung einer Architektur Mittels den Anforderungen, Innovationen und dem IS Portfolio wird in der übergreifenden Architekturplanung ein angepasstes Projektportfolio erarbeitet, dass sowohl in den angepassten Planungen der Infrastruktur und der Architektur als auch in dem Auftrag der Architekturentwicklung resultiert. Nachdem der Entwicklungsauftrag ausgearbeitet und beschlossen wurde, wird der Workflow Initialisierung Architekturentwicklung gestartet. Durch Architekturplanung, Architekturkonfiguration und das Architekturszenario wird nun ein Architektur Outline erarbeitet, um die Ziele des Soll Portfolios zu bestimmen und den Rahmen der weiteren Schritte im Workflow Architekturentwicklung festzulegen. Der letzte Schritt stellt die eigentliche Umsetzung der IT Architektur dar. Ausgehend von den Ergebnissen der Initialisierung erfolgt die Entwicklung der Architektur in iterativen Zyklen, die auf konzeptioneller, logischer und physischer Ebene statt finden WORKFLOW DER INITIALISIERUNG ROLLEN IM WORKFLOW Die Initialisierung des Entwicklungsprozesses kann als ein Zusammenspiel mehrerer Akteure verstanden werden. Um bestimmte Fehler, wie im Kapitel Architekturen in Unternehmen beschrieben, zu verhindern, wird von Anfang 15 Dern,

14 an eine direkte Einflussnahme des Managements fokussiert und findet durch das Architektur Board, das als Steuerungseinheit und Entscheidungsgremium wesentlich an der Gestaltung der Initialisierung mitwirkt, statt. Durch die starke Einbindung der Architektur in den Gestaltungsprozess kann darüber hinaus auch auf eine aktive Organisationsstruktur geschlossen werden, die wesentliche Vorteile gegenüber der passiven Struktur besitzt. Abbildung 3.2: Rollen im Workflow 16 Weiter wird durch die Rollen IT Architekt auf Unternehmensebene und Service Manager sichergestellt, dass durch die Einbindung der übergreifenden Sichten auch das Problem der lokalen Optimierung ansatzweise verhindert werden kann, indem die Umsetzung im intersubjektiven Rahmen aufgehoben wird. Dabei bringt der IT Architekt die Sicht der übergreifenden Architektur und der Service Manager die übergreifende Sicht der IT Basisinfrastruktur in den Prozess mit ein Dern, Dern,

15 Die Rollen Projektleiter, Business Architekt und IT Architekt auf Projektebene bilden den Gegenpart zur übergreifenden Sicht. Sie repräsentieren die projektbezogene Sicht. Im Speziellen ist der Projektleiter für die Steuerung der Entwicklung des Informationssystems und der Business Architekt für die Definition der Business Anforderungen verantwortlich. Der IT Architekt auf Projektebene fügt dann die Anforderungen beider Sichtweisen zusammen und bildet auf Grundlage dieser Anforderungen die Architektur zum Informationssystem. Die jeweiligen Architektenrollen können, um dem Fehlen von ausreichend qualifiziertem Personal entgegen zu wirken, durch externe Ressourcen gedeckt werden. Die rollenbasierte Aufgabe der Initialisierung besteht darin, die Ziele, die Abgrenzung, das Vorgehen und die Planung zu akkreditieren. 18 Es kommt zu einem allgemein akzeptierten Zustand, der im weiteren Verlauf der Umsetzung der Architektur akzeptanzschaffend wirken kann und so die Architektur im Unternehmen besser positioniert werden kann EIGENSCHAFTEN UND ABLAUF Der Workflow Initialisierung Architekturentwicklung nach DERN kann in drei Schritte unterteil werden. Im ersten Schritt, der Abgrenzung, findet die Beschreibung und Abstimmung des Soll Zustandes statt. Dieser wird aus den Anforderungen, den überprüften und ergänzten Szenarien aus dem Prozess Übergreifende Architekturplanung, der bestimmten Risiken und den ermittelten kritischen Erfolgsfaktoren zusammen gesetzt. Die Anforderungen setzen sich wiederum aus den Anforderungen des Projekts, der festgelegten Architekturkonfiguration und aus Anforderungen, die sich aus Sicht der Architektur und der Infrastruktur ergeben, zusammen. 19 Der zweite Schritt Auftragsklärung beschreibt die Ziele und Wege für deren Nachweis. Der Sollzustand geht als Grundlage in die Auftragsdefinition ein und wird durch Ziele der übergreifenden Sicht und der Entwicklungsprozesssicht erweitert. Um Interessenskonflikten vorzubeugen, wird der Auftrag zusätzlich 18 Dern, Dern,

16 um ein Organisations und Kommunikationskonzept und um einen Entwurf der Architekturreleaseplanung erweitert. Der Entwurf der Releaseplanung wird in diesem Rahmen an den Planungsentwurf des jeweiligen Softwareentwicklungsprojektes ausgerichtet. Der resultierende Auftrag wird schlussendlich vom Architekturboard abgesegnet. Gleichzeitig wird die Rolle des Auftragnehmers dem IT Architekten auf Projektebene zugeteilt. 20 Abbildung 3.3: Workflow Initialisierung Architekturentwicklung 21 Im letzten Schritt, der Planung, wird der Entwurf der Architekturreleaseplanung zusammen mit dem der Softwareentwicklung vervollständigt. Es wird der Umfang des Architekturreleases festgelegt und in definierten Meilensteinen des Softwareprojektes dem Workflow Analyse und Design zur Verfügung gestellt. Unter Zuhilfenahme von sinngebenden Sichten werden Schwerpunkte des Releases gebildet und Aktivitäten und Artefakte fixiert, die für die Architekturentwicklung grundlegend sind. Darüber hinaus wird festgelegt, auf welche Weise Change Requests an die Architektur erhoben und bearbeitet 20 Dern, Dern,

17 werden. Mittels dieser Teilergebnisse kann nun die Grundstruktur des Architektur Outline definiert werden. Es entsteht ein konsistenter Überblick über die Kernfakten der Architekturentwicklung aus Planungs und Anforderungssicht, der zum Schluss vom Auftraggeber abgenommen werden muss. 22 Um die Eigenschaften des Workflows in Bezug auf Treiber und Hemmnisse der Einführung von Architekturen zu ermitteln, werden im Folgenden die drei oben genannten Phasen anhand von Auszügen aus dem Activity Diagramm erläutert und analysiert. Das vollständige Diagramm ist im Anhang zu finden und notwendig um die Zusammenhänge der einzelnen Detailaufnahmen nachvollziehen zu können. Abbildung 3.4: Abgrenzung im Acitivity Diagramm 23 Wie in dem Auszug verdeutlicht wird, ist schon in der Abgrenzungsphase ein starker Einbezug des Managements (3. Spalte) in Form des Architektur Boards vertreten. Das Stellen von interdependenten Anforderungen der Infrastruktur und des Managements und die Abstimmung über die erarbeiteten Resultate sind grundlegende Kontrollmöglichkeiten, um die fehlende Unterstützung des Managements durch Mitbestimmung zu verhindern oder diese direkt in einem der ersten Schritte der Umsetzung von IT Architekturen aufzudecken. Außerdem werden durch das Ermitteln von kritischen Erfolgsfaktoren und Risiken dem Management wichtige Kennzahlen geliefert, die ebenfalls ein höheres Maß an Unterstützung ermöglichen. Weiter verhindern die Anforderungen aus Infrastruktur und Softwareentwicklung (2. Spalte) eine 22 Dern, Dern,

18 mangelnde Ausrichtung an strukturellen Voraussetzungen und Nutzerforderungen. Durch den erhöhten Grad der Kundenausrichtung resultiert somit eine höhere Akzeptanz und Nutzungsbereitschaft gegenüber der Architektur im Unternehmen. Mittels der Beschreibung des Soll Zustandes wird frühzeitig für ein begrenztes Leitmotiv der Entwicklung gesorgt, das als Meilenstein auf dem Weg zur Zielarchitektur gesehen werden kann und in einer klaren Ausrichtung auch im späteren Verlauf der Umsetzung resultiert. Abbildung 3.5: Auftragsklärung im Activity Diagramm 24 Auch in dieser Phase findet ein starker Einbezug des Managements in Form des genehmigenden Gremiums, dem Architektur Board (3. Spalte), statt. Es wird über den Start der Architekturentwicklung oder über eine Neuentwicklung des Auftrags entschieden. Dieser gegebenenfalls iterative Vorgang ist von grundlegender Bedeutung, da im Endeffekt dem Management eine Auswahl von verschiedenen Umsetzungsmöglichkeiten eingeräumt werden kann. Ein weiteres Problem beschreibt die Einhaltung der Strategie der IT Architektur. Die Auftragsdefinition vereint die übergreifende und die projektbezogene Sicht, ermöglicht so die Gegenüberstellung beider und zeigt die mögliche Gleichausrichtung der Sichten. Darüber hinaus sorgt die Festlegung des Organisations und Kommunikationskonzepts für klare Strukturen und fördert so ein effizientes Arbeiten. 24 Dern,

19 Abbildung 3.6: Planung im Activity Diagramm 25 Im entscheidenden Schritt wird das Management wieder als letzte Instanz in den Prozess der Initialisierung eingebunden. Die Architektur Release Planung wird weiter verfeinert und geht schlussendlich als Projektplanung in das Architektur Outline ein, welches als Entwurf dem Architektur Board übergeben wird. Mit der Aktivität Auswahl Aktivitäten und Artefakte werden die Architektur Entwicklung Workflows auf die Aktivitäten und Artefakte überprüft und gegebenenfalls reduziert. Dies resultiert in einer möglichen Vereinfachung des Entwicklungsprozesses und somit in einer höheren Nachvollziehbarkeit, wodurch die Effizienz bei Anwendung erhöht werden kann. Zusammenfassend ist eine hohe Beteiligung des Managements gegeben, welches in ein leitendes Komitee eingebunden ist. Über Anforderungen und Spezifikationen kann indirekt von späteren Nutzern auf die Gestaltung Einfluss genommen werden. Außerdem wird versucht ein hohes Maß an Verständlichkeit aufrecht zu erhalten, das in einem hohen Maß an Akzeptanz resultieren kann. Weiter sind auch Effizienzsteigerungen durch iterative Planungsschritte realisiert und die Ausrichtung von IT Architektur an die IT Strategie sicher gestellt. 25 Dern,

20 3.2.3 MÖGLICHE PROBLEMFELDER Wie im Kapitel Eigenschaften und Ablauf gezeigt wurde, sind viele Probleme erkannt und angegangen worden. Jedoch bleiben einige Problemfelder unangetastet und es müssten je nach Häufigkeit Lösungsansätze in den Prozess integriert werden. Zwar findet durch die Einbindung des Managements eine gewisse Ausrichtung an die IT und Unternehmensstrategie statt, jedoch ist dies nicht explizit anzunehmen. Es müsste in einem zusätzlichen Sicherungsschritt diese Ausrichtung garantiert werden, um eine gemeinsame Richtung einzelner Projekte über den Initialisierungsprozess hinaus zu erreichen. Ein weiteres Feld ist die Unterstützung durch das Management. In dem Workflow Initialisierung Architekturentwicklung wird diese durch eine hohe Stimmengewalt und hohen Einbindung erzwungen. Dennoch ist nicht sicher ob die Unterstützung auch nachhaltig ist, so dass im Management der Sinn der Architektur erkannt und die Notwendigkeit gesehen wird. Hier könnte zum Beispiel eine stärkere Einbindung des Managements in die Aktivität Anforderungsanalyse Abhilfe schaffen, da so der Unternehmensführung Notwendigkeiten für die Initialisierung aufgezeigt werden könnten. Gegenüber den aufgeführten Feldern sind allgemeine Probleme wie die Erwartung direkter Ausschüttungen nicht in Workflows für Integration von IT Architekturen lösbar, da grundlegendes Verständnis und auch Wissen für den langfristigen und nachhaltigen Nutzen einer solchen Architektur fehlt. Dazu zählen im Allgemeinen Erwartungshaltungen des Managements, die von diesen Strukturen nicht geleistet werden können. 16

21 4 SCHLUSSTEIL In dieser Seminararbeit wurde nur ein kleiner Teil von DERNS Workflows für das Management von IT Architekturen beleuchtet und mögliche Schwachstellen ermittelt. Als Ergebnis entstand ein solider Eindruck, der durch das nachhaltige Konzept des Prozesses und der Lösungen vieler angesprochener Probleme zustande kam. Jedoch müsste dennoch in einem folgenden Schritt nicht nur die Initialisierung sondern auch der Rest der Workflows auf Nachhaltigkeit überprüft werden, um einen Gesamteindruck über die komplette Prozesskette treffen zu können. Als grundlegende Arbeit wäre eine Umfrage in Unternehmen zu verstehen, die mit genau dem von DERN vorgestellten Schema Systemintegration betrieben hat. Da die Ergebnisse Aufschluss über große Problemfelder während der Umsetzung liefern könnten und so die herausgearbeiteten Hindernisse in Bezug auf den Initialisierungsprozess abgestimmt werden könnten. Speziell in dem hier behandelten Fall wurde von einem Sicherungsschritt gesprochen, um die Ausrichtung an IT und Unternehmensstrategie zu gewährleisten. Wie dieser Zusatz in den momentanen Workflow integriert werden kann und welche neuen Probleme dabei auftreten können, müsste in einem weiteren Schritt erörtert werden. Wichtig ist natürlich, dass die momentane Funktionalität trotz einer Erweiterung erhalten bliebe. Über diese direkten Ansätze hinaus, den Ablauf zur Architekturintegration zu verbessern, müsste jedoch noch ein grundlegendes Konzept für die Sicherung des Managementverständnisses gegenüber einzuführender Architekturen geschaffen werden. Vielleicht wäre es im Rahmen eines der angeschnittenen Workflows sinnvoll, oder aber als grundlegende Einführung in das Thema konzipierbar. 17

22 GLOSSAR Da sich dieses Paper zu einem Großteil auf die Arbeit von DERN über Workflows zur Architekturintegration in Unternehmen bezieht, gelten auch die von ihm verwendeten Begriffsdefinitionen. Architektur Outline Dieses Dokument enthält die Kernfakten zur Durchführung der Architekturentwicklung und geht von der Planung bis zur Umsetzung auf physischer Ebene. Architektursicht Hier wird ein Gesamtdesign eines Systems bzw. einer Gruppe von Systemen dargestellt und wichtige Charakteristika hervorgehoben. Deshalb werden nicht relevante Strukturen weggelassen und es bildet sich so die Grundlage wesentlicher Designentscheidungen. Informationssystem Dieses System bildet die Menge aller fachlichen und infrastrukturellen Softwarebausteine, die entscheidend für die Ausführung von Kern und Serviceprozessen sind. Diese Menge stellt ein eigenes abgeschlossenes System dar, das über Interfaces interagiert. Es gibt zwei Arten von Informationssystemen: Auf der einen Seite unterstützt das Kernsystem Kerngeschäftsprozesse, auf der anderen Seite werden diese Systeme über Servicesysteme durch die Bereitstellung zusätzlicher Dienste unterstützt. IS Portfolio In diesem Portfolio wird eine systematisch definierte Aufstellung der Informationssysteme erörtert, indem deren Zusammenwirken, der Ist Zustand und der Soll Zustand definiert werden. Ist Portfolio Es werden die bestehenden Informations und Subsysteme dargestellt und nach ausgewählten Dimensionen analysiert und bewertet. Außerdem wird der A

23 Integrationsgrad der Anwendungen beschrieben und der Verlauf bzw. die Struktur wichtiger Informationsflüsse und Schnittstellen dargestellt. IT Architektur Es handelt sich um die strukturierende Abstraktion geplanter und bereits existierender Informationssysteme. Darüber hinaus können für übergreifende Strukturen, auch im Rahmen der IT, Referenzarchitekturen gebildet werden. IT Basisinfrastruktur Diese Struktur bildet die Menge aller Hardware und systemnahen Softwarekomponenten, die für Entwicklung, Test und Produktion des Informationssystems eine wichtige Rolle spielen. IT Projektportfolio Hier sind die Vorhaben in Form von Projekten für die Überführung der Anwendungslandschaft in den vorher festgelegten Soll-Zustand definiert. Die Grundlage dazu bildet die Informationsarchitektur und die IT-Basisinfrastruktur. Wichtig ist die zeitliche Abfolge der Projekte und deren Abgrenzung mit Hilfe der IS- und IT-Architekturenentwicklung und der Weiterentwicklungen der IT-Basisinfrastruktur und der IT-Organisation. Organisationsstruktur Hier wird die Aufbau und Ablauforganisation definiert, durch die die optimale Durchführung der Geschäftsprozesse gewährleistet werden soll. Soll Portfolio Die geplante Ausgestaltung der Anwendungslandschaft durch Informations und Subsysteme wird durch die Strukturierung der geplanten Landschaft erörtert. Darüber hinaus wird eine Integrationsstrategie für die Anwendungen und die Sicherstellung eines effizienten Informationsflusses zwischen den Geschäftsprozessen erarbeitet. B

24 ANHANG ACTIVITY DIAGRAMM: WORKFLOW INITIALISIERUNG ARCHITEKTURENTWICKLUNG C

25 ACTIVITY DIAGRAMM: BESCHREIBUNG DER AKTIVITÄTEN NACH DERN 26 Activity Inhalt Input Output Überprüfung Architekturkonfiguration KEF + Risiko Analyse Beschreibung Sollzustand Fixierung Ziele und Scope Sollzustand der Architekturentwicklung Organisationsund Kommunikationskonzept Entwurf Architekturreleaseplanung Analyse und Bewertung aller Anforderungen an die zu entwickelnde Architektur Konsolidierung der Architekturkonfiguration und der zugeordneten Architekturszenarien zur Ergänzung der Anforderungsanalyse Beschreibung der relevanten kritischen Erfolgsfaktoren und Risiken Zusammenfassende Beschreibung des Zustandes, der eintreten muss, damit die Architekturentwicklung als erfolgreich gelten kann Festschreibung der Ziele und der Reichweite der Architekturentwicklung Festlegung der organisatorischen Einbettung incl. Eskalationsverfahren und Rollenverteilung Grobe Festlegung, welche Anforderungen durch definierte Architektur Releases adressiert werden und welche Ergebnisse dazu erzeugt werden müssen. Anforderungsanalyse Architekturkonfiguration Anforderungen Business Case spezifisch Ergänzende Anforderungen des IT Architekten (U Ebene) Ergänzende Anforderungen des Service Managers der IT Basisinfrastruktur Architekturkonfiguration und Szenarien aus der übergreifenden Planung Analysen des IT Architekten KEF des Architekturmanagement Anforderungen Szenarien Risiken Erfolgsfaktoren Anforderungen und Rahmenbedingungen Ziele Risiken und KEF Projektorganisation Entwurf der Planung des Softwareentwicklungsprojektes Ziele, Scope, Anforde rungen Bewertete Anforderungen Konsolidierte Architekturkonfiguration und Szenarien Bewertete KEF und Risiken Beschriebene Ziele incl. Definition des Scope und der Abnahmekriterien Organisations und Kommunikationskonzept Entwurf der Releaseplanung 26 Dern, 2006 D

26 Auftragsdefinition Schriftlicher Auftrag Auftragsvereinbarung Definition Architektur Changemanagement Auswahl Architektursichten Auswahl Aktivitäten und Artefakte Festlegung des Umfangs der Entwicklungs Workflow Architekturreleaseplanung Zusammenfassende, abnahmefähige Beschreibung des Auftrages zur Architekturentwicklung. Commitment zwischen Auftragnehmer und Auftraggeber zum Auftrag der Architekturentwicklung Festlegung, wie Veränderungen an der Architektur von der Anforderung bis zur Umsetzung strukturiert und nachvollziehbar durchgeführt werden und wie das Change Request Verfahren bis hin zur Abnahme von Change Requests gestaltet wird. Definition der wesentlichen Sichten (Sichten im Großen), die bei der Architekturentwicklung erarbeitet werden müssen Überprüfung der Architek tur Entwicklungs Work flows auf durchzuführen den Aktivitäten und die zu erstellenden Artefakte. Ggf. Reduktion oder Ergänzung. Vervollständigung der Releaseplanung Ziele und Scope, Entwurf Releaseplanung, Organisations und Kommunikationskonzept Auftragsdefinition Organisationkonzept Bestehende Change Request Verfahren Abgenommene Anforderungen Definierte Ziele und Scope Kommunikationskonzept Entwicklungs Workflow Auftrag Ausgewählte Sichten Ausgewählte Aktivitäten und Artefakte Auftragsvereinbarung Abgestimmtes Vorgehen zum Changemanagement Wesentliche Architektursichten (im Großen) Releaseplanung E

27 LITERATURVERZEICHNIS Dern, Gernot Management von IT Architekturen. Wiesbaden : Vieweg, Dietzsch, Andreas Architekturmanagement. [Buchverf.] Joachim Schelp. Integrationsmanagement. Berlin : Springer, Göransson, A. und Schuh, G Das Netzwerkmanagement in der virtuellen Fabrik. [Buchverf.] G. Müller Stewens. Virtualisierung von Organisationen. Stuttgart : Schäffer Poeschel, Knackstedt, Ralf, et al Konfigurative Prozessmodellierung der hybriden Leistungserstellung in Unternehmensnetzwerken des Maschinen und Anlagenbaus. Münster, Bochum : s.n., Lederer, A.L. und Mendelow, A.L Information resource planning: Overcoming difficulties in identifying top mananagement's objectives. MIS Quarterly. 1987, Bd. 11, 3. Teo, T.S.H. und Ang, J.S.K An examination of major IS planning problems. International Journal of Information Management. 2001, Bd. 21, 3. Ward, John und Peppard, Joe Strategic planning for information systems. Chichester : Wiley, F