MISTRA ASTRA. Review Sollarchitektur MISTRA

Transkript

1 MISTRA ASTRA Review Sollarchitektur MISTRA Kst.-Stelle Bericht Version Datum Autor(en) Status Visum LST, HBU Gültig sig. HBU ELCA Seilerstrasse 4 - CH-3011 Bern Tel. +41 (0) Fax +41 (0) info@elca.ch Lausanne - Zürich - Bern - Genf - London - Paris - Ho Chi Minh City

2 Management Summary Dieses Review prüfte die im Pflichtenheft vorgeschlagene Sollarchitektur für das MISTRA Basissystem. Nachfolgend werden die Ergebnisse des Reviews den gesteckten Zielen (grün hinterlegt) gegenübergestellt: Sicherstellen der technischen, betriebs- und volkwirtschaftlichen Akzeptanz der Lösung bei den verschiedenen Anwendergruppen (ASTRA, Kantone, Agglomerationen). Ein besonderes Augenmerk gilt dabei einer möglichst niedrigen Eintrittsschwelle für die Nutzung der Lösung bei Kantonen und Agglomerationen. Die Vorgaben im Pflichtenheft nehmen Rücksicht auf den breiten anvisierten Benutzerkreis, die Kantone sind allgemein informiert über MISTRA. Es erscheint uns sinnvoll, dass möglichst rasch die vollständige Liste der unterstützten Systemumgebungen mit den verschiedenen Anwendern abgestimmt und die vorgesehene Verteilung von MISTRA mit ihnen definiert wird. Um auch eine betriebswirtschaftlich sinnvolle Lösung für Kantone und Agglomerationen zu sein, sollte MISTRA sich mit auf dem Markt erhältlichen Produkten vergleichen und mit ihnen messen lassen. Dazu müssen die möglichen Anwender von MISTRA präzise über den vorgesehenen Funktionsumfang und die finanziellen Rahmenbedingungen informiert werden. Gewährleisten der nötigen Offenheit, Modularität und Integrierbarkeit der Lösung in einem sich wandelnden Umfeld. Insbesondere Klärung bezüglich der Kompatibilität mit der IT-Strategie Bund und den Vorgaben von ISB und BIT. Sicherstellen der Wechselwirkungen zwischen den angepeilten ASTRA-IT- Systemen wie IDM, Websphere o. gleichwertiges, SAP-Applikation, PROCON, Web-GIS KOGIS und dem MISTRA-Basissystem. Sicherstellen der nötigen Robustheit und Offenheit gegenüber resp. für Änderungen und Erweiterungen, damit diese nicht zu explodierenden Kosten führen. Das Review hat gezeigt, dass mit den Vorgaben im Pflichtenheft ein System definiert wird, welches sich an die Bundesvorgaben hält und die Strategie befolgt. Mit den vorgesehenen Standardschnittstellen und dem modularen Aufbau ist auch eine gute Integrierbarkeit in die verschiedenen Umgebungen beim ASTRA, den Kantonen und Agglomerationen vorgegeben. Die Ziele, welche hinter diesen Vorgaben stecken, können nur erreicht werden, wenn im weiteren Verlauf des Projekts diese weiter durchgesetzt werden und auch geprüft wird, dass diese eingehalten werden. Handlungsbedarf sehen wir vor allem noch ASTRA-intern, bei der Beschreibung der Geschäftsprozesse, deren Abbildung auf die Systeme und der Festlegung der ASTRA IT-Strategie. Nur mit diesen Vorarbeiten kann MISTRA optimal mit den anderen Systemen integriert werden. V 1.2 / / HBU, LST 2 / 64

3 Sicherstellen einer sowohl technisch als auch finanziell umsetzbaren Vorgabe, die dort, wo nötig, genügend Lösungsspielraum offen lässt, damit die Konkurrenzsituation zwischen den Anbietern genutzt werden kann. präzise fordert, was die Lösung bieten muss. Das Pflichtenheft ist im allgemeinen recht offen und lässt Raum für unterschiedliche Lösungen. Im Bereich der nicht funktionalen Anforderungen ist es aus unserer Sicht gar noch zu offen diese sollten erweitert und präzisiert werden (siehe E- diese sollten erweitert und präzisiert werden (siehe Empfehlungen in Kapiteln 4.4 und 6.2). Auf der anderen Seite empfehlen wir die Einschränkung auf.net zu prüfen. Ermöglichen, dass auf Grund der vorgegebenen Architektur eine Lösung entstehen kann, welche die geforderten Geschäftsprozesse unterstützt. Wie oben erwähnt, ist die vorgesehene Architektur von MISTRA genügend offen, dass sich MISTRA in verschiedenen Umfeldern und in unterschiedliche Geschäftsprozesse integrieren lässt. Ob die Geschäftsprozesse effizient unterstützt werden, kann im jetzigen Stadium nicht abschliessend beurteilt werden. Damit dies beim ASTRA konkret umgesetzt werden kann, muss unbedingt eine ASTRA-weite IT-Architektur definiert werden. Der Reviewbericht enthält eine Reihe von Empfehlungen, welche nun im weiteren Projektverlauf von MISTRA und den verschiedenen Teilprojekten umgesetzt werden sollten. Es erscheint uns sinnvoll, wenn später, sobald die Lösungsarchitektur detailliert ausgearbeitet worden ist, diese wieder prüfen zu lassen. V 1.2 / / HBU, LST 3 / 64

4 I. Inhaltsverzeichnis II. III. IV. Änderungsjournal...5 Referenzierte Dokumente...5 Abkürzungen...6 V. Notation Einführung Kontext Ziele Zielpublikum Struktur des Dokumentes Vorgehen Übersicht der vorgeschlagenen Architektur Systemaufbau und grenzen Systemarchitektur MISTRA Systemarchitektur Basissystem Einbettung der Sollarchitektur in die IT-Landschaft des Bundes Einleitung Kompatibilität mit der ISB Kompatibilität mit den Vorgaben aus der SIP EFD Kompatibilität mit der IT-Strategie ASTRA Kompatibilität mit der Strategie KOGIS MISTRA für Kantone und Agglomerationen Einleitung Laufzeitumgebung Funktionale Anforderungen Nicht funktionale Anforderungen Umsysteme von MISTRA MISTRA und die Umsysteme bei ASTRA Einleitung Sicht IT Architektur ASTRA Integrationsplattform (WebSphere) Sicht MISTRA Architektur Einleitung Nicht funktionale Anforderungen Kompatibilität mit Best Practices FAT-Client und/oder Web-Client Data Warehouse(s) (DWH) Datenmigration Pflichtenheft allgemein...62 V 1.2 / / HBU, LST 4 / 64

5 II. Änderungsjournal Dateiname Version Datum Bemerkung / Autor MISTRA_Reviewbericht_V09.doc Dokument bereit zur Abnahme / HBU, LST MISTRA_Reviewbericht_V10.doc Einarbeitung Kommentare ASTRA / HBU, LST MISTRA_Reviewbericht_V11.doc Einarbeitung Kommentare ASTRA, definitive Version / HBU, LST MISTRA_Reviewbericht_V12.doc Einarbeitung Kommentare Hr. Blaser/ LST III. Referenzierte Dokumente [BinfV] [BIT-ITPlan- Homepage] V 1.2 / / HBU, LST 5 / 64 Verordnung über die Informatik und Telekommunikation in der Bundesverwaltung, zuletzt besucht: [BIT-KommMatrix] Kommunikationsmatrix, BIT, 2. Juni 2003 [BIT-ProdListe] [Datenkatalog] Produktliste BIT (inventaires des softwares installés dans les différents offices) MISTRA, "Datenkatalog Sockeldaten", ASTRA, Version Voranalyse, [F&B_Feb2004] MISTRA, Fragenbeantwortung Studienauftrag, , _D Fragenbeantwortung Gesamt.doc [Feedback] "Review Sollarchitektur MISTRA", ASTRA, [Glossar] MISTRA, "Glossar", ASTRA, [IDM-Voranalyse] IDM ASTRA, Bericht Voranalyse, V1.0, [ILI2GML3] [ISB-ArchEntw] INTERLIS 2 GML 3 Eine Vergleichsstudie; Stephan Nebiker, Susanne Bleisch, Adrian Annen; Studienauftrag der KOGIS; 16. Februar 2004 Vorgehen Architekturentwicklung Bund (R012), V1.01 vom [ISB-ArchVorg] Architekturvorgaben Bund (R009), V vom [ISB-FabaImp] Integration Fabasoft-Imperia (E014), V1.0 vom [ISB-Interop] Basisstandards Interoperabilität (I007), V1.0 vom [ISB-Leitbild] Informatikleitbild Bund vom [ISB-RIAB] Referenzmodell für die Informatikarchitektur Bund (R001), V1.3 vom [ISB-WS] Web Services (I013), V1.0 vom

6 [IS-UVEK] Informatikstrategie UVEK, August 2000 (teilweise überholt) [JSR168] Java Portlet Specification (final release vom 27. Okt., 2003) zuletzt besucht: [KOGIS-Strategie] Strategie für Geoinformation beim Bund, V [KUBAMISTRA] [OpenGIS- RefModel] [Pflichtenheft] Teilprojekt KUBA-DB / MS; Beurteilung der Kompatibilität mit MISTRA, Version 1.0 vom OpenGIS Reference Model, Kurt Bühler, V0.1.2, MISTRA, "Teilprojekt Basissystem, Pflichtenheft", ASTRA, Version Voranalyse, [Projektauftrag] MISTRA, "Kurzbericht Projektauftrag", ASTRA, [SIP-EFD] Strategische Informatikplanung des EFD, V1.5, [UMFRAGE] Benutzerumfrage Strassendaten, Schlussbericht Januar 2003 [WebSphere] IV. Abkürzungen 15. Februar zuletzt besucht: Die schon im [Glossar] erklärten Begriffe werden nicht systematisch in der folgenden Tabelle erklärt. AG BA BCI BIT BPM CMS DBA DFS DK DMS DMZ DWH EAI EFD ERP Arbeitsgruppe Basisapplikation Business Collaboration Infrastructure Bundesamt für die Informatik und Telekommunikation Business Process Modelling Content Management System Database Administrator Digitaler Fahrtenschreiber Datenkatalog Document Management System Demilitarized Zone Datawarehouse Enterprise Application Integration Eidgenössisches Finanzdepartement Enterprise Resource Planning V 1.2 / / HBU, LST 6 / 64

7 ETL FA GML GUI IDM IKS ISB J2EE JSR KOMBV KTV LDAP NFA OS PH PL PMS RAC RDBMS SDB SIP SNMP TP BS UVEK VSAM Extraction, Transformation, Load Fachapplikation Geography Markup Language Graphical User Interface Integriertes Dokumentenmanagementsystem Informations- und Kommunikationssystem Informatikstrategie des Bundes Java 2 Enterprise Edition Java Specification Requests Basisnetzwerk für die Kommunikation der Bundesverwaltung Kantonales Netzwerk Lightweight Directory Access Protocol Neuordnung Finanzausgleich und Aufgabenteilung zwischen Bund und Kantonen Operating System Pflichtenheft Projektleitung Pavement Management System = Erhaltungsmanagement für Fahrbahnen Real Application Cluster Relational Database Management System Sockeldatenbank Strategische Informatikplanung Simple Network Management Protocol Teilprojekt Basissystem Eidgenössisches Departement für Umwelt, Verkehr, Energie, Kommunikation Virtual Storage Access Method V 1.2 / / HBU, LST 7 / 64

8 V. Notation Als Ergebnis des Reviews resultieren Empfehlungen, die im Dokument ausformuliert und begründet werden. Empfehlungen werden wie folgt dargestellt und nummeriert: E1 Beispiel Dies ist ein Beispiel einer Empfehlung. Dient der Illustration der im Dokument verwendeten Notation. Umsetzen: Sagt wer, was, bis wann umsetzen soll. Empfehlungen werden im restlichen Dokument über die Nummer referenziert: z.b. Siehe auch E1 (Seite 8). Die verschiedenen Umsetzungstermine werden in Abbildung 2 auf Seite 12 dargestellt. V 1.2 / / HBU, LST 8 / 64

9 1 Einführung 1.1 Kontext Die Programmsysteme STRADA, zur Verwaltung von Strassendaten, und ISA, zur Verwaltung der Finanzdaten der Strasseninfrastruktur, sind in die Jahre gekommen und müssen ersetzt werden. Mit dem Projekt MISTRA ist ein Management-Informations-System Strasse und Strassenverkehr zu erstellen, welches die strategische, konzeptionelle und operative Steuerung der ASTRA-Aufgabenbereiche Netzkonzipierung, Netzbereitstellung (Bau, Ausbau, Unterhalt, Betrieb) und Netznutzung sowie sinngemässer Aufgaben professioneller Strasseneigentümer und strassenbezogener Netzbetreiber unterstützt. Das System, welches sich auf ein geographisches Informations- und Kommunikations-System (IKS) stützt, soll in Zusammenarbeit mit Kantonen, Agglomerationen und verschiedenen Bundesämtern sowie einschlägigen Fachorganisationen erstellt werden. Eine Studie hat im Jahr 2003 ergeben, dass die gesuchte Lösung nicht als Fertigprodukt auf dem Markt existiert. Die Gesamtheit der Anforderungen kann nur mit einer entsprechenden Konfektionierung und Ergänzung von Standardprodukten erfüllt werden. Im Pflichtenheft für die Ausschreibung der ersten Projektphase wurden bewusst wenig Vorgaben an die Lösungsarchitektur gemacht. Damit kam durch die verschiedenen Anbieter ein breites Lösungsspektrum zusammen. Im Rahmen der Studienaufträge wurden verschiedene Lösungsvorschläge vertieft. Für die weitere Phase des Projekts wird/wurde nun ein neues Pflichtenheft mit einer überarbeiteten Sollarchitektur für MISTRA ausgearbeitet. 1.2 Ziele Mit dem externen Review der neuen Version der Sollarchitektur sollen durch ein kritisches und unvoreingenommenes Hinterfragen der Lösungsansätze folgende Ziele erreicht werden: Sicherstellen der technischen, betriebs- und volkwirtschaftlichen Akzeptanz der Lösung bei den verschiedenen Anwendergruppen (ASTRA, Kantone, Agglomerationen). Ein besonderes Augenmerk gilt dabei einer möglichst niedrigen Eintrittsschwelle für die Nutzung der Lösung bei Kantonen und Agglomerationen. Gewährleisten der nötigen Offenheit, Modularität und Integrierbarkeit der Lösung in einem sich wandelnden Umfeld. Insbesondere Klärung bezüglich der Kompatibilität mit der IT-Strategie Bund und den Vorgaben von der ISB und vom BIT. Sicherstellen der Wechselwirkungen zwischen den angepeilten ASTRA-IT- Systemen wie IDM, Websphere o. gleichwertiges, SAP-Applikation, PROCON, Web-GIS KOGIS und dem MISTRA-Basissystem. V 1.2 / / HBU, LST 9 / 64

10 Sicherstellen der nötigen Robustheit und Offenheit gegenüber resp. für Änderungen und Erweiterungen, damit diese nicht zu explodierenden Kosten führen. Sicherstellen einer sowohl technisch als auch finanziell umsetzbaren Vorgabe, die dort, wo nötig, genügend Lösungsspielraum offen lässt, damit die Konkurrenzsituation zwischen den Anbietern genutzt werden kann. präzise fordert, was die Lösung bieten muss. Ermöglichen, dass auf Grund der vorgegebenen Architektur eine Lösung entstehen kann, welche die geforderten Geschäftsprozesse unterstützt. 1.3 Zielpublikum Dieses Dokument richtet sich an alle Personen, welche in der Ausarbeitung der Anforderungen an die Sollarchitektur MISTRA involviert werden. 1.4 Struktur des Dokumentes Dieses Dokument ist wie folgt gegliedert : Das Kapitel 2 gibt eine Kurzbeschreibung der Lösungsarchitektur aus dem [Pflichtenheft], damit der Bericht auch ohne referenzierte Dokumente gelesen werden kann. In Kapitel 3 wird geprüft, in wie weit die Sollarchitektur mit den verschiedenen Bundesvorgaben übereinstimmt. Kapitel 4 stellt die Sollarchitektur den Bedürfnissen der Kantone gegenüber. In Kapitel 5 wird beurteilt, ob MISTRA in die IT-Landschaft von ASTRA passt. Allgemeine Architekturüberlegungen werden der Sollarchitektur in Kapitel 6 gegenübergestellt. Das Kapitel 7 enthält allgemeine Empfehlungen zum Pflichtenheft. V 1.2 / / HBU, LST 10 / 64

11 1.5 Vorgehen Für dieses Review wurde die im Pflichtenheft (PH) beschriebene Soll-Architektur mit verschiedenen Rahmenbedingungen und Vorgaben gegenübergestellt (siehe auch Abbildung 1). Soll Architektur PH Rahmenbedingungen ISB Rahmenbedingungen BIT Rahmenbedingungen ASTRA Reviewbericht Rahmenbedingungen Kantone Abbildung 1 Rahmenbedingungen und Vorgaben Die Rahmenbedingungen und Vorgaben lagen in verschiedenen Formen vor: In Form von Dokumenten (siehe Kapitel III mit den Dokumentreferenzen). In Form von Interviews mit zuständigen Personen. Die folgenden Personen wurden im Rahmen dieses Reviews involviert: Bereich Zuständige Person Amt/Firma/Kanton Einbettung MISTRA in IT- Systemlandschaft des Bundes (ISB, BIT, UVEK, ASTRA) P. Bürki, L. Junker IT-ASTRA IT-ASTRA Integrationsplattform ASTRA H.-P. Seiler IT-ASTRA Architektur MISTRA E. Bernard InfoLite Benutzung MISTRA Fachliche Aspekte V 1.2 / / HBU, LST 11 / 64 Hrn. Kunz, Hösli und Gasser Hrn. Vögeli, Lambelet und Keller J.-D. Burnat, P. Grellet R. Dieterle C. Käser, Th. Mahrer Kanton ZH Kanton AG Kanton NE ASTRA ASTRA ASTRA Umsystem ISA H.-P. Blaser ASTRA

12 Die Struktur des restlichen Dokuments folgt den Bereichen, welche im Rahmen dieses Reviews beurteilt wurden. Diese Bereiche wurden gemeinsam mit der Projektleitung MISTRA festgelegt. Erkannte Abweichungen von Vorgaben und aus unserer Sicht offene Punkte wurden aufgenommen und entsprechende Empfehlungen formuliert. Diese Empfehlungen basieren auf unserem Wissensstand. Es ist durchaus möglich, dass gewisse Empfehlungen bereits umgesetzt worden sind, dass sie auf uns nicht bekannten oder nicht mehr aktuellen Informationen basieren. Die folgende Abbildung zeigt die kommenden Phasen des Projektes mit den vier geplanten Versionen des Pflichtenheftes. Diese Versionsnummern werden in den Empfehlungen benutzt, um die Umsetztermine festzulegen. Voranalyse Voranalyse Konzept Konzept Angebot Angebot Realisierung Realisierung DK 1 DK 2 DK 3 DK 4 Review- Bericht 1 PH 1 PH 2 PH 3 PH 4 DK = Datenkatalog PH = Pflichtenheft 01/ / / / /2005 Abbildung 2 Versionen des Pflichtenhefts und des Datenkatalogs V 1.2 / / HBU, LST 12 / 64

13 2 Übersicht der vorgeschlagenen Architektur Dieses Kapitel gibt eine Kurzbeschreibung der im Pflichtenheft vorgeschlagenen Sollarchitektur, damit dieser Bericht auch ohne referenzierte Dokumente gelesen werden kann. Eine detaillierte Beschreibung kann im Kapitel 5 vom Pflichtenheft [Pflichtenheft] gefunden werden. 2.1 Systemaufbau und grenzen Dieses Unterkapitel ist aus dem Kapitel vom [Pflichtenheft] extrahiert. Schematisch dargestellt sieht die Systemgrenze (schraffierte Linie) von MISTRA in der Übersicht wie folgt aus: Lieferanten Kanton, SNS, NABEG, Fachdienstleister usw. New ASTRA Kunden SNS, Kantone, ARE, KOGIS, BAV, BFS, BUWAL, usw. BCI/IKS = Basissystem Legende: FA FA FA Lärm FA Unfallschwerpunkte FA Basisapplikationen Metadaten zu Basis- und Generalistendaten (Sockeldaten-Administration, GIS-Fachschale, Analyse+Report, Achsband) Daten über Daten (Eigentümer, Erfasser,, Erfassung, Genauigkeit, usw.) Generalistendaten Strassen und Strassenverkehr: Finanzzuordnung pro Objekt, Zuständigkeiten, Administration, u sw. Basisdaten Strassen und Strassenverkehr : Fahrbahnaufbau & -nutzung, geometrische Profile, Netze, Routen, Achsen, Objektinve ntar, usw. Übrige Basisdaten: Pixelkarten, VECTOR25/200, Orthobilder,, Adressen, Höhenmodelle, Geografische Namen, usw. Geschäftsprozesse unterstützt durch spezifische Fachapplikation FA Wandern (gow@lk) FA Unfallerhebung FA Verkehrsunfälle FA Erhaltungsmanagem. NS Metadaten zu Spezialistendaten FA Neu-/Ausbauprojekte FA Netzdefinition IT-Systeme (HW, OS) / Datenbanken FA Langsamverkehr Daten über Daten (Eigentümer, Erfasser,, Erfassung, Genauigkeit, usw.) Datenmigration FA Sonderbewilligungen Spezialistendaten Strassen und Strassenverkehr: Oberbau, Kunstbauten, Technische Anlagen, Verkehr, Langsamverkehr, Unfälle, Historisierung, usw. FA Bauprojekt-Controlling FA Übergeo. Finanzplanung FA Trassen bestehende Fachapplikationen z.b. KUBA, Strada, EMS, ISA, u.v.a.m. FA Kunstbauten FA GIS-Server Server / Internet / Intranet WEB-GIS: UH-PERI WEB-GIS: IVS Verk.-Meldungenstatistik Webservice Datenkatalog +Datenmodell geo.c@t von KOGIS Webservice Datenmodell Gestützt auf die erwarteten Ergebnisse werden die Beziehungen der Objekte festgelegt BCI/IKS Webservices für Kunden Systemgrenze MISTRA Business Collaboration Infrastructur / Informations- und Kommunikationssystem Kommunikation Messdaten Labordaten Detaildaten Kunstbauten Detaildaten Elektromech. Messnetz Zählerdaten ISA Finanzdaten Spezialistendaten nicht GIS-fähig MISTRA-Phase I: 1. ohne Betrieb 2. ohne Verkehrsmanagement 3. mit Focus I: Infrastruktur NS, LV und Unfälle V 1.2 / / HBU, LST 13 / 64 Abbildung 3 Systemaufbau und -grenzen Es wird ein gemeinsames Informations- und Kommunikationssystem, die Business Collaboration Infrastructure (BCI), aufgebaut und für alle Beteiligten zur Verfügung gestellt, damit Fachapplikationen effektiv und effizient erstellt werden können. Die BCI stellt das Basissystem von MISTRA dar und besteht aus den Teilen IT- Systeme, Datenbanken, Basis-Applikationen, Internet/Intranet und den Generalisten- und Basisdaten zu Strassen und Strassenverkehr. Die BCI bildet die Informatik- und Netzwerkumgebung der verschiedenen Beteiligten ab, sodass eine konstruktive und effiziente Zusammenarbeit mit allen ohne Medienbrüche ermöglicht wird. Das bedeutet, dass die BCI heterogen, teilweise zentral, teilweise dezentral aufgebaut wird. Dank der Einhaltung der vereinbarten

14 Standards (Datenmodell, Datenkatalog, Web-Technologie, GIS-System, Datenbanken, IT-Netzwerk, usw.) können die EDV-Systeme mit den Applikationen und Daten zusammenarbeiten. Die Basis-Applikationen sind Bestandteil der BCI und des Basissystems MISTRA. Sie dienen der Bewirtschaftung der Basisdaten sowie dem Bezug von Sockeldaten für Auswertungen. Daten mit Raumbezug werden über eine GIS-Benutzeroberfläche bewirtschaftet. Hohe Priorität hat die rasche Bereitstellung einer GIS- Basisapplikation sowie eines Analysewerkzeugs (Analyse und Reports). Weitere Basis-Applikationen sind für Achsbanddarstellungen und eine Anwendung zur Administration der Sockeldaten vorgesehen. Die Sockeldaten in der BCI umfassen alle Basisdaten sowie alle diejenigen Daten aus den Fachapplikationen, welche für mehrere Fachbereiche von Interesse sind (Generalistendaten). Für Fachanwendungen werden Spezialistendaten benötigt, erfasst und nicht als Teil der BCI verwaltet. Der Zugriff auf die Sockeldatenbank erfolgt über Schnittstellen, welche sowohl für den Online-Zugriff als auch für den Offline-Zugriff über INTERLIS-Transfers realisiert werden. 2.2 Systemarchitektur MISTRA Dieses Unterkapitel ist aus dem Kapitel vom [Pflichtenheft] extrahiert. Das Kernstück der Lösung ist das Basissystem mit der Sockeldatenbank (SDB). Das Basissystem ist Daten- und Informationsdrehscheibe zwischen den verschiedenen Anwendungen und Systemen, sowohl intern wie auch bei den Beziehungen mit den Lieferanten (Kantone, Agglomerationen, Fachdienstleiter) wie auch den Kunden. Je nach Applikation (Fach-, Webservice) wird entweder auf die SDB oder Fachdatenbank (KUBA, STRADA, Verkehr, LV usw.) alleine oder in Kombination miteinander auf Informationen zugegriffen. Grundsätzlich befinden sich alle applikationsübergreifenden Daten in der SDB. Mit verschiedenen Bundesämtern, den Kantonen und Agglomerationen und gewissen Gemeinden (Städte) wird ein entsprechender Datenaustausch zwischen den verschiedenen Datenbanken stattfinden. Mit gewissen Stellen wird dies, sofern wirtschaftlich und technisch sinnvoll, direkt online erfolgen, ansonsten offline. Via Webservices und Web-Applikationen wird die breite Öffentlichkeit über das Internet auf aufbereitete Informationen zugreifen können. Diese Anwendungen und die entsprechenden Daten könnten einfach mit der Web-GIS-Lösung von KOGIS umgesetzt werden. V 1.2 / / HBU, LST 14 / 64

15 Abbildung 4 MISTRA Basissystem und Fachapplikationen V 1.2 / / HBU, LST 15 / 64

16 2.3 Systemarchitektur Basissystem Dieses Unterkapitel ist aus dem Kapitel vom [Pflichtenheft] und aus [F&B_Feb2004] extrahiert. AnwenderInnen ASTRA / Bund Anw. Internet FAT-Client Browser Browser Client tier Fach-GUI Basis-GUI B C Data tier Application tier (Appl.Server) (Fach-Appl.) Data-Access Fachdaten D A Appl.Server Basis-Appl. Data Access Sockeldaten Web-Server Appl.Server WebServices Map-Server Firewall Extrakt Web-Server Appl.Server WebServices Map-Server Data-Access Daten Produktionsumgebung Internet-Infrastruktur WAN Bund (KOMBV) DMZ Bund (BIT) Abbildung 5 Logische Architektur MISTRA Die in der Abbildung in oranger Farbe abgebildeten, dick umrandeten Elemente (Bereiche A bis C) sind Gegenstand von MISTRA. Die Pfeile zeigen den Verlauf des Datenflusses. Die einzelnen Bereiche umfassen: A. Umgebung für die Bewirtschaftung der Basisdaten an GIS-Arbeitsplätzen (Fat- Clients) B. Umgebung für die Betrachter im Intranet. Die AnwenderInnen greifen auf die aktuelle, produktive Version der Sockeldaten. C. Umgebung für die Betrachter im Internet (read-only). Die AnwenderInnen greifen auf ein repliziertes Extrakt der Sockeldaten zu. D. Umgebung für die Bewirtschaftung der Fachdaten über Fachapplikationen an Fat-Clients. V 1.2 / / HBU, LST 16 / 64

17 Bemerkungen: Die Zielplattform für Server ist Windows 2003 oder höher, für Clients Windows XP oder höher. Die Systemarchitektur ist logisch als 3-tier-Architektur dargestellt. In vielen Anwendungsfällen ist eine Zusammenlegung von Data Access und Application Tier zu erwarten. Für den Low-End-Bereich muss auch eine Installation auf einem einzelnen Arbeitsplatz möglich sein. Das Data Tier umfasst die Komponenten für den Zugriff zu den Daten. Diese beinhalten die Datenbanksoftware, allfällige zusätzliche Fertigprodukte (z.b. RIS, SDE, Oracle Spatial) sowie das MISTRA-Interface zu den Sockeldaten Die Sockeldatenbank ist physisch nicht zwingend als monolithische Datenbank auszubilden. Sie kann sich aus mehreren Datenbanken und Dateisammlungen zusammensetzen. Die Integrität der Daten muss jedoch gewährleistet sein. Es sind relationale Datenbanken zu verwenden. MISTRA muss sowohl im Mehrbenutzer- als auch im Einbenutzerbetrieb funktionieren. Im Mehrbenutzerbetrieb sind Zugriffskonflikte abzufangen; bei Fehlern muss der letzte konsistente Zustand der Daten wieder hergestellt werden können. Der Datenbankzugriff zwischen dem MISTRA-Interface und den Data-Access- Schichten der Fertigprodukte muss systemunabhängig erfolgen. Herstellerspezifische Elemente, insbesondere Stored Procedures sind zu minimieren. Es muss möglich sein, die einer Applikation zugrunde liegende Datenbank durch Produkte unterschiedlicher Hersteller auszuwechseln. Die referentielle Integrität ist ohne Verwendung von Stored Procedures sicher zu stellen. Das Application Tier enthält die Funktionen für die Datenverarbeitung. In den herkömmlichen Fat-Client-Umgebungen sind diese Funktionen i.d.r. im Client- Tier enthalten. Im Sinne der Entlastung der Clients und der Senkung von Lizenz-, Installationsund Betriebskosten strebt MISTRA eine serverorientierte Lösung an. Im Studienauftrag gilt es zu prüfen, inwieweit Web-Services sowohl für (Fat-) GIS- Clients als auch für Browser-Clients verwendet werden können (in Abbildung 5 gestrichelt dargestellt). Viewing-, Analyse- und Auswertungsfunktionen müssen möglichst weitgehend über Web-Services abgedeckt werden, schreibende Funktionen im Rahmen der heutigen technischen Möglichkeiten, z.b. für die Nachführung von Sachdaten sowie für einfache grafische Bearbeitungen, für Planerstellung usw. Die Fachapplikationen müssen standalone, d.h. ohne MISTRA funktionieren können. Für den Bezug von Sockeldaten und das Schreiben von Generalistendaten werden die MISTRA-Interfaces benutzt. Aus sicherheitstechnischen Gründen wird für den Internetzugang in der Bundesverwaltung eine separate Infrastruktur betrieben. Die KOGIS ist im Begriff, die Internetanwendungen des Bundes zu koordinieren. Voraussichtlich wird den interessierten Bundesämtern eine zentral betriebene Intranet-/Internet- Infrastruktur zur Verfügung gestellt. Diese Infrastruktur soll auch von MISTRA genutzt werden. MISTRA-seitig sind Funktionen für die Bereitstellung der Daten vorzusehen. Für den Teil C, rechts "Internet-Infrastruktur" soll auf die Web-GIS-Plattform der KOGIS aufgebaut werden. Zur Zeit läuft ein Pilotprojekt bei der Firma V 1.2 / / HBU, LST 17 / 64

18 CampToCamp in Lausanne. Die eingesetzten Produkte sind Minnesota Map- Server und CartoWeb von CampToCamp. Die KOGIS-Pilot-Infrastruktur dient ausschliesslich als Viewer. Gemäss heutigem Terminplan soll der produktive Betrieb Mitte 2005 auf der Infrastruktur des BIT oder Dritten aufgenommen werden. Wichtiger Bestandteil von KOGIS WebGIS ist, nebst der HW-/SW- Infrastruktur, die Bereitstellung einer WebGIS-Toolbox, mit welcher verschiedene Bundesämter rasch einfache Web-Applikationen aufsetzen und in ihre eigenen Web-Auftritte einbinden können. Es ist möglich, dass bei der Realisierung des Basissystems Komponenten von der Intranetseite in die WebGIS-Plattform KOGIS übernommen werden. Diese wird erst nach Abschluss der Phase Konzept entschieden. V 1.2 / / HBU, LST 18 / 64

19 3 Einbettung der Sollarchitektur in die IT-Landschaft des Bundes 3.1 Einleitung Beim Bund gibt es verschiedene, hierarchisch aufgebaute Vorgaben, welche ein IT- System einhalten sollte. Für MISTRA sind die Vorgaben, die berücksichtigt werden sollten, die folgenden: Die Informatikstrategie des Bundes (ISB). Die Strategische Informatikplanung (SIP). Da noch keine SIP für das UVEK existiert, wird die SIP des EFD als Referenz benutzt. Wir haben die im Pflichtenheft vorgeschlagene Architektur und die dort formulierten Anforderungen an MISTRA den oben erwähnten Vorgaben gegenübergestellt. Nebst den Vorgaben Bund, Departement und Amt ist für MISTRA als GIS System auch die Strategie für Geoinformation des Bundes (KOGIS) relevant. Wir haben diese auch dem Pflichtenheft gegenübergestellt. 3.2 Kompatibilität mit der ISB Die ganze Dokumentation der ISB ist unter publiziert. Die im Pflichtenheft für MISTRA vorgeschlagene Architektur und die Anforderungen sind kompatibel mit der ISB. Wir empfehlen, gewisse Vorgaben aus der ISB, welche bereits implizit im Pflichtenheft berücksichtigt wurden, noch explizit ins Pflichtenheft aufzunehmen: E2 Vorgaben aus der ISB referenzieren Das Pflichtenheft sollte mit den folgenden Referenzen aus der ISB ergänzt werden und an den entsprechenden Stellen darauf verwiesen werden: Basisstandards Interoperabilität (I007) Interoperabilitätsstandards Für Web Services (I013) Die relevanten Begriffe müssen ins Glossar übernommen werden (z.b. UDDI, WSDL, WSS). I007 listet die für die Beschaffung, die Umsetzung und den Betrieb von Informatikprogrammen und -produkten vorgeschriebenen Interoperabilitätsstandards auf. Diese sollten allen Studienauftragnehmern bekannt sein und bei der Lösung berücksichtigt werden. I013 präzisiert die verschiedenen Standards, die hinter dem viel und z.t. auch unterschiedlich gebrauchten Begriff 'Web-Services' stehen und hilft so, allfällige Missverständnisse zu vermeiden. Zudem regelt dieses Dokument auch die Bundesvorgaben für nicht funktionale Aspekte bei Web-Services im Bereich Security. Umsetzen: PH 2, TP BS V 1.2 / / HBU, LST 19 / 64

20 3.3 Kompatibilität mit den Vorgaben aus der SIP EFD Stellvertretend für eine SIP auf Departementsniveau, haben wir jene des EFD [SIP-EFD] dem Pflichtenheft gegenübergestellt (jene des UVEK ist teilweise überholt, siehe auch [IS-UVEK]). Die Informatikstrategie des EFD ist insofern relevant, als sie auch für das BIT verbindlich ist, welches in Zukunft auch den Betrieb von MISTRA übernehmen könnte (z.z. müsste dies noch so sein). Die Sollarchitektur im Pflichtenheft hält die im SIP EFD (Seite 16) formulierten Architekturgrundsätze ein (u.a. 3-tier-Architektur, Architektur, webbasiert). Die Vorgabe.NET widerspricht jedoch der SIP EFD (J2EE vorgegeben). E3.NET Vorgabe lockern An mehreren Stellen wird im Pflichtenheft.NET als Standardarchitektur fürs neue MISTRA vorgegeben. Wir sind der Meinung, dass hier, serverseitig das mögliche Lösungsspektrum etwas erweitert werden sollte und neben.net auch J2EE zugelassen werden sollte. Clientseitig macht diese Erweiterung weniger Sinn, da die meisten Arbeitsplätze des ASTRA, der Kantone, der Agglomerationen und der Gemeinde mit der Microsoft-Technologie ausgerüstet sind und auch eine entsprechende Office Integration (Word, Excel) gefordert wird. Wir empfehlen das Pflichtenheft wie folgt anzupassen: Kapitel 4.2.2: In den Systemzielen 9 und 11 sollte in der Liste mit den Standards nicht nur.net als Architekturstandard, aber.net oder J2EE vorgegeben werden. Kapitel 5.2.5: Das COM-Interface nicht als.net-remoting-interface definieren (.NET-Remoting lässt mehrere Kommunikationsmöglichkeiten offen), sondern hier eine Web-Service (SOAP) Schnittstelle vorgeben. Interne Eigenschaft des Systems, welche nicht zwangsläufig im Pflichtenheft festgelegt werden muss. Wenn für das COM-Interface SOAP vorgegeben wird, kann diese Schnittstelle mit verschiedenen Technologien implementiert werden, ohne dass dies die Umsysteme direkt tangiert. Lässt den Studienauftragnehmern noch mehr Freiraum, was zu interessanteren Lösungen führen kann (.NET Lösung ist natürlich auch noch möglich)..net ist nicht mit der SIP EFD kompatibel..net passt auch nicht unbedingt mit einem allfälligen Einsatz der WebSphere Tools beim ASTRA zusammen (WebSphere ist eher auf J2EE ausgerichtet; siehe Kapitel 5.3 auf Seite 30). Das.NET-Framework läuft z.z. nur auf den Microsoft Betriebssystemen produktiv. Damit würde durch diese Vorgabe automatisch auch das serverseitige Betriebssystem vorgegeben (Windows Server 2003; siehe auch E5 auf Seite 23). Umsetzen: PH 2, TP BS V 1.2 / / HBU, LST 20 / 64