It Arch Pattern

Diplomarbeit

IT-Architekturen zur Integration

heterogener Applikationen im Unternehmen

– Verwendbarkeit von Mustern

für die IT-Architekturgestaltung

Referent:

Dr. Joachim Schelp

Verfasser:

Marco Fischbacher

Abgabetermin: 23. August 2002

Universität St. Gallen

Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften (HSG)

I

Inhaltsverzeichnis

1

Einleitung

1

1.1

Problemstellung

1

1.2

Aufbau dieser Arbeit

2

1.3

Eingrenzung des Themas 3

1.4

Begriffsdefinitionen 4

1.4.1 Architektur

4

1.4.2 Informationssystem 4

1.4.3 Prozess 4

1.4.4 Applikation 5

1.4.5 Software 5

2

Integration heterogener Applikationen

6

2.1

Einleitung

6

2.2

Ebenen des Business Engineering 6

2.3

Anwendungsintegration (EAI) 7

2.3.1 homogene Applikationen

7

2.3.2 heterogene Applikationen

8

2.4

Dimensionen der Integration

9

2.5

Zusammenfassung 11

3

IT-Architekturen

12

3.1

Was ist Architektur?

12

3.2

Architekturplanung

13

3.3

Architektur-Schulen 14

3.3.1 Zachman Framework

14

3.3.2 4+1 View Model 15

3.3.3 Softwarearchitektur nach Carnegie Mellon 16

3.4

Was ist Software Engineering? 17

3.5

Architektur vs. Engineering 18

3.6

Zusammenfassung 18

II

4

Muster

19

4.1

Einleitung

19

4.2

Was sind Muster? 19

4.3

Muster und Mustersprachen nach Alexander

20

4.4

Geschichte der Muster im Software-Engineering

21

4.5

Framework

22

4.6

Dokumentation von Mustern 23

4.7

Zusammenfassung 27

5

Muster im Software Engineering

28

5.1

Einleitung

28

5.2

Analysemuster 28

5.3

Entwurfsmuster 29

5.3.1 Gang of Four 29

5.3.2 Gang of Five 30

5.3.3 Riehle/Züllighoven 31

5.4

Anwendung der Entwurfsmuster

32

5.5

Organisations- und Prozessmuster (Coplien)

33

5.6

Muster zur Prozessverbesserung (Appleton)

34

6

Architekturmuster und andere Muster

35

6.1

Einleitung

35

6.2

Softwarearchitektur-Muster (Carnegie Mellon)

35

6.3

EAI Architekturmuster (Lutz)

36

6.4

Musterbasierte Integrationsarchitekturen (Mularz)

37

6.5

Daten- und methodenbasierte Muster (Linthicum)

37

6.6

Muster zur Umsetzung der Architektur (Dikel et al.)

38

6.7

Strategie-Muster (King)

39

6.8

Musterbasiertes Reengineering (Beedle)

40

6.9

Integrationsmodelle (Brown)

42

6.10

Datenmodellierungsmuster (Hay)

42

6.11

Unterstützungsmuster (Fowler)

43

6.12

Schichtenarchitekurmuster

44

III

7

Architekturgestaltung

45

7.1

Einleitung

45

7.2

Business Engineering

45

7.3

Software Engineering 45

7.4

Implementation einer EAI-Architektur

46

7.5

Mögliches Vorgehen bei der IT-Architekturgestaltung

47

7.6

Muster zur Unterstützung der Architekturgestaltung

49

8

Schlussbetrachtung

51

8.1

Zusammenfassung 51

8.2

Schlussfolgerungen

52

Literaturverzeichnis

53

Anhang

59

IV

Abbildungsverzeichnis

Abbildung 1: Aufbau der Arbeit

2

Abbildung 2: Stufen der Integration nach Kosanke

3

Abbildung 3: Metamodell des Business Engineering bei Österle

6

Abbildung 4: Dimensionen der Integration nach Hasselbring

10

Abbildung 5: Begriffe der Softwarearchitektur bei Garlan

13

Abbildung

6: Zachman Framework

14

Abbildung 7: 4+1 View Model

16

Abbildung 8: Klassifikation von Softwarearchitektur-Muster

36

Abbildung 9: Databasierte vs. methodenbasierte Integration

38

Abbildung 10: Ausprägungen bei multinationalen Unternehmen

40

Abbildung 11: Objektorientiertes Zachman Framework nach Beedle

41

Abbildung 12: Beziehung des Business Engineering zum Software Engineering

47

V

Abkürzungsverzeichnis

ADL

Architecture Description Language

bzw.

beziehungsweise

CASE

Computer Aided Software Engineering

CORBA

Common Request Broker Architecture

EAI

Enterprise Application Integration, Anwendungsintegration oder Integration betrieblicher Anwendungssysteme

d.h.

das heisst

eds.

editors, Herausgeber

e.g.

example given (zum Beispiel)

et al.

et alii, und andere

f.

folgend

ff.

fortfolgend

GoF

„Gang of Four“, die vier Verfasser des Buches „Design Patterns: Elements of Reusable Object-Oriented Software“

GoV

„Gang of Five“, die fünf Verfasser des Buches „Pattern-oriented Software Architecture: A System of Patterns”

Hrsg.

Herausgeber

IS

Informationssystem

I-SPI

Initiating Software Process Improvement

IT

Information Technology, Informationstechnologie

ODBC

Open Database Connectivity

OMT

Object-Modelling-Technique

PLoP

Pattern Languages of Programs

RPC

Remote Procedure Call

S.

Seite

Übers.

Übersetzunng

UML

Unified Modeling Language

USA

United States of America, Vereinigte Staaten von Amerika

u.ä.

und ähnliches

vgl.

vergleiche

VRAPS

Vision, Rhythm, Anticipation, Partnering, Simplification

vs.

versus

z.B.

zum Beispiel

1

1

Einleitung

1.1 Problemstellung

Um den Wettbewerbsvorsprung zu wahren, haben Unternehmen heute eine Reihe von Herausforderungen zu meistern. Ständig steigender Komplexität stehen immer kürzere verfügbare Reaktionszeiten gegenüber (Gomez & Probst 1995, S. 216). Um erfolgreich zu sein, müssen die Unternehmen jederzeit flexibel auf die Herausforderungen reagieren können. Kenntnisse der operativen und finanziellen Effektivität im Unternehmen, sind überlebenswichtig geworden (Österle 1995, S. 107ff.).

Viele Unternehmen befinden sich mitten in der Transformation von der Industrie- in die Informationsgesellschaft. Die Informationsgesellschaft ermöglicht neue Geschäftslösungen. So richten sich immer mehr Unternehmen am Kundenprozess aus und verabschieden sich von der innengerichteten Sicht des Produktportfolios (Österle & Winter 2000, S. 4ff.).

Alle diese Herausforderungen sollen durch das Informationssystem unterstützt oder gar erst ermöglicht werden. Die Reorganisation der Prozesse und Ausrichtung auf den Kunden erfordert, dass immer mehr Daten zwischen verschiedenen Abteilungen über eine Vielzahl heterogener Applikationen und Computersysteme ausgetauscht werden. Informa- tionssysteme sollen flexibel sein und sich ans Umfeld anpassen lassen. Kenntnisse der operativen und finanziellen Effektivität lassen sich nur durch Zusammenführen verschiedenster Daten erlangen. Die IT-Verantwortlichkeit in den Unternehmen lag lange in den Fachabteilungen und es gab keine IT-Architektur auf Unternehmensebene. Die Folge waren autonome nicht integrierte Applikationen (Linthicum 2000, S. 7).

In den letzten Jahren fand aber noch eine andere Entwicklung statt. Hatte man mit dem Aufkommen der ERP-Systeme noch voller Enthusiasmus gehofft, die verschiedensten Systeme durch eine einheitliche integrierte Lösung zu ersetzen, so ist diese Vision heute verflogen. ERP-Systeme erfüllen weder alle Geschäftsanforderungen, noch alle IT- Anforderungen. Unternehmungen geben daher ihre bestehenden Applikationen nicht auf, wenn sie ERP-Systeme einführen (Themistocleous & Irani 2001, S. 321).

Die Bedeutung der IT-Architekturplanung ist heute erkannt, da es nicht mehr möglich ist die Vielzahl der Systeme mit eins-zu-eins-Verbindungen zu integrieren oder gar abge- trennte Applikationen zu betreiben. Die Architekturplanung befasst sich nicht nur mit der technischen Integration und der Ausgestaltung entsprechender Schnittstellen zwischen Applikationen. Die Architekturplanung soll sich an den Geschäftsanforderungen ausrichten. Prozessneugestaltungen, sogenannte Business Process (Re-)Engineering-Projekte (Hammer & Champy 1993), beeinflussen die Anforderungen an die Informationssystem- Architektur. Die vielfältigen Herausforderungen an eine IT-Architektur lassen die Frage aufkommen, inwiefern Konzepte einmal bewährter Lösungen wiederverwendbar werden. Muster sind eine Möglichkeit dazu.

2

1.2 Aufbau dieser Arbeit

Die Themenstellung „IT-Architekturen zur Integration heterogener Applikationen im Un- ternehmen – Verwendbarkeit von Mustern für die IT-Architekturgestaltung“ legt eine Gliederung an den Begriffen nahe. Dazu wird erst der Integrationsbegriff genauer be- leuchtet. Es erfolgt dabei die Einschränkung auf intra-organisationale Integration gemäss der Themenstellung. Ausserdem wird erläutert, was unter Heterogenität zu verstehen ist und warum es Heterogenität in Informationssystemen gibt. Das folgende Kapitel befasst sich mit den Aufgaben der IT-Architektur und grenzt diese vom Software-Engineering ab. Das Software Engineering verfügt auf der technischen Ebene der Integration bereits über viele Muster. Die entstandene Community hat die Idee von Mustern zur Wiederverwen- dung von bewährten Lösungen vorangetrieben. Im dritten Kapitel wird in die Theorie von Mustern eingeführt.

Abbildung 1: Aufbau der Arbeit

Integration

IT-Architektur

Muster

Muster im Software Engineering

Architekturmuster und andere Muster

Vorgehen IT-Architekturgestaltung Verwendbarkeit von Mustern Schlussfolgerungen

Im weiteren Verlauf werden dann verschiedene Typen von Mustern aus der Literatur vorgestellt. Im 4. Kapitel werden die Entwurfsmuster vorgestellt. Sie sind zuerst entstanden. Danach werden verschiedene andere Musteransätze vorgestellt, die für die ganzheitliche IT-Architekturgestaltung von Bedeutung sein können. Dabei handelt es sich um Ansätze der organisatorischen Gestaltung und Prozessumgestaltung, zur Strategiebe- stimmung, um Integrationsmuster und Muster zur Datenmodellierung.

Das Ziel dieser Arbeit, die Verwendbarkeit von Mustern zur IT-Architekturgestaltung zu prüfen, wird dann im siebten Kapitel vorgenommen. In Anlehnung an ein Vorgehensmodell zur IT-Architekturplanung werden die Muster den Phasen zugeordnet.

3

1.3 Eingrenzung des Themas

Auf die Thematik der Integration und der IT-Architekturgestaltung gibt es grundsätzlich zwei Blickwinkel, die Technologiesicht und die Geschäftssicht. Während erstere insbesondere von der klassischen Informatik bearbeitet wird, befasst sich mit letzterer die Betriebswirtschaft in den Bereichen Organisation und Wirtschaftsinformatik. In der vor- liegenden Arbeit wird Literatur aus beiden Gebieten bearbeitet. Verschiedene Autoren ¹ verallgemeinern die technischen Entwurfsmuster aus dem Software Engineering und schlagen sie dann als Architekturmuster vor. In dieser Arbeit wird gezeigt, dass eine ganzheitliche IT-Architekturgestaltung wesentlich umfangreicher ist und die Abstrahierung der Entwurfsmuster allein die Anforderungen nicht abdeckt. Es wurden daher im Literaturstudium verschiedene Ansätze von Mustern zusammengetragen, die für die verschiedenen Phasen und Ebenen der IT-Architekturgestaltung von Bedeutung sind.

Integration von Applikationen ist nicht zu erreichen, ohne die über- und untergeordnete Ebenen zu beachten. Dementsprechend werden auch übergeordnete Muster zur Integration von Prozessen und Organisationen behandelt. Die Integration von Daten dagegen wird nur am Rande behandelt, da es ein eigenes umfangreiches Themengebiet darstellt. Es wird von der Daten-Modellierung bearbeitet, sowie dem Data Warehousing, wo Datenintegration eine wichtige Rolle spielt. Aktuell ist die Forschung zum Semantik Web, die versucht eine maschinenverständliche Beschreibung der Semantik von Daten zu entwickeln ² .

Abbildung 2: Stufen der Integration nach Kosanke

Enterprise Integration

Business Integration

Application Integration

Physical Integration

ni te rag

tion

evolution

Quelle: Kosanke 1997, S. 64

1

²

So bei Lutz, der sich bewusst an die Entwurfmuster anlehnt (2000, S. 66). Beck & Johnson (1994, S. 2f.) verallgemeinern ebenfalls Entwurfsmuster zu Architekturmuster. Wie wir später sehen werden, beziehen diese Autoren damit den Begriff der Architektur allein auf die Ebene der Softwarearchitektur.

vgl. http://www.w3.org/2001/sw/ (12.08.02).

4

Kosanke et al. (1999, S. 84) ordnen die Applikationsintegration zwischen der Ebene der technischen Integration (physical integration) und der Business Integration ein. Zuoberst steht die Unternehmensintegration, mit welcher sich die Disziplin der Unternehmens- modellierung befasst. Dabei stehen meist produzierende Unternehmen im Vordergrund. Nach Ortiz et al. (1999, S. 156) besteht Unternehmensintegration darin Material-, Infor- mations-, Entscheidungs- und Kontrollflüsse in einer Organisation zu etablieren. Dies mit dem Ziel die Kommunikation, Kooperation und Koordination zu verbessern und zu erreichen, dass das Unternehmen als Gesamtheit und gemäss der Strategie operiert. Zur Modellierung bedient man sich Modellierungsmethoden wie CIMOSA (Open System Architecture for Computer Integrated Manufacturing). Im weiteren Verlaufe wird auf die Unternehmensintegration nicht eingegangen, da es sich um ein eigenes Themengebiet auf einer anderen Abstraktionsebene handelt.

1.4 Begriffsdefinitionen

1.4.1 Architektur

Die Begriffe Architektur oder IT-Architektur werden in dieser Arbeit als Überbegriff für die verschiedensten Konzepte aus der Informationstechnologie wie Unternehmensarchitek- tur, Informationssystemarchitektur, Softwarearchitektur und Applikationsarchitektur verwendet. Eine genaue Abgrenzung der Begriffe folgt später. Falls mit Architektur die Baukunst gemeint ist, werden die Worte Bau-Architektur oder Baukunst verwendet.

1.4.2 Informationssystem

Informationssystem steht häufig als Kurzwort für Informations- und Kommunikations- systeme. Ein Informationssystem unterstützt betriebliche Aufgaben durch Applikationen und Datenbanken (Österle 1995, S. 49). Es bezieht sich nach Leist (2002, S.7) damit auf informatisierbare Informationsmodelle und nicht auf Modelle zur Unterstützung der Organisationsgestaltung. Sinz (1997, S. 861) dagegen versteht unter dem Begriff des Informationssystems ebenfalls den personellen Aufgabenträger „Mensch“. Hier wird aber die Definition von Österle verwendet.

1.4.3 Prozess

Ein Prozess ist eine Abfolge von Aufgaben, die über mehrere organisatorische Einheiten verteilt sein können. Nach Österle ist ein Prozess durch IT-Anwendungen unterstützt und produziert oder konsumiert Leistungen (Österle 1995, S. 19). Das Ergebnis eines Prozesses sind Leistungen, die in in- oder externe andere Prozesse einfliessen.

5

1.4.4 Applikation

Eine Applikation wird im Kontext der Geschäftsapplikationen als Softwareelement definiert, das eine Reihe von eng verwandten Geschäftsfunktionen zur Verfügung stellt (Cummins 2002, S. 53). Eine Geschäftsapplikation ist üblicherweise ein System, das ziemlich unabhängig arbeitet und die von einer Gruppe in einer Unternehmung benötigte Funktionalität zur Verfügung stellt. Die Applikation ist meist verbunden mit einer Datenbank und einer Benutzungsoberfläche. Buschmann et al. definieren eine Applikation als ein Programm oder eine Sammlung von Programmen, die eine Kundenanforderung erfüllen (1996, S. 433). Applikationen können dabei zugekaufte Standardsoftware oder Eigenentwicklungen sein (Österle et. al 1992, S. 373).

1.4.5 Software

Software vom Englischen „weiche Ware“ wird gemäss Fremdwörter-Duden (1990) definiert als die zum Betrieb einer Datenverarbeitungsanlage erforderlichen nichtappara- tiven Funktionsbestandteile (Einsatzanweisungen, Programme u.ä.). Besser erscheint mir die Definition von Balzert (2001, S. 45). Er definiert Software, als Programme, zugehörige Daten und notwendige Dokumentationen, die es zusammengefasst erlauben, mit Hilfe eines Computers Aufgaben zu erledigen.

6

2 Integration heterogener Applikationen

2.1 Einleitung

Nachdem das Thema gegenüber verwandten Gebieten grob abgegrenzt worden ist und wesentliche Grunddefinitionen gegeben wurden, folgt hier der Einstieg in die Thematik. Ziel dieses Kapitels ist es den Begriff der Anwendungsintegration zu definieren, sowie die Problematik der Heterogenität zu erläutern. Zuerst wird das Business Engineering Modell von Österle kurz umrissen.

2.2 Ebenen des Business Engineering

Während die Geschäftsanforderungen einerseits die Integration von Applikationen er- fordern, ermöglicht die Integration andererseits wieder neue Geschäftslösungen. Damit das Informationssystem im Einklang mit der Geschäftsstrategie steht, hat Österle folgendes Business Engineering-Modell entwickelt. Er grenzt dabei drei Ebenen voneinander ab: die Strategie, die Prozesse und das Informationssystem (1995, S. 16ff.). Dabei beschreibt die Strategie den Markt, die strategischen Geschäftsfelder, sowie die Marktleistung des Unternehmens. Auf der Prozessebene werden die Prozessleistung, die Prozessabläufe, sowie die Aufgaben als Bestandteile der Prozesse festgelegt.

Abbildung 3: Metamodell des Business Engineering bei Österle

Strategic

Market

Market

business unit

output

Strategy

Activity

Process

Output

Process

Function

Application

Data collection

IT components

System

Quelle: Österle & Blessing 2000, S. 77

Die Ebene des Informationssystems bildet die Applikationen ab, einschliesslich der unter- stützenden Funktionen, die IT-Komponenten und die Datensammlungen, sowie deren Beziehung untereinander (Leist 2002, S. 13ff.). Diese drei Ebenen beeinflussen sich dabei wechselseitig.

7

Johannesson und Perjons (2001, S. 166) sehen die Daten als weitere Ebene. Anwendungs- integration erlaubt demnach der Daten- und der Prozessebene durch die Applikationsebene über Einzelapplikationen hinaus miteinander zu kommunizieren.

2.3 Anwendungsintegration (EAI)

Die Definition von Johannesson und Perjons ist nur eine von vielen Definitionen der Anwendungsintegration. Hier wird deshalb darauf eingegangen, was Anwendungsintegra- tion ist.

Enterprise Application Integration (EAI), auf deutsch Integration betrieblicher Anwen- dungssysteme oder Anwendungsintegration, wird auch als Enterprise Integration, Systems Integration (Hasselbring 2000), Value Chain Integration, Supply Chain Integration, Exten- ded Business Integration und e-business Integration (Linthicum 2000) bezeichnet (Themistocleous & Irani 2002, S. 156). Der Begriff der Anwendungsintegration bezieht sich dabei nach Themistocleous und Irani manchmal nur auf die intra-organisationale Integration von ERP-Systemen, während er bei anderen Autoren die Integration aller Standardsoftware oder sogar aller Software in einem Unternehmen meint (2002, S. 157). Letztere Definition benutzt Sprott (2000, S. 68). Bei ihm ist Integration die Fähigkeit einer Applikation jederzeit mit anderer Standard-, Individual- oder bestehender Software zu interagieren. Die Integrationsfähigkeit einer Applikation wird bestimmt durch die Möglich- keiten der Integration und den dafür nötigen Integrationsaufwand.

Linthicum definiert Integration als uneingeschränktes Teilen von Informationen zwischen zwei oder mehreren Unternehmensapplikationen (2000, S. 354). Eine Reihe von Techno- logien erlaubt den Austausch von Informationen zwischen verschiedenen Geschäfts- applikationen und Geschäftsprozessen innerhalb von Organisationen oder zwischen Or- ganisationen. Im Vordergrund dieser Arbeit steht nur die Integration der Informations- systeme innerhalb von Unternehmen, die sogenannte innerbetriebliche Integration. In der innerbetrieblichen Integration werden die Applikationen in zwei Gruppen unterschieden, sogenannte homogene Applikationen und heterogene Applikationen. Die Integrations- problematik ist dabei unterschiedlich.

2.3.1 homogene Applikationen

Homogene Applikationen können unterschieden werden in solche mit einer Instanz und solche mit mehreren Instanzen (Österle 1996, S. 12ff.). Homogene Applikationen sind solche mit einer Instanz, d.h. es besteht eine Applikation mit einer Datenbank. Das Integrationsproblem stellt sich dabei gar nicht. Es besteht erst bei homogenen Applikation- en mit mehreren Instanzen.

Homogene Applikationen mit mehreren Instanzen, sind mehrere gleiche Applikationen auf verschiedenen Rechnern. Sie haben dabei definitionsgemäss gleiche Datenstrukturen. Damit existieren keine semantischen Unterschiede. Zur Lösung der Integration stellt der

8

Softwarehersteller meist spezielle Mechanismen zum Abgleich zur Verfügung (Replika- tionsmechanismen). Dieses Problem kann daher meist einfach gelöst werden. Schwieriger und häufiger stellt sich in der Realität das Problem der Integration heterogener Appli- kationen.

2.3.2 heterogene Applikationen

Heterogen stammt vom Griechischen „heterogenes“, wobei der Wortteil „hetero“ anders, verschieden und „genos“ Klasse, Art bezeichnet. Heterogen bedeutet entsprechend „verschiedenartig“. In Bezug auf Informationssysteme verweist Hasselbring (2000, S. 36f.) auf zwei Ebenen der Heterogenität:

- Auf der technischen Ebene:

unterschiedliche Hardwareplattformen, Betriebssysteme, Datenbankmanagement- systeme und Programmiersprachen.

- Auf der konzeptuellen Ebene:

verschiedene Programmier- und Datenmodelle, unterschiedliches Verständnis und unterschiedliche Modellierung eines Sachverhaltes.

Als Beispiel für Heterogenität auf der konzeptionellen Ebene nennt Hasselbring (2000, S. 36f.) den unterschiedlichen Gebrauch von Begriffen zur Bezeichnung des selben Konzepts (Synonym) oder Gebrauch eines Begriffes für unterschiedliche Konzepte (Homonym). Während sich die Anwendungsintegration (EAI) auch mit Unterschieden auf der semantischen Ebene befasst, dient Middleware dazu die technische Integration und Syntax zu lösen. Die Abgrenzung zwischen Middleware und Anwendungsintegration ist allerdings fliessend und nicht immer eindeutig.

Nach Österle (1996, S. 12ff.) bestehen heterogene Systeme aus verschiedenen Applikatio- nen mit verschiedenen Datensätzen, die von unterschiedlichen Prozessen genutzt werden. Beispiele für heterogene Systeme sind die Kombination von Modulen verschiedener Softwarepakete wie es bei ERP-Systemen in Unternehmen vorkommt.

Die Gründe für Heterogenität sind zahlreich. Auf der Unternehmensebene geschehen Unternehmensfusionen oder -erwerb, wobei Applikationen der beteiligten Unternehmen anschliessend nicht homogenisiert werden (z.B. aus Zeitgründen). Unternehmensintern finden Neuaufteilungen der Geschäftseinheiten statt oder die Ausrichtung auf den Kunden statt Produktorientierung.

Auf der technischen Ebene kann der Wunsch bestehen, dass aus Gründen des Investitions- schutzes alte und neue Hardware in einem Unternehmen nebeneinander besteht (Welter 1993, S. 24). Dazu gilt es die bestehenden autonomen, nicht auf Integration ausgelegten Systeme zu integrieren. Da Dokumentationen und Programmierer mit entsprechender Er- fahrung meist fehlen, wird die Anpassung oder Erweiterung der Systeme erschwert. Nicht umsonst werden die bestehenden autonomen Systeme im Englischen als „Legacy Systeme“ (wörtlich: Erblast-Systeme) bezeichnet. Themistocleous und Irani haben aus der Literatur

9

folgende Gründe zusammengetragen, warum Legacy Systeme dennoch in Gebrauch sind (2001, S. 319):

- keine Zeit um sie zu ersetzen,

- Ersatz wäre mit grossen Risiken verbunden,

- Mangel an IT-Fachkräften mit entsprechenden Kenntnissen,

- Ersatz der Systeme wäre zu teuer,

- es würde zu lange dauern, bis der Nutzen eines Ersatzes realisiert werden könnte ¹ .

Es gibt aber noch weitere Gründe für technische Heterogenität. Manchmal bestehen Spezialapplikationen, die neben bestehenden Informationssystemen auf spezieller Hard- ware oder Betriebssystem laufen. Die Aufteilung von Datenbeständen aus Sicherheits- gründen oder bessere Performance durch Aufteilung der Verarbeitung auf verschiedene Systeme sind weitere technische Gründe (Österle 1996, S. 5).

2.4 Dimensionen der Integration

Heterogenität ist nach Hasselbring (2000, S. 36f.) nur eine der Dimensionen der Anwendungsintegration. Im weiteren gibt es das Problem der Autonomie und der Distribu- tion.

Zur Beseitigung der Autonomie sind organisatorische Anpassungen nötig, da es um Aspekte der Zusammenlegung von Abteilungen und Neuordnung von Prozessen geht, im Modell von Österle also die Prozessebene. Die technischen Möglichkeiten die Autonomie der Systeme zu beseitigen sind beschränkt.

Ein Beispiel dazu ist Fujitsu Computers, das aus Fusion von ICL Personal Computers, Nokia Data, Aquarius International und Siemens Nixdorf entstanden ist (Themistocleous & Irani 2001, S. 321ff.). Fujitsu Computers funktioniert als virtuelles Unternehmen ² . Die Geschäftsprozesse zwischen den verschiedenen Ablegern sollen entsprechend eng abgestimmt sein. Die unterschiedlichen IT-Infrastrukturen und verschiedene Arten die Geschäftsprozesse zu organisieren, führte zu einer Reihe von Problemen, insbesondere zu grosser Kundenunzufriedenheit. Erst der Beschluss der Geschäftsleitung Prozesse neu zu gestalten und die Autonomie der einzelnen Einheiten zu Gunsten einer zentralen IT- Infrastruktur aufzugeben, führte zu verbesserter Kundenzufriedenheit, Kostenersparnissen

¹ Ruh et al. (2001, S. 133) nennen ebenfalls das hohe Risiko der Ablösung bestehender Applikationen, die zu hohen Kosten, der Mangel an IT-Fachwissen und die zu lange Dauer bis ein Vorteil entsteht.

² Ein virtuelles Unternehmen ist ein Zusammenschluss rechtlich selbständiger Unternehmen, die sich für einen bestimmten Zeitraum zusammenschliessen, wobei jedes seine Kernkompetenz einbringt und gegenüber Dritten als einheitliches Unternehmen aufgetreten wird (Österle et al. 2002, S. 415). Der Begriff wird in der Literatur auch verwendet für Unternehmen, welche die ursprünglichen operativen Grenzen verlassen und engere Partnerschaften zu Geschäftspartnern und Kunden aufbauen (Cummins 2002, S. 408). Dabei werden gewisse Aufgaben integriert und andere outgesourct. Diese Definition entspricht eher dem Gebrauch des Begriffs bei Themistocleous und Irani (2001, S. 321ff.)

10

und erhöhter Flexibilität. Diese Veränderung geschah nicht ohne Widerwillen der Mitarbei- tenden, die sich dadurch in ihrer Macht beschnitten fühlten.

Abbildung 4: Dimensionen der Integration nach Hasselbring

common models, structures, standards; wrappers

td

iri

ubs

noit

heterogenity

organizational changes

autonomy

Quelle: Hasselbring 2000, S. 36

Die Distribution von Systemen lässt sich technisch lösen. Dazu existieren Möglichkeiten wie Methodenfernaufrufe (Remote Procedure Calls, kurz: RPC) oder Proxy Services, wo einem Informationssystem die lokale Verfügbarkeit des anderen Systems durch einen Stellvertreter simuliert wird. Heute geläufig sind sogenannte verteilte Objekte über Technologien wie CORBA. Österle (1996, S. 14f.) verweist aber auf die Problematik von Verzögerungen, wenn asynchrone Techniken angewendet werden. So können Verzögerungen im Datenaustausch eine Unterbrechung des Geschäftsprozesses zur Folge haben.

Als dritte Dimension besteht die bereits erwähnte Heterogenität. Auf der technischen Ebene können dabei schnittstellenorientierte Lösungen wie Adapter oder Wrapper über eine standardisierte Schnittstelle bestehende Systeme integrieren. Eine weitere Möglichkeit ist datenbankorientierte Middleware wie ODBC ¹ .

Auf der konzeptuellen Ebene sind mögliche Abhilfen Datenmodelle und festgelegte Strukturierung der Information über Methoden des Datenaustausches (Hasselbring 2000, S. 37). Transaktionsorientierte Technologien wie Applikationsserver unterstützen eine Transaktionssemantik. Wie Sprott (2000, S. 66) schreibt, haben viele Implementations- projekte in den späten neunziger Jahren Zeit- und Kostenbudgets massiv überschritten.

¹ ODBC: Open Database Connectivity; ein Quasistandard, der dafür sorgt, dass unterschiedliche Datenbanken von einem Client angesprochen werden können (Mertens et al.2001, S. 304)

11

Das war üblicherweise nicht ein technisches Problem, sondern auf Unterschiede in Seman- tik und Geschäftsregeln der unterschiedlichen Applikationen, die nie zur Zusammenarbeit ausgelegt wurden, zurückzuführen.

Nichtsdestotrotz bringt Anwendungsintegration klaren Nutzen. Cook nennt die Ver- besserung von Geschäftsprozessen, die Komplexitätsreduktion von Informationssystemen und die Möglichkeit unternehmensweit Prozesse durch gemeinsamen Datenzugriff zu integrieren (1996, S. 56). Nach Ruh et al. (2001, S. 1ff.) ermöglicht Anwendungsintegration neue Lösungen, welche die Wettbewerbsfähigkeit steigern. Die Kundenbeziehung und Beziehungen in der Supply Chain werden verbessert. Ausserdem werden interne Prozesse rationalisiert und kürzere Vorlaufzeiten am Markt geschaffen. Zudem erhöht Anwendungsintegration den Nutzen von bestehenden autonomen Systemen und von eingeführter Standardsoftware. Doch Anwendungsintegration ist eine aussichtslose Kunst, wie Linthicum schreibt (2000, S. 347). Denn viele der Probleme in der Anwendungsintegration hätten sich durch eine gute IT-Architektur verringern lassen.

2.5 Zusammenfassung

Ein Informationssystem besteht aus Applikationen und Daten. Die Integration der Daten ist ein eigenes Themengebiet, das hier nicht behandelt wird. Die Integration von Applika- tionen wird als Anwendungsintegration (Enterprise Application Integration) bezeichnet.

Anwendungsintegration ist hier die Fähigkeit von Applikationen mit anderer Software im Unternehmen zu interagieren. Dazu muss das Problem der Heterogenität, der Distribution und der Autonomie gelöst werden. Heterogenität bezeichnet dabei verschiedenartige Stan- dards auf der technischen Ebene (Hardwareplattformen, Betriebssysteme, Programmier- sprachen), sowie auf der konzeptuellen Ebene (unterschiedliche Programmiermodelle, Mo- dellierungen eines Sachverhalts). Das Problem der Distribution ist durch technische Mass- nahmen zu lösen. Das Problem der Autonomie durch organisatorische Anpassungen. Es gibt daher immer zwei Blickwinkel, die Geschäftssicht und die technische Sicht.

12

3

IT-Architekturen

3.1 Was ist Architektur?

Die Grundlage zur Integration heterogener Applikationen bildet eine entsprechende Archi- tektur. Da der Begriff „Architektur“ in der Literatur uneinheitlich verwendet wird, soll er im folgenden genauer erläutert werden. Häufig wird Architektur als Grobstruktur eines Systems bezeichnet, das sich in Teilsysteme zergliedert, die miteinander in Beziehung stehen (bei Garlan & Shaw 1996, S. 1; Österle et al. 1992, S. 26; Boar 1999, Vorwort XXII). Die Ebenen, auf die sich die Definitionen der verschiedenen Autoren beziehen, sind aber unterschiedlich.

So wird der Begriff Architektur verwendet, um die Struktur einer Gesamt-Unternehmung zu beschreiben, häufig als Enterprise Architecture oder Unternehmensarchitektur benannt. Unternehmensarchitektur soll hier als umfassender Begriff für die Unternehmensstrategie oder Geschäftsebene ¹ , die Prozessebene und das Informationssystem verstanden werden. Leist schreibt dazu (2002, S. 3), die Unternehmensarchitektur umfasse die drei Ge- staltungsebenen Geschäfts-, Prozess- und Applikationsebene (Strategie-, Prozess- und Informationssystemebene bei Österle 1995, S. 16).

Eine Eingrenzung wird durch die Bezeichnung Informationssystemarchitektur vorgenommen. Österle versteht darunter eine Grobstruktur der Organisation, der Geschäfts- funktionen, der Daten, der Applikationen und der Datenbanken (Österle et al. 1992, S. 26). Ausgehend von diesem konzeptionellen Rahmen werden die Organisation, die Applikationen und die Datenbanken entwickelt.

Weitere Autoren grenzen die Architektur noch weiter ein und benutzen Begriffe wie Soft- warearchitektur oder Applikationslandschaft. Der Begriff Applikationslandschaft findet sich bei Winter (2000, S. 130f.). Er betont damit das Zusammenwirken von unterschiedlichen Systemen, den Applikationen, welche die Applikationsarchitektur bilden. Unter Applikationsarchitektur wird in dieser Definition also nicht die Architektur einer einzelnen Applikation verstanden. Diesen Blickwinkel nehmen Garlan und Shaw (1996, S. 1ff.) ein und bezeichnen es als Softwarearchitektur ² . Die Architektur einer Software-Applikation, von den Autoren Software-System genannt, ist demnach eine Ansammlung von Komponenten und der Interaktionen zwischen diesen Komponenten, den sogenannten Konnektoren. Die Zusammenstellung von Komponenten mit Konnektoren wird als Konfi- guration bezeichnet (Garlan & Monroe 1996, S. 3). Mularz (1995, S. 442) benutzt für die

¹ In der Strategieforschung wird, beeinflusst durch die verbreitete Anwendung des Architekturbegriffs auf Informationssysteme, der Begriff Enterprise Architecture immer stärker verwendet (vgl. Veasey 2001).

² Manchmal wird der Begriff Softwarearchitektur als Überbegriff für sämtliche Architekturkonzepte im Rahmen der Informationstechnologie verwendet (vgl. Mowbray 1998). Da Garlan und Shaw den Begriff anders verwenden, wird hier Softwarearchitektur nicht im allgemeinen Sinn gebraucht. Dafür wird der Begriff (IT-)Architektur verwendet.

13

Konnektoren den Begriff der Integrationskomponenten, die im Gegensatz zu den funktionalen Komponenten stehen.

Abbildung 5: Begriffe der Softwarearchitektur bei Garlan

Software Architecture

Configuration

Connector

Component 1

Component 2

Quelle: eigene Darstellung nach Garlan & Monroe 1996

Ausserdem verbindet die Softwarearchitektur die Systemanforderungen mit der Implemen- tation. Garlan (2000, S. 2) spricht von der Brückenfunktion der Architektur zwischen An- forderungen und Programmcode. Garlan und Shaw orientieren sich damit an den Ideen des Software-Engineering.

Zachman et al. (1996, S. 30f.) betonen in ihrer Definition von Architektur besonders den Entwicklungsprozess. Danach gibt die Architektur die Reihenfolge vor, in der entwickelt werden soll und sie definiert ein universell erkennbares Muster. Im Englischen verwendet man dafür den Begriff des „Architecting“, während „Architecture“ den Zustand bezeichnet (Meier & Rechtin 2002, Vorwort VI). Zusammenfassend soll unter Architektur der Zustand, sowie der Entwicklungsprozess verstanden werden. Die Informationssystem- architektur ist die Grobstruktur der Organisation, der Geschäftsfunktionen, der Daten, der Applikationen und der Datenbanken.

Leist (2002, S.19ff.) verwendet die Begriffe von Zustands- und Vorgehensmodellen. Zu- standsmodelle bilden Struktur und Verhalten eines Unternehmens zu einem bestimmten Zeitpunkt ab. Vorgehensmodelle geben dagegen Massnahmen und Aktivitäten wieder, die Zustandsmodelle von einem Ist- zu einem Soll-Zustand überführen (Zeitraumbezug).

3.2 Architekturplanung

Österle schreibt (1995, S. 128): „Die Architekturplanung ist Bestandteil der Strategie- entwicklung. Sie nimmt Geschäftsfelder, Produktsortiment usw. als Ausgangspunkt, leitet daraus die Prozesse ab und beeinflusst ihrerseits die Geschäftsfelder, das Produktsortiment usw.“. Umgekehrt beeinflusst die Wahl eines Client-Server-Computersystems die Produktivität einer Firma, das Humankapital und den Wettbewerbsvorteil (King 1994, S. 71ff.). Österle et al. sehen die Architektur als „Bebauungsplan“ für die Informations-

14

systementwicklung und legen damit die logischen Strukturen des Informationssystems und der Organisation fest (1992, S. 109). Eine Architekturplanung soll ganzheitlich sein und alle Ebenen umfassen. Winter und Baumöl (2000, S. 46) nennen verschiedene Rollen für einen Business Engineer, u. a. der Architekt. Als Architekt übernimmt man die Gestaltung des Veränderungsprozesses aus einer ganzheitlichen Sicht. Das bedeutet Ziele zu setzen, Vorgaben zur Zielerreichung zu machen, die Ressourcen zu planen, Ergebnisse zu über- prüfen und an die Geschäftsleitung zu berichten, sowie den Prozess führend zu begleiten. Obwohl die Architekturplanung Business Engineering einbezieht, ist es wichtig, dass sich die Architektur nicht daran orientiert, sondern vom Organigramm entkoppelt ist (Cook 1996, S. 73). Denn häufig folgt vor Abschluss einer Reorganisation bereits die nächste und die IT-Architektur sollte sich wieder daran anpassen lassen.

3.3 Architektur-Schulen

3.3.1 Zachman Framework

Um einen Einblick über die bekanntesten Konzepte der IT-Architektur zu erhalten, wird hier auf drei bekannte Konzepte eingegangen.

Abbildung 6: Zachman Framework

Zachman Architecture

What?

How?

Where?

Who?

When?

Why?

Framework

Data

Function

Network

People

Time

Motivation

Scope

List of Things important to the business

List of Process. the Business performs

List of Locations in which Busin. operates

List of Organiz. important to the Business

List of Events significant to the Business

List of Business Goals/Strategies

e.g.

e.g. Business

e.g. Business

e.g. Work

e.g.

e.g.

Business Model

Semantic Model

Process Model

Logistics System

Flow Model

Master Schedule

Business Plan

e.g. Logical

e.g. Application

e.g. Distributed

e.g. Human

e.g. Processing

e.g. Business

System Model

Data Model

Architecture

Systems Archit.

Interface Archit.

Structure

Rule Model

e.g. Physical

e.g. System

e.g. Technology

e.g. Presentation

e.g. Control

e.g. Rule

Technology Model

Data Model

Design

Architecture

Architecture

Structure

Designl

e.g.

e.g.

e.g. Network

e.g. Security

e.g. Timing

e.g. Rule

Detailed Reprasentation

Data Definition

Program

Architecture

Architecture

Definition

Specification

Quelle: www.zifa.com (17.08.02)

John Zachman entwickelte im Rahmen seiner Tätigkeit in Forschung und Praxis bei IBM eine Methode der Informationssystemarchitektur, das sogenannte Zachman-Framework. Durch Einbezug verschiedener Perspektiven (im Diagramm in der linken Spalte) soll ein möglichst vollständiges Bild des Informationssystem entstehen. Zachman et al. verwenden die Metapher der an einem realen Hausbau beteiligten Personen (1997, S. 57ff.). Der visionäre Planer soll die strategische Ausrichtung („Scope“) festlegen. Vom Besitzer werden die Geschäftsprozesse bestimmt. Der Designer setzt die Anforderungen in Produkt-

15

spezifikationen um, in der Informationstechnologie das sogenannte System-Modell. Der Erbauer ist für die Konstruktion verantwortlich, d.h. das Technologie-Modell. Zuletzt steht die Metapher des Subunternehmers, oder übertragen, die Komponenten eines Softwaresystems. Jede der Perspektiven beantwortet die Fragen „Was? Wie? Wo? Wer? Wann? Warum?“. Bestehende Pläne des Informationssystems, ERA-Modellierungen, Datenflussdiagramme und ähnliches werden ins Framework eingebettet. Zachman et al. schreiben, dass einige den Zellen zu Grunde liegende Modellen zwar noch nicht bestehen, aber der Wert des Frameworks dadurch keinesfalls gemindert werde (1997, S. 85). Ähnlich der Entwicklung des Periodensystems der Chemie, würden sich auch die Zellen im Framework nach und nach füllen.

Cook lehnt sich in ihrem Buch „Building Enterprise Information Architectures“ (1996, S. 42ff.) an Zachmans Framework an. Wie sie betont, liegt der grosse Vorteil am Zachman Framework darin, dass es die Architektur horizontal gestaltet. Während vertikale Ansätze monolithische Systeme hervorbringen, erlaubt der horizontale Ansatz eine unternehmens- übergreifende Architektur.

Obwohl Zachman Punkte wie Strategie und Geschäftsprozesse aufgreift, ist das Frame- work doch von einer technischen Sicht geprägt. So unterscheidet Brown (2000, S. 39) die technische Sicht von der Geschäftssicht und ordnet dabei Zachman der technischen Seite zu.

3.3.2 4+1 View Model

Das 4+1 View Model wurde von Rational Software entwickelt, ist inzwischen aber weiter verbreitet ¹ . Da Softwarearchitektur häufig nicht alle Anforderungen der „Kunden“ erfüllt, wird durch die Einnahme von vier Blickwinkeln versucht verschiedene Aspekte zu beachten. Die vier Blickwinkel sind: Logical View, Development View (auch Component View), Process View und Physical View (auch Deployment View). In der Mitte stehen dabei die mit “+1” gemeinten Anwendungsfälle (Use Cases), die helfen die Anforderungen zu erfassen (vgl. Darstellung 7).

Die logische Sicht beschreibt nach Kruchten (1995, S. 3ff.) genauer die funktionalen Anforderungen der Endbenutzer in Form von Objekten und Objektklassen. Dabei werden die Prinzipien von Abstraktion, Kapselung und Vererbung angewendet. Alternativ wird vorgeschlagen bei Datenorientierung allenfalls Entity-Relationship-Diagramme anzuwenden.

Die Prozesssicht soll auch nicht-funktionale Anforderungen einbeziehen, insbesondere wie die Kontrolle über die einzelnen Tasks und Threads organisiert wird, die sogenannte

¹ Clements und Northrop (1996, S. 23) haben das 4+1 View Model in leicht modifizierter Form übernommen, verweisen aber nur am Rande auf die Arbeit von Kruchten (1995). Das modifizierte Modell wird daher von Zühlsdorff in Mertens et al. im „Lexikon der Wirtschaftsinformatik“ (2001, S. 43) zur Definition von „Anwendungsarchitektur“ verwendet, leider ohne Hinweis auf die enge Verknüpfung mit dem „4+1 View Model“ von Kruchten.

16

Laufzeitumgebung. Der Fokus auf die verschiedenen Module einer Software wird durch die Entwicklungs- oder Komponentensicht wahrgenommen.

Die physische Sicht berücksichtigt die Aufteilung von Prozessen über das Netzwerk zwischen verschiedenen Computer, was die Performance, Fehlertoleranz, Integrität und Verfügbarkeit eines Systems beeinflusst.

Abbildung 7: 4+1 View Model

System Engineers

End-user

Topology

Functionality

Communications

Development/Component

Logical View

View

Use Case

View

Physical/Deployment

Process View

View

Integrators

System Engineers

Performance

Topology

Scalability

Communications

Quelle: in Anlehnung an Kruchen 1995, S. 43

3.3.3 Softwarearchitektur nach Carnegie Mellon

Die Scientific Community in den USA hat wichtige Publikationen veröffentlicht, insbesondere das Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh. Bekannte Publikationen sind „An Introduction to Software Architecture“ (1994) und „Software Architecture: Perspectives on an Emerging Discipline“ (1996) von David Garlan und Mary Shaw, Professoren für Computerwissenschaften an der Carnegie Mellon University sowie das Buch „Software Architecture in Practice“ (1998) von Bass, Clements und Kazman.

Während bei anderen Autoren wie Österle et al. (1992) und Zachman et al. (1997) die Unternehmens- oder Informationssystemarchitektur ausgehend von den Geschäftsbedürf- nissen entwickelt wird, sehen Garlan und Shaw den Nutzen der Softwarearchitektur als weiteren Schritt zur Reife des Software-Engineering.

Ähnlich der Entwicklung von der Maschinensprache, die in den fünfziger Jahren zur Programmierung gebraucht wurde, hin zu abstrakteren Sprachen wie Smalltalk oder Fortran, wird die Softwarearchitektur als weitere Abstraktionsebene immer wichtiger (Garlan & Shaw 1994, S. 3ff.; Krueger 1992, S.137ff. und Zachman et al. 1997, S. 4ff.) ¹ . Denn einerseits werden die Systeme immer grösser und komplexer und andererseits nimmt

¹ Ein gut verständlicher Überblick zur Evolution der Software-Entwicklung findet sich bei Lüscher & Straubinger (1996, S. 5ff.).

17

der Aufwand für die Programmierung durch Modularisierung und Programmbibliotheken immer weiter ab.

Garlan und Shaw verweisen auch auf die mangelnde Unterstützung von Heterogenität durch Programmiersprachen (1996, S. 158). Module, die in verschiedenen Programmier- sprachen geschrieben sind, können nicht miteinander kombiniert werden bzw. nur über spezielle, zwischen den Sprachen stehende Prozeduraufrufe. Module müssen daher häufig erst entkodiert werden. Ausserdem unterstützen heutige Programmiersprachen keine Ab- straktion von Interaktion, so dass es unmöglich sei Architekturparadigmen auszudrücken. Dementsprechend lautet die Anforderung an neue Architekturbeschreibungssprache (ADL) dies zu lösen ¹ .

3.4 Was ist Software Engineering?

Wie oben festgestellt sind die Gebiete des Software Engineering und der Architektur, genauer der Softwarearchitektur, eng miteinander verknüpft. Es stellt sich die Frage, wie Software-Engineering definiert wird.

Garlan und Shaw (1996, S. 6) definieren Engineering als Erstellen von kosteneffektiven Lösungen zu praktischen Problemen durch Anwendung von wissenschaftlichem Wissen, um Dinge zu schaffen, die dem Menschen dienen. Wirtz schreibt in Mertens et al. (2001, S. 417f.) Software-Engineering sei die Anwendung wissenschaftlicher Erkenntnisse und Verfahren auf die Konstruktion von Software. Der Begriff enthalte ausserdem das Ziel, mit ebenso gesicherten und erprobten Techniken zu operieren wie traditionelle Ingenieur- disziplinen. Balzert definiert Software Engineering als zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeits- teilige, ingenieurmässige Herstellung und Anwendung von umfangreichen Software- Systemen (2001, S. 45).

Nach Hasselbring (2000, S. 34f.) befasst sich Software Engineering mit der systematischen Entwicklung von komplexen Softwaresystem und behandelt Fragen wie passender Softwarearchitektur und passender Entwurfsmuster. Des weiteren gehört zum Software Engineering die Komposition von Software-Komponenten, der richtige Gebrauch und die Erweiterung von Middleware-Werkzeugen und methodologische Ansätze zur Integration.

Der Begriff des Software-Engineering wurde 1968 bei einem Workshop der NATO aus Verzweiflung über das unstrukturierte Vorgehen bei der Softwareentwicklung erschaffen. Er erlangte in den siebziger Jahren grosse Popularität (Garlan & Shaw 1996, S. 5). Das Software-Engineering hat also einen methodischen Softwareentwicklungsprozess zum Ziel. Dazu bedient es sich auch computergestützter Werkzeuge, sogenannter CASE-Tools.

¹ Eine aktuelle Abhandlung zum Stand der Reife in der Softwarearchitektur findet sich bei Shaw (2001) „The Coming-of-Age of Software Architecture Research“.

18

3.5 Architektur vs. Engineering

Nachdem sowohl Architektur als auch Engineering definiert wurde, sei hier nun versucht, die Gebiete voneinander abzugrenzen. Software-Engineering versteht sich als Opti- mierungsprozess mit dem Ziel effektiver Lösungen. Im Mittelpunkt steht die Absicht die Projektanforderungen möglichst effektiv zu erfüllen, den Programmcode zu optimieren und die Wiederverwendbarkeit von Programmcode zu fördern. Dazu bedient man sich besonders der Analyse. Meier und Rechtin schreiben, Engineering sei ein deduktiver Prozess, Architektur dagegen induktiv (2002, Vorwort III). Engineering befasst sich ausserdem mit dem Ziel quantifizierbarer Kosten. Software Engineering wird besonders durch die Disziplin der Informatik bearbeitet. Es bedient sich drei Hauptmodellen, dem Applikationsbereichsmodell, dem Softwaredesign-Modell und dem Implementationsmodell (Riehle & Züllighoven 1996, S. 5).

Architektur versteht sich einerseits als Prozess, andererseits als Zustand. Im Zentrum des Prozesses der Architektur steht das Erstellen einer Grobstruktur durch Synthese. Es wird versucht durch Vorschläge eine Lösung zu finden, wo alle Schnittstellen passen. Nach Meier und Rechtin (2002, Vorwort III) widmet sich Architektur der Lösung schlecht- strukturierter Situationen. Sie befasst sich mit dem qualitativen Wert und ist auch Kunst. In einer Architektur sind die Implementierungs-, die Nutzungs-, die Modellierungs-, die Organisations- und die Geschäftsprozessentwurf-Sicht zu beachten (Britton 2001, S. 5ff.).

3.6 Zusammenfassung

Der Begriff der IT-Architektur kann sich auf verschiedene Abstraktionsebenen beziehen, und eine Informationssystemarchitektur, eine Softwarearchitektur oder eine Applikations- landschaft bezeichnen. Der Begriff der Architektur hat die zwei Dimensionen Zustand und Vorgehen.

Die Informationssystemarchitektur bezeichnet eine Grobstruktur der Organisation, der Geschäftsfunktionen, Daten, Applikationen und Datenbanken. Eine Softwarearchitektur besteht aus Komponenten, die zusammen mit den verbindenden Konnektoren Appli- kationen bilden. Die Softwarearchitektur steht dabei dem Software-Engineering sehr nahe. Während das Engineering primär ein Optimierungsprozess ist, befasst sich Architektur mit dem Erstellen von Grobstrukturen.

Nachdem nun feststeht, was Integration heterogener Applikationen ist und Ansätze von IT-Architekturen vorgestellt wurden, wird als nächstes in die Theorie der Muster einge- führt. Interessanterweise haben diese ihre Wurzeln in der Architektur des Städtebaus.

19

4

Muster

4.1 Einleitung

Der Gebrauch von Mustern ist eine aktuelle Entwicklung im Software Engineering. Die Arbeiten des Architekten und Städteplaners Christopher Alexander, haben dabei die entstandene Community massgeblich beeinflusst. Automobildesigner entwickeln Autos auch nicht von Grund auf neu nach den Regeln der Physik, sondern verwenden Standarddesigns, die sich in der Vergangenheit bewährt haben. Denn der kleine Leistungsgewinn, wenn man ein Produkt von Grund auf entwickeln würde, ist den Aufwand nicht wert (Schmidt et al. 1996, S. 37). Muster sollen in ähnlicher Weise erprobte Lösungen für verbreitete Softwareprobleme liefern.

4.2 Was sind Muster?

Christopher Alexander schreibt über Muster in der Baukunst: “Jedes Muster beschreibt zunächst ein in unserer Umwelt immer wieder auftretendes Problem, beschreibt dann den Kern der Lösung dieses Problems, und zwar so, dass man diese Lösung millionenfach anwenden kann, ohne sich je zu wiederholen.“ (Alexander et al. 1995, Vorwort X).“

Riehle und Züllighoven definieren Muster in der Softwareentwicklung als die Abstraktion einer konkreten Form, die in einem anderen spezifischen Kontext wieder auftauchen kann ¹ (1996, S. 1f.). Fowler schreibt zu Mustern einfach: „A pattern is an idea that has been useful in one practical context and will be useful in others (1997, S. 1).“

Nach Appleton (2000, S. 3f.) ist ein Muster im Software-Engineering nicht nur eine erprobte Lösung für ein Problem. Die Beschreibung eines Muster sollte die wichtigsten Erkenntnisse enthalten, so dass andere in ähnlichen Situationen daraus lernen können. Daher definiert Appleton ein Muster als ein Bündel an instruktiver Information, das den Kern einer erprobten Lösung für ein immer wieder auftretendes Problem vermittelt ² . Alexander benutzt für Muster, in denen die Anwendung der Muster vermittelt wird, den Begriff „generative patterns“. Gemäss Smolarova und Navrat (1999, S. 140) wäre es vernünftig zwischen den Handlungsanweisungen zur Anwendung eines Musters, und dem eigentlichen Muster als Code in einem gut geschriebenen Programm zu unterscheiden. Sie schlagen für letzteres den Begriff „Pattern instance“ (Musterinstanz) vor. Da diese Begriffsbezeichnung derzeit nicht gebräuchlich ist, wird hier auf diese Unterscheidung verzichtet.

¹ Im Original: „A pattern is the abstraction form of a concrete form which keeps recurring in specific non-arbitrary contexts (Riehle & Züllighoven 1996, S. 1f.).”

² Im Original: „A pattern is a named nugget of instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces (Appleton 2000, S. 3).”

20

Auch nach Bass et al. (1998, 292) werden Muster im Software-Engineering immer mehr als ein Weg gesehen, Erfahrungen auf Neulinge zu übertragen. Diese Form der Dokumentation ist in anderen Design- und Engineeringdisziplinen schon lange verbreitet, aber im Software Engineering bis vor kurzem rar gewesen. Häufig wird der Nutzen von Mustern auch darin gesehen, implizites Wissen explizit zu machen, und Muster im Knowledge Management einzusetzen.

4.3 Muster und Mustersprachen nach Alexander

Von den unterschiedlichsten Disziplinen wird, wie auch hier, immer wieder auf die Muster- definition von Christopher Alexander zurückgegriffen. Alexander war Professor in Bauarchitektur an der University of California in Berkeley. Die bekanntesten Bücher des Architekten und Städteplaner sind „A Pattern Language: Towns, Buildings, Construction“ (1977) ¹ , eine Sammlung von Mustern der Baurchitektur, und „The Timeless Way of Building“ (1979).

Zur Beschreibung der Muster schlägt Alexander (1979, S. 247) eine Drei-Teile-Regel vor, die aus den Elementen Kontext, Problem und Lösung besteht. In Anlehnung an die Drei- Teile-Regel von Alexander benutzt Gabriel (2001) die folgende Definiton für Software- Muster: „Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration, which allows these forces to resolve themselves.“

Weitere Autoren lehnen sich ebenfalls an den Grundraster von Alexander an, um Muster zu beschreiben. So benutzen Beck und Johnson (1994, S. 2ff.) zur Beschreibung von Mustern die Unterteilung in Vorbedingungen (Preconditions), Problem, Einschränkungen (Constraints) und Lösung (Solution). Beedle (1997a, 1997b) unterteilt in Kontext (Context), Problem, Kräfte (Forces) und Lösung (Solution).

Im Buch “Eine Muster-Sprache“ (1995) beschreibt Alexander unzählige Muster der Baukunst in einer klar strukturierten Form. Eine Mustersprache soll nach Alexander (1979, S. 186) generativ sein. Generative Muster ermöglichen durch genaue Anleitung, die im Muster beschriebene Sache zu reproduzieren, sind also instruktiv. Beck und Johnson schreiben, dass eine Mustersprache eine Beschreibung enthalten soll, wann das Muster angewendet wird (1994, S. 2).

Appleton grenzt die Mustersprache vom Musterkatalog ab. Er schreibt, dass Mustersprachen Regeln zur Anwendung der Muster enthalten, um Probleme zu lösen, die den Umfang eines Musters übersteigen. Ein Katalog enthält dagegen solche Regeln nicht. Appleton gebraucht die Metapher von Sprache und Grammatik (2000, S. 17). Die Mustersprache ist ein Lexikon von Mustern, das mit einer Grammatik versehen ist, um gültige Sätze zu bilden. Ausserdem setzt eine Mustersprache die verschiedenen Muster

¹ In dieser Arbeit wird die deutsche Übersetzung von Czech, Kovacsics und Spreitzer aus dem Jahr 1995 benutzt.

21

zueinander in über- und untergeordnete Beziehungen und bildet, wenn sie vollständig ist, aus den Mustern ein zusammenhängendes Ganzes (Alexander 1979 S. 305, 312, 316).

Die Entwicklung von Mustersprachen ist das langfristige, aber schwierige Ziel. Muster- sprachen haben das Ziel, alle Probleme in einem bestimmten Bereich durch Muster abzudecken. Alexanders Buch (1995) erfüllt das etwa für die Bau-Architektur. Im Bereich der Softwarearchitektur existiert z.B. CHECKS eine Mustersprache für den Unterbereich der Informationsintegrität (Buschmann et al. 1996, S. 422).

Um zu guten Mustern zu gelangen, schlägt Alexander (1979) drei Grundsätze vor: die Qualität („the quality without a name“, auch QWAN), den Zugang („the gate“) und den Weg („the timeless way“). Qualität bezeichnet die wesentlichen Grundzüge, die in den Dingen stecken und sie für uns lebendig wirken lassen, aber schwierig in Worte zu fassen sind (S. 19ff.). Alexander geht also davon aus, dass es ein objektives Mass für ästhetische Schönheit mit einem universellen Geltungsbereich gibt (Klose 2002, S. 111). Der Mechanismus, der uns erlaubt die „Qualität“ zu erreichen, wird als Zugang bezeichnet. So ermöglicht eine Mustersprache neue Dinge aus bewährten Grundsätzen zu schaffen (Ale- xander 1979, S. 157ff.). Zwischen Qualität und Zugang steht der Weg. Darunter ist der Prozess der Anwendung von Mustern, um die QWAN zu erreichen, zu verstehen (S. 351ff.). Appleton (2000, S. 2) fasst die Idee von Alexander in einem Satz zusammen: „By following the way, one may pass through the gate to reach the quality.“

Ästhetische Schönheit ist aber kaum das Ziel in der Architektur eines Informationssystems oder einer Software. Da könnte man in Bezug auf die Softwarearchitektur eine wohl- programmierte, aus Komponenten mit klaren Schnittstellen zusammengesetzte Software verstehen. In der Informationssystemarchitektur wären die Kriterien eher die Integriertheit eines Systems, die Erweiteungsfähigkeit und Anpassbarkeit, sowie die konzeptionelle Klarheit.

4.4 Geschichte der Muster im Software-Engineering

Entwurfsmuster im Software-Engineering entstanden durch die Entwicklung von abstrakteren („high-level“) Programmiersprachen wie Fortran oder Smalltalk. Als man in den fünfziger Jahren beim Aufkommen der Computer in Maschinensprache programmierte, wurden gewisse Muster an Prozeduraufrufe erkannt und als abstraktere Spezifikationen in „high-level“ Programmiersprachen eingebracht (Garlan & Shaw 1994, S. 3f.).

1987 entwickelten Ward Cunningham und Kent Beck Benutzeroberflächen in Smalltalk und benutzten dabei Alexanders Ideen, um eine fünf Muster umfassende Mustersprache für Smalltalk-Neulinge zu entwickeln (Cunningham 2000). Jim Coplien publizierte 1991 ein Buch mit einem Katalog von C++-Idioms, einer Art Muster. Im gleichen Jahr trafen sich an einem Workshop Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides. Später bildete sich aus diesen Personen, die sogenannte „Gang of Four“, kurz GoF. 1995 erschien deren Buch „Design Patterns – Elements of Reusable Object-Oriented Software“,

22

die erste gedruckte Sammlung an Mustern für die Softwareentwicklung. Obwohl darin Alexander zitiert wird, schreibt Fowler (1997, S. 6), dass drei aus der „Gang of Four“ die Bücher von Alexander nicht kannten und die Bedeutung von Alexander überschätzt wird.

Mit dem 1996 von Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad und Michael Stal publizierten Buch „Pattern-Oriented Software Architecture: A Systems of Patterns“ wurden Muster noch bekannter. Die fünf Autoren werden auch als „Siemens Gang of Five“ (GoV) bezeichnet. Seit 1994 finden in der Software Engineering Community ausserdem jährlich Konferenzen statt, die sogenannte „Pattern Languages of Programs“ (PLoP), wo das Wissen über Muster gepflegt und erweitert wird. Neben der technischen Ebene, findet auch die Anwendung von Mustern auf Organisationsproblem- stellungen immer weitere Verbreitung, so bei Coplien (1996) „The human side of patterns“.

Der Nutzen von Mustern lässt sich bereits erahnen. Muster formalisieren Ideen zu generischen Schemen, die sich wiederverwenden lassen. Da es sich bei Mustern um erprobte Lösungen handelt, wird Wissen von anderen nutzbar und es kann von erfahrenen Entwicklern auf weniger erfahrene übertragen werden. Muster sind ein Weg eine Problemstellung besser zu verstehen, und anschliessend die richtige Technologie anzuwenden, da sie auch den Anwendungskontext beschreiben. Durch die Förderung der Wiederverwendbarkeit wird der Entwicklungsprozess einfacher.

4.5 Framework

Der weiten Verbreitung objektorientierter Programmiersprachen entsprechend, werden die hier vorgestellten Entwurfsmuster meist objektorientiert sein. Aus der Objektorientierung kommt auch der Begriff des „Framework“, auf Deutsch Rahmenwerk. Obwohl Zachmann den Begriff des Frameworks auf der Ebene der Unternehmensarchitektur ebenfalls verwendet, hat die Bezeichnung „Framework“ in der objektorientierten Softwarearchitek- tur eine andere Bedeutung.

Das Software Framework ist eine mehr oder weniger abstrakte, mehr oder weniger voll- ständige Architektur einer Klasse von Software (Frank in Mertens et al. 2001, S. 203ff.). Appleton (2000, S. 13) definiert ein Software Framework als eine wiederverwendbare Mini-Architektur, die generische Strukturen und Verhalten für eine Familie von Software- abstraktionen liefert. Ein Kontext an Metaphern spezifiziert dabei die Zusammenarbeit der Softwareabstraktionen und deren Verwendung in einem bestimmten Bereich. Nach Beck und Johnson (1994, S. 1) sind Frameworks ein bestimmter Weg (Software-) Architektur zu repräsentieren. Entsprechend gibt es Softwarearchitekturen, die nicht in ein Framework gefasst werden können. Fowler (1997, S. 11) formuliert als Anforderung an ein Framework, dass es weder zu komplex, noch zu schwerfällig sein darf. Es sollte auf den konzeptuellen Modellen eines Bereichs oder einer Branche basieren und in diesem Bereich breit anwendbar sein. Ein Framework für Applikationen in einem bestimmten Bereich (z.B.

23

für Finanzapplikationen) wird Applikationsframework genannt (Buschmann et al. 1996, S.

396).

Die Idee der Frameworks ist, höchstmögliche Wiederverwendbarkeit zu erreichen. Während objektorientierte Programmierung die Wiederverwendbarkeit von Programm- code fördert, unterstützen Frameworks die branchenweite Wiederverwendbarkeit von Ent- wurfs- und Domänenwissen (Frank in Mertens et al. 2001, S. 203ff.). So schreibt Fowler (1997, S. 11), dass zur Wiederverwendbarkeit von Komponenten ein Framework geschaffen werden soll. Frameworks sind für die Softwarearchitektur daher von Bedeutung, weil sie die Details vor dem Entwickler verbergen und es ihm erlauben sich auf die Funk- tionalität einer Architektur zu konzentrieren (Linthicum 2000, S. 84).

Frameworks sind weniger abstrakt bzw. spezialisierter als Muster. Entwurfsmuster sind damit kleinere Architekturelemente als Frameworks (Gamma et al. 1995, S. 29). Frameworks unterscheiden sich von Mustern dadurch, dass sie in der vorgesehenen Pro- grammiersprache implementiert werden, während Muster unabhängig von Programmier- sprachen verfasst sind (Schmidt et al. 1996, S. 39) und daher in jeder beliebigen Program- miersprache umgesetzt werden können. Das hat damit zu tun, dass Frameworks ausführbarer Code sind, während Muster nur Anweisungen enthalten, wie ausführbarer Code zu gestalten ist (Appleton 2000, S. 14).

Von Programmbibliotheken unterscheiden sich Frameworks im sogenannten Kontrollfluss. Bei der Verwendung von Bibliotheken schreibt der Programmierer den Hauptteil der Implementation und benutzt dazu, die in der Bibliothek abgelegten, benötigten Subroutinen. Im Gegensatz dazu, werden in Frameworks Funktionen aufgerufen (Appleton 2000, S. 14).

Die Problematik an Frameworks liegt darin, dass die Kosten der Entwicklung für viele Firmen zu hoch sind. Die Bindung an Programmiersprachen bedingt eine Eingrenzung auf wenige Technologien und Programmiersprachen. Angesichts der Heterogenität von Appli- kationen ist dies in Unternehmen ein schwieriges Unterfangen.

4.6 Dokumentation von Mustern

Die Dokumentation von Mustern sollte sich an fünf Leitwerten orientieren (Schmidt et al. 1996, S. 38).

- Erprobtheit ist wichtiger als Neuheit: Je länger ein Muster bereits gebraucht wird, desto wertvoller ist es.

- Schwerpunkt auf der Beschreibung und der Klarheit der Kommunikation: Muster sollten wie Katalogeinträge sein, sowohl in literarischem wie in technischem Stil.

- Qualitative Validierung des Wissens: Die Beschreibung einer Lösung soll qualitativ erfolgen. Quantitative Aspekte haben zwar ihre Berechtigung. Sie gehören aber nicht in die Beschreibung von Mustern.

24

- Gute Muster entstehen aus Praxiserfahrung: Die Erfahrung aller wird geschätzt, da nicht nur einige wenige die Muster bereit haben, sondern die Muster sich in der Diskussion von Stärken und Schwächen sowie dem Austausch von Erfahrung herauskristallisieren.

- Die Wichtigkeit der menschlichen Dimension in der Software Entwicklung sollte beachtet werden: Die Anwendung von Mustern soll nicht Kreativität durch stures Anwenden von Regeln ersetzen.

Daneben gibt es weitere allgemein anerkannte Kriterien für eine hohe Qualität der Muster. Die Muster sollten einem Reviewprozess unterliegen und allenfalls gemäss den An- merkungen verbessert werden. Ein öffentlicher Review auf dem Internet ist erstrebenswert und Muster sollten populäre Akzeptanz erlangen. Wobei unter Popularität objektive Kriterien, wie Zirkulation der Publikation, gemeint sind. Auch sollten Muster in mehrere Bereiche gegliedert sein. Appleton (2000, S. 9ff.) schlägt ein Format vor, dem die Muster- beschreibungen entsprechen sollten. Er beachtet dabei die Vorschläge von Alexander, das Musterformat der „Gang of Four“ und der „Gang of Five“. Folgende Elemente kommen in den Formaten der verschiedenen Autoren häufig vor:

Name

Eine kurze Bezeichnung zur Beschreibung eines Musters. Das kann ein kurzes Wort oder ein kurzer Satz sein. Dabei fällt es häufig nicht leicht, eine treffende Bezeichnung zu finden. Aber ein guter Name erleichtert die Diskussion und den Austausch mit anderen. Gewisse Namen haben sich in der Literatur bereits etabliert, während andere noch wenig gebraucht werden. Manchmal sind verschiedene Synonyme in der Literatur vorhanden. Dann hilft es diese Bezeichnungen ebenfalls anzugeben. Üblicherweise erfolgt dies im Untertitel mit „auch bekannt als“ (Appleton 2000, S. 10).

Voraussetzungen

Die in diesem Punkt beschriebenen Voraussetzungen müssen erfüllt sein, bevor ein Muster angewendet werden kann (Beck & Johnson 1994, S. 2) .

Problem(-beschrieb)

Das ist eine Beschriebung des Problems, welches durch das Muster gelöst wird. Dieser Problembeschrieb ermöglicht dem Leser die Abschätzung inwiefern das Problem für ihn relevant ist. Dieser Teil kommt bei allen Autoren vor.

25

Kontext

Der Kontext beschreibt die Bedingungen unter denen das Problem auftritt und eine Lösung wünschenswert wäre. Er hilft bei der Beurteilung, ob ein Muster in einem bestimmten Umfeld angewendet werden kann oder soll (Buschmann et al. 1996, Beedle 1997a, 1997b). Bei Gamma et al. 1995 und bei Mularz 1995 wird der Kontext stattdessen Anwendbarkeit genannt.

Zweck und Motivation

Der Zweckabschnitt erläutert genauer, was das Muster bezweckt (Gamma et al. 1995, S. 6, auch bei Mularz 1995, S. 441ff.). Zusätzlich enthält die Beschreibung von Gamma et al. auch ein Abschnitt „Motivation“ (1995, S. 7). Darin wird in einem Szenario das Entwurfs- problem beschrieben. Das Ziel ist dabei, das Verständnis der Klassen- und Objekt- strukturen zu erleichtern.

Widerstände (forces oder constraints)

Ein Problem tritt immer in einem Umfeld von zahlreichen Einflüssen und Einschränkungen auf, die aufeinander und auf das Problem einwirken. Durch diese Beschreibung wird Hilfestellung geleistet bei der Abwägung von verschiedenen Zielkonflikten, die in Betracht gezogen werden müssen (Appleton 2000, S. 10, auch bei Beedle 1997a, 1997b; bei Beck & Johnson 1994, „constraints“ genannt).

Lösung

Dieser Abschnitt beschreibt die Lösung zum Problem. Manchmal visualisiert eine grafische Darstellung eine gefundene Lösung. Nach Appleton hat eine Lösung einerseits die statische Komponente der Struktur eines Musters, andererseits eine dynamische Kom- ponente, welche die Interaktion eines Musters beschreibt (2000, S. 9ff.). Da die Lösung eines der Grundelemente der Drei-Teile-Regel von Alexander (1979) ist, kommt sie in den Beschreibungen von allen Autoren vor.

Konsequenzen oder resultierender Kontext

Konsequenz oder resultierender Kontext bezeichnet den Zustand oder die Konfiguration eines Systems, nachdem das Muster angewendet wurde. Dabei wird auf die positiven und negativen Konsequenzen der Anwendung des Musters eingegangen, sowie auf neue Probleme, die im Kontext aufgetreten sein könnten (als resultierender Kontext bei Appleton 2000, S. 10, als Konsequenzen bei Gamma et al. 1995, Buschmann et al. 1996, Dikel et al. 1997).

Beedle (1997b, S. 5ff.) verweist dagegen in seinen Beschreibungen im Abschnitt resultierender Kontext auf nachfolgende Muster, die beachtet werden sollten.

26

Gedankengänge (rationale)

Im Abschnitt „Gedankengänge“ werden erläuternde Erklärungen zu den Schritten eines Muster gegeben. Es wird ebenfalls beschrieben, wie mit den Widerständen umgegangen wird (Appleton 2000, S.11; auch bei Dikel et al. 2001).

Teilnehmer, Struktur und Interaktionen

In objektorientierten Mustern werden unter diesen Stichworten, die am Muster beteiligten Klassen und Objekte beschrieben, sowie deren Struktur. Die Beschreibung der Struktur erfolgt dabei meist in der Object-Modelling-Technique (OMT). Der Interaktionsabschnitt beschreibt, wie die Teilnehmer zur Erfüllung der Aufgaben zusammenarbeiten. Diese Beschreibungsdimensionen kommen bei Gamma et al. vor (1995, S. 7), die Strukturbeschreibung in OMT auch bei Buschmann et al. (1996). Buschmann et al. gehen zusätzlich im Abschnitt „Dynamics“ noch auf das Laufzeitverhalten eines Musters ein (1996, S. 20).

Beispiele

Zur besseren Illustration werden gerne Beispiele angeführt. Dabei werden meist leicht- verständliche Lösungen bevorzugt (bei Appleton 2000, Beedle 1997a, 1997b, Dikel et al. 2001). Buschmann et al. führen bereits Beispiele beim Problembeschrieb an und kommen später im Punkt „gelöste Beispiele“ darauf zurück (1996, S. 21).

Implementierung und Beispielcode

Der Implementierungsabschnitt präsentiert die Fallen, Tipps oder Techniken, die man kennen sollte, um das Muster zu implementieren. Der Beispielcode erläutert wie Muster in einer ausgewählten Programmiersprache implementiert werden können (Gamma et al. 1995, S. 7, auch bei Buschmann et al. 1996).

Verwandte Muster

Da ein Muster manchmal eine Spezialisierung oder Untergruppe eines anderen Musters sein kann, erläutern die Autoren häufig die Beziehung zu Mustern von anderen Autoren (bei Appleton 2000, Buschmann et. 1996, Beedle 1997b). Gamma et al. (1995, S. 7ff.) verweisen dagegen auf eigene Muster.

Buschmann et al. gebrauchen für den Verweis auf eigene Muster den Abschnitt der „Varianten“. Das sind kurze Beschreibungen von Varianten wie z.B. Spezialisierungen eines Muster (1996, S. 21). Mularz spricht von ergänzenden Mustern (1995, S. 444).

Bekannte Fälle

Beedle (1997a, 1997b) führt in den Beschreibungen noch „Known Uses“ an. Das sind Firmen oder Personen, in welchen das Muster ausgeprägt ist. Gamma et al. nennen in diesem Abschnitt Muster aus echten Softwaresystemen, wobei Beispiele aus mindestens zwei unterschiedlichen Anwendungsbereichen genannt werden (1995, S. 7). Buschmann et al. (1997) nennen ebenfalls Beispiele aus bestehenden Systemen.

27

4.7 Zusammenfassung

Muster sind Abstraktionen von Lösungen zu bestimmten Problem, die immer wieder auftreten. Eine sinnvolle Musterbeschreibung gehorcht dazu der Drei-Teile-Regel von Alexander und gliedert sich mindestens in Kontext, Problem und Lösung. Die Idee der Muster hat grossen Anklang im Bereich der Entwurfsmuster von Softwarearchitektur gefunden. Daraus entstand eine aktive Community, welche vorgeschlagene Muster gegenseitig einem kritischen Review unterzieht. Die verschiedenen Autoren benutzen zwar eigene Formate zur Beschreibung von Mustern, aber sie sind sich doch alle ähnlich.

Die verschiedenen Muster werden in sogenannten Musterkatalogen gesammelt. Wenn zu allen Problemstellungen in einem bestimmten Bereich Lösungsansätze in Musterform beschrieben sind, bezeichnet man eine Sammlung von Mustern als Mustersprache. Diese sind derzeit noch selten. Objektorientierte Frameworks sind Mustern ebenfalls ähnlich. Sie bestehen aber aus ausführbarem Programmcode und unterscheiden sich dadurch von den Mustern. Denn Muster enthalten nur Anweisungen, wie Code zu gestalten ist.

Ein Muster mit hoher Qualität soll erprobt, klar beschrieben und aus der Praxis entstanden sein. Der Review in der Community trägt im weiteren zur hohen Qualität von Mustern bei. Diese Kriterien sollen die Übertragbarkeit der Muster auf neue Situationen und die Verständlichkeit erleichtern. Sie fördern damit den Wissenstransfer von erfahrenen Entwicklern zu weniger erfahrenen Entwicklern.

28

5 Muster im Software Engineering

5.1 Einleitung

Grundsätzlich kann man drei Typen von Mustern im Software Engineering unterscheiden:

die Analysemuster, die Entwurfsmuster und Organisationsmuster. Die ersten zwei Muster werden in diesem Kapitel vorgestellt. Das Organisationsmuster sowie ein weiteres Muster, das Architektur-Muster, werden im nächsten Kapitel vorgestellt. Die Organisationsmuster sind bei Coplien so umfassend, dass sie nicht nur auf Software Engineering zutreffen. Das Architektur-Muster wird entsprechend unserer Architektur-Definition Softwarearchitektur-Muster genannt. Devedzic (2000, S. 3) bezeichnet die Architektur- muster (architectural pattern) ebenfalls als „Patterns for Software Architecture“ (Softwarearchitektur-Muster) ¹ .

Bei der Vorstellung der Muster verschiedener Autoren findet keine empirische quantitative oder qualitative Validierung der Muster statt. Dies hätte umfangreiche Untersuchungen bedingt. Es werden aber nach Möglichkeit Angaben zur Entstehung der Muster gemacht und inwiefern diese einem Review unterzogen wurden. Die Beschreibung der Muster orientiert sich ausserdem an den Leitfragen, wann und wo sie publiziert wurden und was der Autor für einen Erfahrungshintergrund mitbringt. Falls besondere Definitionen vorkommen oder anderweitige Abgrenzungen, werden diese erläutert. Häufig wird auf die Strukturierung der Muster kurz eingegangen, da eine gute Struktur die Anwendung von Mustern erleichtert und damit deren Wert erhöht. Wo vorhanden, wird eine Einschätzung durch andere Autoren wiedergegeben. Da die Musterbeschreibungen teilweise sehr ausführlich sind, ist es nicht möglich, diese hier abzudrucken. Um dennoch ein Bild zu erhalten, sind von ausgesuchten Autoren Beispiele von Musterbeschreibungen im Anhang zu finden.

5.2 Analysemuster

Die Analysemuster erlangten grosse Bekanntheit durch das Buch von Martin Fowler mit dem Titel „Analysis Patterns: Reusable Object Models“ (1997). Fowler beschreibt darin objektorientierte Muster zur konzeptionellen Modellierung von Geschäftsprozessen. Er greift dabei zurück auf seine Erfahrungen in der Praxis als Berater in der Modellierung von Informationssystemen und hat die Muster ständig weiterentwickelt. Laut Fowler haben seine Modelle ebensoviel mit Business Engineering zu tun wie mit Software Engineering (1997, S. 10). Im zweiten kürzeren Teil des Buchs stellt Fowler sogenannte Unterstützungsmuster vor, welche die Umsetzung der Analysemuster in die Architektur eines Informationssystems beschreiben. Dieser Teil wird erst im nächsten Kapitel erläutert.

¹ Bei Devedzic (2000) findet sich auch eine gute Beschreibung der vier Muster.

29

Die Analysemuster unterscheiden sich von den Designmustern, indem sie versuchen, das Problem zu verstehen. Anforderungen werden nicht wie üblich übernommen, sondern hinterfragt und man versucht ein mentales Modell zu bilden, was sich in einer Problem- stellung ereignet (Fowler 1997, S. 1). Analysemuster befassen sich nicht mit der eigentlichen Softwareimplementation. Sie entwerfen konzeptionelle Strukturen von Geschäftsprozessen.

Die Beschreibung der Muster gliedert sich in vier Teile: Jedem Muster wird ein Namen vergeben. Dann folgt eine Beschreibung der Problemstellung und eine Skizze dazu, sowie anschliessend die Lösung. Die Lösung für eine Problemstellung kann dabei aus mehreren unterschiedlichen Lösungsansätzen bestehen, die alle gewisse Vor- und Nachteile aufweisen. Fowler hat dabei darauf verzichtet, für jeden Lösungsansatz ein eigenes Muster zu erstellen. Die Skizzen zu den Problemen sind in objektorientierter Notation erstellt und wurden mit der endgültigen Spezifikation von UML in die UML-Notation überführt.

Die Muster von Fowler enthalten gemäss Johnson eine grosse Menge an Wissen, das in allen Bereichen der Softwareentwicklung für Unternehmen genutzt werden kann (Fowler 1997, Vorwort V). Die Muster sind nie nur für die Branche anwendbar, in der sie ur- sprünglich entwickelt wurden, sondern immer auch auf andere Bereiche übertragbar.

5.3 Entwurfsmuster

Am weitaus bekanntesten sind die Entwurfsmuster, die auch zuerst entstanden sind. Wie bereits zuvor erläutert, spricht man dabei von der Gang of Four und der Gang of Five.

Entwurfsmuster sind ein formalisierter Ansatz um Schnittstellen zu identifizieren, kategorisieren und wiederzuverwenden. Es ist ebenfalls ein Weg, eine Problemstellung besser zu verstehen und die richtige Technologie anzuwenden.

5.3.1 Gang of Four

1994 erschien das Buch mit einer Zusammenstellung an Mustern von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides. Sie waren das Vorbild für weitere Arbeiten über Entwurfsmuster. Die Autoren haben sich lange mit der Thematik befasst und verfügen über gute Kenntnisse in der objektorientierten Programmierung. Obwohl die Sammlung der Entwurfsmuster nur eine Momentaufnahme darstellt, wurden alle in einem öffentlichen Reviewprozess von zahlreichen anderen Personen begutachtet und deren Erfahrungen integriert.

Die 23 Entwurfsmuster werden in drei Gruppen gegliedert, die Erzeugungsmuster, die Strukturmuster und die Verhaltensmuster. Erzeugungsmuster betreffen den Prozess der Objekterzeugung, Strukturmuster befassen sich mit der Zusammensetzung von Klassen und Objekten und Verhaltensmuster charakterisieren die Art und Weise, wie Klassen und Objekte interagieren (Gamma et al. 1995, S. 9). Als zweites Kriterium legt der Gültigkeitsbereich fest, ob sich Muster primär auf Klassen oder Objekte beziehen.

30

Während manche Muster in Kombination auftreten, sind andere sich ausschliessende Alternativen.

Die Beschreibung der Muster ist ausführlich, formalisiert und umfasst mehrere Teile. Zuerst steht der Name des Musters und sofern vorhanden, andere geläufige Bezeichnungen. Dann folgt eine Beschreibung des Zwecks, der Motivation (weshalb dieses Muster?), Anwendbarkeit (wann ist das Muster zutreffend?). Grafisch visualisiert wird die Struktur aufgezeigt und deren Elemente, die Teilnehmer, erläutert. Die Notation dieser Skizzen basiert auf OMT-Notation (object model-notation). Einem Beschrieb der Interaktion dieses Musters mit anderen folgen die Konsequenzen und die Erläuterungen wann dieses Muster implementiert werden soll (Implementation). Es ist immer noch Beispielcode enthalten, sowie eine Aufstellung bekannter Verwendungen in Praxisfällen und der Bezug zu verwandten Mustern.

Die Beschreibung der Muster ermöglicht es, eigene Software mit den Mustern zu entwickeln oder Muster in bestehender Software zu entdecken (Riehle & Züllighoven 1996, S. 8). Mit den Entwurfsmustern werden aber nicht alle Fälle abgedeckt. Es ist daher derzeit nicht möglich, ein Softwaresystem nur mit Entwurfsmustern zu entwickeln. Wie Mularz (1995, S. 443) anmerkt, sind die Entwurfsmuster von Gamma et al. besonders für neue objektorientierte Systeme hilfreich, dagegen weniger für die Integration anderer bestehender Systeme.

5.3.2 Gang of Five

Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad und Michael Stal sind die Autoren des 1996 erschienenen Buches „Pattern-oriented Software Architecture:

A Systems of Pattern“, häufig auch als POSA1 bezeichnet. 2000 erschien Band 2 von Frank Buschmann, Michael Stal, Hans Rohnert und Douglas Schmidt unter dem Titel „Pattern-oriented Software Architecture: Patterns for Concurrent and Networked Objects“. Erschienen ist das Buch im Rahmen der Tätigkeit der Autoren im Software Engineering Lab bei Siemens. Die Muster hatten die Autoren einige Zeit vor Erscheinen des Buchs im Internet publiziert und sich dort mit anderen Mitgliedern der Community darüber ausgetauscht.

Im Gegensatz zu Gamma et al. (1995) sind die Beschreibungen nicht ausschliesslich auf objektorientierte Muster ausgelegt und umfassen nicht nur Beschreibungen von Entwurfs- mustern, sondern auch (Software-)Architekturmuster und Idioms.

(Software-)Architekturmuster beschreiben ein grundlegendes Strukturorganisationsschema für Softwaresysteme. Architekturmuster bieten eine Menge von vordefinierten Untersystemen, beschreiben deren Verantwortlichkeiten näher und enthalten Regeln und Richtlinien zur Organisation der Beziehungen dazwischen (Buschmann et al. 1996, S.

11ff.).

31

Entwurfsmuster liefern Schemen, um die Untersysteme oder Komponenten einer Software oder deren Beziehungen zu verfeinern, die üblicherweise aus verschiedenen kleineren (Software-)Architektureinheiten bestehen.

Idioms sind tiefere Ebenen von Programmiersprachen-spezifischen Mustern. Ein Idiom beschreibt, wie man bestimmte Aspekte von Komponenten oder Beziehungen zwischen Komponenten implementiert, indem man die Möglichkeiten einer bestimmten Pro- grammiersprache ausschöpft.

Als weitere Kriterien gliedern Buschmann et al. die Muster nach strukturellen Prinzipien und Funktionalität. Strukturelle Prinzipien sagen aus, ob die Systeme gekapselt oder verbunden sind, während die Funktionalität Aussagen über Kommunikation und Zugangs- protokolle macht. Während Gamma et al. bewusst nicht auf Muster für Nebenläufigkeit und verteilte Programmierung eingehen (1995, S. 2), widmen Buschmann et al. das zweite Buch ganz den Mustern für nebenläufige und vernetzte Objekte (2002).

Die Muster werden ausführlich beschrieben, wobei zuerst der Name steht, weitere mög- liche Bezeichnungen und ein zusammenfassender Kurzbeschrieb. Im Gegensatz zu Gamma et al. bildet ein Beispiel aus der Realität den Einstieg zur weiteren Beschreibung und steht nicht erst gegen Schluss. Es folgen die Beschreibung des Kontexts, des Problems, der Lösung und die Beschreibung der detaillierten Struktur mit der Illustration in einem OMT- Klassendiagramm. Die Dynamik beschreibt das Laufzeitverhalten eines Musters und wird durch sogenannte „Object Message Sequence Charts“ beschrieben. Zur Implementation geben Implementationsrichtlinien weitere Vorschläge. Programmbeispiele illustrieren die Umsetzung in Code. Der Abschnitt „gelöste Beispiele“ enthält wichtige Aspekte, die in der obigen Beschreibung noch nicht enthalten sind. Der nächste Teil enthält eine kurze Beschreibung von Varianten und Spezialisierungen der Muster, sowie bekannte Anwendungen in existierenden Systemen. Zuletzt stehen die Konsequenzen und Referenzen auf andere Muster.

Buschmann et al. beschreiben nicht nur Entwurfsmuster, sondern auch die darüber- und darunterliegenden Ebenen der Softwarearchitektur-Muster und Idioms. Sie trennen damit die eher generativen Muster von der programmiernahen Beschreibung der Implementa- tionsproblemstellungen. Insbesondere der zweite Band über die Programmierung neben- läufiger und vernetzter Objekte enthält ausschliesslich Muster, die auf Betriebssystemebene interagieren und beschreibt Lösungen für professionelle Software-Entwickler.

5.3.3 Riehle/Züllighoven

Riehle und Züllighoven haben 1996 ein wissenschaftliches Papier veröffentlicht, das ebenfalls drei verschiedene Typen von Mustern beschreibt: die konzeptionellen Muster, die Entwurfsmuster und die Programmiermuster. Riehle und Züllighoven haben ihre Erfahrung mit Pattern in der Entwicklung von interaktiven Softwaresystemen für Forschung und Industriepraxis erworben. Sie lehnen sich für die Musterbeschreibung an Alexander sowie an Gamma et al. an. Da Software Engineering drei Hauptmodelle (ein Applikationsmodell,

32

ein Softwaredesignmodell und ein Implementationsmodell) umfasst, ordnen Riehle und Züllighoven den Modellen die drei Muster zu.

Die konzeptionellen Muster, ursprünglich Interpretations- und Gestaltungsmuster genannt, werden durch die Begriffe und Konzepte eines Applikationsbereichs beschrieben. Konzeptionelle Muster unterstützen damit die Diskussion verschiedenster Gesichtspunkte aller in den Softwareentwicklungsprozess involvierten Gruppen (Riehle & Züllighoven 1996, S. 5ff.). Die Wahl von Metaphern als mentales Bild ist Teil des konzeptionellen Musters. Damit liegt die Ähnlichkeit zu den Analysemustern von Fowler auf der Hand.

Das Entwurfsmuster beschreibt, wie bei den vorher vorgestellten Autoren, die Struktur und Dynamik der Komponenten einer Software sowie deren Beziehung zueinander. Entwurfsmuster spezifizieren damit die konzeptionellen Muster. Programmiermuster, bei Buschmann et al. „Idioms“ genannt, beschreiben die Implementation des Softwaredesigns in eine Programmiersprache.

Die enge Beziehung zwischen den Konzepten von Gamma at al., Buschmann et al. und Riehle, Züllighoven beweist den Wert der vorgestellten Muster. Denn Muster haben gemäss Definition dann eine hohe Qualität, wenn sie immer wieder auftreten und die Realität gut beschreiben.

Auch Bass et al. (1998, S. 25 und 93f.) nehmen eine solche Dreiteilung vor. Systemmuster oder Architekturstile (präziser Softwarearchitektur-Stile) sind eine Beschreibung der verschiedenen Komponenten in Bezug auf deren Laufzeitkontrolle und deren Eigenheiten des Datenaustausches. Entwurfsmuster sind eine Sammlung von Objekten oder Objekt- klassen, die zusammenarbeiten, um eine bestimmte Lösung zu erreichen. Entwurfsmuster sind damit üblicherweise Bestandteil einer Komponente. Die Codemuster sind Programmiervorlagen, die in der Implementierung genutzt werden.

5.4 Anwendung der Entwurfsmuster

Smolarova und Navrat (1999, S. 139ff.) weisen darauf hin, dass Entwurfsmuster die Entwicklung häufig komplizierter machen, da eine zusätzliche Ebene hinzukommt. Dazu ist die Anwendung der Entwurfsmuster häufig mühsam, weil viel Handarbeit geleistet werden muss, um den Programmcode des Musters in eine bestehende Applikation einzufügen oder die Elemente der bestehenden Applikation ins Muster zu übernehmen. Sie schlagen vor, dass Muster in expliziter Form in Software umgesetzt werden sollten, damit sie für nachfolgende Entwickler erkennbar sind und Unterstützung durch Werkzeuge möglich wird. Dazu stellen sie zwei Anforderungen auf: Die Verfolgbarkeit der Muster (Traceability) und die Sichtbarkeit der Muster (Visibility). Die Verfolgbarkeit der Muster soll sicherstellen, dass über die Entwicklungsstufen das Muster als Einheit erkennbar bleibt. Die Sichtbarkeit verfolgt das Ziel, dass Teile eines Musters als zum Muster gehörend erkennbar sind. Um dies zu erreichen, schlagen Smolarova und Navrat vor, aus dem Entwurfsmuster-Katalog eine Sammlung von Musterprototypen zu erstellen. Diese

33

würden keine informellen Elemente enthalten, sondern sich auf die Repräsentation eines Musters konzentrieren und die Struktur beschreiben. Durch Festlegen der noch unbestimmten Teile eines Musters und Ersetzen der generellen Bezeichnungen durch spezifische würde man dann die Muster für den Gebrauch in einem Programm ableiten. Die Ableitung aus einem Prototyp erhöht die Verständlichkeit der strukturellen Abhängig- keiten.

5.5 Organisations- und Prozessmuster (Coplien)

James O. Coplien befasst sich schon länger mit Mustern und hat beim Reviewprozess des Buches von Gamma et al., wie auch von Buschmann et al. mitgewirkt. Coplien widmet sich aber über die Entwurfsmuster hinaus der „Human Side of Patterns“ (1996), wie ein gleichnamiger Artikel von ihm lautet. Zusammen mit Douglas Schmidt, Mitautor des zweiten Bandes von Buschmann et al., hat er das Buch „Pattern Languages of Program Design“ (1995) zur ersten PLoP-Konferenz (1994) herausgegeben. Coplien ist als Forscher bei den Bell Laboratories tätig.

Die Organisations- und Prozessmuster als soziale Muster werden als eine weitere Möglichkeit gesehen, den Softwareentwicklungsprozess zu verbessern. Coplien (1996, S. 1ff. und 1995, S. 183ff.) verweist auf die Ursprünge in den sozialen Mustern in der Anthropologie und auf die Beziehung zwischen Architektur und den sozialen Gruppen, die sich in den Gebäuden aufhalten (Alexander 1977, S. 529, 940).

Die Organisations- und Prozessmuster sind generative Muster, die helfen sollen, eine Organisation zu bilden und durch den Softwareentwicklungsprozess zu führen. Unter Organisation versteht Coplien dabei weniger eine institutionelle Organisation als eine Gruppe mit einem gemeinsamen Ziel. Die Organisationsmuster beschreiben besonders die Strukturen innerhalb einer solchen Gruppe. Die Prozessmuster dagegen beschreiben dabei die Aktivitäten.

Die Beschreibung der Muster gliedert sich ähnlich wie bei anderen Autoren: Name, allenfalls andere Bezeichnung, Kontext, die einwirkenden Kräfte, Lösung und die Lösung auf den Kontext übertragen, sowie manchmal noch die Gedankengänge bis zur Lösung.

Die Anzahl der vorgestellten Organisationsmuster ist mit 31 umfangreich (Coplien 1995, S. 235). Zum Entwicklungsprozess bestehen elf Muster. Coplien hat mit seinen Mustern die Grundlage für eine vertiefte Auseinandersetzung mit Organisations- und Prozess- mustern geschaffen.

34

5.6 Muster zur Prozessverbesserung (Appleton)

Die Muster von Appleton (2000, S. 1ff.) sind genauer Muster zur erfolgreichen Software- entwicklungs-Prozessverbesserung. Sie werden als „I-SPI“ bezeichnet, eine Abkürzung für „Initiating Software Process Improvement“ und wurden an der PLoP-Konferenz 1997 vorgestellt. Appleton geht dabei von der Idee aus, dass Ähnlichkeiten zur Produkt- entwicklung bestehen. Appleton hat die Muster in Prozessverbesserungsinitiativen sowohl als „Change Agent“, wie als Veränderungsbetroffener erfahren.

Appleton weist darauf hin, dass Prozessveränderung mehr umfasst, als die blossen Prozesse. Sie löst eine kulturelle Veränderung aus mit all den Schwierigkeiten, die Wahr- nehmung, die Werte und das normative Verhalten einer Gruppe zu ändern. Die zehn Muster werden in die Gruppe der Organisationsmuster und der Prozess- und Kommuni- kationsmuster unterteilt. Zur Beschreibung der Muster benutzt Appleton seinen Grundraster (2000, S. 9ff.) mit Name, Kontext, Problem, Kräfte, Lösung, Resultat im Kontext, Gedankengänge und verwandte Muster.

Die Organisationsmuster haben die Namen „Local Heroes“, „Center Process Engineering Group“, „Process Improvement Team also Practices“, „Dedicated Improvement Processors“ und „Improvement Action Teams“. Das Kommunikationsmuster heisst “Virtual Forum”, die Prozessmuster „Process is a Product“, „Process follows Practice“, „Improvement follows Process“ und „Improvement follows Spiral“, wobei dieses ein Vor- gehen in einer Spiralenform vorschlägt.

Appleton merkt kritisch an (2000, S. 17), dass die Muster noch nicht ganz vollständig sind. Die Muster sind entsprechend ihrer Bestimmung eher auf Verbesserung eines Software Engineering Prozesses ausgelegt, als auf das Vorgehen in der Architekturgestaltung.

35

6 Architekturmuster und andere Muster

6.1 Einleitung

In den vorangegangenen Kapiteln wurde in die IT-Architektur eingeführt und die Prinzipien von Mustern vorgestellt. Dabei wurde im Kapitel IT-Architektur der Begriff Softwarearchitektur erläutert und auf die Arbeiten des Software Engineering Institute (SEI) hingewiesen. Im letzten Kapitel darauf hingewiesen, dass neben den Analysemuster und Entwurfsmustern auch Organisations- und Prozessmuster, sowie Softwarearchitektur- Muster existieren. Auf die Softwarearchitektur-Muster, die Organisationsmuster und weitere Muster wird in diesem Kapitel nun eingegangen.

6.2 Softwarearchitektur-Muster (Carnegie Mellon)

Im Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh wird nach Verbesserungen im Software-Engineering-Prozess geforscht. Softwarearchitektur wird dabei vorwiegend aus der Perspektive des Software Engineering gesehen (Bass et al.1998, S. 21) (vgl. dazu Softwarearchitektur nach Carnegie Mellon im 3. Kapitel). Code- Wiedergebrauch, kürzere Entwicklungszyklen, die Möglichkeit Komponentenentwicklung extern zu vergeben, die Unterstützung bei der Planung von qualitativ hochwertigen Prototypen und ähnliches, stehen dabei im Vordergrund.

Durch die umfangreiche Forschungstätigkeit wurde über Jahre grosses Wissen aufgebaut und daraus ein Katalog von Mustern erstellt. Die gewonnenen Erkenntnisse wurden anschliessend in grossen komplexen Softwareprojekten angewendet und validiert. Obwohl die Softwarearchitektur-Muster jeweils „Architecture Styles“ genannt werden, entsprechen sie der andernorts gebrauchten Bezeichnung von Softwarearchitektur-Muster. Eine Klassifikation der verschiedenen Muster in verwandte Gruppen entwickelten Shaw und Clements (1997), wobei sie auch Muster von verschiedenen Autoren zusammengetragen haben. In Bass et al. (1998) wurde eine überarbeitete Version publiziert. Dabei existieren fünf Obergruppen an Mustern, nämlich Data-Flow, Call-and-return, Independent Components, Data-centered und Virtual Machine. Ähnliche Muster oder gar dieselben Muster finden sich auch bei Buschmann et al. (1996, S. 25ff.). Diese Muster untergliedern sich in weitere Submuster, die sich wiederum in Spezialisierungen aufteilen können.

Da die Zuordnungen weder ausschliessend, noch eineindeutig sind, wird sie in verschiedenen Publikationen der Autoren unterschiedlich vorgenommen. 1997 werden die Datenfluss-Muster unterschieden in sequentielle Batch, Datenfluss-Netzwerk und ge- schlossene Loop Control. 1998 wird als wichtigste Gruppe zwischen sequentiellem Batch und Pipes and Filters unterschieden (vgl. Abbildung 8). Die Begriffsunklarheiten werden von Bass et al. (1998, 107) zwar erkannt, aber nur ungenügend ausgeräumt, da die Muster nicht beschrieben und katalogisiert werden, sondern nur in Tabellen eingeordnet.

36

Abbildung 8: Klassifikation von Softwarearchitektur-Muster

Independent Components

Communicating

Event Systems

Processes

Implicit

Explicit

Invocation

Invocation

Data Flow

Data-Centered

Batch

Pipes and

Repository

Blackboard

Sequential

Filters

Virtual Machine

Call and Return

Interpreter

Rule-Based

Main program

Object

Layered

System

andSubroutine

Oriented

Quelle: Clements et al. 1998, S. 95

6.3 EAI Architekturmuster (Lutz)

Jeffrey Lutz, Consultant bei einer EAI- und e-commerce-Beratungsfirma, stellt in einem Artikel im EAI-Journal (2002, S. 64) fünf verschiedene EAI-Architekturmuster vor. Diese dienen der Integration verschiedener Applikationen, sowie der Integration von Kompo- nenten innerhalb einer Applikation. Sie haben sich in der Praxis mehr als einmal bewährt oder sind in Werkzeugen von namhaften Herstellern im EAI-Bereich enthalten.

Die Muster heissen „Integration Adapter“, „Integration Messenger“, „Integration Façade“, „Integration Mediator“ und „Process automator“. Sie sind verwandt mit entsprechenden Entwurfsmustern wie sie Gamma et al. (1995) vorschlagen. Als Hauptunterschied wird angeführt, dass Architekturmuster die systemweiten strukturellen Eigenschaften bestimmen und Auswirkungen auf die Untersysteme haben, Entwurfsmuster dagegen nicht.

Zur Beschreibung der Muster verzichtet Lutz auf ein Format. Die Musterbeschreibungen enthalten aber doch die wichtigsten Elemente: Zuerst den Namen des Musters, kurz die Problemstellung, dann die Lösung und deren Nutzen illustriert an Beispielen. Dazu verwendet Lutz Grafiken.

Den Nutzen von EAI-Mustern sieht Lutz neben einer schnelleren Erstellung von EAI- Architekturen darin, dass sie einen Rahmen liefern um EAI-Werkzeuge verschiedener An- bieter auf ihre Stärken und Schwächen hin, besser beurteilen zu können. Daneben helfen sie Anwendungsintegrationsstandards in Unternehmen zu etablieren (Lutz 2000, S. 73).

37

6.4 Musterbasierte Integrationsarchitekturen (Mularz)

Diane Mularz schlägt im Rahmen der ersten PLoP-Konferenz vier Integrationsmuster vor, die aus der Erfahrung der Integration bestehender Systeme entstanden sind (1995, S. 441ff.). Sie arbeitete für das MITRE, ein Forschungszentrum, das Aufträge für amerikanische Regierungsstellen im Bereich der Luftfahrt und Verteidigung ausführt.

Die Beschreibung der Muster erfolgt dabei strukturiert nach Name, Absicht, Kontext, eine Beschreibung der Integrationskonflikte, die gelöst werden und die Lösung, sowie deren Anwendbarkeit und der Hinweis auf ergänzende Muster. Eine Grafik dient der Visuali- sierung.

Das erste der vier vorgestellten Muster ist „Wrapper“, welches die Integration von Legacy Systemen ermöglicht. Der „Work Flow Manager“ führt vom Benutzer bestimmte Auf- gaben in der festgelegten Reihenfolge aus. Der „Broker“ ermöglicht die Integration von verteilten heterogenen Systemen, unabhängig von deren Standort, Kommunikations- protokoll und Plattformabhängigkeit. Wenn Komponenten gewisse Informationen mit anderen teilen sollten, und anschliessend intern verarbeiten, wird das „Shared Repository“ als viertes Muster vorgeschlagen. Mularz weist darauf hin, dass die Muster noch etwas rudimentär beschrieben sind und allenfalls weitere dazukommen könnten. Die Konzentra- tion auf vier wesentliche Ansätze, kurze präzise Beschreibungen im erwähnten Musterfor- mat und unterstützende Grafiken, machen die Muster von Mularz leicht verständlich.

6.5 Daten- und methodenbasierte Muster (Linthicum)

Linthicum (2002) schlägt eine Vereinfachung der Entwurfsmuster vor und führt diese auf zwei Grundmuster zurück: Datenbasierte und methodenbasierte Integrationsmuster. Er lehnt sich dabei an zwei Typen der Anwendungsintegration an, die er bereits in seinem Buch „Enterprise Application Integration“ (2000) beschrieben hat. Linthicum ist ein aus- gewiesener Praktiker, der immer wieder zum Thema Anwendungsintegration publiziert.

Die datenbasierte Integration umfasst Prozesse, Techniken und Technologien zur Ver- schiebung von Daten zwischen Speichern. So werden bei datenbasierter Integration Daten aus verschiedenen Datenbank extrahiert, benötigte Information weitergeleitet und andere Datenbanken damit aktualisiert. Als Untermuster verweist Linthicum auf die Ausprägun- gen relational, objektorientiert, hierarchisch oder multidimensional.

Bei der methodenbasierte Integration wird die Geschäftslogik integriert. Man bezeichnet es auch als Prozess-Integration. Auf einem zentraler Server sind die Methoden abgelegt und damit anderen Applikationen zugänglich. Das erfordert vorgängig die Definition eines allgemeinen Methodensets (Frameworks). Damit besteht die Gefahr, dass die Kosten der methodenbasierten Integration und den Nutzen übersteigen. Die Untermuster der methodenbasierten Integration können objektorientiert, transaktional oder prozedural sein.

38

Im Buch erwähnt Linthicum zusätzlich die Benutzungsoberflächen-Integration und Appli- kationsschnittstellen-Integration. Beide machen Geschäftsprozesse und Daten durch ein Interface zugänglich (2000, S. 39) und stehen zwischen methodenbasierter Integration und datenbasierter Integration. Denn sie können mehr als Daten integrieren, sind aber bei Geschäftsprozessintegration nicht allmächtig. Während die Applikationsschnittstelle voraussetzt, dass die Applikation mit einer Schnittstelle ausgestattet wurde, nützt eine Be- nutzerinterface-Integration das bestehende Benutzerinterface zur Integration (2001, S.

52ff.).

Abbildung 9: Databasierte vs. methodenbasierte Integration

If

choose

Data Level

Method Level

need to access application logic

x

data is bound to a method (e.g. object-oriented)

x

data may be extracted from application without interfering with application integrity (Database)

x

data level interfaces exist (e.g. ODBC)

x

information (not data) can be extracted at an application level (e.g. API)

x

method level technologies exist (application server, distributed objects)

x

low latencies are important

x

Quelle: eigene Darstellung nach Linthicum 2000

Obwohl Linthicum auf das übliche Grundformat eines Musters (Kontext, Problem, Lösung) hinweist, sind seine Muster nur ansatzweise entsprechend beschrieben. Die Fokussierung auf zwei Muster lässt eine leichte Zuordnung zu einem der Muster zu. Im Buch beschreibt Linthicum allerdings noch zwei weitere Muster.

6.6 Muster zur Umsetzung der Architektur (Dikel et al.)

Dikel et al. gehen in ihrem Buch „Software Architecture – Organisational Principles and Patterns“ (2001) über die technischen Entwurfsmuster hinaus und befassen sich mit Orga- nisationsfragen. Die Autoren sind alle als Berater tätig. Fünf Organisationsprinzipien Vi- sion, Rhythmus, Antizipation, Partnerschaft und Vereinfachung (Englisch: Simplification) bilden das VRAPS-Modell (Dikel et al. 2001, S. 2ff.). Dieses Modell haben sie bei einer Reihe von Firmen angewandt, wovon im Buch einige Fallstudien vorgestellt werden.

Die Beschreibung der Muster gliedert sich sehr ausführlich etwa dem Raster aus Abschnitt „4.6 Dokumentation von Mustern“ entsprechend. Als Besonderheit stellen die Autoren den Mustern auch Anti-Patterns, also Anti-Muster gegenüber. Das sind Muster, die im jeweiligen Kontext falsch wären und nicht angewendet werden sollten. Sie bilden somit das Gegenstück zu den Mustern. Es werden hier drei Muster herausgegriffen, die sich mit der methodischen Einführung einer neuen Architektur befassen.

39

Das Pilotprojekt-Muster schlägt vor, bei einer IT-Architektur-Lösung, die für andere, allenfalls gar externe Organisationseinheiten bestimmt ist, ein Pilotprojekt durchzuführen (Dikel et al. 2001, S. 114ff.). Durch positive Erfahrungen im Pilotprojekt werden die anderen Benutzer ermuntert. Wichtig ist dabei das Projekt so zu gestalten, dass weder Überforderung auftritt, noch der Eindruck entsteht, die neue Lösung sei einfach zu bewältigen. Im ersten Fall könnten die zukünftigen Anwender resignieren, im zweiten Fall könnte das Projekt unterschätzt oder als unwichtig betrachtet werden.

Das Muster „Architektur-Review“ wurde in Anlehnung an Bass et al. verfasst. Es kommt auch bei Coplien (1995, S. 206) vor. Damit soll der durchschlagende Erfolg der Architektur sichergestellt und gewisse Fehler verhindert werden. Es schlägt vor ein Review-Team zu bilden, in das die Anspruchsgruppen eingebunden sind.

Wenn in einem Unternehmen neue Technologien benötigt werden und diese nicht zu den derzeitigen oder zukünftigen Kernkompetenzen gehören, soll das dritte Muster angewandt werden: „Outsourcing“. Dabei wird die Entwicklung einer Komponente zur Entwicklung an einen Partner vergeben.

Insgesamt handelt es sich bei den Mustern von Dinkel et al. um organisatorische oder Pro- jektmanagement-Grundsätze, die gut verständlich formuliert in ein Musterformat gebracht wurden. Nützlich sind die ausführlichen Aufstellungen mit Verweisen auf die Muster anderer Autoren.

6.7 Strategie-Muster (King)

Die Globalisierung der Unternehmen hat Auswirkungen auf deren IT-Strategie. King und Sethi (2001, S. 201ff.) haben vier verschiedene Typen von multinationalen Unternehmen in Bezug auf fünf Dimensionen untersucht und anschliessend drei Muster von IT-Strategien gefunden. Dazu haben sie 150 multinational tätige Unternehmen in 20 Ländern und 25 verschiedenen Industrien befragt und die Daten anschliessend statistisch ausgewertet. Ausserdem hat King bisher 300 Publikationen zu Themen der Informationssysteme, des Managements und der strategischen Planung veröffentlicht.

Entsprechend der geringen geografischen Verteilung haben nur wenige Tochterfirmen im ersten Muster eigenständige Planungen globaler Informationssysteme. Die Planung erfolgt implizit mit der Planung am Hauptsitz. Aspekte der Softwareentwicklung erfolgen zentral. Die Tochtergesellschaften nehmen wenig Einfluss auf die Planung am Hauptsitz, aber ho- len oft Rat ein zur Lösung der lokalen Probleme. Die Hardware und Applikationen werden bei globalen Anbietern beschafft.

Das zweite Muster der Firmen hat sowohl Informationssystempläne auf Länderebene in den Tochtergesellschaften, wie auf internationaler Ebene. Auf untergeordneter Ebene wird viel geplant und das Management ist stark darin involviert. Die Daten zwischen den Län- dergesellschaften sind aber wenig standardisiert und die IT-Ausbildung findet lokal statt.

40

Abbildung 10: Ausprägungen bei multinationalen Unternehmen

Multinat. Corp. Type

Dimension

Export

Parent-Child

Portfolio

Global Firm

orientation

configuration

Configuration

Value-Chain configuration

Low

High

Low

High

Value-Chain coordination

Low

Medium

High

High

Strategic Alliances

Low

Low

Medium

High

Centralization

High

Low

High

Low

Market integration

Low

Low

Medium

High

Quelle: King & Sethi 2001, S. 204

Beim dritten Muster bestehen Pläne für die Ländergesellschaften und auf der internatio- nalen Ebene übergreifende Pläne. Diese übergreifenden Pläne existieren sowohl für Tochtergesellschaften im Besitz der Muttergesellschaft wie auch für Joint-Ventures. Der Grossteil der Planung erfolgt auf Unternehmensebene. Nichtsdestotrotz planen die Tochtergesellschaften auch sehr viel und bringen gute Beiträge ein. IT-Training geschieht sehr häufig in weltweiten Schulungen. Hardware und Applikationen werden entsprechend von global tätigen Anbietern beschafft und es wird auf Kompabilität geachtet.

Das vierte Muster, eine Kombination von geringer geografischer Verteilung mit lokaler Autonomie, wies keine der befragten Firmen auf.

King und Sethi verwenden zwar die Bezeichnung Muster zum Beschrieb dieser Strategie- typen. Es handelt sich aber nicht um Muster, die in einem Musterformat in Anlehnung an Alexander beschrieben sind. Der Grund, warum die Arbeit von King und Sethi hier vorgestellt wird, liegt darin, dass sie solche Strategietypen durchaus in einem Musterformat beschreiben liessen. Derzeit existiert auf dem Gebiet zu Mustern im Bereich der IT-Strategie wenig Literatur. Die strategische Ausrichtung eines Unternehmens ist aber bei der Festlegung der IT-Architektur einer Unternehmung durchaus relevant und sollte die IT-Architektur beeinflussen.

6.8 Musterbasiertes Reengineering (Beedle)

Michael Beedle, Berater, hat 1997 an der PLoP-Konferenz seine Business Process Reengineering Muster vorgestellt (1997b). Bereits 1995 hatte er ein objektorientiertes Reengineering-Konzept publiziert. Beedle schreibt (1997a): „There must be one comprehensive congruent enterprise model for the Organization, its IS Organization and its System Architecture.” Beedle schlägt dazu ein objektorientiertes Zachman Framework vor.

41

Die musterbasierte Reengineering-Methode (Pattern Based Reengineering PBR) basiert auf Geschäftsanwendungsfällen ¹ , ist architekturorientiert und stellt eine Mustersprache zur Verfügung um Reengineering durchzuführen. Folgende Phasen werden dabei chronologisch durchlaufen: Strategische Einschätzung, Geschäftsanalyse, Geschäftsent- wurf, Geschäftsentwicklung und Aufrechterhaltung (Beedle 1997a, S. 1ff.). Beedle erachtet den Begriff Muster dann als passend, wenn sich ein Muster mindestens dreimal in der Praxis bewährt hat. Seine Musterbeschreibungen verweisen daher jeweils auf eine Reihe von bekannten Anwendungen in Firmen. Die Muster wurden ausserdem dem „Shep- herding“ unterzogen. Damit wird in der Muster Community der Reviewprozess verstanden ² .

Beedle lehnt sich ebenfalls an das Musterformat von Alexander an (1997b, S. 2ff). Die BPR-Muster beschreiben die soziale, räumliche und zeitliche Evolution in einem Unternehmen und entsprechen, in chronologischer Reihenfolge geordnet, dem Ablauf des Reengineering.

Abbildung 11: Objektorientiertes Zachman Framework nach Beedle

Object-oriented

Applicable

Zachman Framework

Pattern language

Tools in Focus

Risk Assessments

Techniques

Objects in Focus

Financ. Forecasts

Scope

Pattern-based

BRP

Cost/Benefits

Analysis

Impact to whole organization

Process textual

descriptions

Large Scale

organization

ABC Tools

Impact to specific process reengin. Projects

Business Use

Small Scale Org. Business Object Model Roles

Business or

Pattern-based

Process and

Cases

Enterprise Model

BRP

Project Tools

System Use

CASE Tools

Cases

Large Scale Arch. Pattern (Buschm. et al.)

CASE Tools

System Model

Process and

Impact to appl. Development

Class categories Use Case Maps

Applications

Project Tools

CASE Tools

Impact to overall System and Architecture applications

Business Object

Technology Model

Business Patt.

Software Design

Patt. (Gamma)

Compilers

Debuggers

CM tools

Design Heuristics

Models

Design

Object Model + mechanism

CASE Tools

Impact to appl. development projects

Detailed Reprasentation

Idioms

Compilers

Edit, Compile,

Object Code i.e. C++, Java, Smalltalk

Debuggers

Link, Test

Testing tools

Quelle: Beedle 1997a, S. 5

Dabei werden verschiedenste Bereiche abgedeckt. So beschreiben einige Muster Rollen- modelle in Organisationen, wie Leader oder Business Architect. Dabei lehnt Beedle sich an die Arbeiten anderer Autoren an. Beedles Business Architect etwa entspricht dem „Re- engineering Czar“ von Hammer und Champy (1993, S. 115f.). Andere Muster beschreiben eher den Prozess der Veränderung. Wieder andere Muster dienen dagegen eher der Analyse der Ist-Situation. Die weniger umfangreich beschriebenen Muster bezeichnet Beedle als „Pattlets“ und nicht als Muster (Pattern).

¹ Business Use Cases

² vgl. www.hillside.net/conferences/shepherd.htm (Stand 20.08.02)

42

Im Oktober 2002 werden die bisher nur auszugsweise in Artikeln publizierten Muster in Buchform erscheinen. „Enterprise Architectural Patterns: Building Blocks of the Agile Company“ wird über 200 Muster für die verschiedensten Bereiche der Architekturplanung umfassen.

6.9 Integrationsmodelle (Brown)

Laura Brown, war lange Zeit als Beraterin tätig, bevor sie 1994 eine eigene Beratungs- firma gründete. Ihr Buch „Integration models – Templates for Business Transformation“ soll die Lücke zwischen Geschäftsmodellen (wie S-Kurven, Wertschöpfungskette und Kernkompetenzen usw.) und technischen Modellen (wie ERA-Modellierung, Use Cases, Datenflussdiagramme) füllen (Brown 2000, S. 39f.). Sie hat dazu acht Vorlagen von Integrationsmodellen vorgeschlagen, die einem öffentlichen Review auf der Homepages des EAI-Journal unterzogen wurden, sowie anschliessend einem Review von drei ausgesuchten Experten. Brown bezeichnet die Vorlagen wohl nicht als Muster, weil sie diese von den technischen Entwurfsmustern abgrenzen möchte. Integrationsmodelle sind dazu entwickelt worden, um ein Organisationsprinzip zur Modellierung von Integrationsproblemen und Lösungen zur Verfügung zu stellen (Brown 2002).

Die Integrationsmodelle von Brown sind in einem einheitlichen Format gegliedert, das aber von den vorgestellten Musterformaten stärker abweicht. Die Integrationsmodelle gliedern sich in Name, Kurzbeschreibung, Diskussion des Integrationsmodels, wann das Integrationsmodel angewandt wird. Anschliessend folgen Beispiele, der Nutzen und die Konsequenzen, die Folgerungen aus der Anwendung des Modells und Anwendungen im EAI-Umfeld, sowie der Verweis auf Integrationsmodelle, die gut harmonieren. Die acht Modelle von Brown (2000, S. 93ff.) heissen Cycle, Seed, Web, Flow, Wave, Ring, Cell und Tree.

Die Integrationsmodelle von Brown beziehen Fragestellungen, wie „Erfordert ein Ge- schäftsablauf ein Netz an Verbindungen oder Schichten zur Reduktion der Komplexität?“ mit ein. Der starke Einbezug der Geschäftsperspektive unterscheidet sich von anderen Autoren und deren Mustern.

6.10 Datenmodellierungsmuster (Hay)

David Hay hat ein Buch mit dem Namen „Data Model Patterns – Conventions of Thought“ verfasst (1996). Das Buch ist interessant, weil es sich nicht um objektorientierte Muster handelt. Hay hat über 25 Jahre Erfahrung in der Modellierung und Entwicklung von Datenbanksystemen. Die Muster werden dabei relational modelliert, aber da Hay sein Buch gerade mit dem Aufkommen der Muster-Community geschrieben hat, sind seine Muster nicht in einem Format beschrieben. Die Grundidee der Muster von Hay ist dieselbe. Auch seine Muster beschreiben Komponenten, die immer wieder verwendet werden können und häufige Geschäftssituationen oder Strukturen erfassen (1996, S. 22).

43

Die Vorteile musterbasierter Ansätze in der Datenmodellierung sind (Hay 1996, S. 5):

- Die Erstellung neuer Modelle wird einfacher und schneller.

- Die Modelle sind einfacher zu lesen, da sie alle ähnliche Formen haben.

- Das wiederum erleichtert die Verständlichkeit der Besonderheiten.

- Es werden Fehler vermieden, weil die Grundelemente gegeben sind.

- Es resultieren weniger Tabellen und die Wartung wird vereinfacht.

Das Buch umfasst unzählige Modellierungsvorschläge zur Mitarbeiterzuordnung, Re- gionenzuordnung, Vertragsrollenmodellierung und zu Prozessflüssen. Da sie in relationaler Notation mit unstrukturiertem Begleittext verfasst sind, sind sie nicht so einfach anwendbar wie andere Muster.

6.11 Unterstützungsmuster (Fowler)

Wie bereits erwähnt, beschreibt Fowler neben den Analysemustern sogenannte Unter- stützungsmuster. Während Analysemuster hilfreich sind für die Entwickler von Infor- mationssystemen, dienen die Unterstützungsmuster auf einer höheren Abstraktionsebene der Unterteilung einer IT-Architektur in Subsysteme. Das verwendete Modell ist eine sogenannte Schichtenarchitektur.

Fowler unterscheidet in zwei- und dreistufige Architekturen. Applikationen mit einer zwei- stufigen Architektur bestehen aus den Applikationen, die auf Datenbanken zugreifen. Bei einer dreistufigen Architektur ist das konzeptuelle Schema eine weitere Stufe, die zwischen den Datenbanken und den Applikationen steht. Der grösste Vorteil dieser Architektur ist, dass die mittlere Ebene sich auf die Geschäftsabläufe und die Semantik konzentriert, während die anderen Ebenen die Repräsentation und die Strukturierung und Speicherung der Daten übernehmen. Die mittlere Schicht wird beispielsweise druch die wichtigen wiederverwendeten Objekte in einer objektorientierten Programmierung gebildet. Fowler merkt an, dass derzeit solche Applikationen nicht sehr verbreitet sind (Fowler 1997, S. 243). Er schlägt ausserdem noch eine vierte Schicht vor, welche die Applikationslogik enthält und zwischen dem konzeptuellen Schema und der Präsentation steht (1997, S.

246f.).

Bei anderen Autoren, wie Linthicum, wird eine dreistufige Architektur anders definiert (2000, S. 46). Dort existiert eine Repräsentationsschicht, welche die Darstellung der Daten übernimmt. Darunter liegt die Schicht mit der Applikationslogik. Wie Linthicum schreibt, kann dies ein Applikationsserver sein. Die Logik kann sich stattdessen ebenso auf lokalen PCs befinden. Die dritte Stufe ist wieder die Datenschicht.

Eine solche Schichtarchitektur hat nicht nur Vorteile. So ist ein Extraaufwand zur Ent- wicklung der Schichten erforderlich. Manchmal treten auch Performance-Probleme auf (Fowler 1997, S. 249).

44

Als weiteres Unterstützungsmuster neben der Schichtenarchitektur wird das Fassaden- muster beschrieben, wie es auch bei Gamma et al. (1995, S. 185ff.) vorkommt. Dabei wird mittels einer einheitlichen Schnittstelle auf eine Menge von Schnittstellen eines Untersystems zugegriffen. Dies vereinfacht die Benutzung des Untersystems. Fowler beschreibt die Unterstützungsmuster nicht in einem Musterformat, wie es Gamma et al. beim Fassaden-Muster machen und verwendet auch nicht seine Formatierung wie bei den Analysemustern. Es ist dadurch schwieriger, zu verstehen, wann diese Muster eingesetzt werden sollten.

6.12 Schichtenarchitekurmuster

Schichtenarchitekturmuster sind nicht nur bei Fowler (1997) beschrieben. Buschmann et al. (1996, S. 34) stellen die Schichtenarchitektur ebenfalls als Softwarearchitektur-Muster vor und Bass et al. (1998, S. 98ff.) auch. Das bekannteste Modell einer Schichten- architektur ist das ISO/OSI-Modell mit den sieben Schichten Bitübertragung, Sicherung, Vermittlung, Transport, Kommunikation, Darstellung und Anwendung. In einer Schichten- architektur kommunizieren die einzelnen Schichten theoretisch nur mit den benachbarten Schichten. Wie Bass et al. schreiben wird das Modell teilweise untergraben, indem aus Perfomance-Gründen Schichten erlaubt wird, mit zusätzlichen Schichten zu kommunizieren (1998, S. 100).

Das Schichtenmuster hat in der Softwarearchitektur breite Verbreitung gefunden. Die oberste Schicht ist dabei eine Repräsentations- oder Anwendungsschicht, die unterste Schicht eine Schicht mit Kernfunktionalitäten. Die Schichtenarchitektur kann nicht nur als Entwurfsmuster mit unterschiedlichen Ausprägungen, wie es bei den einzelnen Autoren beschrieben ist, gesehen werden. Es ist vielmehr ein grundlegendes Organisationsprinzip, das bei der Dekomposition von Architekturen hilft.

45

7 Architekturgestaltung

7.1 Einleitung

Ein Vorgehensmodell für die IT-Architekturgestaltung bei Integrationsprojekten zu entwickeln, ist eine Fragestellung, die eigentlich ausführlicherer Diskussion bedürfte. Es soll hier dennoch noch versucht werden, ein mögliches Modell zu entwickeln, um anschliessend zu beurteilen, inwiefern Muster für die einzelnen Phasen verwendet werden können.

Obwohl verschiedene Autoren mögliches Vorgehen ansatzweise skizzieren, sind die wenigsten Ansätze umfassend. Allgemeine IS-Architektur-Planungsansätze (wie sie auch Österle entwickelt hat, z.B. Österle et al. 1992) sind für die Problematik der Anwendungs- integration wenig zielgerichtet. Sie fokussieren zu stark auf die Neuentwicklung komplexer Applikationen. Um ein Vorgehensmodell abzuleiten, wird hier daher auf bestehende Modelle aus verwandten Bereichen zurückgegriffen.

7.2 Business Engineering

Die drei Ebenen des Business Engineering Metamodells von Österle wurden bereits unter „2.2 Ebenen des Business Engineering“ erläutert. Die Phasen eines Business Engineering unterteilen sich nach Österle (1995, S. 23) in Analyse, Entwurf, Implementierung und Betrieb. Wie Österle schreibt legt die Logik des Business Engineering ein Top-Down-Vor- gehen nahe (1995, S. 23). Dazu werden von der Geschäftsstrategie ausgehend die Prozesse und Systeme entwickelt.

Beedle schlägt in seiner Business Engineering Methode einen iterativen Zyklus vor, an dessen Anfang die Strategiefestsetzung steht. Darauf folgen die Geschäftsanalyse, der Geschäftsentwurf und anschliessend die Geschäftsentwicklung (1997a, S. 6). Im Gegen- satz zu Österle bezieht er damit die Informationssystemebene nicht explizit ein.

7.3 Software Engineering

Balzert schlägt in seinem „Lehrbuch der Softwaretechnik“ für die Softwareentwicklung ein Vorgehen in sieben Phasen vor (2001, S. 51ff.). Die Softwareentwicklung beginnt dabei mit der Planungsphase, wo eine Durchführbarkeitsuntersuchung vorgenommen wird. Darauf basierend wird dann am Ende der Phase entschieden, ob das Projekt weitergeführt werden soll. In der Definitionsphase werden die genauen Anforderungen ermittelt (Pflichtenheft) und eine Lösung modelliert. Die Phase des Entwerfens (Entwurfsphase) kann nach Balzert als „Programmierung im Grossen“ umschrieben werden (2001, S. 686). In der Implementierungsphase werden dann die entworfenen Komponenten verfeinert und umgesetzt. Die Übergabe des Produkts an den Auftraggeber folgt in der Abnahmephase. Daneben findet die Einführung der Benutzer statt. Diese Phase wird daher als Abnahme-

46

und Einführungsphase bezeichnet. Die kontinuierliche Wartung und Pflege bilden die letzte Phase.

Brown (2000, S. 64ff.) weist auf einige Unterschiede zwischen gewöhnlichen Software- projekten und Integrationsprojekten hin. Die Anforderungen in Integrationsprojekten entwickeln sich demnach erst pragmatisch im Verlaufe der Zeit und stehen nicht schon zu Beginn fest. Das legt ein interatives Vorgehen nahe. Statt Entwicklung einer Applikation für eine bestimmte Abteilung, liegt der Fokus in der Integration auf der Wieder- verwendung bestehender Applikationen mit dem Ziel, neue übergreifende Geschäfts- prozesse zu unterstützen. Wie Brown auch erwähnt, ist bei Integrationsprojekten nicht dem Entwickler überlassen, in welcher Technologie eine Lösung umgesetzt wird. Es sind zahlreiche Restriktionen vorhanden. Da häufig Problemstellungen aus unterschiedlichen Bereichen gelöst werden müssen, sind eher Generalisten statt Spezialisten gefragt. Ein Bei- spiel ist die Anbindung existierender Applikationen an das Internet. Es ist dabei hilfreich, auf Erfahrungen anderer zurückgreifen zu können. Eine weitere Herausforderung ist die Integration unterschiedlichster Datenquellen und Datensätze.

7.4 Implementation einer EAI-Architektur

Cummins (2002, S. 406) schlägt ein Vorgehen zur Umsetzung von Anwendungsintegra- tions-Architekturen mit elf Schritten vor. Im Gegensatz zu anderen Autoren geht er ebenfalls von einer strategischen Planung aus, gestaltet dann die Geschäftsprozesse und befasst sich anschliessend mit der Implementation des Informationssystems. Cook (1996, S. 161ff.) befasst sich dagegen nur mit der Implementation und Britton nur mit den Geschäftsprozessen und der Implementation (2001, S. 267ff.).

Die elf Phasen bei Cummins sind:

- Strategische Planung

- Serviceorientierte Geschäftsprozesse entwickeln

- Benutzereinstellung verändern

- Infrastruktur umsetzen

- Infrastruktur verwalten (managen)

- Applikationsintegrationsziele setzen

- Standards festlegen

- Veränderung bewältigen

- Informationssystemmanagement konsolidieren

- Kritische Erfolgsfaktoren beachten

Cummins beachtet damit sowohl technische Aspekte, wie auch organisatorische und strategischen Fragen.

47

7.5 Mögliches Vorgehen bei der IT-Architekturgestaltung

Die folgende Abbildung soll zeigen, wie sich Geschäftsprozesse, die Informationssystem- architektur, die Applikationsarchitektur und Hardwarearchitektur gegenseitig beeinflussen. Das Vorgehensmodell für die Architekturplanung soll sich dabei grundsätzlich an der Leitidee des Business Engineering-Modell von Österle orientieren. Das heisst, aus der Strategie sollen die Prozesse und daraus die Architektur des Informationssystems bestimmt werden. Die Idee von Beedle, der Ansatz des Software Engineering von Balzert und Elemente des Vorgehensmodelles von Cummins werden ebenfalls einbezogen.

Abbildung 12: Beziehung des Business Engineering zum Software Engineering

Geschäftsprozesse

(Business Engineering)

Informationssystem-

architektur

Hardware-

architektur

Applikationsarchitektur

(Software Engineering)

Quelle: in Anlehnung an Brown (2000, S. 28)

Strategische Einschätzung

In der strategischen Planung sollte zuerst eine gemeinsame Vision festlegt werden (Cummins 2002, S. 407ff.). Dabei sind die Potentiale der Informationstechnik für das Unternehmen zu beachten (Österle 1995, S. 15). Eine mögliche Entscheidung wäre etwa, in einem Unternehmen den Kunden zukünftig Lieferfristen von 24 Stunden anzubieten. Falls batchgesteuerte Kommunikation im Unternehmen dominiert, ist das Informations- system auf ereignisgesteuerte Abläufe umzubauen. Weil Batchabläufe nur zu festgelegten Zeiten die Daten zwischen verschiedenen Applikationen übergeben, z.B. einmal täglich, ergeben sich Verzögerungen in der Bearbeitung. Bei ereignisgesteuerten Abläufen entfallen diese Verzögerungen (Cummins 2002, S. 408).

Geschäftsprozesse

Prozesse sind im Business Engineering-Modell von Österle das Bindeglied zwischen Stra- tegie- und Systementwicklung (1995, S. 20f.). Diese Phase lässt sich glieden in Geschäfts- analyse, Geschäftsentwurf und Geschäftsentwicklung (vgl. Beedle 1997a, S. 6). Geschäfts- prozesse bestehen aus Aufgaben, die über verschiedene Abteilungen verteilt sind. Früher unterstützten Applikationen Einzelfunktionen in Abteilungen, bei Hasselbring als Autonomie der Applikationen bezeichnet (vgl. 2.4 Dimensionen der Integration). Vor der Bestimmung der Architektur eines Informationssystems sollte eine Geschäftsanalyse und ein Geschäftsentwurf stattfinden. Ein IT-Architekt hat daher immer auch die Funktion des

48

Business Engineers. Es wurde bereits darauf hingewiesen, dass die IT-Architektur auch noch an die nächste Geschäftsprozessveränderung anpassbar sein soll. Obwohl der IT- Architekt enge Verknüpfungspunkte mit dem Business Engineering aufweist, muss er bereits die nächste Veränderung antizipieren und anpassbare Applikationen schaffen.

Applikationsintegrationsziele festlegen

Ausgehend von der Vision der Geschäftsstrategie und den Kenntnissen der Geschäfts- prozesse können die Integrationsziele entwickelt werden. Mögliche Ziele sind dabei lose Koppelung der Applikationen oder feste Anbindung, Anbieten eines internetbasierten Zu- griffs auf Applikationen, Einführen Work-Flow-basierter Prozessautomation oder Anbieten offener Dienste wie Verzeichnisdienste.

Österle (1992, S. 122ff.) weist auf die Wichtigkeit der Bewertung des Integrationsnutzens und der Integrationskosten hin (1992, S. 122ff.) Denn wie Linthicum (2002) schreibt, übersteigen die Integrationskosten manchmal den Nutzen.

Analyse der Infrastruktur und Standards festsetzen

Bei der Integration bestehender Applikationen sind die Vorgaben umfangreicher, als bei der Entwicklung neuer Applikationen. Eine Analyse der Applikationen, Datensätze und der zugrunde liegenden Technologien muss daher vor dem Entwurf erfolgen. Ausserdem erfolgt üblicherweise ein Entscheid für bestimmte Standards. Das können offene Standards oder herstellerabhängige Standards und firmeninterne Standards oder Internetstandards sein.

Softwarearchitektur festlegen

In dieser Phase erfolgt die Planung der Softwarearchitektur durch Festlegung der Schnitt- stellen und Bestimmung neuer Komponenten. Es werden technische Integrationsmöglich- keiten zur Lösung der Heterogenität und Distribution bestimmt.

Applikationsentwicklung

Die Applikationsentwicklung setzt die Pläne und Vorgaben um. Hierbei sind die Standards einzuhalten, Wiederverwendbarkeit zu fördern, Reviews und Integrationstests durch- zuführen. Für die Applikationsentwicklung werden die Methoden des Software Engin- eering angewandt, wie sie z.B. im Vorgehensmodell von Balzert beschrieben sind. Da immer mehr Softwareprodukte Schnittstellen enthalten oder durch Unterstützung von CASE-Tools entfällt die Applikationsentwicklung teilweise.

Projektmanagement

Anwendungsintegration erfordert ein Umdenken im Verhalten der Betroffenen. Wie in Ab- schnitt 2.4 erläutert, sind vielfach Widerstände gegen Integration vorhanden. Diese können aus Angst vor Machtverlust resultieren oder weil die Betroffenen in überholten Denk- abläufen verhaftet sind. Daneben müssen auch die Personen, die in einem Projekt arbeiten, gemanagt werden. Dieser Teil hat fortlaufend stattzufinden.

49

7.6 Muster zur Unterstützung der Architekturgestaltung

Da es das Ziel dieser Arbeit ist, zu untersuchen, inwiefern Muster die Architektur- gestaltung unterstützen. Die vorgestellten Phasen werden hier daher in Verbindung zu den Mustern gebracht.

Strategische Einschätzung

King und Sethi haben mit ihrer Untersuchung zur IT-Strategie in multinationalen Unter- nehmen Strategiemuster ermittelt, die zwar nicht in der 3-Teile-Regel oder in einem anderen Format beschrieben sind. Aber es ist möglich, ein Unternehmen in Bezug auf die fünf Dimensionen (Wertschöpfungskettenkonfiguration und -koordination, strategische Allianzen, Zentralisation und Marktintegration) zu beurteilen und die Ähnlichkeit mit einer der drei Gruppen zu bestimmen. Darauf kann die entsprechende der geschilderten IT- Strategien in Betracht gezogen werden.

Obwohl Dinkel et. al. eher Prozessmuster vorschlagen, ist z.B. das „Outsourcing-Muster“ nicht ohne strategischen Bezug. Es gibt eine Richtschnur vor, wann Outsourcing sinnvoll ist.

Insgesamt fehlen aber in einem Musterformat beschriebene Muster, die Bezug auf die Strategie nehmen. Die Geschäftsstrategie hat aber durchaus Auswirkungen auf das Infor- mationssystem. So benötigt ein Unternehmen, das eine Expansionsstrategie verfolgt, auch eine entsprechend skalierbare Architektur.

Geschäftsprozesse

Auf der Ebene der Geschäftsprozesse sind die Muster von Beedle einzuordnen. Beedle unterstützt mit seinen Mustern die Phasen der Geschäftsanalyse, des Geschäftsentwurfes und der Geschäftsentwicklung. Die Muster befassen sich einerseits mit der Reorganisation von Geschäftsprozessen und andererseits beinhalten sie Handlungsanweisungen um die Veränderung zu bewältigen.

Applikationsintegrationsziele festlegen

Muster die zwischen Geschäftssicht und technischer Ebene stehen, sind selten. Die Integrationsvorlagen von Brown schliessen diese Lücke. Geschäftsziele wie reduzierte Durchlaufzeit, Teilung von Ressourcen oder die parallele Bearbeitung von Prozessschritten können in Muster umgesetzt werden, denen man anschliessend Muster zur technischen Realisation zuordnen kann.

Analyse der Infrastruktur und Standards festsetzen

Das Muster der Schichtenarchitektur hilft definitionsgemäss bei der Unterteilung einer IT- Architektur in Subsysteme. Es ist daher nicht nur zur Festlegung einer Softwarearchitektur hilfreich, sondern auch bei der Analyse. Softwarearchitekturmuster können generell einen Beitrag zur Bestimmung und Modellierung der bisherigen Infrastruktur leisten.

50

Softwarearchitektur festlegen

Fowler beschreibt in seinen Analysemustern konzeptionelle Strukturen von Geschäfts- prozessen in objektorientierter Form. Hay beschreibt solche konzeptionellen Strukturen zu Geschäftsfällen in relationaler Form. Die Muster gehen über die Entwurfsmuster der Softwarearchitektur hinaus, weil sie die Muster nicht nur aus Sicht der technischen Imple- mentation beschreiben, sondern als Lösung zu Problemen in Geschäftsprozessen.

Lutz beschreibt in seinen Mustern auch Geschäftsvorfälle, für welche die Muster eine Lösung sind. Er geht damit weiter als Mularz, welcher die Softwarearchitektur-Muster zur Integration nur grundlegend beschreibt. Die Muster der verschiedenen Autoren der Carnegie Mellon-Universität sind dagegen nur auf die technische Ebene fokussiert. Linthicums Muster sind eher grundlegene Ansätze zur Integration. Da er sowohl auf die Geschäftsprozesse eingeht, als auch konkrete Programmzeilen beschreibt, dienen seine Publikationen eher dem Überblick.

Im allgemeinen kann hier unterschieden werden zwischen den technisch geprägten Auto- ren, wie die Gamma et al., Buschmann et al., die Autoren der Carnegie Mellon University, Mularz und solchen, die in den Musterbeschreibungen auch auf die Geschäftsunterstützung eingehen (Fowler, Hay, Lutz).

Applikationsentwicklung

Die Entwurfsmuster der verschiedenen Autoren sind sehr implementierungsnahe. Obwohl sie die Phase der Softwarearchitekturfestlegung ebenfalls unterstützen können, werden sie hier eingeordnet, da sie aus der Softwareentwicklung entstanden sind. Buschmann et al. und Gamma et al. führen in den Beschreibungen gar Beispiele von Programmcode an.

Projektmanagement

Die Muster zum Projektmanagement entstanden aus der Erkenntnis, dass die menschliche Dimension der Softwarentwicklung ebenfalls durch Muster beschrieben werden kann. Coplien hat dazu seine Organisations- und Prozessmuster entwickelt. Diese sind sehr universelle Projektmanagementansätze und können auch als Richtlinien zum Prozess der IT-Architekturgestaltung beigezogen werden. Appleton bezieht sich mit seinen Mustern zur Prozessverbesserung dagegen eher auf die Prozesse der Softwareentwicklung.

Insgesamt ist auf der Ebene des Software Engineering im Bereich der Muster viel geleistet und publiziert worden. Anwendungsintegration interessiert sich aber nicht nur für die technische Zusammenarbeit zwischen Komponenten, sondern auch für den Geschäftskontext. Die Verknüpfung der Integrationsmuster mit der Geschäftssicht ist derzeit eher rar. Aus Sicht der Unternehmen besteht hier sicher Handlungsbedarf. Denn gegenüber Frameworks bieten Muster den Vorteil der Programmiersprachenunabhängigkeit.

51

8

Schlussbetrachtung

8.1 Zusammenfassung

Im Bereich der Softwareentwicklung ist in den letzten Jahren eine Community entstanden, die sich mit Mustern befasst. Die Muster des Städtebauers Alexander waren dabei der Aus- gangspunkt. Um aus Erfahungen anderer zu lernen, auf bewährte Lösungen zurückgreifen zu können und die Kommunikation zwischen Entwicklern zu erleichtern, werden die Muster in Katalogen mit einheitlichem Format beschrieben. Neben den Mustern des Softwareentwurfs entstanden Organisationmuster, welche die optimale Zusammensetzung eines Projektteams beschreiben.

In Unternehmen führen verschiedene Einflüsse, im besonderen die Ausrichtung der Pro- zesse auf den Kunden, zum Bedürfnis heterogene autonome Applikationen integrieren zu können. In der technischen Integration wurden inzwischen viele Probleme gelöst. An- wendungsintegration befasst sich aber auch damit wie die Geschäftsziele und -prozesse durch Integration unterstützt werden können. Dabei gilt es neben der technischen Sicht auch die Geschäftssicht zu berücksichtigen. Der IT-Architekt hat dadurch unterschiedliche Perspektiven zu beachten wie die Geschäftsprozesse, die Organisation, die Nutzungssicht und die Probleme der Implementierung. Die IT-Architekturgestaltung unterscheidet sich darin vom Software Engineering.

Bei all diesen Anforderungen liegt der Gedanke nahe, durch Muster bewährte Lösungen zu Problemen zur Verfügung zu haben. Doch die Entwurfsmuster der Softwarearchitektur reichen dazu nicht aus. Diese Arbeit zeigt weitere Muster aus der aktuellen Literatur, die sich für die Architekturgestaltung verwenden lassen. Zu technischen Implementations- muster existieren inzwischen einige Publikationen. Aber auf der Geschäftsseite sind diese eher selten.

Die Qualität eines Musters richtet sich nach der Strukturiertheit der Sprache, ob sich die Muster bewährt haben und von anderen Personen als gut bewertet wurden. Es wurden daher die Erfahrungen des Autors, ob ein Reviewprozess stattgefunden hat und das ge- wählte Format der Muster dargelegt.

Neben den Entwurfsmustern existieren die Analysemuster, die konzeptionelle Strukturen von Geschäftsprozessen entwerfen. Die Abbildung der Grobstruktur eines Softwaresys- tems erfolgt in den Architekturmustern. Weitere Muster wie Prozess- und Organisations- muster befassen sich dagegen mit den organisatorischen Aspekten. Eine Methode zu musterbasiertem Reengineering existiert ebenfalls.

Sogenannte Integrationsmodelle befassen sich mit der Modellierung von Integrationspro- blemen ausgehend von den Geschäftsanforderungen. Da eine ganzheitliche IT-Architektur- gestaltung der Informationssystemebene sich auch auf die Geschäftsstrategie ausrichten sollte, wurde nach Strategiemustern gesucht. Derzeit sind diese allerdings kaum vorhanden.

52

8.2 Schlussfolgerungen

Während bei homogenen Applikationen eigentlich keine Integrationsprobleme auftreten, ist die Integration heterogener Applikationen immer noch problematisch. Auf der Ebene des Software Engineering wurden durch Muster Fortschritte erzielt. Auf der Geschäfts- und Prozessebene besteht dagegen noch Handlungsbedarf. Grundsätzlich bringen Muster für die IT-Architekturgestaltung Nutzen. So sind sie ein gutes Teamkommunikationsmedium. Aus bewährter Erfahrung gewonnen, erfassen sie den wichtigen Teil eines Designs in einer kompakten Form und fördern die Wiederverwendung.

In der Softwareentwicklung existieren ausgereife Muster von Forschern und Praktikern. Die aufgezeigten Muster sind dabei meist in ähnlichem Format verfasst. Gewisse Muster treten bei fast allen Autoren auf. Der Weg zu Mustersprachen, die Muster eines ganzen Gebietes umfassen, ist erkennbar. Christopher Alexander hat dazu mit den Muster der Bauarchitektur den Grundstein gelegt. Aber ein Gedanke von Alexander hat derzeit noch keine grosse Verbreitung erfahren. Muster sollten die Kommunikation zwischen Vertretern verschiedenster Disziplinen fördern. Die Erwartung an Muster wäre zu Recht, dass sie helfen technische Konzepte Nicht-Technikern verständlich zu machen (Brown 2002). Derzeit ist die Community aber noch stark von der Softwarearchitektur getrieben. Die Beschreibung der Muster der „GoF“ und „GoV“ orientieren sich an den Bedürfnissen der Softwareentwickler.

Darin liegt ein Ansatzpunkt zur Weiterentwicklung. Es wurden bereits von den Software- entwicklungsmustern gewisse grundlegende Softwarearchitekturmuster abstrahiert. Auto- ren wie Lutz haben diese dann mit Geschäftssituationen verknüpft. Brown hat grundlegende Integrationsmodelle entwickelt, die sich vom technischen Blickwinkel gelöst haben. Ausgehend von Softwarearchitektur-Mustern sollte bottom-up die Weiter- entwicklung zu Mustern von Geschäftsprozessen oder gar Strategiemustern vorangetrieben werden, ähnlich wie bereits Organisations- und Prozessmuster entstanden sind.

Das sich bisher entwickelnde Musterformat zur Beschreibung von Mustern ist dafür aber wenig geeignet. Aspekte wie Geschäftsprozessunterstützung und Erweiterbarkeit sollten neben Performance und Codeoptimierung in Mustern enthalten sein. Die Frage der Reprä- sentation von IT-Architekturen wird auch durch sogenannte Architekturbeschreibungs- sprachen bearbeitet. Derzeit existieren verschiedene Forschungssprachen, aber kein einheitliches Grundkonzept (Gomaa & Menascé 2000, S. 117). Das Zusammenführen von Muster und Architekturbeschreibungssprachen wird die Architekturplanung vereinfachen.

Doch auf der Ebene der Softwaretechnik sind die Muster noch nicht ausgeschöpft. Aktuelle Forschung befasst sich damit, die Softwarearchitektur von Legacy Systemen zu ergründen ¹ . Ausserdem wären breitere Untersuchungen über den Einsatz von Mustern in Unternehmen sicher interessant. Bisherige Beispiele beziehen sich meist auf wenige Unternehmen mit denen die Autoren gearbeitet haben.

53

Literaturverzeichnis

Alexander, C., Ishikawa, S. & Silverstein, M. (1995): Eine Muster-Sprache : Städte, Gebäude, Konstruktion. (H. Czech, Übers./Hrsg.) Löcker, Wien.

Alexander, C. (1979): The timeless way of building. Oxford University Press, New York.

Appleton, B. (1997): Patterns for Conducting Process Improvement

Im Internet

abrufbar: http://www.enteract.com/~bradapp/docs/i-spi/plop97.html (19.08.02).

Appleton, B. (2000): Patterns and Software: Essential Concept and Terminology. Im Internet abrufbar: http://www.enteract.com/~bradapp/docs/patterns-intro.html

(09.08.02).

Balzert, H. (2001): Lehrbuch der Software-Technik – Software-Entwicklung. (2. Aufl.) Spektrum Akademischer Verlag, Heidelberg.

Bass, L., Clements, P. & Kazman, R. (1998): Software Architecture in Practice. Addison- Wesley Longman, Reading, Massachusetts.

Beck, K., Coplien, J., Crocker, R., Lutz, D. & Meszaros, G. (1996): Industrial Experience with Design Patterns. In: Proceedings of the 18th International Conference on Software Engineering, Berlin, Deutschland. IEEE Computer Society Press, Los Alamitos, Kalifornien, S. 103-114.

Beck, K. & Johnson, R. (1994): Patterns Generate Architectures. In: Proceedings of the ECOOP'94. Springer Verlag, Berlin, S. 139-149. Auf Internet abrufbar:

ftp://st.cs.uiuc.edu/pub/papers/frameworks/conduits+.ps (19.07.2002).

Beedle, M. (1997a): Pattern Based Reengineering. Object Magazine, Januar 1997. Im Internet abrufbar: http://www.e-architects.com/users/beedlem/papers.html

(20.07.02).

Beedle, M. (1997b): cOOherentBPR – A pattern language to build agile organizations. In:

Proceedings of the 4th Pattern Languages of Programming Conference, Monticello, Illinois. Im Internet abrufbar:

http://st-www.cs.uiuc.edu/users/hanmer/PloP-97/Workshops.html (20.07.02).

Boar, B. (1999): Constructing Blueprints for Enterprise IT Architectures. Wiley, New York.

¹

z.B. bei Fiutem et al. (1999) und Mendonca (2001).

54

Britton, C. (2001): IT Architecutres and Middleware. Strategies for Building Large, Integrated Systems. Prentice Hall, Upper Saddle River, New Jersey.

Brown, L. (2000): Templates for Business Transformation. Sams Publishing, Indianapolis.

Brown, L. (2002): System Innovations – Integration modelling, data warehousing, data strategy. Im Internet abrufbar: http://www.systeminnovations.net/integrat.htm

(06.08.02).

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P. & Stal, M. (1996): Pattern- oriented software architecture: a system of patterns. Wiley, Chichester.

Buschmann, F., Schmidt, D., Rohnert, H. & Stal, M. (2002): Pattern-orientierte Software- Architektur: Muster für nebenläufige und vernetzte Objekte. (M. Buschmann, Übers.) dpunkt-Verlag, Heidelberg.

Clements, P. & Northrop, L. (1996): Software Architecture: An Executive Overview. Technical Report, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania.

Coplien, J. (1995): A Generative Development-Process Pattern Language. In: J. Coplien & D. Schmidt (Eds.) Pattern languages of program design. Addison-Wesley, Reading, Massachussets, S. 183-237.

Coplien, J. (1996): The Human Side of Patterns. C++ Report, 8. Jg., Ausgabe 1. Im Internet abrufbar:

http://www.bell-labs.com/~cope/Patterns/C++Report/OrgPatterns-1.html (Stand

02.08.02).

Cook, M. (1996): Building Enterprise Information Architectures. Reengineering Information Systems. Prentice Hall, Upper Saddle River, New Jersey.

Cummins, F. (2002): Enterprise integration: an architecture for enterprise application and systems integration. Wiley, New York.

Cunningham, W. (2000): History of Patterns. März 2000. Auf Internet abrufbar:

http://c2.com/cgi-bin/wiki?HistoryOfPatterns (22.07.02).

Dikel, D., Kane, D. & Wilson, J. (2001): Software architecture: organizational principles and patterns. Prentice Hall, Upper Saddle River, New Jersey.

Devedzic, V. (2000): Software Patterns. Auf Internet abrufbar:

http://citeseer.nj.nec.com/498638.html (14.08.2002).

Duden: Das Fremdwörterbuch (1990). Duden Verlag, Mannheim.

55

Fowler, M. (1997): Analysis patterns: reusable object models. Addison-Wesley, Menlo Park, Kalifornien.

Fiutem, R., Antoniol, G., Tonella P., Merlo, E. (1999): ART: An Architectural Reverse Engineering Environment. Auf Internet abrufbar:

http://citeseer.nj.nec.com/456930.html (Stand 22.08.02).

Gabriel, R. (2001): A Pattern Definition. Oktober 2001. Auf Internet abrufbar:

http://www.hillside.net/patterns/definition.html (23.07.2002).

Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995): Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, Massachusetts.

Garlan, D. (2000): Software Architecture: a Roadmap. In: Proceedings ot the conference on the future of Software Engineering, Limerick, Ireland. ACM Press, New York, S. 91-101.

Garlan, D. & Monroe, R. (1996): Style-Based Reuse for Software Architectures. In:

Proceedings of the 1996 International Conference on Software Reuse. IEEE Computer Society Press, Los Alamitos, Kalifornien, S. 84-93.

Garlan, D. & Shaw, M. (1994): An Introduction to Software Architecture. School of Computer Science, Carnegie Mellon University, Pittsburgh, Pennsylvannia.

Garlan, D. & Shaw, M. (1996): Software architecture: perspectives on an emerging discipline. Prentice Hall, Upper Saddle River, New Jersey.

Gomez, P. & Probst, G. (1995): Die Praxis des ganzheitlichen Problemlösens. Vernetzt denken, unternehmerisch handeln, persönlich überzeugen. Paul Haupt, Bern.

Gomaa, H. & Menascé, D. (2000): Design and Performance Modelling of Component Interconnection Patterns for Distributed Software Architectures. In: Proceedings of the second international workshop on Software and performance, Ottawa, Ontario, Kanada. ACM Press, New York, S. 117-126.

Hammer, M. & Champy J. (1993): Reengineering the Corporation. A Manifesto for Business Revolution. Harper Collins, New York.

Hasselbring, W. (2000): Information System Integration. Communications of the ACM, 43. Jg., Ausgabe 6, S. 32-38.

Hay, D. (1996): Data Model Patterns: Conventions of Thought. Dorset House, New York.

56

Johannesson, P. & Perjons, E. (2001): Design principles for process modelling in enterprise application integration. Information Systems, 26. Jg., Ausgabe 3, S. 165-

184.

King, W. (1994): Creating a client/server strategy. Information Systems Management, 11. Jg., Ausgabe 3, S. 71-74.

King, W. & Sethi, V. (2001): Patterns in the organization of transnational information systems. Information & Management, 38. Jg., Ausgabe 4, Februar 2001, S. 201-

215.

Klose, M. (2002): Patterns für digitale Produkte im digitalen Wirtschaftsraum. Dissertation, Universität St. Gallen, Nr. 2628.

Kosanke, K., Vernadat, F. & Zelm, M. (1999): CIMOSA: enterprise engineering and integration. Computers in Industry. 40. Jg., Ausgabe 2-3, S. 83-97.

Kruchten, P. (1995): Architectural Blueprints-The 4+1 View Model of Software Architecture. IEEE Software. 12. Jg., 6. Ausgabe, S. 42-50.

Krueger, C. (1992): Software Reuse. ACM Computing Surveys. 24. Jg., Ausgabe 2, S. 131-183.

Leist, S. (2002): Bankenarchitektur des Informationszeitalers – Zielsetzung und Gestaltungsebenen. In: S. Leist & R. Winter (Hrsg.) Retail Banking im Informationszeitalter. Springer, Berlin, S. 3-28.

Lüscher, A. & Straubinger, A. (1996): Objektorientierte Technologien: Eine Einführung. vdf Hochschulverlag ETH, Zürich.

Linthicum, D. (2000): Enterprise Application Integration. Addison-Wesley, Boston.

Linthicum, D. (2001): B2B Application Integration: e-business enable your enterprise. Addison-Wesley, Boston.

Linthicum, David (2002): Data Level vs. Method Level: The Design Patterns for EAI. Auf Internet abrufbar: http://www.eaijournal.com/Article.asp?ArticleID=224.

Lutz, J. C. (2000): EAI Architecture Patterns. EAI Journal, März 2000, S. 64-73.

Mendonça, N. (2001): Architecture Recovery for Distributed Systems. Auf Internet abrufbar: http://www.cwi.nl/~arie/swarm2001/mendonca.pdf.

Meier, M. & Rechtin, E. (2002): The Art of Systems Architecting. (2. Aufl.) CRC Press, New York.

57

Mertens, P., Back, A., Becker, J., König, W., Krallmann, H., Rieger, B., Scheer, A.W., Seibt, D., Stahlknecht, P., Strunz, H., Thome, R. & Wedekind, H. (Hrsg.) (2001):

Lexikon der Wirtschaftsinformatik. (4. Aufl.) Springer, Berlin.

Mowbray, T. J. (1998): Will the Architecture please sit down? Component Strategies, 1998. Auf Internet abrufbar:

http://www.firstmark.ca/ContentDocs/architectural%20docs/

genral%20material%20on%20architectures/wtrapsd.html (Stand 16.07.02).

Mularz, D. (1995): Pattern-based Integration Architectures. In: Coplien, J. & Schmidt, D. (Eds.). Pattern languages of program design (S. 441-452). Addison-Wesley, Reading, Massachussets.

Ortiz, A., Lario, F. & Ros, L. (1999): Enterprise Integration – Business Process Integrated Management: a proposal for a methodology to develop Enterprise Integration Programs. Computers in Industry, 40. Jg., Ausgabe 2-3, S. 155-171.

Österle, H. (1995): Business Engineering: Prozess- und Systementwicklung. Band 1:

Entwurfstechniken. (2. Aufl.) Springer, Berlin.

Österle, H. (1996): Integration: Schlüssel zur Informationsgesellschaft. In: H. Österle, R. Riehm & P. Vogler (Hrsg.) Middleware – Grundlagen, Produkte und Anwendungs- beispiele für die Integration heterogener Welten. Vieweg, Braunschweig, S. 1-24.

Österle, H. & Blessing, D. (2000): Business Engineering Model. In: H. Österle & R. Winter (Hrsg.) Business Engineering. Auf dem Weg zum Unternehmen des Informationszeitalters. Springer, Berlin, S. 183-237.

Österle, H., Brenner, W. & Hilbers K. (1992): Unternehmensführung und Informations- system. Der Ansatz des St. Galler Informationssystem- Managements. (2. Aufl.) Teubner, Stuttgart.

Österle H. & Winter R. (2000): Business Engineering. In: H. Österle & R. Winter (Hrsg.) Business Engineering. Auf dem Weg zum Unternehmen des Informationszeitalters. Springer, Berlin, S. 4-20.

Österle, H., Fleisch, E. & Alt, R. (2002): Business Networking in der Praxis: Beispiele und Strategien zur Vernetzung mit Kunden und Lieferanten. Springer, Berlin.

Riehle, D. & Züllighoven, H. (1996): Understanding and Using Patterns in Software Development. Theory and Practice of Object Systems. 2. Jg., Ausgabe 1, S. 3-13.

Ruh, W., Maginnis, F. & Brown, W. (2001): Enterprise Application Integration. A Wiley Tech Brief. Wiley, New York.

58

Schmidt, D., Fayad, M. & Johnson, R. (1996): Software patterns. Communications of the ACM, 39. Jg., Ausgabe 10, S. 36-39.

Shaw, M. & Clements, P. (1997): A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems. In: Proceedings of the COMPSAC 1997, 21st International Computer Software and Applications Conference. IEEE Computer Society Press, Los Alamitos, Kalifornien.

Sinz, E. J. (1997): Wirtschaftsinformatik. In: G. Pomberger & P. Rechenberg (Hrsg.) Informatik-Handbuch. Carl Hanser, München.

Smolarova, M. & Navrat, P. (1999): Representing Design Patterns as Design Components. In: J. Eder, I. Rozman, T. Welzer (eds.) Advances in Databases and Information Systems, Third East European Conference, ADBIS'99, Maribor, Slovenia, September 13-16, 1999, Proceedings of Short Papers. Institute of Informatics, Maribor, Slovenia, S. 139-147.

Sprott, D. (2000): Componentizing the Enterprise Application Packages. Communications of the ACM, 43. Jg., Ausgabe 4, S. 63-69.

Themistocleous, M. & Irani, Z. (2001): Benchmarking the benefits and barriers of application integration. An International Journal, 8. Jg., Ausgabe 4, S. 317-331.

Themistocleous, M. & Irani, Z. (2002): Novel taxonomy for application integration. An International Journal, 9. Jg., Ausgabe 2, S. 154-165.

Veasy, P. W. (2001): Use of enterprise architectures in managing strategic change. Business Process Management Journal, 7. Jg, Ausgabe 5, S. 420-436.

Welter, H. (1993): Heterogene Netze – Einführung in Standardarchitekturen, Protokolle, Verwaltung und Sicherheit. Addison-Wesley, Bonn.

Winter, R. & Baumöl, U. (2000): Qualifikation für die Veränderung. In: H. Österle & R. Winter (Hrsg.) Business Engineering. Auf dem Weg zum Unternehmen des Informationszeitalters. Springer, Berlin, S. 43-58

Winter, R. (2000): Zur Positionierung und Weiterentwicklung des Data Warehousing in der betrieblichen Applikationsarchitektur. In: R. Jung & R. Winter (Hrsg.) Data Warehousing Strategie: Erfahrungen, Methoden, Visionen. Springer, Berlin, S. 128-139.

Zachman, J., Inmon, W. & Geiger, J. (1997): Data Stores, Data Warehousing and the Zachman Framework. McGraw-Hill, New York.

Anhang

59

Anhang

Hier sind Beispielmuster von verschiedenen Autoren aufgeführt. Es fehlen im besonderen die Muster von Gamma et al. (1995) und Buschmann et al. (1996 und 2002), sowie Fowler (1997) weil sie sehr umfangreich sind. Da es sich bei den Büchern um Standardwerke handelt, sollten sie für Interessierte gut zu beschaffen sein.

Aufgrund der ausführlichen Beschreibungen mit vielen Illustrationen war es leider nicht möglich ein Integrationsmodell von Brown (2000) in den Anhang aufzunehmen. Die Muster von Hay (1996), King und Sethi (2001), Linthicum (2002) und Lutz (2002) sind nicht aufgeführt, weil die Autoren kein Musterformat zur Beschreibung gebrauchen.

Appleton

Muster aus Appleton (1997, S. 5f.):

Local Heroes

Context

You must assemble the process improvement team (also known as the PIT -- see Process is Product). The pool of candidates from which to select team members contains people internal to the organization as well as those external to the organization (experienced consultants and prospective new-hires).

Problem

How do you staff the PIT with members who can effectively lead the practitioner community in accepting and adopting process changes?

Forces

Process experts are often perceived by practitioners as being steeped too much in theory and not enough in practice. It is desirable to have people who are not only knowledgeable about the software processes, but also about the reality that practitioners face in the trenches on a daily basis. Many competent practitioners may not have the requisite software process quality experience. Experts external to the organization may possess the requisite knowledge and experience, but may be viewed as outsiders by key practitioners (whose trust and respect are essential to gain inroads into the development community).

Solution

Compose the PIT primarily of venerated veteran practitioners throughout the development community. These people should be "all-stars in the family": respected members of the organization with proven track records as developers or managers (cf. Domain Expertise in Roles [Coplain]). Ideally, these talented individuals have leadership potential: when they talk, their peers tend to listen and are more likely to follow their example.

If possible, try to recruit members from as many project teams as possible so that each project has at least

one voice to represent its interests. However, don't sacrifice experience and respect at the expense of

equitable representation. When push comes to shove, it is more important to have people who are highly

regarded by their coworkers than to have at least one member from each project team. If you have to make

a compromise, go with the more influential individuals. This advice is borne out both by the author's personal experience as well as in published case studies of process improvement efforts.

Anhang

60

Sometimes project managers will resist having their best and brightest take time away from their project commitments in order to participate in improvement efforts. The manager will often try to send someone else instead (someone they feel is more "expendable" and who typically has much less influence in the development community). These less influential individuals may be highly competent, but they often do not yet command the degree of respect needed to sway their coworkers to give various improvement ideas a fair chance. Emphasize the importance of having the "local hero" be part of the PIT and try to hold out for the "real thing" if you can manage it (this is another one of those times when senior and middle management support may be needed).

Resulting Context

The PIT is both socially and technically aligned with the practitioner community. PIT members have intimate knowledge of development issues, and their deeds and words are respected within the development culture. These people are capable of leading the way because the practitioners know they have "been there, done that," and done it well.

It is assumed that a sufficient number of such people exist within the organization. If they do not, or if their numbers are scarce, then it may not be possible to use this pattern. Other patterns are needed to fill in this gap. One alternative would be to use as many insiders as possible and use external experts to fill the remaining slots.

Motivating individuals to participate in the PIT is not addressed by this pattern (Unity Of Purpose [Harrison] may prove useful here). Patterns for establishing suitable rewards and reinforcement to encourage such participation are also needed (see Compensate Success [Cope] for one example). Congruent action (see [Weinberg]) must somehow accompany the creation of such rewards to ensure that practitioner's commitments are adjusted to allow appropriate time and training to participate in improvement efforts. This requires committed support throughout the management hierarchy to enlist the cooperation of product-line managers and middle-managers to lighten workloads. Gaining such cooperation from management is another issue not directly addressed here (other patterns are needed for this as well).

Related Patterns

This pattern shares many elements with Domain Expertise in Roles [Coplien], Case Team [Beedle], as well as Grass Roots and Local Leader [Delano, Rising].

Size the Project [Coplien] may help to determine how many people should serve on the PIT. Center PEG describes how to "Scope the PIT" for SPI initiatives that encompass a very large group of people.

PIT also Practices and Dedicated Improvement Processors discuss how much time should be devoted by members of the PIT to SPI efforts.

Known Uses

[Curtis] cites SPI case studies which demonstrate the importance of staffing SPI initiatives with respected leaders (developers and managers) who are among the best and brightest in the organization (as opposed to using merely competent people with less influence in the community). [Donaldsen, Siegel] support these findings, as do [Fowler, Rifkin]. [Wakulczyk] describes how having an SEPG filled with peers greatly facilitated their ability to gain trust from, and stay attuned with, the developers at NORAD.

Wichtigste verwendete Abkürzungen:

SPI Software Process Improvement

PIT Process Improvement Team - other acronyms used are PWG (Process Working Group), and sometimes even SEPG (Software Engineering Process Group), though this latter acronym is more often used in place of PEG (see below).

Anhang

61

PEG Process Engineering Group -- the SEI Software CMM uses the acronym SEPG (Software Engineering Process Group)

Anhang

62

Beedle

Muster aus Beedle (1997b, S. 5) Leader

Context

(From Chaos- the pattern of disorder) An organization needs to make decisions at the business strategy level to adapt and survive within a constantly changing business environment.

Problem

Who should be the major sponsor and supporter of the reengineering effort? Who should make financial decisions that involve the major business functions of the organization? Who should communicate to the whole company what reengineering means to them?

Forces

A central point for decision making, global communications, resolution of issues, and vision at the highest

level can be a bottleneck, but an incoherent direction can be disastrous.

Solution

A Leader needs to be carefully appointed (or emerges) in the organization to make these decisions. Good

candidates for the Leader role are for example the CEO, the President, the CIO, the COO, the Director or

VP of Strategy, Change Management or Operations.

The Leader provides many different things: on-going status of the organization, identification of problems (through a Case of Action), definition of a vision (through the Vision Statement), motivation, resolution of issues, communications, financial and moral support, a common purpose, and a common set of values and beliefs. He uses signals to communicate to the organization, symbols to show proof for his communications and systems to reinforce his messages. The Leader appoints the Business Architect and the Process Owners of the organization.

Related Patterns

Patron from [Coplien95].

Resulting Context

(To Core Processes, Business Architect) To make decisions at the business strategy level the fundamental business architecture of the organization must be determined.

Example

The Taco Bell subsidiary of PepsiCo was sick and getting sicker when John E. Martin was named CEO in 1983. Martin’s problem was not convincing PepsiCo that the company had to reinvent itself, but that it had to reinvent itself in radical ways in a short period of time.

Charles Lee from GTE is probably the best example of a reengineering leader.

Known Uses

Robert L. Stark from Hallmark. Norm Phelps from Capital Holding Corporation (DRG).

Anhang

63

Coplien

Muster aus Coplien (1995, S. 202f.):

Patron

Problem

How do you give a project continuity?

Context

You are working with a development organization where roles are being defined. Patron works only if Pattern 11, Developer Controls Process, is in place.

Forces

Centralized control can be a drag; anarchy can be a worse drag. Most societies need a king/parent figure. An organization needs a single, ultimate decision maker. The time needed to make a decision should be less than the time it takes to implement it.

Solution

Give the project access to a visible, high-level manager who champions the project cause. The patron can be the final arbiter for project decisions; this provides a driving force for the organization to make decisions quickly. The patron is accountable for removing project-level barriers that hinder progress, and is responsible for the organization’s morale (sense of well-being).

Resulting Context

Having a patron gives the organization a sense of well-being and focus for later process and organizational changes. Other roles can be defined in terms of the patron’s role.

The Manager role is not meant to maintain totally centralized control, but rather to act as champion. That is, the scope of the manager’s influence is largely outside those developing the product itself, but it includes those whose cooperation is necessary for the success of the product (support organizations, funders, test organizations, and so on). This role also serves as a patron or sponsor; the person is often a corporate visionary.

Rationale

We have observed this pattern at work in QPW, in managers for C++ efforts at AT&T, for a manager in a high-productivity Network Systems project; and in another multilocation AT&T project.

This pattern relates to Pattern 24, Fire Walls, which in turn relates to Pattern 25, Gatekeeper.

Block (1983) talks about the importance of influencing forces over which the project has no direct control.

Putting the developer in charge of the process implies that management tiles become associated with support roles (see Pattern 24, Fire Walls). This works only in a culture where the manager decides to be the servant of the developer (an insight from Norm Kerth).

Anhang

64

Dikel et. al.

Muster aus Dikel et al. (2000, S. 124ff.):

Outsource

Problem Statement

How do you adapt when new standards or technologies emerge that are needed by customers but are not part of your planned core capabilities?

Context

You are a business unit manager whose organization already has an architecture that has proven to be effective and adaptable. To remain competitive, you need to add a set of capabilities to your architecture that do no fit well with your organization’s current or planned core capabilities. Your organization is evaluating whether to build the component itself or acquire a component from a third party.

Forces

If the organization has a strong focus, it can really excel in its targeted areas. If the organization relies on others for key components, there is less control over these components than if they were supplied in house. If organizations trust each other they are more likely to have a successful outsourcing relationship than if there is not trust between them. If there are other customers for a component, then it may be less expensive to have the component provided by a third party.

Solution

Select a third-party component, if such a component is available. If there is no such component, then the organization should seek a partner to develop and support the component. Determine whether the potential partner sees the component you need in their main line of business: for example, whether they can sell it to lots of other customers and assess the amount of unique development the partner will need to deliver and support the component. Assess the potential partner as a supplier and as a business partner, considering both capability and trustworthiness. As a rule of thumb, the more unique development they must do on behalf, the higher the level of trust that is required. Similarly, the lower the trust, the greater your schedule and financial risk. If you find a high level of trust in the potential supplier, outsource the component development.

Result

The component is the product of another supplier. Both organizations can focus on their core technology and expertise. The product can be delivered sooner than if you hired or developed the needed experience. Component users should experience higher quality and lower costs than if the components were built by a team to your organization.

Consequences

There is a tradeoff for outsourcing a component. The users of the component now have less control than if the component were maintained internally. In addition, both the component user and supplier need to devote resources to maintaining the relationship so that the component continues to meet the needs of the user. There is a risk that the component suppler could change business focus, dropt the product, or make a decision that breaks compatibility with your architecture. If you do not ha a solid architecture in the first place you may not be able to effectively incorporate a third-party component. Even if you do have a solid architecture, there may not be a good fit if there is a conflict of assumptions between the component and the architecture.

Anhang

65

Rationale

At the heart of this pattern is the notion that organizations should focus their efforts on their core competencies. When the idea of core competencies was introduced, it did not explicitly address software. Other authors have extended the idea to focus on how to select the software and processes in which to invest. There are never enough resources to implement all of the desired capabilities in the architecture. The architect’s organization has to choose the best places to invest development resources, but that might not be enough for architecture’s customers or their customers. To field a complete solution then, the architecture may need to incorporate components from external suppliers.

Example

Allaire had built a strong following for its ColdFusion Web development framework. However, in order to enter new markets, the architecture needed to be enhanced to support high-volume, fault-tolerant Web sites. Allaire decided to incorporate a third party’s load balancing software so that customers could deploy clusters of ColdFusion servers to support these demands. Allaire was able to incorporate the load balancing technology with higher quality and lower cost than if they had attempted to build it themselves. However, incorporating the component was not without its consequences. A feature for managing Web- client state that was introduced in a previous version of ColdFusion was incompatible with the load balancing software.

Beck und Johnson

Muster aus Beck und Johnson (1994, S. 10):

Wrapper

Preconditions

We have a set of classes that can be composed in different ways to make an application. We probably use Composite and Observer so that we can make many kinds of systems out of a fairly static set of parts.

Problem

We want to add a responsibility to an object, but we don't want to have to make a lot more classes or make it more complicated.

Constraints

Adding the responsibility in a subclass would ensure that the old class was not made more complicated. However, we might want to reuse that responsibility for another object. Multiple inheritance would let us statically assign it to another object, but multiple inheritance can lead to an explosion of classes, and many languages do not support it. Moreover, multiple inheritance does not support dynamically reassigning a responsibility to another object.

Solution

One way to add a responsibility to an object is with a wrapper. A T-wrapper "wraps" an instance of T and supports the T protocol by forwarding operations to the T, handling directly only those operations that relate to the responsibility it is designed to fulfill.

Anhang

66

Mularz

Muster aus Mularz (1995, S. 444f.):

(Legacy) Wrapper

Integration Intent

This pattern provides continued access to a legacy application while extending its capability and user base, eventually leading to its replacement.

Integration Context

A legacy application encapsulates an important functionality. While this functionality must continue to exist, a new functionality is required. In addition, users require access to this functionality from distributed, heterogeneous workstations that are separate from the legacy platform. In the short term, multiple users must be able to access the legacy application. In the long term, it will most likely be necessary to replace all or part of the legacy application while maintaining transparent access for the end user. Note: Although this pattern is explained in terms of legacy application, it can be applied to any application with a product-defined API.

Integration Conflict

The key forces at play here the need for continued access by an expanding user base to existing functionality while allowing for incremental replacement of the implementation in a manner that is transparent to the user.

Solution

Consider the legacy application to be an available service and the user application(s) to be clients of that service. Define a domain-specific interface, a framework that will serve as the basis for integrating the user application with the legacy system. Encapsulate the legacy application in a wrapper that exposes only the framework interface. To extend the functionality, place the new functionality into additional services that are accessed through the framework. Since this framework interface is not likely to match the existing legacy interface, create a mapping between the framework and the existing API. This mapping may require caching if multiple interfaces must be executed to provide a single response to the user. To achieve run-time implementation independence, provide a locator component (ideally on that is separated from the user application, to allow for independent growth of the user base).

Applicability

Use this pattern whenever an existing application can be considered a server for one or more users and has an established interface that can be masked by a front-end wrapper, and it is not currently desirable or feasible to rebuild the application.

Completing Patterns

To support a heterogeneous, distributed user base, consider the use of a broker. A broker should also be considered if the legacy application’s functionality is extended through the introduction of independent new services that may also be distributed.

Post-PloP’94 Note: The concept of a wrapper overlaps with the Facade and Adapter patterns described in

Gamma et al

perspective is probably warranted so that new patterns are not unnecessarily introduced.

In fact, an examination of the published design patterns from an integration pattern

Erklärung

67

Erklärung

Ich erkläre hiermit,

• dass ich die vorliegende Arbeit ohne fremde Hilfe und ohne die Benützung anderer als der angegebenen Hilfsmittel verfasst habe,

• dass ich ohne schriftliche Zustimmung des Rektors keine Kopien dieser Arbeit an Dritte aushändigen werde, ausgenommen nach Abschluss des Verfahrens an Studienkollegen und -kolleginnen oder an Personen, die mir wesentliche Informationen für die Diplomarbeit zur Verfügung gestellt haben.

Marco Fischbacher

Gossau, 23. August 2002

Viel mehr als nur Dokumente.

It Arch Pattern

Hochgeladen von

Dokumentinformationen

Datum des Uploads

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Verfügbare Formate

It Arch Pattern

Hochgeladen von

Beschreibung:

Copyright:

Verfügbare Formate

Verwandte Titel

Verwandte Interessen

Dokumente ähnlich wie It Arch Pattern

Beliebt in It/Computer Sciences

1	Einleitung	1
1.1	Problemstellung	1
1.2	Aufbau dieser Arbeit	2
1.3	Eingrenzung des Themas 3
1.4	Begriffsdefinitionen 4
	1.4.1 Architektur	4
	1.4.2 Informationssystem 4
	1.4.3 Prozess 4
	1.4.4 Applikation 5
	1.4.5 Software 5
2	Integration heterogener Applikationen	6
2.1	Einleitung	6
2.2	Ebenen des Business Engineering 6
2.3	Anwendungsintegration (EAI) 7
	2.3.1 homogene Applikationen	7
	2.3.2 heterogene Applikationen	8
2.4	Dimensionen der Integration	9
2.5	Zusammenfassung 11
3	IT-Architekturen	12
3.1	Was ist Architektur?	12
3.2	Architekturplanung	13
3.3	Architektur-Schulen 14
	3.3.1 Zachman Framework	14
	3.3.2 4+1 View Model 15
	3.3.3 Softwarearchitektur nach Carnegie Mellon 16
3.4	Was ist Software Engineering? 17
3.5	Architektur vs. Engineering 18
3.6	Zusammenfassung 18

4	Muster	19
4.1	Einleitung	19
4.2	Was sind Muster? 19
4.3	Muster und Mustersprachen nach Alexander	20
4.4	Geschichte der Muster im Software-Engineering	21
4.5	Framework	22
4.6	Dokumentation von Mustern 23
4.7	Zusammenfassung 27
5	Muster im Software Engineering	28
5.1	Einleitung	28
5.2	Analysemuster 28
5.3	Entwurfsmuster 29
	5.3.1 Gang of Four 29
	5.3.2 Gang of Five 30
	5.3.3 Riehle/Züllighoven 31
5.4	Anwendung der Entwurfsmuster	32
5.5	Organisations- und Prozessmuster (Coplien)	33
5.6	Muster zur Prozessverbesserung (Appleton)	34
6	Architekturmuster und andere Muster	35
6.1	Einleitung	35
6.2	Softwarearchitektur-Muster (Carnegie Mellon)	35
6.3	EAI Architekturmuster (Lutz)	36
6.4	Musterbasierte Integrationsarchitekturen (Mularz)	37
6.5	Daten- und methodenbasierte Muster (Linthicum)	37
6.6	Muster zur Umsetzung der Architektur (Dikel et al.)	38
6.7	Strategie-Muster (King)	39
6.8	Musterbasiertes Reengineering (Beedle)	40
6.9	Integrationsmodelle (Brown)	42
6.10	Datenmodellierungsmuster (Hay)	42
6.11	Unterstützungsmuster (Fowler)	43

7	Architekturgestaltung	45
7.1	Einleitung	45
7.2	Business Engineering	45
7.3	Software Engineering 45
7.4	Implementation einer EAI-Architektur	46
7.5	Mögliches Vorgehen bei der IT-Architekturgestaltung	47
7.6	Muster zur Unterstützung der Architekturgestaltung	49
8	Schlussbetrachtung	51
8.1	Zusammenfassung 51
8.2	Schlussfolgerungen	52
Literaturverzeichnis		53
	Anhang	59

Abbildung 1: Aufbau der Arbeit		2
Abbildung 2: Stufen der Integration nach Kosanke		3
Abbildung 3: Metamodell des Business Engineering bei Österle		6
Abbildung 4: Dimensionen der Integration nach Hasselbring		10
Abbildung 5: Begriffe der Softwarearchitektur bei Garlan		13
Abbildung	6: Zachman Framework	14
Abbildung 7: 4+1 View Model		16
Abbildung 8: Klassifikation von Softwarearchitektur-Muster		36
Abbildung 9: Databasierte vs. methodenbasierte Integration		38
Abbildung 10: Ausprägungen bei multinationalen Unternehmen		40
Abbildung 11: Objektorientiertes Zachman Framework nach Beedle		41
Abbildung 12: Beziehung des Business Engineering zum Software Engineering		47

ADL	Architecture Description Language
bzw.	beziehungsweise
CASE	Computer Aided Software Engineering
CORBA	Common Request Broker Architecture
EAI	Enterprise Application Integration, Anwendungsintegration oder Integration betrieblicher Anwendungssysteme
d.h.	das heisst
eds.	editors, Herausgeber
e.g.	example given (zum Beispiel)
et al.	et alii, und andere
f.	folgend
ff.	fortfolgend
GoF	„Gang of Four“, die vier Verfasser des Buches „Design Patterns: Elements of Reusable Object-Oriented Software“
GoV	„Gang of Five“, die fünf Verfasser des Buches „Pattern-oriented Software Architecture: A System of Patterns”
Hrsg.	Herausgeber
IS	Informationssystem
I-SPI	Initiating Software Process Improvement
IT	Information Technology, Informationstechnologie
ODBC	Open Database Connectivity
OMT	Object-Modelling-Technique
PLoP	Pattern Languages of Programs
RPC	Remote Procedure Call
S.	Seite
Übers.	Übersetzunng
UML	Unified Modeling Language
USA	United States of America, Vereinigte Staaten von Amerika
u.ä.	und ähnliches
vgl.	vergleiche
VRAPS	Vision, Rhythm, Anticipation, Partnering, Simplification
vs.	versus
z.B.	zum Beispiel

Zachman Architecture	What?	How?	Where?	Who?	When?	Why?
Framework	Data	Function	Network	People	Time	Motivation
Scope	List of Things important to the business	List of Process. the Business performs	List of Locations in which Busin. operates	List of Organiz. important to the Business	List of Events significant to the Business	List of Business Goals/Strategies
	e.g.	e.g. Business	e.g. Business	e.g. Work	e.g.	e.g.
Business Model	Semantic Model	Process Model	Logistics System	Flow Model	Master Schedule	Business Plan
	e.g. Logical	e.g. Application	e.g. Distributed	e.g. Human	e.g. Processing	e.g. Business
System Model	Data Model	Architecture	Systems Archit.	Interface Archit.	Structure	Rule Model
	e.g. Physical	e.g. System	e.g. Technology	e.g. Presentation	e.g. Control	e.g. Rule
Technology Model	Data Model	Design	Architecture	Architecture	Structure	Designl
	e.g.	e.g.	e.g. Network	e.g. Security	e.g. Timing	e.g. Rule
Detailed Reprasentation	Data Definition	Program	Architecture	Architecture	Definition	Specification

If	choose	Data Level	Method Level
need to access application logic			x
data is bound to a method (e.g. object-oriented)			x
data may be extracted from application without interfering with application integrity (Database)		x
data level interfaces exist (e.g. ODBC)		x
information (not data) can be extracted at an application level (e.g. API)			x
method level technologies exist (application server, distributed objects)			x
low latencies are important			x

Multinat. Corp. Type Dimension	Export	Parent-Child	Portfolio	Global Firm
Multinat. Corp. Type Dimension	orientation	configuration	Configuration	Global Firm
Value-Chain configuration	Low	High	Low	High
Value-Chain coordination	Low	Medium	High	High
Strategic Alliances	Low	Low	Medium	High
Centralization	High	Low	High	Low
Market integration	Low	Low	Medium	High

Object-oriented	Applicable
Zachman Framework	Pattern language	Tools in Focus	Risk Assessments	Techniques	Objects in Focus
		Financ. Forecasts
Scope	Pattern-based BRP	Cost/Benefits Analysis	Impact to whole organization	Process textual descriptions	Large Scale organization
		ABC Tools	Impact to specific process reengin. Projects	Business Use	Small Scale Org. Business Object Model Roles
Business or	Pattern-based	Process and		Cases
Enterprise Model	BRP	Project Tools		System Use
		CASE Tools		Cases
	Large Scale Arch. Pattern (Buschm. et al.)	CASE Tools
System Model		Process and	Impact to appl. Development	Class categories Use Case Maps	Applications
		Project Tools
		CASE Tools	Impact to overall System and Architecture applications		Business Object
Technology Model	Business Patt. Software Design Patt. (Gamma)	Compilers Debuggers CM tools		Design Heuristics	Models Design Object Model + mechanism
		CASE Tools	Impact to appl. development projects
Detailed Reprasentation	Idioms	Compilers		Edit, Compile,	Object Code i.e. C++, Java, Smalltalk
		Debuggers		Link, Test
		Testing tools