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

cit GmbH

USU Software AG

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

Qualität von Architekturen

Eine solch methodische Auseinandersetzung mit Architekturen stellt eine mächtige Möglichkeit dar, Architekturen für eGovernment-Projekte zunächst zu abstrahieren und dann sinnvoll einzusetzen. Außerdem hilft sie, eine Vielzahl gescheiterter SOA-Projekte zu verstehen, die ohne entsprechende Architekturendefinition durchgeführt wurden.

Damit kommt der Qualitätssicherung (QS) von Architekturen eine wichtige Rolle zu. Geschieht dies nicht, bleibt der Wert einer Architektur mittel- und langfristig unklar beziehungsweise gering. In diesem Fall sind Architekturen in der Tat nicht hilfreich und SOA kann wirklich als tot bezeichnet werden.

Syntaktische Qualitätssicherung – Klarheit vor Schönheit: Die syntaktische Qualitätssicherung von Architekturen ist die einfachste Ebene und betrachtet die einzelne Architektur, unabhängig davon, welches System und welches Kriterium ihr zugrunde liegt. Hier prüfen die Qualitätssicherer vor allem die Verständlichkeit und Konsistenz der verwendeten Notation. Diese folgt bestenfalls einem etablierten Standard wie zum Beispiel der Unified Modeling Language (UML).

Darüber hinaus gilt es, die Wartbarkeit der Architekturdokumentation zu prüfen, um Änderungen an ihr ohne größeren Aufwand vornehmen lassen zu können und sie werkzeugbasierend weiter zu verwenden.

Schließlich ist gerade die Portierbarkeit der Architekturdokumentation ein wichtiger Faktor. Diesbezüglich stellt die QS sicher, dass die Architekturbeschreibung mit den im jeweiligen Kontext vorhandenen Werkzeugen bearbeitet und zwischen den einzelnen Tools bestmöglich ausgetauscht werden kann.

Selbst auf dieser sehr einfachen Ebene zeigt die Praxis, dass viele Projekte Kardinalfehler machen, indem sie zum Beispiel eigene, nicht standardisierte Notationen erarbeiten, Legenden gar nicht oder nur unvollständig mitgeben oder die Architektur so ablegen, dass sie kaum mehr geändert werden kann. Ein Beispiel zeigt Abbildung 1: Bei dieser Darstellung ist völlig unklar, welche Bedeutung die unterschiedlich eingefärbten Pfeile haben, was die Storages sind (vermutlich Datenbanken) und warum es so viele Synchronizer gibt. Darüber hinaus ist das Dokument eine MS-Paint-Grafik, in der Bearbeitungen kaum oder nur sehr zeitaufwendig möglich sind. Eine solche Architektur stellt tatsächlich keinen echten Wert für das eGovernment dar. Auch eine SOA scheitert auf Basis solcher Grundlagen.

Semantische Qualitätssicherung – Fakten anstelle von Fantasie: Diese Ebene der Architektur-QS adressiert das Zusammenspiel einer konkreten Architektur mit dem realen System. Die Qualitätssicherung überprüft hier, ob die Architekturbeschreibung korrekt ist, ob also die Architekturbeschreibung mit dem realen System übereinstimmt.

Konkret bedeutet diese Sicht für die QS: Existiert für jedes Objekt der Architektur ein entsprechendes Objekt im realen System und umgekehrt?

Passen beide nicht zusammen, ist die Architektur entweder veraltet oder – häufiger – entstammt dem Wunsch und der Fantasie des Erstellers. Wenn die Architektur diesen Test bestanden hat, ist bereits hier eine Evaluation mit der eGovernment-Strategie möglich. Es kann also geprüft werden, ob die Architektur die Strategie bestmöglich unterstützt beziehungsweise wo Schwachstellen existieren.

In der Praxis von IT-Projekten finden sich genügend Beispiele, die das Fehlen dieser QS-Aktivitäten demonstrieren: Häufig sind Architekturen mehr das Ergebnis von Wünschen, die damit lediglich darstellen, wie die konkrete Struktur einmal sein könnte. Auch die für eGovernment besonders wichtige Software-Architektur ist vor diesen Fehlern nicht gefeit: Häufig finden sich sauber modellierte Schichtenarchitekturen mit wohl definierten Schnittstellen auf allen Ebenen, die allerdings kaum einen Bezug zum tatsächlichen, häufig eher chaotischen System aufweisen. Denn tatsächlich kommuniziert dort fast jede Komponente mit allen anderen.

Ein typisches Beispiel für die Abweichung zwischen dem Ideal einer Software-Architektur und dem realen System zeigt Abbildung 2. Insbesondere für diesen Bereich der softwaretechnischen Architekturen existiert eine Vielzahl von Werkzeugen, die eine Überprüfung zwischen Spezifikation und Ist-Zustand semi-automatisch durchführen können.

Nächste Seite: Strategische Qualitätssicherung

Strategische Qualitätssicherung

Diese Ebene der Architektur-QS adressiert das erste Mal wirklich die SOA, indem sie die Gesamtarchitektur (bestehend aus den vielen Einzelarchitekturen) einem umfassenden Check unterzieht. Es wird geprüft, ob die unterschiedlichen Architekturen aufeinander abbildbar sind und die so entstehende Kombination die übergreifende Geschäftsstrategie unterstützt. Dieser Schritt ist jedoch erst sinnvoll, wenn die beiden vorherigen Ebenen erfolgreich durchlaufen worden sind.

Auf diese strategische Ebene bezieht sich auch das Fanal der Burton Group: „SOA ist tot.“ Im Kern bezieht sich diese Aussage nicht auf die syntaktische oder semantische Architekturebene, denn diese müssen als Vorbedingung einer erfolgreichen SOA in jedem Fall existieren.

Vielmehr stellt die Aussage eine fehlende strategische Verankerung von Service-Orientiertheit in allen Architekturen heraus. Insofern weist sie darauf hin, dass Projekte oft versuchen, eine technische SOA-Architektur in einer Nicht-SOA-Organisation oder in einem Nicht-SOA-Umfeld zu etablieren. Dieses Risiko besteht gerade auch für eGovernment, bei dem es die Akteure mit einer äußerst vielschichtigen und dezentral ausgeprägten Service-Landschaft zu tun haben.

Dies spricht allerdings nicht gegen, sondern für Architekturen. Denn erst eine solche Architektur-Analyse unter strategischen Aspekten kann Risiken im realen Umfeld von Behörden aufdecken – seien es Mängel in der Ablauforganisation oder bei der Definition von zum Beispiel Antragsbewilligungen, dem elektronischen Bereitstellen amtlicher Dokumente oder nur der Terminvereinbarung bei der Meldebehörde über das Internet. Insofern stellen Architekturen ein wertvolles Hilfsmittel dar, um die bereits existierenden Prozesse und Systeme einer strategischen Analyse zu unterziehen und fortlaufend zu verbessern.

Die fünf Regeln für eine erfolgreiche SOA

Was bedeutet diese Analyse für eGovernment und deren SOA-Bestrebungen? Architekturen als Grundlage einer SOA können ein wichtiges Hilfsmittel zur Realisierung von eGovernment sein, wenn vor allem folgende fünf Regeln eingehalten werden:

• Identifikation der geeigneten Architektur-Menge: Es gibt mehrere Architekturen für ein System, die bestimmte Sichten realisieren. Die fünf in SAGA formulierten Architekturen stellen einen guten Startpunkt dar, sind aber durchaus um weitere Architekturen zu erweitern.
• Syntaktische QS jeder Architektur: Was für jedes andere Projektergebnis selbstverständlich ist, muss auch für Architekturen gelten: Vorgabe von Notations-Standards, Verarbeitungswerkzeugen und Architektur-Templates.
• Semantische QS jeder Architektur: Eine Architektur hat nur dann einen Wert, wenn ihre Beschreibung auch konform zur Realität ist. Viele, vor allen Dingen technische Architekturen, können heute bereits werkzeuggestützt verifiziert werden.
• Strategische QS aller Architekturen: Hier gilt es, die Synchronisierbarkeit der einzelnen Architekturen und ihr Zusammenspiel mit der Geschäftsstrategie zu überprüfen. Architekturen spielen gerade hier ihren größten Wert aus. Identifizierte Abweichungen sprechen nicht gegen Architekturen, sondern dafür, dass sie helfen, Schwachstellen zu erkennen. Methoden wie zum Beispiel die etablierte Architecture Tradeoff Analysis Method (ATAM) des Software Engineering Institute (SEI) unterstützen dieses Vorgehen.
• Verantwortung für Architekturen: All diese Aufgaben müssen sowohl für Inhouse-Entwicklungen als auch für beauftragte Projekte sichergestellt werden. Es ist die Aufgabe des Qualitätsmanagements innerhalb eines Amtes/einer Behörde oder eines Ministeriums, Architekturen wie andere Artefakte auch als schützenswerte Objekte zu verstehen und zu pflegen.

(ID:2022877)