Das Potential der Informations- und Kommunikationstechnologie (IKT) schafft neue Gestaltungsspielräume, um eine grundlegende Reform der Wechselbeziehung zwischen der Verwaltung und ihren externen sowie internen Anspruchsgruppen zu realisieren. Ein solcher anvisierter Wandel setzt eine überzeugende eGovernment-Vision voraus, die ihm eine klare Gestalt und Richtung gibt. Der Wandel muß zudem ein klares Vorgehen haben. Dazu bedarf es einer eGovernment-Strategie, welche eigenständige Programme identifiziert, priorisiert, plant und koordiniert.


Obwohl eGovernment eine Reihe von technischen Fragen anspricht, wird der Erfolg letztendlich davon abhängen, dass die geschäftlichen Motive für die technischen Entscheidungen stets im Auge behalten werden. Bei jeder Entscheidung sollte daher geprüft werden, ob und inwieweit sie zur Verbesserung der geschäftlichen Performance und zur Verwirklichung der Vision beiträgt.


eGovernment beschränkt sich nicht nur auf die Verbesserung der Beziehungen zwischen Bürger und Verwaltung über das Internet. Vielmehr geht es um viele Anwendungsformen und -generationen der IKT, die in Geschäfts- und Entscheidungsprozessen zusammenwirken und eine Verbesserung der Verwaltungsleistungen anvisieren.


Eine derart erweiterte Sicht von eGovernment macht deutlich, dass es im Regelfall nicht um die Nutzung von isolierten, sondern vielmehr um das Zusammenspiel unterschiedlicher Komponenten - wie z.B. Prozesse, Anwendungen, Daten, etc. - geht. Im Mittelpunkt steht damit das Thema eGovernment-Architektur. Diese Architektur liefert unterschiedliche Sichten auf die Verwaltungseinheit und ermöglicht es den Verantwortlichen das Gesamtsystem auf einer geeigneten Abstraktionsebene zu verstehen. Sie dient als Grundlage für die Entwicklung einer gemeinsamen Vision und Strategie für eGovernment.

Wenn im Zusammenhang mit eGovernment von Architektur gesprochen wird, dann geht es um die Beantwortung der Frage, wie die Geschäftsprozesse der Verwaltung durch Informatik- und Telekommunikationssysteme unterstützt werden. Informatik ist kein Selbstzweck, sondern Informatiksysteme sind so zu planen, dass sie die Abwicklung eines Geschäfts optimal unterstützen, gleichzeitig aber möglichst kostengünstig beschafft und betrieben werden können. Daher sind alle Informatiksysteme grundsätzlich in einem Geschäftskontext zu betrachten. Dieser Kontext besteht einerseits aus Geschäftsprozessen, andererseits aus der diese ausführenden Organisation und der örtlichen Verteilung (Standort). Das Informatiksystem selbst besteht aus Daten, einer oder mehreren Anwendungen und der diese Anwendungen unterstützenden Technologie.

Abb. 1: Geschäfts- und Informatiksichten der Architektur

Ziele und Ergebnisse der Architektur

Ziele der Architektur sind:

• nachvollziehbar und methodisch die zu erfüllenden funktionalen und nichtfunktionalen Geschäftsanforderungen durch ein Informatiksystem abzudecken,

 

• sicher und schnell die Integration von zukünftigen internen und externen Informatikmitteln in das bestehende Gesamtsystem zu ermöglichen und

 

• zielgerichtet und konsistent das bestehende Informatiksystem auf neue Geschäftsanforderungen anzupassen.

Dazu teilt die Architektur einerseits ein komplexes System in Komponenten ein und beschreibt deren Beziehungen und Abhängigkeiten. Auf der anderen Seite definiert sie für diese Komponenten Regeln, welche bei deren Design und Einsatz angewandt werden.

Einordnung der Architektur
Die Vision stellt die "Guidance" für alle am Systembau Beteiligten und für alle Systemkomponenten dar. Die entsprechende Strategie konkretisiert die Vision und zeigt den Weg für deren Realisierung auf. Um diese Strategie in alle benötigten Informatiklösungen einbringen zu können, lenkt die Architektur durch Regeln und Konzepte die Lösungen in eine gemeinsame Richtung.


Einflüsse auf die Architektur
Die Ausgestaltung der Architektur wird einerseits von Geschäftsanforderungen, andererseits von Technologien beeinflusst. Daher muss die Architektur auf Veränderungen der beiden Einflussfaktoren reagieren können. Veränderung bei den Geschäftsanforderungen entstehen auf Grund von politischen Entscheiden, gesetzlichen Anpassungen oder durch kontinuierliche Verbesserung der Verwaltungsprozesse. Für eGovernment relevant ist die Einführung, Verbreitung und Nutzung der internetbasierten Technologien. Auf Grund deren Weiterentwicklung entstehen neue Geschäftsbedürfnisse, welche wiederum die Ausgestaltung der Geschäftsprozesse beeinflussen und neue strategische Potentiale eröffnen. Nachfolgende Grafik verdeutlicht den obenerwähnten Regelkreis zwischen den Kräften und der Architektur:

Abb. 2 : Einordnung und auf die Architektur wirkende Kräfte

Architektur als begleitende Aktivität zum Projektportfolio
In der Realität kann eine Architektur nur in den seltensten Fällen vollständig erarbeitet werden, um dann als Richtlinie für zukünftige Projekte zu gelten. In der Regel werden durch Strategieüberlegungen, z.B. im Rahmen der Strategischen Informatik Planung (SIP), eine Vielzahl von Projekten im Rahmen eines Programms initiiert, welche von einem Architekturentwicklungsprojekt begleitet werden müssen. Dabei fliessen genauso Best Practices von Projekten in die Architektur ein, wie diese wiederum selbst Lösungen durch Architekturrichtlinien beeinflusst.

[<br>]
Abb. 3: Architektur als Begleiter der Projekte des Portfolios

Im Nachfolgenden wird das Fallbeispiel eGovernment-Architektur des Bundesamts für Energie (BFE) beschrieben. Das Bundesamt für Energie ist die Fachstelle für Fragen der Energieversorgung und der Energienutzung im Eidgenössischen Departement für Umwelt, Verkehr, Energie und Kommunikation (UVEK).Das Projekt wurde durch die Firma CSC Switzerland begleitet.


eGovernment im BFE
Im BFE begann man sich relativ früh mit eGovernment auseinanderzusetzen. Mit eGovernment sollte grundsätzlich folgendes erreicht werden:

• zielgerichtete Entwicklung von elektronischen Dienstleistungen für die Bürger/Kunden, Mitarbeiter und Partner/Lieferanten des Amtes.

 

• Steigerung der Effizienz, Transparenz und Nachvollziehbarkeit der Geschäftstätigkeit.

 

• Verhinderung von Einzelmassnahmen und Insellösungen sowie Sicherstellung eines gesamtheitlichen Ansatzes.

 

• bestehende Rollen- und Vorgehensmodelle auf die zukünftigen Anforderungen (z.B. zunehmende Integration der Anwendungen) ausrichten.

 

• kürzere Entwicklungszeiten in einem zunehmend komplexen und vernetzten Umfeld sicherstellen.

 

• Koordination und Abstimmung von laufenden und geplanten Projekten und Vorhaben inner- und ausserhalb des Amtes ermöglichen.

 

• Potentiale der neuen Technologien in einem übergeordneten Rahmen beurteilen und allenfalls zielgerichtet und nutzbringend einsetzen können.

eGovernment wurde von Beginn an nicht als einzelnes Projekt, sondern als Programm bestehend aus zahlreichen einzelnen aufeinander abzustimmenden Massnahmen und Projekten verstanden. Um diese Abstimmung auch langfristig sicherstellen zu können, wurde in einer ersten Phase eine eGovernment-Strategie entwickelt, welche die konkreten Ziele und deren Erreichung aufzeigte.


Warum eine eGovernment-Architektur für das BFE?
Im Rahmen der Erarbeitung der BFE eGovernment-Strategie wurde erkannt, dass zu deren Umsetzung ein übergeordnetes, unterstützendes Konzept zur Sicherstellung der zielgerichteten Gesamtintegration der einzelnen Komponenten unabdingbar ist. Eine zu detaillierte Planung des Wandels bedeutet aber eine Verschwendung von Energie und Ressourcen und hemmt den Fortschritt. Deshalb hatte sich das BFE im Rahmen des Projektes eGovernment-Architektur das Ziel gesetzt, basierend auf dem BFE eGovernment-Modell eine Architektur zu entwickeln, die detailliert genug war, um die Koordination von eGovernment-Vorhaben zu ermöglichen, gleichzeitig jedoch nicht so sehr ins Detail ging, dass sie die Entwicklung von Geschäftslösungen unnötig verzögerte oder behinderte.


Ziele der eGovernment-Architektur des BFE
Im Vordergrund des Projektes standen das Erfassen und Verstehen von geschäftlichen Erfordernissen. Die Geschäftsprozesse bildeten den Schwerpunkt der Analysetätigkeit, denn sie werden im BFE als Ausgangspunkt für die Verbesserung der Performance der Geschäftstätigkeit gesehen.


Dementsprechend verfolgte das Projekt eGovernment-Architektur die folgenden Zielsetzungen:

• Mit der eGovernment-Architektur verfügt das Amt über ein Hilfsmittel, welches die Verbindung zwischen der eGovernment-Strategie und den eGovernment-Lösungen sicherstellt.

 

• Die eGovernment-Architektur umfasst diverse Sichten auf das Gesamtsystem und ermöglicht den eGovernment-Verantwortlichen, die gemeinsame eGovernment-Vision und -Strategie weiter zu entwickeln.

 

• Die Architekturelemente der laufenden und geplanten eGovernment-Projekte werden berücksichtigt und integriert.

 

• Der grobe Entwicklungsbedarf (Soll-Architektur) und die Definition der Pakete für die eGovernment-Architekturentwicklung werden definiert.

 

• Rückkopplungen der Architekturergebnisse zur Weiterentwicklung der BFE eGovernment-Strategie sind dokumentiert.

Dem Projekt wurde das "Hexagon of Change" der Firma CSC zugrundegelegt. Die Architektur wird dabei im Rahmen der sechs Domänen des Wandels (Vgl. Abbildung 1) bearbeitet.
Die folgenden Vorgehensschritte wurden durchgeführt:

• Projektplanung
• Strategie-Analyse und Analyse der Rahmenbedingungen
• Erstellen der Ist-Prozessarchitektur
• Erstellen der Anwendungsarchitektur und Mapping mit den Prozessen
• Identifikation des Entwicklungsbedarfs und Definition von Paketen für die Architekturentwicklung

Folgende Ergebnisse wurden im Rahmen des Projektes erarbeitet:


A) Prozessarchitektur:
Die Prozessarchitektur definiert in Anlehnung an das BFE eGovernment-Modell den Führungsprozess, die Kern- und Unterstützungsprozesse und stellt somit eine Sicht der Geschäftsarchitektur dar. Querschnittsaufgaben werden im Rahmen der Kompetenzzentren wahrgenommen. In Abbildung 4 wird die BFE-Prozessarchitektur skizzenhaft dargestellt.

 

B) Leistungs- bzw. Produkteübersicht:
Im Vordergrund dieses Ergebnisses steht die Untersuchung der Leistungen bzw. Produkte der einzelnen Prozesse.


C) Prozesslandkarte:
Die Prozesslandkarte gibt einen Überblick über die Prozesse des BFE und stellt den Leistungsaustausch innerhalb des BFE als auch den Leistungsaustausch mit den Partnern/Lieferanten und Kunden/Bürgern grafisch dar.


D) Anwendungsarchitektur und Mapping der Anwendungen zu den Prozessen:
Die Anwendungsarchitektur zeigt die wichtigsten Anwendungen und deren Schnittstellen auf. In einem weiteren Schritt wurden die Prozesse mit den Anwendungen in Beziehung gesetzt. Schnittstellen und Berührungspunkte werden über den gesamten Wirkungsbereich (Geschäft und IT) ersichtlich. Dies ermöglicht es, allfällige Lücken in der elektronischen Unterstützung der Prozesse festzustellen.


E) Datenarchitektur:
Die Integration der geschäftsrelevanten Anwendungen im BFE ist aufgrund diverser Rahmenbedingungen nur zum Teil sinnvoll und realisierbar. Aus diesem Grund wurde im Moment auf die aufwendige Erarbeitung einer unternehmensweiten Datenarchitektur verzichtet.


F) Technologiearchitektur:
Die Technologiearchitektur wird in ihren Grundsätzen im Rahmen der Informatikstrategie und -architektur des Departements sowie des departementalen Leistungserbringers vorgegeben. Weiter werden im Rahmen der Kernprojekte der BFE eGovernment-Strategie weiterführende technologische Grundlagen (insbesondere im Bereich der Plattform) erarbeitet. Die Projekt-Ergebnisse werden zu einem späteren Zeitpunkt als Bestandteil in die Architektur aufgenommen.


G) Entwicklungsbedarf eGovernment-Architektur (Soll-Architektur):
Auf der Basis von geschäftsrelevanten Kriterien wurde der aktuelle Zustand kritisch gewürdigt und der Entwicklungsbedarf eruiert.
H) Rückkopplung auf die eGovernment-Strategie:
Die eGovernment-Strategie wurde aufgrund des aktuellen Wissensstandes geprüft und es wurden Empfehlungen für deren Anpassung formuliert.

Im Zusammenhang mit dem oben beschriebenen Projekt konnten folgende
kritische Erfolgsfaktoren identifiziert werden:

• Bereitschaft der obersten Führungsebene das Projekt und dessen Umsetzung aktiv zu unterstützen.

 

• Das Potential des "e" führt zu Veränderungen des Geschäfts. Um das Potential voll ausschöpfen zu können, braucht es die Bereitschaft, die bisherigen Prozesse zu verändern bzw. anzupassen.

 

• Solche Veränderungen führen zu Widerständen, was ein professionelles und konzeptionelles Change-Management unabdingbar macht.

 

• Die Architektur ist als begleitendes, unterstützendes und helfendes Konzept zur Unterstützung des Entwicklungsprozesses zu verstehen.

 

• Die Architektur muss parallel zu den laufenden Projekten und Vorhaben entwickelt werden können.

 

• Das Rollenmodell von NOVE-IT auf der Leistungsbezügerseite ist mit den Rollen der Geschäftsseite zu erweitern.

Die Realisierung und Optimierung von elektronischen Dienstleistungen kann nur sinnvoll praktiziert werden, wenn die zu untersuchende Verwaltungseinheit unter einem ganzheitlichen Ansatz betrachtet wird. Das "e" von eGovernment beinhaltet demnach nicht nur die reinen elektronischen Dienstleistungen sondern das Optimieren und somit die Steigerung der Effizienz und der Effektivität der gesamten Verwaltungseinheit. Ausgehend von dieser ganzheitlichen Sichtweise benötigt man eine Vision, eine Strategie und eine Architektur. Letztere ermöglich es allen Beteiligten die nachvollziehbare, zielgerichtete, sichere und konsistente Anpassung der Informatikmitteln an die neuen geschäftlichen Anforderungen.