12.12.2007, 08:57 Uhr
Mammutprojekt für Solothurner Rechenzentrum
Der Aufbau der Swiss Health Platform ist für die Solothurner Rechenzentren- betreiberin Centris das Projekt der nächsten 15 Jahre. Mit einem modularen Aufbau auf SOA-Basis will man genug Flexibilität für eine so lange Zeit geschaffen haben.
Swiss Health Platform: Der modulare Aufbau soll hohe Flexibilität gewährleisten und die SHP betont zukunftssicher machen.
Wenn Bundesrat Pascal Couchepin wieder einmal die Pharmaindustrie unter Druck setzt, ihre Medikamentenpreise zu senken, lässt das Andreas Wälchli, Leiter des Product Management bei Centris, kalt. Die in seinem Rechenzentrum in Solothurn laufende Swiss Health Platform (SHP) ist nämlich sehr modular aufgebaut. Wenn also der Gesundheitsminister eine Tarifänderung durchboxt, sind nur Anpassungen am Tarifmanagementsystem nötig. Dabei handelt es sich um eine von vielen Komponenten, die zwar ans Kernsystem angekoppelt sind, aber unabhängig von diesem laufen.
Was hier im Detail gilt, spiegelt sich im ganzen SHP-Projekt wider. Die Gesamtlösung für die Kranken- und Unfallversicherer weist eine flexible Bauweise aus, die sich unter anderem durch eine Service-orientierte Architektur (SOA) auszeichnet. Laut Wälchli waren nicht primär technische Vorgaben, sondern hauptsächlich geschäftliche Erwägungen entscheidend für die SOA-Strategie. So habe man sich gefragt, welche Elemente der Plattform aus Business-Sicht eine eigene Dynamik behalten müssen. «Hier macht es wenig Sinn, alles im Kernsystem unterzubringen. Dieses würde viel zu schwerfällig», ist er überzeugt.
Auch Martin Cetin von Centris, zusammen mit Wälchli für die Gesamtprojektleitung der SHP zuständig, sieht Vorteile in der SOA-Bauweise der Plattform. So könne man nun Fremdsysteme sehr einfach an die Lösung anbinden. «Wenn eine Fachperson beispielsweise für seine Applikationen Informationen aus einem Dokumentenarchivierungssystem braucht, kann ihm ein entsprechender Service diese Daten aus dem System holen», erklärt er.
Bei der Wahl sei zudem der längerfristige Investitionsschutz ausschlaggebend gewesen, fügt Wälchli an. Wenn das System in gut 15 Jahren abgelöst werden müsse, habe man keinen Koloss, der ersetzt werden müsse. Die Kunden könnten zudem gewisse Komponenten vorgängig ersetzen, ohne dass sie die ganze Plattform verlassen müssten. Etwa, wenn für bestimmte Aufgaben ein besseres Softwareprodukt auf den Markt komme.
Das Prinzip der vier Schichten
Centris hat die SHP zusammen mit der CSC als Generalunternehmerin nicht auf der grünen Wiese errichtet. Die Rechenzentrenbetreiberin ist seit vielen Jahren für Krankenkassen und Unfallversicherer tätig. Mit dem Aufbau der SHP wird denn auch die bisherige Grossrechner-Umgebung von IBM nach und nach durch eine Linux- und HP-UX-Plattform mit Servern von Hewlett-Packard ersetzt.
Die ganze SHP spielt sich auf vier Stufen ab, basiert also auf einer so genannten «4-Tier-Architektur». Deren Fundament ist der Datenbank-Cluster von Oracle. Über der Datenbank sind auf der Application-Server-Ebene die Anwendungen installiert, also sozusagen das Kernstück und Hirn der SHP. Hauptapplikation ist dabei Syrius ASE (Advanced Server Edition) von Adcubum. Diese Anwendung wurde extra für Centris erweitert und zusammen mit den weiteren Systemen der SHP mit den erwähnten SOA-Fähigkeiten ausgestattet.
Syrius sei auch ein Grund für den Umstieg auf eine Linux- beziehungsweise HP-UX-Umgebung sowie die Wahl von CSC als Generalunternehmerin gewesen, meint Wälchli. Er begründet den Entscheid damit, dass die SHP auf einem Produkt aufgebaut werden sollte, das sich bereits bewährt hatte. Er bezieht sich dabei auf die Vorgängerversion Syrius SE, welche bei zahlreichen kleineren und grösseren Krankenversicherern bereits in Betrieb ist.
Die dritte und vierte Schicht der Installation beliefert den Endanwender. Dieser arbeitet mit einem Ultra-Thin-Client. Das heisst, seinem PC wird nur wenig Rechenleistung abverlangt, und er erhält nur die Bildschirmanzeige von einem dedizierten Server. Vor allem braucht es aber keine Installationen auf dem PC, was bei Updates sehr viel Zeit und Geld spart.
Über die Application und die Ultra-Thin-Client Server ist eine Art Virtualisierungs-Schiene gezogen, die mit einer entsprechenden Lösung von VM-Ware realisiert wurde. Dies erlaubt eine flexible Hardware-Unterstützung der SHP zur Erreichung der individuell benötigten Performance für die Centris-Kunden. So stehen je nach den Anforderungen des Firmenanwenders 4 bis 16 Server im Hintergrund bereit, die nach Bedarf beigezogen werden können. Die Rechner lassen sich, erklärt Wälchli, flexibel hinzuschalten, und zwar ohne Unterbrechung der laufenden Prozesse.
Die gesamte SHP ist ausfallsicher angelegt und läuft in zwei getrennten Rechenzentren. Zudem ist die Installation mandantenfähig. Das heisst, mehrere Firmen können die Anwendungen parallel verwenden und nutzen dieselbe Infrastruktur. «Wichtig ist, dass wir hierbei garantieren können, dass die Daten sauber getrennt sind», erklärt Wälchli.
Gross angelegt
Dieser Aufbau wurde unter anderem auch aus Gründen der Skalierung gewählt. Denn mit der SHP hat Centris grosses vor. Laut Wälchli sind die ganze Architektur und die Plattform von Anfang an auf einen Versichertenbestand von 1,7 bis zwei Millionen Personen ausgelegt. Derzeit arbeitet mit der Krankenversicherung Xundheit zwar erst ein verhältnismässig kleiner Kunde mit dem System. Das wird sich aber in Kürze ändern. Die nächste Krankenkasse, die auf die SHP umsteigen wird, ist die Swica. Und die ist gut zwölf Mal grösser als die Xundheit.
Auch technisch hat Centris noch einiges vor: So läuft die SHP in der Produktion heute auf vier virtualisierten Servern, wobei je deren zwei für die Bereitstellung der UTC und der Kernapplikation Syrius ASE vorgesehen sind. Im Endausbau sollen mehr als 80 virtuelle Server zur Verfügung stehen.
Ähnlich Grosses hat Centris bei den Online-Transaktionen vor. Zählt das Rechenzentrum heute bei seinem ersten Kunden Xundheit noch 30000 Übermittlungen pro Tag, so sollen im Endausbau bis zu 1,5 Millionen teils hochkomplexe Transaktionen täglich abgewickelt werden.
Wie ambitiös diese Zielsetzung ist, wissen die Centris-Mitarbeiter. Laut Wälchli war deren Sondereffort auch ausschlaggebend für das Gelingen des Projekts bis zum jetzigen Zeitpunkt. Allen sei klar, dass die SHP das grösste Projekt für Centris für die nächsten 15 Jahre und existenziell wichtig für die Firma sei. Wälchli: «In so einer Situation gibt man als Mitarbeiter alles.»
Parametrisieren statt Programmieren
Schwierigkeiten gibt es bei einem solchen Mammutprojekt natürlich auch. Da die SHP und ihre Applikationen modular aufgebaut sind, ist mehr Aufwand für die Parametrisierung der Anwendungen nötig. «Als wir das Projekt vor drei Jahren starteten, rechneten wir nicht damit, dass wir 15 Spezialisten brauchen würden, die nur parametrisieren», erklärt er. Doch die Anstrengung dürfte sich für Centris lohnen. «Dank der SHP können wir unseren Kunden künftig mehr bieten und unser Rechenzentrum auf einen technischen Höchstlevel bringen», ist Wälchli überzeugt.
Weitere Informationen
So unterstützen Diagnosetools den Softwarewechsel
Fehlerdiagnose helfen, die häufig unabsehbaren Konsequenzen einer Softwaremigration im Griff zu behalten. Das war bei der Swiss Health Platform nicht anders.
Für die Einführung ihrer Swiss Health Platform (SHP) migrierte Centris von ihrer Kernapplikation IRIS zu Syrius ASE von Adcubum. Dabei halfen die Diagnosewerkzeuge von dynaTrace, Verzögerungen klein zu halten.
Beim Rollout der SHP zeigte die Syrius ASE Performance-Schwächen, die im Testbetrieb noch nicht sichtbar waren. Zwar nutzte Centris schon bei den Beta-Tests Monitoring- und Lasttest-Tools. Diese lieferten aber keine befriedigenden Ergebnisse. Erst eine Konzeptanalyse mit der Performance- und Fehlerdiagnose-Software «dynaTrace Diagnostics» beantwortete offene Fragen. Vera Gawlick, Projektmanagerin für die IT-Systemtechnik bei Centris: «Wo wir anfangs aufgrund von Symptomen nur vermuten konnten, wo es klemmt, lieferte uns das Diagnosetool klare Hinweise, wo Probleme bestehen.»
In dreissig Fällen habe das Tool ineffiziente Datenbank-Statements aufgezeigt und die Transaktionszeit in allen Fällen um neunzig Prozent reduziert. Unter anderem wurde der Spei-cher-bedarf der Java Virtual Machine stark reduziert. Die Analysen zeigten, dass zu viele Sessions für Tage offen blieben. Bei einem Speicherverbrauch pro Session von 40 bis 50 MByte liessen sich Platzprobleme und Prozess-Staus vorhersagen und rechtzeitig beheben.
Heute werden mit dem Tool objektive Messzahlen zur Performance ermittelt. So wird klar, welche Systemengpässe durch die Infrastruktur verursacht werden und welche durch die Applikation selbst. Centris und Adcubum haben eine Taskforce zur Performance-Analyse gebildet. Da die Ergebnisse der Analysen so aufbereitet sind, dass alle Beteiligten von Anfang an vom gleichen Problem reden, konnten die Durchlauf-zeiten datenintensiver, regelmässiger Batchjobs um bis zu 90 Prozent reduziert werden. Gawlick resümiert, dies habe die Kommunikation mit Adcubum deutlich verbessert. Heute steht dynaTrace bei Centris rund um die Uhr als Monitoring-Tool im Einsatz. Performance-Engpässe werden rasch erkannt und können schnell beseitigt werden.