Post on 14-Aug-2018
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
1
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.
2
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: Thierry Perroud, Bundesamt für Informatik und Telekommunikation Experte: Bernhard Rytz, Schweizerische Bundesbahnen SBB Reviewer: 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.
3
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 Services ................. 33
7.1.2 Enterprise Architecture Pattern für Plattform Services ........................ 34 7.1.3 Enterprise Architecture Pattern für Integration Services ..................... 34
4
7.1.4 Entwurfsmuster für Application Services ............................................. 35
7.1.5 Entwurfsmuster für Security Services ................................................. 35 8 Zusammenfassung ............................................................................................ 36
9 Abschliessende Gedanken ................................................................................ 37 10 Anhang .......................................................................................................... 38
10.1 Abbildungsverzeichnis ................................................................................ 38 10.2 Literaturverzeichnis .................................................................................... 38
5
2 Definitionen, Abkürzungen und Referenzen
2.1 Sprachgebrauch
Begriff Definition
Müssen Es ist zwingend erforderlich, entweder auf der Basis von Weisungen oder aus Gründen von „Best Practice―. Ausnahmen dürfen keine gemacht werden.
Sollen Es ist wichtig, dass dies so gemacht wird, es können aber begründete Ausnahmen von der Regel gemacht werden.
Können Es ist angeraten/vorgeschlagen, etwas wie dargestellt zu tun.
Dürfen Es ist erlaubt etwas zu tun und verstösst nicht gegen „Müssen―.
2.2 Definitionen
Begriff Definition
Enterprise Architecture Pattern
Entwurfsmuster für IKT Infrastrukturen. Wird in dieser Arbeit von Entwurfsmuster im Allgemeinen gesprochen, sind Entwurfsmuster für IKT Infrastrukturen gemeint.
Entwurfsmuster für IKT Infrastrukturen
S. Enterprise Architecture Pattern
IKT Informations- und Kommunikationstechnologie
IT-Unternehmensarchitektur
Die Architektur für die Informations- und Telekommunikationstechnologie einer Firma.
2.3 Abkürzungen
Abkürzung Beschreibung
ADM Architecture Development Model
BIT Bundesamt für Informatik und Telekommunikation
COBIT Control Objectives for Information and Related Technology
DMZ Demilitarized Zone
ESB Enterprise Service Bus
IKT Informations- und Kommunikationstechnologie
Java EE Java Enterprise Edition
Nascio National Association of State Chief Information Officers
PKI Public Key Infrastructure
TOGAF The Open Group Architecture Framework
TRM Technical Reference Model
6
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 Services).
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.
7
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.
8
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:
Software Design Patterns, Netzwerk Konzepte, Plattform Best Practices
Enterprise Architecture Patterns
Technisches Referenzmodell (TRM)
Prinzipien
Vision
Zunehmende
Granularität
Abbildung 1: Pyramide 3
2 Rachel Harrison; 2007, TOGAF 8.1.1, S. 5. Zaltbommel: Van Haren Publishing
3 eigene Darstellung
9
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
10
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
11
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 organization-
specific 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 Services 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
12
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 Solution Building Blocks
Definieren, was normalerweise gebraucht wird
Definieren wie die Anforderungen erreicht werden können.
Zeigen Geschäfts- und/oder technische Anforderungen auf
Kennzeichnen die konkrete Implementierung in einer Firma
Führen zu Solution Building Blocks 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 TRM10
10
Rachel Harrison; 2007, TOGAF 8.1.1, S. 146. Zaltbommel: Van Haren Publishing
13
Im BIT wird von diesem generischem TRM leicht abgewichen, indem zusätzlich Integration Services eingeführt werden. Unter den Integration Services werden Elemente verstanden, die für sich alleine keine (Geschäfts) Funktionalität haben, aber durch ihre integrierenden Funktionen Anwendungen zu neuen Services 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 Services / Plattform Services - Integration Services - Application Services - Security Services
Im Idealfall werden die Application Services immer via Integration Services mit den Infrastructure Services oder mit anderen Application Services verbunden:
Application Services
Integration Services
Infrastructure Services
Se
cu
rity S
erv
ice
s
Plattform Services
Abbildung 6: Vereinfachtes TRM11
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:
Application Services
Integration Services
Infrastructure Services
Anwendungsschnittstelle
Infrastruktur Schnittstelle
Netzwerk
Architektur
Java EE
Web Apps
Identity
Management
Services
Access
Management
Se
cu
rity S
erv
ice
s
Plattform ServicesDatenaustausch
Service
Abbildung 7: TRM und Patterns 12
11
Eigene Darstellung 12
Eigene Darstellung
14
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 Services 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 Services, 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
15
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.
16
Folgenden Stakeholdern werden in den Architekturmustern folgende
Benutzer, Kunden, Produktmanagement, Projektleiter
Datenbank-, Storage-, System-, Netzwerk- und Software Ingenieure, Projektleiter
System-, Netzwerk und Software Ingenieure, Projektleiter
System-, Netzwerk und Software Ingenieure, Projektleiter
Sichten ermöglicht
Geschäftsarchitektur Sicht
Daten Architektur Sicht
Anwendungs- Architektursicht
Technologie Architektur Sicht
welche aus folgenden Teilen bestehen:
Sicht auf den Geschäfts-anwendungsfall
Datenhaltungssicht (Wo sind die Daten)
Anwendungs-entwicklungssicht (Komponenten einer Anwendung)
Plattformsicht
Sicht auf die Geschäftsprozess
Datenfluss Sicht (Wo fliessen die Daten durch)
Integrationssicht (Interoperabilität und Schnittstellen, wie werden Anwen-dungen miteinander verbunden)
Netzwerksicht
Sicht auf nötige Organisatorische Belange
Software Verteilungssicht (Wie und wohin werden die Anwendungen verteilt)
Verarbeitungssicht
Sicht auf verwendete Standards und Protokolle
System Engineering Sicht
Security Sicht
Betriebsprozess Sicht
Kostensicht
Abbildung 8: Sichten und Stakeholder14
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
17
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
18
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
Die Lösungsentwicklung setzt oft auf Features einer Plattform, die auf anderen, vergleichbaren Plattformen nicht vorhanden ist
Know-how Aufbau Langsam Rasch
Spezialisierungsmöglichkeiten für Ingenieure
Mittel, gefragt sind eher Generalisten
Hoch
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
19
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
20
- Developing practices that ensure accountability to a clearly identified stakeholder
community, both inside and outside the organization20
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]
21
user interfaces and present in slightly more detail a single pattern drawn from our current
effort to record a complete pattern language for object-oriented programs.22
Etwas später wurde die Idee der Entwurfsmuster durch die Gang of Four um Erich Gamma zu einem festen Bestandteil der Softwareentwicklung.
Patterns identify and specify abstractions that are above the level of single classes and
instances or of components. 23
Ein Design Pattern stellt eine Lösungsschablone für typische Probleme in der Entwicklung dar und besteht aus mindestens folgenden Elementen:
- Name: Der Name benennt das Design Problem und sollte deshalb möglichst
sprechend sein. - Problem: Beschreibt das Szenario, in welchem das Muster angewendet
werden kann. - Kräfte: Welche Kräfte wirken auf das Pattern ein oder werden durch das
Pattern ausgelöst. Dieses Punkt zeigt welche Kräfte miteinander wirken, oder gegeneinander wirken. Beispiele für diese Kräfte können sein: Sicherheit, Performance, Modularität, Einfachheit im Bau, Einfachheit im Betrieb, Skalierbarkeit.
- Kontext: Zeigt die Voraussetzungen auf, die nötig sind, damit das Muster angewendet werden kann.
- Lösung: Beschreibt die Elemente, aus denen das Muster besteht, sowie wie diese Elemente zusammen wirken und wofür das einzelne Element verantwortlich ist. Die Lösung kann eine Guideline zur Implementierung enthalten. Auch Varianten in der Lösungsfindung können hier aufgezeigt werden.
- Konsequenzen: Zeigt die Vor- und Nachteile auf, welche durch den Einsatz
dieses Musters entstehen. Falls vorhanden, werden hier auch Alternativen dargelegt.
- Resultierender Kontext: Der resultierende Kontext zeigt die Einbettung in die IT-Unternehmensarchitektur und die Schnittstellen von und zu anderen Entwurfsmustern. Weiter werden die Vor- und Nachteile, die aus dem Einsatz des Patterns erwachsen, sowie die Konsequenzen bei einem Nicht-Einsetzen des Musters aufgezeigt. Soweit vorhanden, werden allfällige Erweiterungen des Entwurfsmusters kurz umrissen.
- Beispiele und bekannte Verwendungen: Unter diesem Punkt werden Beispiele und/oder erfolgreiche Implementierungen dieses Musters aufgeführt.
- Verwandte Patterns: Damit wird beantwortet, ob es zu diesem Pattern verwandte und/oder alternative Muster gibt und ob davon abgeleitet Sub-Patterns existieren.
- Zusammenfassung und Begründung: Das Pattern als Ganzes wird kurz
zusammengefasst und begründet, weshalb es das vorgestellte Problem zu lösen vermag und wie diese Lösung funktioniert. 24
22
Kent Beck, Ward Cunningham; 1987, Technical Report No. CR-87-43, http://c2.com/doc/oopsla87.html. [Letzter Aufruf: September 2008] 23
Gamma et al.;1994, Design Patterns: Elements of Reusable Object-Oriented Software. Old Tappan: AddisonWesley 24
Vgl. Rachel Harrison; 2007, TOGAF 8.1.1, S. 258. Zaltbommel: Van Haren Publishing
22
Design Patterns sollten nicht erfunden, sondern gefunden werden. Um ein neues Pattern zu entwerfen müssen bestehende Architekturen betrachtet und verglichen werden. So kann die Essenz gefunden werden, welche dann das eigentliche Design Pattern bildet.
5 Enterprise Architecture Pattern
5.1 Definition
Ein Enterprise Architecture Pattern, auch Entwurfsmuster für IKT Architekturen genannt, kann wie folgt definiert werden:
Ein Enterprise Architecture Pattern beschreibt die Lösung für wiederkehrende Bedürfnisse,
die Firmen an ihre IKT Umgebungen stellen. Die Lösung wird in Form einer Lösungs-
schablone beschrieben, welche Name, Problem, Kontext, Kräfte, Lösung, Konsequenzen
und den resultierenden Kontext darlegt.25
TOGAF beschreibt den Einsatz von Patterns wie folgt:
An Architecture Pattern expresses a fundamental structural organization or schema for
software systems. It provides a set of predefined subsystems, specifies their responsibilities,
and includes rules and guidelines for organizing the relationships between them.26
5.2 Einleitung
In den einleitenden Kapiteln zu einem Enterprise Architecture Pattern werden folgende Punkte geregelt:
5.2.1 Name
Die Namenswahl muss möglichst aussagekräftig sein und die Idee und Zielsetzung des angesprochenen Entwurfsmusters gut untermalen.
5.2.2 Problemstellung
In der Problemstellung wird die Ausgangslage beschrieben, die zur Definition des entsprechenden Enterprise Design Patterns geführt hat. Dabei ist zu beachten, dass die Problemstellung so knapp wie möglich und so ausführlich wie nötig gehalten wird und die effektive Ausgangslage zu beschreiben vermag. Ein wesentlicher Punkt der Problembeschreibung ist der oder die Kernpunkte, welche wiederholbar in vielen Firmen als der „drückende Schuh― empfunden werden. Falls nötig, werden in diesem Kapitel auch Begriffe definiert, so dass die weitere Verwendung unmissverständlich ist. Ebenfalls der Problemstellung werden die Views and Viewpoints auf ein Entwurfsmuster zugeordnet. Diese werden meist in Form einer Tabelle aufgeführt, welche den Stakeholder mit seinem Gesichtspunkt (Viewpoint) und seiner spezifischen Sicht auf das Muster (View) beschreibt.
25
Eigene Definition 26
Rachel Harrison; 2007, TOGAF 8.1.1, S. 257. Zaltbommel: Van Haren Publishing
23
5.2.3 Kontext
Der Kontext eines Enterprise Architecture Patterns beschreibt, was die Voraussetzungen sind, damit das vorliegende Entwurfsmuster überhaupt erst eingesetzt werden kann. Folgende Punkte müssen dabei beachtet und dokumentiert werden:
- Umfeld, in dem das Entwurfsmuster realisiert werden kann. - Anforderungen an vorhandene und implementierte Entwurfsmuster für IKT
Architekturen, auf die das Enterprise Design Pattern aufbaut. - Vorgaben bezüglich Technologien, Protokollen oder Sprachen. - Grösse der Firma, die das Entwurfsmuster implementieren möchte. - Abgrenzung zu anderen Entwurfsmustern, resp. zu Punkten, welche
ausserhalb des Entwurfsmusters liegen.
5.2.4 Kräfte
Eine Kraft in der Unternehmensarchitektur lässt sich wie folgt definieren: „
The notion of "forces" equates in many ways to the "qualities" that architects seek to
optimize, and the concerns they seek to address, in designing architectures―27
Das Entwurfsmuster beschreibt sämtliche relevanten, auf das Enterprise Design Pattern einwirkenden Kräfte und Einschränkungen. Es gibt dabei Kräfte, welche beschleunigend auf das Muster wirken und Kräfte, welche die Einführung des Musters eher behindern. Es kann durchaus Kräfte gehen, welche in beide Richtungen wirken können. Welche Richtung dominiert, hängt nicht zuletzt von der Kommunikationsfähigkeit des Unternehmensarchitekten ab, wobei ihm das Entwurfsmuster wiederum hilft, eine gemeinsame Sprache mit den verschiedenen Stakeholdern zu finden.
27
Rachel Harrison; 2007, TOGAF 8.1.1, S. 258. Zaltbommel: Van Haren Publishing
24
5.3 Die Lösungsfindung
Im Folgenden werden die zentralen Elemente des Lösungsansatzes für ein Entwurfsmuster für IKT Architekturen erklärt:
5.3.1 Elemente und Protokolle
Dieses Kapitel listet übersichtsmässig die wichtigsten Elemente auf, welche im Entwurfsmuster existieren. Die Form ist dabei abhängig von der Art des Entwurfsmusters, dies kann eine einfache Aufzählung oder bereits eine relativ detaillierte Schilderung sein.
5.3.2 Systemaufbau / Komponenten
In der Regel wird eine eigene Darstellung verwendet, welche z.B. den Systemaufbau repräsentiert, wie folgendes Beispiel aufzeigt:
Betriebssystem Windows 2003 / 2008
MMC
(Management
Console)
LDAP
Service
Kerberos
Service
Directory Data
LDAP(s)Verwaltung des Systems
Plus API
Authentifizierung
Mit Kerberos
Abbildung 11: Systemaufbau 28
Diese Darstellung zeigt auf einfache Art und Weise, wie ein Verzeichnisdienst auf Active Directory Basis aufgebaut ist und über welche Konnektoren er verfügt. Daraus lassen sich bereits erste Schlüsse über zu verwendende Protokolle ableiten.
28
Eigene Darstellung
25
Eine weitere Darstellungsform ist die Abbildung eines erweiterten Use Case, der wie folgt aussehen kann:
Datenhaltung
Datenaustausch System
Präsentation und Logik
FTPs
File System
Betriebs-
system
Storage
Betriebs-
system
Kundensicht
FTPs Client
Kunde
IdM
Acce
ss M
an
ag
em
en
t
FTPs
Authentisierung und
Autorisierung
Abbildung 12: Use Case mit Systemgrenzen 29
Der Zugriff aus Kundensicht wird gezeigt, der Aufbau des Gesamtsystems, aufgeteilt in die verschiedenen Tiers, sowie allfällige, wichtige Verbindungen zu Umsystemen.
5.3.3 Netzwerkzonierung
Das Netzzonendiagramm repräsentiert die primäre Sicht des Netzwerk Ingenieurs, sowie der Security. Sekundär ist es ebenfalls für den Software Architekten und den Projektleiter von grosser Wichtigkeit, die auf diese Weise beurteilen können, wo die Systeme platziert werden sollen und ob die Netzzonen korrekt ausgewählt worden sind.
29
Eigene Darstellung
26
Die Darstellungsart der Netzwerkzonierung ist eine Grafik, welche die Zonen und Subzonen darstellt, sowie eine erklärende Beschreibung dazu. Ein Beispiel kann wie folgt aussehen:
Nachbarsubzone
Zugangszone
Anwendungssubzone
Datenhaltungssubzone
Management Zone
Loadbalancer
SAN / NAS
Firewall Zonengrenze
Datenaustausch
Server
Authentisierung
Nachbarsubzonen für IdM,
DNS, NTP, etc.
Fire
wa
ll
Ma
na
ge
me
ntz
on
e
LDAP Proxy
LDAP Service
Readonly DC Jumphost
Webapplication
Firewall (WAF)
Abbildung 13: Zonendiagramm 30
5.3.4 Protokolle
Die auf Layer 7 im OSI/ISO Modell verwendeten Netzwerkprotokolle stellen die Schnittstelle für Software Architekten, welche verteilte Anwendungen planen dar. Aus diesem Grund ist der Standardisierung der eingesetzten Protokolle ein hohes Gewicht beizumessen. Protokolle der Layer 3 und 4 sind durch den Einsatz von IP und TCP fast vorgegeben. UDP als verbindungsloses Protokoll sollte nur in Ausnahmefällen über Netzwerkgrenzen hinweg verwendet werden, da UDP nur schwierig abzusichern ist.
5.3.5 Zugriffe
Um prüfen zu können, ob ein Muster konsistent mit den Netzwerkpolicies ist, und um festzulegen, wer von wo auf Systeme zugreift, wird in einer Tabelle definiert, wie die Zugriffsmuster auszusehen haben. Ein Beispiel sieht wie folgt aus:
Quelle Protokolle Beschreibung
Internet HTTP, HTTPs, LDAP, LDAPs
Abfrage von öffentlichen Inhalten, wie z.B. die Abfrage von Adressbüchern oder CRLs geschieht mit HTTP und/oder LDAP, Abfragen, resp. Übertragungen von Informationen, bei denen es auf Integrität und/oder Vertraulichkeit ankommt mit HTTPs und/oder LDAPs.
30
Eigene Darstellung
27
5.3.6 Verbindungsaufbaudiagramm
Das Verbindungsdiagramm zeigt, von wo welche Verbindungen mit welchem Protokoll initiiert werden. Es zeigt dabei den Verbindungsaufbau im Sinne eines TCP Handshakes. Die Pfeilrichtung symbolisiert dabei die Richtung des Verbindungs-Aufbaus, vom initiierenden System zum angesprochenen System. Ein sehr wichtiger, in diesem Kapitel darzulegender Punkt ist, ob es sich bei der Verbindung um eine authentisierte, eine unauthentisierte oder eine Managementverbindung handelt. Unter einer authentisierten Verbindung wird eine Verbindung verstanden, bei der entweder der Benutzer oder das Gerät oder beide zusammen eindeutig und nachvollziehbar identifiziert worden sind. Eine Managementverbindung dient der Verwaltung der Systeme und Anwendungen.
BV-Netz
Application Subzone
SSZ
Access Subzone
ETZ (DMZ)
KomBV-KTV
Internet
Client
Internet
Client
Kanton
Interne
Basis-
dienste
BV-Netz (Teil des BV)
Kantonsnetze
SSZ
ETZ (DMZ) /
Partnernetze
Netzzonen
S.n
Server
Client
Systembeschreibung
Jumphost
Client
BV Netz
SSHF
irew
all M
an
ag
em
en
tzo
ne
Fire
wa
ll
Zo
ne
ng
ren
ze
ET
Z
Fire
wa
ll
Zo
ne
ng
ren
ze
KT
V
Fire
wa
ll
Zo
ne
ng
ren
ze
BV
Identity Subzone
VerzeichnisdienstReadonly
Domain Controller
Kerberos
Database Subzone Application Subzone
AnwendungDatenbank
SSZ
LDAPs
ESB
SQL Net
Kerberos
HTTPs
HTTPs
HTTPs
Fire
wa
ll Zo
ne
ng
ren
ze
SS
Z
HTTPs
HTTPs
Database Subzone
ESB DatenbankAnwendungSQL Net
Verbindungsaufbau
LDAPs
Verbindungsaufbau
Kerberos
Verbindungsaufbau
HTTPs
Verbindungsaufbau
SQL Net
Verbindungsaufbau
SSH
LDAPs
SSH
SSH
La
ye
r 7 F
ilter
Ap
pl.
Ga
tew
ay
Abbildung 14: Verbindungsaufbaudiagramm 31
Gut sichtbar sind die verschiedenen Kommunikationsströme, die Richtung in die sie wirken und die Systeme, auf die sie wirken. Ebenfalls werden die verschiedenen Netzzonen und die zu traversierenden Sicherheitselemente wie Firewalls und Gateways dargestellt.
31
Eigene Darstellung
28
5.3.7 Datenflussdiagramm
Das Datenflussdiagramm ist eng verwandt mit dem Verbindungsaufbaudiagramm, zeigt aber zwischen welchen Systemen die Daten hin- und herfliessen. Die Pfeilrichtung symbolisiert dabei die Datenflussrichtung.
ETZ (DMZ)
SSZ
Service Subdomain
Application Subdomain
BV-Netz
Internet
Anwendung
SSZ
Client
Internet
Client
BV Netz
Datenbank
SSZ
Interne
Basis-
dienste
BV-Netz (Teil des BV)
Kantonsnetze
SSZ
ETZ (DMZ) /
Partnernetze
Netz-Domänen
S.n
1a, 1c
Datenaustausch
System2a, 2c
Server
Client
Systembeschreibung
Datenfluss
Jumphost
Fire
wa
ll Zo
ne
ng
ren
ze
SS
Z
Fire
wa
ll Ma
na
ge
me
ntz
on
e
Fire
wa
ll
Zo
ne
ng
ren
ze
KT
V
We
b A
pp
lica
tion
Fire
wa
ll (nu
r HT
TP
s)
Identity Subdomain
VerzeichnisdienstReadonly
Domain Controller
1b
2b
S.n Systembeschreibung
Fire
wa
ll
Zo
ne
ng
ren
ze
ET
Z
Abbildung 15: Datenflussdiagramm 32
Mit den Nummern werden die einzelnen Schritte eines Transfers aufgezeigt und näher erklärt.
32
Eigene Darstellung
29
5.3.8 Schnittstellen
In diesem Kapitel soll aufgezeigt werden, welche Möglichkeiten die Entwickler haben, mit dem entsprechenden Entwurfsmuster zu interagieren. Dabei werden Schnittstellen in sehr summarischer Art und Weise gezeichnet. Weiter werden – falls möglich – für die verbreiteten Sprachen Java und C# mögliche Frameworks, APIs, Klassen oder Interfaces aufgezeigt, welche für die Interaktion mit dem Entwurfsmuster verwendet werden können. Eine grafische Darstellung der möglichen Schnittstellen kann wie folgt ausschauen:
Framework
WebDAV Client LibraryAnwendung API Aufrufe
sFTP Client LibraryAnwendung API Aufrufe
FTPs Client LibraryAnwendung API Aufrufe
DatenaustauschService
HTTPs
FTPs
sFTP
Abbildung 16: Schnittstellen 33
Die Darstellung der Schnittstellen zeigt die möglichen Libraries, welche von der Anwendung via API Aufrufe angesprochen werden können und danach über die definierten Protokolle mit dem Service zu sprechen vermögen.
5.3.9 Weitere Punkte
Es gibt weitere Punkte, welche in allen Entwurfsmustern zumindest kurz angeschnitten werden müssen:
- Schnittstellen zu anderen Entwurfsmustern oder Schnittstellen, welche von anderen Entwurfsmustern bezogen werden müssen.
- Sicherheit: Wo nötig, werden spezifische Sicherheitsmassnahmen definiert, welche eingehalten werden müssen, damit das Entwurfsmuster den nötigen Sicherheitsstand erreicht. Es sollen jedoch auch generische Sicherheitsentwurfsmuster geschrieben werden, die mit beliebigen anderen Enterprise Design Patterns kombiniert werden können.
- Prozesse: Sind bestimmte Prozesse nötig, damit ein Entwurfsmuster für IKT Architekturen funktioniert, werden diese kurz aufgeführt.
33
Eigene Darstellung
30
5.4 Resultierender Kontext
Der resultierende Kontext beschreibt die Einbettung des Entwurfsmusters in die IT-Unternehmensarchitektur. Dies wird grafisch gemacht und zeigt, wo das Entwurfsmuster Schnittstellen anbietet und von welchen benachbarten Entwurfsmustern es an deren Schnittstellen andockt. Die grafische Darstellung dieser Verhältnisse ist wie folgt:
Sicherer Datenaustausch Service
Java EE Anwendungen .NET Anwendungen
Sichere Netzwerkarchitektur
mit ZonenIdentity Management Service Access Management
Generisches Security
Enterprise Architecture
Pattern
Abbildung 17: Resultierender Kontext 34
Zu dieser Grafik ist anzumerken, dass sie nicht die gesamte IT-Landschaft zu zeigen vermag. Sie beschränkt sich darauf, die mit dem vorgestellten Entwurfsmuster (in rot) in einer Beziehung stehenden Enterprise Architecture Patterns aufzuzeigen. Das erwähnte Generische Enterprise Security Pattern wird in der vorliegenden Arbeit nicht behandelt. Die Idee ist es, in einem Entwurfsmuster die nötigen Vorkehrungen aufzuzeigen, damit jeweils das diskutierte Entwurfsmuster davon entlastet ist. Das Generische Enterprise Security Pattern behandelt sicherheitstechnische Grundsätze, wie z.B. die Rechtevergabe zu erfolgen hat oder welche Controls eingesetzt werden müssen. Weiter werden im resultierenden Kontext folgende Punkte behandelt:
- Die Konsequenzen des Einsatzes des Entwurfsmusters zeigen, was es bedeutet, das jeweilige Enterprise Design Pattern einzusetzen, welche Vorteile generiert werden und welche allfälligen Nachteile zu gewärtigen sind.
- Risiken: Es werden die Umsetzungsrisiken sowie die Risiken im späteren Einsatz eines Entwurfsmusters diskutiert.
- Schliesslich soll auch auf Konflikte mit anderen Entwurfsmustern hingewiesen werden.
34
Eigene Darstellung
31
5.5 Abschluss
5.5.1 Bekannte Verwendungen
Das Kapitel über bekannte Verwendungen legt dar, ob und wie das vorgestellte Entwurfsmuster bereits verwendet wird.
5.5.2 Verwandte Entwurfsmuster
Die mit dem vorliegenden Pattern verwandten Entwurfsmuster werden hier aufgelistet.
5.5.3 Eignung des Entwurfsmusters:
Der Erfolg eines Entwurfsmusters sollte vor, während und nach der Einführung gemessen werden. Folgende Punkte sollen einen Hinweis auf die Eignung und den konkreten Nutzen des Musters geben:
- Interview mit einem Stakeholder: Das Statement eines Stakeholders soll einen Hinweis auf die Qualität und Akzeptanz des diskutierten Entwurfsmusters für IKT Architekturen im BIT geben.
- Fragenkatalog für die Eignung des Musters in einem spezifischen Umfeld. Der kurze Fragenkatalog soll als Grundlage für die Prüfung dienen, ob ein Entwurfsmuster in einer Firma erfolgreich eingeführt werden kann oder ob Gründe vorliegen, dies nicht zu tun.
- Fragenkatalog für die Prüfung des Erfolgs des Entwurfsmusters nach dessen Einführung. Diese Fragen sollen dem Unternehmensarchitekten eine Beurteilung erlauben, ob ein Entwurfsmuster erfolgreich eingeführt wurde und ob es seine Wirkung zu entfalten vermag.
5.5.4 Begründung und Zusammenfassung
Als letztes Kapitel folgen eine Begründung, wieso das vorliegende Entwurfsmuster Sinn macht und eingesetzt werden sollte, sowie eine kurze Zusammenfassung.
6 Qualitative Anforderungen an Enterprise Architecture Patterns
Die Entwurfsmuster müssen folgende Punkte bezüglich Qualität einhalten:
- Klarer, möglichst gleich gehaltener Aufbau gemäss Kapitel 5.
- Vollständigkeit und Kompatibilität der Schnittstellen zu den anderen Patterns.
- Eignung der eingesetzten Technologien in Bezug auf die gesetzten Ziele und Anforderungen.
- Übereinstimmung der Muster mit einem Best Practice Vorgehen nach Herstellervorgaben und/oder Community Vorgaben.
- Die Liste der für eine Firma zu realisierenden Entwurfsmuster für IKT Architekturen muss ein konsistentes Gesamtbild ergeben.
- Für jedes Entwurfsmuster für IKT Architekturen wird ein Stakeholder befragt, der eine Aussage darüber macht, ob das Muster für seine konkrete Tätigkeit sinnvoll und nutzbringend ist und ob er sich vorstellen kann, dieses in seinen Projekten zu nutzen.
32
7 Kategorisierung Ausgehend vom angepassten TRM des BIT mit den Hauptkategorien
- Infrastructure Services / Plattform Services - Integration Services - Application Services - Security Services
können einzelne Entwurfsmuster für IKT Architekturen oder Gruppen solcher Muster definiert werden:
Abbildung 18: Vom TRM zu den Entwurfsmustern35
Da einzelne Gruppen, z.B. Identity Provisioning Services, zu gross sind, um in einem Entwurfsmuster beschrieben zu werden, macht es Sinn diese aufzuteilen.
35
Eigene Darstellung
33
7.1 Zu beschreibende Enterprise Architecture Patterns
Anhand der technischen Services des TRM können folgende Kandidaten für Enterprise Architecture Patterns bestimmt werden. Die Kategorie der Enterprise Architecture Patterns entspricht dabei den Hauptkomponenten des TRM. Als Stakeholder wird der Haupt-Stakeholder aufgeführt, der für die Umsetzung und den Life Cycle des Musters verantwortlich ist. Maximal werden zwei Rollen aufgeführt. Es ist jedoch klar –und wird dann in den Mustern auch so ausgewiesen – dass das jeweilige Enterprise Architecture Pattern auch für andere Personen oder Rollen von Wichtigkeit ist. Die Spalte „Muss― legt fest, welche Entwurfsmuster im Rahmen der vorliegenden Arbeit aufgezeigt werden.
7.1.1 Enterprise Architecture Pattern für Infrastructure Services
Name Kategorie Stakeholder Kurzbeschreibung Muss
Sichere Netzwerk-architektur mit Zonen
Infrastructure Services
Netzwerk Engineering
Beschreibt den globalen Aufbau eines Netzwerkes mit den benötigten Zonen
x
Gesicherte Netzwerkzone in einer DMZ
Infrastructure Services
Netzwerk Engineering
Beschreibt alle Elemente, sowie den Aufbau von Layer 2 bis Layer 7 sowie die Datenflüsse für DMZ Zonen.
Netzwerkzone für Clients
Infrastructure Services
Netzwerk Engineering, Client Engineering
Beschreibt alle Elemente, sowie den Aufbau von Layer 2 bis Layer 7 sowie die Datenflüsse für Client Netzwerk Zonen.
Netzwerkzone für Server
Infrastructure Services
Netzwerk Engineering, Server Engineering
Beschreibt alle Elemente, sowie den Aufbau von Layer 2 bis Layer 7 sowie die Datenflüsse für Server Netzwerk Zonen.
Access Management
Infrastructure Services
Netzwerk Engineering,
Beschreibt alle nötigen Elemente für ein Access Management. Dieser gewährt Zugang zu Netzzonen und Applikationen mit unter-schiedlichen Authentisierungsmethoden.
x
Identity Management Service
Infrastructure Services
Directory Services Engineering
Beschreibt die Elemente und Prozesse, welche für die Erfassung, Verwaltung und Bereitstellung von Identitäten nötig sind.
x
34
Name Kategorie Stakeholder Kurzbeschreibung Muss
Datenbank Plattformen
Infrastructure Services
Datenbank Engineering
Beschreibt alle für eine Datenbankplattform nötigen Elemente und deren Interaktionen.
Datenhaltung mit SAN, NAS und DAS
Infrastructure Services
Storage Engineering, Netzwerk Engineering
Beschreibt alle für die Datenhaltung nötigen Elemente inklusive Backupverfahren. Ein weiteres Augenmerk liegt auf den Interaktionen der Elemente, sowie der nötigen Prozesse.
7.1.2 Enterprise Architecture Pattern für Plattform Services
Name Kategorie Stakeholder Kurzbeschreibung Muss
Monitoring Service
Plattform Services
Server Engineering, Netzwerk Engineering
Beschreibt die Elemente, welche für ein Monitoring der Systeme und Services nötig sind.
Management Service
Plattform Services
Server Engineering, Netzwerk Engineering
Beschreibt die Elemente, welche für das Management der Systeme und Services nötig sind.
Deployment Services
Plattform Services
Server Engineering, Client Engineering
Beschreibt die Elemente, welche für die Installation und die Softwareverwaltung benötigt werden.
7.1.3 Enterprise Architecture Pattern für Integration Services
Name Kategorie Stakeholder Kurzbeschreibung Muss
Enterprise Service Bus
Integration Service
Server Engineering, Software Entwickler
Beschreibt die nötigen Elemente für den Aufbau und den Betrieb eines ESB (Enterprise Service Bus).
Portal Service Integration Services
Server Engineering, Web Entwickler
Beschreibt die für den Aufbau eines Webportals benötigten Elemente.
Sicherer Daten Austausch Service
Integration Service
Server Engineering, Software Entwickler
Beschreibt, welche Elemente für den Betrieb einer Austauschplattform für Daten verschiedenster Art und Form (Datendrehscheibe) nötig sind.
x
Data Warehousing
Integration Service
Software Entwickler, Datenbank Engineering
Beschreibt die für ein Data Warehouse nötigen Elemente und Konzepte.
35
7.1.4 Entwurfsmuster für Application Services
Name Kategorie Stakeholder Kurzbeschreibung Muss
Weban-wendungen auf der Basis von .NET
Application Services
Server Engineering, Software Entwickler
Beschreibt die Elemente (Serverdienste, Frameworks, Entwicklungsumgebungen), welche für die Entwicklung von Webanwendungen auf der Basis von .NET nötig sind.
Weban-wendungen auf der Basis von Java EE
Application Services
Server Engineering, Software Entwickler
Beschreibt die Elemente (Serverdienste, Frameworks, Entwicklungsumgebungen), welche für die Entwicklung von Webanwendungen auf der Basis von Java EE nötig sind.
x
Messaging und Groupware
Application Services
Server Engineering, Netzwerk Engineering
Beschreibt die Elemente eines Messaging Backbones mit einer Groupware Erweiterung auf der Basis von Microsoft Exchange.
7.1.5 Entwurfsmuster für Security Services
Name Kategorie Stakeholder Kurzbeschreibung Muss
Spam- und Malware Schutz
Security Services
Server Engineering, Security Officer
Beschreibt die Konzeption und die nötigen Elemente, um eine IKT Infrastruktur erfolgreich gegen Spam und Malware zu schützen.
Firewall Infrastruktur
Security Services
Netzwerk Engineering, Security Officer
Beschreibt die Elemente einer Firewall Infrastruktur, welche die verschiedenen Netzgrenzen (interne und externe Grenzen) effizient gegen Angriffe und Datenabfluss schützt.
Intrusion Detection
Security Services
Netzwerk Engineering, Security Officer
Beschreibt die Elemente eines Intrusion Detection Systems, sowohl Hostbasiert wie auch Netzbasiert.
PKI Services Security Services
PKI Engineering, Security Officer
Beschreibt die Elemente für die Etablierung einer Public Key Infrastruktur.
36
8 Zusammenfassung Entwurfsmuster für IKT Architekturen sind ein aus Sicht des Autors ein sehr sinnvoller und effizienter Ansatz, die Ziele und Vorgaben der IT-Unternehmens-architekten in der Firma umzusetzen und zu verankern. Die Enterprise Architecture Patterns erfüllen konkret folgende Aufgaben:
- Planungsgrundlage für die IKT Infrastrukturen: Erarbeiten von Plänen („Blue Prints―) für den Aufbau der IKT Architektur in einer Firma.
- Schaffen einer Diskussionsgrundlage und Anregen der Diskussion innerhalb der Firma.
- Ordnungselement: Ein Entwurfsmuster für IKT Architekturen hilft dabei, Ordnung in die Informatik einer Firma zu bringen, indem es einen Rahmen setzt, innerhalb dessen sich die IT zu entwickeln hat.
- Abstimmung zwischen den einzelnen Elementen einer IKT Architektur. Durch die Definition der zu verwendenden Protokolle und Schnittstellen wird Klarheit darüber geschaffen, wie die einzelnen Elemente einer Informatiklandschaft miteinander gekoppelt werden können.
- Verhindern von Doppelspurigkeiten: Durch die Definition der Entwurfsmuster können sich wiederholt stellende Probleme abgefangen und einer einmalig zu bauenden Lösung zugeführt werden. Dies führt mittel- bis langfristig zu grossen Kosteneinsparungen.
- Hilfestellung für Projektleiter, Software Architekten und andere Personen, die in den Entwurf und die Produktion von neuen Anwendungen und Infrastrukturen involviert sind.
- Schaffen einer Referenzgrundlage für die Prüfung von bestehenden IKT Architekturen.
Ein Enterprise Architecture Pattern muss mindestens folgende Elemente enthalten:
- einen möglichst aussagekräftigen Namen - die Problemstellung - den Kontext - die Lösungsfindung - den resultierenden Kontext - bekannte Verwendungen und verwandte Patterns - Angaben zur Prüfung des Entwurfsmusters
Einer der wichtigsten Effekte der Einführung eines Entwurfsmusters für IKT Architekturen ist, dass eine gemeinsame Sprache zwischen den verschiedenen Stakeholdern gesucht und gefördert wird.
37
9 Abschliessende Gedanken Das Potential der Beschreibung der einzelnen Komponenten einer IT Landschaft in einer Unternehmung mit Hilfe von Entwurfsmustern ist nach Ansicht des Autors durch die vorliegende Arbeit aufgezeigt worden. Einige Punkte müssen jedoch noch verbessert werden, bevor Enterprise Architecture Patterns ihren Platz in der IT Unternehmensarchitektur einnehmen können, namentlich sind dies:
- Das Ziel, dass jedes Entwurfsmuster immer den möglichst gleichen Aufbau hat, führt dazu, dass sich stellenweise die wirklich relevanten Teile erst nach weniger wichtigen Passagen finden. So enthält jedes Muster den grundsätzlichen Aufbau Netze – System – Anwendung, was bei einem Pattern, das eine Anwendungsentwicklung beschreibt zum oben erwähnten Effekt führt.
- Ein prüfenswerter Ausweg aus dieser Problematik wäre es, grundsätzliche Muster für die Hauptkomponenten der IT Landschaft zu definieren, z.B. je ein Mustertyp für Application Services, Integration Services, Plattform Services und Security Services. Innerhalb eines solchen Haupttyps bleibt der Aufbau immer gleich, zwischen den Haupttypen darf er sich unterscheiden.
- Es braucht innerhalb des Entwurfsmuster eine vertiefte Analyse, wie das Muster einzuführen und der Einführungserfolg zu messen ist. Dies ist momentan nur durch einen Fragenkatalog abgedeckt, es fehlt aber eine Metrik mit quantifizierbaren Indikatoren, welche den Erfolg zu messen vermag.
- Die Muster müssen ihren Platz in den Projektabläufen, insbesondere in einer Architekturkonformitätsprüfung finden.
- Eine tiefere Einbettung in ein Architekturframework wie TOGAF ist zumindest zu prüfen.
- Die Schnittstellen zwischen den einzelnen Entwurfsmustern müssen standardisiert und weiter ausgearbeitet werden.
- Durch die zeitliche Beschränkung der Diplomarbeit fehlen noch einige grundlegende Entwurfsmuster, wie z.B. ein Entwurfsmuster für die Büroautomation.
- Die vorliegenden Muster sind aus Anforderungen des BIT entstanden und wurden durch das technische und organisatorische Umfeld des BIT beeinflusst. Dieser Punkt muss noch weiter abstrahiert werden.
- Die Entwurfsmuster sind noch zu stark geprägt von persönlichen Erfahrungen des Autors, insbesondere der immer wieder kehrende Fokus auf der Security.
Abschliessend soll festgehalten werden, dass der Gedanke von wiederholbaren Mustern, welche verhindern, dass jedes Mal das Rad neu erfunden werden muss, faszinierend und eine vertiefte Beschäftigung mit dieser Idee in jedem Fall lohnenswert ist.
38
10 Anhang
10.1 Abbildungsverzeichnis
Abbildung 1: Pyramide ............................................................................................... 8
Abbildung 2: ADM ...................................................................................................... 9 Abbildung 3: Enterprise Continuum ......................................................................... 10
Abbildung 4: Komponenten eines TRM ................................................................... 11 Abbildung 5: TOGAF TRM ........................................................................................ 12
Abbildung 6: Vereinfachtes TRM .............................................................................. 13 Abbildung 7: TRM und Patterns ............................................................................... 13
Abbildung 8: Sichten und Stakeholder ...................................................................... 16 Abbildung 9: Externe und interne Kräfte .................................................................. 17
Abbildung 10: Kräftediagramm ................................................................................ 18 Abbildung 11: Systemaufbau ................................................................................... 24
Abbildung 12: Use Case mit Systemgrenzen .......................................................... 25 Abbildung 13: Zonendiagramm ................................................................................ 26
Abbildung 14: Verbindungsaufbaudiagramm ........................................................... 27 Abbildung 15: Datenflussdiagramm ......................................................................... 28
Abbildung 16: Schnittstellen .................................................................................... 29 Abbildung 17: Resultierender Kontext ..................................................................... 30
Abbildung 18: Vom TRM zu den Entwurfsmustern ................................................... 32
10.2 Literaturverzeichnis
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. Rachel Harrison; 2007, TOGAF 8.1.1. Zaltbommel: Van Haren Publishing Pallab Saha: Analyzing The Open Group Architecture Framework from the GERAM Perspective, http://www.opengroup.org/architecture/wp/saha/TOGAF_GERAM_Mapping.htm Wolfgang Johannsen, Matthias Goeken; 2007, Referenzmodelle für IT-Governance IT Governance Institute; 2007, TOGAF mapping with COBIT Research, S. 26. Rolling Meadows: ITGI 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] Kent Beck, Ward Cunningham; 1987, Technical Report No. CR-87-43, http://c2.com/doc/oopsla87.html. [Letzter Aufruf: August 2008] Gamma et al.;1994, Design Patterns: Elements of Reusable Object-Oriented Software. Old Tappan: AddisonWesley