• Coach & Blogger zum Thema Cloud & Compliance sowie sonstige Strukturveränderungen

• Coaching von CxO und erster Führungsebene rund um die Themen Geschäftsmodellentwicklung / Digitalisierung / Cloud Computing / GRC & ITSM

• Vorträge, Podiumsdiskussionen, Kamingespräche, Moderation von Veranstaltungen rund um das Thema 

Es schadet sicherlich nicht das im Juni 2023 veröffentlichte BSI Positionspapier Zero Trust 2023 zu lesen. Ein gut gemeinter Ansatz, der aber leider so nicht wirklich in der Praxis umsetzbar ist.

Warum wird eigentlich immer vorgeschlagen Änderungen am „lebenden Objekt“ der vorhandenen Infrastruktur und Anwendungslandschaft peu-a-peu im laufenden Betrieb durchzuführen? Warum das CISA Zero Trust Maturity Model 2.0 vom April 2023 - das Basisdokument des BSI Positionspapiers - diesen Ansatz immer noch verfolgt, bleibt mir ein Rätsel.

Wenn ich 1957 ein zweistöckiges Einfamilienhaus 🏚 gebaut habe, dann sollte ich es abreißen 💣, wenn ich 2023 ein 10-stöckiges Mehrfamilienhaus 🏢 brauche. Das gilt auch für historisch, hysterisch („Huch, ich habe vergessen einen Flag zu setzen!“) gebaute Infrastrukturen und Anwendungslandschaften, die wir gerade in Deutschland leider noch viel zu häufig antreffen. Es ist schon eine gruselige Vorstellung sich die „heterogenen IT-Welten“ als ein über die Jahre entwickeltes Wohnhaus vorzustellen. Da will man nicht wirklich gerne wohnen.

Warum tun wir es dann, wenn es um den „digitalen Zwilling“ geht?

Der Zero Trust Ansatz ist gut. Das gilt aber insbesondere auch für das IT-Personal.

Developer Convenience führt meist zu instabileren Run-time Umgebungen, was man nicht zuletzt an der Menge von SRE Stellenausschreibungen (Site Reliability Engineering) sehen kann.

Wie wäre es da mal mit einem NoOps Ansatz. Hätte doch auch mal was, wenn man einen industriell gefertigten Infrastrukturkontext inkl. Anwendung produziert und die IT-ler aussperrt.

Ja, aussperrt aus der Produktion! Nur ansehen, nicht anfassen!

Patches werden nur über die vorgefertigten Deployment-Endpoints (von non-IT-lern) eingespielt. Wenn man keinen Admin in der Produktion benötigt, dann ist eine Zero Trust Umgebung inkl. Anwendung leicht umsetzbar.

Fazit:

·         Ja, der Zero Trust Ansatz ist der Richtige! 👍

·         Aber bitte mehr Mut zum Abriss 💣 und Neubau 🛠, insbesondere dann, wenn man eh auf dem Weg in die Cloud ☁ ist.

·         NoOps ist machbar! Glauben Sie nicht? Kontakten Sie mich: ich kann Ihnen zeigen wie es geht 😉

In diesem Blog Post will ich näher darauf eingehen, warum die #BaFin „not amused“ zu sein scheint bzgl. des Zustands der deutschen Versicherungs-IT. 😲😉

Die #BaFin hat vor Jahren schon darauf sinngemäß hingewiesen: 📢Aufsicht umfasst insbesondere auch IT-Aufsicht!

Seit dem 03.03.2022 liegt nun ein Update vor: #VAIT 2.0 💪 (Versicherungsaufsichtliche Anforderungen an die IT), das zum einen neue EU Vorgaben und zum anderen die bis dahin gemachten Prüferfahrungen der IT-Aufsicht bei Versicherern berücksichtigt bzw. widerspiegelt.

Beipackzettel📰: Bitte betrachten Sie bei die, von mir gemachten Aussagen, nicht als allgemeines Bashing. Ich war auch mal „Täter“. Es gibt durchaus nachvollziehbare Gründe, warum der Zustand der Versicherungs-IT heute noch so ist wie er ist und warum die heute Verantwortlichen die IT-Missmanagement Entscheidungen der letzten 30 Jahre nicht einfach mal kurz abstellen können.

Viel Spaß beim Lesen.

VAIT Vorgeschichte und Historisches

Über Solvency II wurde jahrelang erbittert auf EU-Ebene diskutiert und verhandelt bis Solvency II in 2016 dann endlich angewandt wurde. Im Vorfeld wurde dazu das Versicherungsaufsichtsgesetz (VAG) entsprechend angepasst.

2018 wurde die Versicherungsaufsichtliche Anforderungen an die IT (VAIT) erstmals in Form eines BaFin Rundschreibens veröffentlicht. Für Branchenfremde sei erwähnt, dass Rundschreiben der BaFin nie über den Umfang von Gesetzten und Verordnungen hinausgehen dürfen. Die VAIT ist ein Rundschreiben, das VAG Vorgaben konkretisiert.

Damals gab es einen Aufschrei in der Branche, dass dieses Rundschreiben doch weit über den gesetzten Rahmen des VAG (Versicherungsaufsichtsgesetz) hinausgehe und das die Angemessenheit und Proportionalität nicht gegeben wären.

Aus der Stellungnahme des GDV vom 15.03.2018:

·         „Allerdings werden mit den VAIT weitreichende und teilweise überschießende Anforderungen formuliert, für die sich keine Grundlage in den verbindlichen gesetzlichen Vorgaben finden.“

·          „Konsequente Anwendung des Proportionalitätsprinzips mit dem Ziel, den Verwaltungsaufwand für die Unternehmen mit nachweislich einfachem Risikoprofil gering zu halten. Die VAIT müssen flexibel umsetzbar sein und auch ausdrücklich die Nichtanwendung von einzelnen Anforderungen vorsehen.“

Nun muss man wissen, dass Angemessenheit und Proportionalität die Solvency II „Supervokabeln“ sind. Durchaus nachvollziehbar, da es sich hier insbesondere um Prinzipien des Risiko-Managements handelt. Die Kosten für das Risiko-Management sollen sich dabei natürlich in einem wirtschaftlich vertretbaren Rahmen bewegen.

Dennoch hielt und halte ich die o.g. GDV Forderungen für nicht angemessen, vulgo einfach falsch! Für den IT-ler passt das überhaupt nicht, liebe Juristen.

Es ist egal, ob ein kleiner oder großer Versicherer eine Webseite oder App betreibt: die IT-Risiken im Internet sind für alle gleich. Kommt es zu einem DS-GVO oder noch schlimmer, einem §203 StGB relevanten Datenabfluss, dann ist die Anzahl der betroffenen Versicherungskunden kein Kriterium für die Strafbemessung (DS-GVO: bis max. 4% vom weltweiten Umsatz, bei §203 StGB  -Verletzung von Privatgeheimnissen bis zu 2 Jahre Haft oder Geldstrafe).

Ergebnisse der VAIT in der Anwendung

Genug der Vorgeschichte, lassen Sie uns einen Blick auf die Anwendung der VAIT in der Praxis werfen. Am 15.10.2020 veröffentlichte die BaFin auf ihrer Webseite einen Artikel mit der schönen Überschrift:

Erste Prüfungen der BaFin zeigen: Bei der Umsetzung der VAIT ist noch Luft nach oben

Uhhps! Wie gesagt, das war in 2020. Mittlerweile sind wieder zwei Jahre ins Land gegangen und ein Update der VAIT 2.0 wurde am 03.03.2022 veröffentlicht. Neben den neuen EU-Vorgaben (EIOPA-BoS-20-600 vom 12.10.2020 Leitlinien zur „Sicherheit und Governance von Informations- und Kommunikationstechnologie (IKT)“) sind da natürlich auch Erfahrungen der BaFin IT-Prüfer eingeflossen. Diese Erfahrungen müssen ziemlich „gruselig“ gewesen sein. Kann man das an der neuen VAIT 2.0 erkennen? Ja, man sieht es…

Eine Wort-Analyse der VAIT 2.0 lohnt sich

Ich hatte viel Spaß beim Durcharbeiten der VAIT 2.0. An vielen Stellen entstanden bei mir Bilder im Kopf, die zu herzhaften Lachattacken 🤣führten. Ich entschuldige mich schon mal prophylaktisch bei allen meinen Ex-Kollegen auf der IT-Anbieter- und IT-Anwender-Seite.🙏

In diesem Post möchte ich zunächst auf das Wording der VAIT 2.0 eingehen. Später, in einem zweiten Post, dann auf Inhaltliches i.S.v.: Was hat sich verändert? Was wurde präziserer formuliert ? Was wurde verschärft?

Nun, die wohlfeilen Worte, die sich im Solvency II Sprech immer wieder finden lassen, sind die Folgenden:

Allein diese Aufstellung verrät schon sehr viel:

·         Die „ge- und beliebte“ Proportionalität kommt nicht sehr häufig vor. Ist ja auch schwierig bei IT. Auf diese wird dann auch fast nur bei den Vorbemerkungen (4), also der Einordung des Gesamtwerkes eingegangen.

·       „Angemessen“, man könnte auch „verhältnismäßig“ sagen, gehört mit Abstand zu den beliebtesten Wörtern. Eine Steigerung des Begriffes um sage und schreibe +60% verdeutlich aber, dass es da wohl deutliche Unterschiede in der Bewertung was angemessen ist und was nicht zwischen der Aufsicht und den IT-lern der Versicherern gibt.

Was mich ehrlich gesagt nicht wirklich verwundert. Gibt es doch nach wie eine Reihe von IT-Admins, denen es egal ist unter welchen Vorständen sie arbeiten. Frei nach dem Motto, die haben eh keine Ahnung und lassen mich in Ruhe. Hauptsache es läuft. Tja, das reicht aber leider - besser Gott sei Dank - nicht mehr aus, liebe Admins.

·         Laufend + 50%, regelmäßig + 130% und zeitnah + 200%. WOW, das ist doch mal ne Klatsche! Da wird mehr als deutlich, dass es in den IT-Abteilungen der Versicherer einen sehr ernsthaften Bedarf gibt endlich mal aufzuräumen. Vielleicht wird sogar der eine oder andere Versicherer alles abreißen und neu bauen müssen, weil eine Aufräumaktion wirtschaftlich gar nicht mehr darstellbar ist.

Man könnte auch böswillig sagen: unorganisiert, nachlässig und jetzt wahrscheinlich auch noch agil kümmert sich „die IT“ um Dinge, die das Business nicht braucht. Ich habe in meiner beruflichen Karriere sowohl auf der IT-Sell als auch auf der IT-Buy Side vieles gesehen. Das Schlimmste von allem: Das Beharrungsvermögen von Menschen und damit verbunden die Verweigerung die Veränderungen der Realität wahrnehmen zu können oder zu wollen.

Der fehlende Veränderungswille ist nicht nur bei der IT anzutreffen, sondern auch beim Business. Die Veränderungen, die durch agile Vorgehensweisen, Cloud-Einsatz, etc. herbeigeführt werden, führen eben dazu, dass die bisher relativ starren Grenzen zw. IT und den Fachabteilungen zunehmend verschwimmen und am Ende des Tages ganz verschwinden werden. Glauben Sie nicht? Ich kenne schon Unternehmen (Hotel-Konzern) , da gibt es keinen Head of IT mehr. Dort ist IT integraler Bestandteil aller Fachabteilungen und der Vorstand koordiniert die Geschäftsprozesse. Das wird auch früher oder später in der Versicherungswirtschaft Einzug halten.

·         Anlassbezogen + 80% und insbesondere + 32% sind zwei Begriffe, die doch sehr deutlich machen, dass die Aufsicht noch mal ausdrücklich auf Zusammenhänge hinweist, die sorgfältig zu beachten und umzusetzen sind, insbesondere, wenn es um Risikoeinschätzung und -bewertung und deren Dokumentation - ACHTUNG! - aus Business Sicht. Zuerst Compliance, dann die Technik!

Bottom Line

·         Die BaFin-Kollegen waren mit Sicherheit not amused, als sie die IT-aufsichtlichen Prüfungen durchgeführt haben. Das Chaos, das sie gesehen haben müssen, kann man wie oben dargestellt sehr gut, allein schon an der Häufigkeit von verwendeten Wörtern ablesen. Noch interessanter wird es, wenn man sich die inhaltlichen Änderungen der VAIT 2.0 ansieht. Mehr dazu im nächsten Blog Post.

·         Ich hoffe, die BaFin-Prüfer einen ordentlichen Bonus erhalten haben. Jeden Tag in der IT-Steinzeit „rumwühlen“ zu müssen war sicher nicht vergnügungssteuerpflichtig.

Diese Prüfarbeit ist aus meiner Sicht aber sehr wichtig für die Versicherungsnehmer, die Versicherer und den Finanzplatz Deutschland. Good job! Machen Sie weiter so!

·         Compliance, insbesondere IT-Compliance, muss endlich den Platz erhalten, der für das Business wichtig ist: Compliance First, Security Second und Fachlichkeit Third.

Quellen:

Stellungnahme des GDV zur VAIT 15.03.2018 https://www.gdv.de/resource/blob/32190/3afbb30d4a70d2bf34b02971c6b856f3/vait-stellungnahme-download-data.pdf

BaFin: 15.10.2020 - IT der Versicherer im Fokus - Erste Prüfungen der BaFin zeigen: Bei der Umsetzung der VAIT ist noch Luft nach oben

https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Fachartikel/2020/fa_bj_2010_IT_Pruefungen_VA.html

Aktuelle Version der VAIT vom 03.03.2020

https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Meldung/2022/meldung_2022_03_03_Aktualisierung_VAIT.html

Auf der offiziellen Webseite des Beauftragten der Bundesregierung für Informationstechnik unter

https://www.cio.bund.de/Web/DE/IT-Beschaffung/EVB-IT-und-BVB/evb-it_bvb_node.html

 findet man „das Objekt der Begierde“. Einleitend wird mitgeteilt:

Mit den Ergänzenden Vertragsbedingungen für die Beschaffung von IT-Leistungen (EVB-IT) und den zwei noch geltenden Besonderen Vertragsbedingungen für die Beschaffung von DV-Anlagen und Geräten (BVB) wird nahezu das gesamte Anwendungsspektrum der IT-Beschaffung der öffentlichen Hand abgedeckt.

Zusätzlich gibt es ein Dokument „EVB-IT Cloud – Hinweise zur Nutzung der EVB-IT Cloud – Kurzfassung“. Dies enthält sogar ein Beispiel, wie man einen Cloud-Vertrag ausfüllen kann.

Außerdem erfährt man Folgendes:

Mit Beschluss vom 11. Februar 2022 hat der IT-Planungsrat die EVB-IT Cloud gebilligt und seinen Mitgliedern zur Anwendung empfohlen. Die Mitglieder des Bitkom-Arbeitskreises Öffentliche Aufträge haben sich für die Veröffentlichung der zwischen Öffentlicher Hand und der Verhandlungsdelegation des Bitkom abgestimmten EVB-IT Cloud ausgesprochen.

Wie schön denkt der geneigte Leser. Da ist ja dann alles an einem Platz zusammengefasst.

Genug der Vorbereitung. Gehen wir nun frisch ans Werk: Die EVB-IT Cloud AGB umfassen 21 Seiten. Der Umfang scheint überschaubar. 

Ernüchterung schon beim ersten Absatz

Ein Blick auf das Inhaltsverzeichnis lässt einen stutzen: Es sieht aus wie bei einem traditionellen IT-Outsourcing-Vertrag. 🤔 Nun gut, denke ich, lass nicht gleich alle deine Vorurteile hochkommen! Gib dem Dokument eine Chance. Immerhin gibt es sogar ein Glossar.

Schauen wir uns den Text genauer an. Punkt 1 des Werkes: Gegenstand der Vertrages. Jetzt stutze ich nicht, ich musste laut lachen. Ich war sogar geneigt das Dokument direkt in den Rundordner zu werfen (was ich nicht tat), steht da doch unter 1.1 tatsächlich:

Die Leistungen des Auftragnehmers können insbesondere umfassen:

·               Software as a Service (SaaS)*,

·               Platform as a Service (PaaS)*,

·               Infrastructure as a Service (IaaS)*,

·               Managed Cloud Services (MCS)*,

·               Sonstige mit den vorgenannten Leistungen in Zusammenhang stehende Leistungen,
          wie zum Beispiel initiale Leistungen.

Soweit der Auftragnehmer bei der Leistungserbringung im Auftrag Daten des Auftraggebers verarbeitet und/oder hostet, ist dies Teil der geschuldeten Leistungen

Man sieht sofort, dass hier wieder „alles IT ist“. Eine Differenzierung findet gar nicht erst statt. Beispielsweise ist Cloud Computing per Definition ein Mietvertrag und kein Dienstvertrag.

·         IaaS, PaaS, SaaS sind Produkte i.S. eines Mietservices, zumindest nach der NIST Definition Cloud Computing SP 800-145 vom Sept. 2011.

·         MCS ist eine klassische Dienstleistung, die man mit einem entsprechenden (altbekannten) Dienstleistungsvertrag regelt.

Mietgegenstände und Dienstleistungen in einem Vertragskonstrukt abhandeln zu wollen - kann man machen, aber sollte man aus meiner Erfahrung niemals machen, wenn man sich der unterschiedlichen Dimension nicht bewusst ist. Es führt nur zu Missverständnissen und im schlimmsten Fall zu Verfahren vor Gericht.

Die Definition von Cloud Computing

Der Ansatz „Cloud Computing sind doch Server nur woanders“, wie er in den EVB-IT Cloud AGB dargestellt wird trägt nicht. Cloud Computing ist ein fundamentaler Paradigmenwechsel, wie man Infrastrukturen und Anwendungen baut und betreibt, mit Shared Resposibility umgeht und entsprechende Verträge schließt.

Im Sept. 2011 hat die amerikanische Normierungsbehörde NIST bereits eine Definition zum Cloud Computing herausgegeben. Bereits? Nun ja, 5 Jahre nachdem AWS im Jahre 2016 das Licht der Welt erblickte gab es also eine erste Definition. Diese Definition ist allerdings so gut ist, dass sie auch noch heute (2022) trägt. https://csrc.nist.gov/publications/detail/sp/800-145/final

Es geht also bei Cloud Computing um die industrielle Fertigung von Infrastrukturen und Anwendungen ohne manuelle Eingriffe.

Sie fahren ja auch einen Miet-PKW ohne sich mit SIXT abstimmen zu müssen, wie Sie fahren sollen, wo Sie tanken und parken oder wohin Sie fahren.

Same old thinking - Same old results

Ich ahne Böses und alle meine Vorurteile werden auf den nachfolgenden Seiten des Dokuments leider bestätigt. Hier ein paar Beispiele:

Unter 2.1.1 Art und Umfang der Leistungen 

Es müsste aber eigentlich heißen: Art und Umfang des Mietgegenstandes😉

Insbesondere hat der Auftragnehmer die Cloudinfrastruktur und die Anwendung bzw. Plattform so zu dimensionieren, dass diese mit einer im Hinblick auf die zu erwartenden bzw. vereinbarten Zugriffe angemessenen Reaktions- und Ausführungsgeschwindigkeit und mit einem für die bestimmungsgemäße Nutzung ausreichendem bzw. dem vereinbarten Speicherplatz verfügbaren aktuellen Sicherheitspatches und auch im Übrigen den vereinbarten Anforderungen entsprechend zur Verfügung steht.

Nein, liebe EVT-IT Cloud AGB Autoren: Da muss man unterschieden:

·         Bei IaaS: das ist die Aufgabe des Auftragnehmers

·         Bei PaaS: das ist die Aufgabe des Auftragnehmers

·         Bei SaaS: das ist eine Selbstverständlichkeit, aber völlig deplatziert. Oder legen Sie so etwas im übertragenen Sinne etwa beim Kauf eines Autos gegenüber dem Hersteller auch fest?

Unter 2.1.2 finden man diesen schönen Absatz

Soweit vereinbart, ist der Auftragnehmer zur Installation und Integration der im Vertrag vereinbarten Programmstände* der Anwendung/Plattform verpflichtet. Dies erfolgt jeweils innerhalb angemessener Frist, nachdem der Programmstand* verfügbar ist, jedoch unter Beachtung von Ziffer 2.1.5.

Nein, liebe EVT-IT Cloud AGB Autoren:

·         Wenn Sie das haben wollen, dann schließen Sie bitte einen traditionellen Hosting-Vertrag ab. Beispielsweise patched man beim Cloud Computing nicht, sondern wendet ein Deploy & Destroy Verfahren ein, um immer auf dem aktuellen Stand zu sein.

·         Cloud Computing funktioniert anders! Cloud Computing ist die industrielle Fertigung von Infrastrukturen und Anwendungen.

Und munter geht es so weiter unter 2.2.1 Infrastructure as a Service (IaaS)

Soweit eine IaaS*-Leistung geschuldet ist, stellt der Auftragnehmer dem Auftraggeber ab dem vereinbarten Bereitstellungszeitpunkt die im Vertrag vereinbarte Cloudinfrastruktur zur Nutzung zur Verfügung und sorgt für die vereinbarte Verfügbarkeit, die vereinbarte Qualität der Leistung (funktional und nichtfunktional) sowie für die Sicherheit der Cloudinfrastruktur. Ziffer 2.1.1 Sätze 3 ff. gelten entsprechend.

Nein, liebe EVT-IT Cloud AGB Autoren:

·         Bei Cloud Computing gibt es keinen „vereinbarten Bereitstellungszeitpunkt“

·         Laut NIST Definition beinhaltet Cloud Computing nämlich immer Self-Service:

o   A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

Man könnte dieses Spiel seitenweise weiter treiben bis es langweilig wird. Aber einen Punkt finde ich noch erwähnenswert:

Unter Punkt 3 Nutzungsverbote

Soweit der bestimmungsgemäße Gebrauch der Leistung nicht explizit beschrieben ist, ist eine Verwendung der Leistung im Hochrisikobereich ausgeschlossen (Betrieb von Kernenergieanlagen, Flugsicherungssystemen, Kriegswaffen, lebenserhaltenden Apparaten oder vergleichbare risikobehaftete Anwendungen, bei denen Leistungsstörungen typischerweise unmittelbar zum Tod von Menschen oder zu Großschadenslagen führen).

Mir ist das zu pauschal und zu oberflächlich. IT ist heute integraler Bestandteil nicht nur bei der Verwaltung wirtschaftlicher Zusammenhänge, sondern eben auch als Embedded Systeme. Zu den Embedded Systemen zählen aus meiner Sicht (bezogen auf die obige Auflistung): Kernenergieanlagen, Flugsicherungssystemen, Kriegswaffen, lebenserhaltende Apparate. Aber warum beispielsweise ein Krankenhaus seine Verwaltungssysteme, nicht die Software für die Herz-Lungenmaschine, sondern für die DRG Abrechnung, Personalplanung, etc. nicht in „der Cloud“ betreiben soll, erschließt sich mir nicht. Ich erinnere nur an den Fall der Düsseldorfer Uni-Klinik im Sep 2021. "DoppelPaymer“-Ransomware legte die Verwaltung der Klinik lahm. Eine Notfallpatientin verstarb, weil sie nach Wuppertal zu einem Ersatzkrankenhaus gebracht werden musste.

Auch sollte dem öffentlichen Dienst mittlerweile bekannt sein, dass z.B. mit Azure Stack oder AWS Outpost Edge-Dienste für das eigene Rechenzentrum zur Verfügung stehen. Security können die Hyperscaler besser als jede interne IT-Abteilung eines Unternehmens oder einer Behörde. Das BSI vielleicht ausgenommen.

Ein kurzer Ausflug in den aktuellen Koalitionsvertrag

Unter dem Punkt Nachhaltigkeit bei der Digitalisierung:

Für IT Beschaffungen des Bundes werden Zertifizierungen wie z. B. der Blaue Engel Standard. Ersatzteile und Softwareupdates für IT-Geräte müssen für die übliche Nutzungsdauer verpflichtend verfügbar sein. Dies ist den Nutzerinnen und Nutzern transparent zu machen.

Wenn man das liest, dann kann man sich kaum des Eindrucks erwehren, dass Digitalisierung nur aus Handys, Notebooks und PCs besteht.

Unter dem Punkt Wirtschaft / Industrie:

Wir schaffen sichere Absatzmärkte für klimafreundliche Produkte durch Mindestquoten in der öffentlichen Beschaffung.

Schön, das unterschreibe ich sofort. Nur muss den Verantwortlichen klar sein, dass man dann sofort alle eigenbetriebenen Rechenzentren zuschließen müsste. Auch die meisten deutschen Hoster im Vergleich zu AWS, Azure, GCP im wahrsten Sinne „Dreckschleudern“.

Kurzer Rückblick: AWS hat mit Graviton 2 eine eigene CPU entwickelt (2019), die ein 40% besseres Preis-/Leistungsverhältnis aufweist als vergleichbare INTEL oder AMD CPUs. Mit Graviton 3 (2021) wurde die Leistung für Machine Learning, aka KI, Aufgaben um Faktor 3 beschleunigt bei gleichzeitiger Senkung des Strombedarfs um bis zu 60% gegenüber Graviton 2. Wer kann da noch mithalten?!

Unter dem Punkt Vergaberecht

Wir wollen die öffentlichen Vergabeverfahren vereinfachen, professionalisieren, digitalisieren und beschleunigen. Die Bundesregierung wird die öffentliche Beschaffung und Vergabe wirtschaftlich, sozial, ökologisch und innovativ ausrichten und die Verbindlichkeit stärken, ohne dabei die Rechtssicherheit von Vergabeentscheidungen zu gefährden oder die Zugangshürden für den Mittelstand zu erhöhen. Wir werden die bestehenden Anforderungen entsprechend des europäischen Vergaberechts im nationalen Vergaberecht präzisieren.

Das hört sich alles gut an. Aber leider gibt keinen europäischen Hyperscaler, der mit AWS, Azure oder GCP mithalten kann. Wie wäre es, sich mehr darauf zu fokussieren wie man die Hyperscaler secure und compliant nutzen kann? Das geht nämlich.

Bottom Line

Es macht einen schon nachdenklich, wenn nach 15 Jahren AWS, nach 11 Jahren NIST Cloud Definition im Feb. 2022 Cloud Beschaffungs-AGBs seitens des Bundes-CIO veröffentlicht werden, die „Cloud als Server, nur woanders“ sehen. Das Suchen und Ersetzen des Wortes Hosting durch Cloud macht noch keine Cloud-AGBs!

Was mich wundert, ist, dass selbst der Bitkom dieses Dokument durchgewunken hat. Das lässt sich nur erklären, dass die deutschen Hoster, die angeblich auch Cloud können, hier mitgewirkt haben. Hosting nur umbenennen in Cloud Computing reicht nicht. So aber wird das nix mit den digitalen Zielen des Koalitionsvertrages.

Ich komme langsam ins Rentenalter und ich frage mich ernsthaft, wie die jüngere Generation die Renten der Boomer zukünftig erwirtschaften wollen, wenn bei der Basis der Digitalisierung (und das ist Cloud Computing wie es AWS, Azure und GCP bereitstellen) ein so grundsätzliches Unverständnis des Cloud Computing Paradigmenwechsels besteht.

Naja, dann arbeite ich halt noch ein wenig länger als geplant. Bekanntlich stirbt die Hoffnung zuletzt.😉

Wie alles anfing

Am 01.07.2017 anlässlich des 10-jährigen Firmenjubiläums der Firma PRIOGO AG in Zülpich gab es einen Vortrag von Prof. Günther Schuh und die Möglichkeit den e.GO Life Probe zu fahren. Es war ein Samstag und ich verabschiedete mich noch von meiner Frau mit den Worten: „Keine Angst, ich kaufe nicht gleich ein e-Auto.“ Von wegen: 5 Std. später musste ich meiner Frau beichten, dass ich spontan eine Vorbestellung für den neuen e.GO Life getätigt hatte.🤷‍♂️

Die spontanen Beweggründe

Prof. Günther Schuh ist einfach ein begnadeter Redner. Seine Argumente haben mich damals und auch heute noch voll überzeugt. Sinngemäß waren es diese Argumente:

• Ein Autokauf ist eine emotionale Angelegenheit. Optik und Fahrspaß sind entscheidend.
• Ein e-Auto wird nur gekauft, wenn es zum gleichen Preis eines Verbrenners, besser noch preiswerter, zu haben ist.
• Ein e-Auto mit einer kleinen Batterie (Reichweite bis 150 km) hat einen guten ökologischen Fußabdruck.
• Neuwagen müssen grundsätzlich nachhaltiger gebaut sein, als Vorgängerversionen
• Wer braucht schon Tankstellen? Erst recht e-Tankstellen? Private Schnelllade-Wallboxen? 

Dafür müsste die gesamte Strom-Infrastruktur in den Städten und Gemeinden neu ausgebaut werden. Eine 220 V Steckdose ist vollkommen ausreichend. Das Auto steht ja i.d.R. 23 Std. am Tag eh auf einem Parkplatz rum.

Alle diese Anforderungen erfüllt der e.GO Life First Edition und darüber hinaus hat er noch eine Lebensdauer von 50 Jahren. Die Batterie allerdings wird man voraussichtlich alle 8 Jahre austauschen. Die alte Batterie wird dann noch einer Zweitverwertung zugeführt.

Analyse meines Mobilitätsverhaltens

Aufgrund meines damaligen beruflichen Wechsels nach Hannover zur Talanx<Linkedin> kam ich im Okt. 2007 in den Genuss einer Bahncard 100 First. Ich wurde begeisterter Bahnfahrer und legte zw. 50.000 – 60.000 km / pro Jahr zurück. Corona beendete im März 2020 die Liebe leider (oder vielleicht auch Gott sei Dank) abrupt. Auch wenn Bahnfahren ökologisch & ökonomisch sinnvoller ist als mit dem Auto zu fahren. Ein Video Call ist noch günstiger.

Von 2002 – 2007 bin ich noch täglich die Strecke Bonn - Hilden / Düsseldorf mit dem Auto gefahren. Ich „genoss“ das am stärksten befahrene Autobahnteilstück Europas, die A3 Köln – Leverkusen. Okt. 2007 dann der Umstieg auf die Bahn. Ich muss gestehen, dass ich noch 3 Jahre benötigte, bis ich meinen Wagen abgeschafft habe, nachdem ich mal nachgerechnet hatte, dass ich nur 1.500 km damit gefahren bin pro Jahr. Alles Kurzstrecken.🤦‍♂️

Fahrten zum Kölner Weinkeller, zum Golfplatz nach Eitorf, zu Freunden nach Ittenbach oder Neunkirchen-Seelscheid, zur Bahn nach Siegburg oder zum Köln/Bonner Flughafen, zum Supermarkt und Ähnliches bestimmten meinen Bewegungsrahmen. Also rd. 50 km rund um Bonn. Alles was weiter entfernt ist, fahre ich eh grundsätzlich mit der Bahn. 

Was also sprach bzw. spricht gegen einen e.GO Life? Nichts!

Die erste Herausforderung

Leider musste ich 2,5 Jahre warten bis ich den e.GO Life endlich am 06.01.2020 in Aachen in Empfang nehmen durfte. Der Wagen Nr. 131 wurde der Meinige. 

Die erste Herausforderung: Das e.GO Werk in Aachen und mein Wohnort liegen 105 km auseinander. Die Reichweite lag damals noch bei 106 km (ein späteres Software Update erhöhte auf 146 km und schaltete noch weitere Funktionen frei). 

Was also tun? Meine Frau war mitgekommen und ich muss gestehen, dass ich sehr froh war, dass sie noch einen Termin in Köln hatte, so dass ich sie in Düren am Hauptbahnhof (das lag auf meiner Strecke) „hinauswerfen“ konnte. Auch wenn meine Frau schlank ist; jedes Kilo zählt bekanntlich beim Stromverbrauch, sowohl beim e-Bike als auch beim e-Auto. 😉

Natürlich habe ich auf dieser Fahrt alles das gemacht, was man von einem e-Automobilisten erwartet: Heizung aus, kein Radio an, maximale Ausnutzung der kinetischen Energie, langsam anfahren und lange ausrollen lassen. Bloß nicht bremsen. Ich hätte nur noch einen Hut auf haben müssen, um das Klischee vollständig zu erfüllen.😂Die „Bleifüßer“ werden mich an diesem Tag gehasst haben. Aber das Ergebnis konnte sich sehen lassen. Noch stolze 15 km Reichweite zeigte das System an als ich, zugegeben erleichtert, zu Hause ankam.

Die Tücken der Software

Bekanntlich ist ein Tesla ja kein Auto, sondern zwei Tablets auf Rädern. Wir alle wissen seit nunmehr 40 Jahren: Software reift bekanntlich beim Kunden. Ich war also darauf eingestellt, dass bei einem Vorserienwagen eines Startups, das noch ein Softwareupdate bekommen soll, nicht alles perfekt sein würde von Anfang an.

So war es dann auch. Zweimal „sprang“ der Wagen nicht an. Mit einer zweijährigen Mobilitätsgarantie seitens der e.GO AG war das jetzt auch nicht so schlimm. Das Notfall Call Center funktionierte. Lustig war die telefonische Kommunikation mit dem Abschleppservice: 

• Abschlepp-Manager: „Sie brauchen ne Starthilfe?“
• Ich: „Nein, das ist ein e-Auto und der hat ne volle Batterie. Es handelt sich um einen e.GO Life First Edition.“
• Abschlepp-Manager: „Ich hab‘ das Fahrzeug auch erstmal googlen müssen …dann kommen wir jetzt und schleppen ihn ab.“

Nach 20 Minuten war er da und der Wagen wurde ins Dieselzentrum nach Köln gebracht. Auch lustig: Ein e-Auto ins Dieselzentrum Köln zu bringen. Die Aufklärung ist einfach: Das Dieselzentrum Köln ist ein BOSCH Wartungszentrum und da BOSCH die Wartung der e.GO Flotte durchführt, machte das auch Sinn. Der e-Motor ist übrigens von BOSCH.

Das Software Update

Der Wagen war nach dem Software Update auf die eigentliche Version 1.x nicht mehr wiederzuerkennen. Ich war und bin immer noch begeistert. Leicht ansprechende Lenkung, fahren mit einem Pedal (die Bremse nutze ich seitdem nur noch in Notsituationen), dank Freischaltung der Rekuperation auch Batterie-Reichenweiten-Verlängerung auf 146 km. Die elektronische Stabilitäts-Kontrolle (ESC) mit Antischlupfregelung (ASR) machten es möglich an der Ampel sportliche Premiumfahrzeuge ordentlich im e.GO-Sportmodus zu „zersägen“ 😎. Die erstaunten Reaktionen sind immer wieder schön, insbesondere von jungen männlichen Verkehrsteilnehmern 😉.

Die Förderung

Jaja, die Förderung von e-Autos ist doch ein schönes Beispiel für die „fortgeschrittene“ Digitalisierung öffentlicher Behörden. Bei der BAFA muss man das „Portal“ zur „Kommunikation“ nutzen. Die besteht nämlich aus dem „digitalem“ Antrag und dann warten auf die gelbe Post mit dem Bescheid. Beim Regierungspräsidenten in Arnsberg darf man auch mailen und telefonieren. Das ist doch schon mal was im Vergleich zur Servicewüste BAFA. (Sorry, das musste jetzt mal sein.) Wenn man sich als IT-ler diese beiden „Portale“ anschaut, dann gruselt es einem schon ein wenig.

• Der Umweltbonus der Bundes wird beim Bundesamt für Wirtschaft und Ausfuhrkontrolle (BAFA) beantragt:
  
  „Die Antragstellung erfolgt ausschließlich online auf dem elektronischen Antragsformular auf der Internetseite: http://www.bafa.de/umweltbonus. Per Post eingeschickte oder unvollständige Anträge können vom BAFA nicht bearbeitet werden.
  
  Die Antragstellung kann erst nach dem Erwerb (Abschluss des Kauf- oder Leasingvertrages bzw. verbindliche Bestellung) erfolgen.“

• Die Förderung für Unternehmen / Gewerbetreibende des Landes NRW wird beim Regierungspräsidenten Arnsberg – Abtl. 6 Bergbau und Energie beantragt:
  
  „Es wird darauf hingewiesen, dass beantragte Maßnahmen noch nicht beauftragt werden dürfen; es muss zunächst der Zuwendungsbescheid abgewartet werden, bevor die Maßnahme beauftragt werden kann.“
  
  P.S.: Da die Förderung vom Land NRW kommt, muss ich natürlich mindestens 80% meiner gefahrenen km in NRW fahren! Dafür muss ich ein Fahrtenbuch führen, um jederzeit den Nachweis erbringen zu können. Und das bei einem Stadtauto, besser Nahverkehrsauto! Ok, ich könnte von Bonn aus die Landesgrenze von Rheinland-Pfalz erreichen. Und ja, der Friseur meiner Frau, den sie länger kennt als mich 😉, hat sein Geschäft in Remagen. Ich kann die Landesregierung von NRW beruhigen, durch die Fahrten meiner Frau zu ihrem Friseur kommen keine 21% der Gesamt-Kilometerleistung zusammen.

Ah ja, man sieht schon, dass es ein sehr abgestimmtes Verfahren zwischen Bund und Ländern gibt. (Achtung Ironie). Bei einem Amt mit dem Kauf erst abwarten bis der Bescheid kommt, beim anderen dann zittern, ob man die Prämie noch bekommt, weil man ja erst nach Kauf beantragen kann und dann gilt da auch noch das FiFo Prinzip mit einem gedeckeltem Fördertopf! Bei mir als Einzelunternehmer war das nur nervig, aber wie soll das eigentlich ein Unternehmen, das vielleicht 20 e-Autos erwerben will, machen? Liebe #SPD, #Grüne, #FDP und #CDU es wird Zeit so einen Behördenwildwuchs abzuschaffen, sonst gibt es nichts mit der #Mobilitätswende! Gut gemeint reicht nicht mehr aus. Man muss es auch gut machen. Wie wäre es mal mit niederschwelligen Angeboten…

Genug genörgelt. Ich kann mich nicht beklagen, auch wenn ich auf die Auszahlung des Umweltbonus durch die BAFA über ein halbes Jahr warten musste, im Gegensatz zum Regierungspräsidenten Arnsberg, der mit nur 2 Monaten hier als Sieger hervorging. Die Ursache: Die Bundesförderungsregeln (BAFA) hatten sich nämlich geändert. 

Statt 2.000 € wurden nun 3.000 € durch den Bund nun gefördert. Dies immer unter dem Vorbehalt, dass der Hersteller in gleicher Höhe die Kaufrechnung reduziert. Ich hatte, wie alle langwartende e.GO Vorbesteller, neben 2.000 € Umweltbonus durch die e.GO AG auch einen „First Edition Rabatt“ bekommen i.H.v. 1.470,58 (Netto). 

Die BAFA brauchte daher ein wenig Zeit, um einen Änderungsbescheid zum Bundesumweltbonus auszustellen, in dem dieser „First Edition Rabatt“ als „paritätische Förderung“ i.S. der neuen 3.000 € Umweltbonusregelung gelten konnte, so dass ich nunmehr 3.000 € statt 2.000 € Bundesumweltbonus durch die BAFA erhielt. Nach dem Änderungsbescheid kam das Geld auch ruckzuck auf meinem Konto an. Da habe ich doch gerne gewartet.
Vielen Dank😎. 

Ich kann es mir aber trotzdem nicht verkneifen: Die digitale Kommunikation während der Wartezeit (6 Monate) war gleich null und analoge Kommunikation (Telefonanrufe oder Briefe) und Emails verbietet sich das BAFA ja bekanntlich (siehe Webseite)… ohne Worte.

Die Anschaffungskosten

Die Verbrauchskosten

Beim Diesel liegt der Preis pro Liter aktuell bei rd. 1,54 € in Bonn. Wenn ich mal wieder bei einer Tankstelle vorbeikomme, kann ich mich eines „Schmunzelns“ nicht erwehren🤣.

Meine Aufstellung zu den laufenden jährlichen Kosten für 2022 erklärt auch warum:

Gesamtkostenbetrachtung für 6 Jahre

ÖPNV oder e.GO?

Die positiven Erfahrungen, die ich mit der Bahncard 100 von 2007 bis 2020 gemacht habe, haben mich zu einem ÖPNV Fan werden lassen. Flatrate bei Bahn & Bus bundesweit und in 130 Städten waren und sind grundsätzlich schon cool und verändern Mobilitätsverhalten extrem.

Durch Corona ist die Situation jedoch eine andere geworden. Ich fahre nicht mehr für ein 1-2 stündiges Meeting mal schnell nach Nürnberg oder Berlin. Teams, Zoom & Co. haben das überflüssig gemacht.

Es bleibt der Nahverkehrsbereich: z.B. 9 km bis in die Bonner Innenstadt. Hin und zurück 18 km. Keine Parkgebühren für Straßenparkplätze bei e-Autos (Bonner Regelung). 

Also 1,62 € Vollkosten hin- und zurück. 

Das ÖPNV-Einzelticket kostet 3,00 € (Papierticket) oder digitales App-Ticket für 2,85 €. 🤔

Ok, sagen wir ein Ü60 Ticket-Monatsticket im VRS Verbund Bonn/Köln (also rd. 50 km Radius) wäre eine Lösung. 117,70 € / Monat und Person (5 Tarifstufen) und dann nur in NRW gültig. Nach Remagen, Koblenz oder Bad Neuenahr gilt das Ticket nicht. Meine Frau käme nicht mal mehr zu Ihrem Friseur! 🤣

Ganz klar: Das e.GO Life Konzept setzt den ÖPNV massiv unter Druck. Selbst bei reduzierten Ticketpreisen für Ü60er. 

Bottom Line und Ausblick

Ich hoffe, liebe(r) Leser(in) es hat Ihnen Spaß gemacht diesen Blog zu lesen. Wie ich im Teaser schon gesagt habe: Nicht für jede Situation passt das, was meine Frau und ich hier praktizieren. Den Anspruch haben wir auch nicht. 

• Würde ich einen e.GO wiederkaufen? Aber ja! Nie wieder ohne. Ganz klar, ich fahre e.GO statt ÖPNV und habe dabei noch ne Menge Spaß. Vielleicht würde ich mir heute den e.GO Cross gönnen.😉
• Würde ich ein e-Auto von einem etablierten Hersteller kaufen? Nein, eher nicht, weil deren Konzepte bisher eigentlich nur sind: Ersetze Verbrenner durch e-Motor. Die e.GO Next SE hat da ein komplett anderes Konzept (siehe Prof. Schuhs überzeugende Argumente).
• #umparkenimKopf  ist dringend notwendig. Analysieren Sie Ihr Mobilitätsverhalten, nicht nur emotional 😉.
• e-Mobilität bedeutet keinen Verzicht. Im Gegenteil, es ist ein Gewinn: Insbesondere für die Babyboomer und Rentner-Rookies meiner Generation kann e-Mobilität eine deutliche Reduktion ihres monatlichen Renten-Cash-outs bedeuten.
• Da bleibt dann auch noch was zum Vererben und wenn es nur ein e.GO ist 😉. Wenn „Freude am Fahren“ und „Vorsprung durch Technik“ jetzt nicht nur aus Bayern, sondern auch aus Aachen kommen, dann freuen sich auch die Enkel😉
• Eine Schnelllade-Wallbox daheim und -Infrastruktur unterwegs ist rausgeschmissenes Geld. Weil viele bei diesem Punkt den Kopf schütteln werden, werde ich dazu noch einen separaten Beitrag schreiben. Bleiben Sie gespannt.

Und wie schon gesagt: Meine Story hier ist nur eine anekdotische Evidenz… 👋

#Deleveloper und #Admins, die immer noch glauben, dass #cloudnative mit #Containern bzw. #K8s gleichgesetzt wird, können sich hier spielerisch eines Besseren belehren lassen.

Jeremy Daly hat hier einen wirlich super coolen Beitrag im letzten Jahr veröffentlicht: das Lambda Musical. Ein wirklich schönes Geschenk. 🎁 Vielen Dank dafür!!👍👍👍

Ich hab mich schlapp gelacht 🤣

Viel Spaß beim anschauen...

P.S.: globaldatanet das wäre duch die richtige Intro-Musik für nächsten Serverless Summit 22 😉

Am 01.11.2021 habe ich mit meinem Blog📰 mit ein bisschen Herzklopfen ❤ begonnen. Ich hatte mich darauf eingestellt, dass Arbeit auf mich zukommt. Deshalb hatte ich mir einen Plan 📝 gemacht und die ersten Blog Posts bereits vorgeschrieben. Wie immer ist ein Projektplan nur der Nachweis des Machbaren. Die Realität sieht bekanntlich immer anders aus.🗑 So auch bei mir, das Vorschreiben hat nicht viel geholfen, ich habe alle Posts mehrfach umgeschrieben.✏

Ich möchte heute, zum Jahresabschluss, meine Statistik mit Ihnen teilen:

Vielen, vielen Dank 🙏 für dieses 🎁 und überwältigende Feedback. Damit habe ich nie in diesem Maße mitgerechnet.

Darüber hinaus haben eine Reihe alter Weggefährten 🤵und jüngere Kollegen den Kontakt zu mir gesucht. Wir hatten nicht nur sehr interessante Email-Kommunikationen und Video Calls, sondern das ein- oder andere Thema wird gemeinsam weiterverfolgt.

Vielen Dank für alles. Es ist reinste Motivation, um weiterzumachen. Die Liste von Ideen📝ist lang, z.B.:

1.      „Die Untiefen des Cloud Governance Cyles“

2.      „Agile Cloud Projekte im Spannungsfeld von HGB und IFRS“

3.      „EC2, Kubernetes oder doch gleich Serveless“

....

Gerne nehme ich aber auch Ideen💡 und Themen aus der Leserschaft auf. Also trauen Sie sich und schicken mir ein Thema 🌥📌, zu dem Sie gerne meine Einschätzung / Kommentar haben wollen.

Am 17.01.2022 werde ich den nächsten Blog Post veröffentlichen. Bis dahin wünsche ich Ihnen alles Gute, ein schönes Weihnachtsfest und einen guten Rutsch ins neue Jahr. Lassen Sie sich boostern und bleiben Sie gesund. Der digitale Wandel braucht Sie!👋😉

Disclaimer: Die nachfolgenden Ausführungen stellen eine Meinungsäußerung dar, keine juristische Beratungsdienstleitung. Dazu fragen Sie bitte Ihren Justiziar oder Ihren Anwältin.

Zu den technischen IT-Compliance-Anforderungen gehören physische Sicherheit der Systeme, Zugangsschutz und Business Continuity Management, Hardware, OS-Konfigurationen & Härtung, etc. Viele dieser Anforderungen werden durch vertragliche Konstrukte abgedeckt wie User Agreement, Enterprise Agreement, Service Terms, SLAs, etc. Aber eben nicht alle.

Technische IT-Compliance-Anforderungen, die auf Basis von Cloud Services konfiguriert werden, sollten weniger über die einschlägigen Konsolen der Cloud*) Provider konfiguriert, sondern mit Infrastructure-as-Code durchgeführt werden. Reproduzierbarkeit und Überprüfbarkeit der Ergebnisse lassen sich so am besten garantieren. „Weniger ‚Künstler‘, mehr Fließbandarbeit in der IT-Infrastruktur wagen!“, ist heute Stand der Technik.

Die Bereitstellung muss so einfach sein, dass das von jede(m/r) Assistent(en/in) durchgeführt werden kann. Ohne ausgeprägte IT-Kenntnisse. So einfach wie ein one-click Einkaufserlebnis beim Online-Weinhändler Ihres Vertrauens. 

Die Compliance Landing Zone

Werden IT-Compliance-Anforderungen beim Bau von Cloud-Infrastrukturen per default mit einbezogen, so kann man das durchaus als Compliance-by-Design bezeichnen. Wichtig ist dabei, dass tatsächlich alles automatisiert und per Infrastructure-as-Code bereitgestellt wird. Es sollte nicht vorkommen, dass der Cloud-Admin noch schnell via Konsolenzugriff ein paar Einstellungen „nachliefert“. Damit das nicht „per Zufall“ passieren kann, empfehle ich die Konsole des Cloud Accounts zu versiegeln und den Root-Account in einem Bankschließfach „zu versenken“. 

Empfehlenswert ist auch eine Funktionstrennung zwischen denjenigen, die per Infrastucture-as-Code entwickeln und denen, die testen und denen, die die Verantwortung in der Produktion tragen.

Zwingend notwendig ist es, dass der IT-ler sich mit juristischen Texten auseinandersetzen muss. Ich sehe schon die fragenden Gesichter: „Warum ich? Das kann doch der Jurist besser.“ Ja, der Jurist versteht die Texte und die „Dependencies“ (IT-Sprech) zw. den unterschiedlichen Gesetzen, Verordnungen im EU- und dem nationalen Recht besser als der IT-ler. 

Was ist aber mit der Ableitung dessen, was technisch umgesetzt werden muss?! Welche Cloud Services setze ich wie zusammen, um den IT-Compliance-Anforderungen gerecht zu werden? Das kann im Regelfall der IT-ler besser als der Jurist. Deshalb bleibt es dem IT-ler nicht erspart, die juristischen Texte durchzuarbeiten - sich mit Juristen abzustimmen - und die technische Ableitung festzulegen. 

Zugegeben, diese Tätigkeit ist jetzt nicht gerade vergnügungssteuerpflichtig. Nach über 10 Jahren praktischer Cloud Erfahrung im hoch-regulierten Umfeld sowohl auf der Anwender- als Anbieterseite gibt es aus meiner Sicht keine andere Möglichkeit.

Ich gebe auch gerne zu, dass mich beispielsweise das Durcharbeiten der GDPR nicht nur eine ganze Woche Arbeit gekostet hat (inkl. „beglückender“ Entdeckungsmomenten von Übersetzungsfehler im deutschen Text), sondern auch drei sehr gute Rotweinflaschen🍷, die ich mir als Motivation gönnen „musste“.😉

Sind die IT-Compliance-Anforderungen entsprechend berücksichtigt, so handelt es sich bei der Compliance Landing Zone de fakto um eine juristische Anwendung (siehe dazu auch meinen Blog Post No. 4: „Cloud*) ist wie Hosting!“ – Wirklich?).

Die juristische Compliance-Ausmultiplikation 

Technisch - und damit aus Sicht eines IT-lers - ist es völlig egal welche rechtliche Einheit für die Anwendungsentwicklung, den IT-Betrieb, den User Help Desk, etc. verantwortlich ist. Der IT-ler sieht immer nur das technische Gesamtkonstrukt und das im Hinblick auf: Wie schnell kann ich was bereitstellen und läuft es technisch stabil. Immer nach dem Motto: „Developer statt Customer Experience / Convenience First“. 

Nicht nur Kunden, sondern auch Juristen haben allerdings einen ganz anderen Blickwinkel als IT-ler. Deshalb müssen wir uns dem Thema der Haftung nähern und damit den Fragen: „Wer entwickelt / betreibt was? Wer ist für was verantwortlich?“ Die Haftungsfrage ist eine der zentralen juristischen Fragen.

Juristisch ist es ein Unterschied, ob die IT mit eigenen Mitarbeitern entwickelt und betrieben wird oder eben nicht. Der Bezug Anwendungen oder der IT-Betrieb als Fremdbezugsleistung von Dritten hat einen juristischen Impact; technisch meist nicht. Neben Fragen nach der Fertigungstiefe der bezogenen Dienstleistung, der handwerklichen oder industriellen Fertigung, der Durchführung des Betriebes, der Rest-Eigenleistung, etc., spielen hier juristische Fragestellungen die wirklich entscheidende Rolle.

Das fängt bei der Scheinselbständigkeit von Freelancern (§ 7 Abs. 4 Satz 1 Nr. 4 des SGB IV) und der Arbeitnehmerüberlassung (AÜG) an und endet im IT-Betrieb bei der Auftragsdatenverarbeitung (ADV) mit technisch-organisatorischen Maßnahmen (TOM). (Anmerkung: Die Auflistung ist nicht abschließend.)

Das hat zur Konsequenz, dass eine Compliance Landing Zone, die von unternehmenseigenen IT-Mitarbeitern entwickelt und betrieben wird, technisch anders aussehen kann als die Compliance Landing Zone eines ISVs, der eine compliant SaaS Lösung anbietet.

Wenn man so will, stellt die Entwicklung und Betrieb einer Compliance Landing Zone, durch eigene Mitarbeiter, juristisch eine Öffnungsklausel dar. Mit der Folge, dass weniger umfangeiche IT-Compliance-Anforderungen umzusetzen sind. Dies begründet sich in der Annahme, dass ich im eigenen Unternehmen meine Mitarbeiter direkter beaufsichtigen und führen kann. Führen ist hierbei i.S.v. Weisungsbefugnis zu verstehen.

Die Idee ist gut in der Theorie. Ich kenne viele IT-Admins, die nach dem Motto gehandelt haben: „Ich habe schon so viele Vorstände kommen und gehen sehen… Ich bin hier der IT-Admin.“ Deshalb empfehle ich auch hier, die strengeren IT-Compliance Anforderungen anzuwenden, die für externen Sachbezug bzw. IT-Dienstleistung durch Dritte. Auch im Falle, dass die eigene IT-Mannschaft versucht zu „meutern“. Aus Erfahrung kann ich sagen: Standhaftigkeit hilft. Es soll vorkommen, dass für den Standhaften Spitznamen wie Darth Vader oder Lord Voldemort vergeben werden. Falls das Ihnen passieren sollte: Meine Gratulation.🥇

Es hilft nicht nur bei der Disziplinierung von IT-Admins, sondern auch enorm bei M&A Aktivitäten und De-Investments von Unternehmensteilen. Wer ein IT Cave-out schon mal mitgemacht hat, weiß wovon ich rede.

Bottom Line

Technische Compliance Anforderungen sind lösbar mittels Infrastructure-as-Code und einer klaren Funktionstrennung zw. Entwicklung einer Landing Zone einerseits und dem (mehrfachen) Deployment und Betrieb derselben andererseits.

Beim Design einer Compliance Landing Zone empfehle ich die strengsten IT-Compliance-Anforderungen als Basis zu verwenden. Nicht die Developer/IT-Admin Experience / Convenience steht im Vordergrund, sondern die Business-Flexibilität u.a. für M&A Aktivitäten und De-Investments.

Die Bedeutung von Compliance wird in Zukunft weiter steigen, weil immer mehr IT-Services von Dritten bezogen werden. Die eigene Fertigungstiefe wird sich zukünftig deutlich verringern.

******

*) Mit Cloud meine ich immer nur Hyperscaler wie AWS, Azure, GCP oder Cloud-Provider, die die NIST SP 800-145 Norm vollständig erfüllen.

Die Bedeutung von Regeln insbesondere im digitalen Umfeld gewinnt zunehmend an Bedeutung. GDPR, IT Sicherheitsgesetze, §203 StGB, KRITIS Körbe, um nur einige zu nennen. Die GDPR Regulierung ist sicherlich die am weitesten bekannte. GDPR wird leider häufig missverstanden oder missbräuchlich instrumentalisiert. Datenschutz behindert nicht Innovationen, solange man „Stasi 2.0“ nicht als Innovation ansieht. Auch wenn Dr. Google da was anderes sagt: „Compliance behindert Innovation“ - Google Treffer - 219.000  (07.10.19) - 298.000 (05.09.20) - 701.000 (19.11.21). - Es wird durch Wiederholung nicht richtiger. Compliance kann auch durchaus Innovationstreiber sein.

Aus meiner Sicht macht es nur deutlich, dass es eine Art Verweigerungshaltung gibt, sich mit IT-Compliance auseinander zu setzen. Aus dem Finanzbereich hört man das weit weniger. Hier gehört es zur DNA „Gestaltungspielraum“ auszuloten z.B. bei der Bilanzerstellung. Auch wenn es manchmal zu Grenzüberschreitungen kommt, wie beim Enron-Skandal oder Cum-Ex Geschäften, die dann entsprechend geahndet werden.

Gesetzliche Prinzipien und Regeln muss man bei IT Projekten, ganz gleich welcher Art, an den Anfang als Business-Anforderung einstellen und nicht erst kurz vor Produktionsgang, meist auf Druck, betrachten.

Gesetze, Verordnungen und Rundschreiben von Aufsichtsorganen dienen nun mal dazu, dass wir unsere Gesellschaft ordnen, wie wir zusammenleben wollen. Das gilt auch für den digitalen Raum und damit eben auch für IT-Anbieter wie IT-Anwender.

Im Nachfolgenden sind wesentliche Punkte (nicht abschließend) adressiert, die beachtet werden müssen, um die Cloud compliant und stressfrei nutzen zu können.

Disclaimer: Die nachfolgenden Ausführungen stellen eine Meinungsäußerung dar, keine juristische Beratungsdienstleitung. Dazu fragen Sie bitte Ihren Justiziar oder Ihre Anwaltskanzlei. 

Meine Empfehlung: RA Michaela Witzel

Hauptkategorien der IT Compliance

IT-Compliance lässt sich grundsätzlich in zwei Hauptkategorien unterteilen:

• Compliance-Anforderungen an Infrastrukturen und Laufzeitumgebungen. Oft auch als Landing Zone benannte technische Basis für Anwendungen / Services.
• Compliance-Anforderungen an Anwendungen / Services, die i.d.R. sehr unterschiedlich sein können, je nach Anwendungsgebiet (z.B. Schadensverwaltung einer Unfallversicherung im Vergleich zu einer Social Media Anwendung).

Der Umgang mit IT-Compliance-Anforderungen

Um sich den juristischen Rahmen als IT-ler zu erschließen und davon abgeleitet eine technische Lösung bzgl. der IT-Compliance-Anforderungen zu entwickeln und umzusetzen, ist es sinnvoll folgende Vorgehensweise einzuhalten. Diese hat sich in der Praxis sehr bewährt:

• Strikte Trennung nach technischen IT-Compliance-Anforderungen und Compliance-Anforderungen, die in der Anwendung / Service umgesetzt werden müssen.
• Die Nutzung von rechtlichen Öffnungsklauseln ist zu vermeiden.z.B.: Die Kategorisierung des Schutzbedarfs von Dokumenten erhöht die Komplexität des technischen Designs und damit auch den Aufwand und auch die Komplexität bei der Umsetzung.
• Komplexität führt i.d.R. zu höheren Fehleranfälligkeiten. Deshalb wird grundsätzlich nur die strengste IT-Compliance-Anforderungen ausgewählt. Dies führt zur Reduzierung der technischen Komplexität, der Fehleranfälligkeit und manchmal auch zu höheren Erstaufwänden.

Rechtliche Öffnungsklauseln entstehen bekanntlich durch Kompromisse und waren sicherlich auch sinnvoll, so lange IT on-prem betrieben wurde. In der Cloud*) sind rechtliche Öffnungsklauseln eher hinderlich als hilfreich.

Anwendungsinterne Compliance-Anforderungen

In Bezug auf IT-Compliance-Anforderungen innerhalb von Anwendungen ist das Spektrum sehr weit. Es ist davon abhängig welche Art von Anwendung man bauen will und in welcher Branche diese zum Einsatz kommen soll.

Zwei Beispiele können das verdeutlichen:

(Anmerkung: Die im Nachfolgenden aufgelisteten Aufzählungen sind nicht abschließend.)

• Bei der Bestandsverwaltung von Lebensversicherungen in Europa sind u.a. BSIG (Gesetz über das Bundesamt für Sicherheit in der Informationstechnik) Compliance-Anforderungen aus dem Solvency II Regime (Richtlinie 2009/138/EG) und den daraus abgeleiteten nationalen Gesetzen, Verordnungen und Aufsichts-Rundschreiben zu berücksichtigen. Zusätzlich ist das Berichtswesen zu FATCA (Foreign Account Tax Compliance Act) und natürlich die GDPR zu beachten.

• Beim Betrieb einer Social Media Plattform / App sind hingegen, neben dem GDPR und dem BSIG (Gesetz über das Bundesamt für Sicherheit in der Informationstechnik), weitere gesetzliche Vorgaben zu beachten. Dies sind u.a. in Deutschland, das TMG (Telemediengesetz), TKG (Telekommunikationsgesetz), NetzDG (Gesetz zur Verbesserung der Rechtsdurchsetzung in sozialen Netzwerken), um nur einige zu nennen.

Es bleiben also noch genügend Baustellen selbst wenn die technischen IT-Compliance-Anforderungen (bezogen auf die Infrastruktur) gelöst sind. Zu den technischen IT-Compliance-Anforderungen und wie man diese am besten bewältigt schreibe ich im nächsten Blogbeitrag, der am 06.12.21 erscheinen wird. Der Umfang dieses Themas würde den Umfang dieses Blogbeitrags sprengen.

Bottom Line

Die Bedeutung von IT-Compliance ist heute schon hoch und diese wird in Zukunft weiter steigen.
IT-ler müssen sich deshalb mit IT-Compliance-Anforderungen stärker als bisher auseinandersetzen.

IT-Compliance ist keine Stabsfunktion mehr. IT-Compliance muss integraler Bestandteil sowohl bei jedem Projekt als auch im IT-Betrieb werden. Dabei sind immer die strengsten Anforderungen zu wählen. Öffnungsklauseln sind technisch zu vermeiden.

Es ist sinnvoll IT-Compliance-Anforderungen zw. technischen und anwendungsspezifischen Anforderungen aufzutrennen.

Die Interpretationshoheit z.B. des GDPRs darf man Juristen allein nicht überlassen. Deshalb müssen IT-ler die Gesetze und Verordnungen lesen und durcharbeiten, damit Juristen und IT-ler ein gemeinsames Bild zeichnen können.

******

*) Mit Cloud meine ich immer nur Hyperscaler wie AWS, Azure, GCP oder Cloud-Provider, die die NIST SP 800-145 Norm vollständig erfüllen.

Solche Aussagen habe ich schon vielfach gehört. Leider ist es mit einem einfachen Ja oder Nein nicht zu beantworten. Einige Dinge sind gleich, aber eben nur wenige. Beispielsweise in der Versicherungswirtschaft sind traditionelles Hosting und Cloud-Nutzung Ausgliederungen i.S. des VAG (Versicherungsaufsichtsgesetz). In beiden Fällen muss das Versicherungsunternehmen ein Ausgliederungskonzept erstellen.

Die Zusammenarbeit zwischen einem Hoster und einem Auftraggeber im Vergleich zu einem Cloud-Provider und einem Auftraggeber ist grundsätzlich unterschiedlich. Das Shared Responsibility Model macht den Unterschied zwischen Hosting und Cloud deutlich. 

Shared Responsibility Model oder der AWS „Supermarkt“

Werfen wir einen Blick auf das Geschäftsmodell und das Selbstverständnis der Hyperscaler. In diesem Fall auf AWS. Für die anderen Hyperscaler gilt Nachfolgendes gleichermaßen. 

AWS ist ein „Supermarkt“ für mich, wie REWE, EDEKA oder andere. Ich kaufe dort Lebensmittel ein und koche anschließend daheim. Wenn das Essen nicht schmeckt, machen meine Enkel nicht den Supermarkt verantwortlich, sondern mich oder meine Frau, je nachdem wer von uns am Herd stand. 

So ist es auch bei AWS: wenn ich auf Basis von AWS Services eine IT-Umgebung inkl. Anwendung baue und betreibe, dann bin ich in der Verantwortung, weil ich die Komponenten ausgesucht, konfiguriert und zusammengebaut habe. Nicht der Komponentenlieferant.

Wenn ich eine „schimmelige Tomate“ verarbeite, z. B. eine Konfiguration nicht ordentlich ausführe oder einen Service nutze, der noch Beta Status hat oder wenn ich z.B. das eingesetzte Linux AMI nicht zeitnah durch das runderneuerte Linux AMI ersetze, dann bin ich in der Verantwortung und eben nicht AWS.

Welche der > 200 AWS Security Services Sie einsetzen und welche nicht, ist Ihre Entscheidung, die Entscheidung der Köchin oder des Kochs. Die Verantwortung des Hyperscalers beschränkt sich auf die Erbringung der beschriebenen Leistung in den Service Terms und den SLAs. 

Das nennt man: Shared Responsibility. Dies ist die Grundvoraussetzung, um industriell gefertigte Cloud Services vollautomatisiert und ohne Providerinteraktion für Kunden bereitzustellen.

Das ist der entscheidende grundsätzliche Unterschied zw. Cloud Computing Services und Managed Services Hosting. Versuchen Sie mal mit AWS, Microsoft oder Google SLAs oder Service Terms zu verhandeln. Sie werden nichts erreichen, außer, dass man Ihnen vielleicht freundlicher sagen wird als: „Read the f*ing manual. Take it or leave it.“ Im Ergebnis ist es aber gleich. Der Cloud-Provider wird seine SLAs oder Service Terms nicht anpassen, nur weil Sie vielleicht ein DAX/M-DAX Unternehmen sind. 

Ein Managed Service Hosting Provider (neue Name für Outsourcing) dagegen schon. Allerdings nur gegen Einwurf kleiner Münzen und „größerer“ Scheine. Um im Bild des Supermarktes zu bleiben: Hosting ist Lebensmitteleinkauf und Zubereitung als kombinierte Dienstleistung im Gegensatz zur reinen Lebensmittel-lieferung des Hyperscalers.

Cloud: ‚Mainframe by other Means‘

Ein wichtiger Aspekt des Shared Responsibility Modells sind eben diese „harten“ SLAs und Service Terms. Ermöglichen diese doch erst die industrielle Fertigung von IT Services und Anwendungen. Damit einher gehen ungeahnte Möglichkeiten der Überwachung, des Monitorings, tlw. in Real-Time und vor allem eine lückenlose Protokollierung aller Vorgänge in der Cloud, auf die der Kunde zugreifen kann. Man muss es als Kunde aber auch tun!

Im Vergleich dazu hunderte eigene Hardwarekomponenten im eigenen Rechenzentrum, die man mühsam zusammenstöpseln muss und deren komplette, lückenlose Überwachung i.d.R. (fast) nie anzutreffen ist. Frei nach dem Motto: „Hauptsache es läuft. System Management wird überschätzt.“ 

Cloud Computing ist damit für die Unternehmens-IT eigentlich die Rückkehr zum klassischen Mainframe Konzept. Alles auf „einer Maschine“, lückenlose Dokumentation sämtlicher Zugriffe; wenn auch nun in einem technisch anders aufgesetzten Rahmen. 

Advanced Shared Responsibility Model

Die Idee des Shared Responsibility Models hat seine gedanklichen Ursprünge aus der Zeit, in der  man OLAs (Operating Level Agreements) diskutiert hat. 2002/2003 hatte ich die Überlegung, dass die Anwendungsentwicklung auf entsprechende IT-Produkte/Standards des on-prem RZ zugreifen können sollte. IT-Produkte/Standards analog aufgebaut und in Sync zur IT-Kostenleistungsverrechnung (siehe Blog No. 3). Das haben wir damals leider nicht durchgängig hinbekommen. Der manuelle Installationsanteil war einerseits zu groß und anderseits war der Mindset der IT-Admins damals noch mehr der eines „Künstlers“ als der eines „Fließbandarbeiters“. Jeder Server wurde damals mehr oder weniger persönlich „begrüßt und an den Platz begleitet“, sprich ins Rack eingebaut und installiert.

Heute gibt es andere Voraussetzungen durch die Cloud. Warum sollte man in der Cloud weiterhin das machen, was Admins so machen? Was spricht eigentlich dagegen von AWS zu lernen und das Shared Responsibility Model zu erweitern? Nichts!

Bottom Line

Das Shared Responsibility Modell ist die Grundlage zum Verständnis des Hyperscaler-Konzeptes. Man muss es verstanden haben, wenn man das Thema Compliance und Security in der Cloud bewerten will. Das ist Grundvoraussetzung.

Compliance First, Security Second, Anwendung Third ist der Ansatz, den jeder Hyperscaler-Nutzer verinnerlichen sollte, nicht nur in der Versicherungswirtschaft. IT Compliance Anforderungen werden weiter zunehmen, ob GDPR oder IT-Sicherheitsgesetze.

Es gilt immer die Eigenverantwortung für das, was man wie nutzt. Verantwortung kann man weder auslagern (liebe Banken), noch ausgliedern (liebe Versicherer) noch outsourcen (liebe Provider).

******

*) Mit Cloud meine ich immer nur Hyperscaler wie AWS, Azure, GCP oder Cloud-Provider, die die NIST SP 800-145 Norm vollständig erfüllen.

Ich habe heute den #Serverless Summit 2021 ( https://lnkd.in/eZNiBmft ) besucht. 📢 Neue Erkenntnisse:

#Kubernetes braucht niemand mehr: „You can definitely go fully serverless in realworld“ wie Kurt Lee mit seiner Präsentation "Going fully serverless in real world" eindrucksvoll am Beispiel www.vingle.net und www.catchfashion.com gezeigt hat.🥇🥇🥇

Java und C# gehören aufs Altenteil, zumindest im Serverless Umfeld. Cold Start Lambdas mit diesen Programmiersprachen machen einfach keinen Spaß. Da nimmt man doch lieber JS, Python, Go oder Rust 👍

📢Das DevOps Team ist tot, es lebe das OpsTeam.

#AWS #Stepfunctions goes NoCode. 👍 In Kombination mit #QuickSight, #Honeycode, S3 Static Website und anderen Teilen des AWS Universums wird das spannend werden zu sehen, wie das mal zu einer No Code Plattform zusammenwächst. Kommt nicht? Hhmm, #Microsoft macht es gerade vor mit der #powerplatform Family (siehe #Ignite in der letzten Woche)

Jetzt kommt natürlich sofort das Argument: Vendor Lock-In! 😱Man müsse #cloudagnostic sein. Muss man sich aber leisten können. 90% Kosteneinsparungen mit serverless gegenüber EC2 (siehe Kurt Lees Vortrag). 90% Einsparungen sind übrigens realistisch, wie ich aus eigener Erfahrung bestätigen kann.

Nicht das #Kubernetes Fans jetzt in Depressionen verfallen…😨😉

Vielen Dank an die Panelisten: Darko Mesaroš, Ben Ellerby, Alex Casalboni, Marek Kuczyński, 🌤 Farrah Campbell – Ich habe viel gelernt. Vielen Dank! 👍👍👍

Eine wirklich gelungende Veranstaltung 🥇🥇🥇 und dazu auch noch kostenfrei. Morgen (18.11.2021) ab 16:00 findet Teil 2 statt. Ich kann es nur empfehlen...

Wenn CapEx durch OpEx (fast) vollständig ersetzt wird – und das ist der Fall bei konsequentem Cloud Einsatz – dann werden alle traditionellen IT- und Projekt-Budget-Prozesse auf den Kopf gestellt. Weder das Controlling noch die Rechnungsleger sind i.d.R. darauf vorbereitet. Konsequente, flächendeckende Einführung von Cloud Computing kann durchaus im ersten Anlauf daran scheitern, dass das Controlling und die Rechnungsleger ihr Veto einlegen. Schließlich will der Vorstand seine Ergebnisse präzise planen und mit einer ausgewogenen Bilanz präsentieren, insbesondere wenn das Unternehmen börsennotiert ist. Nicht jeder IT-ler hat das auf dem Radar. 

Der IT-Budget-Jahresplanungsprozess

Welcher IT-Leiter kennt das nicht: Im März eines Jahres fängt man die IT Budget-Planung für das nächste Geschäftsjahr an. Jedes Jahr aufs Neue muss „die IT“ wieder etwas planen, von dem sie gar nicht weiß, ob das kommt bzw. relevant ist. Dies betrifft insbesondere Projekte für neue Anwendungen. Als ein „Stochern im Nebel“ empfand ich das immer, während meiner Zeiten als IT-Leiter. Der Planungsprozess beschäftigt eine Menge von Mitarbeitern und kostet viel Zeit und meist ist der tatsächliche Ablauf von Projekten im Folgejahr völlig anders als geplant. 

Nun gut, die Geschäftsleitung will, dass die Zahlen am Ende des Jahres stimmen. Welcher CEO oder CFO hat schon Lust auf einer Bilanz-Pressekonferenz IT-Zahlen bei Abweichungen zum Plan erklären zu müssen. Natürlich keiner! Also fügt man sich zwangsläufig in die „Inquisitionsmühlen“ des Controllings.

Aber wer kann im März eines Jahres schon planungsgenau vorhersagen, was bis zum Dezember des Folgejahres an Innovationen zu finanzieren ist? „Kein Problem“, meint mein langjähriger Weggefährte Bernd Oster. „Jeder dessen IT-Budget zu 90% durch Wartungskosten und Ersatzinvestition gebunden ist und keinen finanziellen Rahmen für Innovationen hat, macht das mit links!“ Er hat Recht! Genauso ist es! 

Neue Herausforderungen im IT-Budget-Planungsprozess

Cloud legt hier noch ein paar Scheite mehr ins Feuer. Bei Cloud Nutzung werden die bisherigen (on-prem) Planungs- und Controlling-Prozesse auf den Kopf gestellt. Das pay-as-you-use Konzept stellt eine Organisation vor neue Herausforderungen. Neben Accounting und Controlling auch die IT-Einkaufsabteilung. Fragen wie: „On-demand, Reserved oder Spot Instanzen? Mit oder ohne SavingsPlans? Welche Datenbank auf EC2 oder RDS oder doch lieber serverless?“ können von keinem der Beteiligten zum Planungszeitpunkt (März d. VJ.) seriös beantwortet werden. Eine verbindliche Festlegung wäre zu diesem Zeit nicht nur contra-produktiv sondern sogar anti-innovativ! (Dabei wollen doch alle immer Innovatoren sein. 🤔)

Die Fragen kann man nur gemeinsam beantworten, Fachabteilung und IT-Abteilung, aber nicht im Planungsprozess selbst, sondern erst bei der konkreten Planung/Implementierung der Anwendung, also zeitlich irgendwann im Planungsjahr selbst. Wie kommt man aus dieser Zwickmühle heraus? Es geht kein Weg daran vorbei ein IT-Eventualbudget festzulegen - was Controller gar nicht lieben.

Im Zielbild, wenn also Cloud flächendeckend genutzt wird, „mutiert“ der  IT-Kostenplanungsprozess zum Planungsprozess der Fachabteilung. Nur die Fachabteilung kann sagen wie das Geschäft sich entwickeln soll und was das für die Anwendungen bedeutet (z.B. Anzahl neuer Kunden, Anzahl Rechnungen, etc.). Dies gilt sowohl für bestehende als auch für neue Anwendungen in der Cloud. Wenn sich die Annahmen der Fachabteilung als falsch erweisen, ändern sich auch die Kosten. Hm, ist das jetzt gut oder schlecht? Auf jeden Fall ist es eine neue und ungewohnte Situation.

Die IT-Abteilung kann nicht mehr vorplanen wie bisher, sondern kann nur zuarbeiten, wenn die Fachseite eine konkrete fachliche Planung vorlegt. „Die Cloud“ mit dem pay-as-you-use Konzept dreht den bisherigen IT-Budget-Jahresplanungsprozess völlig auf den Kopf.

Während der Jahresplanung meldet sich der IT Einkauf

Der IT-Einkauf will natürlich Lizenzen, Wartungsverträge, Berater-Kontingente, etc. mit den Lieferanten verhandeln, gerne auch im Vorfeld, um beste Konditionen auszuhandeln. Auch mit AWS, Microsoft und Google. 

Die erste Ernüchterung des IT-Einkaufs: SLAs kann man mit den Cloud Providern nicht verhandeln, im Gegensatz zu traditionellen Hostern. „Ok, dann machen wir was am Preis!“ ist dann meist die nächste Reaktion des IT-Einkäufers. Fixe, garantierte Abnahmeverpflichtungen finden Cloud Provider immer gut, so meine Erfahrung. 

„Lustig“ wird es dann meist bei einer Dual Cloudstrategie. Ein fiktives Beispiel zu Illustration: Microsoft ist der preferred Cloud Provider, AWS die Alternative. Der Einkauf verpflichtet sich im nächsten Jahr eine ordentliche Menge an Azure Consumption verbindlich und fest zu konsumieren. Dafür bekommt man einen guten Rabatt. Mit AWS wird ein kleineres Kontingent vereinbart. Alles findet im laufenden Jahr statt und betrifft das kommende Jahr. Im nächsten Jahr passiert Folgendes: Die AWS Consumption geht durch die Decke, aber die Azure Consumption bleibt auf Vorjahresniveau.

Bei einer solchen „Gefechtslage“ kommt es sofort zum berühmten Finger Pointing. Was niemanden hilft, nur Nerven kostet und das eigentliche Problem nicht löst, nämlich das Zusammenspiel zwischen Fachabteilung, IT und IT-Einkauf unter Cloud Bedingungen.

Mein Lösungsvorschlag: Nur das als festes Kontingent einkaufen, wo man absolut sicher ist, dass das auch wirklich verkonsumiert wird. Im Jahresablauf selbst alle vier Wochen nachsteuern z.B. mit Reserved Instanzen oder mit neuen Savingsplans.

IT Kostenleistungsverrechnung

Bei Cloud Nutzung sieht die Welt anders aus als on-prem. Ein Beispiel aus der Praxis: 

Für 10.000 USD AWS Consumption erhalten Sie von AWS ca. 2,2 Mio. Abrechnungsdatensätze. Detaillierter geht es kaum und es ist lückenlos. Da man bereits den „gesharten“ Anteil berechnet bekommt, vereinfacht sich einerseits die Zuordnung zum Verursacher, anderseits stellt sich die Frage: Was kann man aus diesen Abrechnungsdaten noch ablesen?

Wie richtet man das IT Controlling in diesem Umfeld neu aus? Ein einfaches Beispiel: Welche EC2 (Server) Instanz soll ich nutzen? INTEL Architektur (z.B. t2.xlarge) oder INTEL kompatibel mit AMD (z.B. t3a.xlarge) oder darf es vielleicht ARM Architektur sein (z.B. r6g.xlarge)? Die IT Ressourcen sind ziemlich ähnlich und gut einsetzbar für Java Anwendungen. Der wesentliche Unterschied liegt im Preis: tlw. 42% geringere Kosten. 

Das nächste Zuordnungsproblem sind Gutschriften und Rabatte. Wie werden diese den einzelnen Anwendungen zugeordnet? Wie kann ich dafür sorgen, dass z.B. der Rabatt für die Reserved Instances tatsächlich derjenigen Anwendung – und damit auch der richtigen Fachabteilung – zugutekommt, die dauerhaft im Betrieb sind?

Man erkennt sehr schnell, dass sich das IT Controlling stark verändern wird. IT Controlling greift u.a. in Hardware und Software Architekturen ein. Aber nicht nur. Dazu mehr in einem kommenden Blog zum Thema Cloud Governance Cycle.

Projekte

Bottom Line

Flächendeckender Einsatz von Cloud Computing verändert sämtliche IT-Budget-Prozesse:

• Budgetplanungsprozesse,

• Kostenleistungsverrechnung, 

• Projektplanungen.

Auch das Thema Abschreibung oder Aufwand wird davon massiv betroffen, aber dazu demnächst mehr in einem kommenden Blog.

IT Controlling umfasst zukünftig mehr als nur Zahlen.

Der Anbieter- und der Anwendermarkt wird sich, wg. der industriellen Fertigung von Infrastrukturen und Anwendungen, komplett neu aufstellen müssen. 

Kein Stein bleibt auf dem anderen. Die Industrialisierung der IT nimmt ihren Lauf. Es erinnert manchmal an Gerhard Hauptmanns Roman Die Weber (1892), nur sind heute die IT Admins (und nicht nur die), die Weber dieses Strukturwandels. 

***************************************

*) Mit Cloud meine ich immer nur Hyperscaler wie AWS, Azure, GCP oder Cloud-Provider, die die NIST SP 800-145 Norm vollständig erfüllen.

Eine solche oder ähnlich formulierte Frage bekomme ich häufiger zu hören. Meist noch angereichert mit dem Hinweis: „Das soll ja billiger sein.“ Es gibt sicherlich mehrere Gründe in ‚die Cloud‘ *) zu gehen. Kosten einsparen zu wollen ist dabei m.E. der Grund mit der größten Motivation. Das Kostenargument ist allerdings kein guter Grund „in die Cloud" zu gehen. Es kann durchaus auch teurer werden als on-prem. Es kommt immer auf den Einzelfall an: Welche Anwendungen betrifft es und wie werden diese in der Cloud betrieben. Es gibt aber andere, triftigere Gründe „in die Cloud zu gehen".

It’s all about Pace of Innovation, neither Technology nor IT Operation

Die Geschwindigkeit mit der AWS, Microsoft und Google - Monat für Monat aufs Neue - ihre Cloud Plattformen mit technologischen Innovationen erweitern, ist mehr als beeindruckend. Technologische Innovationen können langjährig erfolgreiche Geschäfts-modelle ganzer Branchen innerhalb kurzer Zeit zum Einsturz bringen. Jedem fällt dazu mittlerweile ein Beispiel ein.

Bei allem Respekt vor dieser Innovationsgeschwindigkeit sollte man allerdings nicht vergessen mit welchem Mindset die drei Anbieter ihre Plattformen entwickeln. Die Ansätze unterschieden sich deutlich und haben unterschiedliche Historien. In diesem Beitrag befasse ich mich mit AWS. „Go Build“ ist ein Motto von AWS, das gerne gezeigt wird. Vom ‚Builder‘ für den ‚Builder‘, wenn man so will. Wobei ‚Builder‘ nicht etwa nur für den ‚Entwickler‘ steht, sondern auch für den ‚Geschäftsmodellbauer‘. Business/IT-Alignement as it’s best: Technologie als integraler Bestandteil eines Geschäftsmodells.

Entsprechend ist der AWS „Baukasten" wie ein Lego-System konzipiert. Man kann viele kleine Teile/Komponenten immer wieder anders zusammensetzen und bekommt damit neue Infrastrukturen und Anwendungen.**)

Innovationsbeispiel 1 – „Traditional database comes to an end“ (2018)

In der Keynote von Werner Vogels zur re:invent 2018 verkündete dieser „Traditional database comes to an end“ und warf u.a. diese Folie an die Wand:

Die Idee des relationalen Datenbank Modells wurde einfach „zertrümmert“. Das relationale Datenbankmodell, das für viele die Datenbanktechnologie der Wahl war, war plötzlich nicht mehr als fester Faktor einer Anwendungsarchitektur gegeben, sondern massiv in Frage gestellt worden. Aus Performance-, Skalierungs-, Security- und Kostengründen seien jetzt Special Purpose Databases einzusetzen, so #Werner Vogels. Und er hat Recht, wenn man sich intensiver mit diesem Thema beschäftigt, dann stimmt man ihm zu. Schließlich wissen wir, aus Untersuchungen und eigener Erfahrung, dass der nächste Anbieter nur einen Klick entfernt ist, falls denn die Performance zu Lieferzeiten mutiert. Relationale Datenbanken at Scale sind eben langsamer in der Performance als Special Purpose Datenbanken.

Seit den 70er Jahren dominierte das relationale Datenbankmodell, weil Speicherplatz damals extrem teuer im Vergleich zu CPU war. Da heute Speicherplatz deutlich weniger als CPU kostet, sind Special Purpose Datenbanken auch wirtschaftlich attraktiv.

Ein Snapshot aus 2018 zeigt die reichhaltige Auswahl bei AWS.

Performance, Skalierung, Security und Kosten sind in digitalen Geschäftsmodellen schlicht kritische Erfolgsfaktoren. Es ist sinnvoll sich die am besten geeignete Datenbank für seinen Use Case auszusuchen und nicht mehr stoisch am relationalen Datenbankmodell festzu-halten.

Innovationsbeispiel 2 – AWS Nitro (2019)

Auf der re:invent 2019 stellte #Werner Vogels die letzte Stufe der AWS Nitro Entwicklung mit den Worten „Game Changer“ vor. Fünf Jahre wurde daran gearbeitet den Hypervisor neu zu erfinden. Es hat sich gelohnt einen in Hardware „gegossenen“ Hypervisor zu entwickeln. Die Vorteile dieses Hypervisors sind offensichtlich: deutlich besseres Preis-/Performance-verhältnis, verbesserte Security und deutlich schnellere Entwicklung von neuen EC2 Servertypen. Es kommt noch ein weiterer Vorteil hinzu: Hardware kann man patentieren lassen, Software nicht. Ich bin gespannt, wie die AWS Wettbewerber damit auf Dauer umgehen werden. Aus eigener Erfahrung kann ich berichten, dass man bis zu 40% AWS EC2 CPU Kosten einsparen kann. 

Innovationsbeispiel 3 – KI Services (2020)

Auf der re:invent 2020 stellte Swami Sivasubramanian, VP Machine Learning AWS in seiner Keynote neuen KI Services von AWS sehr eindrucksvoll vor.

Heute hat man die Möglichkeit selbst zu entscheiden, ob man ein Amazon Machine Image (AMI) mit z.B. PyTorch in seiner VPC deployed oder ob man nicht doch lieber einen ready-to-use KI-Service (wie z.B. Recognition) nutzen will.

Schneller und einfacher kann man KI nicht einführen. Man muss es nur mal ausprobieren und ernsthaft anfangen. Gleich wohl bleibt natürlich bei der Einführung von KI im Unternehmen noch genug zu tun. Dies sind i.d.R. aber keine technische Problemstellungen, sondern kulturelle und organisatorische.

Insbesondere wird gerne Compliance vorgeschoben, dass man KI Services „in der Cloud“ nicht nutzen könne. Dem entgegne ich: „Doch man kann KI Services einsetzen! Man muss den Einzelfall betrachten und vor allem muss man die Compliance-Anforderungen auch kennen, nicht nur vom Hörensagen. Es gibt immer einen Weg, schließlich besteht die AWS Cloud aus Lego-Steinen!“

Bottom Line

Der Antrieb Kosten einsparen zu wollen ist oftmals der erste Ansatz sich mit dem Thema Cloud Computing zu beschäftigen. Man kann damit sehr erfolgreich sein, wenn man stark volatile Anwendungen hat, die viel CPU und Speicher brauchen, wie z.B. bei der Berechnung von Risikomodellen für Banken und Versicherungen.

Es gibt nur einen Grund das heimischen Rechenzentrum zu verlassen und in „die Cloud“ umzuziehen: Die Geschwindigkeit der Entwicklungen technologischer Innovationen. 

Unternehmen müssen heute die Möglichkeit haben ihre Geschäftsmodelle schnell, einfach und kostengünstig anzupassen oder diese neu zu erfinden. „Wer zu spät kommt, den bestraft das Leben“ wie Michail Gorbatschow schon sagte. Das gilt erst recht in der Technologie.

"Das on-prem Rechenzentrum ist ein Auslaufmodell.", sage ich als ehemaliger, bekennender Serverstreichler.

**********************************

*) Mit Cloud meine ich immer nur Hyperscaler wie AWS, Azure, GCP oder Cloud-Provider, die die NIST SP 800-145 Norm vollständig erfüllen.

**) Jeff Bezos wurde lt. Brad Stone, Autor des Buches The Everythingstore durch Steve Grand, Autor des Buches Life and How to Make It inspiriert modulare Buildingblocks für AWS zu entwickeln

Wie alles anfing oder warum ich ein Cloud Fan wurde, möchte ich hier mit einer kleinen Theaterszene darstellen.

Szene:              Ein Problem liegt auf dem runden Tisch
Problem:          Das Rechenzentrum des Unternehmens kann keinen 24x7 Betrieb für das „Einsammeln von

                          Finanzdaten“ gewährleisten
Ort:                   In der Holding eines Versicherungskonzerns
Mitwirkende: Chef (CIO), Kollege (Head of Infrastructure), ich (Demand Manager)

Es sei angemerkt, alle handelnden Personen sind frei erfunden, Ähnlichkeiten zu lebenden Personen sind zufällig.

Chef: „Und was machen wir jetzt?“ 🤨😟

Ich: „Alle reden von ‚der Cloud‘. Lasst es uns ausprobieren!“ 😎

Kollege: „Du darfst nicht in ‚die Cloud‘!!“😦

Ich: „Warum nicht?!“ 🤔

Kollege: „Wegen § 203 StGB *).“ 😧

Ich:🙄 „Kollege, ich bin die Holding! Ich habe keine Kunden. Ich habe nur Gesellschaften! 🤣

Kollege: 😡 „Cloud ist unsicher!“

Ich: „Du kaufst doch bei Amazon (Retail) deine Laufschuhe. Hast du jemals mit deinem Account eine EC2 Instanz gemietet und hochgefahren?“🤨

Kollege: „Nein.“😯

Ich: 🙄„Ok, du warst noch nie in der Cloud und hast keine Ahnung. 🤷‍♂️ Außerdem geht es nur um eine Anwendung. 😐 Lasst es uns einfach ausprobieren und machen.“ 😣

Chef: 😌 „Ok, aber es muss ordentlich vorbereitet und die Compliance muss eingehalten werden.“ 🤫

Die Stimmung am Schluss: Chef: 👍- Kollege: 😠 - Ich: 😎

So oder so ähnlich hätte der Start in die Praxis meiner Cloud Journey aussehen können. - A.D. 2010 😉

Bottom Line:
Wenn Sie ein Cloud Projekt starten wollen und Cloud Computing ist noch nicht Mainstream in Ihrem Unternehmen, dann
-  holen Sie sich die #Governance,
-  lösen Sie ein Problem und minimieren gleichzeitig das #Risiko für Ihren Chef,
- und kümmern Sie sich selber aktiv um #Compliance Themen. Überlassen Sie es nicht andern, schon gar nicht Stabsfunktionen.

Die Governance, Risk und Compliance Deutungshoheit ist von entscheidender Bedeutung, wenn Sie eine Cloud Journey in Ihrer Unternehmensorganisation starten und erfolgreich umsetzen wollen.

Am kommenden Montag erscheint mein Blog zum Thema: „Warum soll ich in ‚die Cloud‘ gehen?“
*************************************************************************
*) § 203 StGB Verletzung von Privatgeheimnissen (deutsches Strafgesetzbuch)
„Wer unbefugt ein fremdes Geheimnis, namentlich ein zum persönlichen Lebensbereich gehörendes Geheimnis oder ein Betriebs- oder Geschäftsgeheimnis, offenbart [u.a. Mitarbeiter von Unfall-, Kranken- und Lebensversicherungen]…wird mit Freiheitsstrafe bis zu einem Jahr oder mit Geldstrafe bestraft.“

Der Begriff Cloud Computing wird inflationär verwendet. Alles ist „in der Cloud“. Niemand, insbesondere IT-ler gestehen selten ein, dass das alles „ganz schön nebelig ist“. Niemand will sich die Blöße geben, dass er/sie nicht weiß was das eigentlich ist: Cloud Computing. Und was sich dadurch alles verändert bzw. verändern wird. Wer braucht schon Wolken, wenn man Sonne haben kann.

Im Nachfolgenden ein Versuch den Nebel um Cloud Computing zu lüften.

Definition Cloud Computing *)

„Cloud Computing sind doch Server nur woanders“ hört man häufig, wenn man danach fragt, was Cloud Computing eigentlich ist. Kann man so sehen, ist es aber nicht. Cloud Computing ist ein fundamentaler Paradigmenwechsel, wie man Infrastrukturen und Anwendungen baut und betreibt.

Im Sept. 2011 hat die amerikanische Normierungsbehörde NIST bereits eine Definition zum Cloud Computing herausgegeben. Bereits? Nun ja, 5 Jahre nachdem AWS im Jahre 2006 das Licht der Welt erblickte, gab es also eine erste Definition. Die allerdings so gut ist, dass sie auch noch heute (2021) trägt. 

Die Abbildung zeigt die Definition der NIST SP 800-145 auf einen Blick. Man kann trefflich stundenlang darüber diskutieren, was das im Einzelnen für jedes einzelne technische Level bedeutet. Ob das technisch überhaupt möglich ist, etc. Der Stack kann gerne erweitert werden. Wie auch immer, in den nächsten Abb. sind die Essential Charteristics der NIST SP 800-145 aufgelistet.

Cloud Computing Time Line

Festzuhalten bleibt, dass AWS seit 2006, Azure seit 2010 (m.E. einsetzbar ab 2013) und Google seit 2011 Cloud Services im Markt anbieten, die diese Charakteristiken auch erfüllen. Selbstbedienung vom Feinsten: immer schneller, immer preiswerter und (zum Glück) kein Servicepersonal mit denen ich reden muss, um einen Service in Produktion zu setzen.

Industrielle Fertigung vs. Handwerk

„Cloud“ Provider, die ich erst fragen muss, um Services in Produktion zu setzen, sind keine Cloud Provider! Diese Art „Cloud“ ist traditionelles Hosting. Nicht mehr und nicht weniger. Gegen Einwurf kleiner und großer Münzen werden auch Sonderlocken implementiert. Traditionelles Hosting ist Handwerk. Jedes Werkstück ist ähnlich, aber nicht gleich. Jedes Mal bauen Handwerker das Werkstück neu, wobei sie schon Maschinen nutzen, aber eben nur manchmal. Viel Handwerk und keine vollständige Automation des Herstellungsprozesses.

Cloud Computing ist die vollständige industrielle Fertigung von Infrastruktur und Anwendung.

Infrastructure-as-Code heißt hier die Zauberformel. Man kann die vollständige Automatisierung des Deployments und des Betriebes von Anwendungen erreichen. Die Qualität des Betriebs steigt. Die Kosten sinken. Hat man Landing Zone Modelle entwickelt, in denen Anwendungen lauffähig betrieben werden können, erreicht man sogar den Punkt von Zero Marginal Cost für das Deployment einer neuen Umgebung. Der CFO wird es danken.

Bottom Line

Cloud Computing ermöglicht eine radikal andere Vorgehens- und Arbeitsweise beim Deployment und Betrieb im Vergleich zum traditionellen Rechenzentrum. Die Betonung liegt auf der industriellen Fertigung mittels Infrastructure-as-Code.

Nicht jeder IT-Admin wird das mögen. „Wenn der Wind weht, sollte man Windmühlen bauen und keine Mauern“ besagt ein altes Sprichwort. Das gilt auch hier. Cloud Computing ist so ein Wind, der alle Mauern einreißen wird früher oder später. Und nicht nur in der Infrastruktur. Aber davon später mehr…

*******************************

*) Mit Cloud meine ich immer Hyperscaler wie AWS, Azure, GCP. Cloud-Provider, die die NIST SP 800-145 Norm vollständig erfüllen.

Was für eine scharfe Idee ist das denn: Eine Cloud Ausfallversicherung für #AWS, #Azure, #GCP und andere auf den Markt zu bringen! https://lnkd.in/e_ZmSKK4

Warum bin ich noch nicht selbst darauf gekommen!💡 Denn diese Versicherungsidee wird wahrscheinlich sogar Erfolg haben, obwohl sie eigentlich niemand braucht.💰💰💰

Wer sowas abschließt, der hat ein massives Problem mit seinen Admins. Die haben dann im Zweifelsfall noch nicht verstanden, dass sie, die Admins, dafür verantwortlich sind, wie sie ihre Infrastrukturen und Anwendungen bauen müssen, damit diese im K-Fall überstehen können.

Der Koch (die Anwender-Admins) ist verantwortlich für das Menü, nicht der Supermarkt (#AWS & Co.)!

Cloud ist eben noch Neuland, wie das Internet. 😉

In diesem Jahr ist viel passiert, u.a. bin ich bei Novum-RGI von der CTO-Rolle zurückgetreten, um mich mehr um das Coaching von Startups zu kümmern. Dieses Jahr kamen zwei neue Startups dazu.

Bei Workshops und beim Coaching habe ich immer wieder alte Folien aus meiner Talanx Zeit aufgelegt. Immer noch so aktuell, dass Teilnehmer daraus neues Wissen ziehen konnten.

Auch meine Folien vom AWS Summit 2014 in der Keynote von Werner Vogels kommen immer noch zum Einsatz. Nach diesem Vortrag kamen viele englischsprechende Menschen auf mich zu und meinten unbekümmert, dass ich ja viel jünger im Kopf sei, als ich aussehen würde. 😎 Zur Einordung, ein Kollege und ich waren damals die Einzigen, die Anzug und Krawatte trugen - neben der Security.👨‍💼

Werner meinte damals dazu nur: „That’s a good payoff.“ und lachte. Stimmt, es hat mich 10 Jahre jünger gemacht und es hält bis heute an, Werner! 👍

Adrian Ballosch, einer meiner Coachees meinte auch noch: „Warum bloggst Du eigentlich nicht?! Ich habe so viel gelernt von Dir.“ (Danke für die Blumen, Adrian)

Jetzt fange ich damit an. 📢 Immer montags werde ich unter dem Motto "Clearing The Fog"  LinkedIn Artikel zum Thema #Compliance & #Cloud veröffentlichen.📢 Nächsten Montag geht es los. Ich bin gespannt, wohin mich das noch führen wird….👋