Das Prometheus-Konsortium und die konsortiale Software-Entwicklung
){kind=small}
Prometheus Foundation
Die geplante IT-Architektur
Das IT-Konzept
Fünf IT-Firmen wurden im Vorfeld der Gründung damit beauftragt, ein grobes Konzept der zu erstellenden Software zu erarbeiten. Sie machten es sich zum wesentlichsten Ziel, eine breite Akzeptanz der Software zu erreichen. Die vielen unterschiedlichen Schnittstellen zwischen den Parteien sollen durch eine einheitliche Schnittstelle ersetzt werden.
Einheitliche Schnittstellen sollten mit offenen Standards einhergehen bzw. diese nutzen, wo immer es möglich ist. Für den Bereich der Versicherungen existieren solche Standards bereits. Die Brancheninitiative Prozessoptimierung (BiPRO), ein Konsortium von über hundert Unternehmen, definiert Standards für den Datenaustausch zwischen Versicherungen, Maklern und Dienstleistern in deren Umfeld. Diese Standards werden als Public Domain bereitgestellt, jedoch mit einer interessanten Komplikation. Vor der Veröffentlichung muss nämlich die Tauglichkeit jedes Standards mit einer Referenzimplementation nachgewiesen werden, diese ist jedoch in vielen Fällen nicht frei. Das erschwert es der Prometheus Foundation, an neuen Standards mitzuwirken. In Arbeit befindliche Standards kann sie nicht implementieren, weil die Spezifikation nicht vorab veröffentlicht wird. Laut Jochen Krause gibt es jedoch Gespräche mit der BiPRO, um das Problem zu lösen.
Die Software der Prometheus Foundation wird sich in drei Teile gliedern, ein zentrales Verzeichnis für Versicherungsprodukte (Produktbus), eine Client-Komponente sowie einen Service Proxy. Der Service-Proxy wird eine Zwischenschicht darstellen, mit der die neue Architektur die vorhandenen Web-Dienste der Versicherer nutzen kann. Er wird beispielhaft implementiert und kann von den Versicherungen selbst integriert oder von Dienstleistern betrieben werden. Er ist aber nur als vorübergehende Lösung gedacht, der langfristig wohl verschwinden oder stark reduziert werden soll. Die Client-Komponente enthält die verschiedenen Module für Verträge, Schadensmeldungen, Kundenverwaltung, Rechnungswesen, Vergütung, Produkte, Controlling und was sonst noch so anfallen könnte. Diese Software soll sowohl auf dem Desktop wie auch als Web-Anwendung laufen können. Die Oberfläche soll so weit wie möglich anhand der Produktbeschreibungen, die im Produktbus hinterlegt sind, dynamisch generiert werden.
Der Produktbus soll die Definitionen der Produkte, Verarbeitungsprozesse und anderem enthalten. Es dürfte offensichtlich sein, dass diese Definitionen umfangreich und komplex sein werden. Zudem sind sie dynamisch und können sich häufig ändern. Ihre Basis bilden die aktuellen und vielleicht die noch kommenden BiPRO-Standards. Technische Grundlage aller BiPRO-Standards ist eine Service-orientierte Architektur, die Domänenmodelle im XML-Schema definiert und über Web-Services kommuniziert.
Der Produktbus muss zentral betrieben werden, beispielsweise von der Foundation selbst oder einem Dienstleister. Jedes Versicherungsunternehmen speichert die Datenstrukturen seiner Produkte im Produktbus ab und benennt die Dienste, über welche die Prozesse für die entsprechenden Produkte abgewickelt werden können.
Angesichts dieser Grundlagen verwundert es nicht, dass zur Umsetzung die Eclipse-Plattform herangezogen wird. Das in Eclipse bereits vorhandene OSGi-Modulkonzept wurde als Basis für die ganze Architektur gewählt. Damit folgt man einem aktuellen Trend, der sich immer mehr zu verstärken scheint, nämlich sehr stark auf bereits vorhandene, flexible Komponenten aufzusetzen und nur das Nötigste selbst neu zu entwickeln. Das Projekt stellt fest, dass bereits kommerziell einsetzbare OSGi-Komponenten für alle funktionalen Anforderungen vorliegen.
Hintergrund: Eclipse und OSGi
Eclipse ist im Grunde nur ein Rahmen für nahezu beliebige Plugins. Da die Basis und auch die meisten Plugins in Java geschrieben sind, ist eine der verfügbaren Standard-Konfigurationen eine Entwicklungsumgebung für Java und XML. Der Kern von Eclipse ist mittlerweile eine Implementierung der OSGi-Spezifikation, die sich in aller Kürze als dynamisches Modulsystem für Java beschreiben lässt. Module heißen im OSGi-Jargon Bundles, und sie implementieren eine versionierte Software-Schnittstelle. Sie lassen sich dynamisch aktivieren, deaktivieren, aktualisieren und ausführen, wobei OSGi die Abhängigkeiten prüft.
OSGi startete 1999 und wurde ursprünglich für den Einsatz in Set-Top-Boxen und Heim-Routern entwickelt. Über andere eingebettete Geräte und Mobilgeräte (Smartphones) wurde es zu einem enormen Erfolg, und es gibt heute mehrere freie Implementationen, neben der von Eclipse beispielsweise auch eine von der Apache Foundation (Apache Felix), die untereinander auch austauschbar sind. Überhaupt besitzen Eclipse und Apache viele Berührungspunkte oder gar Überschneidungen. Auch in der Organisation ähneln sie sich; wer viel beiträgt (womit in erster Linie Code gemeint ist), hat viel mitzureden (Meritokratie). Sie folgen damit den wichtigen »Open Source Rules of Engagement«, die beispielsweise bei der Eclipse Foundation explizit nachzulesen sind. Sie lassen sich auf die drei Schlagworte Offenheit, Transparenz und Meritokratie verkürzen: Das Projekt ist offen für alle und will allen die gleichen Bedingungen bieten; es ist transparent, da alle Diskussionen und Produkte öffentlich sind; und es ist eine Meritokratie wie oben beschrieben.
Das Eclipse-Konsortium war natürlich auch Vorbild für die Prometheus Foundation, auch wenn beide Organisationen deutliche Unterschiede aufweisen. Die Produkte der Eclipse Foundation werden in der Öffentlichkeit sicher nicht so sehr wahrgenommen wie beispielsweise der Linux-Kernel, aber sie erlangen unter Software-Entwicklern immer größere Bedeutung. Tatsächlich handelt es sich um ein fast nicht mehr überschaubares Projekt, unter dessen Dach zahlreiche Unterprojekte entstehen und vorangetrieben werden.
Es gibt aber mindestens drei bedeutende Unterschiede zwischen der Prometheus Foundation und der Eclipse Foundation. Erstens produziert die Eclipse Foundation Software-Komponenten für Entwickler. Es entstehen mehr und mehr ausgereifte und sehr flexible Komponenten, die zwar eine Einarbeitung erfordern, um sie zu meistern, dann aber eine enorme Produktivitätssteigerung erwarten lassen. Die Prometheus Foundation dagegen will Software für Endanwender produzieren, wenn auch nur für einen ganz spezifischen Anwenderkreis. Die Software muss natürlich ebenso robust und sicher wie benutzerfreundlich sein.
Der zweite Punkt betrifft die Mitgliedschaft. In der Eclipse Foundation gibt es verschiedene Arten der Mitgliedschaft, von den Entwicklern, die aufgrund ihrer Codebeiträge aufgenommen werden, bis zu Unternehmen mit verschiedenen Beitragshöhen und Stimmrechten. Die Mitgliedschaft in der Prometheus Foundation ist generell mit einer Gebühr verbunden und steht nur denen offen, die im Versicherungsgeschäft oder dessen Umfeld im weitesten Sinne tätig sind.
Der dritte Unterschied ist, dass für die Eclipse-Mitglieder die Entwicklung von Software das Kerngeschäft darstellt. Für die Versicherungen, Makler und ihre Dienstleister stellt die Software lediglich ein Betriebsmittel dar, in das investiert werden muss.
