Jusletter IT

Die E-Government-Architektur Schweiz wurde durch die Swiss eGovernment Architecture Community, eine Fachgruppe von eCH¹ , erarbeitet. Im Rahmen der Studie² «E-Government Architektur Schweiz im internationalen Vergleich» haben wir sie durch den Vergleich mit entsprechenden Architektur-Konzepten aus anderen Ländern validiert. Die Erkenntnisse aus der Studie dienen dem Wissensaufbau für die Weiterentwicklung der E-Government-Architektur Schweiz aufzubauen.

Die E-Government-Architektur der Schweiz war Ende 2010 in der Vernehmlassung bei eCH. Die Architektur besteht aus aktuell vier Dokumenten:

• Architekturübersicht E-Government Schweiz (eCH-0122)
  
• Übersicht über die E-Government-Architektur: Vertrieb (eCH-0123)
  
• Übersicht über die E-Government-Architektur: Produktion (eCH-0124)
  
• Übersicht über die E-Government-Architektur: Kommunikation (eCH-0125)
  

Im Rahmen dieses Artikels wird auf die Architekturübersicht eingegangen.

In der Studie standen die folgenden Fragen im Zentrum:

• Lassen sich die Architektursichten und deren Inhalt durch den Vergleich mit nationalen bzw. internationalen Architekturen validieren?
  
• Ergeben sich aus unterschiedlichen Definitionen in verschiedenen Ländern allfällige Interoperabilitätsprobleme?
  
• Welche guten Definitionen könnten allenfalls für die Schweiz übernommen werden?
  

In einem ersten Entwurf wurde ein Vergleich mit Deutschland erstellt. In einem zweiten Schritt wurden weitere Architektur-Konzepte in den Vergleich mit einbezogen.

Aufgrund der Priorität der Verhinderung potentieller Interoperabilitätsprobleme durch die Erkenntnisse aus der Studie lag der Fokus unseres Architekturvergleichs auf dem europäischen Umfeld und dabei insbesondere auf den Nachbarländern der Schweiz. Für die Identifikation von guten Ideen für die Weiterentwicklung der E-Government-Architektur Schweiz wurden zudem weitere Quellen berücksichtigt.

Die nachstehende Tabelle gibt einen Überblick über die für den Vergleich betrachteten Architekturen.

Deutschland	Aufgrund der sprachlichen und geografischen Nähe der Schweiz zu Deutschland wurde der nördliche Nachbar in der ersten Phase als Pilot analysiert.
Frankreich	Aufgrund der geografischen Nähe zur Schweiz wurde Frankreich als Vergleichsobjekt analysiert. Der zentralistische Ansatz in Frankreich bildet einen Gegensatz zu den eher demokratisch/föderalistischen Vorhaben in der Schweiz oder auch in Deutschland.
Italien	Aufgrund der geografischen Nähe zur Schweiz bestand zu Beginn die Absicht, Italien in der Studie zu berücksichtigen. Dokumente zur italienischen E-Government Architektur waren allerdings nur schwer zugänglich bzw. beinhalten nicht die für die vorliegende Studie relevanten Informationen. Interessant sind Dokumentationen, welche Überlegungen zum Disaster Recovery- und dem Business Continuity Management aufzeigen, da diese in der Schweiz bisher nicht berücksichtigt werden.
Österreich	Österreich ist das Nachbarland, das in E-Government, mindestens gemäss Capgemini-Studie3 , eine führende Position hat.
Europäische Union	Die Europäische Union unternimmt grosse Anstrengungen, um im Sinne einer länder-übergreifenden Öffnung möglichst viele Hürden abzubauen und Behördenleistungen aller Länder für Bürger und Unternehmen auch in ihrem Ursprungsland dank E-Government zugänglich zu machen.
Niederlande	Niederlande4 ist mit NORA (Nederlandse Overheids Referentie Architectuur) nun bereits an der dritten Version seiner E-Government-Architektur.
Russland	Russland ist ein Einsteiger in eGovernment, der die neuen Entwicklungen und die neuesten Ergebnisse (in vielen Fällen Best Practice) in diesem Gebiet aus der ganzen Welt benutzt.

Gemäss IEEE1471⁵ wählt eine Architekturbeschreibung verschiedene Viewpoints, die verschiedene Stakeholder adressieren. Die zu den Viewpoints zugehörigen Views bestehen aus allenfalls mehreren Modellen. Verschiedene Elemente dieser Modelle können in verschiedenen Sichten dargestellt sein.

Bei der Betrachtung der verschiedenen Architekturen fällt allerdings auf, dass diese zum einen solche Begrifflichkeiten nicht verwenden, auf der anderen Seite aber auch sonst vielfach wesentliche Elemente aus IEEE1471 vermeiden. Die Sichten der Architekturen sind selten benannt und die Stakeholder einer Sicht werden nie erwähnt. Zudem wird bei den Architekturen nie explizit zwischen Modellen und zugehörigen Sichten unterschieden. Insofern besteht hier noch viel Potential zur Verbesserung der E-Government-Architekturen. In den folgenden Abschnitten werden einige zueinander passende Sichten miteinander verglichen.

Die Geschäftsfähigkeiten der Partner aus der Schweizer Architektur sind Informationen finden, Leistung beziehen, Geld transferieren und Sicherheitsanforderungen erfüllen (vgl. Abbildung 1).

Abbildung 1: Modell der Geschäftsfähigkeiten für Partner (eCH-0122)

Die Sicht aus Österreich, die der Sicht in Abbildung 1 am nächsten kommt, ist in Abbildung 2 dargestellt. Dabei sind einige Differenzen zwischen den beiden Artefakten zu finden. Die Schweizer Architektur stellt einevollständige Aufzählung aller Partnerfähigkeiten über zwei Ebenen vor. Dagegen umfasst die österreichische Darstellungbeispielhaft Partner, eine Sequenz von fünf Geschäftsfähigkeiten der Partner sowie die zugehörigen Plattformen .

Abbildung 2: Typischer E-Government Musterprozess⁶

Zudem fallen auch inhaltlich wesentliche Differenzen auf, indem zum Beispiel die beiden Prozesse «Ausfüllen» und «Abholen» aus dem Österreicher Prozess in der Schweizer Variante Teil der Fähigkeit «Informationen senden und empfangen» sind.

Grundsätzlich kann nach beiden Konzepten Lösungen gebaut werden. Die Wahrscheinlichkeit, dass Realisierungen nicht international verwendet werden können und diese zudem nicht interoperabel sind, ist allerdings sehr hoch.

Abbildung 3 stellt den Schweizer Ablauf eines Verwaltungsverfahrens dar. Dieses teilt sich in die zwei Phasen Leistungszugang und Leistungsbezug und umfasst die Kunden- und die Behördensicht.

Abbildung 3: Verwaltungsverfahren im E-Government Schweiz (eCH-0122)

Beim Vergleich mit Abbildung 1 fällt auf, dass es bei der vorliegenden Schweizer Architektur noch schwer fällt, den Bezug zwischen den verschiedenen Sichten herzustellen. Dies gelingt in der niederländischen Architektur NORA⁷ besser, die inzwischen in Teilen bereits in der dritten Version vorliegt. Abbildung 4 zeigt eine statische Sicht auf die Leistungserbringung nach NORA.

Abbildung 4: Erbringung von Leistungen nach NORA⁸

Die Farben «weiss» für Kunde, «blau» für Distribution, «orange» für Produktion und «grau» für Register wird über weite Strecken durchgezogen. Dies gibt eine gute Orientierung beim Vergleich verschiedener Sichten. Auch in NORA wird aber das Zusammenspiel verschiedener Akteure und Komponenten fast ausschliesslich beispielhaft dargestellt und das Architekturprinzip selten explizit gemacht. Abbildung 5 übernimmt die Färbung aus NORA und zeigt, wie die Schichtenarchitektur explizit dargestellt werden könnte.

Abbildung 5: Schichten des Organisationsmodells⁹

Das Thema der Interoperabilitätsebenen wurde bereits an der IRIS 2009¹⁰ thematisiert. In eCH-0122 wird von drei Interoperabilitätsebenen gesprochen:Organisatorische, Semantische und Technische Interoperabilität . Dies entspricht den Definitionen von EIF 1.0¹¹ .

Die französische Architektur spricht dagegen von sechs Interoperabilitätsebenen (vgl. Abbildung 6).

Abbildung 6 Die sechs Interoperabilitätsebenen aus Frankreich¹²

Die verschiedenen zum Teil sehr ähnlichen Konzepte spiegeln sich sehr gut in der Entwicklung auf der EU-Ebene. EIF1.011 ist ein breit akzeptiertes Dokument, dessen Überarbeitung zu einer Version 2.0 allerdings in den letzten zwei Jahren nicht abgeschlossen werden konnte.

Das Thema der legalen und politischen Interoperabilität im EIF-Entwurf V2.0¹³ wurde durch Länder wie Frankreich bereits aufgegriffen. Frankreich separiert zusätzlich noch die technische von der syntaktischen Interoperabilitätsebene. Die zusätzlichen Ebenen sprechen wesentliche Themen an, die oft nicht im Blickfeld der involvierten Personen (insbesondere solchen aus dem technischen Bereich) liegen.

Das Europäische Forschungsprojekt STORK setzt sich eine einheitliche und interoperable Infrastruktur für den elektronischen Identitätsnachweis zum Ziel. Die elektronische Identität soll in 13 Ländern landesgrenzen-übergreifend für die Identifikation und Authentifikation bei der Verwendung von öffentlichen Diensten pilotiert werden. STORK dient als Kristallisationspunkt für elektronische Identitätsinitiativen in der EU, die den Bürgern erlaubt, ihre Identität zu beweisen und nationale elektronische Identitätssysteme (Passwörter, ID-Karten, …) auch ausserhalb ihres Wohnlandes zu verwenden. Dazu sollen die bestehenden Lösungen integriert werden.

Das Projekt STORK hat zwei verschiedene Architekturgrundsätze integriert, um die Interoperabilität der eID’s europaweit garantieren zu können. Beim Middleware-Ansatz verbinden sich die Länderlösungen über die Infrastruktur, um Daten auszutauschen. Alle Middleware-Länder kommunizieren über einen standardisierten Eingangspunkt und so direkt mit dem STORK-Framework. Der Proxy-Ansatz verwendet für jedes Land einen eigenen Zugangspunkt. Der national-spezifische Server kommuniziert danach mit dem STORK-Framework.

Um die Schweizer Identitätslösung SuisseID¹⁴ interoperabel zu machen, ist es daher notwendig, die SuisseID über einen dieser beiden Ansätze mit STORK zu integrieren. Hilfreich dafür ist, dass beide Ansätze auf der gleichen technischen Basis SAML 2.0¹⁵ basieren.

Abbildung 7 STORK Architektur¹⁶

Auf der semantischen Ebene sind auf der Basis von unterschiedlichen organisatorischen und legalen Ausgangslagen weitere Probleme zu erwarten. Als Beispiel im Kontext von Person sei hier Russland erwähnt, wo es juristischen Personen möglich ist, Leistungen zu beziehen, die in andern Ländern natürlichen Personen vorbehalten sind (z.B. Visum beantragen).

Für das Beschaffungswesen arbeitet das Projekt PEPPOL¹⁷ mit viel Aufwand an der Integration des Beschaffungswesens der verschiedenen Länder. Dazu wurde die gemeinsame Kommunikationsschiene BUSDOX zum Austausch von Geschäftsdokumenten zwischen Behörden und Unternehmen auf technischer Ebene realisiert.

Sowohl STORK für die gemeinsame Verwendung von Daten wie PEPPOL für die Umsetzung eines Behördenprozess zeigen, wie schwierig es ist, behörden- und landesgrenzen-übergreifend Interoperabilität zu erreichen. Die EU arbeitet in diesen Projekten nun bereits mehrere Jahre in multinationalem Kontext an der Behebung dieser Interoperabilitätsprobleme und will diese Bemühungen bis 2015 fortsetzen. Verschiedene erfolgreiche Architekturlösungen aus diesen Projekten sollen als Plattform für andere Bereiche verwendet werden und so auch zur Ausbreitung anderer Anwendungen beitragen.

Sowohl STORK wie PEPPOL aber auch die Schwierigkeiten bei der Bearbeitung des European Interoperability Framework zeigen, wie schwierig es ist, Interoperabilität zu erreichen. Der Vergleich der verschiedenen Architekturlösungen im Rahmen der Studie zeigt, dass es durchaus Gemeinsamkeiten in den Ansätzen der verschiedenen Länder gibt. Die meisten der betrachteten Architekturen sind allerdings heute nur beispielhaft und informal beschrieben. Auf dieser Basis lassen sich keine schlüssigen Konsistenzaussagen treffen. Es muss sogar davon ausgegangen werden, dass Lösungen auf der Basis von inkonsistenten Architekturansätzen nicht interoperabel sind, beziehungsweise die Herstellung ihrer Interoperabilität grosse Aufwände verursachen würde. Es wäre allerdings eine Illusion zu meinen, dass mit sauber definierten Architekturen Interoperabilitätsprobleme verhindert werden können. Diese lassen sich damit höchstens reduzieren.

NORA, die Architektur der Niederlande, hebt sich von der Konsistenz her positiv von den anderen betrachteten Architekturen ab, ist aber bei weitem nicht so formal, wie die Spezifikationen von STORK und PEPPOL. Diese beiden Projekte stehen heute auch noch nicht für allgemein gültige Architekturen. Die gewonnenen Resultate aus diesen Projekten können aber in Zukunft, wenn sie auf andere Anwendungsfelder übertragen werden, wesentliche architekturelle Bausteine der Interoperabilität von Lösungen im europäischen Kontext bilden.

Die Defizite bestehender Architekturen lassen sich aus vielerlei Gründen nicht in kurzer Zeit beheben. Wesentlich ist, sie laufend zu pflegen, Schritt für Schritt ihre Konsistenz zu verbessern und die verschiedenen internationalen Architekturen einander anzugleichen.

Bernold, Rony; Zurbuchen, Nina; Laube-Rosenpflanzer, Annett; Neuroni, Alessia; Spichiger, Andreas, Studie E-Government-Architektur Schweiz im internationalen Vergleich, Berner Fachhochschule, Kompetenzzentrum Public Management und E-Government, Bern (2011).
eCH-0122, Architekturübersicht E-Government Schweiz, Entwurf (2010).
EIF 1.0, European Interoperability Framework for Pan-European eGovernment Services (2004).http://ec.europa.eu/idabc/en/document/3473/5887.html .
European Interoperability Framework (EIF), Draft document as a basis for EIF 2.0, European Commission (2008).
IEEE 1471, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, New York (2000).
Kuehn, Andreas; Spichiger, Andreas; Riedl, Reinhard, Interoperabilität und Standards im E-Government, in: Schweighofer (Hrsg.), Semantisches Web und Soziales Web im Recht, Tagungsband des 12. Internationalen Rechtsinformatik Symposions IRIS 2009, OCG, Wien (2009).
NORA 2.0 - Nederlandse Overheid Referentie Architecture - Samenhang en samenwerking binnen de elektronische overheid.www.e-overheid.nl/onderwerpen/architectuur-en-nora .

---

Andreas Spichiger, Ronny Bernold, Reinhard Riedl, Kompetenzzentrum Public Management und E-Government, Berner Fachhochschule, Morgartenstrasse 2a, Postfach 305, 3000 Bern 22 CH
andreas.spichiger@bfh.ch ;ronny.bernold@bfh.ch ;reinhard.riedl@bfh.ch ;www.e-government.bfh.ch

---