Entwurfsmuster für IKT Architekturen -...

Diplomarbeit

Entwurfsmuster für IKT Architekturen - Theorieteil

Verfasser: Reto Inversini

Klasse MAS-06-02 Nummer MAS-06-01.13

Bridelstrasse 12 3008 Bern

[email protected]

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.



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.



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:


Integration 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


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


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


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


Netzwerk Engineering

Beschreibt den globalen Aufbau eines Netzwerkes mit den benötigten Zonen

x

Gesicherte Netzwerkzone in einer DMZ


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


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


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


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


Directory Services Engineering

Beschreibt die Elemente und Prozesse, welche für die Erfassung, Verwaltung und Bereitstellung von Identitäten nötig sind.

x

34


Datenbank Plattformen


Datenbank Engineering

Beschreibt alle für eine Datenbankplattform nötigen Elemente und deren Interaktionen.

Datenhaltung mit SAN, NAS und DAS


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


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


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


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


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


Weban-wendungen auf der Basis von .NET



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



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



Beschreibt die Elemente eines Messaging Backbones mit einer Groupware Erweiterung auf der Basis von Microsoft Exchange.

7.1.5 Entwurfsmuster für Security Services


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

Entwurfsmuster für IKT Architekturen -...

Documents

Transcript of Entwurfsmuster für IKT Architekturen -...