Service-orientierte Architektur

SOA-Puzzle statt Großsystem

Reppesgaard studierte in Hannover und arbeitete danach als Reporter und Moderator bei Hörfunk von Radio Bremen zu innen- und jugendpolitischen Themen und in den Bereichen Technologie und Wissenschaft. Seit dem Jahr 2000 lebt er in Hamburg, seit 2001 arbeitet er mit Christoph Lixenfeld im druckreif Redaktionsbüro zusammen.
Drei Jahre haben Fraunhofer-Experten die Entwicklung der E-Government-Plattform „Integrierte Software Berliner Jugendhilfe“ begleitet. Jetzt wissen sie, welche Fallstricke die SOA-Technologie mit sich bringt.

Mehr als 110 000 Kindergartenplätze in 2100 Kindertagesstätten (Kita) stellen über 800 gemeinnützige freie Träger in Berlin bereit. Der Betrieb dieser Einrichtungen bringt für die Berliner Senatsverwaltung für Bildung, Jugend und Sport sowie für die zwölf Bezirksjugendämter große organisatorische Herausforderungen mit sich. Zudem geht es um sehr viel Geld, mehr als eine Milliarde Euro steckt die Hauptstadt in die Kinderbetreuung. Bislang machte die dezentrale Abwicklung über die Jugendämter und die nachträgliche jährliche Abrechnung mit den Trägern eine bedarfsgerechte Planung unmöglich.

„Für uns stand der Steuerungsgedanke im Vordergrund, wir wollen saubere Zahlen für die Planung“, erklärt Michael Richter, der in der Senatsverwaltung das Projekt „Integrierte Software Berliner Jugendhilfe“ (ISBJ) leitet, die Initialzündung für das E-Government-Vorhaben. „Man muss sehr genau wissen, wofür man Geld ausgibt, um das Optimum in der Kinderbetreuung sicherzustellen.“ Vom Begriff SOA hatte er 2003 noch nichts gehört. Doch was die Experten des Fraunhofer-Instituts für Software- und Systemtechnik (ISST) in Berlin berichteten, passte zu dem, was er sich vorgestellt hatte. „Warum sollte man schon wieder ein unflexibles Großsystem bauen und nicht eine Software, die aus einzelnen Bausteinen besteht und die wir bei Bedarf neu ordnen können, wenn sich gesetzliche Vorgaben oder Organisationsstrukturen ändern?“, hatte sich Richter gefragt.

Zuerst musste das Projektteam definieren, aus welchen Bausteinen das System überhaupt bestehen soll. Die Grundlage bildete die vom ISST entwickelte komponentenbasierte Referenzarchitektur zur StandardisierungStandardisierung von E-Government-Plattformen. In Bereichen wie der Wirtschaftlichen Jugendhilfe, der zentralen Vormundschafts- und Unterhaltsvorschusskasse und vor allem in der Kita-Verwaltung wurde geprüft, welche Dienste fachspezifisch sind und welche Komponenten auch in anderen Behördenanwendungen wiederverwendet werden können. Alles zu Standardisierung auf CIO.de

Die „Personenstammverwaltung“ ist ein Beispiel für solch eine Komponente. „Über eine automatische Schnittstelle zum Einwohnermeldewesen stellen wir sicher, dass die Person im System ihren Erst- oder Zweitwohnsitz in Berlin hat. Und wir bekommen mit, wenn jemand umzieht“, sagt Richter. Der Abgleich spart viel Geld: Zum einen kamen früher bis zu 30 Prozent der jährlich versandten 150 000 Briefe wegen veralteter Adressen nicht an. Zum anderen werden diejenigen, die keinen Anspruch auf Leistungen aus Berlin haben, früh identifiziert. „So eine Komponente kann auch in einer Studentenverwaltungs- oder Wohnungssoftware eingesetzt werden“, sagt Richter. Andere Bausteine sind dagegen speziell für die
Fachbehörden programmiert „Eine Anwendung zur Verwaltung von Tagesstättenplätzen lässt sich nicht zur Verwaltung eines Fuhrparks nutzen, dazu ist die fachliche Logik zu unterschiedlich“, erklärt Software-Architekt Ulrich Kriegel vom ISST.

Erst nachdem das Projektteam alle Komponenten der ersten Projektphase bis ins letzte Detail auf dem Papier definiert hatte, begann nach einer Ausschreibung die Programmierarbeit. „Es wurde gebaut, was gebraucht wurde, und nicht etwas gebaut, bei dem man danach schaut, was man damit machen kann“, sagt Kriegel. Umgesetzt wurde das Projekt auf Basis der Oracle-Datenbank und der Oracle-Fusion-Middleware. An den J2EE-Komponenten, aus denen die Plattform besteht, haben etliche Firmen mit programmiert, indem sie einzelne Bausteine als Teilprojekte bearbeiteten. Alle Einzelteile mussten gemäß der „Standards und Architekturen für E-Government-Anwendungen“ (SAGA) codiert werden. Dies stellte sicher, dass diese Puzzleteile tatsächlich zusammenpassen und wiederverwertbar sind.

Zur Startseite