Eidgenössisches Departement für Umwelt, Verkehr, Energie und Kommunikation UVEK Bundesamt für Strassen ASTRA Mühlestrasse 2, 3063 Ittigen Standortadresse: Mühlestrasse 2, 3063 Ittigen Postadresse: Markus Maeder, 15.2.2017 Architekturmanagement Leitfaden Architekturkonformität ASTRA DG-IT M483-0210 Vorgabe Impressum Erstelldatum / Revisiondatum: 15.02.2017 Ersteller/in: Markus Maeder, DG-IT Verzeichnis / Dateiname: VO_Leitfaden_Architekturkonformität_X00.919.docx Anzahlseiten: 10 Genehmigt am: 15.2.2017 Genehmigt von: ABA Änderungsverzeichnis Version Datum Ersteller Bemerkungen X00.90 20.8.2014 M. Maeder Anpassungen an Hermes 5 und neuen PM Leitfaden X00.91 09.05.2016 M Leutenegger Gekürzte Version erstellt X00.99 17.01.2017 M. Maeder Version für Freigabe 0.991 30.1.2017 W. Hoffmann Überarbeitung 1.0 15.2.2017 M. Maeder Freigegebene Version durch ABA 1.01 3.4.2017 W. Hoffmann Input Jum eingearbeitet
Referenzen Referenz Version Datum Bemerkungen 1 1.4 17.2.2016 Leitfaden IT-Projektmanagement im ASTRA Präzisierungen und Konkretisierungen zu HERMES 5 N222-0024 2 1.0 14.11.2013 Reglement IT-Architekturboard ASTRA M323-1788 3 17.8.2016 IT Architekturvorgaben für das ASTRA N064-0326 4 1.0 24.11.2015 Architekturprinzipien ASTRA P173-0083 5 0.99 Architekturprozesse 6 1.0 1.2.2017 Prüfprotokoll für Lieferobjekte in Projekten 7 1.0 1.2.2017 Prüfprotokoll für Lieferobjekte bei Anpassungen von Anwendungen 2/11
INHALTSVERZEICHNIS Architekturmanagement Leitfaden Architekturkonformität 1 Strategische Informatik ASTRA 1 1. Ausgangslage 4 1.1. Zweck und Abgrenzung 4 1.2. Beteiligte Rollen 4 1.3. Motivation 4 2. Vorgaben 5 3. Architekturkonformität 5 4. Aktivitäten und Resultate 6 4.1. Für Projekt 6 4.2. Anpassung von Anwendungen 9 3/11
1. Ausgangslage 1.1. Zweck und Abgrenzung Dieser Leitfaden richtet sich an Projektleiter sowie Wartungsleiter. Er beschreibt den Architekturkonformitätsprozess sowohl für Projekte als auch für Anwendungen welche sich in der Wartung befinden. Der Begriff Architektur umfasst die folgenden Architekturdomänen: - Geschäftsarchitektur - Informationsarchitektur, aufgeteilt in Anwendungs- und Datenarchitektur - Technologiearchitektur - Sicherheitsarchitektur In den nachfolgenden Ausführungen beinhaltet der Begriff Architektur ausschliesslich die Anwendungs- und die Sicherheitsarchitektur. Mit Architekturkonformität(sprüfung) wird damit sowohl Anwendungsarchitektur- als auch Sicherheitsarchitekturkonformität(sprüfung) bezeichnet. 1.2. Beteiligte Rollen Der Leadarchitekt ist für alle Architekturfragen ein kompetenter Partner in den Projekten und bei Änderungen von Anwendungen. Er stellt sicher, dass Vorgaben (Gesetze, Bund, Departement, Amt, Domäne) in den zugeteilten Projekten und Anwendungsänderungen berücksichtigt werden und richtet die Architektur an der Informatikstrategie des Amtes aus. Der Leadarchitekt ist somit nicht eine Kontrollstelle, die man erst kontaktiert, wenn man Ergebnisse überprüfen möchte. Er arbeitet je nach Bedarf der Governance mehr oder weniger bei der Erstellung der Lösungsarchitektur mit und muss bei Architekturfragen frühzeitig beigezogen werden. Des Weiteren muss frühzeitig der Informatiksicherheitsbeauftragte des ASTRA hinzugezogen werden, um relevante Einflüsse der Sicherheitsarchitektur auf die Anwendungsarchitektur und umgekehrt festzustellen. 1.3. Motivation Mit den Architekturprinzipien ASTRA sind klar definierte Regeln vorhanden welche durch die Architekturkonformität umgesetzt werden. Das Ziel ist die mittelfristige Ausrichtung der einzelnen Anwendungsarchitekturen auf die IT-Strategie des ASTRA und des Bundes. Die konsequente Umund Durchsetzung der Vorgaben optimieren und vergünstigen neue IT-Lösungen. Dieses Dokument ist ein Hilfsmittel für Projektleiter, Wartungsleiter und Projektbeteiligte zur Erreichung dieses Ziels. 4/11
2. Vorgaben Das IT-Architekturboard ASTRA führt eine Liste mit den Architekturvorgaben für das ASTRA [3] und deren Geltungsbereich. Die Vorgaben kommen von verschiedenen Stellen (Bund, ISB, UVEK, ASTRA). Der Leadarchitekt ist bestrebt, die relevanten Vorgaben so zu verdichten, dass Projektbeteiligte einen schnellen Einstieg finden und nicht sämtliche Detailinformationen durcharbeiten müssen. Der Leadarchitekt tritt als erste Anlaufstelle für Architekturfragen auf und unterstützt die verantwortlichen Projekt- und Wartungsleiter/Anwendungsverantwortliche beratend. Die Lösungsarchitektur wird in Zusammenarbeit mit dem Leadarchitekten in ADOit dokumentiert. Für die Prüfung der Architekturartefakte muss dem Leadarchitekten/ISBO genügend Vorlaufzeit eingeräumt werden (nach Absprache). 3. Architekturkonformität Der Architekturkonformitätsprozess gliedert sich für Projekte und Anpassungen an bestehenden Anwendungen in drei generische Prozessschritte. Diese Schritte werden in jeder Projektphase o- der Anpassung durchlaufen. 1) Prüfobjekt definieren 2) Prüfobjekte erarbeiten 3) Prüfobjekte prüfen 1) Die Prüfobjekte werden gemeinsam durch den Projektleiter / Wartungsleiter/Anwendungsverantwortlicher und den Leadarchitekten/ISBO anhand der jeweiligen Vorgaben (vgl [3]) definiert. 2) Der Projektleiter bzw. Wartungsleiter erarbeitet mit den weiteren Beteiligten und mit allfälliger Beratung/Unterstützung durch den Leadarchitekten/ISBO die vereinbarten Prüfobjekte. 3) Der Leadarchitekt/ISBO prüft die Prüfobjekte auf deren Konformität gemäss [3] und gibt, wenn die Konformität gewährleistet ist, diese frei. Der detaillierte Architekturprozess ist in [5] beschrieben Hinweis: Bei komplexen Prüfobjekten wie der Systemarchitektur hat es sich bewährt, bei verschiedenen Fertigstellungsgraden Prüfungen vorzunehmen (z.b. 30%,50%,90%), damit das Projekt möglichst wenig Korrekturen vornehmen muss. Der Bedarf an Reviews wird im Rahmen des Projektes in gegenseitigem Einvernehmen zwischen Projektleiter, Wartungsleiter und Leadarchitekt/ISBO geplant und definiert. Es kann verschiedene Ursachen geben, welche eine Anpassung der architekturrelevanten Dokumente und der Amtsarchitektur allgemein notwendig machen: - neue Verordnungen/Gesetze auf fachlicher Ebene - neue Verordnungen auf technischer Ebene (z.b. BINV) - Änderung des Schutzbedarfs aufgrund neuer Anforderungen für neue Releases - neue Schnittstellen - neue Strategien BUND/UVEK/ASTRA - neue Vorgaben BUND/UVEK/ASTRA - Life Cycle von Produkten - weitere 5/11
4. Aktivitäten und Resultate Dieses Kapitel gliedert sich in zwei Teile. Im ersten Teil werden die für Projekte relevanten Aktivitäten im Bereich Architektur aufgeführt, im zweiten für Anpassungen an Anwendungen (Wartung, Changes). 4.1. Für Projekt In diesem Kapitel werden die vom Projekt auszulösenden Aktivitäten, die zu liefernden Dokumente sowie die Tätigkeiten der Architektur in Zusammenhang mit der Überprüfung der Architektur- und Sicherheitskonformität beschrieben. Die einzelnen Aktivitäten und die zu erbringenden Resultate sind im IT-Projektleitfaden des ASTRA verbindlich verankert. Abbildung 1 zeigt die Steuerung des Projektes und die Einbettung des IT- Architekturkonformitätsprüfungsprozesses in der Übersicht sowie dessen Zuordnung zu den einzelnen Phasen gemäss HERMES. Die folgenden Tabellen liefern eine Übersicht über die Meilensteine und Quality Gates, die der Leadarchitekten/ISBO minimal prüft. 6/11
INITIALISIERUNG Aufgabe (Verantwortung Aufgabe) Motivation 1 Projektinitialisierungsauftrag 1.2 Projektentscheid Relevanz Systemarchitektur (Leadarchitekt) Grobmodell in ADOit Architekturskizze, wenn vorhanden - Eruieren von Synergien und strategischen Themen - Begleitungstiefe festlegen und Aufwand abschätzen - Thema vorstellen im Architekturboard ASTRA 3 Variantenwahl 3.1 Projektentscheid Erstbeurteilung Architekturvarianten (Leadarchitekt) Grobmodell in ADOit Studie in Projekten [6] Phase Initialisierung - Sicherstellung der Einhaltung von Vorgaben und Strategien - Abhängigkeiten aufzeigen 4 Projektfreigabe 4.1 Schuban, IKT-Grundschutz prüfen 4.2 Architekturkonformität prüfen (Leadarchitekt) Schuban, IKT-Grundschutz in Projekten [6] Phase Initialisierung Projektauftrag Phasenfreigabe in Projekten [6] Phase Initialisierung - Sicherstellung der Qualität, sodass darauf basierend die Architektur entwickelt werden kann nach geltenden Vorgaben (insbesondere WISB) - Sicherstellung Fokussierung auf fachliche Themen, sodass keine unnötigen Architektureinschränkungen gemacht und nicht Ergebnisse der Konzeptphase vorweggenommen werden - Prüfen, ob Meilensteine und Quality Gates aus Sicht Architektur eingehalten wurden - Befunde, die nicht behoben wurden und nicht die Freigabe verhindern, müssen im Bericht festgehalten werden (Vorbehalte) 7/11
KONZEPT Aufgabe (Verantwortung Aufgabe) Hilfsmittel 6 ISDS-Konzept und Systemarchitektur 6.2 ISDS Konzept prüfen Detailmodell in ADOit ISDS-Konzept Kap. 1-6 Risikoanalyse in Projekten [6] Phase Konzept - Prüfen, dass die gewählte Architektur den Vorgaben (insbesondere BINV) entsprechen - Widerspruchsfreiheit zu Dokument Systemarchitektur - Relevante Kapitel gemäss Hermes 6.3 Systemarchitektur freigeben (Lead-Architekt) Detailmodell in ADOit Systemarchitektur in Projekten [6] Phase Konzept - Prüfen, dass die gewählte Architektur den Vorgaben [3] entsprechen - Widerspruchsfreiheit zu Dokument ISDS Konzept 7 Phasenfreigabe 7.1 Phasenbericht prüfen (Lead-Architekt) Ggf. Bericht Prüfung von Lieferobjekten in Projekten [6] Phase Konzept - Prüfen, ob Meilensteine und Quality Gates aus Sicht der IT-Architektur eingehalten wurden - Befunde, die nicht behoben wurden und nicht die Freigabe verhindern, müssen im Bericht festgehalten werden 8/11
REALISIERUNG Aufgabe (Verantwortung Aufgabe) Hilfsmittel 9 Phasenfreigabe 9.1 Vorabnahme Systemarchitektur (Lead Architekt) ISDS-Konzept prüfen Umsetzungs-, Technologiemodell in ADOit Systemarchitektur in Projekten [6] Phase Realisierung ISDS-Konzept (Kap. 5-8) in Projekten [6] Phase Realisierung - Befunde, die nicht behoben wurden und nicht die Freigabe verhindern, müssen im Bericht festgehalten werden - Relevante Kapitel gemäss Hermes EINFÜHRUNG Aufgabe (Verantwortung Aufgabe) Hilfsmittel 12 Abnahme 12.1 Endabnahme durchführen (Lead-Architekt, ISBO) Umsetzungs-, Technologiemodell in ADOit Systemarchitektur Schuban, IKT-Grundschutz ISDS-Konzept (Kap. 9-11) Prüfberichte (Excel-Vorlage) in Projekten [6] Phase Einführung - Prüfen, ob Befunde aus früheren Prüfungen behoben wurden - Befunde, die nicht behoben wurden und nicht die Freigabe verhindern, müssen im Abnahmebericht festgehalten werden 4.2. Anpassung von Anwendungen Für Anwendungen, welche sich im Wartungsmodus befinden, erfolgt die Architekturkonformitätsprüfung auf Basis der im EAM-Tool (aktuell: AdoIT) abgebildeten Modelle (Grob-, Detail-, Umsetzungs-, Technologiemodell). Bei Anpassungen einer Anwendung ist sicherzustellen, dass die zugrundeliegenden Dokumente sowie die Modelle im EAM-Tool nachgeführt werden und zwar so, dass die Architektur weiterhin den Vorgaben entspricht. Diese Anpassungen müssen mit dem Lead-Architekten im Vorab besprochen werden. Die folgenden Ergebnisse sind zu überprüfen: 9/11
WARTUNG VOR UMSETZUNG Aufgabe (Verantwortung Auf- Hilfsmittel gabe) Wartungsrelease planen W.01 Schuban, IKT-Grundschutz prüfen W.02 ISDS Konzept prüfen W.03 Systemarchitektur freigeben (Lead Architekt) bei Anpassungen von Anwendungen Detailmodell in ADOit Ggf. Umsetzungs-, Technologiemodell bei Anpassungen von Anwendungen Grobmodell Detailmodell Umsetzungs-, Technologiemodell Dokument Systemarchitektur bei Anpassungen von Anwendungen - Sicherstellung der Qualität, so dass darauf basierend die Architektur entwickelt werden kann nach geltenden Vorgaben (insbesondere BINV) - Prüfen, dass die gewählte Architektur den Vorgaben [3] entspricht - Widerspruchsfreiheit zu Dokument Systemarchitektur - Prüfen, dass die gewählte Architektur den Vorgaben (insbesondere BINV) entsprechen - Widerspruchsfreiheit zu Dokument ISDS Konzept Zu beachten, ist das vor der Beauftragung zur Spezifikation / Realisierung von Softwarekomponenten die benötigten Freigaben des Leadarchitekten/ISBO vorliegen muss (vgl. ). ABNAHME Aufgabe (Verantwortung Aufgabe) Hilfsmittel Wartungsrelease abnehmen W.04 Schuban, IKT Grundschutz prüfen Detailmodell in ADOit Ggf. Umsetzungsmodell in ADOit Prüfprotokoll Prüfung von Lieferobjek- - Prüfen, ob Befunde aus früheren Prüfungen behoben wurde - Befunde (Vorbehalte), die ten bei Anpassungen von Anwendungen nicht behoben wurden und nicht die Freigabe verhindern, müssen im Prüfprotokoll erscheinen W.05 ISDS-Konzept prüfen Detailmodell in ADOit Ggf. Umsetzungsmodell in ADOit - Prüfen, ob Befunde aus früheren Prüfungen behoben wurde 10/11
W.06 Systemarchitektur prüfen (Lead-Architekt) bei Anpassungen von Anwendungen Grobmodell, Detailmodell Umsetzungs-, Technologiemodell Dokument Systemarchitektur bei Anpassungen von Anwendungen - Befunde (Vorbehalte), die nicht behoben wurden und nicht die Freigabe verhindern, müssen im Prüfprotokoll erscheinen - Korrekte Umsetzung der Modelle gemäss Systemarchitektur - Befunde (Vorbehalte), die nicht behoben wurden und nicht die Freigabe verhindern, müssen im Prüfprotokoll erscheinen HINWEIS: Entsprechen diese Dokumente nicht mehr der Realität oder es ist absehbar, dass sie nicht mehr der Realität entsprechen werden, ist der Lead-Architekt / ISBO zwingend frühzeitig beizuziehen, auch wenn noch kein Release geplant ist. 11/11