Während viele BPM-Projekte abteilungs- oder unternehmensintern geführt werden, gibt es viele Wertschöpfungsketten, die sich über mehrere Firmen, Unternehmen und sogar staatliche Stellen erstrecken. Geschäftsprozessintegration kann hierbei jeweils bilateral erfolgen oder aber über eine zentrale Integrationsplattform, die viele Partner mit standardisierten Schnittstellen anbindet, um Geschäftsprozesse möglichst standardisiert und somit effizienter ausführen zu können. Letzteres erlaubt Synergieeffekte und verhindert Mehrfachimplementierungen von gemeinsamen Teilprozessen und Softwarefunktionen. Dieser Ansatz, von uns Large Scale Business Process Integration genannt, stellt eine zentrale Prozessdrehscheibe in den Mittelpunkt der Zusammenarbeit (Abbildung 1), die Teilprozesse bei den verschiedenen Prozessbeteiligten miteinander orchestriert.

Abbildung 1: Prozessintegration mit Drehscheibe Terravis

Unser Beispiel Terravis

Das Produkt Terravis ist aus dem E-Government-Projekt eGRIS hervorgegangen, wobei die größte Finanzinfrastrukturbetreiberin der Schweiz, SIX (www.six-group.com) im Jahr 2009 die Projektleitung übernahm. Bis Ende 2011 wurden Hypothekargeschäfte und die damit zusammenhängenden notariellen Beurkundungen und Grundbuchanmeldungen ausschließlich auf Papier und auf dem Postweg abgewickelt. Trotz einer gesetzlichen Regelung auf Bundesstufe fehlten Standards und Schnittstellen, da es seitens der Grundbuchämter und Notare keine Veranlassung gab, system- oder gebietsübergreifende Lösungen anzubieten. Im Rahmen des Projekts eGRIS wurden entsprechende Lösungen zusammen mit Vertretern der 26 Kantone erarbeitet und Anfang 2012 erstmals produktiv eingesetzt. SIX betreibt die Plattform Terravis, die drei Hauptmodule beinhaltet:

Die Plattform Terravis regelt im Rahmen des elektronischen Geschäftsverkehrs den Meldungsaustausch zwischen Grundbuchämtern, Notaren und Banken auf elektronischer Ebene. Damit die unterschiedlichen Prozesse zwischen den erwähnten Partnern automatisiert werden können, müssen sie zuerst in möglichst wenigen Ausprägungen standardisiert werden; und dies in einem interdisziplinären Geschäftsbereich, der sich – im Gegensatz zur Finanzwelt – in den letzten hundert Jahren individuell und papierlastig entwickelt hat.

Die Schweiz ist mit Deutschland vergleichbar föderalistisch aufgestellt, wo das Grundbuchwesen zwar auf Bundesstufe gesetzlich geregelt ist, jedoch die Ausführung den 26 Kantonen überlassen wird. Dies führt zu divergierenden Ausprägungen und Ausführungsbestimmungen. Das Notariatswesen ist in der Schweiz noch föderaler als das Grundbuchwesen, wurde doch erst 2012 erstmals ein Gesetzesartikel im Zusammenhang mit Beurkundungen auf Bundesstufe in Kraft gesetzt. Die organisatorische Regelung ist entsprechend vielfältig. Etwa die Hälfte der Kantone kennt das lateinische (freiberufliche) Notariat, weitere das Amtsnotariat (Grundbuchverwalter ist gleichzeitig Notar) und schließlich diverse mit einer Kombination von freiberuflichem und Amtsnotariat. Als zusätzliche Herausforderung soll nicht unerwähnt bleiben, dass es in der Schweiz selbstverständlich ist, Deutsch, Französisch und Italienisch zu unterstützen.

Mit diesen Voraussetzungen wurden in dedizierten und iterativen Workshops mit den einzelnen Fachbereichen (Grundbuch, Bank, Notar) unter Berücksichtigung von verschiedenen Sprachzonen und Interessen über Monate die ersten standardisierten fachlichen Prozesse erarbeitet, die als Basis für die Implementierung dienten. Voraussetzung dazu war einerseits die Definition und Erarbeitung der späteren Geschäfts- und Softwareservices zusammen mit den unterschiedlichen Grundbuch- sowie Bankensoftwareherstellern als Basis für eine spätere Integration. Bei der Entwicklung war SIX für die Prozess- und Webportalimplementierung gezwungen, einen iterativen und dynamischen Ansatz zu wählen. Iterativ, weil die Implementierung mit den einzelnen Fachgruppen zwecks Akzeptanz verifiziert werden musste und dynamisch, weil SIX sich nicht auf eine endlose Spezifikationsphase einlassen wollte. In einer ersten Phase geht die Projektleitung von einer Integration mit über 300 Grundbuchinstanzen, 100 Finanzinstituten und mehreren Hundert Notaren aus. Dabei werden die Notare und in einer Übergangsphase die Banken über ein eigenes Webportal an Terravis angeschlossen.

Wichtig ist hierbei, dass Terravis lediglich die Prozessintegration durchführt. Die Hypothekenverwaltung, das Notar- und Grundbuchwesen etc. verbleiben bei den jeweiligen Institutionen bzw. Banken. Dies ist beispielhaft in Abbildung 2 für den Gläubigerwechsel dargestellt.

Abbildung 2: Terravis Systemgrenzen

In der Schweiz sind Hypotheken von über 800 Milliarden Franken ausstehend. Damit zusammenhängend werden jährlich rund 500 000 Geschäfte abgewickelt, welche in den nächsten Jahren sukzessive auf die Terravis-Plattform migriert werden. Um diese Geschäfte wirklich von einem Partner medienbruchfrei „end to end“ abwickeln zu können, musste zusätzlich erstmals in der Schweiz eine Lösung für den Einsatz von qualifizierten digitalen Signaturen erarbeitet werden, welche sowohl den rechtlichen Ansprüchen als auch den Ansprüchen der Wirtschaft genügt. Dabei wurde das Remote-Signieren mittels Signaturserver mit einem akkreditierten Provider integriert. Schließlich wurden weltweit einzigartig bei Terravis grundbuchliche Geschäfte mit dem Zahlungsverkehrssystem Swiss Interbank Clearing hochintegriert verknüpft, sodass bei Kreditablösungen ebenfalls die Zahlungen in den elektronischen Prozess integriert ausgelöst werden können.

Architekturebenen

Ein Projekt dieser Größenordnung erfordert ein besonderes Architekturmanagement, das sich nicht nur mit den fachlichen und technischen Details der Lösung allein, sondern auch mit dem Management der Geschäftspartner auf einer soziologischen und wirtschaftlich-politischen Ebene beschäftigt. Da das Projekt nicht rein Top-down, einem Wasserfallansatz folgend, sondern iterativ durchgeführt wurde, mussten mehrere Schauplätze gleichzeitig im Blick behalten und miteinander synchronisiert werden. Wir haben im Laufe der Umsetzung fünf Architekturebenen identifiziert:

In den ersten Projektphasen stand besonders die Businessarchitektur im Vordergrund. Auf dieser Ebene steht sowohl die Identifikation und Diskussion der Anforderungen mit den Stakeholdern und Geschäftspartnern. Insbesondere im E-Goverment-Umfeld ist es nicht immer leicht, alle Partner von dem Erfolg des gemeinsamen Projekts zu überzeugen. Es müssen Verträge geschlossen werden, die Verrechnungs- und Zahlungsmodalitäten geklärt und Komitees für die gemeinsame Arbeit an Datenaustauschformaten und Integrationsszenarien gegründet werden. Da die Einführung eines solchen Projekts nicht als Big Bang für alle Prozesse ausgerollt werden kann, wiederholen sich diese Schritte im Verlauf des Projekts immer wieder für verschiedene Prozesse.

Die Systemarchitektur kann im Groben aus den fachlichen Anforderungen abgeleitet werden, allerdings spielen hier oft auch politische oder juristische Dimensionen eine wichtige Rolle. So kann beispielsweise eine Anforderung sein, dass alle ein- und ausgehenden Anfragen protokolliert und als Auditlog archiviert werden müssen, damit ein Auditor auch Jahre später noch in der Lage ist, die damals abgelaufene Prozessinstanz nachzuvollziehen. Auch möchten Geschäftspartner Einblick in den aktuellen Stand der Prozesse bekommen, gleichzeitig sind aber auch Datenschutzbestimmungen zu beachten, die sicherstellen, dass dieser Zugriff nur von an diesem Vorgang teilnehmenden Partnern vorgenommen werden kann. Diese Faktoren haben großen Einfluss auf die Architektur des Gesamtsystems aber auch auf die Produktwahl.

Die Prozessarchitektur widmet sich der technischen Umsetzung der fachlich identifizierten Prozesse. Auf welcher Grundlage diese Prozesse umgesetzt werden, hängt von der Systemarchitektur ab. Geht es um high-throughput- Szenarien mit kurzlaufenden Prozessen, kommt möglicherweise gar keine Prozess- Engine zum Einsatz. Für langlaufende Prozesse mit einer Laufzeit zwischen Tagen und Monaten, wie sie im Terravis-Projekt umgesetzt wurden, ergibt der Einsatz einer solchen Engine als zentrale Architekturkomponente durchaus Sinn. Die Herausforderung auf dieser Architekturebene ist der Schulterschluss zwischen den fachlichen und den technischen Prozessmodellen. Auf der Businessarchitekturebene wurden die groben Prozesse bereits definiert, an deren Darstellung und Granularität sind die Geschäftspartner gewöhnt. In der Regel weicht die Struktur und Darstellung der technischen Modelle allerdings von diesen Modellen ab, d. h. es muss für die Ablaufverfolgung eine semantische Verknüpfung zwischen den technischen und den fachlichen Aktivitäten hergestellt werden. Ein weiterer Aspekt der Prozessarchitektur ist die Definition von Protokollen und deren Kommunikation mit den Geschäftspartnern. Im SOA-Umfeld wird oft von zustandslosen Diensten ausgegangen, oder zumindest erlauben die Schnittstellendefinitionen der Dienste nicht die Modellierung von Konversationen zwischen Partnern. Dies ist aber ein integraler Bestandteil der Gesamtarchitektur. Auch wenn auf fachlicher Ebene geklärt ist, welche Partner in welcher Reihenfolge Daten austauschen, ist dies auf technischer Ebene zunächst ungeklärt. Dieses „Behavioral Interface“ kann auch als Bedienungsanleitung für Dienste gesehen werden, muss formal mit den Partnern abgestimmt sein und sowohl isoliert im eigenen Projekt als auch in Integrationstests mit den Partnern getestet werden können.

Während die Prozessarchitektur den „Programming in the large“-Aspekt bedient, geht es bei der Integrationsarchitektur um das „Programming in the small“, also die Geschäftsfunktionen, die durch die Prozesse orchestriert werden. Die größte Herausforderung bei einem Large-Scale-Integrationsprojekt ist es, die richtige Abstraktion und die richtige Granularität für den Serviceschnitt zu finden. Dabei muss insbesondere auch die Schemaintegration geachtet werden. Möchte man tausend Notare elektronisch anbinden, ist es nicht akzeptabel, tausend unterschiedliche notarspezifische Datentypen und Services zu integrieren. Diese Anforderung kann in den meisten Fällen bereits in der Businessarchitektur gelöst werden und bringt die Anzahl der zu integrierenden Dienste auf ein Minimum. Trotzdem birgt jeder zu integrierende Drittdienst ein Risiko, da weder die Schemata noch die Implementierungen unter der Projektkontrolle stehen. Deshalb sollten nach Möglichkeit alle externen Dienste durch interne Dienst-Wrapper gekapselt werden. So entsteht eine Art „Knautschzone“, die an dieser Stelle eine lose Kopplung erwirkt und dadurch das Gesamtsystem robuster macht. Ändert sich einer dieser Dienste, kann entweder der Wrapper angepasst oder der Dienst durch einen anderen ersetzt werden, ohne das die Prozesslogik angepasst werden muss.

Eine weitere Herausforderung ist die Versionierung von Prozessen und Diensten, die sich durch den iterativen Ansatz nicht vermeiden lässt. So muss die Architektur den Geschäftspartnern zusichern, über einen bestimmten Zeitraum hinweg mit mehreren Versionen der gleichen Dienste gleichzeitig umgehen zu können.

Orthogonal zu den bisher genannten Architekturebenen müssen Sicherheitsaspekte betrachtet werden. Sicherheiten werden in der Regel schon vertraglich zugesichert und haben deshalb auch Einfluss auf die Systemarchitektur. Müssen Security-Gateways eingesetzt werden? Wie werden Partner authentifiziert und autorisiert? In der Prozessarchitektur muss entschieden werden, mit welchen Rechten die Geschäftsfunktionen (Dienste) aufgerufen werden. Agiert der Prozess als eine Art technischer Superbenutzer oder werden die Dienste im Namen eines Prozessteilnehmers aufgerufen? Weiterhin müssen die Dienste so abgesichert werden, dass nur befugte Systeme darauf Zugriff haben und alle Zugriffe protokolliert werden, wenn die Anforderungen das fordern.

Umsetzung in Terravis

In Terravis mussten für alle beschriebenen Architekturebenen ebenfalls Entscheidungen gefunden werden. Diese mussten sowohl den Anforderungen aller Interessensgruppen entsprechen und zugleich pragmatisch und schnell technisch umsetzbar sein.

Hier stand zuallererst die Businessarchitektur im Mittelpunkt. Von Anfang an wurde hier entschieden, dass nicht alle Partner untereinander Verträge schließen müssen, da dies sehr aufwändig und administrativ nicht handhabbar wäre. Stattdessen schließen die Teilnehmer mit Terravis Verträge, in denen die Beziehungen, Rechte und Verpflichtungen zu den anderen Teilnehmern geregelt sind. Diese Verträge wurden in Komitees mit Repräsentanten der jeweiligen Partner entwickelt und als Standard festgelegt. Neben den Komitees für die Verträge gibt es viele Gremien mit unterschiedlicher Besetzung, in denen verschiedene Fragestellungen bearbeitet und als Vorgaben in die Terravis- Entwicklung weitergegeben werden.

In den Verträgen werden auch die Zahlungsmodalitäten festgelegt: Terravis als zentrale Plattform berechnet anfallende Gebühren und stellt diese gesammelt jedem einzelnen Partner in Rechnung. Partner, insbesondere Grundbuchämter, die dabei ihre Dienstleistungen anbieten, bekommen dann das Geld von Terravis weiterverrechnet. Zusätzlich berechnet Terravis standardisierte Transaktionskosten, mit denen der Aufbau und der Betrieb der Plattform finanziert werden.

Die Systemarchitektur wird vom Terravis-Entwicklungsteam definiert. Hierbei gibt es einige Vorgaben, insbesondere dass die Datenhoheit der Kantone gewahrt bleiben muss, und Terravis keine Daten speichern darf (was auch Caching beinhaltet), was eine große Herausforderung bezüglich der Performance ist. Ansonsten basiert Terravis auf einer SOA, mit in Apache Camel und Java implementierten Message-Routern, Adapterservices zu allen Umsystemen und einem BPEL-Server zur Prozesskoordination. Daneben gibt es verschiedene Webportale, die es den Anwendern erlauben, alle Terravis-Funktionen über einen Webbrowser zu bedienen, solange ihre Organisation noch nicht direkt die angebotenen Serviceschnittstellen in ihre Systeme eingebunden hat. Hierbei war es besonders wichtig, keine Terravis-Insellösung zu schaffen: Das Übergangsportal für die Banken und das Notarenportal verwenden exakt die gleichen Services wie die externen Partner bei ihrer Integration und genießen somit keinen Heimvorteil.

Bei allen Aktivitäten im System wird in ein zentrales Auditlog geschrieben und abrechnungsrelevante Informationen zu der jeweiligen Aktivität gespeichert.

Neben der fachlichen Überwachung in Form von Abfrage und Selektion der Auditinformationen gibt es eine technische Überwachung, die zum einen die eigenen Services überwacht und bei Bedarf den Betrieb informiert, als auch eine Überwachung, die die Erreichbarkeit der Umsysteme regelmäßig überprüft und bei Bedarf den Support informiert. Ebenso werden bei Fehlern in Prozessabläufen die jeweiligen Ansprechpartner informiert, die das Problem analysieren und beheben können.

Die Architekturebene, in die bislang am meisten Arbeit investiert werden musste, ist die Prozessarchitektur. Es gab zu jedem der unterstützten Prozesse fachliche Arbeitsgruppen, in denen mit den an dem jeweiligen Prozess beteiligten Stakeholdern der Prozessablauf, die Aufgaben und Ziele, sowie die Regeln der Zusammenarbeit diskutiert und festgelegt wurden. Diese Abstimmung hat sehr lange gedauert und viel Arbeit gekostet, hat aber auch dazu geführt, dass die Prozessmodelle seit ihrer Einführung fachlich stabil geblieben sind.

Zur technischen Implementierung der Prozessmodelle wurde BPEL benutzt. Ein zentraler BPEL-Server, bei Terravis fiel die Wahl auf ActiveVOS, bietet viele Funktionen, die ansonsten sehr aufwändig manuell implementiert werden müssten, und steigert so die Produktivität und die Umsetzungsgeschwindigkeit. Hierbei seien vor allem Message Correlation und Prozesspersistenz genannt. Die graphischen Monitoring-Werkzeuge erlauben es zudem, einfach und ohne eigenen Implementierungsaufwand, Prozessinstanzen zu verfolgen. Im kommenden Terravis- Release wird die Prozessverfolgung noch auf ein Meilensteinmodell abgebildet. Dies erfordert einen kleinen Implementierungsaufwand, erlaubt aber unabhängig von großen Modellen die Abfrage des Prozessstatus in einer von Fachanwendern verständlichen und sehr groben Prozesssicht. Die Fehlerbehandlung in den Prozessen ist bei Terravis zunächst komplett betriebsorganisatorisch gelöst: Anstatt zu versuchen, alle Ausnahmefälle und Fehlermöglichkeiten von Anfang an zu modellieren, wird ein Prozess bei einem Fehler angehalten und die Parteien müssen sich zunächst außerhalb vom Prozess einigen. Der Prozess kann dann in Terravis fortgesetzt oder beendet werden. Die so gemachten Erfahrungen können dann genutzt werden, um Fehlerfälle zu modellieren und deren Behandlung später zu automatisieren.

Als Integrationsarchitektur wurden SOAP-Web-Services gewählt. Diese bieten einen verbreiteten Toolsupport und vor allem eine formale und standardisierte Schnittstellenbeschreibung. Diese ist gerade dann wichtig, wenn mit vielen Partnern zusammengearbeitet werden muss, wie das bei Terravis der Fall war. Zur Absicherung der Kommunikationswege wird Two-Way-SSL verwendet, d. h., die Verbindung ist nicht nur verschlüsselt, sondern beide Parteien authentifizieren sich mit Zertifikaten. Diese Form der Authentifizierung ist sehr sicher und wird von allen gängigen Bibliotheken unterstützt.

Alle von Terravis angebotenen Services sind versioniert. Dabei unterstützt Terravis den gleichzeitigen Betrieb von verschiedenen Versionen. So kann eine Bank, die einen Service in Version 1.0 einen Prozess gestartet hat, dort mit einer Bank verhandeln, die bereits eine andere Version, z. B. 2.0, verwendet. Terravis übersetzt alle Nachrichten in die jeweils passende Version und sichert allen Partnern ein zweijähriges Migrationsfenster von einer alten zu einer neuen Version zu.

Erfahrungen und Herausforderungen

Im Laufe des Projekts hat sich herausgestellt, dass die Aufwände für die Kommunikation, die Integration mit Partnern und die Abklärung von Prozessen und anderen fachlichen Fragen weitaus größer waren als angenommen und faktisch etwa gleich groß wie die rein technischen Aufwände sind.

Bei interdisziplinären Projekten, wo mehrere Anspruchsgruppen mit unterschiedlichem Hintergrund und Fachwissen involviert sind, ist dem Change- Management eine hohe Priorität einzuräumen. Ein Ausklammern der Softfaktoren seitens der Projektverantwortlichen aus Gründen der Bequemlichkeit rächt sich potenziell bei der späteren Akzeptanz der Lösung. Beim Design der Prozesse ist dem Umgang mit Spezialfällen und Ausnahmen sowie dem Umstand, dass die Umwelt nicht perfekt ist, Rechnung zu tragen. Das Vorstellungsvermögen vieler Involvierter hinkt oft hinterher, da es in der Papierwelt gefangen ist. Prototypen und Livevorführungen sind ein probates Mittel, um Abhilfe zu schaffen und die Basis für weitergehende Abstimmung zu legen.

Dem Servicedesign und der Serviceversionierung kommt eine erhebliche Bedeutung zu, wenn Partnersysteme direkt mit einer zentralen Plattform integrieren sollen. Diese sind gut, konsistent und auf Verständlichkeit ausgerichtet zu designen. Dazu gehören Namenskonventionen, Versionierungsrichtlinien, definierte Subsets von verwendeten Elementen etc. Je komplizierter die angebotene Schnittstelle ist, desto höher sind die Integrationsaufwände.

SOAP ist zwar nicht mehr Hype und ein großer Trend, aber die Möglichkeit, eine Schnittstelle maschinenlesbar und generierbar zu beschreiben, hilft ungemein, Integrationsaufwände zu reduzieren. Dennoch sind Integrationstests und deren Aufwände einzuplanen.

Die Überwachung zur Laufzeit steigt stark mit der Anzahl der verbundenen Systeme. Selbst jetzt, wo bei Weitem noch nicht alle Systeme, die vorgesehen sind, mit Terravis verbunden sind, treten natürlicherweise Probleme mit der Konnektivität, Benutzern und Zertifikaten auf. Je größer die Anzahl der verbundenen Systeme ist, desto mehr muss die Überwachung automatisiert werden und desto mehr muss die Überwachung proaktiv erfolgen.

Zusammenfassung

Large-Scale-Business-Process-Integrationen, also Plattformen, die viele Partner über eine prozessorientierte Plattform miteinander integrieren, bringen einerseits große Effizenzgewinne für die involvierten Partner und bergen andererseits viel Komplexität in sich. Entsprechende Projekte lassen sich erfolgreich umsetzen, wenn sich innerhalb der Projektleitung Business und IT optimal abstimmen und ergänzen. Die Umsysteme und die Businesswelt, welche durch die Process Integration verbunden werden, sind unvollkommen, daher ist proaktives Handeln und ein iteratives Vorgehensmodell unverzichtbar. So ist es möglich, solche großen und komplexen Systeme erfolgreich zu entwickeln, einzuführen und zu betreiben!

TAGS