www.opitz-consulting.com/go/3-1-913
Die Auslagerung von Services und Daten in den Clouds bringt immer einen Kontroll- und Sicherheitsverlust mit sich. Dabei können sich geschäftliche Risiken negativ auf das Image eines Unternehmens auswirken und die Beziehung zum Kunden nachhaltig beschädigen. Steigende Abhängigkeiten zu Drittanbietern sowie komplexe gesetzliche Bestimmungen verschärfen Compliance-Szenarien und machen eine ausgefeilte Governance wichtiger denn je!
Brauchen IT-Verantwortliche neue Methoden, oder können Sie diese Herausforderungen mit COBIT und TOGAF bewältigen?
Mit dieser Fragestellung befasste sich Kornelius Fuhrer, Senior Consultant bei OPITZ CONSULTING, in seinem Vortrag auf der OOP 2012 in München. Und diskutierte mögliche Optionen mit den teilnehmenden Softwarearchitekten und Entscheidern.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Ich veröffentliche regelmäßig in unterschiedlichen Magazinen Oder spreche auf verschiedenen Konferenzen zu den erwähnten Themenkomplexen
Wo gibt es Governance-Methoden im Leben die funktionieren? als Berater fliegt man viel das Thema ist Cloud Governance Wie funktioniert die Governance im Flugverkehr Landeanflug durch die Wolken bei 150m Sicht Nach 40 sec. in den Wolken/also ohne Transparenz Ist ein jeder erfahrene Pilot tot => ohne die Instrumente 300m – Im Hintergrund hört man die ganze Zeit den Tower an gibt => Guidance 200m – die Instrumente Schaffen Transparenz 100m Also wie ist der Luftverkehr geregelt? Welche Maßnahmen/Governance Mechanismen werden ergriffen, um Risiken auszuräumen und Sicherheit zu gewährleisten
Luftfahrtamt erlässt Vorschriften und Gesetze Es gibt Flugschulen mit Schulungsunterlagen/Bücher und Prüfungen Unten rechts: Die FFL - Fachschule für Luftfahrzeugführer Pilot braucht Technische Hilfsmitte zur Schaffung von Transparenz Standardisierte Prozesse/Routinen/Verfahren die helfen Fehler zu vermeiden >> Alles nur um sicher durch die Wolken zu kommen! >> Menschenleben nicht zu gefährden!
Was ist bei vielen Kunden zu beobachten : Es gibt so was wie das Luftfahrtamt , dass nennt sich IT-Steuerungskreis , Hier werden Vorgaben und Richtlinien erstellt. Aber gibt es auch eine Flughafensicherheit die die Einhaltung und Wirksamkeit zyklisch überprüft? Gibt es einen Architektur-TüV ? Zyklischer technischer Check/Vorbeugung der Erosion der Architektur Dürfen die Projektleiter ohne Flugführerschein die Programme/Projekte durch die Cloud fliegen? Gibt es eine Flugschule? Werden die Betroffenen durch den durch den Governance-Prozess gelotst ? |> Das sind die Fragen die wie im Folgenden klären wollen
Die prominentesten sind hier wohl: Sarbanes-Oxley Act für alle an US Börsen notierten Unternehmen Richtigkeit und Verlässlichkeit der veröffentlichten Finanzdaten Mindestanforderungen an das Risikomanagement (MaRisk) Gesetz zur Kontrolle und Transparenz im Unternehmensbereich ( KonTraG ) Bundesdatenschutzgesetz (BDSG) <RUHIG >> PAUSEN MACHEN>
Je nach Servicetyp findet ein zunehmender direkter Kontrollverlust statt Potenzielle geschäftliche Interessenkonflikte zwischen Cloud-Service Anbieter und Nutzer =>| Zeitnahe Durchführbarkeit von dringenden Änderungsmaßnahmen => Sicherheitsupdates Schwierige Einhaltung von gesetzliche Richtlinien über die geografischen und Unternehmensgrenzen hinweg =>| Service-Nutzer verstößt unbewusst gegen (geänderte) lokale Gesetze (wo Software/Daten physisch abgelegt) Die gemeinsame Nutzung von physikalischen Systemen in einer virtuellen Umgebung birgt Sicherheitrisiken! Gelöschte Daten können nach Freigabe des Speichers durch Dritte wiederhergestellt werden Aber das meisten haben Sie sowieso schon gehört! Fragen wie: Wer ändert wann was in welchen Systemteilen? Haben die Mitarbeiter des Dienstleisters Zugriff auf die Daten? Hat der Dienstleister weitere Dienstleister? =>| Können Sie diese Fragen ohne Bedenken noch sicher beantworten?
Als Resultat folgenden Imageschäden , Die nur mit kostenintensiven Marketing Initiativen abzumildern sind. KonTraG – Gesetz zur Kontrolle und Transparenz => Vorstände haften mit Ihrem Privatvermögen Der Skandal mit der Datenwolke war das Initialereignis für die Deutsche Telekom für eine erstgemeinte EA-Initiaitve! <RUHIG >> PAUSEN MACHEN>
Das The Open Group Architecture Framework (TOGAF) umfassenden Ansatz für Entwurf, Planung, Implementierung und Wartung von Enterprise Architekturen ADM => zyklische Ausführung => Architektur fortgeschrieben. Phase A ( Architekturvision ) Festlegung von Architekturziele + Stakeholder + Fragestellungen <klick> Phase B-D werden für die Geschäfts-, Anwendungs-, Informations-/Daten- und die Technologiearchitektur dokumentiert Erstellung der Ergebnisartefakte/Deliverables Phase E Roadmapping : Vorhaben festgelegt, die die Transformation aus der IST-Situation zum Zielzustand durchführen. Phase F Abstimmung => übergreifende Zusammenarbeit/Kommunikation diese Absprachen werden in Phase G überwacht . (EA-Governance) Phase H Veränderungsmanagement && Anforderungen und externe Einflüsse Grundlage für den nächsten Durchlauf der ADM >> TOGAF beinhaltet viele Konzepte, Prinzipien, Methoden, Richtlinien … Der Standard umfasst knapp 1000 Seiten >> Dauert immer Recht lange, den in den Unternehmen zu etablieren/zum leben zu bekommen
Etwas Pragmatischer: EA Zyklus von Niemann Nicht so stark formalisiert , sehr flexibel und schnell einsetzbar . Schnittpunkte zur IT-Governance Initial/Einmalig : Dokumentation der Ist-Situation begonnen (Document). DOCUMENT : Modell der Architektur erstellt, umgesetzt und befüllt. Analyze : Analyse der gesammelten Daten: Identifikation von Handlungsbedarfs PLAN: Planung des weiteren Vorgehens >> Ableitung und Auswertung von Szenarien => GAPs => Roadmap ACT: Umsetzung der geplanten Änderungen () gemäß Referenzarchitektur >> Dokumentation der Änderungen: Der Zyklus wird nun wieder von vorne durchlaufen. CHECK : Qualitätssicherung bei jedem Schritt (Check). Fortlaufende Definition und Überwachung der KPIs Sind die Maßnahmen noch zu den Architekturzielen konform?
Strukturierung der Architekturartefakte in Dimensionen Nur die wichtigsten für Cloud Governance Strategiearchitektur = Unternehmensstrategie , alle Geschäfts- und IT-Strategien und - ziele, Geschäfts- und IT-Vorhaben/Initiativen Zielorientierte Gestaltung: Architekturziele und Vorgaben sind für alle darunter liegenden Dimensionen relevant Ausrichtung zwischen Geschäfts- und der IT-Strategie sowie Geschäftsarchitektur und der IT-Architektur |> Mangelhafte Ausrichtung führt zu nicht abgestimmten Aktivitäten und resultiert in nicht umsetzbaren Strategien Geschäftsarchitektur = kohärente fachliche Sicht => gesamte Unternehmen Geschäftsorientierte Gestaltung , Weiterentwicklung des Geschäftsmodells . Geschäftsobjekte , Geschäftsdomänen , Geschäftsfähigkeiten/Capabilities , Funktionen, Produkte , Wechselbeziehung |> SaaS Kontext: Transparenz => passgenaue Dimensionierung der SLAs =>Dimensionen darunter nicht mehr im Kontrollbereich Kernbestandteil der Enterprise Architektur ist die Bebauung der Servicearchitektur mit den Services, Wechselbeziehung Technische Architektur => Technologien, Technsiche Bausteine, Standards, Plattformen, Referenzarchitekturen etc. |>Im PaaS Kontext vollständig abstrahiert |>Im IaaS Kontext nur Hardware abstrahiert. Middleware, Technolgien Coporate, IT, Cloud und SOA Governance: Mechanismen, Prinzipien, Richtlinien, Policies, Governance Roadmaps
Im Metamodell ist das Herzstück einer Enterprise Architektur. Zu sehen sind die Architekturartefakte mit Wechselbeziehungen & Wechselwirkungen => transparent , analysierbar und planbar . >Im SaaS Kontext sind alle blauen und grauen Architekturartefakte abstrahiert -> beim SaaS-Anbieter! <freestyle auf der Folie> Aus welchen Technischen Bausteinen besteht die Standardplattform? Ist diese Cloud-Kontext einsatzfähig? Welche Informationsobjekte fließen über welche Informationsflüsse? Handelt es sich um sensible Daten? Wie ist der Informationsfluss gesichert? Das Metamodell ist die Basis für Blickwinkel Die Blickwinkel beantworten die Fragestellungen der Stakeholder über eine Visualisierung
Es gibt unzählige Blickwinkel auf die Architektur, aber welche sind nun für die Governance relevant? Das hängt natürlich immer von den Fragestellungen der Stakholder ab! Vorstellung einer Auswahl Blickwinkeln => Best Practice => Zur Unterstützung der Governance <RUHIG >> PAUSEN MACHEN>
Der Klassiker Auszug aus einer Anwendungslandschaft => Informationsflusskarte Anwendungen und Bausteine sind über Informationsflüsse miteinander verknüpft. Informationsflüsse und Anwendungen sind hier klickbar , Traversierung/Drilldown ist zur Tiefenanalyse möglich. Informationsfluss => aufgefächert => einzelnen Informationsobjekte => übergeordnete Geschäftsobjekte sichtbar Fachlich und technische Analyse auf Compliance-Level, Standardkonformität , etc Anzeige von Kennzahlen : Oben rechts im Symbol: Standard- oder Strategiekonformitätsindex Pfeil ist der Gesundheitszustand des Architekturartefaktes Lebenszyklusphase (Active, Retired, Plan) angezeigt.
Die CRUD-Matrix ( CRUD = Create, Read, Update, Delete ) Welcher Service greift auf die Geschäftsobjekte wie zu? Inhärentes Abhängigkeitsverhältnis : Zwischen fachlichen und IT-Strukturen / Zwischen Geschäftsarchitektur und IT-Architektur Welche Services verarbeiten wie, welche sensiblen Daten? Wo werden diese zwischengespeichert? Sind sie verschlüsselt?
Zusehen: technischen Bausteine pro Architekturdomänen und deren Compliance-Level <Erklärung der Farben> Welche Architekturartefakte entsprechen Sicherheits- und Compliance- Anforderungen? Wie weit wurden welche SLAs umgesetzt? Wichtig wenn ich Standardplattformen für die Clouds zusammenstellen möchte!
Hier: Umsetzungsplan als strategische Roadmap : Roadmap zur Governance der Cloud Sourcing Strategie |> Fullfillment Geschäftsprozess soll vollständig in die Clouds PLAN und IST Zustand mit Meilensteinen Abbildung aller Services dieses Ziel verfolgen und in die Clouds transformiert werden müssen Auswirkungen der Programme/Projekte auf die IT-Architektur effektiv abbilden. Kurzum: Der Masterplan ist ein wichtiges Instrument für alle Governance Domänen
CIO => ganzheitliche und gleichzeitig kompakte Visualisierung => strategischen und operativen Kennzahlen Oben-Links: Governance Domäne => Risikomanagement Portfolio-Grafik => Quantitative Einschätzung der maximalen Verluste Oben-Rechts: Zustand der Governance-Kontrollpunkte/controls als Kreisdiagramm Unten-Links: Compliance Abdeckung im Gesamtunternehmen Unten-rechts: Issue Managment |> kennzahlengestützten Bewertung der Governance-Ziele Komplexe Zusammenhänge werden dadurch erkennbar Strategische und Operative Entscheidungen schnell und konsistent treffbar Trends ableitbar. Nachhaltige Steuerung
Immer grösser werdende Risiken (Sicherheit, Compliance, Projekte und Partner) durch Cloudsourcing „ Klare Definition von Strategien und Ziele“ Ist Cloudsourcing Strategie konform zur gesamt IT-Strategie ? Werden die Ziele der Geschäftsstrategie unterstützt? Welche Compliance Anforderungen haben welche Cloud-Services ? Welche SLAs müssen mit dem Cloud-Anbieter vereinbart werden? Risikomanagement wird nicht im Dunkeln betrieben, sondern im Lichte einer transparenten Informationsbasis Die Enterprise Architektur produziert dieses Licht <klick>
Welche Entscheidungen müssen getroffen werden? Wer trifft diese Entscheidungen ? Wie werden diese Entscheidungen getroffen? Wie werden die Ergebnisse überwacht? und ganz wichtig: Auf welcher Informationsbasis werden die Entscheidungen getroffen. =>> Beitrag von EA geleistet
Corporate Governance =>Unternehmenssteuerung/Unternehmenskontrolle => langfristige Wertschöpfung Aufsichts- bzw. Verwaltungsrat => Risikomanagement/Risikocontrolling Corporate Governance => Compliance Fragen, Einhaltung von Gesetzen + geforderten Regulierungen IT-Governance = Pendant zum IT-Management und abhängig von IT-Strategie und Corporate Governance IT-Führung, IT- Organisation und IT-Prozesse werden Unternehmensstrategie/-ziele ausgerichtet IT-Governance hat die Aufgabe diese Abstimmungsprozesse zu organisieren und zu kontrollieren Ressourcen / Risiko Management zentrale Rolle für Integration/Ausrichtung der ITG mit der Cloud Governance =>> bestimmt letztendlich die Effektivität der Cloud Governance SOA-Governance => Service-Business Alignment + Service-Denken Fachbereich und IT etablieren SOA-Service => Cloud ausgelagert => SOA Governance => cloud-spezifisch erweitert Cloud Governance (Service-Modell, Bereitstellungsmodelle) ist wesentlich umfassender als SOA Governance Alle Governance Modelle definieren: Prinzipien , Prozesse , Rollen und Verantwortlichkeiten >> Und damit die Regulierung und Kontrolle Ihrer Domänen
Rechts die verschiedenen Sichten der Governance Pyramide Auf der Ebene der Unternehmensführung die Sicht der Corporate und IT Governance (COBIT) Reifegrade / Maturity Models TOGAF für die Enterprise Architektur Sicht Infrastruktur Sichten (ITIL) Unternehmensspezifische Governance Prozesse und Verfahren <klick> Cloud Governance mit COBIT als prominentestes Beispiel <RUHIG >> PAUSEN MACHEN>
COBIT = Control Objectives for Information & Related Technology Zielgruppe: Strategisches Management, Vorstand, Aufsichtsgremien, Business-& IT-Management • Weltweit anerkanntes Werkzeug zur Sicherstellung, dass die IT effektiv arbeitet • Stellt eine gemeinsame Sprache zur Kommunikation von Zweck, Zielen und erwarteten Resultate zur Verfügung Governance-Domänen 1. Strategische Ausrichtung: Abgleich Geschäfts- und IT-Strategie => kontinuierliche Verbesserung des Wertbeitrages der IT 2. Wertbeitrag : Schaffung von geschäftlichen Werten/Nutzen von Services und Projekten => gesamten Lebenszyklus => Kosteneffizienz 3. Risikomanagement Identifizierung/Analyse/Begrenzung/Eliminierung von Risiken 4. Ressourcenmanagement : Optimierung von Investition => Effizienter Ressourceneinsatz 5. Ergebnismessung : Überwachung und leistungsseitige Steuerung der Strategieimplementierung Generische Geschäftsanforderungen => Qualitätskritieren => müssen von IT-Prozesse erfüllt => dann Kontrollziel erreicht 34 IT-Prozesse PO: 10 Planungsprozesse => technischen, strukturellen und strategischen Rahmen => Beitrag der IT für den Geschäftserfolg AI: 7 Prozesse zur Identifikation/Beschaffung/Entwicklung/Integration von Leistungen und Ressourcen
DS: 13 Prozesse Steuerung des Systembetriebes : Performance/Sicherheit/Skalierbarkeit/Business Continuity ME: 4 Prozesse zum Performance Management/Interne Kontrolle/regulatorische Anforderungen KPI: Zielerreichungsindikatoren/Managementinfomrationen : Hat IT-Prozess die Geschäftsanforderungen erfüllt? KGI: Outcome Measures: Leistungsindikatoren: Prozessziel erreicht? Control erreicht Essentieller Bestandteil von COBIT: Controls: Kontroll- und Steuerungselemente für Prozesse und Anwendungen <In der Grafik anzeigen> Application-Controls sind wesentlicher Bestandteil eines internen Kontrollsystems |> Und hier muss beim Cloudsourcing angesetzt werden |> Welche Controls brauchen wir beim Cloudsourcing
98 Sicherheitskontrolle Integration cloud-relevanter Kontroll- und Steuerungselemente in eigene Cloud Governance Prozesse >> COBIT IT Prozessziele
RACI Charts aus COBIT zur Vollständigkeit: Wer ist Verantwortlich? Wer ist haftbar? Wer muss beraten werden? Wer muss nur informiert werden
Operative Umsetzung in den Clouds? Ist abhängig vom Servicetyp!
|> Cloud Governance a la COBIT kann hier mit den vorgestellten Mechanismen funktionieren |> COBIT sehr umfangreich und formalisiert
Cloud Governance aus der Sicht eines Cloud Anbieters!
IaaS: Die Infrastruktur kann entsprechend den Anforderungen des Services angepasst werden Klient muss sich um explizite Sicherheitsmaßnahmen muss auf Anwendungsebene selbst kümmern Verschlüsselung sämtlicher Kommunikationswege Verschlüsselte Speicherung von sensiblen Daten Secret keys <> „Standard“ software application keys PaaS Installation der Services in eine virtualisierte und standardisierte Betriebsumgebung beispielsweise mit vorkonfigurierter Middleware Hosting Services Security Services: Identity and Access Management (IAM) Firewalls , VPN , Anti-Malware / Intrusion Detection and Prevention. Managed Document Services: Dokumentenmanagement für Unternehmen
Hohe, mandantenfähige Sicherheitsstandards für sensible Daten Application Operations (Standard und SAP) Hosting, Betrieb und Wartung von mandantenfähigen Anwendungen und Services (SAP Umfeld) Cloud-Angebot von ganzen Servicelandschaften Kunden nutzen die standardisierten und industrialisierten Services nach Bedarf und bleiben technologisch auf dem neuesten Stand .
SOA-Regelungen für die Cloud: Cloud Governance Buttom-Up! (COBIT ist TOP DOWN) Erweiterung der bestehende Governance-Strategie statt das Rad für die Cloud neu zu erfinden. |> logische Weiterentwicklung der SOA Governance. PLAN: Governance-Methodik und Stakeholderanalyse , Workshops, Interviews Identifizierung von GAPs und Verbesserungsmöglichkeiten Governance Maturity Assessement: Validierung der aktuellen SOA/Cloud Prinzipien/Strategie / Ziele . Governance Scoping: inkl. der betroffenen Prozesse und Rollen DEFINE: Definition der Mechanismen/Instrumente (Prozesse, Ziele, … Roadmaps), um die Ziele der Planphase zu erreichen Erstellung einer Roadmap mit Messpunkten Welche Prozesse/Policies/Trigger werden wo benötigt? Welche Prozesse müssen überwacht/kontrolliert werden ( Governed Processes ) Sind neue Rollen und Verantwortlichkeiten erforderlich? RACI charts! => Erstellung von Roadmaps => Technolgisch, organisatorisch und prozessual!
IMPLEMENT: Rollout/Implementierung der planten Governance Lösung mit den definierten Mechanismen Veränderungsmanagement : Kommunikationskonzept : Informationsveranstaltungen, Information und Abholung aller Beteiligen Coaching und Schulung der beteiligten Personen MONITOR: Überwachung und Messung der Effektivität Auswertung der Kennzahlen Wie oft werden Trigger ausgelöst und aus welchem Grund? Müssen Policies, Proezsse oder die Trigger selbst angepasst Vitality Process nächste Folie
Wird ein Trigger ausgelöst => Vitality Process <klick> Identify : Identifizierung der Umstände Warum wurde der Trigger ausgelöst? Berechtigt oder unberechtigt? Müssen Governance Mechanismen angepasst werden? >> Als Beispiel könnte man nehmen: SLA kann für einen Service kann nicht aufrechtgehalten werden. Infrastruktur ist azyklisch unter Last Assess : Evaluierung der Erforderlichen Änderungen Muss der Service in die Clouds? Abstimmung zwischen Service Architekten und Cloud Governance Spezialisten Refresh : Auslagerung des Services die Clouds Approve: Genehmigung durch Governance Autorität Communicate: Kommunikation und Information der Beteiligten |> Welche Gremien und Rollen wurden implementiert
@TODO: Reihenfolge Fokussierung auf Cloud-Rollen IT Architect: Hat den Gesamtüberblick über alle IT Betriebs- und Servicemodelle, Technologien, Standards , EA: Technische Architektur und Anwendungsarchitektur und Informationsarchitektur. Entwirft und Plant Standards und Richtlinien , um beispielsweise die IT-Strategie besser zu unterstützen. Policy Custodian: Erstellt, erweitert und wartet Policy‘s und stellt sicher, dass Policy‘s und Serviceverträge den entsprechenden Services zugeordnet sind. Service Analyst : S-O Analyse und Service Modelling : Identifikation von Service Kandidaten, Capability Kandidaten, Service Kompositionskandidaten , Koordiniert und führt die Service Architekten und Business Analysten Cloud Governance Specialist: Betriebsmodelle (public, private, community) haben Ihre eigenen Charakteristiken . Plattformen => herstellerspezifisch . Unterschiedliche Regeln, Ziele, Prozesse mapping auf Governance Mechanismen Cloud Security Specialist: Spezialist für spezifische Bedrohungen in den Clouds unabhängig von der Softwarearchitektur Fokus ist weiter als beim SOA Security Spezialist Cloud Architect: spezialisiert auf Cloud-Technologien, Entwurftskonzepte und –muster, Cloud-Mechanismen Rolle SOA Architekt + Rolle des Cloud Architekten = eine Person Er konzipiert Architekturen dessen Teile in den clouds und andere nicht in den clouds liegen. Er stellt zur Entwurfszeit sicher das Standards und Compliance berücksichtigt werden
Cloud Service Owner: Person oder Organisation , die für den Service von Gesetzgeber her verantwortlich und haftbar ist. Im Kontext von public Clouds und sensibler Daten relevant. Cloud Ressource Administrator : Ist verantwortlich für die Administration , Deployment und Wartung von Services => Cloud IT Ressourcen Rolle kann ein Person oder Organisation sein die Cloudservices anbietet oder benutzt sein =>| Cloud Service Hersteller , Service Owner und Ressource Administrator unterschiedliche Organisationen sein Cloud Technology Professional: devleop, build & deploy cloud-basierte services und it ressourcen . (Cloud Entwickler = Person: Service Developer und Administrator) QA Spezialist: operationalisiert/verifiziert entsprechende Tests Harmonisiert mit dem Service Analyst und Policy Custodian . Educator: Zentrale Rollen entlang des gesamten Governance Prozesses. => Mentor coacht/schult/senibilisiert/informiert über allen Governance Prinzipien, Mechanismen und die eingesetzten Technologien
Cloud Governance Program Office • Ist die zentrale Autorität , die die Cloud Governance Modell konzipiert und justiert . • Sicherstellung der Standard- und Regelkonformität • Ausrichtung => IT Governance, EA Governance oder SOA Governance • Führt Revisionen durch und behandelt Ausnahmen • Veränderungsmanagement : Erstellung einen Informations- und Kommunikationsplan CIO Office • Entscheider der letzten Instanz • Postulierung/Freigabe der strategischen Vergehens in den Clouds • Freigabe der Governance Mechanismen => CIO, CTO, IT-Planer oder IT-Strategen, Business Domain Owners EA Governance Council • Definition/Konzeption von Cloud - portfolios => Chief Enterprise Architect, Chief Cloud Architect
Sponsor- & Leadership • Definiert die zukünftige strategische Stoßrichtung und Roadmaps für Cloud Vorhaben • Sicherstellung => Beitrag zur Geschäfts-/Unternehmensstrategie leisten • Bereitstellung von Mitteln und Ressourcen Scope & Delivery Mgmt. • Verantwortllich für Lösungen aus einen Business Blickwinkel • Ermittlung und Sicherstellung des Wertbeitrages • Kommunikation der Anforderungen Definition & Development • Konzeption von Cloud Goverance Prozessen/Methoden und best practices • Definition der Kontrollelemente/Controls • Definition and Überwachung von KPI/KGI • Initiierung und Begleitung von organisatorischen Veränderungen • Roadmap zur Cloud Transformation
=> Cloud Competence Center sichert Projektwissen nachhaltig verantwortet die Cloud Governance bildet die Schnittstelle zwischen technischer IT und den Fachbereichen bindet Ressourcen flexibel und skalierbar ein, vom virtuellen Team bis zur eigenen Orga-Einheit initiiert und betreut Folgeprojekte Execution and Delivery • Steuerung der Lösungen einer bestimmten Domäne • Design, Entwicklung, Test, deployment, Betrieb der Services • Wartung der Schnittstellen • Befolgung von Richtlinien und Standards • Verständnis und bewusste Einhaltung der Gov-Mechnismen
WOFÜR braucht der Kunde dieses Governance Framework? IaaS, PaaS und SaaS für interne Nutzung und als mandantenfähigen Services nach extern. Servicetypen brauchen Ihre eigenen Modelle => starke regulatorische Unterschiede PLAN, DEFINE, IMPLEMENT und MONITOR für die Cloud Governance Unten: Weiterentwicklung von IaaS => PaaS => SaaS Integration in IT-Governance mit COBIT und CSA
XaaS Governance Prozesse PO1: Definition eines strategischen IT-Plan ( Ausrichung und Steuerung der IT-Ressourcen, Optimierung des Wertbeitrags ) PO4: Definition der IT-Prozesse, Organisation und Beziehungen Neue Anforderungen: Personal, Qualifikationen, Funktionen, Verantwortung, Entscheidungsbefugnis, Rollen, Zuständigkeiten und Überwachung. => CSA Information Security: Verständnis/Bewusstsein für Einhaltung der Policies/Standards/Prozesse PO10: Beurteile und Manage IT-Risiken => CSA Risk Management Program: Einführung eines Risiko Managements Programms => Identifikation/Begrenzung/Eliminierung des Risiko in den Clouds => CSA Risk Management Assessment: Änderungen von Business/Sicherheits-Policies/Prozeduren/Standards/Kontrollelemente müssen relevant und wirksam bleiben =>| CSA Controls sind nicht vollständig nur Beispiele!!!
IaaS Governance Prozesse PO2: Definition die Informationsarchitektur => CSA-Control : Data Governance: Unternehmensweiten Data Dictionary, Syntaxregeln, Datenklassifikationsschemas und Sicherheitsstufen gemäß der Compliance, Zu schützende Daten bekommen einen DATA Owner/Steward mit definierten Verantwortlichkeiten DS2: Steuerung der Leistungen und Angebote von Drittanbietern => CSA: Compliance – Audits, Reviews der Verträge, Reports, Messdaten und Services => CSA: Risk Management: Third Party Access: Identifikation/Evaluierung von Geschäftsprozessen die den Zugang von Dritten erfordern ME3: Sicherstellung der Compliance und Vorgaben => CSA Compliance – Independent Audits : Unabhängige Audits
PaaS Governance Prozesse PO8: Qualitätsmanagement (Standards, Richtlinien, Verfahren, Blueprints) => CSA-Control: Release Management – Qualitätstests : Kontinuierliche Überwachung, Analyse und Verbesserung >> Den Rest wiederholt sich von der letzten Folie
SaaS Governance Prozesse DS2: Steuerung der Leistungen und Angebote von Drittanbietern (Wirksamkeit, Compliance) => CSA: Compliance – Transparente Audits, Reviews der Verträge, Reports, Messdaten und Services => CSA: Risk Management : Third Party Access: Identifikation/Evaluierung von Geschäftsprozessen die den Zugang von Dritten erfordern DS5: Sicherstellung der Security der Cloud Services (Security Management) => CSA: Information Security - Policy Reviews zur Sicherung der Wirksamkeit
Kommt aus dem Qualitätsmanagement => ist aber die Basis für fast jeden Zyklus |>Transformation in allen vorgestellten Zyklen ist möglich Die Basis von TOGAF und der ADM: Architekturvision = PLAN Modellierung der IST und SOLL Architektur= DO, Überprüfung der Roadmap & EA Governance= CHECK Implementierung = ACT Die Basis von EA-Zyklus Niemann |>> Document >> Analyse >> Plan >> Act >> check Die Basis von COBIT! |>> Plan & Organise, Aquire & Implement, Deliver & Support, Monitor & Evaluate! Die Basis von Open Group SOA Governance |>> PLAN, DEFINE, IMPLEMENT, MONITOR Eigentlich hat sich doch nichts geändert! Warum: Weil das Basisprinzip der gesunde Menschenverstand ist Bevor ich was mache plane ich es, Dann führe ich es im Kleinen aus und prüfe es / ziehe meine Rückschlüsse / Erkenntnisgewinn Setze es dann im Großen um!
Skalierung des Deming-Zyklus für mehrere Governance Domänen (horizontal) Für diese gibt es jeweils auch einen Implementierungszyklen Governance Zyklus ist praktisch der Deming-Zyklus auf sich selbst angewendet , Um die applizierten Governance Mechanismen pro Governance Domäne evolutionär zu verbessern Animation! Welche Richtlinien/Methoden/Policies pro Governance Domäne brauche definiere ich kundenspezifisch! Meines Erachtens der agilste und verständlichste Ansatz Der ist eigentlich sehr starr/standardisiert/formalsiert => Und nur alter Wein in neuen/aufgeblähten Schleuchen!!!