Diplomarbeit

IT-Architekturen zur Integration heterogener Applikationen im Unternehmen Verwendbarkeit von Mustern fr die IT-Architekturgestaltung

Referent:

Dr. Joachim Schelp

Verfasser: Marco Fischbacher

Abgabetermin: 23. August 2002

Universitt St. Gallen

Hochschule fr Wirtschafts-, Rechts- und Sozialwissenschaften (HSG)

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

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/Zllighoven.................................................................................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 Untersttzungsmuster (Fowler) .............................................................................43 6.12 Schichtenarchitekurmuster ....................................................................................44

III

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 Mgliches Vorgehen bei der IT-Architekturgestaltung ..........................................47 7.6 Muster zur Untersttzung 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: Ausprgungen bei multinationalen Unternehmen ....................................40 Abbildung 11: Objektorientiertes Zachman Framework nach Beedle .............................41 Abbildung 12: Beziehung des Business Engineering zum Software Engineering ............47

Abkrzungsverzeichnis
ADL bzw. CASE CORBA EAI d.h. eds. e.g. et al. f. ff. GoF Architecture Description Language beziehungsweise Computer Aided Software Engineering Common Request Broker Architecture Enterprise Application Integration, Anwendungsintegration oder Integration betrieblicher Anwendungssysteme das heisst editors, Herausgeber example given (zum Beispiel) et alii, und andere folgend fortfolgend Gang of Four, die vier Verfasser des Buches Design Patterns: Elements of Reusable Object-Oriented Software Gang of Five, die fnf Verfasser des Buches Pattern-oriented Software Architecture: A System of Patterns Herausgeber Informationssystem Initiating Software Process Improvement Information Technology, Informationstechnologie Open Database Connectivity Object-Modelling-Technique Pattern Languages of Programs Remote Procedure Call Seite bersetzunng Unified Modeling Language United States of America, Vereinigte Staaten von Amerika und hnliches vergleiche Vision, Rhythm, Anticipation, Partnering, Simplification versus zum Beispiel

GoV Hrsg. IS I-SPI IT ODBC OMT PLoP RPC S. bers. UML USA u.. vgl. VRAPS vs. z.B.

1 Einleitung
1.1 Problemstellung
Um den Wettbewerbsvorsprung zu wahren, haben Unternehmen heute eine Reihe von Herausforderungen zu meistern. Stndig steigender Komplexitt stehen immer krzere verfgbare Reaktionszeiten gegenber (Gomez & Probst 1995, S. 216). Um erfolgreich zu sein, mssen die Unternehmen jederzeit flexibel auf die Herausforderungen reagieren knnen. Kenntnisse der operativen und finanziellen Effektivitt 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 ermglicht neue Geschftslsungen. 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 untersttzt oder gar erst ermglicht 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. Informationssysteme sollen flexibel sein und sich ans Umfeld anpassen lassen. Kenntnisse der operativen und finanziellen Effektivitt lassen sich nur durch Zusammenfhren 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 Lsung zu ersetzen, so ist diese Vision heute verflogen. ERP-Systeme erfllen weder alle Geschftsanforderungen, noch alle ITAnforderungen. Unternehmungen geben daher ihre bestehenden Applikationen nicht auf, wenn sie ERP-Systeme einfhren (Themistocleous & Irani 2001, S. 321). Die Bedeutung der IT-Architekturplanung ist heute erkannt, da es nicht mehr mglich ist die Vielzahl der Systeme mit eins-zu-eins-Verbindungen zu integrieren oder gar abgetrennte 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 Geschftsanforderungen ausrichten. Prozessneugestaltungen, sogenannte Business Process (Re-)Engineering-Projekte (Hammer & Champy 1993), beeinflussen die Anforderungen an die InformationssystemArchitektur. Die vielfltigen Herausforderungen an eine IT-Architektur lassen die Frage aufkommen, inwiefern Konzepte einmal bewhrter Lsungen wiederverwendbar werden. Muster sind eine Mglichkeit dazu.

1.2 Aufbau dieser Arbeit

Die Themenstellung IT-Architekturen zur Integration heterogener Applikationen im Unternehmen Verwendbarkeit von Mustern fr die IT-Architekturgestaltung legt eine Gliederung an den Begriffen nahe. Dazu wird erst der Integrationsbegriff genauer beleuchtet. Es erfolgt dabei die Einschrnkung auf intra-organisationale Integration gemss der Themenstellung. Ausserdem wird erlutert, was unter Heterogenitt zu verstehen ist und warum es Heterogenitt in Informationssystemen gibt. Das folgende Kapitel befasst sich mit den Aufgaben der IT-Architektur und grenzt diese vom Software-Engineering ab. Das Software Engineering verfgt auf der technischen Ebene der Integration bereits ber viele Muster. Die entstandene Community hat die Idee von Mustern zur Wiederverwendung von bewhrten Lsungen vorangetrieben. Im dritten Kapitel wird in die Theorie von Mustern eingefhrt.
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 Musteranstze vorgestellt, die fr die ganzheitliche IT-Architekturgestaltung von Bedeutung sein knnen. Dabei handelt es sich um Anstze der organisatorischen Gestaltung und Prozessumgestaltung, zur Strategiebestimmung, um Integrationsmuster und Muster zur Datenmodellierung. Das Ziel dieser Arbeit, die Verwendbarkeit von Mustern zur IT-Architekturgestaltung zu prfen, wird dann im siebten Kapitel vorgenommen. In Anlehnung an ein Vorgehensmodell zur IT-Architekturplanung werden die Muster den Phasen zugeordnet.

1.3 Eingrenzung des Themas

Auf die Thematik der Integration und der IT-Architekturgestaltung gibt es grundstzlich zwei Blickwinkel, die Technologiesicht und die Geschftssicht. Whrend erstere insbesondere von der klassischen Informatik bearbeitet wird, befasst sich mit letzterer die Betriebswirtschaft in den Bereichen Organisation und Wirtschaftsinformatik. In der vorliegenden Arbeit wird Literatur aus beiden Gebieten bearbeitet. Verschiedene Autoren1 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 Anstze von Mustern zusammengetragen, die fr 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 maschinenverstndliche Beschreibung der Semantik von Daten zu entwickeln2.
Abbildung 2: Stufen der Integration nach Kosanke

integration

ration Enterprise Integ Business Integrat ion

ration Application Integ

Physical Integration

evolution
Quelle: Kosanke 1997, S. 64

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 spter 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).

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 Unternehmensmodellierung befasst. Dabei stehen meist produzierende Unternehmen im Vordergrund. Nach Ortiz et al. (1999, S. 156) besteht Unternehmensintegration darin Material-, Informations-, Entscheidungs- und Kontrollflsse 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 gemss 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 fr die verschiedensten Konzepte aus der Informationstechnologie wie Unternehmensarchitektur, Informationssystemarchitektur, Softwarearchitektur und Applikationsarchitektur verwendet. Eine genaue Abgrenzung der Begriffe folgt spter. Falls mit Architektur die Baukunst gemeint ist, werden die Worte Bau-Architektur oder Baukunst verwendet.

1.4.2 Informationssystem
Informationssystem steht hufig als Kurzwort fr Informations- und Kommunikationssysteme. Ein Informationssystem untersttzt 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 Untersttzung der Organisationsgestaltung. Sinz (1997, S. 861) dagegen versteht unter dem Begriff des Informationssystems ebenfalls den personellen Aufgabentrger 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 knnen. Nach sterle ist ein Prozess durch IT-Anwendungen untersttzt und produziert oder konsumiert Leistungen (sterle 1995, S. 19). Das Ergebnis eines Prozesses sind Leistungen, die in in- oder externe andere Prozesse einfliessen.

1.4.4 Applikation
Eine Applikation wird im Kontext der Geschftsapplikationen als Softwareelement definiert, das eine Reihe von eng verwandten Geschftsfunktionen zur Verfgung stellt (Cummins 2002, S. 53). Eine Geschftsapplikation ist blicherweise ein System, das ziemlich unabhngig arbeitet und die von einer Gruppe in einer Unternehmung bentigte Funktionalitt zur Verfgung stellt. Die Applikation ist meist verbunden mit einer Datenbank und einer Benutzungsoberflche. Buschmann et al. definieren eine Applikation als ein Programm oder eine Sammlung von Programmen, die eine Kundenanforderung erfllen (1996, S. 433). Applikationen knnen dabei zugekaufte Standardsoftware oder Eigenentwicklungen sein (sterle et. al 1992, S. 373).

1.4.5 Software
Software vom Englischen weiche Ware wird gemss Fremdwrter-Duden (1990) definiert als die zum Betrieb einer Datenverarbeitungsanlage erforderlichen nichtapparativen Funktionsbestandteile (Einsatzanweisungen, Programme u..). Besser erscheint mir die Definition von Balzert (2001, S. 45). Er definiert Software, als Programme, zugehrige Daten und notwendige Dokumentationen, die es zusammengefasst erlauben, mit Hilfe eines Computers Aufgaben zu erledigen.

2 Integration heterogener Applikationen

2.1 Einleitung
Nachdem das Thema gegenber 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 Heterogenitt zu erlutern. Zuerst wird das Business Engineering Modell von sterle kurz umrissen.

2.2 Ebenen des Business Engineering

Whrend die Geschftsanforderungen einerseits die Integration von Applikationen erfordern, ermglicht die Integration andererseits wieder neue Geschftslsungen. Damit das Informationssystem im Einklang mit der Geschftsstrategie 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 Geschftsfelder, sowie die Marktleistung des Unternehmens. Auf der Prozessebene werden die Prozessleistung, die Prozessablufe, sowie die Aufgaben als Bestandteile der Prozesse festgelegt.
Abbildung 3: Metamodell des Business Engineering bei sterle

Market Strategy

Strategic business unit

Market output

Activity Process

Process

Output

Function

Application

Data collection

IT components System
Quelle: sterle & Blessing 2000, S. 77

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

Johannesson und Perjons (2001, S. 166) sehen die Daten als weitere Ebene. Anwendungsintegration 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 Anwendungsintegration ist. Enterprise Application Integration (EAI), auf deutsch Integration betrieblicher Anwendungssysteme oder Anwendungsintegration, wird auch als Enterprise Integration, Systems Integration (Hasselbring 2000), Value Chain Integration, Supply Chain Integration, Extended 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, whrend 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 Fhigkeit einer Applikation jederzeit mit anderer Standard-, Individual- oder bestehender Software zu interagieren. Die Integrationsfhigkeit einer Applikation wird bestimmt durch die Mglichkeiten der Integration und den dafr ntigen Integrationsaufwand. Linthicum definiert Integration als uneingeschrnktes Teilen von Informationen zwischen zwei oder mehreren Unternehmensapplikationen (2000, S. 354). Eine Reihe von Technologien erlaubt den Austausch von Informationen zwischen verschiedenen Geschftsapplikationen und Geschftsprozessen innerhalb von Organisationen oder zwischen Organisationen. Im Vordergrund dieser Arbeit steht nur die Integration der Informationssysteme 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 Integrationsproblematik ist dabei unterschiedlich.

2.3.1 homogene Applikationen

Homogene Applikationen knnen 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 Applikationen mit mehreren Instanzen. Homogene Applikationen mit mehreren Instanzen, sind mehrere gleiche Applikationen auf verschiedenen Rechnern. Sie haben dabei definitionsgemss gleiche Datenstrukturen. Damit existieren keine semantischen Unterschiede. Zur Lsung der Integration stellt der

Softwarehersteller meist spezielle Mechanismen zum Abgleich zur Verfgung (Replikationsmechanismen). Dieses Problem kann daher meist einfach gelst werden. Schwieriger und hufiger stellt sich in der Realitt das Problem der Integration heterogener Applikationen.

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 Heterogenitt: Auf der technischen Ebene: unterschiedliche Hardwareplattformen, Betriebssysteme, Datenbankmanagementsysteme und Programmiersprachen. Auf der konzeptuellen Ebene: verschiedene Programmier- und Datenmodelle, unterschiedliches Verstndnis und unterschiedliche Modellierung eines Sachverhaltes.

Als Beispiel fr Heterogenitt auf der konzeptionellen Ebene nennt Hasselbring (2000, S. 36f.) den unterschiedlichen Gebrauch von Begriffen zur Bezeichnung des selben Konzepts (Synonym) oder Gebrauch eines Begriffes fr unterschiedliche Konzepte (Homonym). Whrend sich die Anwendungsintegration (EAI) auch mit Unterschieden auf der semantischen Ebene befasst, dient Middleware dazu die technische Integration und Syntax zu lsen. Die Abgrenzung zwischen Middleware und Anwendungsintegration ist allerdings fliessend und nicht immer eindeutig. Nach sterle (1996, S. 12ff.) bestehen heterogene Systeme aus verschiedenen Applikationen mit verschiedenen Datenstzen, die von unterschiedlichen Prozessen genutzt werden. Beispiele fr heterogene Systeme sind die Kombination von Modulen verschiedener Softwarepakete wie es bei ERP-Systemen in Unternehmen vorkommt. Die Grnde fr Heterogenitt sind zahlreich. Auf der Unternehmensebene geschehen Unternehmensfusionen oder -erwerb, wobei Applikationen der beteiligten Unternehmen anschliessend nicht homogenisiert werden (z.B. aus Zeitgrnden). Unternehmensintern finden Neuaufteilungen der Geschftseinheiten statt oder die Ausrichtung auf den Kunden statt Produktorientierung. Auf der technischen Ebene kann der Wunsch bestehen, dass aus Grnden des Investitionsschutzes 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 Erfahrung meist fehlen, wird die Anpassung oder Erweiterung der Systeme erschwert. Nicht umsonst werden die bestehenden autonomen Systeme im Englischen als Legacy Systeme (wrtlich: Erblast-Systeme) bezeichnet. Themistocleous und Irani haben aus der Literatur

folgende Grnde zusammengetragen, warum Legacy Systeme dennoch in Gebrauch sind (2001, S. 319): keine Zeit um sie zu ersetzen, Ersatz wre mit grossen Risiken verbunden, Mangel an IT-Fachkrften mit entsprechenden Kenntnissen, Ersatz der Systeme wre zu teuer, es wrde zu lange dauern, bis der Nutzen eines Ersatzes realisiert werden knnte1.

Es gibt aber noch weitere Grnde fr technische Heterogenitt. Manchmal bestehen Spezialapplikationen, die neben bestehenden Informationssystemen auf spezieller Hardware oder Betriebssystem laufen. Die Aufteilung von Datenbestnden aus Sicherheitsgrnden oder bessere Performance durch Aufteilung der Verarbeitung auf verschiedene Systeme sind weitere technische Grnde (sterle 1996, S. 5).

2.4 Dimensionen der Integration

Heterogenitt ist nach Hasselbring (2000, S. 36f.) nur eine der Dimensionen der Anwendungsintegration. Im weiteren gibt es das Problem der Autonomie und der Distribution. Zur Beseitigung der Autonomie sind organisatorische Anpassungen ntig, da es um Aspekte der Zusammenlegung von Abteilungen und Neuordnung von Prozessen geht, im Modell von sterle also die Prozessebene. Die technischen Mglichkeiten die Autonomie der Systeme zu beseitigen sind beschrnkt. 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 Unternehmen2. Die Geschftsprozesse zwischen den verschiedenen Ablegern sollen entsprechend eng abgestimmt sein. Die unterschiedlichen IT-Infrastrukturen und verschiedene Arten die Geschftsprozesse zu organisieren, fhrte zu einer Reihe von Problemen, insbesondere zu grosser Kundenunzufriedenheit. Erst der Beschluss der Geschftsleitung Prozesse neu zu gestalten und die Autonomie der einzelnen Einheiten zu Gunsten einer zentralen ITInfrastruktur aufzugeben, fhrte zu verbesserter Kundenzufriedenheit, Kostenersparnissen
1

Ruh et al. (2001, S. 133) nennen ebenfalls das hohe Risiko der Ablsung 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 selbstndiger Unternehmen, die sich fr einen bestimmten Zeitraum zusammenschliessen, wobei jedes seine Kernkompetenz einbringt und gegenber Dritten als einheitliches Unternehmen aufgetreten wird (sterle et al. 2002, S. 415). Der Begriff wird in der Literatur auch verwendet fr Unternehmen, welche die ursprnglichen operativen Grenzen verlassen und engere Partnerschaften zu Geschftspartnern 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 erhhter Flexibilitt. Diese Vernderung geschah nicht ohne Widerwillen der Mitarbeitenden, die sich dadurch in ihrer Macht beschnitten fhlten.
Abbildung 4: Dimensionen der Integration nach Hasselbring

proxy services

distribution

common models, structures, standards; wrappers

a on a ti niz ga or y m no to au

s ge an ch l

heterogenity

Quelle: Hasselbring 2000, S. 36

Die Distribution von Systemen lsst sich technisch lsen. Dazu existieren Mglichkeiten wie Methodenfernaufrufe (Remote Procedure Calls, kurz: RPC) oder Proxy Services, wo einem Informationssystem die lokale Verfgbarkeit des anderen Systems durch einen Stellvertreter simuliert wird. Heute gelufig sind sogenannte verteilte Objekte ber Technologien wie CORBA. sterle (1996, S. 14f.) verweist aber auf die Problematik von Verzgerungen, wenn asynchrone Techniken angewendet werden. So knnen Verzgerungen im Datenaustausch eine Unterbrechung des Geschftsprozesses zur Folge haben. Als dritte Dimension besteht die bereits erwhnte Heterogenitt. Auf der technischen Ebene knnen dabei schnittstellenorientierte Lsungen wie Adapter oder Wrapper ber eine standardisierte Schnittstelle bestehende Systeme integrieren. Eine weitere Mglichkeit ist datenbankorientierte Middleware wie ODBC1. Auf der konzeptuellen Ebene sind mgliche Abhilfen Datenmodelle und festgelegte Strukturierung der Information ber Methoden des Datenaustausches (Hasselbring 2000, S. 37). Transaktionsorientierte Technologien wie Applikationsserver untersttzen eine Transaktionssemantik. Wie Sprott (2000, S. 66) schreibt, haben viele Implementationsprojekte in den spten neunziger Jahren Zeit- und Kostenbudgets massiv berschritten.
1

ODBC: Open Database Connectivity; ein Quasistandard, der dafr sorgt, dass unterschiedliche Datenbanken von einem Client angesprochen werden knnen (Mertens et al.2001, S. 304)

11

Das war blicherweise nicht ein technisches Problem, sondern auf Unterschiede in Semantik und Geschftsregeln der unterschiedlichen Applikationen, die nie zur Zusammenarbeit ausgelegt wurden, zurckzufhren. Nichtsdestotrotz bringt Anwendungsintegration klaren Nutzen. Cook nennt die Verbesserung von Geschftsprozessen, die Komplexittsreduktion von Informationssystemen und die Mglichkeit unternehmensweit Prozesse durch gemeinsamen Datenzugriff zu integrieren (1996, S. 56). Nach Ruh et al. (2001, S. 1ff.) ermglicht Anwendungsintegration neue Lsungen, welche die Wettbewerbsfhigkeit steigern. Die Kundenbeziehung und Beziehungen in der Supply Chain werden verbessert. Ausserdem werden interne Prozesse rationalisiert und krzere Vorlaufzeiten am Markt geschaffen. Zudem erhht Anwendungsintegration den Nutzen von bestehenden autonomen Systemen und von eingefhrter Standardsoftware. Doch Anwendungsintegration ist eine aussichtslose Kunst, wie Linthicum schreibt (2000, S. 347). Denn viele der Probleme in der Anwendungsintegration htten 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 Applikationen wird als Anwendungsintegration (Enterprise Application Integration) bezeichnet. Anwendungsintegration ist hier die Fhigkeit von Applikationen mit anderer Software im Unternehmen zu interagieren. Dazu muss das Problem der Heterogenitt, der Distribution und der Autonomie gelst werden. Heterogenitt bezeichnet dabei verschiedenartige Standards auf der technischen Ebene (Hardwareplattformen, Betriebssysteme, Programmiersprachen), sowie auf der konzeptuellen Ebene (unterschiedliche Programmiermodelle, Modellierungen eines Sachverhalts). Das Problem der Distribution ist durch technische Massnahmen zu lsen. Das Problem der Autonomie durch organisatorische Anpassungen. Es gibt daher immer zwei Blickwinkel, die Geschftssicht und die technische Sicht.

12

3 IT-Architekturen
3.1 Was ist Architektur?
Die Grundlage zur Integration heterogener Applikationen bildet eine entsprechende Architektur. Da der Begriff Architektur in der Literatur uneinheitlich verwendet wird, soll er im folgenden genauer erlutert werden. Hufig 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, hufig als Enterprise Architecture oder Unternehmensarchitektur benannt. Unternehmensarchitektur soll hier als umfassender Begriff fr die Unternehmensstrategie oder Geschftsebene1, die Prozessebene und das Informationssystem verstanden werden. Leist schreibt dazu (2002, S. 3), die Unternehmensarchitektur umfasse die drei Gestaltungsebenen Geschfts-, 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 Geschftsfunktionen, 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 Softwarearchitektur 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 Softwarearchitektur2. 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 Konfiguration bezeichnet (Garlan & Monroe 1996, S. 3). Mularz (1995, S. 442) benutzt fr die

In der Strategieforschung wird, beeinflusst durch die verbreitete Anwendung des Architekturbegriffs auf Informationssysteme, der Begriff Enterprise Architecture immer strker verwendet (vgl. Veasey 2001). Manchmal wird der Begriff Softwarearchitektur als berbegriff fr smtliche 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. Dafr 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 Implementation. Garlan (2000, S. 2) spricht von der Brckenfunktion der Architektur zwischen Anforderungen 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 dafr den Begriff des Architecting, whrend Architecture den Zustand bezeichnet (Meier & Rechtin 2002, Vorwort VI). Zusammenfassend soll unter Architektur der Zustand, sowie der Entwicklungsprozess verstanden werden. Die Informationssystemarchitektur ist die Grobstruktur der Organisation, der Geschftsfunktionen, der Daten, der Applikationen und der Datenbanken. Leist (2002, S.19ff.) verwendet die Begriffe von Zustands- und Vorgehensmodellen. Zustandsmodelle bilden Struktur und Verhalten eines Unternehmens zu einem bestimmten Zeitpunkt ab. Vorgehensmodelle geben dagegen Massnahmen und Aktivitten wieder, die Zustandsmodelle von einem Ist- zu einem Soll-Zustand berfhren (Zeitraumbezug).

3.2 Architekturplanung
sterle schreibt (1995, S. 128): Die Architekturplanung ist Bestandteil der Strategieentwicklung. Sie nimmt Geschftsfelder, Produktsortiment usw. als Ausgangspunkt, leitet daraus die Prozesse ab und beeinflusst ihrerseits die Geschftsfelder, das Produktsortiment usw.. Umgekehrt beeinflusst die Wahl eines Client-Server-Computersystems die Produktivitt einer Firma, das Humankapital und den Wettbewerbsvorteil (King 1994, S. 71ff.). sterle et al. sehen die Architektur als Bebauungsplan fr 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 Bauml (2000, S. 46) nennen verschiedene Rollen fr einen Business Engineer, u. a. der Architekt. Als Architekt bernimmt man die Gestaltung des Vernderungsprozesses aus einer ganzheitlichen Sicht. Das bedeutet Ziele zu setzen, Vorgaben zur Zielerreichung zu machen, die Ressourcen zu planen, Ergebnisse zu berprfen und an die Geschftsleitung zu berichten, sowie den Prozess fhrend 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 hufig folgt vor Abschluss einer Reorganisation bereits die nchste 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 Framework

What? Data

How? Function

Where? Network

Who? People

When? Time

Why? 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

Business Model

e.g. Semantic Model

e.g. Business Process Model

e.g. Business Logistics System

e.g. Work Flow Model

e.g. Master Schedule

e.g. Business Plan

System Model

e.g. Logical Data Model

e.g. Application Architecture

e.g. Distributed Systems Archit.

e.g. Human Interface Archit.

e.g. Processing Structure

e.g. Business Rule Model

Technology Model

e.g. Physical Data Model

e.g. System Design

e.g. Technology Architecture

e.g. Presentation Architecture

e.g. Control Structure

e.g. Rule Designl

Detailed Reprasentation

e.g. Data Definition

e.g. Program

e.g. Network Architecture

e.g. Security Architecture

e.g. Timing Definition

e.g. Rule Specification

Quelle: www.zifa.com (17.08.02)

John Zachman entwickelte im Rahmen seiner Ttigkeit 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 mglichst vollstndiges Bild des Informationssystem entstehen. Zachman et al. verwenden die Metapher der an einem realen Hausbau beteiligten Personen (1997, S. 57ff.). Der visionre Planer soll die strategische Ausrichtung (Scope) festlegen. Vom Besitzer werden die Geschftsprozesse bestimmt. Der Designer setzt die Anforderungen in Produkt-

15

spezifikationen um, in der Informationstechnologie das sogenannte System-Modell. Der Erbauer ist fr 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 Plne 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, wrden sich auch die Zellen im Framework nach und nach fllen. 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. Whrend vertikale Anstze monolithische Systeme hervorbringen, erlaubt der horizontale Ansatz eine unternehmensbergreifende Architektur. Obwohl Zachman Punkte wie Strategie und Geschftsprozesse aufgreift, ist das Framework doch von einer technischen Sicht geprgt. So unterscheidet Brown (2000, S. 39) die technische Sicht von der Geschftssicht 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 verbreitet1. Da Softwarearchitektur hufig nicht alle Anforderungen der Kunden erfllt, 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 Anwendungsflle (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 Zhlsdorff in Mertens et al. im Lexikon der Wirtschaftsinformatik (2001, S. 43) zur Definition von Anwendungsarchitektur verwendet, leider ohne Hinweis auf die enge Verknpfung 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 bercksichtigt die Aufteilung von Prozessen ber das Netzwerk zwischen verschiedenen Computer, was die Performance, Fehlertoleranz, Integritt und Verfgbarkeit eines Systems beeinflusst.
Abbildung 7: 4+1 View Model
End-user Functionality System Engineers Topology Communications

Logical View

Development/Component View Use Case View

Process View

Physical/Deployment View
System Engineers Topology Communications

Integrators Performance Scalability

Quelle: in Anlehnung an Kruchen 1995, S. 43

3.3.3 Softwarearchitektur nach Carnegie Mellon

Die Scientific Community in den USA hat wichtige Publikationen verffentlicht, 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 fr Computerwissenschaften an der Carnegie Mellon University sowie das Buch Software Architecture in Practice (1998) von Bass, Clements und Kazman. Whrend bei anderen Autoren wie sterle et al. (1992) und Zachman et al. (1997) die Unternehmens- oder Informationssystemarchitektur ausgehend von den Geschftsbedrfnissen 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 fnfziger 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.)1. Denn einerseits werden die Systeme immer grsser und komplexer und andererseits nimmt
1

Ein gut verstndlicher berblick zur Evolution der Software-Entwicklung findet sich bei Lscher & Straubinger (1996, S. 5ff.).

17

der Aufwand fr die Programmierung durch Modularisierung und Programmbibliotheken immer weiter ab. Garlan und Shaw verweisen auch auf die mangelnde Untersttzung von Heterogenitt durch Programmiersprachen (1996, S. 158). Module, die in verschiedenen Programmiersprachen geschrieben sind, knnen nicht miteinander kombiniert werden bzw. nur ber spezielle, zwischen den Sprachen stehende Prozeduraufrufe. Module mssen daher hufig erst entkodiert werden. Ausserdem untersttzen heutige Programmiersprachen keine Abstraktion von Interaktion, so dass es unmglich sei Architekturparadigmen auszudrcken. Dementsprechend lautet die Anforderung an neue Architekturbeschreibungssprache (ADL) dies zu lsen1.

3.4 Was ist Software Engineering?

Wie oben festgestellt sind die Gebiete des Software Engineering und der Architektur, genauer der Softwarearchitektur, eng miteinander verknpft. Es stellt sich die Frage, wie Software-Engineering definiert wird. Garlan und Shaw (1996, S. 6) definieren Engineering als Erstellen von kosteneffektiven Lsungen 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 Ingenieurdisziplinen. Balzert definiert Software Engineering als zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen fr die arbeitsteilige, ingenieurmssige Herstellung und Anwendung von umfangreichen SoftwareSystemen (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 gehrt zum Software Engineering die Komposition von Software-Komponenten, der richtige Gebrauch und die Erweiterung von Middleware-Werkzeugen und methodologische Anstze 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 Popularitt (Garlan & Shaw 1996, S. 5). Das Software-Engineering hat also einen methodischen Softwareentwicklungsprozess zum Ziel. Dazu bedient es sich auch computergesttzter 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 Optimierungsprozess mit dem Ziel effektiver Lsungen. Im Mittelpunkt steht die Absicht die Projektanforderungen mglichst effektiv zu erfllen, den Programmcode zu optimieren und die Wiederverwendbarkeit von Programmcode zu frdern. 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 & Zllighoven 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 Vorschlge eine Lsung zu finden, wo alle Schnittstellen passen. Nach Meier und Rechtin (2002, Vorwort III) widmet sich Architektur der Lsung schlechtstrukturierter 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 Geschftsprozessentwurf-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 Applikationslandschaft bezeichnen. Der Begriff der Architektur hat die zwei Dimensionen Zustand und Vorgehen. Die Informationssystemarchitektur bezeichnet eine Grobstruktur der Organisation, der Geschftsfunktionen, Daten, Applikationen und Datenbanken. Eine Softwarearchitektur besteht aus Komponenten, die zusammen mit den verbindenden Konnektoren Applikationen bilden. Die Softwarearchitektur steht dabei dem Software-Engineering sehr nahe. Whrend das Engineering primr ein Optimierungsprozess ist, befasst sich Architektur mit dem Erstellen von Grobstrukturen. Nachdem nun feststeht, was Integration heterogener Applikationen ist und Anstze von IT-Architekturen vorgestellt wurden, wird als nchstes in die Theorie der Muster eingefhrt. Interessanterweise haben diese ihre Wurzeln in der Architektur des Stdtebaus.

19

4 Muster
4.1 Einleitung
Der Gebrauch von Mustern ist eine aktuelle Entwicklung im Software Engineering. Die Arbeiten des Architekten und Stdteplaners 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 bewhrt haben. Denn der kleine Leistungsgewinn, wenn man ein Produkt von Grund auf entwickeln wrde, ist den Aufwand nicht wert (Schmidt et al. 1996, S. 37). Muster sollen in hnlicher Weise erprobte Lsungen fr verbreitete Softwareprobleme liefern.

4.2 Was sind Muster?

Christopher Alexander schreibt ber Muster in der Baukunst: Jedes Muster beschreibt zunchst ein in unserer Umwelt immer wieder auftretendes Problem, beschreibt dann den Kern der Lsung dieses Problems, und zwar so, dass man diese Lsung millionenfach anwenden kann, ohne sich je zu wiederholen. (Alexander et al. 1995, Vorwort X). Riehle und Zllighoven definieren Muster in der Softwareentwicklung als die Abstraktion einer konkreten Form, die in einem anderen spezifischen Kontext wieder auftauchen kann1 (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 Lsung fr ein Problem. Die Beschreibung eines Muster sollte die wichtigsten Erkenntnisse enthalten, so dass andere in hnlichen Situationen daraus lernen knnen. Daher definiert Appleton ein Muster als ein Bndel an instruktiver Information, das den Kern einer erprobten Lsung fr ein immer wieder auftretendes Problem vermittelt2. Alexander benutzt fr Muster, in denen die Anwendung der Muster vermittelt wird, den Begriff generative patterns. Gemss Smolarova und Navrat (1999, S. 140) wre es vernnftig zwischen den Handlungsanweisungen zur Anwendung eines Musters, und dem eigentlichen Muster als Code in einem gut geschriebenen Programm zu unterscheiden. Sie schlagen fr letzteres den Begriff Pattern instance (Musterinstanz) vor. Da diese Begriffsbezeichnung derzeit nicht gebruchlich 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 & Zllighoven 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. Hufig 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 Musterdefinition von Christopher Alexander zurckgegriffen. Alexander war Professor in Bauarchitektur an der University of California in Berkeley. Die bekanntesten Bcher des Architekten und Stdteplaner sind A Pattern Language: Towns, Buildings, Construction (1977)1, eine Sammlung von Mustern der Baurchitektur, und The Timeless Way of Building (1979). Zur Beschreibung der Muster schlgt Alexander (1979, S. 247) eine Drei-Teile-Regel vor, die aus den Elementen Kontext, Problem und Lsung besteht. In Anlehnung an die DreiTeile-Regel von Alexander benutzt Gabriel (2001) die folgende Definiton fr SoftwareMuster: 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, Einschrnkungen (Constraints) und Lsung (Solution). Beedle (1997a, 1997b) unterteilt in Kontext (Context), Problem, Krfte (Forces) und Lsung (Solution). Im Buch Eine Muster-Sprache (1995) beschreibt Alexander unzhlige Muster der Baukunst in einer klar strukturierten Form. Eine Mustersprache soll nach Alexander (1979, S. 186) generativ sein. Generative Muster ermglichen 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 lsen, die den Umfang eines Musters bersteigen. Ein Katalog enthlt 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 gltige Stze zu bilden. Ausserdem setzt eine Mustersprache die verschiedenen Muster
1

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 vollstndig ist, aus den Mustern ein zusammenhngendes Ganzes (Alexander 1979 S. 305, 312, 316). Die Entwicklung von Mustersprachen ist das langfristige, aber schwierige Ziel. Mustersprachen haben das Ziel, alle Probleme in einem bestimmten Bereich durch Muster abzudecken. Alexanders Buch (1995) erfllt das etwa fr die Bau-Architektur. Im Bereich der Softwarearchitektur existiert z.B. CHECKS eine Mustersprache fr den Unterbereich der Informationsintegritt (Buschmann et al. 1996, S. 422). Um zu guten Mustern zu gelangen, schlgt Alexander (1979) drei Grundstze vor: die Qualitt (the quality without a name, auch QWAN), den Zugang (the gate) und den Weg (the timeless way). Qualitt bezeichnet die wesentlichen Grundzge, die in den Dingen stecken und sie fr uns lebendig wirken lassen, aber schwierig in Worte zu fassen sind (S. 19ff.). Alexander geht also davon aus, dass es ein objektives Mass fr sthetische Schnheit mit einem universellen Geltungsbereich gibt (Klose 2002, S. 111). Der Mechanismus, der uns erlaubt die Qualitt zu erreichen, wird als Zugang bezeichnet. So ermglicht eine Mustersprache neue Dinge aus bewhrten Grundstzen zu schaffen (Alexander 1979, S. 157ff.). Zwischen Qualitt 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 Schnheit ist aber kaum das Ziel in der Architektur eines Informationssystems oder einer Software. Da knnte man in Bezug auf die Softwarearchitektur eine wohlprogrammierte, aus Komponenten mit klaren Schnittstellen zusammengesetzte Software verstehen. In der Informationssystemarchitektur wren die Kriterien eher die Integriertheit eines Systems, die Erweiteungsfhigkeit 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 fnfziger 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 Benutzeroberflchen in Smalltalk und benutzten dabei Alexanders Ideen, um eine fnf Muster umfassende Mustersprache fr 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. Spter 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 fr die Softwareentwicklung. Obwohl darin Alexander zitiert wird, schreibt Fowler (1997, S. 6), dass drei aus der Gang of Four die Bcher von Alexander nicht kannten und die Bedeutung von Alexander berschtzt 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 fnf Autoren werden auch als Siemens Gang of Five (GoV) bezeichnet. Seit 1994 finden in der Software Engineering Community ausserdem jhrlich 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 Organisationsproblemstellungen immer weitere Verbreitung, so bei Coplien (1996) The human side of patterns. Der Nutzen von Mustern lsst sich bereits erahnen. Muster formalisieren Ideen zu generischen Schemen, die sich wiederverwenden lassen. Da es sich bei Mustern um erprobte Lsungen 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 Frderung 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 Softwarearchitektur eine andere Bedeutung. Das Software Framework ist eine mehr oder weniger abstrakte, mehr oder weniger vollstndige 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 fr eine Familie von Softwareabstraktionen 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 reprsentieren. Entsprechend gibt es Softwarearchitekturen, die nicht in ein Framework gefasst werden knnen. Fowler (1997, S. 11) formuliert als Anforderung an ein Framework, dass es weder zu komplex, noch zu schwerfllig sein darf. Es sollte auf den konzeptuellen Modellen eines Bereichs oder einer Branche basieren und in diesem Bereich breit anwendbar sein. Ein Framework fr Applikationen in einem bestimmten Bereich (z.B.

23

fr Finanzapplikationen) wird Applikationsframework genannt (Buschmann et al. 1996, S. 396). Die Idee der Frameworks ist, hchstmgliche Wiederverwendbarkeit zu erreichen. Whrend objektorientierte Programmierung die Wiederverwendbarkeit von Programmcode frdert, untersttzen Frameworks die branchenweite Wiederverwendbarkeit von Entwurfs- und Domnenwissen (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 fr die Softwarearchitektur daher von Bedeutung, weil sie die Details vor dem Entwickler verbergen und es ihm erlauben sich auf die Funktionalitt 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 Programmiersprache implementiert werden, whrend Muster unabhngig von Programmiersprachen verfasst sind (Schmidt et al. 1996, S. 39) und daher in jeder beliebigen Programmiersprache umgesetzt werden knnen. Das hat damit zu tun, dass Frameworks ausfhrbarer Code sind, whrend Muster nur Anweisungen enthalten, wie ausfhrbarer 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, bentigten Subroutinen. Im Gegensatz dazu, werden in Frameworks Funktionen aufgerufen (Appleton 2000, S. 14). Die Problematik an Frameworks liegt darin, dass die Kosten der Entwicklung fr viele Firmen zu hoch sind. Die Bindung an Programmiersprachen bedingt eine Eingrenzung auf wenige Technologien und Programmiersprachen. Angesichts der Heterogenitt von Applikationen ist dies in Unternehmen ein schwieriges Unterfangen.

4.6 Dokumentation von Mustern

Die Dokumentation von Mustern sollte sich an fnf Leitwerten orientieren (Schmidt et al. 1996, S. 38). Erprobtheit ist wichtiger als Neuheit: Je lnger ein Muster bereits gebraucht wird, desto wertvoller ist es. Schwerpunkt auf der Beschreibung und der Klarheit der Kommunikation: Muster sollten wie Katalogeintrge sein, sowohl in literarischem wie in technischem Stil. Qualitative Validierung des Wissens: Die Beschreibung einer Lsung soll qualitativ erfolgen. Quantitative Aspekte haben zwar ihre Berechtigung. Sie gehren aber nicht in die Beschreibung von Mustern.

24

Gute Muster entstehen aus Praxiserfahrung: Die Erfahrung aller wird geschtzt, da nicht nur einige wenige die Muster bereit haben, sondern die Muster sich in der Diskussion von Strken und Schwchen sowie dem Austausch von Erfahrung herauskristallisieren. Die Wichtigkeit der menschlichen Dimension in der Software Entwicklung sollte beachtet werden: Die Anwendung von Mustern soll nicht Kreativitt durch stures Anwenden von Regeln ersetzen.

Daneben gibt es weitere allgemein anerkannte Kriterien fr eine hohe Qualitt der Muster. Die Muster sollten einem Reviewprozess unterliegen und allenfalls gemss den Anmerkungen verbessert werden. Ein ffentlicher Review auf dem Internet ist erstrebenswert und Muster sollten populre Akzeptanz erlangen. Wobei unter Popularitt objektive Kriterien, wie Zirkulation der Publikation, gemeint sind. Auch sollten Muster in mehrere Bereiche gegliedert sein. Appleton (2000, S. 9ff.) schlgt ein Format vor, dem die Musterbeschreibungen entsprechen sollten. Er beachtet dabei die Vorschlge von Alexander, das Musterformat der Gang of Four und der Gang of Five. Folgende Elemente kommen in den Formaten der verschiedenen Autoren hufig vor: Name Eine kurze Bezeichnung zur Beschreibung eines Musters. Das kann ein kurzes Wort oder ein kurzer Satz sein. Dabei fllt es hufig 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, whrend 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 mssen erfllt sein, bevor ein Muster angewendet werden kann (Beck & Johnson 1994, S. 2) . Problem(-beschrieb) Das ist eine Beschriebung des Problems, welches durch das Muster gelst wird. Dieser Problembeschrieb ermglicht dem Leser die Abschtzung inwiefern das Problem fr ihn relevant ist. Dieser Teil kommt bei allen Autoren vor.

25

Kontext Der Kontext beschreibt die Bedingungen unter denen das Problem auftritt und eine Lsung wnschenswert wre. 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 erlutert genauer, was das Muster bezweckt (Gamma et al. 1995, S. 6, auch bei Mularz 1995, S. 441ff.). Zustzlich enthlt die Beschreibung von Gamma et al. auch ein Abschnitt Motivation (1995, S. 7). Darin wird in einem Szenario das Entwurfsproblem beschrieben. Das Ziel ist dabei, das Verstndnis der Klassen- und Objektstrukturen zu erleichtern. Widerstnde (forces oder constraints) Ein Problem tritt immer in einem Umfeld von zahlreichen Einflssen und Einschrnkungen auf, die aufeinander und auf das Problem einwirken. Durch diese Beschreibung wird Hilfestellung geleistet bei der Abwgung von verschiedenen Zielkonflikten, die in Betracht gezogen werden mssen (Appleton 2000, S. 10, auch bei Beedle 1997a, 1997b; bei Beck & Johnson 1994, constraints genannt). Lsung Dieser Abschnitt beschreibt die Lsung zum Problem. Manchmal visualisiert eine grafische Darstellung eine gefundene Lsung. Nach Appleton hat eine Lsung einerseits die statische Komponente der Struktur eines Musters, andererseits eine dynamische Komponente, welche die Interaktion eines Musters beschreibt (2000, S. 9ff.). Da die Lsung 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 knnten (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

Gedankengnge (rationale) Im Abschnitt Gedankengnge werden erluternde Erklrungen zu den Schritten eines Muster gegeben. Es wird ebenfalls beschrieben, wie mit den Widerstnden 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 Erfllung 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 zustzlich im Abschnitt Dynamics noch auf das Laufzeitverhalten eines Musters ein (1996, S. 20). Beispiele Zur besseren Illustration werden gerne Beispiele angefhrt. Dabei werden meist leichtverstndliche Lsungen bevorzugt (bei Appleton 2000, Beedle 1997a, 1997b, Dikel et al. 2001). Buschmann et al. fhren bereits Beispiele beim Problembeschrieb an und kommen spter im Punkt gelste Beispiele darauf zurck (1996, S. 21). Implementierung und Beispielcode Der Implementierungsabschnitt prsentiert die Fallen, Tipps oder Techniken, die man kennen sollte, um das Muster zu implementieren. Der Beispielcode erlutert wie Muster in einer ausgewhlten Programmiersprache implementiert werden knnen (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, erlutern die Autoren hufig 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 fr 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 ergnzenden Mustern (1995, S. 444). Bekannte Flle Beedle (1997a, 1997b) fhrt in den Beschreibungen noch Known Uses an. Das sind Firmen oder Personen, in welchen das Muster ausgeprgt 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 Lsungen 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 Lsung. 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 Lsungsanstze 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 ausfhrbarem Programmcode und unterscheiden sich dadurch von den Mustern. Denn Muster enthalten nur Anweisungen, wie Code zu gestalten ist. Ein Muster mit hoher Qualitt soll erprobt, klar beschrieben und aus der Praxis entstanden sein. Der Review in der Community trgt im weiteren zur hohen Qualitt von Mustern bei. Diese Kriterien sollen die bertragbarkeit der Muster auf neue Situationen und die Verstndlichkeit erleichtern. Sie frdern damit den Wissenstransfer von erfahrenen Entwicklern zu weniger erfahrenen Entwicklern.

28

5 Muster im Software Engineering

5.1 Einleitung
Grundstzlich 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 nchsten 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 Architekturmuster (architectural pattern) ebenfalls als Patterns for Software Architecture (Softwarearchitektur-Muster)1. Bei der Vorstellung der Muster verschiedener Autoren findet keine empirische quantitative oder qualitative Validierung der Muster statt. Dies htte umfangreiche Untersuchungen bedingt. Es werden aber nach Mglichkeit 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 fr einen Erfahrungshintergrund mitbringt. Falls besondere Definitionen vorkommen oder anderweitige Abgrenzungen, werden diese erlutert. Hufig wird auf die Strukturierung der Muster kurz eingegangen, da eine gute Struktur die Anwendung von Mustern erleichtert und damit deren Wert erhht. Wo vorhanden, wird eine Einschtzung durch andere Autoren wiedergegeben. Da die Musterbeschreibungen teilweise sehr ausfhrlich sind, ist es nicht mglich, 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 Geschftsprozessen. Er greift dabei zurck auf seine Erfahrungen in der Praxis als Berater in der Modellierung von Informationssystemen und hat die Muster stndig weiterentwickelt. Laut Fowler haben seine Modelle ebensoviel mit Business Engineering zu tun wie mit Software Engineering (1997, S. 10). Im zweiten krzeren Teil des Buchs stellt Fowler sogenannte Untersttzungsmuster vor, welche die Umsetzung der Analysemuster in die Architektur eines Informationssystems beschreiben. Dieser Teil wird erst im nchsten Kapitel erlutert.

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 Problemstellung ereignet (Fowler 1997, S. 1). Analysemuster befassen sich nicht mit der eigentlichen Softwareimplementation. Sie entwerfen konzeptionelle Strukturen von Geschftsprozessen. 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 Lsung. Die Lsung fr eine Problemstellung kann dabei aus mehreren unterschiedlichen Lsungsanstzen bestehen, die alle gewisse Vor- und Nachteile aufweisen. Fowler hat dabei darauf verzichtet, fr jeden Lsungsansatz ein eigenes Muster zu erstellen. Die Skizzen zu den Problemen sind in objektorientierter Notation erstellt und wurden mit der endgltigen Spezifikation von UML in die UML-Notation berfhrt. Die Muster von Fowler enthalten gemss Johnson eine grosse Menge an Wissen, das in allen Bereichen der Softwareentwicklung fr Unternehmen genutzt werden kann (Fowler 1997, Vorwort V). Die Muster sind nie nur fr die Branche anwendbar, in der sie ursprnglich 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 erlutert, 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 fr weitere Arbeiten ber Entwurfsmuster. Die Autoren haben sich lange mit der Thematik befasst und verfgen 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 Gltigkeitsbereich fest, ob sich Muster primr auf Klassen oder Objekte beziehen.

30

Whrend manche Muster in Kombination auftreten, sind andere sich ausschliessende Alternativen. Die Beschreibung der Muster ist ausfhrlich, formalisiert und umfasst mehrere Teile. Zuerst steht der Name des Musters und sofern vorhanden, andere gelufige 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, erlutert. Die Notation dieser Skizzen basiert auf OMT-Notation (object model-notation). Einem Beschrieb der Interaktion dieses Musters mit anderen folgen die Konsequenzen und die Erluterungen wann dieses Muster implementiert werden soll (Implementation). Es ist immer noch Beispielcode enthalten, sowie eine Aufstellung bekannter Verwendungen in Praxisfllen und der Bezug zu verwandten Mustern. Die Beschreibung der Muster ermglicht es, eigene Software mit den Mustern zu entwickeln oder Muster in bestehender Software zu entdecken (Riehle & Zllighoven 1996, S. 8). Mit den Entwurfsmustern werden aber nicht alle Flle abgedeckt. Es ist daher derzeit nicht mglich, ein Softwaresystem nur mit Entwurfsmustern zu entwickeln. Wie Mularz (1995, S. 443) anmerkt, sind die Entwurfsmuster von Gamma et al. besonders fr neue objektorientierte Systeme hilfreich, dagegen weniger fr 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, hufig 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 Ttigkeit 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 darber ausgetauscht. Im Gegensatz zu Gamma et al. (1995) sind die Beschreibungen nicht ausschliesslich auf objektorientierte Muster ausgelegt und umfassen nicht nur Beschreibungen von Entwurfsmustern, sondern auch (Software-)Architekturmuster und Idioms. (Software-)Architekturmuster beschreiben ein grundlegendes Strukturorganisationsschema fr Softwaresysteme. Architekturmuster bieten eine Menge von vordefinierten Untersystemen, beschreiben deren Verantwortlichkeiten nher 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 Mglichkeiten einer bestimmten Programmiersprache ausschpft. Als weitere Kriterien gliedern Buschmann et al. die Muster nach strukturellen Prinzipien und Funktionalitt. Strukturelle Prinzipien sagen aus, ob die Systeme gekapselt oder verbunden sind, whrend die Funktionalitt Aussagen ber Kommunikation und Zugangsprotokolle macht. Whrend Gamma et al. bewusst nicht auf Muster fr Nebenlufigkeit und verteilte Programmierung eingehen (1995, S. 2), widmen Buschmann et al. das zweite Buch ganz den Mustern fr nebenlufige und vernetzte Objekte (2002). Die Muster werden ausfhrlich beschrieben, wobei zuerst der Name steht, weitere mgliche Bezeichnungen und ein zusammenfassender Kurzbeschrieb. Im Gegensatz zu Gamma et al. bildet ein Beispiel aus der Realitt den Einstieg zur weiteren Beschreibung und steht nicht erst gegen Schluss. Es folgen die Beschreibung des Kontexts, des Problems, der Lsung und die Beschreibung der detaillierten Struktur mit der Illustration in einem OMTKlassendiagramm. Die Dynamik beschreibt das Laufzeitverhalten eines Musters und wird durch sogenannte Object Message Sequence Charts beschrieben. Zur Implementation geben Implementationsrichtlinien weitere Vorschlge. Programmbeispiele illustrieren die Umsetzung in Code. Der Abschnitt gelste Beispiele enthlt wichtige Aspekte, die in der obigen Beschreibung noch nicht enthalten sind. Der nchste Teil enthlt 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 darber- und darunterliegenden Ebenen der Softwarearchitektur-Muster und Idioms. Sie trennen damit die eher generativen Muster von der programmiernahen Beschreibung der Implementationsproblemstellungen. Insbesondere der zweite Band ber die Programmierung nebenlufiger und vernetzter Objekte enthlt ausschliesslich Muster, die auf Betriebssystemebene interagieren und beschreibt Lsungen fr professionelle Software-Entwickler.

5.3.3 Riehle/Zllighoven
Riehle und Zllighoven haben 1996 ein wissenschaftliches Papier verffentlicht, das ebenfalls drei verschiedene Typen von Mustern beschreibt: die konzeptionellen Muster, die Entwurfsmuster und die Programmiermuster. Riehle und Zllighoven haben ihre Erfahrung mit Pattern in der Entwicklung von interaktiven Softwaresystemen fr Forschung und Industriepraxis erworben. Sie lehnen sich fr 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 Zllighoven den Modellen die drei Muster zu. Die konzeptionellen Muster, ursprnglich Interpretations- und Gestaltungsmuster genannt, werden durch die Begriffe und Konzepte eines Applikationsbereichs beschrieben. Konzeptionelle Muster untersttzen damit die Diskussion verschiedenster Gesichtspunkte aller in den Softwareentwicklungsprozess involvierten Gruppen (Riehle & Zllighoven 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, Zllighoven beweist den Wert der vorgestellten Muster. Denn Muster haben gemss Definition dann eine hohe Qualitt, wenn sie immer wieder auftreten und die Realitt gut beschreiben. Auch Bass et al. (1998, S. 25 und 93f.) nehmen eine solche Dreiteilung vor. Systemmuster oder Architekturstile (prziser 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 Objektklassen, die zusammenarbeiten, um eine bestimmte Lsung 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 hufig komplizierter machen, da eine zustzliche Ebene hinzukommt. Dazu ist die Anwendung der Entwurfsmuster hufig mhsam, weil viel Handarbeit geleistet werden muss, um den Programmcode des Musters in eine bestehende Applikation einzufgen 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 fr nachfolgende Entwickler erkennbar sind und Untersttzung durch Werkzeuge mglich 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 gehrend erkennbar sind. Um dies zu erreichen, schlagen Smolarova und Navrat vor, aus dem Entwurfsmuster-Katalog eine Sammlung von Musterprototypen zu erstellen. Diese

33

wrden keine informellen Elemente enthalten, sondern sich auf die Reprsentation eines Musters konzentrieren und die Struktur beschreiben. Durch Festlegen der noch unbestimmten Teile eines Musters und Ersetzen der generellen Bezeichnungen durch spezifische wrde man dann die Muster fr den Gebrauch in einem Programm ableiten. Die Ableitung aus einem Prototyp erhht die Verstndlichkeit der strukturellen Abhngigkeiten.

5.5 Organisations- und Prozessmuster (Coplien)

James O. Coplien befasst sich schon lnger 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 ttig. Die Organisations- und Prozessmuster als soziale Muster werden als eine weitere Mglichkeit gesehen, den Softwareentwicklungsprozess zu verbessern. Coplien (1996, S. 1ff. und 1995, S. 183ff.) verweist auf die Ursprnge in den sozialen Mustern in der Anthropologie und auf die Beziehung zwischen Architektur und den sozialen Gruppen, die sich in den Gebuden 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 fhren. 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 Aktivitten. Die Beschreibung der Muster gliedert sich hnlich wie bei anderen Autoren: Name, allenfalls andere Bezeichnung, Kontext, die einwirkenden Krfte, Lsung und die Lsung auf den Kontext bertragen, sowie manchmal noch die Gedankengnge bis zur Lsung. 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 fr eine vertiefte Auseinandersetzung mit Organisations- und Prozessmustern geschaffen.

34

5.6 Muster zur Prozessverbesserung (Appleton)

Die Muster von Appleton (2000, S. 1ff.) sind genauer Muster zur erfolgreichen Softwareentwicklungs-Prozessverbesserung. Sie werden als I-SPI bezeichnet, eine Abkrzung fr Initiating Software Process Improvement und wurden an der PLoP-Konferenz 1997 vorgestellt. Appleton geht dabei von der Idee aus, dass hnlichkeiten zur Produktentwicklung bestehen. Appleton hat die Muster in Prozessverbesserungsinitiativen sowohl als Change Agent, wie als Vernderungsbetroffener erfahren. Appleton weist darauf hin, dass Prozessvernderung mehr umfasst, als die blossen Prozesse. Sie lst eine kulturelle Vernderung aus mit all den Schwierigkeiten, die Wahrnehmung, die Werte und das normative Verhalten einer Gruppe zu ndern. Die zehn Muster werden in die Gruppe der Organisationsmuster und der Prozess- und Kommunikationsmuster unterteilt. Zur Beschreibung der Muster benutzt Appleton seinen Grundraster (2000, S. 9ff.) mit Name, Kontext, Problem, Krfte, Lsung, Resultat im Kontext, Gedankengnge 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 Vorgehen in einer Spiralenform vorschlgt. Appleton merkt kritisch an (2000, S. 17), dass die Muster noch nicht ganz vollstndig 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 eingefhrt und die Prinzipien von Mustern vorgestellt. Dabei wurde im Kapitel IT-Architektur der Begriff Softwarearchitektur erlutert 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 SoftwarearchitekturMuster 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). CodeWiedergebrauch, krzere Entwicklungszyklen, die Mglichkeit Komponentenentwicklung extern zu vergeben, die Untersttzung bei der Planung von qualitativ hochwertigen Prototypen und hnliches, stehen dabei im Vordergrund. Durch die umfangreiche Forschungsttigkeit 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 fnf Obergruppen an Mustern, nmlich 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 knnen. 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 geschlossene 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 ungengend ausgerumt, da die Muster nicht beschrieben und katalogisiert werden, sondern nur in Tabellen eingeordnet.

36

Abbildung 8: Klassifikation von Softwarearchitektur-Muster

Independent Components

Communicating Processes

Event Systems

Implicit Invocation

Explicit Invocation

Data Flow Batch Sequential Pipes and Filters

Data-Centered Repository Blackboard

Virtual Machine

Call and Return

Interpreter

Rule-Based System

Main program Object Layered and Subroutine 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) fnf verschiedene EAI-Architekturmuster vor. Diese dienen der Integration verschiedener Applikationen, sowie der Integration von Komponenten innerhalb einer Applikation. Sie haben sich in der Praxis mehr als einmal bewhrt oder sind in Werkzeugen von namhaften Herstellern im EAI-Bereich enthalten. Die Muster heissen Integration Adapter, Integration Messenger, Integration Faade, Integration Mediator und Process automator. Sie sind verwandt mit entsprechenden Entwurfsmustern wie sie Gamma et al. (1995) vorschlagen. Als Hauptunterschied wird angefhrt, 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 Lsung und deren Nutzen illustriert an Beispielen. Dazu verwendet Lutz Grafiken. Den Nutzen von EAI-Mustern sieht Lutz neben einer schnelleren Erstellung von EAIArchitekturen darin, dass sie einen Rahmen liefern um EAI-Werkzeuge verschiedener Anbieter auf ihre Strken und Schwchen hin, besser beurteilen zu knnen. Daneben helfen sie Anwendungsintegrationsstandards in Unternehmen zu etablieren (Lutz 2000, S. 73).

37

6.4 Musterbasierte Integrationsarchitekturen (Mularz)

Diane Mularz schlgt im Rahmen der ersten PLoP-Konferenz vier Integrationsmuster vor, die aus der Erfahrung der Integration bestehender Systeme entstanden sind (1995, S. 441ff.). Sie arbeitete fr das MITRE, ein Forschungszentrum, das Auftrge fr amerikanische Regierungsstellen im Bereich der Luftfahrt und Verteidigung ausfhrt. Die Beschreibung der Muster erfolgt dabei strukturiert nach Name, Absicht, Kontext, eine Beschreibung der Integrationskonflikte, die gelst werden und die Lsung, sowie deren Anwendbarkeit und der Hinweis auf ergnzende Muster. Eine Grafik dient der Visualisierung. Das erste der vier vorgestellten Muster ist Wrapper, welches die Integration von Legacy Systemen ermglicht. Der Work Flow Manager fhrt vom Benutzer bestimmte Aufgaben in der festgelegten Reihenfolge aus. Der Broker ermglicht die Integration von verteilten heterogenen Systemen, unabhngig von deren Standort, Kommunikationsprotokoll und Plattformabhngigkeit. 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 rudimentr beschrieben sind und allenfalls weitere dazukommen knnten. Die Konzentration auf vier wesentliche Anstze, kurze przise Beschreibungen im erwhnten Musterformat und untersttzende Grafiken, machen die Muster von Mularz leicht verstndlich.

6.5 Daten- und methodenbasierte Muster (Linthicum)

Linthicum (2002) schlgt eine Vereinfachung der Entwurfsmuster vor und fhrt diese auf zwei Grundmuster zurck: 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 ausgewiesener Praktiker, der immer wieder zum Thema Anwendungsintegration publiziert. Die datenbasierte Integration umfasst Prozesse, Techniken und Technologien zur Verschiebung von Daten zwischen Speichern. So werden bei datenbasierter Integration Daten aus verschiedenen Datenbank extrahiert, bentigte Information weitergeleitet und andere Datenbanken damit aktualisiert. Als Untermuster verweist Linthicum auf die Ausprgungen relational, objektorientiert, hierarchisch oder multidimensional. Bei der methodenbasierte Integration wird die Geschftslogik integriert. Man bezeichnet es auch als Prozess-Integration. Auf einem zentraler Server sind die Methoden abgelegt und damit anderen Applikationen zugnglich. Das erfordert vorgngig 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 knnen objektorientiert, transaktional oder prozedural sein.

38

Im Buch erwhnt Linthicum zustzlich die Benutzungsoberflchen-Integration und Applikationsschnittstellen-Integration. Beide machen Geschftsprozesse und Daten durch ein Interface zugnglich (2000, S. 39) und stehen zwischen methodenbasierter Integration und datenbasierter Integration. Denn sie knnen mehr als Daten integrieren, sind aber bei Geschftsprozessintegration nicht allmchtig. Whrend die Applikationsschnittstelle voraussetzt, dass die Applikation mit einer Schnittstelle ausgestattet wurde, ntzt eine Benutzerinterface-Integration das bestehende Benutzerinterface zur Integration (2001, S. 52ff.).
Abbildung 9: Databasierte vs. methodenbasierte Integration
If... choose... need to access application logic data is bound to a method (e.g. object-oriented) data may be extracted from application without interfering with application integrity (Database) data level interfaces exist (e.g. ODBC) information (not data) can be extracted at an application level (e.g. API) method level technologies exist (application server, distributed objects) low latencies are important x x x Data Level Method Level x x

x
Quelle: eigene Darstellung nach Linthicum 2000

Obwohl Linthicum auf das bliche Grundformat eines Musters (Kontext, Problem, Lsung) hinweist, sind seine Muster nur ansatzweise entsprechend beschrieben. Die Fokussierung auf zwei Muster lsst 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 Organisationsfragen. Die Autoren sind alle als Berater ttig. Fnf Organisationsprinzipien Vision, 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 ausfhrlich etwa dem Raster aus Abschnitt 4.6 Dokumentation von Mustern entsprechend. Als Besonderheit stellen die Autoren den Mustern auch Anti-Patterns, also Anti-Muster gegenber. Das sind Muster, die im jeweiligen Kontext falsch wren und nicht angewendet werden sollten. Sie bilden somit das Gegenstck zu den Mustern. Es werden hier drei Muster herausgegriffen, die sich mit der methodischen Einfhrung einer neuen Architektur befassen.

39

Das Pilotprojekt-Muster schlgt vor, bei einer IT-Architektur-Lsung, die fr andere, allenfalls gar externe Organisationseinheiten bestimmt ist, ein Pilotprojekt durchzufhren (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 Lsung sei einfach zu bewltigen. Im ersten Fall knnten die zuknftigen Anwender resignieren, im zweiten Fall knnte das Projekt unterschtzt 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 schlgt vor ein Review-Team zu bilden, in das die Anspruchsgruppen eingebunden sind. Wenn in einem Unternehmen neue Technologien bentigt werden und diese nicht zu den derzeitigen oder zuknftigen Kernkompetenzen gehren, 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 Projektmanagement-Grundstze, die gut verstndlich formuliert in ein Musterformat gebracht wurden. Ntzlich sind die ausfhrlichen 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 fnf Dimensionen untersucht und anschliessend drei Muster von IT-Strategien gefunden. Dazu haben sie 150 multinational ttige Unternehmen in 20 Lndern 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 verffentlicht. Entsprechend der geringen geografischen Verteilung haben nur wenige Tochterfirmen im ersten Muster eigenstndige 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 holen oft Rat ein zur Lsung der lokalen Probleme. Die Hardware und Applikationen werden bei globalen Anbietern beschafft. Das zweite Muster der Firmen hat sowohl Informationssystemplne auf Lnderebene in den Tochtergesellschaften, wie auf internationaler Ebene. Auf untergeordneter Ebene wird viel geplant und das Management ist stark darin involviert. Die Daten zwischen den Lndergesellschaften sind aber wenig standardisiert und die IT-Ausbildung findet lokal statt.

40

Abbildung 10: Ausprgungen bei multinationalen Unternehmen

Multinat. Corp. Type Dimension Value-Chain configuration Export orientation Parent-Child configuration Portfolio Configuration Global Firm

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 Plne fr die Lndergesellschaften und auf der internationalen Ebene bergreifende Plne. Diese bergreifenden Plne existieren sowohl fr Tochtergesellschaften im Besitz der Muttergesellschaft wie auch fr Joint-Ventures. Der Grossteil der Planung erfolgt auf Unternehmensebene. Nichtsdestotrotz planen die Tochtergesellschaften auch sehr viel und bringen gute Beitrge ein. IT-Training geschieht sehr hufig in weltweiten Schulungen. Hardware und Applikationen werden entsprechend von global ttigen Anbietern beschafft und es wird auf Kompabilitt 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 Strategietypen. 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 schlgt dazu ein objektorientiertes Zachman Framework vor.

41

Die musterbasierte Reengineering-Methode (Pattern Based Reengineering PBR) basiert auf Geschftsanwendungsfllen1, ist architekturorientiert und stellt eine Mustersprache zur Verfgung um Reengineering durchzufhren. Folgende Phasen werden dabei chronologisch durchlaufen: Strategische Einschtzung, Geschftsanalyse, Geschftsentwurf, Geschftsentwicklung und Aufrechterhaltung (Beedle 1997a, S. 1ff.). Beedle erachtet den Begriff Muster dann als passend, wenn sich ein Muster mindestens dreimal in der Praxis bewhrt hat. Seine Musterbeschreibungen verweisen daher jeweils auf eine Reihe von bekannten Anwendungen in Firmen. Die Muster wurden ausserdem dem Shepherding unterzogen. Damit wird in der Muster Community der Reviewprozess verstanden2. Beedle lehnt sich ebenfalls an das Musterformat von Alexander an (1997b, S. 2ff). Die BPR-Muster beschreiben die soziale, rumliche 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 Zachman Framework

Applicable Pattern language

Tools in Focus

Risk Assessments

Techniques

Objects in Focus

Scope

Pattern-based BRP

Financ. Forecasts Cost/Benefits Analysis ABC Tools Process and Project Tools CASE Tools CASE Tools Process and Project Tools CASE Tools Compilers Debuggers CM tools CASE Tools Compilers Debuggers Testing tools

Impact to whole organization

Process textual descriptions

Large Scale organization

Business or Enterprise Model

Pattern-based BRP

Impact to specific process reengin. Projects

Business Use Cases System Use Cases Class categories Use Case Maps

Small Scale Org. Business Object Model Roles

System Model

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

Impact to appl. Development

Applications

Technology Model

Business Patt. Software Design Patt. (Gamma)

Impact to overall System and Architecture applications Impact to appl. development projects

Design Heuristics

Business Object Models Design Object Model + mechanism Object Code i.e. C++, Java, Smalltalk

Detailed Reprasentation

Idioms

Edit, Compile, Link, Test

Quelle: Beedle 1997a, S. 5

Dabei werden verschiedenste Bereiche abgedeckt. So beschreiben einige Muster Rollenmodelle in Organisationen, wie Leader oder Business Architect. Dabei lehnt Beedle sich an die Arbeiten anderer Autoren an. Beedles Business Architect etwa entspricht dem Reengineering Czar von Hammer und Champy (1993, S. 115f.). Andere Muster beschreiben eher den Prozess der Vernderung. 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).
1 2

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 fr die verschiedensten Bereiche der Architekturplanung umfassen.

6.9 Integrationsmodelle (Brown)

Laura Brown, war lange Zeit als Beraterin ttig, bevor sie 1994 eine eigene Beratungsfirma grndete. Ihr Buch Integration models Templates for Business Transformation soll die Lcke zwischen Geschftsmodellen (wie S-Kurven, Wertschpfungskette und Kernkompetenzen usw.) und technischen Modellen (wie ERA-Modellierung, Use Cases, Datenflussdiagramme) fllen (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 mchte. Integrationsmodelle sind dazu entwickelt worden, um ein Organisationsprinzip zur Modellierung von Integrationsproblemen und Lsungen zur Verfgung zu stellen (Brown 2002). Die Integrationsmodelle von Brown sind in einem einheitlichen Format gegliedert, das aber von den vorgestellten Musterformaten strker 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 Geschftsablauf ein Netz an Verbindungen oder Schichten zur Reduktion der Komplexitt? mit ein. Der starke Einbezug der Geschftsperspektive 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 knnen und hufige Geschftssituationen oder Strukturen erfassen (1996, S. 22).

43

Die Vorteile musterbasierter Anstze 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 Verstndlichkeit der Besonderheiten. Es werden Fehler vermieden, weil die Grundelemente gegeben sind. Es resultieren weniger Tabellen und die Wartung wird vereinfacht.

Das Buch umfasst unzhlige Modellierungsvorschlge zur Mitarbeiterzuordnung, Regionenzuordnung, Vertragsrollenmodellierung und zu Prozessflssen. Da sie in relationaler Notation mit unstrukturiertem Begleittext verfasst sind, sind sie nicht so einfach anwendbar wie andere Muster.

6.11 Untersttzungsmuster (Fowler)

Wie bereits erwhnt, beschreibt Fowler neben den Analysemustern sogenannte Untersttzungsmuster. Whrend Analysemuster hilfreich sind fr die Entwickler von Informationssystemen, dienen die Untersttzungsmuster auf einer hheren 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 zweistufigen 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 grsste Vorteil dieser Architektur ist, dass die mittlere Ebene sich auf die Geschftsablufe und die Semantik konzentriert, whrend die anderen Ebenen die Reprsentation 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 schlgt ausserdem noch eine vierte Schicht vor, welche die Applikationslogik enthlt und zwischen dem konzeptuellen Schema und der Prsentation steht (1997, S. 246f.). Bei anderen Autoren, wie Linthicum, wird eine dreistufige Architektur anders definiert (2000, S. 46). Dort existiert eine Reprsentationsschicht, 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 Entwicklung der Schichten erforderlich. Manchmal treten auch Performance-Probleme auf (Fowler 1997, S. 249).

44

Als weiteres Untersttzungsmuster neben der Schichtenarchitektur wird das Fassadenmuster 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 Untersttzungsmuster 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 Schichtenarchitektur ist das ISO/OSI-Modell mit den sieben Schichten Bitbertragung, Sicherung, Vermittlung, Transport, Kommunikation, Darstellung und Anwendung. In einer Schichtenarchitektur kommunizieren die einzelnen Schichten theoretisch nur mit den benachbarten Schichten. Wie Bass et al. schreiben wird das Modell teilweise untergraben, indem aus Perfomance-Grnden Schichten erlaubt wird, mit zustzlichen Schichten zu kommunizieren (1998, S. 100). Das Schichtenmuster hat in der Softwarearchitektur breite Verbreitung gefunden. Die oberste Schicht ist dabei eine Reprsentations- oder Anwendungsschicht, die unterste Schicht eine Schicht mit Kernfunktionalitten. Die Schichtenarchitektur kann nicht nur als Entwurfsmuster mit unterschiedlichen Ausprgungen, 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 fr die IT-Architekturgestaltung bei Integrationsprojekten zu entwickeln, ist eine Fragestellung, die eigentlich ausfhrlicherer Diskussion bedrfte. Es soll hier dennoch noch versucht werden, ein mgliches Modell zu entwickeln, um anschliessend zu beurteilen, inwiefern Muster fr die einzelnen Phasen verwendet werden knnen. Obwohl verschiedene Autoren mgliches Vorgehen ansatzweise skizzieren, sind die wenigsten Anstze umfassend. Allgemeine IS-Architektur-Planungsanstze (wie sie auch sterle entwickelt hat, z.B. sterle et al. 1992) sind fr die Problematik der Anwendungsintegration wenig zielgerichtet. Sie fokussieren zu stark auf die Neuentwicklung komplexer Applikationen. Um ein Vorgehensmodell abzuleiten, wird hier daher auf bestehende Modelle aus verwandten Bereichen zurckgegriffen.

7.2 Business Engineering

Die drei Ebenen des Business Engineering Metamodells von sterle wurden bereits unter 2.2 Ebenen des Business Engineering erlutert. 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-Vorgehen nahe (1995, S. 23). Dazu werden von der Geschftsstrategie ausgehend die Prozesse und Systeme entwickelt. Beedle schlgt in seiner Business Engineering Methode einen iterativen Zyklus vor, an dessen Anfang die Strategiefestsetzung steht. Darauf folgen die Geschftsanalyse, der Geschftsentwurf und anschliessend die Geschftsentwicklung (1997a, S. 6). Im Gegensatz zu sterle bezieht er damit die Informationssystemebene nicht explizit ein.

7.3 Software Engineering

Balzert schlgt in seinem Lehrbuch der Softwaretechnik fr die Softwareentwicklung ein Vorgehen in sieben Phasen vor (2001, S. 51ff.). Die Softwareentwicklung beginnt dabei mit der Planungsphase, wo eine Durchfhrbarkeitsuntersuchung vorgenommen wird. Darauf basierend wird dann am Ende der Phase entschieden, ob das Projekt weitergefhrt werden soll. In der Definitionsphase werden die genauen Anforderungen ermittelt (Pflichtenheft) und eine Lsung 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 Einfhrung der Benutzer statt. Diese Phase wird daher als Abnahme-

46

und Einfhrungsphase bezeichnet. Die kontinuierliche Wartung und Pflege bilden die letzte Phase. Brown (2000, S. 64ff.) weist auf einige Unterschiede zwischen gewhnlichen Softwareprojekten 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 fr eine bestimmte Abteilung, liegt der Fokus in der Integration auf der Wiederverwendung bestehender Applikationen mit dem Ziel, neue bergreifende Geschftsprozesse zu untersttzen. Wie Brown auch erwhnt, ist bei Integrationsprojekten nicht dem Entwickler berlassen, in welcher Technologie eine Lsung umgesetzt wird. Es sind zahlreiche Restriktionen vorhanden. Da hufig Problemstellungen aus unterschiedlichen Bereichen gelst werden mssen, sind eher Generalisten statt Spezialisten gefragt. Ein Beispiel ist die Anbindung existierender Applikationen an das Internet. Es ist dabei hilfreich, auf Erfahrungen anderer zurckgreifen zu knnen. Eine weitere Herausforderung ist die Integration unterschiedlichster Datenquellen und Datenstze.

7.4 Implementation einer EAI-Architektur

Cummins (2002, S. 406) schlgt ein Vorgehen zur Umsetzung von Anwendungsintegrations-Architekturen mit elf Schritten vor. Im Gegensatz zu anderen Autoren geht er ebenfalls von einer strategischen Planung aus, gestaltet dann die Geschftsprozesse 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 Geschftsprozessen und der Implementation (2001, S. 267ff.). Die elf Phasen bei Cummins sind: Strategische Planung Serviceorientierte Geschftsprozesse entwickeln Benutzereinstellung verndern Infrastruktur umsetzen Infrastruktur verwalten (managen) Applikationsintegrationsziele setzen Standards festlegen Vernderung bewltigen Informationssystemmanagement konsolidieren Kritische Erfolgsfaktoren beachten

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

47

7.5 Mgliches Vorgehen bei der IT-Architekturgestaltung

Die folgende Abbildung soll zeigen, wie sich Geschftsprozesse, die Informationssystemarchitektur, die Applikationsarchitektur und Hardwarearchitektur gegenseitig beeinflussen. Das Vorgehensmodell fr die Architekturplanung soll sich dabei grundstzlich 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
Geschftsprozesse
(Business Engineering)

Hardwarearchitektur

Informationssystemarchitektur

Applikationsarchitektur
(Software Engineering)

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

Strategische Einschtzung In der strategischen Planung sollte zuerst eine gemeinsame Vision festlegt werden (Cummins 2002, S. 407ff.). Dabei sind die Potentiale der Informationstechnik fr das Unternehmen zu beachten (sterle 1995, S. 15). Eine mgliche Entscheidung wre etwa, in einem Unternehmen den Kunden zuknftig Lieferfristen von 24 Stunden anzubieten. Falls batchgesteuerte Kommunikation im Unternehmen dominiert, ist das Informationssystem auf ereignisgesteuerte Ablufe umzubauen. Weil Batchablufe nur zu festgelegten Zeiten die Daten zwischen verschiedenen Applikationen bergeben, z.B. einmal tglich, ergeben sich Verzgerungen in der Bearbeitung. Bei ereignisgesteuerten Ablufen entfallen diese Verzgerungen (Cummins 2002, S. 408). Geschftsprozesse Prozesse sind im Business Engineering-Modell von sterle das Bindeglied zwischen Strategie- und Systementwicklung (1995, S. 20f.). Diese Phase lsst sich glieden in Geschftsanalyse, Geschftsentwurf und Geschftsentwicklung (vgl. Beedle 1997a, S. 6). Geschftsprozesse bestehen aus Aufgaben, die ber verschiedene Abteilungen verteilt sind. Frher untersttzten 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 Geschftsanalyse und ein Geschftsentwurf 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 nchste Geschftsprozessvernderung anpassbar sein soll. Obwohl der ITArchitekt enge Verknpfungspunkte mit dem Business Engineering aufweist, muss er bereits die nchste Vernderung antizipieren und anpassbare Applikationen schaffen. Applikationsintegrationsziele festlegen Ausgehend von der Vision der Geschftsstrategie und den Kenntnissen der Geschftsprozesse knnen die Integrationsziele entwickelt werden. Mgliche Ziele sind dabei lose Koppelung der Applikationen oder feste Anbindung, Anbieten eines internetbasierten Zugriffs auf Applikationen, Einfhren 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, Datenstze und der zugrunde liegenden Technologien muss daher vor dem Entwurf erfolgen. Ausserdem erfolgt blicherweise ein Entscheid fr bestimmte Standards. Das knnen offene Standards oder herstellerabhngige Standards und firmeninterne Standards oder Internetstandards sein. Softwarearchitektur festlegen In dieser Phase erfolgt die Planung der Softwarearchitektur durch Festlegung der Schnittstellen und Bestimmung neuer Komponenten. Es werden technische Integrationsmglichkeiten zur Lsung der Heterogenitt und Distribution bestimmt. Applikationsentwicklung Die Applikationsentwicklung setzt die Plne und Vorgaben um. Hierbei sind die Standards einzuhalten, Wiederverwendbarkeit zu frdern, Reviews und Integrationstests durchzufhren. Fr die Applikationsentwicklung werden die Methoden des Software Engineering angewandt, wie sie z.B. im Vorgehensmodell von Balzert beschrieben sind. Da immer mehr Softwareprodukte Schnittstellen enthalten oder durch Untersttzung von CASE-Tools entfllt die Applikationsentwicklung teilweise. Projektmanagement Anwendungsintegration erfordert ein Umdenken im Verhalten der Betroffenen. Wie in Abschnitt 2.4 erlutert, sind vielfach Widerstnde gegen Integration vorhanden. Diese knnen aus Angst vor Machtverlust resultieren oder weil die Betroffenen in berholten Denkablufen verhaftet sind. Daneben mssen auch die Personen, die in einem Projekt arbeiten, gemanagt werden. Dieser Teil hat fortlaufend stattzufinden.

49

7.6 Muster zur Untersttzung der Architekturgestaltung

Da es das Ziel dieser Arbeit ist, zu untersuchen, inwiefern Muster die Architekturgestaltung untersttzen. Die vorgestellten Phasen werden hier daher in Verbindung zu den Mustern gebracht. Strategische Einschtzung King und Sethi haben mit ihrer Untersuchung zur IT-Strategie in multinationalen Unternehmen Strategiemuster ermittelt, die zwar nicht in der 3-Teile-Regel oder in einem anderen Format beschrieben sind. Aber es ist mglich, ein Unternehmen in Bezug auf die fnf Dimensionen (Wertschpfungskettenkonfiguration 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 ITStrategien 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 Geschftsstrategie hat aber durchaus Auswirkungen auf das Informationssystem. So bentigt ein Unternehmen, das eine Expansionsstrategie verfolgt, auch eine entsprechend skalierbare Architektur. Geschftsprozesse Auf der Ebene der Geschftsprozesse sind die Muster von Beedle einzuordnen. Beedle untersttzt mit seinen Mustern die Phasen der Geschftsanalyse, des Geschftsentwurfes und der Geschftsentwicklung. Die Muster befassen sich einerseits mit der Reorganisation von Geschftsprozessen und andererseits beinhalten sie Handlungsanweisungen um die Vernderung zu bewltigen. Applikationsintegrationsziele festlegen Muster die zwischen Geschftssicht und technischer Ebene stehen, sind selten. Die Integrationsvorlagen von Brown schliessen diese Lcke. Geschftsziele wie reduzierte Durchlaufzeit, Teilung von Ressourcen oder die parallele Bearbeitung von Prozessschritten knnen in Muster umgesetzt werden, denen man anschliessend Muster zur technischen Realisation zuordnen kann. Analyse der Infrastruktur und Standards festsetzen Das Muster der Schichtenarchitektur hilft definitionsgemss bei der Unterteilung einer ITArchitektur in Subsysteme. Es ist daher nicht nur zur Festlegung einer Softwarearchitektur hilfreich, sondern auch bei der Analyse. Softwarearchitekturmuster knnen generell einen Beitrag zur Bestimmung und Modellierung der bisherigen Infrastruktur leisten.

50

Softwarearchitektur festlegen Fowler beschreibt in seinen Analysemustern konzeptionelle Strukturen von Geschftsprozessen in objektorientierter Form. Hay beschreibt solche konzeptionellen Strukturen zu Geschftsfllen in relationaler Form. Die Muster gehen ber die Entwurfsmuster der Softwarearchitektur hinaus, weil sie die Muster nicht nur aus Sicht der technischen Implementation beschreiben, sondern als Lsung zu Problemen in Geschftsprozessen. Lutz beschreibt in seinen Mustern auch Geschftsvorflle, fr welche die Muster eine Lsung sind. Er geht damit weiter als Mularz, welcher die Softwarearchitektur-Muster zur Integration nur grundlegend beschreibt. Die Muster der verschiedenen Autoren der Carnegie Mellon-Universitt sind dagegen nur auf die technische Ebene fokussiert. Linthicums Muster sind eher grundlegene Anstze zur Integration. Da er sowohl auf die Geschftsprozesse eingeht, als auch konkrete Programmzeilen beschreibt, dienen seine Publikationen eher dem berblick. Im allgemeinen kann hier unterschieden werden zwischen den technisch geprgten Autoren, wie die Gamma et al., Buschmann et al., die Autoren der Carnegie Mellon University, Mularz und solchen, die in den Musterbeschreibungen auch auf die Geschftsuntersttzung eingehen (Fowler, Hay, Lutz). Applikationsentwicklung Die Entwurfsmuster der verschiedenen Autoren sind sehr implementierungsnahe. Obwohl sie die Phase der Softwarearchitekturfestlegung ebenfalls untersttzen knnen, werden sie hier eingeordnet, da sie aus der Softwareentwicklung entstanden sind. Buschmann et al. und Gamma et al. fhren 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 Projektmanagementanstze und knnen 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 fr die technische Zusammenarbeit zwischen Komponenten, sondern auch fr den Geschftskontext. Die Verknpfung der Integrationsmuster mit der Geschftssicht ist derzeit eher rar. Aus Sicht der Unternehmen besteht hier sicher Handlungsbedarf. Denn gegenber Frameworks bieten Muster den Vorteil der Programmiersprachenunabhngigkeit.

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 Stdtebauers Alexander waren dabei der Ausgangspunkt. Um aus Erfahungen anderer zu lernen, auf bewhrte Lsungen zurckgreifen zu knnen 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 fhren verschiedene Einflsse, im besonderen die Ausrichtung der Prozesse auf den Kunden, zum Bedrfnis heterogene autonome Applikationen integrieren zu knnen. In der technischen Integration wurden inzwischen viele Probleme gelst. Anwendungsintegration befasst sich aber auch damit wie die Geschftsziele und -prozesse durch Integration untersttzt werden knnen. Dabei gilt es neben der technischen Sicht auch die Geschftssicht zu bercksichtigen. Der IT-Architekt hat dadurch unterschiedliche Perspektiven zu beachten wie die Geschftsprozesse, 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 bewhrte Lsungen zu Problemen zur Verfgung zu haben. Doch die Entwurfsmuster der Softwarearchitektur reichen dazu nicht aus. Diese Arbeit zeigt weitere Muster aus der aktuellen Literatur, die sich fr die Architekturgestaltung verwenden lassen. Zu technischen Implementationsmuster existieren inzwischen einige Publikationen. Aber auf der Geschftsseite sind diese eher selten. Die Qualitt eines Musters richtet sich nach der Strukturiertheit der Sprache, ob sich die Muster bewhrt haben und von anderen Personen als gut bewertet wurden. Es wurden daher die Erfahrungen des Autors, ob ein Reviewprozess stattgefunden hat und das gewhlte Format der Muster dargelegt. Neben den Entwurfsmustern existieren die Analysemuster, die konzeptionelle Strukturen von Geschftsprozessen entwerfen. Die Abbildung der Grobstruktur eines Softwaresystems erfolgt in den Architekturmustern. Weitere Muster wie Prozess- und Organisationsmuster befassen sich dagegen mit den organisatorischen Aspekten. Eine Methode zu musterbasiertem Reengineering existiert ebenfalls. Sogenannte Integrationsmodelle befassen sich mit der Modellierung von Integrationsproblemen ausgehend von den Geschftsanforderungen. Da eine ganzheitliche IT-Architekturgestaltung der Informationssystemebene sich auch auf die Geschftsstrategie ausrichten sollte, wurde nach Strategiemustern gesucht. Derzeit sind diese allerdings kaum vorhanden.

52

8.2 Schlussfolgerungen
Whrend 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 Geschfts- und Prozessebene besteht dagegen noch Handlungsbedarf. Grundstzlich bringen Muster fr die IT-Architekturgestaltung Nutzen. So sind sie ein gutes Teamkommunikationsmedium. Aus bewhrter Erfahrung gewonnen, erfassen sie den wichtigen Teil eines Designs in einer kompakten Form und frdern 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 frdern. Die Erwartung an Muster wre zu Recht, dass sie helfen technische Konzepte Nicht-Technikern verstndlich 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 Bedrfnissen der Softwareentwickler. Darin liegt ein Ansatzpunkt zur Weiterentwicklung. Es wurden bereits von den Softwareentwicklungsmustern gewisse grundlegende Softwarearchitekturmuster abstrahiert. Autoren wie Lutz haben diese dann mit Geschftssituationen verknpft. Brown hat grundlegende Integrationsmodelle entwickelt, die sich vom technischen Blickwinkel gelst haben. Ausgehend von Softwarearchitektur-Mustern sollte bottom-up die Weiterentwicklung zu Mustern von Geschftsprozessen oder gar Strategiemustern vorangetrieben werden, hnlich wie bereits Organisations- und Prozessmuster entstanden sind. Das sich bisher entwickelnde Musterformat zur Beschreibung von Mustern ist dafr aber wenig geeignet. Aspekte wie Geschftsprozessuntersttzung und Erweiterbarkeit sollten neben Performance und Codeoptimierung in Mustern enthalten sein. Die Frage der Reprsentation von IT-Architekturen wird auch durch sogenannte Architekturbeschreibungssprachen bearbeitet. Derzeit existieren verschiedene Forschungssprachen, aber kein einheitliches Grundkonzept (Gomaa & Menasc 2000, S. 117). Das Zusammenfhren von Muster und Architekturbeschreibungssprachen wird die Architekturplanung vereinfachen. Doch auf der Ebene der Softwaretechnik sind die Muster noch nicht ausgeschpft. Aktuelle Forschung befasst sich damit, die Softwarearchitektur von Legacy Systemen zu ergrnden1. Ausserdem wren 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 : Stdte, Gebude, Konstruktion. (H. Czech, bers./Hrsg.) Lcker, 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. AddisonWesley 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): Patternoriented software architecture: a system of patterns. Wiley, Chichester. Buschmann, F., Schmidt, D., Rohnert, H. & Stal, M. (2002): Pattern-orientierte SoftwareArchitektur: Muster fr nebenlufige 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. Mrz 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 Fremdwrterbuch (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 Problemlsens. Vernetzt denken, unternehmerisch handeln, persnlich 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. 165184. 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. 201215. Klose, M. (2002): Patterns fr digitale Produkte im digitalen Wirtschaftsraum. Dissertation, Universitt 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. Lscher, A. & Straubinger, A. (1996): Objektorientierte Technologien: Eine Einfhrung. vdf Hochschulverlag ETH, Zrich. 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, Mrz 2000, S. 64-73. Mendona, 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., Knig, 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: Schlssel zur Informationsgesellschaft. In: H. sterle, R. Riehm & P. Vogler (Hrsg.) Middleware Grundlagen, Produkte und Anwendungsbeispiele fr 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): Unternehmensfhrung und Informationssystem. 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. & Zllighoven, 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, Mnchen. 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 Einfhrung in Standardarchitekturen, Protokolle, Verwaltung und Sicherheit. Addison-Wesley, Bonn. Winter, R. & Bauml, U. (2000): Qualifikation fr die Vernderung. 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 aufgefhrt. 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 Bchern um Standardwerke handelt, sollten sie fr Interessierte gut zu beschaffen sein. Aufgrund der ausfhrlichen Beschreibungen mit vielen Illustrationen war es leider nicht mglich 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 aufgefhrt, 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 Abkrzungen:

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
PEG Process Engineering Group -- the SEI Software CMM uses the acronym SEPG (Software Engineering Process Group)

61

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. Martins 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 organizations 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 patrons role. The Manager role is not meant to maintain totally centralized control, but rather to act as champion. That is, the scope of the managers 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 organizations 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 architects organization has to choose the best places to invest development resources, but that might not be enough for architectures 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 partys 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 Webclient 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 applications functionality is extended through the introduction of independent new services that may also be distributed. Post-PloP94 Note: The concept of a wrapper overlaps with the Facade and Adapter patterns described in Gamma et al.. In fact, an examination of the published design patterns from an integration pattern perspective is probably warranted so that new patterns are not unnecessarily introduced.

Erklrung

67

Erklrung
Ich erklre hiermit,

dass ich die vorliegende Arbeit ohne fremde Hilfe und ohne die Bentzung anderer als der angegebenen Hilfsmittel verfasst habe, dass ich ohne schriftliche Zustimmung des Rektors keine Kopien dieser Arbeit an Dritte aushndigen werde, ausgenommen nach Abschluss des Verfahrens an Studienkollegen und -kolleginnen oder an Personen, die mir wesentliche Informationen fr die Diplomarbeit zur Verfgung gestellt haben.

Marco Fischbacher

Gossau, 23. August 2002