eGovernment und softwareorientierte Architektur (SOA) SOA zeigt Praxistauglichkeit im Land Berlin

Autor / Redakteur: Dirk Meyer-Claassen / Gerald Viola

Mit der Einführung einer serviceorientierten Standardsoftware und der Integration von bestehenden eGovernment-Diensten konsolidiert das Land Berlin die Sachbearbeitungsunterstützung für die bauordnungsrechtlichen Verfahren aller Berliner Bezirke (Projekt eBG – Elektronisches Bau- und Genehmigungsverfahren). Durch die föderale Heterogenität der Organisation, der Software- und Netzlandschaft in den Anwendungsbereichen beweist eine konsequente serviceorientierte Softwarearchitektur ihre integrative Stärke in der Einführung und im Betrieb.

Firmen zum Thema

Betriebsumfeld
Betriebsumfeld
( Archiv: Vogel Business Media )

Die Geschäftsprozesse in der Berliner Bauaufsicht sind charakterisiert durch die Notwendigkeit an Zugriffen auf verschiedene Informationsbasen (Objektinfo, Umweltinfo, Personeninfo, …) und durch die Beteiligung von mehreren internen und externen Behörden und Dienststellen. Nebenbei stehen die Genehmigungs- und Überwachungsprozesse stark im politischen und wirtschaftlichen Fokus. Das Land Berlin hat deshalb mit eBG ein zukunftsweisendes Projekt gestartet. Wichtige Zielsetzungen hierfür waren:

  • Vereinheitlichung der verschiedenen organisatorischen Prozesse in den Bezirken mit Zusammenführung übergreifender Fach-/Anwendungsadministration an einer zentralen Stelle.
  • Bereitstellung einer zentralen Anwendung für alle Bauaufsichtsbehörden (inklusiv Migration aller Vorgänge), Datenhaltung je Bezirk in einem eigenen Mandanten.
  • Integration von Landesdiensten, um möglichst redundanzfrei zu arbeiten.
  • Berücksichtigung dezentraler Strukturen der Bezirke und deren eigenverantwortlicher Selbstständigkeit in IT-Themen (Ausstattung, Sicherheit).

Bereits beim Aufbau des Betriebsumfelds zeigen sich die Vorteile von SOA. Die jeweiligen Dienste werden auf zentralen Servern betrieben und können leicht standortübergreifend bereitgestellt werden.

Als Einsatzvoraussetzungen auf den Clients wird nur ein aktueller Browser mit Java Runtime benötigt sowie zur Dokumentbearbeitung MS Office oder OpenOffice. Die eBG-eigenen Dienste werden in einem Rechenzentrum der Deutschen Telekom betrieben, die Berliner Landesdienste im Landesnetz Berlin. In der Abbildung „Betriebsumfeld“ ist das grob dargestellt.

Nächste Seite: Implementierungen nach Standardvorgaben

Implementierungen nach Standardvorgaben

Für das organisatorische und technische Betriebsumfeld wurde ein umfangreiches Betriebs- und Sicherheitskonzept erstellt. Auch hierfür stellen die orchestrierten Einzeldienste keine Nachteile gegenüber den monolithischen Einzellösungen dar. Vielmehr besitzen sie den Vorteil, dass sie auf Standardvorgehen und Implementierungen beruhen, für die bereits umfangreiche Risikountersuchungen vorliegen. Für die Integration von bestehenden Systemen zeigt sich auch der Vorteil, dass alle Anbindungen am Server erfolgen und somit bis zum unsicheren Client keine Freigaben erfolgen müssen.

Nächste Seite: Eigene Dienste im Echtbetrieb

Eigene Dienste im Echtbetrieb

Eine diensteorientierte Architektur lebt natürlich von der Verfügbarkeit von möglichst vielen und effektiven Services, die man orchestrieren kann. Diese müssen beschafft und für bestehende Systeme aufgebaut werden.

Dies ist ein Prozess, der im Land Berlin noch einiges an Energie fordern wird, beispielsweise zur Einführung der elektronischen Signatur.

Vorteilhaft war bei der Einführung, dass man sich immer an den konkreten fachlichen Prozessen orientierte. Diese wurden zunächst berlinweit auf der Grundlage der gesetzlichen Vorgaben erfasst und in einem optimierten Prozesskatalog zusammengeführt. Dadurch benötigte man beispielsweise für die Anbindung der bestehenden Fachanwendungen keine 100-prozentigen Services (alle Funktionen), sondern nur überschaubare Einzelfunktionen, für die man dann wirtschaftliche Einstiegslösungen schaffen kann.

Für den aktuellen Echtbetrieb in den zwölf Bezirken werden folgende eBG-eigenen Dienste verwendet:

  • Kerndienste im Fachverfahren beispielsweise Dokumentenerstellung, Statusdienst, Fristendienst, Antragsmanagement, Gebührendienst: Einzelansteuerung für die Orchestrierung der Aufgabenlisten innerhalb der Vorgänge.
  • Mandantenübergreifender Stammdatendienst: Einheitliche zentrale Datenpflege mit Bereitstellung für alle Mandanten, beispielsweise für Vorgangstypen, Dokumentvorlagen, Textbausteine, Aufgabenlisten.
  • Elektronischer Aktendienst für die Verwaltung aller Vorgangsdokumente: Aktendarstellung und Weitergabe an verschiedene Systeme zur einheitlichen Vorgangs- und Objektverwaltung.
  • DMS Dienst – Versionierte Ablage und Archivierung: Für die gesicherte Langzeitarchivierung und die online Bereitstellung aller Vorgangs- und Objektdokumente.
  • Scandienst: Für die Übernahme von Papierdokumenten in die elektronische Sachbearbeitung.
  • Integrationsbus mit der Möglichkeit des erweiterten Workflowmanagements und der Zusammenarbeitsoption mit anderen BPEL-Systemen: Orchestrierungsplattform mit Steuerungsfunktion für die arbeitsteiligen Prozesse (beispielsweise elektronische Ämterbeteiligung).

Ferner wurden folgende Dienste des Landes Berlin integriert:

  • Kassenverfahren ProFiskal:

Direkte Übergabe von Gebührenrechnungen.

  • Räumliches Bezugssystem (RBS):

Übernahme von Adressen aus dem RBS in das Fachverfahren eBG.

  • Fächerübergreifendes Informationssystem (FIS-Broker):

Direkter Aufruf von weiteren geobasierenden Informationen zu einem Grundstück direkt aus dem Fachverfahren eBG (beispielsweise Bebauungsplan usw.).

  • Planviewer (Oracle AutoVUE als serverbasierender Dienst mit DMS-Integration):

Komfortable Planbearbeitung (bis A0) mit Verwaltung von Planänderungen in der Vorgangsakte.

In den nächsten Stufen sind noch folgende Landesdienste zu integrieren.

  • Dienste für die EU-DLR (Portal),
  • Formularservices mit aktiver Plausibilisierung aus den Fachdaten,
  • Elektronische Signatur (Einzel- und Amtssignatur),
  • Konvertierdienst: einheitliche gesicherte Konvertierung von Dokumentenformaten (beispielsweise .doc to PDF/A),
  • Stammdatendienste für externe Datenquellen (Architektenkammer),
  • Baulastenverzeichnis im GIS.

Nächste Seite: Erfahrungen und Fazit

Resümee

Aufgrund der Erfahrungen bei den Prozessunterstützungen in der Berliner Bauaufsicht kann festgestellt werden: Serviceorientierte Architekturen sind keine Utopie mehr. IT-Fachverfahren müssen heute nicht mehr als monolithische Systeme realisiert, sondern können aus verschiedenen Komponenten und Diensten „orchestriert“ werden.

Nach einer Projektlaufzeit von mehr als zwei Jahren und der erfolgreichen Überführung der Bezirke in den Echtbetrieb fällt die Bilanz über die Stärken und Schwächen der SOA-Technologie positiv aus, vor allem, was die Architektur der Plattform angeht. Das Land Berlin ist unabhängiger als bisher von den Produkten einzelner IT-Anbieter und kann definierte Dienste für die Zusammenarbeit mit allen Beteiligten (Bürger, Fachstellen, EAP – einheitlicher Ansprechpartner) bereitstellen.

Man verfügt über eine einheitliche Plattform, die sich einfach warten und problemlos weiterentwickeln lässt. Neben den Aufgaben der Berliner Bauaufsicht können zukünftig weitere Prozesse in der Berliner Verwaltung mit den eBG-Modulen abgebildet werden. So könnten Aufgaben der Denkmalbehörden oder nach dem Sanierungsrecht kurzfristig im eBG abgebildet werden.

Das Projekt eBG stellt daher als ein Leitprojekt im Regierungs- und Modernisierungsprogramm „ServiceStadt Berlin“ einen weiteren wesentlichen Meilenstein für den Aufbau einer serviceorientierten eGovernment-Architektur für das Land Berlin dar.

Zusammenfassend kann man feststellen, dass die Einführung einer SOA in der Bauverwaltung gute Potenziale für die wirtschaftliche Bewältigung der vielfältigen Organisations- und Koordinationsaufgaben bietet.

Klar ist jedoch, dass für die Orchestrierung eine vorgeschaltete Prozessanalyse mit Wirtschaftlichkeitsbetrachtung für die einzelnen Dienste absolut notwendig ist. Nur dadurch können die wirklichen Kerndienste lokalisiert und priorisiert werden.

Dieser Beitrag erschien zuerst im Dezember 2009 im „eGovernment Kompendium 2010“. Der „Call for Papers“ für das „eGovernment Kompendium 2011“ startet am 21. Juni 2010.

(ID:2041962)