Entwurfsmuster für IKT Architekturen - Theorieteil

Diplomarbeit Entwurfsmuster für IKT Architekturen - Theorieteil Verfasser: Reto Inversini Klasse MAS-06-02 Nummer MAS-06-01.13 Bridelstrasse 12 3008 Bern reto.inversini@lab42.ch Betreuer: Herr Thierry Perroud Bundesamt für Informatik und Telekommunikation Monbijoustrasse 74 3003 Bern Experte: Herr Bernhard Rytz Datum: 11. September 2008

Abstract Die vorliegende Diplomarbeit behandelt das Thema der Enterprise Architecture Patterns (Entwurfsmuster für IKT Architekturen von Firmen). Mit Hilfe dieser Entwurfsmuster wird eine Lösung für ein konkretes Problem in einem spezifischen Kontext der Unternehmensarchitektur definiert. 1

Vorwort Die vorliegende Diplomarbeit entstand zwischen Mai und September 2008 an der Software Schule Schweiz. Sie wäre nicht ohne die fort währende Unterstützung, den intensiven Gedankenaustausch und die Hilfe der folgenden Personen möglich gewesen, wofür ihnen mein Dank gebührt. Betreuer: Experte: Reviewer: Thierry Perroud, Bundesamt für Informatik und Telekommunikation Bernhard Rytz, Schweizerische Bundesbahnen SBB Martina Etzweiler Patric Geissbühler Emanuel Haldi Dieter Kastrau Stefan Neuenschwander Jürg Rösch Weiter möchte ich meiner Lebensgefährtin, Martina Etzweiler und meinen Eltern, Enrico und Yolanda Inversini dafür danken, dass sie mich immer unterstützt haben. Allen, hier nicht namentlich genannten Personen, die mir mit Ideen und Aufmunterung geholfen haben, ebenfalls ein grosses Danke. Das Schreiben der Diplomarbeit war eine bereichernde, intensive und sehr lehrreiche Zeit, die ich nicht missen möchte. 2

1 Inhaltsverzeichnis 1 Inhaltsverzeichnis... 3 2 Definitionen, Abkürzungen und Referenzen... 5 2.1 Sprachgebrauch... 5 2.2 Definitionen... 5 2.3 Abkürzungen... 5 3 Einführung... 6 3.1 Abstract... 6 3.2 Sinn und Zweck... 6 3.3 Zielpublikum und Einsatzgebiet... 6 3.4 Motivation und Problemstellung... 6 4 Allgemeine Beschreibung... 8 4.1 TOGAF... 8 4.1.1 Architektur Entwicklungsmodell... 9 4.1.2 Das Enterprise Continuum... 10 4.1.3 Das Technische Referenz Modell... 11 4.1.4 Views and Viewpoints... 14 4.1.5 Kräfte... 16 4.1.6 Architecture Governance... 19 4.2 Entwurfsmuster... 20 5 Enterprise Architecture Pattern... 22 5.1 Definition... 22 5.2 Einleitung... 22 5.2.1 Name... 22 5.2.2 Problemstellung... 22 5.2.3 Kontext... 23 5.2.4 Kräfte... 23 5.3 Die Lösungsfindung... 24 5.3.1 Elemente und Protokolle... 24 5.3.2 Systemaufbau / Komponenten... 24 5.3.3 Netzwerkzonierung... 25 5.3.4 Protokolle... 26 5.3.5 Zugriffe... 26 5.3.6 Verbindungsaufbaudiagramm... 27 5.3.7 Datenflussdiagramm... 28 5.3.8 Schnittstellen... 29 5.3.9 Weitere Punkte... 29 5.4 Resultierender Kontext... 30 5.5 Abschluss... 31 5.5.1 Bekannte Verwendungen... 31 5.5.2 Verwandte Entwurfsmuster... 31 5.5.3 Eignung des Entwurfsmusters:... 31 5.5.4 Begründung und Zusammenfassung... 31 6 Qualitative Anforderungen an Enterprise Architecture Patterns... 31 7 Kategorisierung... 32 7.1 Zu beschreibende Enterprise Architecture Patterns... 33 7.1.1 Enterprise Architecture Pattern für Infrastructure... 33 7.1.2 Enterprise Architecture Pattern für Plattform... 34 7.1.3 Enterprise Architecture Pattern für Integration... 34 3

7.1.4 Entwurfsmuster für Application... 35 7.1.5 Entwurfsmuster für Security... 35 8 Zusammenfassung... 36 9 Abschliessende Gedanken... 37 10 Anhang... 38 10.1 Abbildungsverzeichnis... 38 10.2 Literaturverzeichnis... 38 4

2 Definitionen, Abkürzungen und Referenzen 2.1 Sprachgebrauch Begriff Müssen Sollen Können Dürfen Definition Es ist zwingend erforderlich, entweder auf der Basis von Weisungen oder aus Gründen von Best Practice. Ausnahmen dürfen keine gemacht werden. Es ist wichtig, dass dies so gemacht wird, es können aber begründete Ausnahmen von der Regel gemacht werden. Es ist angeraten/vorgeschlagen, etwas wie dargestellt zu tun. Es ist erlaubt etwas zu tun und verstösst nicht gegen Müssen. 2.2 Definitionen Begriff Enterprise Architecture Pattern Entwurfsmuster für IKT Infrastrukturen IKT IT- Unternehmensarchitektur Definition Entwurfsmuster für IKT Infrastrukturen. Wird in dieser Arbeit von Entwurfsmuster im Allgemeinen gesprochen, sind Entwurfsmuster für IKT Infrastrukturen gemeint. S. Enterprise Architecture Pattern Informations- und Kommunikationstechnologie Die Architektur für die Informations- und Telekommunikationstechnologie einer Firma. 2.3 Abkürzungen Abkürzung ADM BIT COBIT DMZ ESB IKT Java EE Nascio PKI TOGAF TRM Beschreibung Architecture Development Model Bundesamt für Informatik und Telekommunikation Control Objectives for Information and Related Technology Demilitarized Zone Enterprise Service Bus Informations- und Kommunikationstechnologie Java Enterprise Edition National Association of State Chief Information Officers Public Key Infrastructure The Open Group Architecture Framework Technical Reference Model 5

3 Einführung 3.1 Abstract Architectural Patterns: The expression of a fundamental structural organization or schema for a system or solution. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. 1 Die vorliegende Diplomarbeit behandelt das Thema der Enterprise Architecture Patterns (Entwurfsmuster für IKT Architekturen von Firmen). Mit Hilfe dieser Entwurfsmuster wird eine Lösung für ein konkretes Problem in einem spezifischen Kontext definiert. Die Entwurfsmuster für IKT Architekturen stammen aus einer der vier Hauptdomänen der Architektur (Infrastructure, Application, Plattform, Security und Integration ). 3.2 Sinn und Zweck Die zu entwickelnde Sammlung von Entwurfsmustern für IKT Architekturen von Firmen verfolgt das Ziel, einem IT-Unternehmensarchitekten ein einfach zu handhabendes Arbeitsinstrument zur Erstellung, Kontrolle und Beurteilung von IKT Architekturen zur Verfügung zu stellen. Weiter dient es einem Projektleiter, einem Lösungsarchitekten oder einem IKT Ingenieur als Planungsgrundlage für die Erstellung von effizienten Designs im Bereich der Informations- und Kommunikationstechnologie. 3.3 Zielpublikum und Einsatzgebiet Die Enterprise Architecture Patterns richten sich an Unternehmensarchitekten, Lösungsarchitekten, sowie an interessierte Leser, die sich näher mit der Gestaltung von Unternehmensarchitekturen auseinandersetzen möchten. Das Einsatzgebiet dieser Enterprise Architecture Patterns ist weder auf eine bestimmte Branche, noch auf eine bestimmte Grösse einer Firma beschränkt. Je nach Ausprägung kann es aber grössere Abweichungen geben. Zudem können je nach Branche zusätzliche Enterprise Architecture Patterns notwendig sein, um die IT Landschaft adäquat beschreiben zu können. 3.4 Motivation und Problemstellung Ich arbeite für den Sicherheits- und Risikomanagementbereich des Bundesamtes für Informatik und Telekommunikation (BIT). Bei den Projektberatungen stellten wir immer wieder fest, dass einer der Kernpunkte Architekturfragen sind und dass die Projektleiter und Solution Architekten sehr oft aus Mangel an Wissen über die Gesamtarchitektur suboptimale Lösungen wählten, welche spätestens im Betrieb zu erhöhten Kosten führten. Aus diesem Grund wurde vermehrt ein Fokus auf die Unternehmensarchitektur gelegt, was dieses Jahr in der Gründung eines eigenen Bereiches für Unternehmensarchitektur mündete. Diese Thematik übte von Anfang an eine grosse Faszination auf mich aus, denn genauso wie bei der Sicherheit geht 1 Frank Buschmann, Régine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stahl; 1996. Pattern-Oriented Software Architecture A System of Patterns, New York, NY: John Wiley and Sons, Inc. 6

es darum, Interaktionen zwischen verschiedenen Systemen zu erkennen, zu optimieren und in Einklang zu bringen. Die vorliegende Arbeit entstand aus der Erkenntnis heraus, den Projektleitenden und Lösungsarchitekten ein einfach handhabbares, gut verständliches Planungsinstrument in die Hand zu geben, anhand dessen sie ihre Projekte besser in die bestehende (und geplante) Informatiklandschaft einpassen können. Für zwei Projekte (Ausbau des Webhosting Bereiches und Weban-wendungen auf der BEA Weblogic Plattform) wurden bereits Entwurfsmuster für IKT Architekturen gezeichnet und deren Nutzen wurde als sehr positiv bewertet. Da ich in dem Bereich Sicherheits- und Risikomanagement bleiben werde, stellt diese Diplomarbeit für mich auch so etwas wie ein Abrunden und ein letztes Auskosten des faszinierenden Gebietes der Unternehmensarchitektur dar. 7

4 Allgemeine Beschreibung 4.1 TOGAF The Open Group entwickelt das Architekturframework The Open Group Architecture Framework, welches zu einem der bekanntesten Architekturentwicklungsmodelle in der Informatik geworden ist. Im Gegensatz zu anderen Architektur Frameworks wie z.b. demjenigen von Zachman ist TOGAF frei verfügbar. Es soll aber an dieser Stelle klar gesagt werden, dass die Idee der Enterprise Architecture Patterns Framework unabhängig ist. Ein Architekturframework definiert sich nach TOGAF wie folgt: An architecture framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks. 2 Im Folgenden werden einzelne Elemente von TOGAF kurz vorgestellt, soweit sie für die vorliegende Arbeit relevant sind. Die Einbettung und die verschiedenen Granularitätsstufen werden aus der folgenden Darstellung ersichtlich: Vision Prinzipien Technisches Referenzmodell (TRM) Zunehmende Granularität Enterprise Architecture Patterns Software Design Patterns, Netzwerk Konzepte, Plattform Best Practices Abbildung 1: Pyramide 3 2 Rachel Harrison; 2007, TOGAF 8.1.1, S. 5. Zaltbommel: Van Haren Publishing 3 eigene Darstellung 8

4.1.1 Architektur Entwicklungsmodell Der Einsatz eines Architektur Entwicklungsmodell (ADM, Architecture Development Model) wird in TOGAF wie folgt beschrieben: As a generic method, the ADM is intended to be used by enterprises in a wide variety of different geographies and applied in different vertical sectors/industry types. As such, it may be, but does not necessarily have to be, tailored to specific needs. 4 Das ADM zeigt, wie aus dem Framework und Architekturprinzipien in mehreren Phasen die Unternehmensarchitektur entwickelt werden kann. Abbildung 2: ADM 5 Das ADM ist ein Prozesszyklus, der nie fertig ist, sondern immer wieder von neuem beginnt. Genau so wie auch eine IKT Umgebung in einer Firma nie zu Ende gebaut ist, sondern kontinuierlich weiter entwickelt werden muss, um den zentralen Punkt erfüllen zu können, die Anforderungen des Geschäfts. Da in der Praxis in der Regel zu den verschiedenen Phasen im Modell schon Artefakte vorhanden sind, ist der ADM Zyklus von TOGAF nicht iterativ. Phasen können über das Requirements Management als Angelpunkt auch direkt angesprungen werden. Die Arbeit wird sich speziell im Bereich D., Technology Architecture, abspielen, hat jedoch einen Einfluss auf den gesamten Zyklus der Architekturentwicklung. In dieser Phase werden diejenigen Teile berücksichtigt, welche im Enterprise Continuum (Repository mit allen Architektur Artefakten und Assets) dargestellt sind. Die Enterprise Architecture Patterns stellen ebenfalls einen Teil dieses Continuums dar. 4 Rachel Harrison; 2007, TOGAF 8.1.1, S. 4. Zaltbommel: Van Haren Publishing 5 Rachel Harrison; 2007, TOGAF 8.1.1, S. 20. Zaltbommel: Van Haren Publishing 9

4.1.2 Das Enterprise Continuum Das Enterprise Continuum wird aus dem Architecture Continuum und dem Solution Continuum gebildet. Darunter ist nach TOGAF ein Virtual Repository zu verstehen, in dem sämtliche Architekturelemente und Assets dokumentiert werden. Folgende Elemente zählen zum Continuum: - Architekturmodell - Architektur Beschreibungen - Architektur Entwurfsmuster - Weitere Artefakte Der Hauptfokus des Enterprise Continuums liegt darin, die Basis für die Wiederverwendbarkeit von Architekturkomponenten zu schaffen und mit dem Virtual Repository ein Gefäss für die Aufbewahrung und Einordnung solcher Komponenten zu schaffen: The Enterprise Continuum is thus a framework (a framework-within-a-framework) for categorizing architectural source material both the contents of the architecture working repository, and the set of relevant available reference models in the industry. 6 Das Architecture Continuum kann als eine Sammlung von Architecture Building Blocks und Architektur Modellen beschrieben werden, während das Solution Continuum dasselbe für Solution Building Blocks tut. Das Verhältnis dieser beiden wird in der folgenden Grafik dargestellt: Abbildung 3: Enterprise Continuum 7 Die Enterprise Architecture Patterns passen sich zwischen dem Architecture und dem Solutions Continuum ein, indem sie die Architektur Building Blocks weiter spezifizieren und sich so den Solution Building Blocks annähern. 6 Rachel Harrison; 2007, TOGAF 8.1.1, S. 18. Zaltbommel: Van Haren Publishing 7 Rachel Harrison; 2007, TOGAF 8.1.1, S. 141. Zaltbommel: Van Haren Publishing 10

Die Idee hinter den Architectural Building Blocks und den Solution Building Blocks wird im folgenden Kapitel näher erklärt. 4.1.3 Das Technische Referenz Modell Um eine Zielarchitektur nach TOGAF entwickeln zu können, braucht es die architektonischen Grundlagen, welche durch das TRM (Technical Reference Model), die Standards Information Base, sowie durch Building Blocks definiert werden. Abbildung 4: Komponenten eines TRM 8 TOGAF definiert das TRM wie folgt: The Technical Reference Model has two main components: 1. The Technical Reference Model (TRM), which provides a model and taxonomy of generic platform services 2. The Standards Information Base (SIB), which provides a database of standards that can be used to define the particular services and other components of an organizationspecific architecture that is derived from the TOGAF Foundation Architecture The TRM is universally applicable and, therefore, can be used to build any system architecture. 9 Die Standards Information Base liefert Industriestandards, welche bei der Definition der Architekturen einen formalen Rahmen bilden. Sie ist unter folgendem Link abrufbar: http://www.opengroup.org/sib.htm Das in TOGAF generische TRM ist der Teil der Architektur auf deren Basis die effektiven technischen definiert werden. Für die vorliegende Arbeit ist er der wichtigste Teil. Die Building Block Information Base schliesslich enthält die 8 Pallab Saha: Analyzing The Open Group Architecture Framework from the GERAM Perspective, http://www.opengroup.org/architecture/wp/saha/togaf_geram_mapping.htm, zitiert nach TOGAF V 8.1. [Letzter Aufruf: August 2008] 9 Rachel Harrison; 2007, TOGAF 8.1.1, S. 143. Zaltbommel: Van Haren Publishing 11

Architectural Building Blocks und die Solution Building Blocks, wobei letzterer die feiner granulierte und firmenspezifische Ausprägung des Architectural Building Blocks ist. Architectural Building Blocks Definieren, was normalerweise gebraucht wird Zeigen Geschäfts- und/oder technische Anforderungen auf Führen zu Solution Building Blocks Solution Building Blocks Definieren wie die Anforderungen erreicht werden können. Kennzeichnen die konkrete Implementierung in einer Firma Erfüllen ein Geschäftsbedürfnis, sind die eigentlichen Produkte. Die Arbeit spielt sich zwischen diesen beiden Ebenen ab und versucht, die Architectural Building Blocks in der Art eines Design Patterns aufzubereiten. Die drei wichtigsten Punkte einer Unternehmensarchitektur sind Anwendungen, Plattformen für diese Anwendungen und die Kommunikationsinfrastruktur. Um ein Zusammenspiel von Anwendung, Plattform (Middle Ware und Betriebssystem) und Netzwerk zu finden, werden Schnittstellen gebraucht und zwar APIs in Richtung Plattform und Netzwerk Schnittstellen in Richtung Netzwerk: Werden die Anwendungen weiter aufgeteilt, entstehen zwei generische Anwendungstypen: Die Geschäftsanwendung und die Infrastrukturanwendung. Sie unterscheiden sich primär in ihrem Anpassungsgrad an einzelne Aufgabenstellungen. Eine detaillierte Sicht auf das TRM zeigt diese Aufteilung deutlich: Abbildung 5: TOGAF TRM 10 10 Rachel Harrison; 2007, TOGAF 8.1.1, S. 146. Zaltbommel: Van Haren Publishing 12

Im BIT wird von diesem generischem TRM leicht abgewichen, indem zusätzlich Integration eingeführt werden. Unter den Integration werden Elemente verstanden, die für sich alleine keine (Geschäfts) Funktionalität haben, aber durch ihre integrierenden Funktionen Anwendungen zu neuen zusammenführen können. Die Communications Infrastructure von TOGAF wird erweitert und mit den Infrastructure Applications verschmolzen, so dass prinzipiell alle Infrastrukturdienste in diesem Block erfasst werden können. - Infrastructure / Plattform - Integration - Application - Security Im Idealfall werden die Application immer via Integration mit den Infrastructure oder mit anderen Application verbunden: Application Integration Plattform Infrastructure Security Abbildung 6: Vereinfachtes TRM 11 Entwurfsmuster für IKT-Architekturen können nur eine einzelne dieser Schichten betreffen oder aber über mehrere oder alle Schichten gehen. Folgende Grafik soll diesen Zusammenhang visualisieren: Java EE Web Apps Datenaustausch Service Identity Access Management Management Application Anwendungsschnittstelle Integration Plattform Infrastruktur Schnittstelle Security Netzwerk Architektur Infrastructure Abbildung 7: TRM und Patterns 12 11 Eigene Darstellung 12 Eigene Darstellung 13

Auf der linken Seite sind mögliche Entwurfsmuster für IKT-Architekturen dargestellt und ihre Ausdehnung in Bezug auf die Schichten, Anwendung, Abwendungs- Plattform, resp. Integration und Kommunikationsinfrastruktur. Es ist gut zu erkennen, dass sich Patterns mindestens auf einer Schicht plus der entsprechenden Schnittstelle bis über alle Schichten erstrecken können. Ebenfalls sichtbar wird die Querschnittsaufgabe der Security, welche sich über alle Schichten erstrecken. Auch wenn die Ausdehnung über mehrere Ebenen gehen kann, ist das Entwurfsmuster meist doch einer Ebene als hauptsächlich zuzuordnen. 4.1.4 Views and Viewpoints Das fundamentale Konzept der Views and Viewpoints soll mit den Definitionen von TOGAF eingeleitet werden: Stakeholders are people who have key roles in, or concerns about, the system; for example, as users, developers, or managers. Different stakeholders with different roles in the system will have different concerns. Stakeholders can be individuals, teams, or organizations (or classes thereof). Concerns are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system. Concerns may pertain to any aspect of the system's functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability. A view is a representation of a whole system from the perspective of a related set of concerns. [ ] A viewpoint defines the perspective from which a view is taken. More specifically, a viewpoint defines: how to construct and use a view (by means of an appropriate schema or template); the information that should appear in the view; the modeling techniques for expressing and analyzing the information; and a rationale for these choices (e.g., by describing the purpose and intended audience of the view). 13 Zusammenfassend kann gesagt werden, dass eine Architektursicht (View) eine Manifestation der Gesamtarchitektur aus dem Gesichtspunkt (Viewpoint) eines bestimmten Stakeholders darstellt und beschreibt, was dieser sieht. Dabei wird die Sprache des Stakeholders verwendet, um es diesem zu ermöglichen, die Sicht zu verstehen und zu beurteilen, ob die vorliegende Architektur es ihm ermöglicht, seine Geschäftsziele effizient zu erreichen. Die Idee hinter der Entwicklung der verschiedenen Sichten ist es somit, eine einfache und dem Stakeholder gut verständliche Sichtweise auf ein bestimmtes Architekturproblem zu geben. Naturgemäss unterscheiden sich die Sichten je nach Stakeholder und nach betrachteter Architektur. Es ist aber sehr wichtig festzuhalten, dass alle Sichten und Gesichtspunkte gleichwertig betrachtet werden müssen und es aus Architektursicht keine wichtigeren und weniger wichtigen Sichten gibt. Der Gesichtspunkt (Viewpoint) in der Architektur legt das grundlegende Modell für eine spezifische Betrachtungsweise einer Architektursicht fest. Der Viewpoint beschreibt somit eine bestimmte Betrachtungsweise durch einen bestimmten Stakeholder. 13 Rachel Harrison; 2007, TOGAF 8.1.1, S. 297. Zaltbommel: Van Haren Publishing 14

Ein Viewpoint beinhaltet folgende Elemente: - Der adressierte Stakeholder - Das durch den Viewpoint adressierte Anliegen - Das verwendete Modell TOGAF schlägt folgende Stakeholder als kleinste gemeinsame Menge in einer Firma vor. Je nach Bedarf kann diese Liste beliebig erweitert werden: - Benutzer (Users), Planer, Management - System-, Datenbank, Netzwerk und Software Ingenieure - Operators, Administratoren und Manager - Beschaffer Nebst den durch die Stakeholder bedingten Sichten, gibt es allgemeine Sichten, welche auch aus der klassischen Software Architektur bekannt sind: - Kontextsichten: In welchem Kontext steht das System? Welche Geschäftsanwendungsfälle können abgebildet werden? Diese Sicht ist meist ein Blick aus der Vogelperspektive auf das Architekturmuster. - Laufzeitsichten: Wie läuft das System ab? Wie ist seine dynamische Struktur. Diese Sicht wird im Zusammenhang mit den Datenflüssen zum Zuge kommen. - Bausteinsichten: Aus welchen Bausteinen besteht ein Muster? Diese Sicht kommt in den Enterprise Architektur Mustern sehr oft zum Zug, da es genau darum geht, die einzelnen Bausteine und deren Abhängigkeiten darzustellen. - Infrastruktursichten: In welcher Umgebung steht das System? Diese Sicht hilft es, nötige Infrastrukturelemente zu erkennen und wo nötig als eigene Infrastrukturpatterns zu beschreiben. In den Architekturmustern werden folgende Sichten und Stakeholders verwendet. Je nach Muster können einzelne Sichten weggelassen oder dazugenommen werden. 15

Folgenden Stakeholdern werden in den Architekturmustern folgende Datenbank-, System-, Netzwerk Storage-, System-, und Software Netzwerk- und Ingenieure, Software Ingenieure, Projektleiter Projektleiter Benutzer, Kunden, Produktmanagement, Projektleiter System-, Netzwerk und Software Ingenieure, Projektleiter Geschäftsarchitektur Sicht Sicht auf die Geschäftsprozess Sicht auf nötige Organisatorische Belange Sicht auf den Geschäftsanwendungsfall Sichten ermöglicht Daten Architektur Anwendungs- Sicht Architektursicht welche aus folgenden Teilen bestehen: Datenhaltungssicht Anwendungsentwicklungssicht (Wo sind die Daten) (Komponenten einer Datenfluss Sicht (Wo fliessen die Daten durch) Anwendung) Integrationssicht (Interoperabilität und Schnittstellen, wie werden Anwendungen miteinander verbunden) Software Verteilungssicht (Wie und wohin werden die Anwendungen verteilt) Technologie Architektur Sicht Plattformsicht Netzwerksicht Verarbeitungssicht Sicht auf verwendete Standards und Protokolle System Engineering Sicht Security Sicht Betriebsprozess Sicht Kostensicht Abbildung 8: Sichten und Stakeholder 14 Nebst der eindeutig einer der Hauptsichten zugehörigen Themen gibt es übergreifende Sichten, welche alles betreffen und denen dadurch indirekt auch ein integrierender Faktor zukommt. Dies ist die Security Sicht, die Betriebsprozesssicht, sowie die Kostensicht. TOGAF ordnet die Kostensicht der Technologiesicht zu. In der vorliegenden Arbeit wird bewusst davon abgewichen, da die Wahl der Entwurfsmuster für IKT Architekturen durchaus auch zu Kosten in anderen Sichten, insbesondere durch organisatorische Notwendigkeiten, führen kann. 4.1.5 Kräfte Auf ein Architekturmuster wirken verschiedenste Kräfte ein; Kräfte, welche die Ausbreitung eines Musters fördern, Kräfte, welche es bewusst oder unbewusst zu verhindern versuchen. Damit die Muster in einer Firma realisiert werden können, müssen die Kräfte klar erkennbar sein. Um diese Kräfte zu kanalisieren und dazu zu bringen, dem Firmenzweck entsprechend zu handeln, ist eine gute Governance 14 Eigene Darstellung, vgl. Rachel Harrison; 2007, TOGAF 8.1.1, S. 302. Zaltbommel: Van Haren Publishing 16

nötig, welche nicht nur die Erstellung dieser Patterns unterstützt, sondern auch später dafür besorgt ist, dass die Patterns effektiv auch umgesetzt werden können. Ein allgemeines Kräftediagramm der im BIT relevanten Kräfte, die auf ein Pattern einwirken, kann wie folgt dargestellt werden: Abbildung 9: Externe und interne Kräfte 15 Wichtig ist dabei festzuhalten, dass es Kräfte gibt, welche extern sind und die kaum beeinflusst werden können. Ebenso sehr dürfen die internen, oft politisch motivierten Kräfte in ihrer Wirkung keinesfalls unterschätzt werden. Ein schon fast klassisches Beispiel ist der Zwiespalt zwischen Individuallösungen und standardisierten Lösungen, wo es für jede Architektur nötig ist, zu entscheiden, wie stark die individuelle Komponenten und damit der Freiheitsgrad für alle beteiligten Parteien ist. 15 Eigene Darstellung 17

In einem Diagramm dargestellt, präsentiert sich dies wie folgt: Abbildung 10: Kräftediagramm 16 Dieses Tauziehen zwischen Standardisierung der Plattformen und Individuallösungen bricht sehr häufig zwischen Betrieb und Lösungsentwicklung auf. Die beiden Parteien zeigen dabei folgende Grundhaltungen: Kraft und Wirkung Betrieb Lösungsentwicklung Grundhaltung gegenüber neuer Technologie Konservativ und zurückhaltend Progressiv, versucht oft die neueste Version einzusetzen Kostensicht Langfristig Kurzfristig, auf das Projekt bezogen Vereinheitlichung vs. Spezialisierung Der Betrieb möchte Plattformen vereinheitlichen zum Preis, dass nicht jedes Feature eines Produktes nutzbar ist Know-how Aufbau Langsam Rasch Spezialisierungsmöglichkeiten Mittel, gefragt sind eher Hoch für Ingenieure Generalisten Die Lösungsentwicklung setzt oft auf Features einer Plattform, die auf anderen, vergleichbaren Plattformen nicht vorhanden ist An diesem Beispiel sind die Schwierigkeiten bei der Auswahl einer geeigneten Technologie erkennbar, weil die beiden Parteien, die Betriebs- und die Entwicklungsorganisation, divergierende Ansichten haben. Ein Pattern kann diese Divergenzen zwar nicht lösen, aber bis zu einem gewissen Grad entschärfen. Dies geschieht dadurch, dass einerseits die Probleme beim Entwurf eines Musters auf den Tisch der beteiligten Parteien gelangen und andererseits das gegenseitige Verständnis gefördert wird. Das Muster kann auch als konkretes Objekt für eine Architekturdiskussion dienen. Die Enterprise Architecture Patterns dienen somit auch zur Beschreibung eines oder mehrerer Anliegen eines oder mehrerer Stakeholders und repräsentieren somit die Views und Viewpoints. 16 Eigene Darstellung 18

4.1.6 Architecture Governance Die Architecture Governance ist in die Governance einer Gesamtfirma eingebettet zu betrachten. Unter Governance wird Folgendes verstanden: Gemeint ist hiermit die verantwortliche, transparente und nachvollziehbare Leitung und Überwachung von Organisationen und ihre Ausrichtung an Regulierungen, Standards und ethischen Grundsätzen. 17 TOGAF bettet die Architecture Governance wie folgt in die Enterprise Governance ein: Architecture governance typically does not operate in isolation, but within a hierarchy of governance structures, which, particularly in the larger enterprise, can include all of the following as distinct domains with their own disciplines and processes: - Corporate governance - Technology governance - IT governance - Architecture governance 18 Dies wird auch durch das Framework für IT Governance COBIT (Control Objectives for Information and Related Technology) bestätigt, welche in einem Mapping der COBIT Prozesse zu den TOGAF Prozessen folgendes festhält: Governance is fundamental in entrenching EA (essentially a new way of working) into a business. Architecture compliance (chapter 24) maps to most of the COBIT processes. However, without adequate governance, enterprise architecture will remain a theoretical concept that will fail to deliver the desired business benefits. This necessitates greater collaboration and a cross-discipline understanding between the compliance, audit, risk and security functions, and the chief architect. 19 TOGAF beschreibt die Architecture Governance als die Anwendung und Richtung durch die eine IKT Architektur verwaltet und kontrolliert wird: Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It includes the following: - Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization - Implementing a system to ensure compliance with internal and external standards and regulatory obligations - Establishing processes that support effective management of the above processes within agreed parameters 17 Wolfgang Johannsen, Matthias Goeken; 2007, Referenzmodelle für IT-Governance 18 Rachel Harrison; 2007, TOGAF 8.1.1, S. 239. Zaltbommel: Van Haren Publishing 19 IT Governance Institute; 2007, TOGAF mapping with COBIT Research, S. 26. Rolling Meadows: ITGI 19

- Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization 20 In Bezug auf die Entwurfsmuster für IKT Architekturen bedeutet dies, dass die Entwicklung, Bekanntmachung und Anwendung dieser Entwurfsmuster in die Governance einfliessen muss. Idealerweise geschieht dies als zusätzliches Prüfelement für die Architekturkonformitätsprüfung von Projekten. Dazu müssen folgende Fragen in die Konformitätsprüfung einfliessen: - Wurde vor der Lösungsentwicklung der Katalog der Entwurfsmuster für IKT Architekturen konsultiert? - Welche Entwurfsmuster für IKT Architekturen enthalten Elemente, welche für die Lösungsfindung interessant sind? - Wie gross ist die Übereinstimmung der Lösungsarchitektur mit dem oder den verwendeten Entwurfsmustern für IKT Architekturen. Falls es Abweichungen gibt, sind diese begründbar? - Müssen neue Entwurfsmustern für IKT Architekturen definiert oder bestehende angepasst werden? Ein weiterer, wichtiger Punkt ist die Definition eines Change Prozesses, welcher den Wechsel von einer entwurfsmusterlosen Enterprise Architektur in Richtung einer auf Entwurfsmustern gründenden Architektur begünstigt und unterstützt. Dazu sind die nötigen Anreize zu schaffen, wie zum Beispiel vereinfachte und beschleunigte Konformitätsprüfungen bei dem korrekten Einsatz von Enterprise Architecture Patterns. Weiter ist es wichtig, dass die Idee der Entwurfsmuster für IKT Architekturen aktiv verbreitet wird und dass Schlüsselpersonen durch das Team der Unternehmensarchitekturen mit dem Potential eines breiten Einsatzes dieser Muster vertraut gemacht werden. Ebenso sehr zur Governance gehört aber die Einsicht, dass Entwurfsmuster genauso wenig wie bei der Softwareentwicklung - ein Allerweltsheilmittel sind. Die Entwurfsmuster für IKT Architekturen sind dort einzusetzen, wo sie einen Nutzen zu stiften vermögen und nicht um des Musters willen. 4.2 Entwurfsmuster Der Begriff Entwurfsmuster (Design Patterns) stammt ursprünglich aus der Architektur und wurde durch Christopher Alexander wie folgt umschrieben: Jedes Muster beschreibt ein in unserer Umwelt beständig wiederkehrendes Problem und erläutert den Kern der Lösung für dieses Problem, so dass diese Lösung beliebig oft angewendet werden kann, ohne sie jemals ein zweites Mal gleich auszuführen. 21 Diese Idee wurde durch Kent Beck und Ward Cunningham auf die Informatik übertragen: We outline our adaptation of Pattern Language to object-oriented programming. We sumarize a system of five patterns we have successfuly used for designing window-based 20 Rachel Harrison; 2007, TOGAF 8.1.1, S. 242. Zaltbommel: Van Haren Publishing 21 Reto E. König; 2008, Skript Design Patterns zur Vorlesung Advanced Java, zitiert nach Christopher Alexander. https://prof.ti.bfh.ch/knr1/fh/sws/java/web/projektarbeit/patterns.pdf [Letzter Aufruf: August 2008] 20