Open Data Niedersachsen. Expertise im Auftrag der GovConnect GmbH

Transkript

1 Open Data Niedersachsen Expertise im Auftrag der GovConnect GmbH i

2 Auftraggeber: GovConnect GmbH Hildesheimer Straße Hannover Autoren der Expertise von Fraunhofer FOKUS Dr. Matthias Flügge Jens Klessmann Jan Ziesing Stand: August 2012

3 Inhaltsverzeichnis 1 Rahmenbedingungen von Open Data Niedersachsen Status quo offener Verwaltungsdaten in Deutschland Status quo auf Ebene der Länder und Kommunen Technologische Aspekte Generischer Prozess für die Bereitstellung und Nutzung offener Daten Basiskomponenten und Basistechnologien einer Open-Data-Plattform Basiskomponenten Basistechnologien Diskussion von Architekturoptionen Generische Grobarchitektur der Open-Data-Plattform Architekturoptionen Vor- und Nachteile der Architekturoptionen Empfehlungen aus architektureller Sicht Markt- und betriebswirtschaftliche Aspekte Wertschöpfung und Geschäftsmöglichkeiten bei Open Data Geschäftsmöglichkeiten mit Leistungen für Bürgern und Unternehmen Geschäftsmöglichkeiten mit Leistungen für die öffentliche Hand Angebots- und Produktgestaltung Bereitstellung und Betrieb einer Open Data Plattform Unterstützung bei der Einführung von Open Data Handlungsempfehlungen und Roadmap i

4

5 1.1 Status quo offener Verwaltungsdaten in Deutschland 1 Rahmenbedingungen von Open Data Niedersachsen D ie GovConnect GmbH bietet als gemeinsames Unternehmen niedersächsischer IT-Dienstleister datenschutzgerechte egovernment-lösungen wie z. B. für den Bereich des Meldewesens für seine Kunden an. Gesellschafter der GovConnect sind die Hannoverschen Informationstechnologien AöR (HannIT), die ITEBO GmbH Osnabrück, die KDO Service GmbH Oldenburg sowie der Zweckverband Kommunale Datenverarbeitungszentrale Südniedersachsen (KDS). Die GovConnect GmbH zieht in Erwägung im Umfeld von Open Data ein eigenes Angebot für ihre Kunden zu entwickeln. Mit der vorliegenden Untersuchung werden durch Fraunhofer FOKUS im Auftrag für die GovConnect GmbH, inhaltliche Voraussetzungen für den Aufbau eines solchen Angebots analysiert. Im Rahmen der Expertise sind dabei vor allem Fragen konzeptioneller, technischer und betrieblicher Art untersucht worden. Im folgenden Dokument werden zunächst existierende politisch-gesellschaftliche Rahmenbedingungen offener Verwaltungsdaten in Deutschland vorgestellt. Alsdann werden die konzeptionellen und technischen Aspekte eines möglichen Angebots der GovConnect GmbH für ihre Kunden untersucht. Im Anschluss erfolgt die Analyse der Potenziale für Geschäftsmodelle im Umfeld offener Daten für eine Organisation wie die GovConnect GmbH. 1.1 Status quo offener Verwaltungsdaten in Deutschland Im Herbst 2010 hat die Bundesregierung ihr aktuelles Programm zur Verwaltungsmodernisierung»Vernetzte und transparente Verwaltung«veröffentlicht. Als wesentliche Ziele, die bei der Reform der öffentlichen Verwaltung berücksichtigt werden sollen, werden hier die stärkere Kooperation mit Akteuren aus Zivilgesellschaft und Wirtschaft sowie eine generell höhere Transparenz der eigenen Handlungen und Entscheidungen festgestellt. 1

6 1 Rahmenbedingungen von Open Data Niedersachsen Im Regierungsprogramm werden 19 verschiedene Modernisierungsprojekte mit kurzen Projektsteckbriefen aufgeführt. Im Projekt»Open Government«soll»wo es rechtlich möglich und zweckmäßig ist ein freier Zugang zu Informationen der Verwaltung geschaffen werden«(bundesministerium des Innern, 2010: S. 57f.). Ziel ist es, Pilotvorhaben für die Bereitstellung von Verwaltungsdaten zu realisieren und bis zum Jahr 2013 eine mit den Ländern abgestimmte Open Government-Strategie entwickelt zu haben, um dann an die Umsetzung zu gehen. In der Nationalen E-Government Strategie (NEGS) der Bundesrepublik wird die Bereitstellung offener Verwaltungsdaten vor allem in den Zielbereichen C Transparenz, Datenschutz und Datensicherheit und D Gesellschaftliche Teilhabe anvisiert. Mit den darin enthaltenen Zielen Handeln der Verwaltung, Durchführung von Verfahren und Gesetzgebung sind transparent sowie Die Mitwirkung von Bürgern und Unternehmen wird gefördert sollen staatliche Daten, welche für Dritte relevant sein können, aufbereitet zur Verfügung gestellt werden. Im Rahmen des NEGS-Umsetzungsprogramms sind im Jahr 2011 sieben Steuerungsprojekte beschlossen worden. Im Steuerungsprojekt Förderung des Open Government liegt der Schwerpunkt dabei zunächst auf offenen Verwaltungsdaten. Zu Beginn wird eine Studie zur Machbarkeit und anschließend eine Pilotplattform entwickelt (IT-Planungsrat, 2011). Hierzu hat das Bundesministerium des Innern Ende 2011 die Erarbeitung einer nationalen Studie zu Open Government Data in Deutschland bis Mitte 2012 und die Entwicklung einer landesweiten prototypischen Plattform für offene Daten bis Ende 2012, sowie einen Pilotbetrieb in 2013 beauftragt (Klessmann u. a., 2012). Verschiedene Bundesbehörden und ihre nachgeordneten Einrichtungen stellen seit Jahren proaktiv Verwaltungsdaten online bereit. Speziell in den Bereichen statistischer und umweltspezifischer Daten sowie im Bereich der Informationen mit Raumbezug haben entsprechende verwaltungspolitische Aufgabenstellungen und die nationale Umsetzung von EU-Vorgaben zu ausgeprägten Initiativen geführt. Zum Beispiel sind beim Bundesamt für Statistik bereits heute vielfältige Informationen zu ökonomischen, gesellschaftlichen und weiteren Entwicklungen zum Download erhältlich. Diese Informationen sind in ihrem Umfang und in ihrer Struktur häufig bereits kompatibel zu vergleichbaren Daten der europäischen Statistik sowie der deutschen Landes- und Kommunalstatistikämter. Im Umweltbereich wird spätestens seit der Neufassung des Umweltinformationsgesetzes (UIG) von 2004 der freie Zugang zu Informationen über die Umwelt auf Bundesebene vorgeschrieben (Umweltinformationsgesetz (UIG), 2004), entsprechende Regelungen finden sich auch auf Länderebene. Als technologisches Werkzeug zur Umsetzung des UIG bietet das PortalU des Bundesumweltamtes Zugang zu umfangreichen Datenbanken mit Umweltinformationen. Das Portal ist Ergebnis einer Bund-Länder-Kooperation und wurde mit dem Ziel eines einheitlichen Einstiegspunktes für Umweltdaten entwickelt. Nutzer können über die Suchmaschine in den angeschlossenen Datenbeständen mit Unterstützung eines Fachwörterbuches, dem Semantischen Networkservice recherchieren (Schenk u. a., 2010). Im Bereich räumlicher Informationen, also geobasierter Daten, existiert als nationale Umsetzung der EU-Richtlinie zur Schaffung einer Geodateninfrastruktur in der Europäischen Gemeinschaft mit dem Gesetz über den Zugang zu digitalen Geodaten (GeoZG, 2009) eine rechtliche Vorgabe zum Aufbau einer digitalen Infrastruktur für Deutschland (GDI-DE), die den Zugang zu Geodaten für un- 2

7 1.1 Status quo offener Verwaltungsdaten in Deutschland terschiedliche Zielgruppen ermöglichen soll. Entsprechende Normen finden sich ebenfalls auf Ebene der Länder, in denen Regelungen für Geodaten im Zuständigkeitsbereich von Ländern und Kommunen getroffen werden. Mit dem organisatorisch-technischen Aufbau der bundesweiten Geodateninfrastruktur GDI- DE wurde bereits im Jahr 2003 begonnen, vor dem Erlass des GeoZG. Ein technisches Architekturkonzept liegt seit 2007 vor und wurde im Jahr 2010 in einer überarbeiteten Version veröffentlicht. Begleitet wurde die technische Umsetzung mit Informationsmaßnahmen für die involvierten datenhaltenden Stellen der öffentlichen Verwaltung sowie der Abfrage existierender Geodatensätze nach Anhang 1 der EU-Richtlinie INSPIRE bei den entsprechenden Stellen bei Bund, Ländern und Kommunen. Im Zusammenhang mit dem Aufbau der GDI-DE werden vorrangig die Geodaten aus den Bereichen bereitgestellt, die in den Anhängen 1 bis 3 der INSPIRE-Richtlinie beschrieben sind (INSPIRE, 2007). Im Frühjahr 2012 wurde das nationale Webangebot für räumliche Daten Geportal.DE freigeschaltet. Hierüber ist ein zentraler Zugang sowohl zu Geodaten als auch zu Geodatendiensten der involvierten öffentlichen Stellen realisiert. Bei den Daten in den beschriebenen Bereichen mit geregeltem Informationszugang handelt es sich nicht notwendigerweise um offene Daten entsprechend der Open-Data-Prinzipien. So sieht das Geodatenrecht bislang eine eingeschränkte, häufig kostenpflichtige Weiterverwendung raumbezogener Daten vor. Das GeoZG befindet sich jedoch Mitte 2012 in der Überarbeitung. Ein wesentliches Ziel der Novellierung ist es, die aktuellen Entwicklungen zur möglichst geldleistungsfreien Bereitstellung staatlicher Daten aufzugreifen und die Daten mit Raumbezug in der Hoheit des Bundes entsprechend bereitzustellen. Ein über die Umweltdaten oder Geodaten hinausgehender einheitlicher Zugriff auf Verwaltungsdaten über einen gemeinsamen Einstiegspunkt, eine durchgängig abgestimmte Auszeichnung mit Metadaten sowie die Bereitstellung als Linked Data steht dagegen vielfach noch aus. Die Nutzung der Handlungsempfehlungen der durchgeführten Untersuchung zu Open Government Data in Deutschland zur Entwicklung einer organisations- und ebenenübergreifenden Strategie für offene Verwaltungsdaten ist in diesem Zusammenhang mittel- bis langfristig sicher unerlässlich, wenn die Zielsetzung von mehr Transparenz und Wirtschaftsförderung mittels einfach zugänglicher Verwaltungsinformationen angenommen wird. Zu unterscheiden von Initiativen zur proaktiven Bereitstellung von Verwaltungsdaten zur Weiterverwendung durch Dritte ist bislang meistens der Ansatz des Informationsfreiheitsrechts. Die meisten einschlägigen Gesetze in Deutschland sehen einen Zugang zu Verwaltungsinformationen auf Anfrage einer Person vor. Eine Ausnahme bildet die gesetzliche Regelung auf Landesebene im Fall des Stadtstaates Bremen; dort ist eine proaktive Bereitstellung von Informationen vorgesehen. Das Gesetz zur Regelung des Zugangs zu Informationen des Bundes schreibt seit dem Jahr 2006 einen Anspruch auf Informationszugang bei Verwaltungsinformationen im Bereich der Bundeseinrichtungen vor. Als zivilgesellschaftliche Initiative setzt das Projekt»FragdenStaat.de«an dem Anspruch auf Informationszugang auf Bundesebene an. Mithilfe eines Internetportals gleichen Namens sollen entsprechende Anfragen zum einen vereinfacht und zum anderen öffentlich gemacht werden. Auf diese Weise erhofft man sich eine Steigerung der Bekanntheit des Rechts auf Informationszugang sowie eine Zunahme positiver Antworten seitens der angesprochenen Verwaltungseinheiten bei gleichzeitiger Abnahme von Doppelanfragen aufgrund der öffentlichen Dokumentation der Anfragen. 3

8 1 Rahmenbedingungen von Open Data Niedersachsen Ebenfalls von Bedeutung ist die Realisierung eines nationalen Wettbewerbs für Softwareanwendungen und Ideen auf Basis offener Verwaltungsdaten. Dieser»Apps für Deutschland«genannte Wettbewerb fand von Anfang November 2011 bis Anfang März 2012 unter der Schirmherrschaft des Bundesministers des Innern statt. Koordiniert wurde der Wettbewerb von den zivilgesellschaftlichen Organisationen Government 2.0 Netzwerk Deutschland e. V., Open Data Network e. V. und Open Knowledge Foundation Deutschland. Als Unterstützer waren der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien (Bitkom e. V.) sowie verschiedene Gebietskörperschaften und Fachbehörden tätig. Ziele des Wettbewerbs waren es, den Ansatz offener Verwaltungsdaten bekannter zu machen, innovative Anwendungen und Ideen für die Weiterverwendung von Verwaltungsinformationen zu erhalten und weitere Daten zur Verfügung zu stellen. Verwaltungseinheiten aller föderalen Ebenen waren im Rahmen des Wettbewerbs aufgerufen eigene Datensätze als offene Daten bereitzustellen. Preise wurden in den drei Kategorien Ideen, Anwendungen und Daten vergeben. Die Preise wurden durch Sponsoren aus der Privatwirtschaft ermöglicht (Government 2.0 Netzwerk Deutschland e. V. u. a., 2011). Ebenfalls von nationaler Bedeutung ist eine mögliche Teilnahme Deutschlands an der internationalen Initiative»Open Government Partnership«. Dieses Vorhaben wurde im Herbst 2011 von verschiedenen Staaten wie den USA, Brasilien und Norwegen und Nicht-Regierungsorganisationen (NROs) angestoßen. Ziel ist die Förderung der Umsetzung und Fortentwicklung des Open-Government-Ansatzes in den beteiligten Ländern. Diese setzen sich eigene Verpflichtungen, die öffentlich bekannt gegeben werden. Mithilfe eines gemeinsam mit den zivilgesellschaftlichen Organisationen durchzuführenden Monitorings sollen entsprechende Fortschritte dokumentiert werden. In Deutschland formieren sich verschiedene NROs vor allem aus den Bereichen Bürgerbeteiligung und Transparenz, um die Bundesregierung zu einer Teilnahme an der Initiative zu bewegen (Drescher, 2011). 1.2 Status quo auf Ebene der Länder und Kommunen Entsprechend den nationalen Gesetzgebungen in den Bereichen Umwelt-, Verwaltungs- und Informationsrecht finden sich vergleichbare Normen auf der Ebene der Länder in Deutschland. Hier weisen die Gesetzgebungen entsprechend der föderalen Konkurrenz unterschiedliche Ausprägungen auf oder fehlen teilweise auch gänzlich. Spezifisch auf das Thema Bereitstellung von Verwaltungsdaten als offene Daten konzentrieren sich derzeit noch wenige Länder und Kommunen. Nachfolgend werden einzelne Initiativen skizziert, die unterschiedlich weit fortgeschritten sind. Auf Länderebene in Deutschland findet sich z. B. in Nordrhein-Westfalen (NRW) die Initiative Open.NRW, die sich Open Government und damit auch offenen Verwaltungsdaten widmet. In der Koalitionsvereinbarung der aktuellen Regierungsparteien in NRW wird eine stärkere Öffnung von Verwaltung angekündigt. Mit der genannten Initiative soll eine»kosten- und diskriminierungsfreie Bereitstellung öffentlicher Daten und Informationen«erfolgen. Weiterhin sollen regelmäßig Wettbewerbe durchgeführt werden, bei denen»entwickler unter Verwendung öffentlich bereitgestellter Daten Applikationen erstellen, die zu Transparenz, Partizipation und Zusammenarbeit beitragen«(nrw SPD, Bündnis 90/Die Grünen NRW, 2012: S. 168f). Das zweite Flächenbundesland, in dem mehr Transparenz über die Bereitstellung von Verwaltungsinformationen nach dem Open-Data-Ansatz 4

9 1.2 Status quo auf Ebene der Länder und Kommunen angekündigt und auch bereits umgesetzt wurde, ist Baden-Württemberg. Die neue grün-rote Landesregierung ist bestrebt zuerst ein Landesinformationsfreiheitsgesetz auf den Weg zu bringen, analog zu bereits existierenden Normen in den meisten anderen Bundesländern. Hierbei soll jedoch explizit eine Ausrichtung an den Open-Data-Prinzipien erfolgen (Bündnis 90/Die Grünen, SPD Baden-Württemberg, 2011: S. 79). Im Gesetz des Bundeslandes Bremen zur Informationsfreiheit sind Regelungen zur proaktiven Bereitstellung einzelner Informationen des öffentlichen Sektors und zur Erstellung eines entsprechenden Informationsregisters festgelegt. Hierin unterscheidet sich das bremische Informationsfreiheitsgesetz von vergleichbaren Normen in anderen Bundesländern und auf Bundesebene. Um eine strategische Herangehensweise an offene Verwaltungsdaten zu entwickeln, wurde von lokalen Akteuren aus Verwaltung, Politik und Wissenschaft eine»bremer Empfehlung zu Open Government Data«verfasst und veröffentlicht (Linnert u. a., 2011). In dieser Empfehlung werden zum einen ausgewählte Open-Data-Prinzipien für die lokalen Gegebenheiten interpretiert und zum anderen eigene Anliegen formuliert. In dem Dokument wird die Notwendigkeit einer an den Bedürfnissen verschiedener Nutzergruppen orientierten Erschließung als wichtig angesehen. Technische Standardisierung wird als wesentliche Voraussetzung für die großflächige Umsetzung offener Verwaltungsdaten verstanden; diese soll mit Arbeiten kombiniert werden, die ohnehin in der Verwaltung notwendig werden, um etwa den Einsatz von Dokumentenmanagementsystemen sinnvoll zu gestalten. Ebenso werden die Themen Kosten und Maschinenlesbarkeit behandelt. Für Ersteres wird eine differenzierte Betrachtung empfohlen, abhängig von den späteren Nutzergruppen. Maschinenlesbarkeit wird als grundsätzlich richtig erachtet, jedoch sollte die Umwandlung in maschinenlesbare Formate möglichst keine Mehrkosten aufseiten der Verwaltung erfordern. Die Bremer Empfehlung enthält mehrere neue Ergänzungen zu den existierenden Open-Data-Prinzipien. Es wird die Schaffung organisatorischer Verfahren und Strukturen in der Verwaltung gefordert, um offene Verwaltungsdaten nachhaltig zu ermöglichen. Zur Realisierung einer föderalen Plattform für offene Verwaltungsdaten wird ein verteiltes Redaktionsmodell empfohlen, bei dem von Beginn an auf Qualität der Inhalte und Beschreibungen geachtet werden soll. Abschließend wird der Aufbau einer kooperativen Dateninfrastruktur von den Urhebern der Empfehlung als notwendig erachtet. Auf kommunaler Ebene sind in Deutschland neben den Stadtstaaten Berlin und Bremen und auch Hamburg bislang u. a. Aktivitäten in Köln und München feststellbar. München hat im Rahmen des lokalen O- pen-government-pilotprojektes»munich Open Government Day«(MOGDy) je einen Anwendungs- und Ideenwettbewerb durchgeführt. Dabei ging es darum, Anwendungen oder Vorschläge mit dem Ziel zu entwickeln, Daten des öffentlichen Sektors kreativ zur Lösung städtischer Probleme, zur Verbesserung existierender Geschäftsmodelle oder für mehr Transparenz in Entscheidungen und Prozessen der öffentlichen Verwaltung einzusetzen. Das Pilotprojekt MODGy hatte eine Laufzeit von Dezember 2010 bis Juni Im Herbst 2011 wurde das Projekt im Rahmen des European Public Sector Awards des European Institute for Public Administration mit einem Best-Practice-Zertifikat ausgezeichnet (European Institute for Public Administration, 2011). Die Stadt Köln hat sich zum Ziel gesetzt zur Internetstadt zu werden. Ein Baustein der Strategie ist die Bereitstellung von Daten öffentlicher Einrichtungen für die freie Weiterverwendung durch Dritte (Stadt Köln, Der Oberbürgermeister, 2011). Dazu entwickelt die Stadt derzeit eine 5

10 1 Rahmenbedingungen von Open Data Niedersachsen Open-Data-Strategie, in der bereits bestehende Angebote der Datenbereitstellung in der Kommune untersucht, technische Vorschläge zur Fortentwicklung und rechtliche Fragestellungen beleuchtet werden. In Niedersachsen sind bislang Aktivitäten zu Open Government Data vor allem im politischen Umfeld feststellbar. Die aktuelle Landesregierung stellte in einer Diskussion im Landesparlament fest, dass durch die existierenden Pflichten zur Veröffentlichung und weitere freiwillige Aktivitäten genügend Transparenz sichergestellt ist. Als Beispiele existierender Veröffentlichungen werden angeführt: Übersichten zu Förderprojekten und -maßnahmen der Landesregierung in den einzelnen Landesteilen, die Bereitstellung des Haushaltsplans nach offizieller Veröffentlichung, statistische Informationen zur demographischen und ökonomischen Entwicklung in Niedersachsen sowie z. B. Umweltinformationen entsprechend des UIG des Bundes (Schünemann, 2011). In der Stadt Osnabrück beschloss der Rat der Stadt im Juni 2012 einstimmig die Entwicklung eines Open- Data-Angebotes. Im Beschluss wird festgestellt, dass die Stadt in Teilbereichen bereits gut für die Bereitstellung öffentlicher Daten aufgestellt ist. Dies umfasst besonders die Bereiche Geodaten und Statistik. Die hier vorliegenden Ansätze sollen nach Möglichkeit weiter ausgebaut werden, solange die rechtlich zulässig und sinnvoll ist. Dafür soll die Verwaltung der Stadt prüfen inwieweit ein Open-Data-Portal in der Stadt aufgebaut werden kann und welcher Zeitrahmen dafür vorzusehen wäre. Die Ergebnisse der Prüfung sollen im Ausschuss für Organisationsangelegenheiten weiter beraten werden (Zählgemeinschaft SPD/Bündnis 90/Die Grünen und CDU-Fraktion, 2012). 6

11 2.1 Generischer Prozess für die Bereitstellung und Nutzung offener Daten 2 Technologische Aspekte I n diesem Kapitel werden technologische Rahmenbedingungen für die Entwicklung eines Open-Data- Angebots durch die GovConnect GmbH diskutiert. Einleitend wird ein generischer Prozess für die Bereitstellung und Nutzung offener Daten vorgestellt, um ein allgemeines Verständnis für die Abläufe, Akteure und Domänen rund um eine Open-Data-Plattform herzustellen. Anschließend werden typische Basiskomponenten und Basistechnologien zu Open-Data-Plattformen beschrieben. Es folgt eine Betrachtung von groben Architekturoptionen für die Realisierung einer Plattform und eine Diskussion der jeweiligen Vor- und Nachteile. Das Kapitel schließt mit technologischen und architekturellen Empfehlungen für die Entwicklung eines Open-Data-Angebots durch die GovConnect GmbH. 2.1 Generischer Prozess für die Bereitstellung und Nutzung offener Daten Auf Basis der Erfahrungen aus verschiedenen Open-Data-Projekten hat Fraunhofer FOKUS einen generischen Prozess für die Bereitstellung und Nutzung offener Daten entwickelt. Der Prozess (siehe Abbildung 1) stellt auf einem hohen Abstraktionsniveau die typischen Schritte von der Datenerfassung bis hin zur Datennutzung, sowie die involvierten Domänen und Akteure dar. Relevante Rohdaten werden von Verwaltungen und öffentlichen Unternehmen erfasst. Entsprechend des Kundenkreises der GovConnect GmbH handelt es sich dabei primär um kommunale Verwaltungen und Unternehmen. Diese Daten werden in organisationsinternen Systemen und Prozessen gepflegt und qualitätsgesichert. Zudem erfolgt hier die Extraktion von offenen Daten, die z. T. bereits heute über verschiedene Kanäle, z. B.. auf den Webseiten der Kommunen oder über entsprechende Schnittstellen, bereitgestellt werden. Diese Daten werden nun mittels Metadaten beschrieben und in der Open-Data-Plattform registriert und auffindbar gemacht. Alternativ erfolgt die Bereitstellung von Daten auch direkt auf der Plattform. 7

12 2 Technologische Aspekte Abbildung 1: Generischer Soll-Prozess für die Bereitstellung und Nutzung offener Daten Der nachfolgende Schritt der Datenaufwertung ist optional und abhängig vom Ausbaugrad der Open- Data-Plattform. Die grundlegende Idee hinter diesem Schritt ist es, externen Akteuren, wie z. B. Datenjournalisten, die Aufbereitung von Daten zu ermöglichen, um beispielsweise deren Maschinenlesbarkeit oder semantische Interpretierbarkeit zu verbessern. Dazu kann auch die Aggregation verschiedener Datensätze zu einem neuen Datensatz gehören. Eine Open-Data-Plattform kann entsprechende Werkzeuge anbieten, die eine Datenaufwertung unterstützen. Die dezentral und möglicherweise auch zentral vorgehaltenen Daten können von Entwicklern über das öffentliche Open-Data-Portal gefunden und in Anwendungen und Visualisierungen integriert werden. Bürger und Unternehmen nutzen diese Anwendungen für bestimmte Anwendungszwecke, wie z. B. Verkehrsauskünfte, und um sich über städtische Vorgänge und Entscheidungen zu informieren und evtl. auch an diesen zu partizipieren. Auf diese Weise entstehen möglicherweise neue oder höherwertige Daten, die wiederum im Sinne einer Rückkopplung auf der Plattform bereitgestellt werden können. Der oben beschriebene generische Prozess soll zunächst zu einem allgemeinen Verständnis der Abläufe rund um die Bereitstellung und Nutzung offener Daten und der beteiligten Akteure Datenbereitsteller, Datenaufbereiter, Plattformbetreiber und (direkte und indirekte) Datennutzer beitragen. Als Teil eines Umsetzungsprojektes sind für diese Akteure entlang des obigen Prozesses Anwendungsfälle zu entwerfen, aus denen sich die detaillierten Plattformfunktionalitäten ableiten lassen. 2.2 Basiskomponenten und Basistechnologien einer Open-Data-Plattform Bei der Betrachtung von Best-Practice-Beispielen zu Open Data lässt sich feststellen, dass diese häufig auf ähnlichen Basiskomponenten und Basistechnologien aufsetzen. Diese sollen nachfolgend dargestellt werden Basiskomponenten Grundlegende Komponenten einer Open-Data-Plattform sind in Abbildung 2 dargestellt. 8

13 2.2 Basiskomponenten und Basistechnologien einer Open-Data-Plattform Open-Data-Plattform Open-Data-Portal Datenbereitsteller Datennutzer Open-Data-Register Datenspeicher Abbildung 2: Basiskomponenten einer Open-Data-Plattform Verwaltungen und weitere Datenbereitsteller beschreiben die von Ihnen bereitgestellten offenen Daten mittels Metadaten (z. B. Ansprechpartner, Zeitbezug, Ortsbezug), die in einem Open-Data-Register gespeichert und verwaltet werden. Wie bereits im vorherigen Abschnitt erwähnt, werden die eigentlichen Datensätze vorwiegend dezentral, z. B. auf entsprechenden kommunalen Webseiten, durch die Datenbereitsteller verwaltet und zugänglich gemacht. Die Inhalte des Datenregisters werden über ein Web-basiertes Open-Data-Portal dargestellt und durchsuchbar gemacht. Direkte Datennutzer verwenden das Open-Data-Portal, um Datensätze zu finden und über entsprechende Verweise auf die dezentral vorgehaltenen Daten zuzugreifen. Zudem bietet ein Open- Data-Portal üblicherweise Informationen zu Anwendungen, die basierend auf den offenen Daten entwickelt wurden, sowie Interaktionsmöglichkeiten, wie z. B. die Kommentierung von Datensätzen oder Diskussionsforen rund um das Thema Open Data. Optional kann eine Open-Data-Plattform auch Funktionalitäten für die zentrale Speicherung und Abfrage der eigentlichen Daten anbieten. In diesem Fall wird als Teil der Plattform ein Datenspeicher eingerichtet. Dieser ermöglicht im einfachsten Fall das Ablegen und Herunterladen ganzer Dateien oder auch darüber hinausgehend die strukturierte Abfrage von Daten (z. B.Linked Data) über entsprechende Schnittstellen. Ein solcher Datenspeicher ist besonders dann relevant, wenn es Datenbereitsteller gibt, die nicht über die Möglichkeit verfügen, Daten auf einem eigenen Webserver bereitzustellen oder wenn es sich z. B. um besonders große Datenmengen handelt. 9

14 2 Technologische Aspekte Basistechnologien Von zentraler Relevanz sind die Metadaten, die für die Beschreibung von offenen Daten verwendet werden. Anhand der Metadaten kann ein Datennutzer relevante Daten finden und erhält zusätzliche Informationen, die eine Wiederverwendung und Verarbeitung der Daten erleichtern. Für die Beschreibung von offenen Daten mit Metadaten hat sich noch kein einheitlicher Standard durchgesetzt. Es empfiehlt sich jedoch eine Orientierung an Best-Practice-Beispielen, wie data.gov, data.gov.uk oder daten.berlin.de. Im Rahmen einer Open-Government-Studie, die im Auftrag des Bundesinnenministeriums erarbeitet wird, wird aktuell ein Metadatenvorschlag für die im Anschluss zu realisierende Open-Government-Data- Plattform entwickelt, der ebenfalls als Orientierung dienen kann. Im Rahmen einer W3C Arbeitsgruppe wird derzeit ein RDF 1 Vokabular für Datenkataloge Data Catalog Vocabulary (DCAT) entwickelt 2. Aufgrund unterschiedlicher lokaler Anforderungen ist zu erwarten, dass es trotz intensiver Harmonisierungsbemühungen, auch in Zukunft immer Unterschiede in den Metadatenbeschreibungen verschiedener O- pen-data-plattformen geben wird. Hier sind Abbildungen auf gemeinsame Vokabulare, wie z. B. DCAT, ein probates Mittel für die Föderation von Open-Data-Portalen und für eine plattformübergreifende Suche. Letztendlich sollten auch die technischen Formate in denen offene Daten publiziert werden, gewissen Kriterien genügen. Zwei der acht von der Open Government Working Group 3 publizierten Open- Government-Data-Prinzipien 4 treffen diesbezüglich Aussagen: Offene Daten sollten so strukturiert sein, dass sie automatisch verarbeitbar ( maschinenverarbeitbar ) sind. Zudem sollten die Datenformate nicht proprietär sein, d. h. die Verwendung offener Standards wird vorausgesetzt. Der WWW-Erfinder Tim Berners-Lee hat ein 5-Sterne-System 5 für Linked Open Data beschrieben. Datensätze, die den o. g. Prinzipien genügen, d. h. die in maschinenverarbeitbaren und nicht-proprietären Formaten vorliegen, erhalten demnach jedoch nur drei Sterne. Volle fünf Sterne gibt es laut Berners-Lee, wenn semantische W3C- Standards, wie RDF und SPARQL, für die Bereitstellung und Abfrage verwendet werden und die Daten zudem nicht isoliert vorliegen, sondern miteinander semantisch verknüpft sind. Zusammenfassend kann man festhalten, dass sich aus rein technischer Sicht drei Dimensionen ergeben, entlang derer Daten mehr oder weniger offen sein können: 1) Die strukturierte Abfragemöglichkeit von Daten, 2) die Verwendung offener Standards für Datenformate und 3) die semantische Ausdrucksstärke. So würden sich, um konkrete Beispiele zu nennen, z. B. als digitale Bilder gescannte Dokumente am einen Ende der Skala (wenig offen), tabellarische CSV-Daten im Mittelfeld, und RDF Daten, die über SPARQL abfragbar sind, am anderen Ende der Skala (sehr offen) befinden. Für die Realisierung des Open-Data-Registers bietet sich die Verwendung des Softwareprodukts CKAN 6 der Open Knowledge Foundation 7 an. CKAN ist eine bereits vielfach erprobte und eingesetzte Plattform (z. B. daten.berlin.de, data.gov.uk, geplantes Open-Data-Portal der Europäischen Kommission) für die 1 W3C Resource Description Framework RDF, 2 W3C Data Catalog Vocabulary DCAT, 3 Open Government Working Group, 4 Eight Principles of Open Government Data, 5 Linked Open Data, 6 CKAN, 7 Open Knowledge Foundation, 10

15 2.3 Diskussion von Architekturoptionen Bereitstellung und Verwaltung von offenen Daten und kann daher als Quasi-Standard in diesem Bereich bezeichnet werden. CKAN ist Open Source Software, die somit unter der AGPL-Lizenz kostenfrei zur Verfügung steht und von einer aktiven Entwicklercommunity weiterentwickelt wird. CKAN bietet bereits heute zahlreiche Erweiterungen, z. B. für den Import von Geodaten, sowie für die Datenvisualisierung und Datenpersistierung. CKAN verfügt über dokumentierte Web-basierte APIs für die Abfrage und Verwaltung von Metadateneinträgen. CKAN-Instanzen sind zudem föderierbar. CKAN bietet auch Portalfunktionalitäten für die Bereitstellung Web-basierter Front-Ends für die Suche und Anzeige von Datensätzen. Bei einem Umsetzungsprojekt ist somit zu entscheiden, ob diese Funktionalitäten für die Darstellung des Open-Data-Portals zum Einsatz kommen sollen, oder ob dafür ein dediziertes Content Management System (CMS) zum Einsatz kommen soll. Der Vorteil der Verwendung eines separaten CMS für die Gestaltung des Front-Ends liegt in einer höheren Flexibilität hinsichtlich der Erweiterbarkeit und der Verwendung von Standardkomponenten, wie z. B. Diskussionsforen, Blogs, Warenkörbe und Tagwolken. Als nachteilig ist bei dieser Option jedoch anzusehen, dass in diesem Fall die Kommunikation zwischen CMS und Register explizit implementiert werden muss. CKAN bietet zudem Basisfunktionalitäten für die Realisierung eines Datenspeichers an. Dateien können in einem Data Store abgelegt werden. Strukturierte tabellarische Daten können zudem über eine Web- Service-Schnittstelle abgefragt werden. Für weitergehende Funktionalitäten bietet sich die Verwendung eines sogenannten Multi Data Stores an, der unterschiedlichste Formate und Abfragemöglichkeiten unterstützt. Ein Beispiel ist die Software Virtuoso 8 von OpenLink Software. Die Software, die auch in einer Open-Source-Version zur Verfügung steht, bietet u. a. einen Filestore, eine objektrelationale Datenbank und einen sogenannten Triple Store für RDF Daten, die über eine SPARQL-Schnittstelle abgefragt werden können. 2.3 Diskussion von Architekturoptionen Nachfolgend werden Architekturoptionen für die Gestaltung einer Open-Data-Plattform diskutiert, die die GovConnect GmbH Ihren Kunden, d. h. den Kommunen im Bundesland Niedersachsen, anbieten kann. Ausgangspunkt der Diskussion ist eine Best-Practice-Grobarchitektur, die der Berliner Open-Data- Plattform zu Grunde liegt und zudem Basis für diverse weitere Umsetzungsprojekte ist. Diese Grobarchitektur wird anschließend auf die wesentlichen Komponenten, Akteure und Kommunikationsbeziehungen reduziert, um auf Basis einer vereinfachten Sichtweise verschiedene Umsetzungsoptionen darzustellen. Nachfolgend werden Vor- und Nachteile dieser Optionen diskutiert und Empfehlungen ausgesprochen. 8 Virtuoso, 11

16 2 Technologische Aspekte Generische Grobarchitektur der Open-Data-Plattform Die in Abbildung 3 skizzierte Grobarchitektur stellt Komponenten einer Open-Data-Plattform und angrenzender Domänen dar, sowie deren Kommunikationsbeziehungen im Hinblick auf Daten und Metadaten. Verwaltungen und öffentliche Unternehmen, die Ihre Datensätze auf einer eigenen Webseite veröffentlichen, nutzen ein Web-basiertes Verwaltungsportal, um Metadaten zu den Datensätzen zu registrieren. Das Verwaltungsportal ist nicht öffentlich. Die Datenbereitsteller müssen sich registrieren und authentisieren, um über dieses Portal neue Metadaten einzustellen. Die Metadaten werden in das Open-Data-Register übernommen, das zugleich das Herzstück der Plattform darstellt. Häufig besteht für Webauftritte der Verwaltung ein dezentraler Redaktionsprozess, d. h. es wird ein CMS verwendet, das es verschiedenen öffentlichen Stellen in einer Kommune ermöglicht, Ihre eigenen Webseiten zu pflegen und innerhalb eines vorgegebenen Gestaltungsrahmens - redaktionell zu überarbeiten. Für öffentliche Stellen, die an einen solchen dezentralen Redaktionsprozess für den Webauftritt einer Kommune angebunden sind und auf diesem Wege Daten veröffentlichen, kann eine Erweiterung der Redaktionsseiten des CMS entwickelt werden, um auf diesem Wege Metadaten zu veröffentlichten, Datensätzen einzutragen und direkt bei der Open-Data-Plattform zu registrieren. Dazu muss die CMS- Erweiterung die Metadaten an eine Web-Service-basierte Import-Schnittstelle des Open-Data-Registers übertragen. Der wesentliche Vorteil dieses Angebots ist, dass Verwaltungsmitarbeiter direkt aus ihren gewohnten Prozessen heraus Daten auf der Open-Data-Plattform publizieren können. Open-Data-Plattform Daten suchen Amt A, Kommunales Unternehmen B Metadaten Ämter C,D eigene Website Datensatz Metadaten Betreiber Webseite kommunexy.de Verwaltungsportal CMS Metadatenformular kommune XY.de Metadaten veröffentlichen CMS Datenportal Import API App-Portal Open-Data- Register App suchen Anwender Feedback zu Daten indirekte Datennutzer (z. B. App-Nutzer) Website kommune XY.de Datenspeicher Transformationswerkzeuge/-dienste Informationen zu Apps veröffentlichen App nutzen Daten abfragen Apps Kommunikation zu Metadaten Kommunikation zu Daten Datenaufbereiter direkte Datennutzer (z. B. App-Entwickler, Data Businesses) Abbildung 3: Grobarchitektur einer Open-Data-Plattform 12

17 2.3 Diskussion von Architekturoptionen Das visuelle Front-End der Open-Data-Plattform besteht meist aus einem öffentlichen Datenportal und einem öffentlichen App-Portal mit Informationen zu registrierten Datensätzen und Apps sowie entsprechenden Suchfunktionalitäten. Die Portale können auf Basis eines CMS 9 erstellt werden, das auf das Open- Data-Register zugreift. Oben wurde bereits erwähnt, dass entsprechende Standardprodukte, wie CKAN, bereits einfache Web-basierte Front-Ends für die Suche nach Daten und die Anzeige von Metadaten bieten. Alternativ zum Einsatz eines CMS können als auch diese Front-Ends angepasst und nach außen als Open-Data-Portal bereitgestellt werden. Direkte Datennutzer, wie z. B. App-Entwickler und Datenjournalisten, finden Daten von Interesse über das Datenportal und beziehen die dezentral vorliegenden Datensätze über entsprechende Links, die Teil der Metadaten sind. Indirekte Datennutzer, wie z. B. Bürgerinnen und Bürger oder Organisationen aus der Zivilgesellschaft, finden über das App-Portal Anwendungen von Interesse und können diese über Links zu externen Webseiten oder App-Stores nutzen bzw. herunterladen. Die Möglichkeit, nicht nur Metadaten, sondern auch die eigentlichen Datensätze zentral auf der Plattform zu speichern, geht über Basisfunktionalitäten einer Open-Data-Plattform hinaus. Im kommunalen Umfeld kommt dem jedoch u. U. eine hohe Bedeutung zu, da evtl. ausgewählten Akteuren kein Webserver zur öffentlichen Bereitstellung der Daten zur Verfügung steht oder dieser aus Kapazitätsgründen nicht für diese Zwecke geeignet ist. Daher ist in der Grobarchitektur als optionale Komponente ein Datenspeicher dargestellt. Datenbereitsteller, die das Verwaltungsportal nutzen, können über dieses auch die Daten selber in den Datenspeicher einstellen. Als weitere optionale Funktionalität wurde die Bereitstellung von Werkzeugen diskutiert, die sowohl Verwaltungsmitarbeiter als auch externe Akteure bei der Transformation, Restrukturierung, Aggregation etc. von Daten unterstützen. So kann z. B. die Überführung eines Datensatzes aus einem Format A in ein Format B dazu beitragen, dass dieser einfacher von Anwendungsentwicklern wiederverwendet werden kann. Die Grobarchitektur enthält dementsprechend eine optionale Komponente Transformations-werkzeuge/- dienste. Im Idealfall sind entsprechende Werkzeuge direkt mit dem Datenspeicher integriert, um die aufbereiteten Daten direkt auf der Plattform ablegen und anderen Nutzern zur Verfügung stellen zu können. In der Grobarchitektur nicht dargestellt sind Komponenten, die nur indirekt mit der Bereitstellung und Wiederverwendung offener Daten zu tun haben, wie z. B. Nutzerverwaltung und Datensicherung. 9 Hierbei kann z.b. das dem kommunalen Webauftritt zu Grunde liegende CMS verwendet werden, wenn eine enge Integration des Open-Data-Portals mit dem Webauftritt gewünscht ist. 13

18 2 Technologische Aspekte Architekturoptionen Die Architekturoptionen für das Angebot einer Open-Data-Plattform durch die GovConnect GmbH werden auf Basis einer vereinfachten Sichtweise auf die im vorherigen Abschnitt dargestellten Grobarchitektur diskutiert. Die in Abbildung 4 dargestellte Architektur abstrahiert von der Anbindung eines externen CMS an das Open-Data-Register, da es sich dabei um eine Individuallösung handelt, die den Datenbereitstellungsprozess lediglich vereinfacht. Zudem wurde auf die optionale Komponente Transformationswerkzeuge und -dienste und den Akteur Datenaufbereiter verzichtet, da solch ein Angebot üblicherweise erst in einer späteren Ausbaustufe in Betracht zu ziehen ist. Letztendlich wurde auch die Unterscheidung in direkte und indirekte Datennutzer aufgehoben, da diese für die Diskussion unerheblich ist. Open-Data-Plattform Amt A, Kommunales Unternehmen B Metadaten Verwaltungsportal CMS Daten-/App- Portal Daten/Apps suchen Datennutzer eigene Website Open-Data- Register Daten abfragen Datenspeicher Abbildung 4: Vereinfachte Grobarchitektur der Open-Data-Plattform Die GovConnect GmbH steht der grundsätzlichen Herausforderung gegenüber, der Vielzahl der Kommunen im Land Niedersachsen möglichst leichtgewichtig zu ermöglichen, Ihren Bürgerinnen und Bürgern sowie den regionalen Unternehmen ein Portal zu offenen Daten bereitzustellen. Um dies zu erreichen, ist eine naheliegende und einfache Option, für jede Kommune eine separate Instanz der Plattform anzulegen. Die Komponenten der verschiedenen Plattform-Instanzen sind somit strikt voneinander getrennt. Dazu ist einmalig eine Open-Data-Plattform einzurichten, die dann in Form eines VM-Images virtualisiert wird. Für jede Kommune, die als neuer Kunde auftritt, kann somit das Image instanziiert und auf die lokalen Bedarfe hin konfiguriert werden. Die Konfiguration bezieht sich dabei im Wesentlichen auf das Metadatenschema, das für die Beschreibung von offenen Daten verwendet wird, und die visuelle Gestaltung der Portale für die von Kommune zu Kommune unterschiedliche Anforderungen existieren. 14

19 2.3 Diskussion von Architekturoptionen OD-Plattform Instanz B Kommune B Metadaten Verwaltungsportal CMS Daten-/App- Portal Daten/Apps suchen Datennutzer eigene Website Kommune A Open-Data- Register Daten abfragen Datenspeicher OD-Plattform Instanz A Abbildung 5: Architekturoption A Separate Instanzen der Plattform Eine weitere Architekturoption ist in Abbildung 6 skizziert. In diesem Fall wird nur eine Instanz der Open- Data-Plattform angelegt. Diese verfügt über ein zentrales Datenregister und einen zentralen Datenspeicher. Für jede Kommune werden innerhalb des CMS bzw. der Portalsoftware individuelle Verwaltungsportale für die Datenbereitstellung durch die Verwaltungsmitarbeiter und individuell gestaltete Portale für Datennutzer (App- und Datenportal) angelegt. Gängige Portalprodukte, wie z. B. Liferay 10, unterstützen bereits standardmäßig die Einrichtung von Communities, d. h. von Nutzergruppen denen Portale in leicht unterschiedlicher Erscheinungsform präsentiert werden. Es ist bei dieser Option sicherzustellen, dass z. B. gesteuert über bestimmte Identifier in den Metadaten im Datenregister unterschieden wird welcher Metadatensatz zu welcher Kommune gehört. Open-Data-Plattform Metadaten eigene Website eigene Website Kommune B CMS Verwaltungsportal Verwaltungsportal Daten-/App- Portal Daten-/App- Portal Daten/Apps suchen Datennutzer Kommune A Open-Data- Register Daten abfragen Datenspeicher Abbildung 6: Architekturoption B Zentrale Registry, zentraler Datenspeicher, individuelle Portale 10 Liferay Portal Software, 15

20 2 Technologische Aspekte Vor- und Nachteile der Architekturoptionen Beide Architekturoptionen bringen jeweils Vor- und Nachteile mit sich, die zusammenfassend in Tabelle 1 aufgelistet sind. Tabelle 1: Vor- und Nachteile der Architekturoptionen Option A Separate Plattforminstanzen Vorteile Nachteile Out-of-the-box Lösung, CKAN auch als Portal nutzbar Update/Patches/Sicherung des Datenregisters/ des Datenspeichers/des OS je Plattforminstanz Metadaten und Daten verschiedener Kommunen voneinander isoliert Evtl. zusätzlicher Aufwand für Föderation der Datenregister Option B Zentrales Register, zentraler Datenspeicher, individuelle Portale Vorteile Zentrale Pflege des Datenregisters und des Datenspeichers Kommunenübergreifendes Datenportal ohne Föderation verschiedener Datenregister möglich Nachteile Kommunikation zwischen Register und Portal ist zwingend zu implementieren CKAN standardmäßig nicht mandantenfähig Daten verschiedener Kommunen nur logisch separiert Die Umsetzung der Option A bringt den Vorteil mit sich, dass hier quasi eine Standard-Lösung zum Einsatz kommen kann, die in der Form schon mehrfach erfolgreich umgesetzt wurde. Bei der Verwendung von CKAN als Datenregister besteht hier insbesondere die Möglichkeit, auch die Portalfunktionalitäten von CKAN zu nutzen und auf ein separates CMS bzw. eine separate Portalsoftware für die Bereitstellung des Daten-, App- und Verwaltungsportals zu verzichten. Wie in den vorherigen Abschnitten bereits diskutiert, ist zuvor anhand der funktionalen Anforderungen für das Open-Data-Portal abzuschätzen, ob diese Lösung ausreichend ist, oder ob ein dediziertes CMS zum Einsatz kommen sollte. Ein weiterer Vorteil dieser Option kann darin gesehen werden, dass die von den verschiedenen Kommunen bereitgestellten Metadaten und Daten isoliert voneinander vorgehalten werden. Bei genauerer Betrachtung ist diese Isolierung jedoch nicht notwendig, da es sich um öffentliche Daten handelt. Dennoch ist nicht auszuschließen, dass diesbezüglich von Kundenseite entsprechende Anforderungen gestellt werden. Als nachteilig zu sehen ist der Umstand, dass bei separaten Plattform-Instanzen Updates und Patches der Softwarekomponenten pro Instanz vorgenommen werden müssen. Auch die Datensicherung ist für jede einzelne Instanz der Plattform einzurichten. 16

21 2.3 Diskussion von Architekturoptionen Sofern z. B. auf Landkreis- oder Landesebene der Bedarf entsteht, ein übergreifendes Open-Data-Portal bereitzustellen, das die Inhalte verschiedener kommunaler Portale aggregiert bzw. als One-Stop-Shop zur Verfügung stellt, so muss dafür explizit eine Föderation der verschiedenen Datenregister eingerichtet werden. CKAN bietet bereits sogenannte Harvesting -Funktionalitäten, durch die eine Föderation vereinfacht wird. Die Vor- und Nachteile der Option B sind im Wesentlichen invers zu denen der Option A. Datenregister und Datenspeicher können zentral gepflegt und gewartet werden. Je höher die Anzahl der Kunden, desto höher sind die damit verbundenen Effizienzgewinne gegenüber Option A. Eine Föderation verschiedener Datenportale ist ohne größere Aufwände möglich, da ein zentrales Datenregister verwendet wird, auf das lediglich ein entsprechendes übergeordnetes Datenportal aufgesetzt werden müsste. Erhöhter Aufwand entsteht bei der Umsetzung der Option B durch den Umstand, dass in jedem Fall ein separates CMS bzw. eine Portalsoftware für die Realisierung der individuellen Portale zum Einsatz kommen muss. Die Verwendung von CKAN für die Front-End-Funktionalitäten scheidet aus, da es für eine CKAN-Instanz nur ein (angepasstes) CKAN-Front-End geben kann. Der Umstand, dass CKAN nicht mandantenfähig ist, kann auch bei der Verwendung einer separaten Portalsoftware zusätzlich Work-Arounds erforderlich machen, z. B. im Hinblick auf den Umstand, dass verschiedene Kommunen unterschiedliche Schemata für Datenkategorien (wie z. B. Demographie, Umwelt, Soziales etc.) verwenden. Der Umstand, dass die Daten und Metadaten verschiedener Kunden nur logisch separiert sind, d. h. in einer zentralen Datenbank vorliegen, ist wie oben bereits ausgeführt nur bedingt als Nachteil zu sehen Empfehlungen aus architektureller Sicht In einem gemeinsam mit dem Auftraggeber durchgeführten Workshop zeigte sich, dass der GovConnect GmbH keine gesicherten Informationen zur Anzahl konkreter Interessenten an einem als Dienstleistung bereitgestellten Open-Data-Portal und zur Zahlungsbereitschaft potenzieller Kunden vorliegen. Allerdings wurde darauf hingewiesen, dass hinsichtlich der Zahlungskraft der Kommunen eine große Bandbreite existiert. Die Realisierung einer Lösung entsprechend Architekturoption B erfordert aufgrund des individuellen Charakters zunächst eine höhere Anfangsinvestition, die sich erst mit wachsender Kundenzahl amortisiert. Zudem bestehen hier u. U. noch kleinere technische Herausforderungen bzgl. der Herstellung der Mandantenfähigkeit. Daher ist unter Berücksichtigung der o. g. Rahmenbedingungen die Realisierung eine Plattform entsprechend Option A vorzuziehen. Für Kunden, die eine mittlere bis hohe Zahlungsbereitschaft mitbringen, kann diese vorgefertigte Plattform instanziiert und hinsichtlich Metadatenschemata, Portalfunktionalitäten und Erscheinungsbild individuell angepasst werden. Zeichnet sich eine hohe Nachfrage nach dem Angebot ab, so können die gegenüber der Option B eingesparten Mittel eher für die Realisierung von 17

22 2 Technologische Aspekte Automatisierungsmechanismen für die Instanziierung der Plattform und für das automatisierte Einspielen von Aktualisierungen der Softwarekomponenten eingesetzt werden. Parallel dazu kann erwogen werden, ein Angebot für Kunden mit sehr niedriger Zahlungskraft bereitzustellen. Hierfür kann für alle Kunden eine gemeinsame Instanz der nach Architekturoption A implementierten Plattform bereitgestellt werden. Diese Instanz verfügt über ein fest vorgegebenes Portal und über ein fixes Metadaten- und Kategorienschema. Da es sich um eine Minimallösung handelt, werden individuelle Anpassungen nicht vorgenommen. Für jeden neu hinzukommenden kommunalen Kunden wird lediglich ein Zugang zum Verwaltungsportal angelegt, der es dem Kunden ermöglicht offene Daten zu registrieren und damit über das gemeinschaftliche Portal auffindbar zu machen. Beim Anlegen eines Datensatzes wird in den Metadaten automatisch der Kunde vermerkt, sodass über das Portal auch dediziert nach Daten einer Kommune oder eines Landkreises gesucht werden kann. Eine mittel- bis langfristige Vision ist die Bereitstellung eines regelrechten Software-as-a-Service-Angebots mit dem sich Kunden über einen Web-Zugang im Self-Service ein Open-Data-Portal anlegen und dieses hinsichtlich visueller Gestaltung, Portalfunktionalitäten und Metadatenschema selbsttätig konfigurieren und administrieren können. Die mit dieser Ausbauoption verbundenen Aufwände sind jedoch ungleich höher, weshalb dieses Angebot hier nicht weiter diskutiert wird. 18

23 3.1 Wertschöpfung und Geschäftsmöglichkeiten bei Open Data 3 Markt- und betriebswirtschaftliche Aspekte I n diesem Abschnitt sollen die Kunden- und Erlösperspektive betrachtet werden, um so die Entwicklung möglicher Produkte und Geschäftsmodelle für die GovConnect GmbH vorzubereiten. Hierzu soll zunächst ein kurzer Überblick über die verschiedenen Geschäftsmöglichkeiten gegeben werden, wobei die verschiedenen Ansätze auch einer einfachen, rudimentären Bewertung unterzogen werden und ein erster Priorisierungsvorschlag unterbreitet wird. Für den Bereich der Open-Data-Portale sollen zudem einzelne Hinweise zu bestehenden Betreibern und Finanziers gegeben werden. In der Folge werden aufbauend auf den Priorisierungsvorschlägen zwei mögliche Produktausgestaltungen angerissen, die die Grundlage eines Geschäftsmodells der GovConnect für den Open-Data-Bereich bilden könnten. Abschließend werden die im Rahmen einer Umsetzung nächsten Schritte benannt und in einer groben Roadmap verortet. 3.1 Wertschöpfung und Geschäftsmöglichkeiten bei Open Data Das Wertschöpfungsmodell ist bei Open Data relativ simpel. Das Grundprinzip setzt voraus, dass der Staat Daten bereitstellt auf deren Basis Bürgerinnen, Bürger und Unternehmen eigene Wertschöpfungsmodelle entwickeln können. Neben der höheren Transparenz und einfacherem Engagement sollte also auch die privatwirtschaftliche Wertschöpfung gesteigert werden, indem aufgrund der öffentlichen Daten sowohl bisher nicht adressierte als auch bereits anderweitig befriedigte Bedarfe effizienter bedient werden können. Der Staat profitiert wiederum in Form einer gesteigerten Wohlfahrt und ggf. höherer Steuereinnahmen von diesen privatwirtschaftlichen Aktivitäten. Die Wertschöpfungskette ist dabei dem im vorherigen Kapitel beschriebenen Soll-Prozess sehr ähnlich: Die verschiedenen Verwaltungen und Ämter, die in einer Open-Data-Initiative partizipieren, stellen Daten bereit, die über ein Open Data Portal veröffentlicht werden und auf denen Bürgerinnen, Bürger und Unternehmen direkt oder indirekt aufsetzen, um eigene Wertschöpfungsmodelle zu realisieren. 19