Architekturen für eGovernment Fünf Regeln für den SOA-Erfolg

Serviceorientierte Architekturen wurden in den letzten Jahren als Wundermittel gehandelt. SOA konnten häufig sogar fertig von der Stange gekauft werden. Auch beim eGovernment hat SOA als Hoffnungsträger verstärkt Einzug gehalten. Inzwischen hat sich aber gezeigt, dass zahlreiche Projekte nicht die erhofften Ergebnisse erzielen.

Anbieter zum Thema

USU Software AG

Fujitsu Technology Solutions GmbH

mgm technology partners GmbH

Die Burton-Group-Analystin Anne Thomas Manes spitzte die Enttäuschung noch weiter zu, als sie Anfang des Jahres behauptete: „SOA ist tot.“ Stellen Architekturen als verallgemeinertes Konzept also überhaupt einen signifikanten Wert für eGovernment dar? Die Antwort lautet weiterhin „Ja“ – allerdings nur, wenn die Qualität der verwendeten Architekturen systematisch gesichert ist. Dieser Artikel stellt fünf wichtige Regeln dafür vor.

Grundsätzlich kann eine SOA die Aufgaben von eGovernment in idealer Weise unterstützen: Die Behörden wollen ihre Online Services für die Bürger möglichst effizient und gebrauchstauglich verfügbar machen. Unterschiedlichste Systeme zahlreicher Anbieter von Public Services müssen hierfür miteinander interagieren.

Bildergalerie

Dies setzt außerdem voraus, dass die dabei verwendeten Daten zueinander kompatibel sind. Die Services selbst müssen überschneidungs- und widerspruchsfrei angeboten werden. Auch bezüglich der Flexibilität stellt das eGovernment besonders hohe Anforderungen, die grundsätzlich durch SOA erfüllbar sind: Die sich regelmäßig ändernde Lage bei Gesetzen und Vorschriften erfordert eine hohe Anpassungsfähigkeit und Änderbarkeit sowohl der angebotenen Services als auch der dafür im Hintergrund eingesetzten Funktionen.

Warum kann eine SOA eine solch komplexe Sachlage unterstützen? Weil sie auf einem höchst effizienten Konzept der Komplexitätsbeherrschung beruht – nämlich dem von Architekturen. Diese Essenz von SOA wird häufig vernachlässigt, sodass zwar Services definiert und implementiert werden, die architektonischen Vorbedingungen, Abhängigkeiten und Auswirkungen aber völlig unbearbeitet bleiben. Systematische Qualitätssicherung kann diese Verknüpfung zwischen SOA und Architektur sicherstellen.

Architektur – was ist das?

Die IEEE 1471 definiert Architektur als grundlegende Organisation eines Systems, die bestimmt wird durch dessen Komponenten, deren Verhältnis zueinander sowie die Umgebung und die Kriterien, die das System-Design und seine Evolution bestimmen. Diese Definition hilft, zwei wesentliche Dimensionen von Architekturen zu erkennen: Welche Systeme werden betrachtet und welches Kriterium wird für die Strukturierung verwendet?

Dimension 1 – Ein Amt hat bereits eine Architektur: Wird das Amt selbst als System aufgefasst, so kann entsprechend der Definition auch hier eine Architektur identifiziert werden. Verallgemeinert bedeutet dies, dass neben der Software, die für eGovernment notwendig ist und die häufig im alleinigen Fokus einer SOA steht, auch die Behörden, Ämter, Institutionen, Organisationen und die Geschäftsprozesse eine Architektur besitzen.

Typische Beispiele solcher Architekturen sind Organigramme, Netzwerk-Architekturen und Zuständigkeitsmatrizen. Wichtig ist an dieser Stelle, dass solche Architekturen implizit schon immer bestehen, schließlich funktionierten die Öffentlichen Verwaltungen auch schon ohne SOA und IT. Was allerdings nicht immer existiert, ist die explizite Modellierung, das heißt, das Aufschreiben solcher Architekturen.

Dimension 2 – Mehrere Architekturen für ein Amt: Die obige Definition offenbart noch eine weitere Dimension des Architekturbegriffs. Für ein einziges betrachtetes System, etwa ein kommunales Melderegister, eignen sich unterschiedliche Architekturen zur Beschreibung – je nachdem, welches Kriterium für die Architekturbildung in den Mittelpunkt gerückt werden soll.

So sind für ein Amt zum Beispiel Zuständigkeitsarchitekturen, Vertretungsarchitekturen oder auch Prozessarchitekturen möglich. Für Software sind einerseits technologische Architekturen möglich, bei denen nach Software-Technologien wie etwa .Net, SQL oder Corba klassifiziert wird. Andererseits sind auch funktionale Architekturen denkbar, bei denen der Zweck eines Moduls die Komponentenbildung bestimmt, zum Beispiel der Einzug von Steuern oder die Verwaltung von Bürgerdaten oder Kraftfahrzeugen in Meldesystemen.

Ein einziges System besitzt daher eine Vielzahl unterschiedlicher Architekturen.

Häufig werden diese unterschiedlichen Architekturen als Architektursichten oder Architekturbeschreibungen bezeichnet. So nennen die eGovernment-Standards und -Architekturen des Bundes, SAGA (siehe Kasten), fünf unterschiedliche sogenannte „ViewPoints“. Im Kern handelt es sich allerdings tatsächlich um unterschiedliche Architekturen.

Nächste Seite: Qualität der Architekturen

(ID:2022877)