papierZumVortrag - bib International College

MODERNE
SOFTWARE-ARCHITEKTUREN
IN DER ANWENDUNGSENTWICKLUNG
E R FA H R U N G E N
UND
E I N S C H ÄT Z U N G E N
AU S D E R
PROJEKTPRAXIS
Dr. Michael Löwe
Euroforum Konferenz Softwareentwicklung
München, Mai 2000
EINLEITUNG
Die Anforderungen an die Abteilungen zur Anwendungsentwicklung haben sich in den vergangenen Jahren stark
gewandelt. Die Erstellung individueller, auf das einzelne
Unternehmen zugeschnittener und optimierter Funktionen
nimmt ab. Statt dessen wird die Integration am Markt
angebotener fachlicher wie technischer Standardlösungen
gefordert.
Der Zugang zu den Anwendungen über das Internet, die
Integration der Individual-Software in eine Plattform zur
Bürokommunikation, der Anschluß eigener Komponenten
an eine Standardlösung für die Buchhaltung oder zum
Dokumenten- und Workflowmanagement, die Nutzung
von Office-Systemen auch aus den Anwendungen heraus,
der standardisierte elektronische Datenaustausch mit
fremden Unternehmen sind Beispiele für aktuelle Anforderungen an die Anwendungsentwicklung. Diesen Anforderungen erzwingen den Wandel von einer geschlossenen, stark spezialisierten, individuellen Richtlinien folgenden Systemlandschaft hin zu einer offenen, flexiblen,
internationalen Standards folgenden Infrastruktur.
Viele Unternehmen sind derzeit dabei, solche Infrastrukturen aufzubauen. Entscheidend für den langfristigen
Erfolg dieser Bemühungen ist die Wahl der richtigen
technischen und fachlichen Architektur für diese Infrastruktur. Die richtige Architektur erlaubt den schnellen
und unkomplizierten Austausch einzelner Bausteine, ohne
das gesamte Gebäude kostspielig komplett einreißen oder
umbauen zu müssen. Leider sind derzeit zur Wahl der
richtigen Architektur keine Patentrezepte auf dem Markt.
Und die Schnelligkeit der Entwicklung im DV-Bereich
nimmt weiter zu. Beispiele sind die raschen Fortschritte
des CORBA-Standards, die rasante Entwicklung und
Verbreitung der Technologie rund um Java oder die
schnelle Etablierung des XML-Standards. Nur mit einer
stabilen Architektur wird man zukünftig in der Lage sein,
dieser Geschwindigkeit zu folgen und sie zum Nutzen des
eigenen Unternehmen umzusetzen.
Ein großes deutsches Versicherungsunternehmen hat in
den vergangenen 4 Jahren den Aufbau einer solchen Ar-
chitektur auf der Basis objektorientierter Technologien
vorangetrieben. Daran war der Autor maßgeblich beteiligt. Auf der Grundlage dieser praktischen Projekterfahrungen beschreiben wir in diesem Papier die Bedeutung
der Architektur in einer modernen Anwendungslandschaft, erläutern die verschiedenen Ebenen der fachlichen
und technischen Architektur, diskutieren zentrale Probleme und Lösungsmöglichkeiten sowohl im Bereich der
fachlichen als auch der technischen Systemarchitektur
und resümieren den derzeitigen Stand-der-Kunst.
ZUR BEDEUTUNG DER ARCHITEKTUR
Die Rahmenbedingungen zur Entwicklung von Anwendungssystemen sind schon immer durch Software- und
Systemarchitekturen bestimmt worden. Allerdings waren
die Spielräume bis vor ein paar Jahren relativ eng. So
sahen z. B. alle klassischen Archtiketuren auf zentralen
Großrechner („Fat Server“) ähnlich aus, vgl. Abbildung 1.
Abbildung 1: Architektur "klassisch"
Sie waren wesentlich durch die Hardware- und Betriebsarchitektur des Großrechnersystems selbst geprägt.
Die Anwendungsentwicklung bewegte sich „zwischen“
eingesetzter Datenbank und Transaktionsmonitor.
Zur Kapselung dieser Systemteile wurden i.d.R. Programmschichten zum Zugriff auf die Datenbank und den
Transaktionsmonitor eingezogen, um so eine homogene
Entwicklungsumgebung in einer Programmiersprache
(i.d.R. Cobol) zu erhalten. Sämtliche weitere Architektur-
überlegungen betrafen dann „nur noch“ die funktionale
Zerlegung der Programme.
Die einzige praktikable Alternative zum zentralen Großrechner stellten bis vor kurzem die klassische Client/Server-Architektur dar, vgl. Abbildung 2.
Abbildung 2: Architektur "der Moderne"
Diese auch unter der Bezeichnung „Fat client“ bekannte
Architektur ersetzen das Terminal am Arbeitsplatz durch
einen PC. Dadurch sind graphische Oberflächen und die
Einbindung anderer PC-Standardsoftware möglich. Die
Server sind in diesem Szenario i.d.R. Datenbank-Server
und nur zu einem kleineren Teil Funktionsserver, wenn
die Transaktionen von „Legacy Systems“ eingebunden
werden. Anwendungsentwicklung spielt sich in hier fast
ausschließlich auf und für den Klienten ab.
Architektur ist hauptsächlich durch die Anstrengung bestimmt, die DBMS- und TM-Klienten sowie die Betriebssystemteile zur Oberflächengestaltung auf dem PC zu
kapseln und so wiederum zu einer Anwendungsentwicklung zu kommen, die sich in einem homogenen „Framework“ bewegt. Solche Frameworks werden entweder
durch die eingesetzten Entwicklungswerkzeuge, z.B.
durch Smalltalk-Systeme, oder durch marktgängige Standardbibliotheken bereitgestellt. Sämtliche weitergehenden
Architekturfragen sind in diesem Szenario „nur noch“
Fragen der Programm-Modularisierung.
Insofern unterscheidet sich die klassische Client/ServerArchitektur im Groben nur unwesentlich vom MainframeComputing. Die Offenheit und Flexibilität der Client/Server-Architektur ist allerdings wesentlich größer,
lassen sich in einer solchen Architektur doch mühelos
sämtliche Arbeitsplatzsysteme, wie Textverarbeitung,
Tabellenkalkulation oder Multimedia-Wiedergabe, und
sämtliche Client/Server-Systeme mit PC-Klienten, wie
Datenbank-, Workflow-, Dokumentenmanagement-, Bürokommunikations- und Groupware-Systeme einbinden.
Anwendungsentwicklung hatte sich also schon immer mit
Architekturfragen auseinanderzusetzen, allerdings in
relative überschaubaren und engen Grenzen. Wenige
zentrale Entscheidungen legten die Architektur komplett
fest. Diese Situation ändert sich derzeit und deswegen
kommt der Architektur in der Anwendungsentwicklung
heute eine besondere Bedeutung zu.
Die wesentlichen treibenden Faktoren für diese Veränderung sind:
1. Verteilungstechnologien. DCE, CORBA, DCOM,
Java BEANS etc. sind Verteilungstechnologien, die es
ermöglichen, kommerzielle Anwendungssysteme als
verteilte Systeme (mit voneinander komplett unabhängigen Laufzeitkomponenten) zu planen, zu entwickeln
und zu betreiben. Die hinter diesen Technologien stehenden internationalen bzw. Herstellerstandards bieten
die nötige Zukunftssicherheit für solche verteilte Architekturen.
2. Das Internet. Die Öffnung der Anwendungssysteme
für das Internet ist heute eine zentrale Anforderung an
die Anwendungsentwicklung. Die Standards des Internets bestimmen dadurch die Architekturen wesentlich
mit. Dazu gehören HTML, DHTML, XML, Scripting,
Applets, Servlets, Security-Standards und die Mechanismen des E-Business. Insbesondere erzwingt das Internet eine stringente Server-Orientierung in allen Architekturfragen, denn die Klienten sind StandardBrowser, die nur durch Scripting und Applets in engen
Grenzen1 adaptiert werden können. Die unbekannte
Anzahl der möglichen Benutzer der eigenen Anwendungen erzwingt neue Überlegungen zur Skalierbarkeit.
3. Groupware und Workflow Management. Diese
Systeme „elektrifizieren“ jeden Arbeitsplatz im Unternehmen. Unternehmensorganisation, Zusammenarbeit
und Managementprozesse sind Ziel dieser Systeme.
Durch ihre Integration in eine Anwendungslandschaft
verliert die DV den reinen Werkzeugcharakter. Die
Formalisierung der Aufbau- und Ablauforganisation,
die der Einsatz solcher Systeme voraussetzt, stellt ganz
neue Anforderungen insbesondere an die fachliche Architektur der IV-Infrastruktur. Darüber hinaus haben
diese Systeme weniger den Charakter einer Komponente, die sich in eine Infrastruktur einpaßt. Sie sind vielmehr selbst die Infrastruktur, die über reichhaltige
Schnittstellen die Anbindung von anderen Systemen
ermöglichen. Aus diesem Grund spielen diese Art von
Systemen in jeder Architektur eine Sonderrolle.
4. Objekttechnologie. Diese Technologie entwickelt sich
zur Basis sämtlicher moderner Entwicklungen. Sie ist
nicht nur die Grundlage graphische Oberflächen. Objekte sind auch die Einheiten der Analyse (OOA) des
Entwurfs (OOD), der Funktionsverteilung (Objekte als
Dienste) und der Softwareverteilung (Klassen als Applets). Objekttechnologie, wo immer eingesetzt, stellt
den Entwurf in das Zentrum sämtlicher Aktivitäten. So
wird die Objektorientierte Modellierung auch die Sprache zur Beschreibung von Architekturen sein.
5. Schwächen der existierenden Architekturen. Die
klassischen Architekturen erweisen sich in vielerlei
Hinsicht als unzureichend. Die zentrale Architektur auf
einen Mainframe-Rechner ist nicht offen genug, um
langfristig neue Systeme und Technologien integrieren
zu können. Die dezentrale Architektur des klassischen
Client/Server hat wesentliche Probleme im Bereich der
Software-Verteilung und der (Betriebs-)Sicherheit. Ins1
Die derzeitige Übertragungsraten im Internet lassen die Übertragung
großer Mengen Programmcodes noch nicht zu.
besondere ist sie nicht genug „Server-zentriert“ um
langfristig den Anforderungen der Integration ins weltweite Netz gerecht zu werden.
Die Vielzahl der Einflußfaktoren auf die moderne Anwendungsentwicklung und die Vielzahl der dort jeweils
angebotenen Lösungen oder Teillösungen führt zu einer
bisher nicht gekannten Anzahl möglicher Architekturvarianten. Aber nicht alles ist mit allem sinnvoll zu kombinieren. Viele Technologien sind sogar inkompatibel oder
werden erst kompatibel gemacht.2
In dieser Situation versprechen vorgefertigte Architekturen großer Hersteller Hilfe, wie etwa der „Application
Server“ von Oracle oder „Webshere“ von IBM. Hier
werden verschiedene Technologien zu einer Architektur
zusammengeführt, die den Herausforderungen der Zukunft an die Anwendungsentwicklung standhalten soll. Es
fällt aber i. A. schwer, den Nutzen solcher Standardlösung
für den geplanten Anwendungsbereich zu beurteilen,
wenn man noch keine eigenen Überlegungen zu seiner
zukünftigen Architektur angestellt hat. 3
tes schnell überfordert sein.4 Also sind Vorkehrungen
zur Skalierbarkeit der Server durch Mehrfachinstanziierung auf verschiedenen Rechnern zu treffen. Eine dynamische Lastverteilung zwischen diesen Instanzen ist
vorzusehen.
4. „Regionalisierbarkeit“ von Klienten und Servern.
Damit die Lastverteilung selbst nicht zum Nadelöhr der
Architektur wird, muß eine Mehrfachinstanziierung der
Lastverteilung möglich sein. Dadurch können Gruppen
von Klienten durch Gruppen von Servern bedient werden.5
Zusammenfassend läßt sich sagen: Die rasante Entwicklung der Informationstechnologie eröffnet nie gekannte
technische und kommerzielle Möglichkeiten und Optionen. Aber gerade dadurch ist eine stabile und zukunftssichere Architektur von zentraler Bedeutung für jede Anwendungsentwicklung.
Abbildung 3: Aus Klienten werden Server
BEISPIELARCHITEKTUR
Viele deutsche Versicherungs- und Finanzdienstleistungsunternehmen haben in den letzten Jahren einige
Systeme mit objektorientierter Technologie in der FatClient-Architektur entwickelt. Die neuen Anforderungen
(s.o.) machen einen Neuentwurf der Architektur mit einer
stärkeren Orientierung auf Server-basierte Dienste nötig.
Dabei kann die vorhandene Zerlegung der Systeme in
Programmkomponenten das Schema der DiensteArchitektur abgeben. Folgende Probleme müssen dabei
gelöst werden:
1. Multi-User-Fähigkeit. Sämtliche Programmkomponenten sind auf einen Benutzer (Thread-of-Control)
ausgerichtet. Als Server müssen sie mehreren Klienten
Dienste erbringen können.
2. Asynchrone Einbindung. Die Klienten dieser Server
sollten nicht blockieren, solange sie auf die Diensteerbringung warten. Denn ggf. sind sie in einer Serverzentrierten Architektur selber Server für andere Kunden, die in der Wartezeit für einen Kunden Sinnvolles
für andere Kunden tun können.
3. Skalierbarkeit. Wenn viele Klienten gleichzeitig einen
Dienst benötigen, kann eine einzelne Instanz des Diens-
Die von uns gewählte Architektur, die diese Probleme
löst, ist in Abbildung 3 dargestellt. Die Abbildung zeigt
wie aus Einzelplatzdiensten zur Funktionsberechnung mit
Excel selbständige multi-user-fähige Dienste werden,
ohne daß der Code der Komponente selbst geändert werden muß:6 Die Komponenten „Funktionsklient“ und
„Funktionsdienst“ sind durch eine einfache Client/ServerZerlegung aus dem Originalcode des Fat-Client-Systems
gewonnen worden. Die OLE-Einbindung von Excel über
eine COTS-Komponente7 „OLE-Access“ für Smalltalk
konnte 1:1 übernommen werden. Multi-user-Fähigkeit
erreichen wir durch einen selbst entwickelten Warteschlangenmechanismus (Message Queueing), der die
eingehenden Nachfragen nach Funktionsberechnung
serialisiert. Der Funktionsklient ist entsprechend um einen
Mechanismus zur Erstellung und Versendung eines Funktionsaufrufs (Message Sending) erweitert worden. 8 Die
Kommunikation dieser beiden Komponenten über das
Netz wird mit Hilfe eines kommerziellen CORBA Orb’s
ermöglicht.
4
In einer Fat-Client-Architektur steht für einen Benutzer ein leistungsfähiger Arbeitsplatzrechner exklusiv zur Verfügung. Performanzprobleme auf diesen Rechnern für einen Benutzer gibt es heute kaum noch.
5
Dabei muß es egal sein, ob die Klienten- und Servergruppen disjunkt
sind oder nicht.
6
2
Ein Beispiel ist IIOP, ein Protokoll, das CORBA-Systeme verschiedener Anbieter interoperabel macht. Einige Hersteller sind schon dabei,
XML zum Austauschformat für Object Request Broker zu machen.
3
Es ist dann ebenfalls kaum möglich zu beurteilen, ob ggf. nicht integrierte oder integrierbare Technologiekomponenten für den eigenen
Bereich wirklich verzichtbar sind.
Zur Berechnung von Tarifen und anderer komplizierter Funktionen
haben wir in unsere Systeme Excel als Funktionsdienst über OLE eingebunden. Dadurch können die Fachabteilungen selbst Funktionen definieren, auf einem zentralen Server versioniert ablegen und über definierte
Prozesse in die Anwendungen einbinden.
7
COTS = Customer-of-the-shelves.
8
Das Format der Nachrichten ist in der IDL von CORBA beschrieben.
Die Messaging-Komponenten sind so gestaltet, daß Funktionsaufruf und Rückgabe des Ergebnisses asynchron
sind. Das bedeutet, daß der Funktionsklient nicht bis zur
Rückgabe des Ergebnisses blockiert und insbesondere in
der Wartezeit weitere Funktionsaufrufe absetzen kann.
 Einen Statistikdienst zur Aktualisierung der statistischen Daten bei Bestandsänderungen.
Skalierbarkeit erhalten wir dadurch, daß sich mehrere
Funktionsdienste unter einer Lastverteilung (Load Balancing) konfigurieren lassen.9 Die Lastverteilung selbst
benimmt sich den Klienten gegenüber wie ein einzelner
Funktionsdienst, verteilt jedoch den Funktionsaufruf an
den aktuell schnellsten Funktionsdienst. 10 Der Funktionsdienst liefert das Ergebnis selbst an den Klienten und
informiert den Lastverteiler über die Dauer der Berechnung. Damit aktualisiert der Lastverteiler sein statistisches Leistungsprofil zu den Funktionsdiensten.
Wie diese Architekturbeispiele zeigen, sind relativ komplizierte Mechanismen und die Beherrschung eine Reihe
von Technologien nötig, um den aktuellen Herausforderungen gerecht zu werden. Zudem sind eine Vielzahl von
Alternativen in jedem Detail möglich. Hier sind einige
Beispiele:
Im Dienst zur Lastverteilung konnten dieselben Komponenten zur Nachrichtenvermittlung wiederverwendet
werden wie im Funktionsdienst.
Mit den Mitteln von CORBA ist es möglich, mehrere
Lastverteilungsdienste zu starten und so zu einer „Regionalisierung“ der Klienten und Server zu kommen.11 Das
ist insbesondere dann nötig, wenn die Lastverteilung
selbst bei einer sehr großen Anzahl von Klienten und
Servern zum Nadelöhr der Architektur wird.
Alle Komponenten in dieser Systemarchitektur sind wiederverwendbar. So werden wir auf dieselbe Weise weitere
Programmkomponenten zu Diensten umbauen, u. a.:
 Einen Persistenzdienst zur Speicherung von Objekten
in relationalen Datenbanken.
 Einen Transaktionsdienst zur Verwaltung langer Transaktionen.
 Einen Sperrendienst zur Verwaltung pessimistischer
und optimistischer Synchronisationsmechanismen.
 Einen Benutzer- und Rechtedienst zur Prüfung der
Bearbeitungsrechte.
 Eine Textkomposition zur Erzeugung, Drucken, Archivieren und Versenden von RTF-Dateien aus sogenannten Steuerdateien, i.e. Textbausteinlisten mit Variablenbelegungen.
 Einen Auftragsdienst zur Erstellung und Zustellung von
Aufträgen im existierenden Workflow-System.
 Einen Abrechnungsdienst zum Erzeugen und Verbuchen von Beitragsrechnungen.
 Einen Führungs- und Beteiligungsdienst zum Erzeugen
und Abrechnen von Abrechnungen in Versicherungskonsortien.
9
Es ist möglich, weitere Funktionsdienste hochzufahren und in eine
Lastverteilung einzubringen, während das System läuft. Auch das Herunterfahren ist zur Laufzeit möglich.
10
In einem Szenario mit mehreren Funktionsdiensten können die Berechnungen für einen Klienten wesentlich schneller werden als in der
Fat-Client-Version, wenn dieser viele unabhängige Funktionsaufrufe
absetzt, deren Abarbeitung durch die Lastverteilung parallelisiert wird.
11
Ein Funktionsdienst kann so konfiguriert werden, daß er einem oder
mehreren Lastverteilern zur Verfügung steht.
Wir werden so schrittweise die gesamte KomponentenZerlegung unserer Programme in eine Dienstestruktur
umbauen.
 CORBA wird hier im wesentlichen zur Kommunikation
eingesetzt. Dazu lassen sich natürlich auch RMI oder
RPC’s pur verwenden.
 Das Thema Lastverteilung könnte durch Einbindung
eines kommerziellen Transaktionsdienstes für CORBA
angegangen werden.
 Die Nachrichtendienste könnten auch durch marktgängige Produkte ersetzt werden.
 Das Thema Persistenz kann durch die Einbindung einer
objektorientierten Datenbank erledigt werden.
Welche Entscheidungen im Einzelfall getroffen werden,
hängt ganz wesentlich von (1) der Gesamtschau auf die
zukünftige Systemlandschaft des jeweiligen Anwenders
(Architektur), (2) den Wünschen zur Integration von
Altanwendungen und (3) dem vorhandenen und herstellbaren Know-how in der Entwicklung ab.
Im Rest dieses Papiers schildern wir unsere Erfahrungen
und Ergebnisse zu diesen Themen und arbeiten die hauptsächlichen Fragestellungen heraus, die beim Aufbau einer
neuen Architektur beachtet werden müssen.
ARCHITEKTUREBENEN
Die oben dargestellte
Beispielarchitektur löst
vorrangig systemtechnische Probleme, wie
Mehrbenutzerfähigkeit,
Verteilung und Skalierbarkeit. Wir bezeichnen
sie deshalb als Systemarchitektur.
Davon
lassen sich Architekturen auf anderen Ebenen
unterscheiden,
vgl.
Abbildung 4: Architekturebenen
Abbildung 4. In diesem
Abschnitt wollen wir
alle Arten von Architekturen kurz charakterisieren und
von einander abgrenzen.
Die Technische Architektur beschreibt die Prinzipien und
Regeln, wie im Unternehmen Rechensysteme und Netze
sowie die grundlegenden Betriebs- und Kommunikationsmittel, auf denen die Anwendungsentwicklung und die
Produktion beruhen, aufgebaut sind und eingesetzt werden. Neben der reinen Hardware umfaßt diese Architektur
auch die eingesetzten Betriebssysteme, Datenbanksysteme, Netzprotokolle, Sicherheitsmechanismen, Verteilungs- und Kommunikationsplattformen sowie Verfahren
zur Softwareinstallation und -freigabe.
Die Systemarchitektur beschreibt die Prinzipien und Regeln, mit denen im Unternehmen systemtechnische Fragestellungen gelöst werden. Dazu gehören u. a.: Technisches Objektmodell, Verteilung, Persistenz, Transaktionssicherheit, Sperren, Nachrichten, Ereignisbehandlung,
Skalierbarkeit, Mehrbenutzerbetrieb, Rechteverwaltung,
Druck, Versand, Lastverteilung, Arbeitsverteilung, Lange
Transaktionen, Prozessmanagement, Fehlerbehandlung,
technische Datenformate (wie etwa XML oder RTF).
Die Anwendungsarchitektur beschreibt die Prinzipien und
Regeln, mit denen grundsätzliche fachliche Fragestellungen in den Anwendungssystemen gelöst werden. Dazu
gehören u. a.: Fachliches Objekt- oder Datenmodell, Zeitreihen und Versionsmanagement, Produktsteuerung, fachlich begründete Anwendungskomponenten, fachliche
Schnittstellen zwischen den Komponenten, Trennung der
Management- von der Ressourcenebene, Koordination
und Kooperation innerhalb des Unternehmens, Koordination und Kooperation mit anderen Unternehmen, fachliche Standards (wie etwa genormte fachliche Datenformate, z. B. das GDV-Format der Deutschen Versicherungswirtschaft).
Die Fachliche Architektur beschreibt die Geschäftsregeln,
Standards und Prinzipien des Aufbaus und der Abläufe in
einem Unternehmen, ohne Beschränkungen der konkret
eingesetzten Technik zu berücksichtigen (Annahme Idealer Technik).
Wie wir bereits in Abbildung 4 angedeutet haben, sind die
Architekturen auf den unterschiedlichen Ebenen nicht
unabhängig. Von oben nach unten definieren sie die Anforderungen und Probleme, die auf der nächst niedrigeren
Ebene gelöst werden müssen. Und umgekehrt definieren
sie von unten nach oben die Angebote, die auf der nächst
höheren Ebene genutzt werden können.
Ein stringentes „Top-down“-Szenarion sieht etwa so aus:
Die fachliche Architektur definiert durch eine WorkflowAnalyse sämtliche Prozesse so detailliert, daß eine Entscheidung möglich ist, welche Aktivitäten in den Geschäftsprozessen wie durch klar umrissene „Use-Cases“12
mit DV unterstützt werden können.
Die Anwendungsarchitektur wird durch eine objektorientierte Analyse (OOA) aus diesen „Use cases“ gewonnen.
Dazu wird ermittelt, welche „Use Cases“ gemeinsame
Objektstrukturen bearbeiten. Das führt zu einem fachlichen Objektmodell, zu einer Zusammenfassung der „Use
cases“ um gemeinsame Objekte zu fachlichen Komponenten und über die Beschreibung der Objektinteraktionen zu
einer Festlegung der fachlichen Schnittstellen. Neben
dieser qualitativen Beschreibung werden die Anforderungen nach Durchsatz und Sicherheit aus einer Betrachtung
der Häufigkeit der einzelnen „Use Cases“ gewonnen.
12
Im Sinne der UML (Unified Modelling Language)
Auf der Grundlage der Anwendungsarchitektur folgt die
Konzeption der Systemarchitektur, die nötig ist, um die
geforderten „Use Cases“ in der geforderten Menge und
Sicherheit abwickeln zu können. Das Ergebnis ist eine
Systemarchitektur, wie sie in Auszügen im Abschnitt
Beispielarchitektur beschrieben ist. Das fertige SoftwareSystem entsteht, wenn die einzelnen Anwendungskomponenten in der Systemarchitektur realisiert werden.
Das System wird schließlich auf einer HardwareLandschaft in Produktion gebracht, deren Technische
Architektur und Merkmale sich aus den qualitativen und
quantitativen Anforderungen der Systemarchitektur ergeben.
In der Praxis ist diese Vorgehensweise nicht möglich.
Denn heute ist ein Neubeginn „auf der grünen Wiese“
nicht praktikabel. Dazu sind zu viele Systeme bereits im
Einsatz und eine vollständige Migration in eine neue
Architektur in kurzer Zeit aus Kostengründen nicht
machbar. Deswegen finden in den Betrieben viele Veränderungen „Bottom-up“ statt: Neue, schnellere und preiswertere Rechentechnik wird eingesetzt, wo immer möglich. Um die neuen Optionen dieser Technik zu nutzen,
sucht man nach Systemarchitekturen, in denen die alten
Systeme und Neuentwicklungen koexistieren können.
Hier bekommt die Systemarchitektur einen besonders
hohen Stellenwert, Fragen der Anwendungsarchitektur
werden zurückgestellt, geht es doch um den Einsatz bereits vorhandener Anwendungen. Auf der fachlichen
Ebene wird nichts verändert.
Wir denken, daß langfristig weder der „Top-down“- noch
der „Bottom-up“-Ansatz Früchte tragen kann. Gegen den
ersten spricht die zu schnelle Entwicklung der Technologie. Gegen den zweiten sprechen die Altanwendungen,
die auch nach dem zweiten und dritten technischen „Face
Lifting“ ihr Alter und ihre Mängel nicht verbergen können.
Wir schlagen eine Art „inside-out“-Vorgehen vor. Durch
neue Systemarchitekturen müssen konsequent die fachlichen Architekturmängel der Anwendungen beseitigt werden und durch neue Überlegungen zur Anwendungsarchitektur müssen die existierenden Defizite in der Systemtechnik aufgezeigt und beseitigt werden. Dadurch erhält
man die gewünschten neuen Handlungs- und Entwicklungsmöglichkeit sowohl auf der fachlichen Seite als auch
bei der Erneuerung der Rechentechnik.
Ins Zentrum der Entwicklung sollte also die Erneuerung
der gesamten Software-Architektur gestellt werden. Unter
diesem Begriff fassen wir die Anwendungs- und die Systemarchitektur zusammen. Einige der Hauptprobleme, die
dabei zu lösen sind, diskutieren wir in den folgenden
beiden Abschnitten.
ANWENDUNGSARCHITEKTUR
Der Definition der richtigen Anwendungen in der richtigen Architektur kommt heute besondere Bedeutung zu.
Denn der Bedarf nach Integration der einzelnen Anwendungen zu einer Plattform „aus einem Guß“, auf der sämtliche Geschäftsprozesse einheitlich und ohne Brüche
abgewickelt werden können, steigt weiter an. 13
Abbildung 5 zeigt das Schema einer solchen Anwendungsarchitektur am Beispiel einer Versicherungsanwendung.
Hier wollen wir anhand von Beispielen einige Themen
diskutieren, die besondere Einfluß auf die Gestaltung der
Anwendungsarchitektur insgesamt haben:
(1) Erweiterbarkeit.
(2) Integration von Standardlösungen und „Legacy Systems“.
(3) Integration in Standardlösungen.
(4) E-Business.
Abbildung 5: Produktzentrierte Anwendungsarchitektur
(1) Erweiterbarkeit. Moderne Anwendungen sollen
flexibler werden. Möglichst ohne Programmieraufwand
sollen neue Produkte in den Systemen zur Verarbeitung
bereitgestellt werden können.14 Dafür reichen die klassischen Mittel der Anpassung über Einstellungen in Tabellen15 nicht mehr.
Im Zentrum steht das Paar Produkt/Vertrag. Die Beziehung zwischen diesen beiden Objekten entspricht einer
Klasse/Instanz-Beziehung aus der objektorientierten Modellierung. Das Produkt definiert den Aufbau und das
Verhalten jedes als Instanz dieses Produkts ausgefertigten
Vertrages.
Ein Höchstmaß an Flexibilität wird erreicht, wenn das
Objektmodell, daß den Anwendungen zugrunde liegt, zur
direkten Manipulation offengelegt wird. In zukünftigen
produktgetriebenen Systemen wird das der Fall sein. Die
Fachabteilungen können dann selbst die Attribut- und
Aggregationsstruktur der Objekte definieren, Spezialisierungshierarchien aufbauen und verändern, eigenständig
Funktionen (über Excel, s.o.) definieren und integrieren
sowie den Anschluß sämtlicher weiter verarbeitender
Systeme konfigurieren. Eine solche Konzeption hat weitreichende Konsequenzen für die Anwendungsarchitektur:
Große Teile des Verhaltens eines Vertrages werden durch
seine „Nachverarbeitung“ in den umliegenden Systemen,
wie etwa „Schadenbearbeitung“ oder „Statistik“ bestimmt. Damit auch hier die Produktsteuerung zum Tragen kommt, haben wir die Anbindung dieser Systeme
über das „Model/View-Pattern“ konzipiert. Produkt/Vertrag ist das Modell, daß aus verschieden Sichten
(View) betrachtet und weiterverarbeitet wird: Z. B. legt
das Produkt fest, wie das Prozeßschema zur „vorläufigen
Deckungszusage (klassisch die Doppelkarte in der Autoversicherung)“ aussieht und zwar unter Nutzung einer
Definitionskomponente für Prozesse aus dem WorkflowSystem. Sobald ein Vertrag angelegt wird, muß die Workflow-Komponente für die entsprechende Abwicklung des
Prozesses sorgen. Das Klasse/Instanz-Muster auf der
Modellseite spiegelt sich im „Process View“ über das
Klasse/Instanz-Paar „Prozeßschema/Prozeß“ wieder.
 Neue DV-gestützte Arbeitsplätze zur Objekt- und Produktentwicklung entstehen in den Fachabteilungen.
 Dadurch entstehen neue Geschäftsprozesse und Organisationsstrukturen.
 Alle vorhandenen Systeme müssen an die neue Flexibilität angepaßt werden.
 Durch den generischen Ansatz stecken die Fachlichen
Aspekte nicht mehr in den Systemen, sondern werden
erst durch die fachlichen Objekte und ihr Verhalten auf
der Systemplattform definiert.
Abbildung 6 zeigt das grundsätzliche Muster, wie in einer
weitgehend produktgetriebenen Anwendungsarchitektur
externe Komponenten und Systeme eingebunden werden.
 Typische Prozesse der Software-Entwicklung, wie Test,
Freigabe und Release-Management von neuen Versionen müssen unterstützt werden.
13
Es gibt wenig vorgefertigte Branchenlösungen. Vorstücke wie etwa
die Versicherungsanwendungsarchitektur VAA des Gesamtverbandes
der Deutschen Versicherungswirtschaft GDV werden auf der Ebene der
Fachlichen Architektur konkret, bleiben aber auf den unteren Ebenen
sehr skizzenhaft. Eine durchgängige Anwendungsarchitektur, in der z.
B. DV-Komponenten unterschiedlicher Hersteller als Lösung unterschiedlicher fachlicher Fragestellungen problemlos kombiniert und
integriert werden können, ist uns nicht bekannt.
14
Insbesondere dort, wo Produkte immateriell sind, z. B. bei Banken
und Versicherungen, nimmt diese Anforderung zu.
15
Tabellensteuerung wie wir sie in vielen Standardlösungen finden.
Abbildung 6: Architektureinfluß auf die Komponenten
Sie zeigt die Kombination des Klasse/Instanz-Musters mit
dem „Model/View-Pattern“, die zur durchgängigen Funktionsfähigkeit der Produktsteuerung im gesamten DVSystem durchgehalten werden muß. Es wird deutlich, daß
diese fachlich begründete Architekturentscheidung weitreichende Konsequenzen z. B. bei der Auswahl der einzusetzenden Workflow-Komponente oder bei der Art und
Weise wie „Legacy Systems“ „angeschlossen“ werden,
hat.
(2) Integration von Standardlösungen und „Legacy
Systems“. Die grundlegenden Entscheidungen zur Anwendungsarchitektur, wie z. B. im vorangegangenen
Abschnitt beschrieben, müssen bereits festliegen, wenn
man die Integration von „Fremdsystemen“ konzipiert.
(Unter dem Begriff „Fremdsysteme“ fassen wir Standardlösungen und „Legacy Systems“ zusammen, da sie sich
im Verhältnis zu einer Anwendungsarchitektur ähnlich
verhalten). Nur dann läßt sich entscheiden, ob die angebotenen Schnittstellen und Zugänge fachlich ausreichen oder
adaptiert werden können.
Wenn Daten mit den Fremdsystemen ausgetauscht werden sollen, empfiehlt es sich, das dafür zu verwendende
Typsystem16 unternehmensweit festzulegen. Denn Fremdsysteme bringen hier häufig unerwartete Beschränkungen
mit sich. Hier einige Beispiele:
 Ganze Zahlen in Excel sind nur 15 Stellen genau. Für
Währungsangaben reicht das nicht immer aus.
 Währungsfelder in „Legacy Systems“ sind häufig aus
Platzmangel in Tausend Währungseinheiten angegeben.
Rechnungen mit solchen Feldern führen schnell zu Ungenauigkeiten.
 Datumsformate sind in den verschiedenen Systemen
i.d.R. verschieden und bedürfen der Konvertierung
beim Transfer.
Im Falle von Legacy-Anwendungen empfiehlt sich unseres Erachtens nur die Client/Server-Zerlegung17 des Systems, die unveränderte Verwendung des Server-Teils und
die Entwicklung eines neuen graphischen Clienten im
Rahmen der anwendungsübergreifenden Oberflächenphilosophie.
Standardlösungen sind dann unproblematisch, wenn ihre
Oberflächen nur für den Definitionsteil an wenigen Arbeitsplätzen nötig sind, vgl. Abbildung 6. So kann z. B.
der Applikationsteil von Excel, i.e. die eigentliche Nutzung der definierten Funktionen, ohne sichtbare Oberfläche eingebunden werden.
(3) Integration in Standardlösungen. Bestimmte Standardsysteme sind weniger Komponenten, sondern selbst
Architekturen. Dazu gehören Workflow-ManagementSysteme, Groupware-Systeme und manche Standardanwendungssysteme wie SAP R/3. Mit diesen Systemen
importiert man eine Architektur, in die man seine Anwendungen integrieren kann. Gemeinsames Merkmal
dieser Systeme ist die hohe Erweiterbarkeit bis hin zu
einer eigenen Programmiersprache und Programmierumgebung, mit der sich eigene Komponenten realisieren und
integrieren lassen.
Der Griff zu solchen vorfabrizierten Architekturen entlastet von manch eigener Anstrengung. Bedeutet aber auch
das Einlassen auf die Architekturvorstellungen eines
Herstellers. Die Adäquatheit dieser Architekturen für die
eigenen Belange kann man z. B. dadurch prüfen, ob sich
die oben skizzierte produktgetriebene Philosophie mit der
Standardlösung umsetzen läßt.
Die Integration der Benutzeroberflächen von Fremdsystemen mit den Oberflächen der eigenen Systeme stellt ein
weiteres Problem dar, daß im Rahmen der Anwendungsarchitektur gelöst werden muß. Medienbrüche, z. B. Maskenemulationen der Altanwendungen neben wirklichen
Graphischen Oberflächen der neuen Anwendungen, sind
zu vermeiden.
(4) E-Business. Der Einfluß von E-Business auf die Anwendungsarchitektur ist eher gering, obwohl das Thema
derzeit einer der Motoren bei der Umgestaltung der Anwendungslandschaften ist. Modern aufgestellte Unternehmen mit einer offenen, Server-orientierten, hoch skalierbaren Systemarchitektur, haben wenig Schwierigkeiten ihre Systeme in das weltweite elektronische Geschäft
einzubinden.
Auch hier verhalten sich „Legacy Systems“ und Standardlösungen ähnlich. Reine GUI-fizierungen der Masken von
Altsystemen unter Windows bringen meist nicht die gewünschte Integration in ein Gesamtkonzept. Aber auch
die Philosophie bestimmter Standardlösungen wie etwa
die Oberflächen älterer Lotus Notes Versionen sind unter
Windows sehr gewöhnungsbedürftig.
Auf der fachlichen Seite bedeutet E-Business zum einen
erhöhte Anforderungen an die Einfachheit der angebotenen Produkte sowie die Klarheit und Attraktivität der
Darstellung dieser Produkte an der Oberfläche. Denn der
Kunde selbst bedient die Systeme und kann nicht auf die
Hilfe eines kompetenten Sachbearbeiters zurückgreifen.
16
In unserer Architektur haben wir z. B. als Basistypen Text (unbegrenzt
in RTF), String (255), Integer (15 Stellen), Datum/Zeit und sämtliche
Aufzählungstypen im vorhandenen Tabellenverwaltungssystem vorgesehen. Über den Basistypen lassen wir freie Konstruktionen von „Records“ und „Variants“ zu, d. h.: Rekursive Datentypen über „und“ und
„oder“. Auf der Grundlage dieses Typsystems konnten wir eine regelbasierte Standard-View-Komponente zum Transfer von Daten aus dem
Produkt/Objektmodell in die Fremdsysteme realisieren (vgl. Abbildung
6). Einzige Voraussetzung dafür ist, daß sich die an der Schnittstelle zu
einem Fremdsystem erwarteten Datenformate im Typsystem darstellen
lassen. Dazu lassen sich für jedes Fremdsystem spezifische „Wrapper“
schreiben, die die nötigen Anpassungen und Konvertierungen vornehmen.
Im Bereich der Unternehmensvernetzung erzwingt es zum
anderen, die konsequente Nutzung standardisierter Formate zum Datenaustausch und die Einhaltung unternehmensübergreifender Abläufe.
*****
Anwendungsarchitektur in dem hier verwendeten Sinn als
Zerlegung einer DV-Unterstützung in fachlich begründete
Komponenten und die Definition der fachlichen Prinzipien zum Aufbau und der Interaktion dieser Komponenten ist für viele Unternehmen ein neues Thema. Als Vorgabe zur Auswahl der richtigen Systemarchitektur – so
17
Separierung der Maskensteuerung von der Datenhaltung und Anwendungslogik.
hoffen wir in diesem Abschnitt deutlich gemacht zu haben
– ist die Auseinandersetzung mit diesem Thema aber
unerläßlich.
SYSTEMARCHITEKTUR
Wie wir oben bereits dargestellt haben, entwickeln sich
die Systemarchitekturen derzeit weg von „Fat-server“und „Fat-Client“-Lösungen hin zu Plattformen für verteilte Dienste.
Aus der Vielzahl der möglichen Wege zu einer solchen
Plattform, haben wir einen ausgewählt, der mit wenigen
kommerziellen Produkten18 auskommt und zu dem unsere
eigenen Lösungen optimal passen.
Vor dem Hintergrund der Erfahrungen, die wir bei der
Auswahl der Produkte und beim Aufbau der Architektur
gemacht haben, wollen wir in diesem Abschnitt auf die
Themen hinweisen, die beim Aufbau einer wie auch immer gearteten Diensteplattform von zentraler Bedeutung
sind:
(1) Beherrschung der Heterogenität,
(2) Übergreifendes Transaktionsmodell,
(3) Integration von Fremdsystemen,
(4) Adäquate Anwendungsarchitektur.
(1) Beherrschung der Heterogenität. Heterogenität ist
ein zentrales Thema, mit dem man durch die neuen Architekturen konfrontiert wird. Betrachten sie z. B. das Szenario in Abbildung 7.
Unsere Lösung für dieses Problem ist die „Flucht“ auf die
Meta-Ebene. Da wir ein Objektmodell zur freien Definition von fachlichen Objekten auf der Ebene der Anwendungsarchitektur zur Verfügung stellen (siehe letzten
Abschnitt), kennen wir die konkreten Objektstrukturen im
Endsystem nicht. Wir müssen also keine konkreten Objekte in die unterschiedlichen Formate bringen, sondern
das generische Objektmodell der Anwendungsarchitektur
auf die Objekt- und Datenmodelle der verschiedenen
Systeme abbilden. Die Umwandlung der Formate ineinander haben wir als Dienste gekapselt und so für die
Anwendung transparent gemacht. Nachdem das Objektmodell der Anwendungsarchitektur fixiert war, stellte die
Vielzahl der Formate kein Problem mehr dar.19
Die Herstellung solcher Lösungen zur Vermeidung oder
Überwindung von Heterogenität nimmt einen großen Teil
der Zeit zum Aufbau von Systemarchitekturen in Anspruch, zumal dafür Sorge getragen werden muß, daß die
benötigte Performanz durch solch einen Meta-Ansatz
nicht auf der Strecke bleibt. 20
(2) Übergreifendes Transaktionsmodell. Verteilung
bedingt Koordination. Ein zentrales Thema dabei sind
Dienste-übergreifenden Transaktionen. Wenn nicht nur
Datenbankaktualisierungen sondern auch der Druck und
Versand von Dokumenten aus MS-Word, die Berechnung
abgeleiteter Daten mit Excel, die Aktualisierung von
Terminen in einer Software zur Bürokommunikation und
die Versorgung von Altsystemen in solche Transaktionen
einbezogen werden muß, sind die kommerziellen Lösungen rar.21 Um die Sicherheit der Verarbeitung genau so
wie in den „Fat-Server“- und „Fat-Client“-Architekturen
bereitzustellen, muß ein Transaktionskonzept im Rahmen
der Systemarchitektur von der Anwendungsentwicklung
selbst entworfen und eingebunden werden.
Unsere Lösung sieht asynchrone Transaktionsobjekte für
lange Transaktionen (vgl. Abbildung 8) vor, die bis an die
Oberfläche der Benutzer sichtbar sind und setzt eine vollständig historische Führung der Datenbestände voraus:
Abbildung 7: Das Dasein der Objekte
Hier sind alle Metamorphosen dargestellt, die ein fachliches Objekt in unserem Zielsystem von der Datenbank bis
zur Oberfläche durchmachen muß, bevor es dort bearbeitet werden kann. Das heißt: Die fachlichen Objekte, die in
der UML entworfen und in Visual Age for Smalltalk
(VA) realisiert sind, existieren im System aus verschiedenen technischen Gründen in mindestens 10 unterschiedlichen technischen Formaten.
Jede Änderung am Objektmodell hat im schlimmsten Fall
eine Anpassung all dieser Formate zur Folge. Der Entwicklungszyklus wird dadurch natürlich entscheidend
verlängert, das angestrebte Ziel erhöhter Flexibilität wird
konterkariert.
18
Wir benötigen einen CORBA-Orb und die Server-Komponenten des
bei uns eingesetzten Visual Age for Smalltalk.
Jede Bestandsveränderung wird im Rahmen einer offenen Transaktion zunächst in den einzelnen Diensten als
lokale (DB-)Transaktion ausgeführt und mit einer logischen Sperre (Verweis auf die Transaktion) versehen.
Offene Transaktionen werden durch ein Bearbeitungsdatum im Jahr 9999 gekennzeichnet. Dadurch sind diese
Änderungen außerhalb der Transaktion noch nicht sichtbar. Das Commit für eine Lange Transaktion geschieht
explizit durch den Benutzer. Dann werden asynchrone
alle nötigen Folgeaktivitäten in den einzelnen Diensten
veranlaßt, zunächst ebenfalls durch die offene Transaktion gesperrt und zum Schluß die logischen Sperren
19
Die Vielzahl der verschiedenen teilweise nicht kompatiblen Objektmodelle sind ein wesentlicher Hemmschuh für die weitere schnelle
Durchsetzung der Objekttechnologie.
20
Unser Beispiel macht zudem deutlich, hier ganz neue Ansprüche an
die Qualifikation und die Fähigkeiten der Anwendungsentwicklung
gestellt werden.
21
Zudem sind die Zwei-Phasen-Commit-Transaktionen, die i.d.R.
angeboten werden, nicht performant genug.
dadurch entfernt, daß das Bearbeitungsdatum der Transaktion mit dem aktuellen Datum aktualisiert wird. Solch
eine Transaktion ist geschlossen. Da alle Dienste die
Bearbeitungsdaten für ihre Bestände von denen der
Transaktionen ableiten, werden so alle Änderungen
gleichzeitig sichtbar.22
Das bedeutet, daß die Erneuerung der technischen und der
fachlichen Architekturen in der Anwendungsentwicklung
Hand in Hand vorangehen muß, damit die neue Technologie ihre Vorteile im „Business“ entfalten und ein „Business Reengineering“ technisch adäquat umgesetzt werden
kann.
RESÜMEE
Abbildung 8: Lange Transaktionen
Die Komplexität der Lösung macht deutlich, wie schwierig die Bereitstellung eines befriedigenden und performanten Transaktionskonzepts in einer Verteilten Welt ist
und welche umfangreichen Voraussetzungen dafür nötig
sind, hier die historische Verwaltung der Daten.23
(3) Integration von Fremdsystemen. Die Integration
von Legacy Systems und Standardsoftware in eine Systemarchitektur ist ein meist mühevoller Prozeß. Schon
allein die Teilnahme dieser Systeme an Transaktionsprozessen, wie sie oben beschrieben wurden, erfordert umfangreiche „Wrapper“ um die Anwendungen, die die
geforderten Protokolle realisieren und sämtliche Fehlersituationen erkennen und geeignet signalisieren. Neben den
fehlenden Schnittstellen zur Einbindung in Transaktionen
weisen alte wie neue Fremdsysteme folgende Schwächen
auf, die bei der Integration beseitigt werden müssen: Unzureichende Datenformate, unzureichende Objektmodelle,
unzureichende Ereignismodelle, unzureichende Schnittstellen und die Präsupposition bestimmter Architekturen.
Die fortschreitende Durchdringung immer weiterer Arbeitsbereiche mit Informartions- und Kommunikationstechnologie macht in vielen Unternehmen die Reform der
grundsätzlichen System- und Anwendungsarchitekturen
nötig. Die eingefahrenen Pfade der Anwendungsentwicklung auf einem Zentralrechner (Fat-Server) oder auf dem
Arbeitsplatzrechner (Fat-Client) müssen dabei verlassen
werden. Insbesondere das Internet zusammen mit den
Mechanismen des E-Business zwingt dazu, beide Architekturen in einer Plattform für verteilte Dienste zu integrieren.
Dafür sind noch keine fertigen Standardarchitekturen
ausgearbeitet. Den Abteilungen zur Anwendungsentwicklung bleibt die Wahl, entweder auf Plattformen großer
Anbieter zurückzugreifen oder selbst einzelne Technologien in eine eigene Plattform zu integrieren. 24
Nach wie vor geht es dabei um die klassischen Probleme
der DV, z. B. Performanz, Skalierbarkeit, Transaktionssicherheit, das richtige Objektmodell, Evolution von Altanwendungen und Migration von alten Datenbeständen.
Diese alten Probleme in immer neuen Architekturen für
das Unternehmen zu lösen, wird die vorrangige Aufgabe
der Anwendungsentwicklung in den nächsten Jahren sein.
Ein Ende der Arbeit und der intellektuellen Herausforderungen ist hier noch lange nicht in Sicht.
(4) Adäquate Anwendungsarchitektur. Die Erneuerung
der Systemarchitektur ist nur dann sinnvoll, wenn die
Vorteile durch eine adäquate Anwendungsarchitektur
auch genutzt werden. Eine Systemarchitektur als Plattform für Verteilte Dienste macht nur Sinn, wenn auch
wirklich Dienste zu verteilen sind, wenn also die Anwendungsarchitektur in Form von interagierenden fachlichen
Dienste beschrieben ist.
Umgekehrt müssen, wie wir oben gesehen haben, bestimmte Eigenschaften der Systemarchitektur in den Anwendungen selbst sichtbar werden, um den sicheren Umgang mit solch einer DV-Landschaft gewährleisten zu
können.
22
Zur Beschleunigung des Zugriffs werden diese Bearbeitungsdaten
durch einen regelmäßig laufenden Denormalisierungs-Batch direkt in
die Bestände kopiert.
23
Historische Datenhaltung heißt: keine Aktualisierung und kein Löschen von Daten.
24
In beiden Fällen ist breiteres und tieferes Know-how in modernen ITtechniken nötig.