Analyse der E-Government-Domäne Meldewesen am Beispiel des Dienstes einfache Melderegisterauskunft

Transkript

1 Analyse der E-Government-Domäne Meldewesen am Beispiel des Dienstes einfache Melderegisterauskunft Jan Lehmann, Werner Rotzoll DVZ Datenverarbeitungszentrum Mecklenburg-Vorpommern GmbH Lübecker Straße 283, Schwerin, Germany Stefan Kühne Universität Leipzig, Institut für Informatik, Abteilung Betriebliche Informationssysteme Augustusplatz 10 11, Leipzig, Germany Kurzfassung Die Datenverarbeitungszentrum Mecklenburg-Vorpommern GmbH (DVZ M-V) ist seit vielen Jahren als Systemhaus der Landesverwaltung Mecklenburg-Vorpommern tätig. Der aktuelle Schwerpunkt ist die Bereitstellung von nachgefragten E-Government-Diensten. Neu ist, dass offene, zum Teil über das Internet verteilte Systeme im Aufbau sind, die trotz Heterogenität der Hard- und Softwarekomponenten sicher, funktionstüchtig und stabil harmonieren müssen. Insbesondere in der E- Government-Domäne Meldewesen werden derzeit bundesweit enorme Anstrengungen unternommen, eine interoperable Infrastruktur zu etablieren und die ersten Dienste (elektronische Rückmeldung, Melderegisterauskünfte u. a.) Ende des Jahres 2006 zur Verfügung zu stellen. Gegenstand des Beitrags ist die Analyse der Domäne Meldewesen. Dazu werden Ziele und Stakeholder bestimmt und Informationen, die im Zusammenhang mit dem E-Government- Dienst einfache Melderegisterauskunft stehen, gesammelt und ausgewertet. Ferner wird eine E-Government-Zielarchitektur vorgestellt, um eine technische Sicht zu vermitteln. Anliegen ist es, Grundlagen für eine domänenspezifische Modellierung zu schaffen. Diese unterstützt nicht nur die Kommunikation der Beteiligten, sondern soll zukünftig auch Modelloperationen wie Transformation oder Validierung im Sinne einer modellgetriebenen Softwareentwicklung dienen. Modellierungen und Transformationen sind dabei unter den Aspekten der Integration von Komponenten, Prozesssteuerung, sicherer Betrieb und den damit einhergehenden Nutzungs-, Betreuungs- und Änderungsprozessen zur permanenten Unterstützung unterschiedlichster Interessengruppen anzugehen. 1. Einordnung und Zielstellungen einer Modellierungsunterstützung für offene, verteilte Systeme im Meldewesen Kernziel von E-Government ist das Entstehen einer,digitalen Verwaltung, deren Online- Angebot im Hinblick auf Information, Kommunikation, Dienstleistungen und Beteiligungsmöglichkeiten so weit möglich und rechtlich zulässig auf die Bedürfnisse der Bürger und Unternehmen, also auf die Bedürfnisse der Behördenkunden, zugeschnitten ist. [1, S. 3] 20

2 Im Zusammenhang mit der Umsetzung der gesetzlichen Bestimmungen aus dem Melderechtsrahmengesetz (MRRG), wonach Rückmeldungen bei einem Zuzug von Einwohnern und Fortschreibungen an die relevanten Meldebehörden (Wegzugsgemeinde, Meldebehörden der Nebenwohnungen) spätestens bis zum auf elektronischem Wege zu erfolgen haben, entsteht deutschlandweit derzeit ein Verbund von Meldebehörden unter Einbeziehung von Vermittlungsstellen (auch als Broker bezeichnet). Mehr und mehr treten Gesamtarchitekturen an die Stelle von Insellösungen. Schnittstellen müssen spezifiziert, konfiguriert und verändert werden können. Besonders relevant sind Schnittstellen zwischen Komponenten der sich schrittweise etablierenden serviceorientierten Architekturen (SOA). Für E-Government typisch sind Prozesse, die auf der Grundlage gesetzlicher Rahmenbedingungen analysiert und gestaltet werden. Diese Prozesse müssen im Verbund mit anderen Anwendungsbereichen (Bürger, Wirtschaft, andere Verwaltungen) auch über offene, unsichere Netze (Internet) sicher abgebildet werden. Systemhäuser und Systemintegratoren benötigten dringend eine durch Vorgehensmodelle, Methoden und Werkzeuge gestützte Modellierungsund Integrationstechnologie, die den besonderen Bedingungen komplexer offener Anwendungssysteme gerecht wird. Bestehende Methoden, wie Unified Modeling Language (UML), unterstützen nur teilweise die Formalisierung der zu unterstützenden Prozesse. Insbesondere die Schnittstelle zum Kunden, hier die Verwaltung, bedarf Alternativen. Aus diesem Grunde wird das Ziel verfolgt, auch über den Einsatz domänenspezifischer Sprachen (DSL) alternative Wege zu beschreiten. Sind erst einmal nutzbare, transformier- und validierbare Modelle aufgestellt, können diese im erheblichen Maße zur Verbesserung von Effizienz und Qualität der bereitzustellenden Dienste beitragen. Durch die Auswahl des E-Government- Dienstes einfache Melderegisterauskunft wurde die Domäne Meldewesen weiter eingegrenzt. Ausgangspunkt für eine textuelle und wissensbasierte Analyse waren Gesetze, Verordnungen und Vorschriften. Das technische Zielsystem ist eine auf Basiskomponenten basierende und durch Standards vorgegebene E- Government-Architektur. Die ersten Schritte auf dem Wege zu einer Domänenmodellierung eine formale Datenerfassung unter dem Aspekt der Domäneneingrenzung sowie eine Datensammlung und erste Analysen wurden angegangen. 2. Kurzbeschreibung der E-Government-Domäne Meldewesen Das Meldewesen in Deutschland ist dezentral organisiert. Die Zuständigkeit für das Einwohnermeldewesen ist nach 1 Abs. 1 Melderechtsrahmengesetz (MRRG) in die Regelungskompetenz der Länder gegeben. Es gelten Landesmeldegesetze (LMG). Danach werden in allen Bundesländern die Gemeinden als zuständige Meldebehörden bestimmt. Es existiert folglich die dezentrale Datenhoheit der einzelnen Meldebehörden, Einwohnerdaten in Melderegistern zu führen. Die IT- Landschaft in den Meldebehörden ist sehr heterogen. Die Melderegister mit den über die Einwohner vorliegenden Daten dienen als Informationsbasis für eine Vielzahl von Aufgaben. Durch einen Rückgriff auf diese Daten lassen sich unterschiedlichste staatliche, private und privatwirtschaftliche Anforderungen optimal erledigen, soweit die gesetzlichen Voraussetzungen dafür geschaffen wurden. Beteiligte für einen künftigen Informationsverbund Meldewesen sind die mehr als Meldebehörden Deutschlands, darunter allein in Mecklenburg- Vorpommern gegenwärtig 117. Relevante Dienste im Meldewesen sind: Einfache Melderegisterauskunft, Behördenauskunft, Elektronische Rückmeldung, Elektronisches Führungszeugnis, An-, Ab- und Ummeldung über das Internet, Datenübermittlungen. 21

3 Der elektronische Zugriff auf Daten führt zur Steigerung der Effizienz und zur Senkung der Prozesskosten. E-Government im Meldewesen wird diese Vorteile noch weiter ausbauen und Bürgerinnen und Bürgern, Unternehmen und Behörden die Zusammenarbeit mit den Meldebehörden über das Internet ermöglichen. Die bereitzustellenden Lösungen stellen hohe Ansprüche an den Datenschutz und an die Datensicherheit. 3. Kurzcharakteristik des Dienstes einfache Melderegisterauskunft Die einfache Melderegisterauskunft (emra) ist ein Internet-Dienst. Ihre gesetzliche Grundlage ist der 21 des Melderechtsrahmengesetzes (MRRG): Melderegisterauskünfte können auf automatisiert verarbeitbaren Datenträgern, durch Datenübertragung oder im Wege des automatisierten Abrufs über das Internet erteilt werden. Für die Nutzung des Dienstes gelten folgende Rahmenbedingungen: 1. Die Anfrage wird über eine Portalanwendung gestellt. Für Großkunden, die eine Mehrfachanfrage stellen, werden separate Zugangsmöglichkeiten geschaffen. 2. Der Antragsteller oder die anfragende Person identifiziert die gesuchte Person mit Vor- und Familiennamen sowie mindestens zwei weiteren optionalen Angaben (Geburtsdatum, Geschlecht und Anschrift). 3. Die Identität der gesuchten Person kann durch einen automatisierten Abgleich der im Antrag angegebenen und mit den im Melderegister gespeicherten Daten des Betroffenen eindeutig festgestellt werden. Die einfache Melderegisterauskunft wird z. B. bei der Adresssuche oder dem Adressabgleich durch Inkasso-Firmen, Versandhäuser aber auch durch Private, z. B. bei der Vorbereitung eines Klassentreffens herangezogen. Anfragen (auch negative Bescheide) sind kostenpflichtig. Die Auskunft wird erst dann erteilt, wenn der Bezahlprozess erfolgreich abgeschlossen werden konnte. Die Höhe der Gebühren ist in Gebührenverordnungen der Länder festgelegt und differiert zwischen 4 bis 10 je angefragte Person. Als Zahlungsverfahren können bspw. Kreditkartenzahlung und Lastschrifteinzugsverfahren zugelassen werden. 4. Analyseergebnisse des Gesetzestextes des Landesmeldegesetzes Mecklenburg-Vorpommern (LMG M-V) 4.1. Rollen und deren Aufgabenzuordnung Aus dem Gesetzestext leiten sich folgende Rollen in der Nutzung des emra-dienstes ab: Meldebehörde, Bürger, Betroffener, anfragende Person, gesuchte Person, Portalbetreiber, Vermittlungsstelle, beteiligte Personen. Hinter der Rolle des Portalbetreibers verbergen sich jedoch weitere beteiligte Personen, sodass das Spektrum der Rollen recht breit ist. Die Ausprägung der Rollen durch Personen und Personengruppen führen uns zu den Stakeholdern, den Interessengruppen, die differenziert zu unterstützen sind. Die den Rollen per Gesetz zugeordneten Aufgaben entsprechen folgenden Kategorien: G = gesetzlich, F = funktional, O = organisatorisch, T = technisch, S = sicherheitstechnisch. Beispielhaft soll für die Rollen Meldebehörde, anfragende Person und Portalbetreiber die Aufgaben abgeleitet und Kategorien zugeordnet werden. 22

4 Meldebehörde: übernehmen die Aufgaben laut Gesetz, führen Melderegister und erteilen Auskünfte, sind angemessen an den Einnahmen zu beteiligen. Anfragende Person: muss in dem Verfahren eindeutig identifiziert werden. Portalbetreiber: hat eine öffentlich-rechtliche Einrichtung zu sein, andernfalls bedarf es einer gesonderten Zulassung und übernimmt folgende Aufgaben: Registrierung der Anfragenden, Entgegennahme und Weiterleitung der Anfragen an Meldebehörden oder andere Portale, Entgegennahme von Antworten, stellt die Antwortdaten an Auskunftssuchende bzw. andere Portale zur Verfügung hat die Gebührenfeststellung, -erhebung und deren Verteilung sicherzustellen, ist für die Gewährleistung des Datenschutzes und der Datensicherheit verantwortlich, hat Daten nur für die unmittelbare Aufgabenerfüllung zwischenzuspeichern und anschließend zu löschen. Diese Beispiele zeigen, dass das LMG, das MRRG und die Datenschutzgesetzgebungen die entscheidenden Rahmenbedingungen aus rechtlicher, funktionaler, organisatorischer, technischer und sicherheitstechnischer Sicht vorgeben. Die Rahmenbedingungen sind bei der Umsetzung stringent zu beachten Bestimmung und Eingrenzung der Zielgruppen für den Aufbau und Betrieb eines Auskunftsportals Meldewesen Die Umsetzung des emra-dienstes ist im LMG geregelt. Die Meldebehörden können als Auftraggeber eingeordnet werden. Der Dienst wird über einen Portalbetreiber unter Einbeziehung einer Vermittlungsstelle zur Verfügung gestellt. Der Portalbetreiber ist für den Zugang zum Dienst, die Vermittlungsstelle für den Zugang zu den Einwohnerdaten zuständig. Dahinter verbirgt sich wieder eine Vielzahl beteiligter Personen. Für die Etablierung des Dienstes sind die Entwicklung und die Aufnahme des Wirkbetriebes erforderlich. Abbildung 1 zeigt die sich überlagernden Bereiche Entwicklung und Wirkbetrieb, die durch den Portalbetreiber zu organisieren sind. Abbildung 1: Beziehungen von Zielgruppen bei der Bereitstellung von E-Government-Diensten. 23

5 Von entscheidender Bedeutung ist das Zusammenwirken zwischen Auftraggeber (hier Verwaltung) und dem Servicemanagement beim Portalbetreiber. Diese Kommunikationsschnittstelle bedarf beschreibender Mittel, in denen sich insbesondere der Auftraggeber bzw. die Verwaltung wiederfindet. Die Beziehung zwischen Servicemanagement und Entwicklung ist durch Methoden zu unterstützen, die Transformation und Validierung anwendbar machen. Bei der Beziehung Servicemanagement zu Systemintegration stehen Orchestrierung und Validierung im Vordergrund. Die Beziehung Servicemanagement und Wirkbetrieb bedarf einer leistungsfähigen Unterstützung von Service-, Problem- und Changemanagementprozessen. In der Beziehung Systemintegration und Entwicklung stehen Architekturaspekte, Komponentenbeschreibungen, Schnittstellen und deren Überwachung im Vordergrund. Abbildung 3: Funktionale Aspekte. Organisatorisch gilt es insbesondere die Beziehungen zwischen den unterschiedlichen Stakeholdern zu spezifizieren und zu regeln (vgl. Abbildung 4). Dies ist herkömmlich sehr aufwendig. Eine entsprechende Unterstützung wäre deshalb hilfreich Ergänzende Bemerkungen zur Rolle des Servicemanagers/Fachbetreuers Der Servicemanager/Fachbetreuer hat die meisten Schnittstellen zu anderen Stakeholdern. Exemplarisch soll der Handlungsrahmen des Servicemanagers/Fachbetreuers beschrieben werden. Bei E-Government-Diensten gilt es, im Rahmen der gesetzlichen Bestimmungen zu agieren (vgl. Abbildung 2). Abbildung 2: Gesetzliche Grundlagen. In diesem Rahmen hat der Servicemanager ein breites Spektrum von Anforderungen zu erfüllen. Dazu wird eine Handlungsunterstützung benötigt. So werden aus funktionaler Sicht nicht nur die Prozessabläufe, sondern z. B. eine Übersicht der Datenobjekte benötigt. Die verwendeten Datenobjekte sind im Meldewesen durch den OSCI-XMeld-Standard vorgegeben und geben Auskunft über den verarbeiteten Datenumfang (vgl. Abbildung 3). Abbildung 4: Organisatorische Aspekte. Technisch ist die Vielzahl von Komponenten in unterschiedlichen Zuständigkeitsbereichen verteilt. In der vorliegenden Anwendung emra liegen Zuständigkeiten bei der anfragenden Person, dem Portalbetreiber, der Vermittlungsstelle und den Meldebehörden. Trotzdem ist die Funktionsfähigkeit des Gesamtsystems durch den Servicemanager/Fachbetreuer sicherzustellen. Dazu benötigt er auch technische Informationen (vgl. Abbildung 5). 24

6 Abbildung 5: Technische Aspekte. Die technische Komponenten- und Schnittstellenübersicht ermöglicht die Identifizierung der prozessrelevanten Komponenten. Diese Komponenten müssen zur Sicherstellung der Funktionsfähigkeit des Gesamtsystems auf Validierungs-, Protokollierungs- und Monitoringmöglichkeiten geprüft werden. Es ist sicherzustellen, dass bei den zu verarbeitenden Datenvolumen die geforderte Performance des Systems erreicht wird. Sicherheitstechnisch stellt der emra-dienst insbesondere wegen des Zugangs zu personenbezogenen Daten sehr hohe Anforderungen, deren Vorgaben in einem speziell angefertigten Sicherheitskonzept umzusetzen sind (vgl. Abbildung 6). Abbildung 6: Sicherheitstechnische Aspekte. Regelmäßige Reviews sind durch den Servicemanager/Fachbetreuer zu veranlassen, um die Umsetzung der Maßnahmen zur Einhaltung der Sicherheitsanforderungen zu gewährleisten. Aus der Komplexität und der Vielfalt der Anforderungen an einen Servicemanager leitet sich ein Bedarf an prozessunterstützenden Instrumenten ab (vgl. Abbildung 7). Abbildung 7: Unterstützungsmöglichkeiten Einordnung der Stakeholder in eine Modellarchitektur Grundlage für den Einsatz einer werkzeugtechnischen Unterstützung sind passende Modellierungssprachen und -methoden. Die in diesem Abschnitt durchgeführte Zielbestimmung, die Charakterisierung der Domäne Meldewesen durch die Erhebung von Daten und die Ermittlung von Rollen und deren Aufgabenverteilung legen die Grundlagen dafür, dass Anforderungen an Modelle gestellt und Klassifizierungen von Modellen vorgenommen werden können. Die unterschiedlichen Zielstellungen der Stakeholder erfordern eine Modellierung auf verschiedenen Abstraktionsebenen. Das Spektrum reicht dabei von fachlich-abstrakten Modellierungsebenen, welche für Auftraggeber und Service-Management relevant sind, bis zu technisch-konkreten Modellierungsebenen für die Gruppen Entwicklung und Systemintegration. In Abbildung 8 ist eine mögliche Modellarchitektur dargestellt. Auf der untersten Ebene befindet sich die E-Government-Plattform, welche aus verschiedenen Infrastruktur- und Basiskomponenten besteht. Die technische Integration der Komponenten erfolgt auf der Integrationsebene. Hier können z. B. auf Basis von Web-Service-Technologien die systemübergreifende Orchestrierung der Komponenten beschrieben werden. Die darüber liegenden Modellierungsebenen, wie die technische und fachliche Prozessmodellierungsebene, beschreiben Prozesse mit abnehmend technischem Detaillierungsgrad bzw. zunehmend fachlichem Abstraktionsgrad. Untersuchungen von Forschungspartnern beschäftigen sich mit der Anwendbarkeit des Model-Driven Integration Engineering (MDIE) [2] unter Nutzung von Domain Specific Languages [3] sowie klassischer Modelltypen, wie Ereignisgesteuerte Prozessketten (EPK) [4]. Diese werden eingegrenzt auf die E-Government- Domäne Meldewesen. Dabei müssen Modelltypen, die als Grundlage für die Erzeugung von Quellcode (z. B. Orchestrierungsmodelle), Scripten, Reports u. a. dienen, die Besonderheiten der Zielarchitektur der E-Government- Plattform berücksichtigen. Daher wird diese im Folgenden beschrieben. 25

7 Szenarienübersicht Funktions- und Komponentenübersicht Fachliche Prozessmodellierung Technische Prozessmodellierung Technische Integration (z. B. BPEL4WS) E-Government-Plattform (z. B. Verzeichnisdienst, BPMS, Portal, Payment) Auftraggeber Servicemanagement Entwicklung und Systemintegration Wirkbetrieb Abbildung 8: Einordnung der Stakeholder in eine Modellarchitektur. 5. Zielarchitektur der E-Government-Plattform 5.1. E-Government-Architektur des Landes Mecklenburg-Vorpommern Die Architektur der E-Government-Landesinfrastruktur Mecklenburg-Vorpommerns orientiert sich an den Standardarchitekturen für E- Government-Anwendungen (SAGA). [5] Zum Einsatz kommen Basiskomponenten, also mehrfach durch verschiedene Anwendungen nutzbare Bausteine. Beispiele sind Portal, Virtuelle Poststelle, Verzeichnisdienst u. a. Abbildung 9 zeigt die Gesamtarchitektur des Landes Mecklenburg-Vorpommern. Der Dienst emra geht über drei Netzbereiche: das Internet, der demilitarisierten Zone im Rechenzentrum (DMZ) und dem Intranet als verwaltungsinterner Bereich. Es kommen die Basiskomponenten Portal, Virtuelle Poststelle (VPS), epayment und Verzeichnisdienst (VD) zum Einsatz. Im Backend- Bereich ist das Prozessmanagement (Business Process Management System) die Kernkomponente Bearbeitungsvorgang einer einfachen Melderegisterauskunft Im Folgenden wird der Bearbeitungsvorgang einer einfachen Melderegisterauskunft aus technischer Sicht beschrieben. Die anfragende Person stellt eine Anfrage mittels des Formulars für die einfache Melderegisterauskunft im Portal. Dieses Portal befindet sich in der DMZ. Die Anfrage wird geprüft und mittels OSCI-Transport [6] (verschlüsselt, signiert) an die Virtuelle Poststelle (VPS) gesendet. OSCI (Online Service Computer Interface) ist ein standardisiertes und in der Verwaltung für einen sicheren Datentransport verbindliches Transportprotokoll. Aus dem geschützten Netzwerk (Intranet) wird von innen nach außen auf die VPS zugegriffen und die Anfrage abgeholt. Es erfolgt eine nochmalige Prüfung der Anfrage. Anschließend wird die Anfrage an das Fachverfahren, dass im Falle der emra ein zentrales Informationsregister (ZIR) mit den Meldedaten aller Bürger des Landes M-V (Auskunftsdatenbestand) ist, weitergeleitet. Die Antwort, die durch das ZIR erstellt wurde, wird aufbereitet und mittels OSCI-Transport in die VPS im Internet verschlüsselt und signiert gesendet. Dort wird die Antwort durch das Portal abgeholt und dem Endanwender bereitgestellt. Bei der Befüllung des ZIR und dessen permanenter Aktualisierung sind Transportaufgaben vom Melderegister (MR) über das Verwaltungsnetz zur Vermittlungsstelle sicher umzusetzen. Dazu wird ebenfalls das OSCI- Transportprotokoll eingesetzt. 26

8 Abbildung 9: E-Government-Zielarchitektur M-V Die Kernkomponente Business Process Management System (BPMS) Das BPMS übernimmt die Steuerung der Backendprozesse. Anfragenachrichten von em- RA werden einer Schemaprüfung unterzogen und in ein internes Format konvertiert. Es wird eine so genannte virtuelle Fallakte initialisiert und die Daten werden in einer Datenbank so lange gehalten, wie es zur Abarbeitung des Prozesses notwendig ist. Der eigentliche Steuerungsprozess beinhaltet eine Auskunftsberechtigungsprüfung, die Ansteuerung eines Webservices zur Bereitstellung der Auskunftsergebnisdaten und die Bereitstellung der Ergebnisdaten. Die BPMS-Engine basiert auf der Business Process Execution Language (BPEL). Modelle als Grundlage zur Generierung von BPEL sind eine sich aus der Architektur ableitende Anforderung Besondere Einordnung von OSCI-Transport Für die elektronische Datenübermittlung im Meldewesen wird der Standard OSCI-XMeld verbindlich zum Einsatz gebracht. Eine Grundlage für die Standardisierung bildete der Datensatz für das Meldewesen Einheitlicher Bundes-/Länderteil - (DSMeld). Dieser Standard trifft Aussagen über die zwischen den Verfahren zu übermittelnden Inhaltsdaten. Für den sicheren Transport von Nachrichten wurde der Standard OSCI-Transport entwickelt. OSCI-Transport ist der Standard für ein Datenübermittlungsprotokoll, welches eine sichere Datenübermittlung sowohl über öffentliche Netze (z. B. das Internet), als auch über verwaltungseigene Kommunikationsnetze erlaubt. In OSCI-Transport wurde das Rollenmodell Autor/Sender und Empfänger/Leser umgesetzt. Somit kann sichergestellt werden, dass nur Au- 27

9 tor und Leser Einsicht in Inhaltsdaten nehmen können. OSCI-Transport ist hochgradig konfigurierbar. So kann z. B. durch den Sender einer Nachricht festgelegt werden: ob und wie die Inhaltsdaten (also der eigentliche Nachrichteninhalt) signiert und/oder verschlüsselt werden, ob und wie die Nutzungsdaten (also Daten zur Steuerung und zum Nachvollzug einer Datenübermittlung, mit Angaben über Sender und Empfänger, Übermittlungszeitpunkten etc.) signiert und/oder verschlüsselt werden, ob die Daten synchron (also mit unmittelbarer Antwort des Senders) oder asynchron (also analog der klassischen ) ausgetauscht werden, welches technische Transportprotokoll auf der Nachrichtenebene zwischen den jeweiligen OSCI-Transport-Instanzen genutzt werden soll, z. B. http oder ftp (vgl. auch [7]). Die Forderung nach einem sicheren Transport der laut LMG zulässigen Einwohnerdaten aus den Melderegistern in das ZIR führte zur Einsatzentscheidung für OSCI-Transport. Daraus leitete sich die Notwendigkeit ab, eine OSCI-Transportinfrastruktur aufzubauen, in der Autor und Sender im Bereich der Meldebehörden, Empfänger und Leser im Verantwortungsbereich der Vermittlungsstelle liegen Ausblick auf Brokerverbund Der derzeitig in Mecklenburg-Vorpommern im Aufbau befindliche Verbund von Meldebehörden zu Auskunftszwecken wird perspektivisch zu einem bundesweiten Verbund von Brokern ausgebaut. Broker handeln im Auftrage der Meldebehörden und tauschen Anfragen und Anfrageergebnisse aus, falls die Auskunftsdaten nicht im eigenen Zuständigkeitsbereich liegen. Bei dem Aufbau eines Brokerverbundes ist eine Vielzahl rechtlicher, organisatorischer und technischer Aufgaben zu lösen, sodass diese Entwicklung erst in den kommenden Jahren einer Lösung zugeführt wird. Abbildung 10 zeigt das Kommunikationsschema zwischen Brokern. Abbildung 10: Brokerverbund [8, S. 301]. 28

10 6. Zusammenfassung Ziel des Beitrages war es, die vielfältigen Herausforderungen der Domäne E-Government darzustellen. Am Beispiel der einfachen Melderegisterauskunft wurden die ersten Ergebnisse einer Domänenanalyse des Bereichs Meldewesen präsentiert. Dabei zeigten sich die Komplexität und die Vielfältigkeit der Aufgaben in diesem Bereich. Die beteiligten Personengruppen müssen hinsichtlich gesetzlicher, funktionaler, organisatorischer, technischer und sicherheitstechnischer Anforderungen unterstützt werden. Die differenzierten Beziehungen zwischen diesen Stakeholdern erfordern den Einsatz unterschiedlicher Modelltypen. Nur wenn es gelingt, die E-Governnment-Dienste technologiegestützt zu begleiten, können Effizienz in der Umsetzung und im Betrieb mit der geforderten Qualität erreicht werden. Ansätze zur Lösung der beschriebenen Problematik finden sich im Bereich der modellgetriebenen Entwicklung. Über bedarfsgerechte/ domänenspezifische Modellierungen werden relevante Aspekte der umzusetzenden Systeme für unterschiedliche Personengruppen erfasst und können über Modelloperationen, wie Transformation und Validierung, weiter verwendet werden. Durch das OrViA-Prozessframework [9] wird hierfür ein grob-strukturiertes Vorgehen vorgeschlagen. Da durch OSCI-XMeld [8] der Standardisierungsgrad bereits sehr fortgeschritten ist, wird in dieser Domäne mit der Umsetzung weiterer Services kurz- und mittelfristig zu rechnen sein. Die E-Government-Domäne Meldewesen bietet somit ein hinreichendes Betätigungsfeld, die Tragfähigkeit der Konzepte und den sich ergebenden Mehrwert zu evaluieren. Literatur [1] Projektgruppe E-Government im Bundesamt für Sicherheit in der Informationstechnik (BSI): Chefsache E-Government Leitfaden für Behördenleiter. Abruf am [2] Thränert, Maik; Kühne, Stefan: Model Driven Integration Engineering und seine Anwendung im Projekt OrViA. In: Fähnrich, Klaus-Peter; Kühne, Stefan; Speck, Andreas; Wagner, Julia (Hrsg.): Integration betrieblicher Informationssysteme, Problemanalysen und Lösungsansätze des Model-Driven Integration Engineering. Eigenverlag Leipziger Informatik-Verbund (LIV), Leipzig 2006, S [3] Kühne, Stefan; Christian Welzel: Metamodellierung am Beispiel der E- Government-Domäne Meldewesen und Eclipse GMF. In: Fähnrich, Klaus-Peter; Kühne, Stefan; Speck, Andreas; Wagner, Julia (Hrsg.): Integration betrieblicher Informationssysteme, Problemanalysen und Lösungsansätze des Model-Driven Integration Engineering. Eigenverlag Leipziger Informatik-Verbund (LIV), Leipzig 2006, S [4] Specht, Thomas; Drawehn, Jens; Höß, Oliver: Domänenspezifische Modellierung von E-Government-Szenarien. In: Fähnrich, Klaus-Peter; Kühne, Stefan; Speck, Andreas; Wagner, Julia (Hrsg.): Integration betrieblicher Informationssysteme, Problemanalysen und Lösungsansätze des Model-Driven Integration Engineering. Eigenverlag Leipziger Informatik-Verbund (LIV), Leipzig 2006, S [5] KBSt: SAGA Version 2.1: Standards und Architekturen für E-Government- Anwendungen Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt). Abruf am [6] OSCI Leitstelle (Hrsg.): OSCI-Transport osci_spezifikation_1_2_deutsch.pdf, Abruf am [7] Die OSCI-Leitstelle: OSCI Informelle Beschreibung. Abruf am

11 30 [8] Projektgruppe OSCI-XMeld: OSCI- XMeld Spezifikation Version 1.2 / Stand 21. Januar /Spezifikation%20xmeld12.pdf, Abruf am [9] Stein, Sebastian; Kühne, Stefan; Wagner, Julia: Das Forschungsprojekt OrViA Orchestrierung und Validierung integrierter Anwendungssysteme. In: Fähnrich, Klaus-Peter; Kühne, Stefan; Speck, Andreas; Wagner, Julia (Hrsg.): Integration betrieblicher Informationssysteme, Problemanalysen und Lösungsansätze des Model-Driven Integration Engineering. Eigenverlag Leipziger Informatik-Verbund (LIV), Leipzig 2006, S