Entdecken Sie eBooks
Kategorien
Entdecken Sie Hörbücher
Kategorien
Entdecken Sie Zeitschriften
Kategorien
Entdecken Sie Dokumente
Kategorien
IT-Architekturen zur Integration heterogener Applikationen im Unternehmen Verwendbarkeit von Mustern fr die IT-Architekturgestaltung
Referent:
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
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.
Integration
IT-Architektur
Muster
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.
integration
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.
Market Strategy
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.
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.
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).
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
a on a ti niz ga or y m no to au
s ge an ch l
heterogenity
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
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
Business Model
System Model
Technology Model
Detailed Reprasentation
e.g. Program
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.
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
Process View
Physical/Deployment View
System Engineers Topology Communications
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.
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.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.
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.
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.
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.
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.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.
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.
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.
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.
34
35
36
Communicating Processes
Event Systems
Implicit Invocation
Explicit Invocation
Virtual Machine
Interpreter
Rule-Based System
37
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.
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.
40
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
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.
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
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
Pattern-based BRP
Business Use Cases System Use Cases Class categories Use Case Maps
System Model
Applications
Technology Model
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
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
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.
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.
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.
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.
Cummins beachtet damit sowohl technische Aspekte, wie auch organisatorische und strategischen Fragen.
47
Hardwarearchitektur
Informationssystemarchitektur
Applikationsarchitektur
(Software Engineering)
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
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.
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.
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
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.
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