Praktisch ergeben sich bei sehr unterschiedlichen Projekten doch allgemeingültige Gesichtspunkte für OOP. Einige davon seien hier am Beispiel der Entwicklung einer Produkt -Baustein-Architektur für Finanzdienstleister gezeigt. Pilotkunde war eine Leasinggesellschaft.
Die geistig dem Taylorismus Verhafteten sollten ab hier nicht mehr weiterlesen. Sie werden sich fragen: Was hat denn ein Sektor wie Leasing mit anderen wie dem Wertpapiergeschäft etc. gemeinsam? Die Projektergebnisse, auf die sich dieser Bericht bezieht, sind aber zum großen Teil auch für generalisierten Finanzdienstleister (Bank, Versicherung, Finanzservice-Unternehmen, Informationsanbieter) verwendbar.
Die Beteiligten erarbeiteten ein umfangreiches Objektklassenmodell sowie einen darauf basierenden Prototyp für Leasing und Finanzierung, der bereits Konstrukte enthält, die gerade auch für Finanzinnovationen nutzbar sind. Wesentliche Zielsetzung war es, die Produkt- und Konditionengestaltung in zweifacher Hinsicht flexibler zu gestalten. Fachlich sollte es möglich werden, Produkte und Komponenten spartenübergreifend neu zu kombinieren; DV-technisch ging es um das ingenieurmäßige Kreieren neuer Produkte einschließlich Kalkulation und Abwicklung, und dies mit einem jeweiligen Entwicklungsaufwand von nur wenigen Personentagen.
Diese Planung mag sich für viele Entwicklungen im Finanzdienstleistungs-Bereich utopisch anhören, verschlingt doch heute ein neues Produkt normalerweise einige zig Personenjahre, bis die entsprechende DV-Unterstützung realisiert ist. Selbst kleinere Anpassungen oder die Kombination bereits existierender Finanzdienstleistungs-Produkte sind mit den heute gängigen Methoden noch recht aufwendig.
Ein Gedankenexperiment verdeutlicht, daß die Zielsetzung dennoch erreichbar sein könnte. Definiert man als Grundmuster den Tausch einer Einmalzahlung gegen einen Zahlungsstrom und als Variationen davon zum Beispiel Hypothekenkredit, Anschaffungsdarlehen, Termingeld und Kauf einer Anleihe, so lassen sich drei dieser Grundmuster auf sechs verschiedene Arten reihen: a-b-c, a-c-b, b-a-c, b-c-a, c-a-b, c-b-a. Hat aber jeder Typ fünf Variationen, so daß also 15 Elemente kombiniert werden können, dann gibt es schon 1,3 Billionen verschiedene Reihungen aller Typen.
Wenn es demnach gelingt, aus der Vielzahl der heutigen und zukünftigen Produkte wenige Muster herauszuarbeiten, allgemeingültig darzustellen und inklusive der Kombinationslogik in Software umzusetzen, so sind hier sehr große Einsparungen zu erwarten.
Doch zurück vom Gedankenexperiment zum Projekt. Aufgabe war es, das heutige Spektrum an Finanzdienstleistungs-Produkten auf möglichst einfache Grundmuster sowie deren Kompositionsprinzipien zu untersuchen.
Der Produktbegriff ist im Finanzbereich noch neu, so daß bisher kein einheitliches Verständnis existiert. Dennoch ist eine unternehmensweit zu fassende Definition für die analytische Betrachtung und Erarbeitung eines Modells für Produkte und Konditionen unerläßlich. Viele Sichten wie Marketing-, Vertriebs-, Controlling- und Abwicklungssicht sind in ein gemeinsames Produktverständnis zu integrieren (vgl. Abbildung l).
Mangels Produktbegriff gibt es bei Finanzdienstleistern vielfach auch keine umfassenden Produktkataloge mit detaillierter Beschreibung der Produkte für alle Sichten. Die folgenden Fragen sind für jedes Produkt umfassend zu beantworten:
- Was ist der Sinn des Produkts?
- Für wen ist das Produkt bestimmt?
- Wie unterscheiden sich Produkte ?
- Wie wird das Produkt kalkuliert?
- Welche Faktoren beeinflussen Kalkulation und Konditionengestaltung?
- Wie wird das Produkt erzeugt und vermarktet?
Ausgerüstet mit diesem Katalog und viel Abstraktions- und Bankerfahrung entstanden im Team mit den Mitarbeitern des Auftraggebers abstrakte Daten-Teilmodelle für einzelne Bausteine. Zusammen mit diversen Kombinationsmöglichkeiten ergab sich daraus das Produkt- und Konditionenmodell im Sinne eines Datenmodells nach der erweiterten Entity-Relationship-Methode. Die Abbildung aller Leasing- und Finanzprodukte einschließlich sämtlicher Attribute in das Modell sollte seine Aussagekraft testen (vgl. Abbildung 2).
Mit dem anschließenden Entwurf einer DV-Lösung, der die Flexibilität bis zur softwaretechnischen Umsetzung veranschaulichen sollte, wird zur Zeit ein demnächst verfügbarer Prototyp entwickelt. Die Umsetzung erfolgt jetzt nicht mit objektorientierten Entwicklungswerkzeugen wie C++, Eiffel, Enfin oder ähnlichem, sondern mit Hilfe eines die Datenmodellierung und strukturierte Analyse unterstützenden CASE-Tools einer 4GL und eines relationalen DB-Systems.
Der objektorientierte Ansatz fand mit Hilfe eines entsprechenden Designs Eingang in das Projekt. Vorteile zum Beispiel des Polymorphismus sind hierbei zwar nur schwer zu nutzen, jedoch lassen sich so die anderen positiven Merkmale der Objektorientierung weitgehend realisieren.
Das Modell, das in seiner Darstellung als erweitertes Entity-Relationship-Modell etwa 70 Entitäten mit Beziehungen und Attributen umfaßt, basiert im wesentlichen auf der konsequenten Anwendung der folgenden Konstruktionsprinzipien:
- Generalisierung und Spezialisierung sind sicherlich die bekanntesten objektorientierten Prinzipien und dienen der Vererbung; mit ihnen lassen sich Strukturen verallgemeinern, wie dies mit dem Tauschrecht auf Abbildung 3 dargestellt ist. Die Restwertgarantie - die Verpflichtung eines KFZ-Händlers, ein Fahrzeug zu einem festgelegten Preis bei Einhaltung einer definierten Km-Leistung zu einem bestimmten Zeitpunkt von der Leasinggesellschaft zu übernehmen - und eine Option, die an der deutschen Terminbörse gehandelt wird, lassen sich hierdurch beispielhaft generalisieren.
- Aggregation bezeichnet die Zusammenfassung von mehreren Teilen zu einem neuen Ganzen (vgl. Abbildung 4). Erkennt man, daß es sich bei einem Betrachtungsgegenstand um eine Zusammensetzung von mehreren Komponenten handelt, so lassen sich durch gegebenenfalls fortgesetzte Auflösung die sogenannten Basiskomponenten ermitteln, die dann näher zu analysieren sind. Aus ihnen lassen sich dann nicht nur die analysierten, sondern auch neue Objekte zusammenstellen. Dies ist einer der wesentlichsten Schlüssel zur Flexibilität.
- Typisierung bezeichnet in der Objektorientierung das Bilden von Metaklassen oder Klassen erster Ordnung (vgl. Abbildung 5). Dieses in der fachlichen Welt oft anzutreffende Konstrukt findet in Datenmodellen nur selten Eingang. Bisher wurden Klassen im Repository dokumentiert und komplett im Datenbankverwaltungs-System implementiert. Durch Metaklassen kann jetzt eine Klassendefinition in einem DV-System dynamisch erfolgen; zum Beispiel wird durch Anlegen eines neuen Vertragstyps als Exemplar der Metaklasse Vertratgstyp die Struktur eines neuen Vertrages definiert, und in der nächsten Minute können mit dem DV-System bereits Verträge dieses neuen Typs erfaßt werden, sofern alle benötigten Komponentenklassen bereits existieren; eine solche Möglichkeit ist im entwickelten Prototyp bereits gegeben.
Die Reduktion der Entwicklungsaufwände für neue Produkte um mindestens eine Zehnerpotenz ist durch konsequente Umsetzung des Metaklassen-Konzeptes in greifbare Nähe gerückt.
Das vorgestellte Produkt-Baustein-Modell deckt auf breiter Ebene alle Bereiche eines Unternehmensdatenmodells ab. Die wesentlichen Entitäten seien hier ohne weitere Erläuterung aufgezählt:
Vertragstyp, Produkttyp, Handelsobjekttyp, Vorgangstyp, Konditionstyp, Preistyp, Vorgangskonditionstyp, Vertrag, Handelsobjekt, Vorgang, Kondition, Preis, Vorgangskondition.
Für alle genannten gibt es so wohl weitere Spezialisierungen als auch die Möglichkeit der weiteren Aggregation.
Bereits während der durchgeführten Modellierungsarbeiten ließen sich aufgrund der intensiven Verfolgung des Bausteinprinzips für das Leasing- und Finanzierungsgeschäft neue Finanzdienstleistungs-Produkte vom Modellierungsteam kreieren, die für die Fachabteilung revolutionären Charakter haben.
Wo, bitteschön, gibt es bereits Leasingangebote mit variablem Zinssatz respektive Zinsbegrenzung nach oben und unten? Marketing-Experten sollten hellhörig werden.
Es eröffnen sich somit neue kreative Möglichkeiten für die Produktgestaltung. Sogar kundenspezifische Individualprodukte sind ohne weiteres mit voller DV-Unterstützung möglich.
Mit der Verfügbarkeit von Produktbausteinen als Softwarechips werden in Zukunft nur noch wenige Entwickler und Programmierer benötigt. Neuentwicklungen erledigt in dieser neuen objektorientierten Welt ein Produktingenieur nach den Vorstellungen der Marketing-Abteilung in kürzester Zeit.