[Hier nun auch die vollständige Version des Artikels zu offenen Architekturen – ursprünglich am 07.02.2013 im 21stCenturyIT-Blog von CSC veröffentlicht.]

Die Ideen und Vorschläge von Open Government liegen bereits einige Jahre auf dem Tisch. Mittlerweile ist auch die logische Konsequenz verstanden, dass in einer Gesellschaft, deren Mitglieder sich ganz selbstverständlich in allen Bereichen des Alltags vernetzen, auch deren Administration, die öffentliche Verwaltung, gezwungen ist, sich einer Vernetzung nach innen und nicht zuletzt nach außen zu öffnen.

Open Government ist eine vielschichtige Herausforderung. Es ist kein rein ideologisches oder politisches Thema. Es ist ein strategisches Vorhaben, das eine nutzenorientierte Öffnung auf allen Ebenen der Verwaltung in allen Bereichen ihres Agierens und Interagierens erfordert. Dazu sind Veränderungen in der Organisation, in der Art und Weise, wie die Verwaltungsmitarbeiter mit internen und externen Beteiligten zusammenarbeiten und kommunizieren, also der Arbeits-, Geschäfts- und der Kommunikationsprozesse erforderlich.

Hier kommt die IT ins Spiel. Denn es ist ihre Aufgabe, die für die Abbildung der Prozesse erforderliche technische Umgebung und die erforderlichen Verfahren bereit zu stellen. Open Government, eine vernetzte Verwaltung benötigt eine geeignete Infrastruktur, eine offene Architektur.
Bisher haben wir es in der IT noch nicht geschafft, unseren Beitrag zu Open Government zu leisten: eine solche offene Gesamtarchitektur technisch zu realisieren.

Es reicht nicht, ein Open-Data-Portal hier, einen Bürgerhaushalt dort und einen mobilen Schlaglochmelder da ins Netz zu stellen. Für eine offene Verwaltung müssen wir eine offene technische Infrastruktur schaffen, in der Verfahren und Daten mit anderen internen und externen Verfahren und Daten vernetzt werden können.

Wird eine Anwendung zum Anliegenmanagement – wie zum Beispiel Märker Brandenburg oder FixMyStreet – bereitgestellt, erwarten die Nutzer, dass eingehende Meldungen der Bürgerinnen und Bürger direkt an die zuständigen Sachbearbeiter in der Kommunalverwaltung übergeben werden. Gleichermaßen wird erwartet, dass jederzeit der aktuelle Bearbeitungsstand einer Meldung auf der Website nachvollziehbar ist. E-Mails mit den eingehenden Meldungen zu verschicken oder kommunalen Redakteuren die Weitergabe zu übertragen und den Bearbeitungsstatus in der Website pflegen zu lassen, sind hier kein angemessener Ansatz. Vielmehr müssen die Meldungen und die Aktualisierung der entsprechenden Bearbeitungsstati nahtlos in den alltäglichen Arbeitsprozess der Verwaltung integriert sein.

Im Beispiel bedeutet das, dass das interne Vorgangsbearbeitungssystem mit dem öffentlichen Anliegenmanagementsystem bidirektional gekoppelt werden muss, will man die entsprechenden Prozesse angemessen effizient und transparent realisieren.

Schon bei diesem einfachen Szenario wird deutlich, dass die technische Unterstützung für Open Government keine triviale Sache für die IT ist. Zur Umsetzung braucht es fähige Architekten und geeignete Architekturansätze.

Mit diesem Artikel möchte ich skizzieren, welche Entwurfsmuster die IT-Architekten im Public Sector anwenden müssen, um ein tragfähiges Fundament zum Auf- und Ausbau von Open Government zu legen.

Die beiden für eine offene Architektur wichtigsten Paradigmen sind

  • das Prinzip der losen Kopplung
  • das Prinzip der kompromisslosen Modularisierung

Lose Kopplung mit serviceorientierten Web-APIs

Um für eine Aufgabenstellung geeignete Lösungsansätze zu finden, ist es nicht nur in der IT ein wichtiges Prinzip, sich nach Lösungen umzuschauen, die ähnliche Herausforderungen bereits erfolgreich meistern. Man sucht nach praktisch Bewährtem, nach „Best Practices”. Bei der Frage, welche Lösungen sich durch ihre fachliche und technische Offenheit und Vernetzung auszeichnen, bieten Anwendungen des Web 2.0 einen interessanten Ansatz. Diese Anwendungen zeichnen sich – wie dessen Nutzer – durch ihre ausgeprägte Offenheit und Fähigkeit zur Vernetzung aus. Genau diese Eigenschaften müssen wir in unserer offenen Architektur implementieren, indem wir die technischen Konzepte des Web 2.0 adaptieren.

Zentrales Entwurfsmuster der Architektur vieler Web-2.0-Anwendungen ist das der losen Kopplung über Schnittstellen. Diese Schnittstellen, sogenannte Web-APIs (Application Programming Interfaces, Programmierschnittstellen), bieten ausschließlich granulare, zustandslose Operationen als Dienste an.

Granular ist eine Operation, wenn sie eine nicht sinnvoll weiter zerlegbare Funktion bereitstellt. Im einfachsten Fall sind dies sogenannte „CRUD”-Operationen (Create/Read/Update/Delete) für die relevanten Fachobjekte oder eine generische Operation zum Absetzen einer Suchanfrage über die Fachdaten. So ist beispielsweise eine Operation zur Einreichung eines Antrags granular (und stellt eine „Create-Operation” dar).

Zustandslos ist eine Operation, wenn sie in sich funktional abgeschlossen ist, sprich dass eine fachliche Transaktion sich nicht über mehrere technische Funktionen der Schnittstelle erstreckt, sondern durch den Aufruf genau einer Operation erledigt ist.

Um Web-APIs mit granularen, zustandslosen Operationen umsetzen zu können, ist es notwendig, dass auch die dahinter stehende fachliche Funktionalität streng modularisiert wird. Dazu ist die fachliche Logik in klare Einzelaufgaben zu unterteilen und entsprechend in getrenntem Code zu implementieren.

Kompromisslose Modularisierung – Trennung von Verfahrenskern, API und Verfahren

Bei dem Entwurf eines neuen IT-Verfahrens ist darauf zu achten, dass die Lösungsarchitektur einen Verfahrenskern vorsieht, der als Dienstleister (Service-Provider) ausschließlich die fachlichen Funktionalitäten (und Daten) kapselt und über eine serviceorientierte Web-API bereitstellt. Der Verfahrenskern ist kein Fachverfahren. Fachverfahren sind in dieser Konstellation Konsumenten der Dienste des Kerns, auf die sie ausschließlich über dessen Web-API zugreifen.

Die Trennung von Verfahrenskern und konkreten Verfahren ist absolut und konsequent anzuwenden: Wird für Anwender eine grafische Oberfläche benötigt, ist auch diese „nur” ein Konsument der Dienste des Kerns – selbst wenn dies im ersten Schritt das einzige Verfahren sein sollte, das sich den Diensten des Verfahrenskerns bedient. Das bringt zusätzliche Vorteile: Es kann für unterschiedliche Benutzergruppen die jeweils passende Benutzeroberfläche angeboten werden. Heimarbeiter könnten einen Webbrowser, Kollegen im Außendienst einen Tablet-PC, „Power-User” vor Ort einen Rich-Client für ihre Arbeit nutzen: all diese Client-Lösungen greifen auf den gleichen Verfahrenskern zurück.

Für bestehende Fachverfahren ist zu prüfen, ob sie über Systemintegrationsschnittstellen verfügen, vor die eine servicebasierte Web-API geschaltet werden kann. Dann ist es möglich, zumindest das eine oder andere „historisch gewachsene” System in eine IT-Strategie der Offenheit einzubinden und dabei bereits erfolgte Investitionen für die geplante „Restlaufzeit” zu sichern.

Gleichzeitig erlaubt dieses Vorgehen, Funktionalitäten und Daten, für die dies angemessen ist, zur externen, freien Nutzung bereit zu stellen. Hierzu ist in dem Teil der IT-Infrastruktur, der über das Internet erreichbar ist, ein Service-Proxy oder „Schnittstellenserver” einzurichten. Dieser publiziert ausschließlich die „öffentlichen” Teile der Web-APIs im Web und kann über Cybersecurity-Mechanismen, -Werkzeuge und -Methoden abgesichert, gehärtet werden. Ggf. ist es auch möglich bzw. sinnvoll, hierbei dedizierte Komponenten des dahinter liegenden Verfahrenskerns einzusetzen.

Web-APIs werden mit leichtgewichtigen Technologien wie Webservices über SOAP (Simple Object Access Protocol) oder REST (Representational State Transfer) umgesetzt. Diese passen sich optimal in sichere und hochverfügbare Enterprise-IT ein, da sie inhärent solide Lastverteilung, Skalierbarkeit, Sicherheitsmechanismen und Cloud Computing unterstützen – schließlich wurden sie in einem Umfeld, dem Web 2.0, entwickelt, in welchem diese Aspekte essentiell sind.

Die Einführung einer Architektur für Offenheit mit Hilfe von Web-APIs und kompromissloser Modularisierung …

  • … setzt Prozesse bedarfsgerecht mit serviceorientiert orchestrierten Diensten um.
  • … optimiert Wiederverwendung und Wartbarkeit der IT-Fachverfahren.
  • … sichert bereits getätigte Investitionen.
  • … ermöglicht die bedarfsgerechte und effiziente Vernetzung der Verwaltung nach innen und nach außen.
  • … unterstützt die sichere Umsetzung von Open Government und Open Data.
  • … erschließt Synergieeffekte intern und extern verknüpfter Wertschöpfungsketten.

Die beiden beschriebenen Grundprinzipien sind dazu geeignet, offene Architekturen sicher, performant und verlässlich in den IT-Infrastrukturen der öffentlichen Verwaltung zu schaffen und Open Government endlich Realität werden zu lassen.

Wir haben die Technologie. Wir müssen sie nur anwenden. Für eine offene, vernetzte Verwaltung.