▶️ Digitale Souveränität - Warum Backup der einzige Weg aus der SaaS-Falle ist

Wir in der IT feiern unsere "Cloud First"-Strategien und wiegen uns in Sicherheit, weil unsere Verträge uns "Ownership" an den Daten zusichern. Doch wenn der Stecker gezogen wird – sei es durch technische Ausfälle, geopolitische Spannungen oder eine gesperrte Kreditkarte – offenbart sich die brutale Wahrheit: Wir haben zwar Eigentum, aber keinen Besitz. Wir sind Mieter im eigenen Geschäft, und der Vermieter hat die Schlösser ausgetauscht.

Digitale Souveränität bedeutet nicht, keine Cloud zu nutzen. Sie bedeutet, jederzeit die Wahl und die Fähigkeit zu haben, den Anbieter zu wechseln oder weiterzumachen, auch wenn die Cloud nicht mehr da ist.

Im folgenden Video-Vortrag entlarve ich die "Souveränitäts-Illusion" moderner IT-Architekturen. Du erfährst, warum SaaS-Dienste technisch oft "No-Restore"-Umgebungen sind und warum regulatorische Compliance (DORA, NIS2) noch lange keine echte Handlungsfähigkeit garantiert.

Der Lösungsansatz ist überraschend pragmatisch: Wir bei Tektit nutzen klassische Backup- und Disaster-Recovery-Methoden nicht nur für den Notfall, sondern als strategisches Werkzeug zur Rückgewinnung unserer Datenhoheit. Wir zeigen konkrete Architekturen, wie man Daten aus der SaaS-Falle befreit ("Data Jailbreak"), sie neutralisiert und in den eigenen "Besitz" überführt – idealerweise auf eigene Server oder unabhängige Infrastrukturen.

Schau Dir diesen Vortrag von der SLAC 2026 an, er ist ein Weckruf für alle, die nicht nur glauben wollen, dass ihre Daten sicher sind, sondern es wissen müssen. Zum Querlesen findest Du das Transkript mit den wichtigsten Folien unter dem Video. In der Liste meiner Publikationen findet Ihr die Folien und alle weiteren Vorträge.

https://www.youtube.com/watch?v=BGShQwBkdww

(Gemeinsame Veröffentlichung mit meinem persönlichen Blog unter schlomo.schapiro.org)

Wir bei Tektit Consulting unterstützen Euch gerne bei der Entwicklung Eures eigenen SaaS-Data-Jailbreaks und begleiten Euch auf Ihrem Weg zu mehr Datensouveränität. Lasst uns gemeinsam mit einer kurzen SaaS-Backup-Analyse starten, um Eure individuelle Roadmap zu entwickeln.

---

Transkript mit Folien

Schlomo Schapiro: [00:00:00] Digitale Souveränität ist mehr als ein Stück Papier und der Weg aus der SaaS-Falle ist einfach Backup und Disaster Recovery. Und ich möchte euch heute ein bisschen erzählen, warum dieses riesengroße Thema gar nicht so weh tut und wie wir beim Umgang mit SaaS ein klein bisschen unseren Fokus auf die nicht-funktionalen Anforderungen legen, um damit fundamentale Probleme und Herausforderungen für unsere Firmen und Organisationen zu lösen. Und tatsächlich ihnen zu helfen, SaaS sinnvoll zu benutzen, ohne alles auf eine Karte zu setzen, ohne nur die Risiken zu haben. Also mein Ziel ist tatsächlich: SaaS nutzen, ohne es zu bereuen nachher. Weil ich glaube tatsächlich, man wird SaaS nicht los und ich zeige auch gleich noch ein paar Gründe, warum SaaS seine Daseinsberechtigung hat und es ist halt da.

[00:00:56] Ganz kurz, ne: Wir lieben SaaS. Also ich mag tatsächlich SaaS. Ich habe keinen Bock mehr auf „Ich muss immer Admin sein“, habe ich lange genug gemacht und irgendwann will man nicht mehr. Kleine Intro: Backup, Disaster Recovery. Ist wirklich nur eine kleine Intro, es geht um die anderen Sachen dann natürlich.

[00:01:21] Falle: SaaS ist eine Falle, wie kommen wir raus? Data Jailbreak so als Buzzword. Und ganz wichtig: Ich möchte euch mit dem Konzept einer Minimum Viable Company vertraut machen. Also was ist eigentlich der Kern eures Unternehmens, auf den es ankommt? Und natürlich dann ein Masterplan hier: Wie kommen wir denn jetzt weiter? Was machen wir morgen? Was könnt ihr morgen... okay, vielleicht Montag nach den Feiertagen... was könnt ihr Montag machen und damit sicherstellen, dass ihr halt die richtigen Dinge tut, die richtigen Dinge anstupst?

[00:01:58] Also wir brauchen SaaS. Und ja, ich glaube an SaaS. Ich habe lange genug Admin gemacht und das ist ein toller Job. Und als ich dann zu ImmoScout ging, habe ich plötzlich gemerkt, ich muss bei Kunden nicht mehr erzählen, wie geile IT funktioniert, indem ich per VPN in meinen Keller gehe und dort meinen Server vorführe. Weil ich hatte halt bei ImmoScout da ein Rechenzentrum statt einem Server. Und bin damals mit meiner privaten IT komplett zu Google gegangen, Google Workspace – also G Suite damals, gab es noch gratis. Habe damit den kompletten E-Mail, PIM, Groupware, alles Stack, der bei mir im Keller lief (inklusive DNS halt) entsorgt und es nie bereut, weil extrem viel Zeit gespart. Ich war auch schon in der Legacy Falle, das war damals noch SLES 10. Ich habe die Updates natürlich bis zum bitteren Ende ausgesessen. Und wer die alte Welt noch kennt, dann auf SLES 11... das ist halt nicht so einfach, da musste man viel umbauen und es war auch noch big und relativ komplex natürlich. Alles Handbetrieb, weil ich war damals auch nicht so modern mit Automation, ne. Die T-Shirts habe ich erst vor so 10 Jahren angefangen zu drucken, das ist alles schon 20 Jahre her bald.

[00:03:14] Und ich stehe zu der Entscheidung und für meine Familie war der Wechsel zu Google Workspace genau richtig. Und sozusagen, wir haben von dem SaaS-Ding unendlich profitiert. Erstmal habe ich 10, 15 Jahre das gratis bekommen (G Suite 10 User gratis) und als es dann anfing Geld zu kosten, habe ich gerne dafür bezahlt, weil es sich lohnt. Das Geld ist viel weniger, als was ich sonst in Admin von einem eigenen Stack investieren würde und damit lohnt sich das für mich immer noch. Und ich erzähle jetzt über meine Familie als Beispiel, aber ihr könnt auch auf Heise noch nachlesen: G Suite nicht mehr gratis? Hört auf zu jammern, Google macht das beste Angebot. Das hat damals einen Riesen-Aufschrei verursacht.

[00:03:59] Und ich glaube, mein persönliches Beispiel ist nur stellvertretend für das, was in den meisten Unternehmen auch stattfindet. Nämlich: Man kann die Aufgaben in der IT nicht mehr alleine mit ein, zwei Admins im Keller bewältigen. Also beim besten Willen, man kann es nicht mehr. Das heißt wir, ne, sind hier dieser Dude – wir werden halt auch hofiert von den SaaS-Anbietern. Die geben sich Mühe und sie machen das gut. Und am Ende haben wir auch was davon, also ist irgendwie schon eine Win-Win Geschichte.

[00:04:33] Mal so ein Beispiel, was wir wollen, so ein ganz banales Beispiel ist: Wir wollen ein fliegendes Auto, ne? Wer will das nicht? Also ich will ein fliegendes Auto, ich hasse Autofahren, ich hasse im Stau stehen, ich hasse diese Stunden auf der Autobahn. Ich hätte gern das fliegende Auto, ist total geil, mein Traum auch, genau in der Keep-It-Simple Version. Ja. Die Realität ist natürlich, wenn man das selber bauen würde, säh es ungefähr so aus: ein bisschen stressig, ganz viel Arbeit (ne, die schwitzen alle) und ist irgendwie hochgradig kompliziert. Weiß nicht, habt ihr mal Laputa gesehen? So ein japanischer Zeichentrickfilm über so eine fliegende Stadt. Ja, das ist so in dem Stil und die arbeiten alle wie verrückt, aber sie haben eine fliegende Stadt.

[00:05:22] Die SaaS-Wirklichkeit sieht dann so aus: Hier oben die Leute alle happy, da drunter die komplexe Maschinerie und wie es bei uns ankommt, ist natürlich so, ne: Wir fliegen auf Wolken und Ende. Und das ist die SaaS-Story und das ist eine Erfolgsgeschichte in der Wirtschaft und am Markt. Und deshalb hat sie ihre Daseinsberechtigung.

[00:05:43] Und wir leben heute alle in dieser Bubble, ob wir es wollen oder nicht. Ne, ihr habt doch alle ein Handy oder so ein Smartphone mit keine Knöpfe. Ne, so „echte Männer haben Knöpfe“ ist schon lange vorbei. Also haben wir heute alle ein Smartphone ohne Knöpfe. Genau, heute kann man nur noch sagen „echte Männer haben HDMI Port“, aber auch das ist bald vorbei.

Publikum: [00:06:09] (Lachen)

Schlomo Schapiro: [00:06:18] Aber äh, ne, ist halt so. Und wer heute ohne Smartphone rumrennt oder, ich sag mal, mit einem „neutralen“ Smartphone, der verzichtet halt ganz bewusst auf ganz viele Errungenschaften der Neuzeit und sagt halt: „Nee, brauche ich nicht, will ich nicht, habe irgendwie eine andere Abwägung.“ Und man ist damit aber auf einer einsamen Insel, ne. Ich treffe diese Leute ganz, ganz selten und ich bewundere das, weil ich tu's mir leider nicht an. Also ich sehe den Wert, ich sehe den Sinn und ich sag dann: „Nee, in meiner eigenen Risikoabwägung bin ich nicht so weit.“

[00:06:53] Das heißt, wir leben alle in dieser SaaS-Bubble. Und das ist ein Fakt. Weil wir den Fakt nicht ändern können, müssen wir drum herum arbeiten. Und das ist eigentlich die Story, die ich euch heute verkaufen möchte: Wie arbeiten wir da drum herum?

[00:07:03] Also mal ein super pragmatisches Beispiel. Und ich vermute, ihr alle habt euch schon mal diese Frage gestellt. Ich habe irgendwie... man macht Fotos. Also Smartphones helfen jetzt auch Fotos zu machen. Man hat dann ganz viele Fotos. Und seitdem jetzt Google das mit der Location History noch kaputt gemacht hat, nutze ich Fotos als Location History. Das heißt, ich mach einfach Fotos und dann sehe ich nachher auf der Karte, wo wir waren. Super praktisch. Und ich kann nachher, gehe ich halt auf dem Zoom raus, ah guck mal, da habe ich ein Foto gemacht, ach da waren wir vor 10 Jahren mal, ist ja cool.

[00:07:44] Und wenn man sich das mal anguckt: Also 8 TB, 300 €, ne, eine Platte, so easy. Steckst in einen PC, irgendeine Software drauf, fertig. Ist vielleicht doch nicht so geil. Dann könntest du so eine Synology nehmen. Ich habe mal vorhin recherchiert, also jetzt für 1100 € kriegst du die Synology mit echten Synology Platten und hast dann da deine 8 TB redundanten Storage. Und übrigens, da ist eine Software drauf, die Fotos verwaltet und die automatisiert die Fotos vom Handy hochlädt. Das funktioniert richtig klasse und schon hast du dein autarkes Non-Cloud Fotoarchiv mit modernen Features wie Gesichtserkennung und einer Karte und lauter so Features, die man gerne hätte.

[00:08:31] Oder ihr geht auf das, was euer Handy mitliefert, da ist Google und Apple ungefähr so preislich auf demselben Niveau für die 8 TB halt, zahlt man da schlappe 600 € im Jahr. Jedes Jahr. Wenn ihr nicht mehr zahlt, dann habt ihr auch die Fotos nicht mehr irgendwann, ne? Also ist schon so ein Commitment, so richtiges Commitment. Und ich kenne ganz viele Leute, die machen genau das, ne, ob jetzt mit Google oder Apple ist egal. Ich kenne ganz viele Leute, leben komplett im Apple Ökosystem, haben dann da Terabyte an Daten, Fotos, das ganze Leben und auch keine Exitstrategie. Und eine ganz schlimme Abhängigkeit übrigens, viel, viel schlimmer als alles, was wir hier diskutieren.

[00:09:26] Genau, man könnte auch Profi sein und sagen, ich nehme jetzt hier Adobe. Es kostet noch ein bisschen mehr, hat noch mehr Features. Da musste ich sogar anrufen, um den Preis rauszufinden, steht nicht mehr auf der Homepage, echt.

[00:09:42] Was hat man hier in Summe? Man macht so einen Tradeoff zwischen Souveränität und Kontrolle, die ist natürlich bei der Platte ganz hoch auf der einen Seite, und Bequemlichkeit und Features auf der anderen Seite. Ne, also ist klar jetzt, ne, Adobe Photo Cloud hat halt Features bis zum Umfallen, da kommen wir hier links mit Marke “Eigenbau” nicht mit. Am Ende entscheidet man sich halt immer zwischen Aufwand und Geld. Es ist immer dasselbe Spiel und jede Diskussion rund um SaaS oder IT oder alles könnt ihr immer genau auf diesen Punkt runterbrechen. Das seid ihr oder euer Chef, der es auch nicht besser weiß. Also könnt Ihr irgendwas soufflieren und das ist es: Es ist immer Geld gegen Aufwand. Zeit gegen Geld, ne, eure Zeit, andere Leute Zeit. Oder halt weniger Aufwand, aber auch weniger Features, weniger Fähigkeiten.

[00:10:43] Genau, nur um das abzuschließen, es gibt noch Immich, und Hoster davon, es gibt auch Ente, auch so ein Foto-Ding, ganz neu. Da gibt's noch weitere Lösungen, die sind alle cool. Aktuell z.B. nutze ich Synology als zusätzliche Backup-Ebene für meine Fotos. Primär ist hier und ich zahle etwas mehr als das, aber für die ganze Familie. Auch kein Geheimnis, wir haben 10 Konten mal 160€ pro Nase pro Jahr. Dafür haben wir aber 20 TB Storage, also Storage kommt so aus der Steckdose und ist nie alle, weil es mein Verständnis von quasi modernem Leben ist, ne? Strom kommt aus der Steckdose, Netz kommt aus der Steckdose, mobile Daten, es kommt alles aus der Steckdose. Ich will mich nicht mehr damit beschäftigen, dass es mal alle ist. Dafür ist doch die Entwicklung auch gut.

[00:11:38] Genau, und ich nutze es als Backup und habe genau das investiert vor ein paar Jahren und bin damit super glücklich. Und es zeigt halt, man muss sich auch als Privatmensch mit diesen Themen auseinandersetzen heutzutage. Man kann das nicht ignorieren und das ist so ein bisschen die Herausforderung. Ich habe ganz oft Gespräche mit Leuten und dann erzähle ich denen so ein bisschen: „Na ja, alle eure Zugänge hängen an eurer blabla@icloud.com oder @me.com oder sowas Adresse. Ist euch eigentlich klar, dass die jederzeit weg sein kann? Und wie kommt ihr dann in eure Sachen rein?“ Wirklich, und dann reden wir über eigene Domains und warum man eine eigene E-Mail braucht und lalala. Das betrifft jeden, jede. Und deshalb ist es mir ein Herzensanliegen, über digitale Souveränität zu sprechen im Kontext Backup und Disaster Recovery, weil das einfach auch für jeden immer die Lösung darstellt. So, reden wir mal über die Firmen, ne, genug über Privatquatsch.

[00:12:44] Also das grundlegende Problem, jede IT-Landschaft sieht im Kern irgendwo so aus: Ne, wir haben halt Admins, wir haben Server, wir haben Netzwerk, wir haben ganz viel Netzwerk, weil solange Leute im Büro sitzen, geht's halt nicht ohne Netzwerk. Und so Sachen wie Drucker, PCs, Laptops, die muss man auch noch betreuen. Und das ist ja vielleicht auch eine Kernaufgabe von IT-Abteilungen in Unternehmen, nämlich dafür zu sorgen, dass alle Mitarbeiter halt vernünftig arbeiten können. Dafür muss ich ihnen ja Technik auf den Schreibtisch stellen und dann hintenrum dafür sorgen, dass die Technik was tun kann. Dummerweise gibt's da drumrum noch ganz viel Fachanwendungen, die auch noch existieren. Jetzt kommt eine Quizfrage: Wer kann alle Abkürzungen auflösen? Wenn ihr jetzt nicht fragt, gehe ich davon aus, ihr könnt die alle auflösen. ATS, Applicant Tracking System, geht's um Recruiter, Recruiting Management... also Scherz beiseite, ich habe ein bisschen recherchiert und ein Haufen von denen sind mir auch in der Beratungspraxis schon begegnet oder in verschiedenen Rollen in verschiedenen Unternehmen, und ich habe sie einführen dürfen.

[00:13:59] Die Realität in der IT ist: Jede Fachanwendung, jede Abteilung braucht halt was. Und das führt zu ganz vielen Problemen, denn am Ende ist es ja so: IT treibt das Business. IT ist ja zentral und integral in allem, was wir tun. Es gibt keine Ecke im Unternehmen, die nicht irgendwas mit IT tut, wegen IT arbeiten kann. Ja, selbst der Hausmeisterservice hat ein Ticketsystem und wenn die Tickets nicht kommen, dann haben die Hausmeister auch keine Arbeit. Also IT treibt, steuert und managed. Und das heißt aber im Umkehrschluss, jede Geschäftseinheit braucht natürlich ihre eigene IT-Lösung. Und du kannst nicht ein kleiner König im Unternehmen sein, wenn du keine eigene Anwendung hast.

[00:14:53] Na, es ist auch ein soziologisches, kulturelles, politisches, organisatorisches Problem. Wenn du ein Unternehmen bist und 100 Leute hast, aber keine Fachanwendung, wer bist du dann? Auch das führt natürlich zu mehr Anwendungen logischerweise. Und weil IT die Innovation treibt, oder Innovation auf IT basiert, werden natürlich Anwendungen auch immer spezieller und komplexer und komplizierter. Und während man so redet und sich gerade Gedanken macht über den Zoo, den man schon hat, hat natürlich die nächste Geschäftseinheit schon eine weitere Anwendung eingeführt. So hintenrum, ne? Die Schatten-IT ist ja durch SaaS noch viel schlimmer geworden, weil jeder mit einer Kostenstelle kann jetzt IT einführen, und das machen die auch.

[00:15:49] Das alles führt erstmal zu Silos, weil ich als Kostenstelleninhaber einer Geschäftseinheit mache natürlich erstmal IT für mich, nicht fürs Unternehmen, und löse meine Probleme. Und mir ist dann egal, wie gut es mit anderen Sachen integriert ist, also habe ich ein Silo. Und für uns ITler erzeugt das halt Probleme ohne Ende. Probleme, Probleme, Probleme.

[00:16:14] Jetzt fragt ihr euch: Was hat das mit SaaS zu tun? Na ja, nur wegen SaaS können wir das überhaupt managen! Also all das ohne SaaS zu managen ist hoffnungslos, geht gar nicht. Und das ist genau der Punkt, warum ich glaube, SaaS ist aus der Welt nicht mehr wegzudenken. SaaS ist ein Erfolgsmodell für die Nutzer, für die Kunden, weil sie tatsächlich darüber ganz viele Vorteile ziehen. Das eine ist: Ich habe einfach eine klare Planbarkeit. Ich habe ein Problem und ich zahle nur für die Lösung meines Problems. Und ich zahle nicht für: Ich baue ein IT-Team auf, was irgendwie eine neue Anwendung lernt und ganz viel Overhead macht. Und dieses CAPEX zu OPEX umwandeln, ist für Firmen extrem wertvoll, weil es ihre wirtschaftliche Grundlage verschiebt, weg von großen Investitionen hin zu mehr laufenden Kosten, die man zur Not aber auch runterfahren kann. Ne, wenn ich jetzt eine SaaS-Anwendung habe, die wird per User bezahlt, dann schmeiße ich halt die Hälfte raus und habe ich die Hälfte der Kosten reduziert. Wenn es eine On-Premise-Anwendung war, dann habe ich das Invest schon im Keller stehen und ich kann halt nicht mal die Hälfte einsparen. Klingt jetzt krass, aber Leute, das ist aus Arbeitgebersicht ein Argument. Auch wenn es uns weh tut, es ist ein Argument und so denkt die Wirtschaft. Für die Wirtschaft sind Investitionskosten Betongold quasi, ist ein Problem. Und viele Firmen wollen weniger Hardcore-Invest und mehr laufende Kosten haben. Und da spielt halt SaaS total dicke rein.

[00:18:02] Das andere ist natürlich Flexibilität, ja. Ich habe viel weniger Vorlauf, um eine neue Anwendung einzuführen. Ich habe viel weniger Integrationstiefen, Aufwände, technische Schmerzen, ne. Kreditkarte reicht, wir können loslegen mit arbeiten. Das sind harte Vorteile für SaaS. Und die Welt braucht das und nutzt das. Wiederum, das sind die Gründe, warum wir SaaS nicht loswerden. Und ganz wichtig... ach so, der ist auch wichtig übrigens, ne: Nur wegen SaaS kann jedermann quasi geile Software benutzen, weil einfach diese Skalierung von klein zu groß da ist. Also nehmen wir mal ein Beispiel, ne, ich nutze Google Workspace, Riesen-Groupware-Lösung. Eine Alternative wäre Open-Xchange (OX App Suite). Kennt das jemand, schon mal gehört? Wisst ihr, wie viel Aufwand das macht, Open-Xchange zu betreiben? Habt ihr das? Ja, ja. Wie viel Admins brauchst du dafür?

Publikum: [00:19:04] (Unverständlich) ...vielleicht...

Schlomo Schapiro: [00:19:08] ...für die Glühlampe tauschen? Scherz. Also ich kenne halt auch Open-Xchange, ich kenn's auch von größeren Umgebungen und es ist halt nichts, was man so als kleine Anwendung betreiben kann. Es ist ein großes Ding. Ja, und ich könnte es jetzt für mich zu Hause definitiv nicht betreiben, keine Chance. Wirklich hoffnungslos. Wenn ich jetzt aber eine richtig gute PIM-Software haben will oder eine Groupware haben will, dann muss ich das Problem ja lösen. Und da ist halt SaaS quasi... reduziert halt diese Einstiegshürde, ich kann es einfach nutzen. Und ich glaube daher, dass halt SaaS dieses quasi „jeder kann gute Software benutzen“-Problem löst. Ja, Trade-off ist halt die Abhängigkeit und die starke Kopplung und so, aber du kriegst erstmal eine Lösung. Und wenn ich halt eine Lösung haben will und sie gerade brauche und mein Unternehmen jetzt endlich mal den nächsten Schritt gehen soll, dann ist mir das vielleicht lieber.

[00:20:13] Ganz wichtig ist auch: Firmen haben oftmals ein Fokusproblem. Verzetteln sich in tausend Sachen und beschäftigen sich mit tausend Dingen, die aber nicht ihr Kerngeschäft sind. Und SaaS-Lösungen, gerade in IT, helfen tatsächlich, den Fokus auf die eigene Wertschöpfung, die Kernwertschöpfung zurückzuholen, indem man halt sagt: Alles, was nicht unsere Kernwertschöpfung ist, machen wir extern. Und ob ich jetzt einen Dienstleister beauftrage, der für mich Server wartet, oder einen SaaS-Anbieter einkaufe, der für mich die Software nur bereitstellt, ist fast schon dasselbe. Es ist kein großer Abstand, ne. Ich habe bei beiden einen großen Kontrollverlust, ich habe nicht mehr so viel mitzureden, ich benutze das einfach. Wenn es nicht geht, dann kann ich halt hingehen und meckern, und die ignorieren mich. Es ist kein großer Unterschied. Und alle, die mal mit einem großen kommunalen Rechenzentrum zu tun hatten, ich glaube, ihr könnt jetzt alle... ich würde mich nicht wundern, wenn ihr sagt: „Also bei SaaS habe ich eine bessere Qualität.“ Ja, das sind einfach... ist halt so, ne. Genau, und das ist der Grund, warum halt SaaS eine beliebte, sozusagen willkommene, erfolgreiche Lösung für die ganzen Unternehmensanwendungen sind, die wir halt so brauchen. Ist so.

[00:21:31] Also, wie gehen wir damit um? Und um das zu verstehen, muss ich euch leider einen kleinen Ausflug in Richtung Backup und Disaster Recovery mitnehmen. Das ist ein Vortrag (Video auf YouTube) vom letzten Jahr, der ist ziemlich intensiv und umfangreich. Könnt ihr auf YouTube nachgucken. Was ich hier habe, ist nur ein paar kleine Auszüge daraus, die jetzt noch mal speziell auf unser SaaS-Thema quasi einzahlen. Da ist aber noch viel mehr, was man sich über Backup und Disaster Recovery antun kann, angucken kann. Deshalb ist meine Empfehlung: Schaut euch das Video an. Wenn ihr nur den Titel eintippt, dann wird euch YouTube das schon ausspucken.

[00:22:19] Und vielleicht der allerwichtigste Punkt ist noch mal so Grundverständnis Business Continuity oder die Fähigkeit, sein Geschäft fortzuführen. Ich habe überlegt, wie kann man es eigentlich definieren. Bin großer Fan von Definitionen. Eine Definition, zusammengefasst: Wir bleiben halt im Geschäft. Und dieses „egal wie“ ist der entscheidende Punkt. Für ein Unternehmen ist es extrem wichtig, in Krisensituationen zu überleben. Und für KRITIS und Städte und so, ne, natürlich noch viel mehr, aber auch für jedes Unternehmen ist es halt eine ureigene hehre Aufgabe, Herausforderung und Pflicht, das eigene Überleben zu sichern. Ist glaube ich unbestritten, oder? Fängt an bei Arbeitsplatzsicherheit und hört auf bei Investoren, die wollen halt ihr Geld nicht davonschwimmen sehen.

[00:23:36] So, noch mal ganz kurzen Blick auf die Basics. Und ich hoffe, ihr kennt es schon alle. Mir ist einfach wichtig, dass wir über dasselbe reden und dasselbe meinen. Also, eine Zeitlinie, einen Zeitstrahl, und natürlich macht man irgendwann mal ein Backup oder will man. Alle Backups, ja, komme noch dazu. Oh sehr gut! Also machen noch ein Backup, und noch ein Backup. Und wie es halt so ist mit Murphy, genau während das Backup läuft, knallt's richtig. Es knallt ja nicht zwischen zwei Backups. Es knallt, während ein Backup läuft, sonst wäre es langweilig. Genau, dann kommt Headless Chicken Mode, Chaos, irgendwie Magic, wir tun was. Und dann haben wir halt eine teilweise Wiederherstellung geschafft, weil wir sind ja coole Admins. Und dann geht's Nacharbeiten, und dann haben wir eine weitgehende Wiederherstellung geschafft, und das Leben geht weiter. Der Rest war Kollateralschaden. Ne, soweit erstmal Basics.

[00:24:41] Ganz wichtige Begriffe: RPO, Recovery Point Objective, muss man unbedingt benutzen, wenn man mit Leuten darüber redet, weil sonst komische Ideen in den Köpfen entstehen. Und ich merke mir das immer: Wie alt ist der Kram, den wir wiederherstellen? Also Reise in die Vergangenheit. Und das andere ist natürlich die Recovery Time Objective (RTO). Also, wie lange dauert das überhaupt? Und weil ich mir immer nicht merken kann, was jetzt RPO und RTO war, habe ich mir überlegt: Also die RPO ist das, was wir in der Hosentasche haben, ne, und damit fangen wir an irgendwas zu machen. Und die RTO ist das, was wir dann tun. Also haben und tun ist RPO und RTO. Und jetzt kann ich es mir merken. Und das Bild ist so für mich die Grundstellung vom Tanz. Da kommen wir nachher noch mal drauf zurück. Wenn ihr mit Leuten über Backup und Disaster Recovery redet, sprecht bitte immer über dieses Bild und benutzt diese Begriffe und fragt die Leute: „Wie viel Reise in die Vergangenheit dürfen wir uns denn erlauben? Wie viel ist es dir wert, weniger in die Vergangenheit zu reisen?“ Weil es ist ja noch schlimmer, musst 426 Systeme aufeinander abstimmen. Habe ich nachher eine Folie für natürlich. Es war mal einfach, ne. Es war einfach, als wir einen Server im Keller hatten und der hat alles gemacht.

[00:26:16] Genau, also das nächste ultrawichtige Ding, was man immer wieder den Leuten erklären muss – und da führt leider kein Weg dran vorbei: Backup ist nicht Notfallwiederherstellung. Das sind zwei Paar Stiefel und die sind fundamental unterschiedlich. Und das eine zu haben, heißt noch lange nicht, dass man das andere auch kann. So, ich hoffe, ich überrasche keinen. Also die Wiederherstellung ist immer ein einzelnes Ding, ne? Wenn ich ein Restore mache, dann stelle ich eine Datei, eine LUN, einen Server, ein irgendwas wieder her. Ne, Restore ist einzeln. Und die Notfallwiederherstellung, das Disaster Recovery, ist im Gegensatz dazu immer alles. Also nicht eine Datei, sondern alle Dateien. Alle LUNs, alle Server, alle Rechenzentren, was auch immer eure Skalierung gerade ist. Alle Nutzer. Dieser Übergang von „einzeln“ zu „viele“, das ist der Unterschied zwischen Backup und Disaster Recovery. Und wenn man anfängt darüber zu reden, dann merkt man plötzlich, dass vielleicht die Backup-Strategie halt wirklich nur eine Backup-Strategie ist und weder Restore noch Disaster Recovery beinhaltet.

[00:27:39] Denn diese einzelne Wiederherstellungsgeschichte, die findet immer statt, wenn die Zutaten dafür noch da sind. Also, ich stelle eine Datei her, wenn der Fileserver noch da ist. Ich stelle eine LUN wieder her, wenn das Storage noch da ist. Das heißt, dieses Restore hat immer den Kontext von „meine Welt existiert noch und ich habe vielleicht aus Versehen was gelöscht“. Und das Disaster Recovery findet genau dann statt, wenn das alles nicht da ist. Ich muss alle Server wiederherstellen, weil, na ja, sie sind nicht da. Und deshalb ist das Problem bei Disaster Recovery: Wir haben keine Zeit. Und die Zeit ist das größte Problem im Disaster Recovery. Also hier, die Zeit ist der größte Feind von allem an der Stelle. Und dann reden wir über eine RTO von einem Tag. Ein Tag, ne? Aber wir haben all das nicht: kein Server, kein Storage, kein Rechenzentrum, kein Internet. Aber an dem Tag sind wir wieder live, oder? Also das ist so die Herausforderung von Disaster Recovery und warum ich Disaster Recovery viel spannender finde als Backup, tatsächlich. Also hier spielt die Musik.

[00:28:52] So, ich habe mir drei Grundsätze ausgedacht, um das Ganze noch mal in Rahmenbedingungen einzufassen. Also ganz wichtig: Backup ist da, um die Wiederherstellung zu ermöglichen. Backup ist Mittel zum Zweck, Restore ist das Ziel. Deshalb fängt bei mir jede Diskussion an von „Erzähl mir mal, wie das Restore funktioniert, und dann sage ich dir, welches Backup du dafür brauchst“. Nicht andersrum. Und wenn man so anfängt zu reden und zu denken, dann merkt man plötzlich, dass man Anforderungen ins Spiel kriegt, die vorher unklar waren.

[00:29:32] Jetzt natürlich die Steigerung, ne: Ein umfassendes Backup und eine Automation der Wiederherstellung führen zu Disaster Recovery und das führt zu Business Continuity. In genau dieser Reihenfolge. Deshalb renne ich mit „Automate“ T-Shirts rum, weil Automation einfach der Weg ist, wie wir in die Skalierung von dem einen Ding zu „alle Dinger“ kommen. Das ist halt zu viel für Handbetrieb. Und das Dritte, ganz wichtig und immer wieder eine Überraschung: Bitte benutzt dasselbe Backup, um Wiederherstellung und Notfallwiederherstellung zu ermöglichen. Genau dasselbe Backup! Weil ihr habt doch schon eine Kopie der Daten, brauchen nicht noch eine. Auch super teuer sonst. Also das sind meine drei Prinzipien, um tatsächlich Backup und Disaster Recovery ganzheitlich in den Griff zu kriegen.

[00:30:25] Jetzt schauen wir mal ganz schnell auf so ein paar Herausforderungen. Ne, also Nummer eins: Die Zeit. Die Zeit ist unser größter Feind und die rennt uns immer davon. Und bis wir angefangen haben zu arbeiten, ist schon die Hälfte der Zeit rum. Mal ein Beispiel, ne: 140 TB SAN, ist das groß oder klein? So, Meinung?

Publikum: [00:30:45] Klein.

Schlomo Schapiro: [00:30:46] Klein. Ne, es ist klein. Die krasse Wahrheit ist, 140 TB SAN ist klein. Es ist... ich kann mich noch dran erinnern, wie 140 TB SAN, das war so, ja, an der Uni hat man das vielleicht. Aber sonst hat es niemand. Und heute ist es irgendwie klein. LTO9 ist immer noch weit verbreitet und quasi der Goldstandard. Und jetzt stellt euch mal vor, das fällt aus. Wenn man das ausrechnet, kommt man auf quasi 5 Tage nur kopieren (und es geht nichts schief), um dieses ganze Ding wieder zurückzuspulen. Banalste Mathematik. Klingt doch erstmal gut, ne? Ja, Moment, da war doch so RTO ein Tag, oder?

[00:31:35] Spannendere Frage ist: Also erstmal, ist die Woche okay überhaupt, von wegen Wiederherstellung? Zweitens: Was macht eigentlich die Firma extern, während wir uns intern mit der Wiederherstellung beschäftigen und nichts existiert? Vielleicht schwimmen uns extern schon alle Felle davon. Oder wie lange dauert es eigentlich, jetzt ein neues SAN zu besorgen und in den Keller zu installieren, bevor ich diese Woche Wiederherstellung überhaupt anfangen kann? Und meine Lieblingsfrage, aus der Brille Automation, ist natürlich: Kann ich das irgendwie testen und validieren? Woher weiß ich denn, dass ich das schaffe? Woher weiß ich denn, dass diese Technik funktioniert? Also ich habe es nicht ausprobiert. Dem Anbieter hatten wir versprochen, dass es so klappt, aber wir hatten das mal getestet? Sorry, ich kenne echt wenig Leute, die das regelmäßig testen. Das leisten sich ganz wenige Unternehmen. Ne, also eine Bank vielleicht oder ein Pharmaunternehmen oder so, die halt irgendwie Hardcore-Anforderungen, so Compliance-Anforderungen haben, aber welche normale Firma testet das mindestens einmal im Jahr? Es ist nicht zu leisten, in meinen Augen. Also ist ein echtes Problem, ja. Es ist irgendwie, man müsste es machen, das ist total offensichtlich, aber in der Realität fällt's schwer.

[00:32:54] Also was ist jetzt die SLA von dem Ganzen? Und ich sag immer, das ist RPO plus RTO und beten, hoffen und ganz viel Glück. Ne, das ist die faktische SLA vom Wiederherstellungsprozess. Und das ist natürlich eine Unbekannte. Und wie kriegen wir jetzt diese Unbekannte raus? Weil mein Ziel ist ja, die Zeit zu schlagen in dem ganzen Spiel. Und die Idee ist total banal: Na ja, wenn ich das Restore loswerde in meinem Prozess, dann kann ich die RTO schlagen. Und diese Unsicherheiten. Und der Weg, das zu schlagen, ist durch Automation. Also ich mache es jedes Mal, ne? Jedes Backup stelle ich sofort wieder her. Irgendwo anders. Wenn ich das gemacht habe, dann habe ich ein Ersatzsystem, was ich benutzen kann. Und dann ändert sich mein Prozess von „ich probiere mal aus, ob ich wiederherstellen kann“ zu „ich schalte um auf ein schon wiederhergestelltes System, was einfach funktioniert“. Und damit kann ich eine feste RTO erzeugen, die ich auch noch getestet und validiert habe, mit einem harten Versprechen durch einen echten Test. Klingt einfach und ist richtig schwer. Lasst euch davon bitte nicht beirren, dass ich das hier so schön erzähle. Es ist schwer.

[00:34:21] Du brauchst Ressourcen. Du hast aber Virtualisierung, das hilft ein bisschen. Für manches, nicht für alles.

Publikum: [00:34:30] Ja, kann ja sein, dass bei uns am Flughafen ein Jumbo reinfällt. Beim Rechenzentrum ist ja...

Schlomo Schapiro: [00:34:44] Ja, wenn du dir jetzt so DORA und BSI-Gesetz anguckst, steht das drin. Steht nicht drin, woher du das Geld kriegst und womit du es bezahlen sollst, steht nur drin, dass du es machen musst! Genau. Noch mal auf das ursprüngliche Bild quasi übertragen, ne. Also ich nenne das die No Restore Solution, weil es halt den Restore aus dem Notfallprozess rausnimmt. Und wir haben natürlich die Backups. Der Unterschied ist jetzt, nach dem Backup kommt das Restore, die Validierung, dann habe ich mein Recovery-System schon rumliegen. Und ja, das ist manchmal schwierig, Ressourcen, Aufwand, Geld, whatever, aber die Grundidee, die ist tatsächlich valide und funktioniert super. Das gibt mir erstmal eine Möglichkeit hier zu checken, ob mein Backup und mein Restore tatsächlich funktionieren.

[00:35:35] Ich kann euch aus eigener Erfahrung sagen, das ist kein selbstverständlicher Punkt. Wir haben zu ImmoScout-Zeiten das live erlebt. Da hatten wir Subversion (SVN) und haben ein tolles Backup-System um Subversion gebaut. Und dann haben wir mal gesagt, lass uns doch mal das Restore automatisieren und testen. Und dann kam raus: Unser Subversion ließ sich nicht wiederherstellen! Weil es gab irgendwie 10 Millionen Revisionen zurück einen Datenfehler und alles danach konnte man nicht wiederherstellen. Und wir haben dann vom Subversion-Team quasi einen Entwickler kommen lassen, der mit einem Hex-Editor unser Subversion repariert hat. Und das haben wir nur rausgefunden, weil wir diesen automatisierten Restore-Test gemacht haben. Stellt euch mal vor, wir hätten es nicht gemacht und wir hätten es einmal gebraucht und dann erst gemerkt, es geht kein Restore, ist kaputt. Also für mich war das so echt die Lesson Learned: Was du nicht getestet hast, ist wahrscheinlich kaputt.

[00:36:36] Genau, ne. Dann kommt das Backup, es knallt, das ist alles wie vorher. Und dann schalte ich bloß noch um. Das geht schnell. Und dann habe ich halt meine Recovery Time fest, unabhängig von der Menge der Daten, der Menge der Systeme und whatever. Und so habe ich eine feste RTO, die halt von meinem Architekturaufwand abhängt und nicht mehr von der Datenmenge oder den Systemen. Und das ist die No Restore Solution. Das ist ein Grundkonzept, ein Architekturkonzept sozusagen, dass man auf ganz viele Sachen applizieren kann. Und es ist meine Empfehlung: Nutzt diesen Ansatz, um eure Notfallwiederherstellungskonzepte tatsächlich testbar, beweisbar und auch zuverlässig zu machen. Und die geforderten Wiederherstellungszeiten real einzuhalten, nicht nur als schönes Papier an der Wand, ne. Daher der Titel vom Vortrag: Digitale Souveränität ist mehr als ein Stück Papier. Das ist Automation, die man bauen muss.

[00:37:37] So, kommen wir zur nächsten Herausforderung für alle KRITIS-Freunde hier. Wir sind ja in Deutschland. Und in Deutschland gibt's Regulatorik. Und die bestimmt unser Leben. Egal, was wir tun und egal, wo wir es tun, die Regulatorik bestimmt unser Leben und wir kommen da nicht drum rum. Ich habe das mal zusammengefasst. Die ganze Regulatorik kann man wunderbar zusammenfassen, ich nenne das das elfte Gebot der IT: Das sagt einfach, du musst deinen Kram ordentlich machen. Da führt kein Weg dran vorbei. Und ja, man kann das schön biblisch formulieren, ich sag einfach: Mach es ordentlich. Kümmer dich um die schwierigen Sachen, kümmer dich rechtzeitig um die schwierigen Sachen, und dann ist alles gut. Ihr könnt es gerne als elftes Gebot mitnehmen, an die Wand beppen und sagen: „Ey Leute, das müssen wir auch noch tun.“

[00:38:47] Wer es noch ein bisschen mehr belegt haben möchte: Ich habe mir mal die Mühe gemacht, aus den relevanten Regularien ein paar Zitate zu sammeln. Ist übrigens die überarbeitete Folie im Vergleich zum vorherigen Vortrag. Wir haben jetzt nur noch das BSI-Gesetz, in dem ja die NIS-2-Verordnung aufgegangen ist, für alle Kritische Infrastruktur und Anbieter von irgendwelchen tollen Cloud-, SaaS-, sonst was Lösungen. Software-Anbieter, also ganz viele fallen da drunter, die es vorher nicht taten. Dann in der Finanzwirtschaft gibt's noch DORA oben drauf, daneben, dazu, ist quasi dasselbe in Grün. Und wenn ihr denkt, ihr seid fein raus, dann wette ich mit euch, die Datenschutzgrundverordnung erwischt euch doch! Da steht dasselbe nämlich auch noch mal drin. Tatsächlich, Überraschung für mich, als ich das Ganze durchgelesen und recherchiert habe: In der Datenschutzgrundverordnung steht drin, du darfst Daten nicht verlieren. Ja, man denkt ja eher, man muss die Daten schützen, ich darf keine Daten erheben blablabla. Ja, stimmt, aber wenn du die Daten hast, dann musst du sie verwahren und sorgfältig schützen und dafür sorgen, dass sie nicht aus Versehen verloren oder verschütt gehen. Das heißt, das ganze Thema Backup, Disaster Recovery und quasi Nachfolge-Exit-Strategie von SaaS-Anbietern ist da alles mit drin in der Datenschutzgrundverordnung. Das trifft ja nun wirklich alle. Also es gibt kaum ein Unternehmen, das es schafft, an der Datenschutzgrundverordnung vorbeizuschlittern. Und selbst als Privatmensch ist man da ja schon betroffen, wenn man irgendwie WhatsApp benutzt oder ein Foto von einem Freund schießt und vorher nicht um Erlaubnis gefragt hat und sich das schriftlich halt geben lassen, um es abzuheften.

Publikum: [00:40:34] Hä? Nein, nein. Abgehakt.

Schlomo Schapiro: [00:40:38] Und dann gehst du auf eine Kita-Feier, machst da Fotos und schwupps bist du doch gefangen! Ja, es ist halt so, ne? Ist nur die Zusammenfassung, lest euch das durch oder gebt's einer KI und stellt Fragen dagegen. Das Einzige, was in den Verordnungen nicht drin steht, ist, wo das Geld herkommt, um es zu tun, und wo die Admins herkommen sollen, die das dann umsetzen. Irgendwie haben sie da sich dann die Abkürzung genommen.

[00:41:14] Kommen wir mal zu einem kleinen spaßigen Teil. Ich habe einen Selbsttest mitgebracht für euch und es gibt hier auch was zu gewinnen. Nämlich wer den Selbsttest besteht, der kriegt von mir ein Zertifikat ausgehändigt. Genau, und dann geht's los. Jetzt mal alle die Hände hoch. So als Start. Kommt, nicht einschlafen, alle die Hände hoch. So, und jetzt könnt ihr die Hände oben behalten, wenn ihr die erste Anforderung erfüllt: Also, ihr habt Backups.

Publikum: [00:42:07] (Unverständlich) Was auch immer du gerade spielen möchtest...

Schlomo Schapiro: [00:42:09] Ich hoffe ja, wir haben schon... genau. Das problematische Wort hier ist natürlich „umfangreich“, ne, weil ja, alle haben Backups, aber wie viel, was, sind schwierig, ne? Okay, aber alle sind noch dabei. So, haben wir eine Doku dazu? Hm, ja genau. Ich kann euch sagen, in meinem letzten Vortrag haben es zwei bis zum Ende geschafft. Das ist ernst gemeint. Ich hoffe, dass ihr alle jetzt noch mitkommt.

[00:42:36] Genau. So, habt ihr mal eine sogenannte Business Impact Analyse gemacht? Also einfach so eine Wenn-Dann-Geschichte, ne: Wenn das ausfällt, was geht dann kaputt? Ist übrigens vorgeschrieben in den ganzen Regularien.

Publikum: [00:42:54] Sorry. Ja, ja.

Schlomo Schapiro: [00:42:54] Habt ihr mal einen Abgleich gemacht zwischen den Wiederherstellungszeiten und dem, was euer Business eigentlich haben will oder bräuchte, um kein Geld zu verlieren, oder um adäquat wenig Geld zu verlieren? Ne, so mal Technik und Geld irgendwie miteinander verheiraten, jenseits der „Es muss immer ein Tag sein“. Habt ihr es mal ausprobiert? Flächendeckend, ne? Genau. Habt ihr es geübt? Wäre dann das Nächste. Sorry.

[00:43:43] Und jetzt natürlich spannend: Drittanbieter-Lösungen. Vulgo SaaS, aber nicht nur SaaS, also jede Art von Drittanbieter-Lösung. In der Regulatorik wird da gar nicht unterschieden, ob das jetzt Microsoft mit SaaS ist oder DATEV, ne, ist ja auch SaaS. Oder ob das einfach nur ein Dienstleister ist, der bei euch im Keller was betreibt oder bei sich im Keller. Da gibt's halt einmal das Thema, die Verantwortung auch zu validieren. Also speziell die DORA, die gesagt hat: Ja, also der Geschäftsführer ist jetzt persönlich haftend für die Qualität der Drittanbieter in seinem Haus und der Umsetzung der Vorgaben. Und ganz wichtig: Ihr braucht eine Exit-Strategie. Es reicht aber nicht aus, eine Exit-Strategie zu haben. Ihr müsst auch die Daten... in der Regulatorik steht „easily accessible“, ich würde es mal mit offenen Formaten übersetzen tatsächlich, die Regulatorik schreibt über neutrale Datenformate. Ihr müsst die Daten aus dem Zeug wieder rauskriegen können! Ganz wichtiger Punkt. Also eine Exit-Strategie ohne das reicht nicht aus.

[00:44:53] Es tut mir leid, dass ich jetzt keinen hier mitnehmen konnte. Ich habe aber trotzdem fünf Kopien und ihr könnt euch gerne nachher was abholen. Das ist so an die Wand beppen oder sonst wo, ne, dann wäre das das Zertifikat. Wir können es mal als To-Do-Liste mitnehmen. Genau, also wer das alles schafft, ist dann zertifiziert. Ihr könnt jetzt irgendwie teure Berater kaufen und die metrische Tonnen von Papier schreiben lassen. Oder vielleicht bei uns ganz pragmatisch euch bei der Umsetzung helfen lassen. Und wir sorgen dafür, dass ihr nicht Bullshit macht und nicht Bullshit Bingo an der Wand spielt, sondern halt echte Ergebnisse produziert. Das ist das, was ich gerne mache: Handfest, konkret, funktioniert, beweisbar, automatisiert.

[00:45:32] Ja, kommen wir mal auf SaaS und Cloud zu sprechen, ne. Also Wolken fangen ist irgendwie so ein schwieriges Hobby. Und das Kernproblem ist halt, es ist weit weg. So, und die größte Herausforderung in meinen Augen ist die unglaubliche Dezentralisierung. Das ist so das klassische Rechenzentrum, was ihr vielleicht noch hier und da habt, ne: Server, Virtualisierung, Storage, noch ein Backup Storage, ein Band dazu, die Klassiker. Das ist schon kompliziert und schwierig. Aber jetzt stellt euch mal vor, da kommt noch viel mehr dazu. Da kommt genau dasselbe, aber 100 Mal mehr dazu! Und ob ihr das nun Cloud oder SaaS nennt, ist eher so eine Geschmackssache, es ist inhaltlich genau dasselbe. Cloud ist ein Rechenzentrum von jemand anderem. Und SaaS ist: Du hast nicht mal Zugriff auf das Rechenzentrum, sondern du benutzt nur die Software. Also ist noch weiter weg. Aber das Problem der Dezentralisierung, dieser Ausbreitung in die unendliche Fläche, das ist halt dasselbe.

[00:46:42] Und wie du schon gesagt hast, ne, wie willst du das wiederherstellen? Und irgendwie auch noch konsistent machen? Denn das ist die Konsistenzherausforderung, die es hier gibt, ne. Wir haben jetzt hier so eine verteilte Landschaft von irgendwelchen Anwendungen, die irgendwo in der Welt laufen, und typischerweise kommunizieren die über Queues, über Rohre, Pipelines, whatever miteinander. Also asynchron, weil synchron würde gar nicht funktionieren. Das heißt aber, ich habe jetzt plötzlich so Leitungen, in denen Zeug liegt und da habe ich State drin. Und dann ist so die allererste Frage, die ich mir mal stelle: Okay, wie synchronisiere ich denn jetzt mal ein Backup über meine gesamte IT-Landschaft hinweg? Oder wie viel Daten habe ich eigentlich In-Transit versteckt? Also die haben ein System verlassen, schlummern in der Queue, das nächste System hat sie noch nicht angefasst und verarbeitet. Ganz pragmatische Probleme. Und egal ob SaaS, Cloud, Multi blablub, in dem Moment, wo ich halt diese Dezentralisierung habe, komme ich da an.

[00:47:59] Und das Traurige ist, es gibt keine gute Lösung, sondern die Anwendungsarchitektur muss das Zusammenführen von zeitlich unterschiedlichen Backups und so weiter beherrschen. Das heißt, die Datenkonsistenz als Problem muss ich auch in der Anwendung wieder lösen. Die kann ich nicht mehr auf der Infrastrukturebene lösen. Und das ist eine Diskussion, die habe ich persönlich ganz oft schon geführt mit Anwendungsentwicklern. Mal drüber reden, dass sie halt nicht mehr annehmen können, Backup und Disaster Recovery ist ein Problem, was die Infrastruktur ihnen abnimmt. Ist nicht! Geht nicht. Funktioniert nicht. Ist eine Illusion. Wenn man mal anfängt, über die konkreten Szenarien zu reden und drüber konkret zu reden: Ja, wie machen wir denn eine Wiederherstellung, ne? Wir reden nicht über Backup, wir reden über Restore. Und aus der Restore-Geschichte ergibt sich dann das passende Backup. Und wenn du mit Entwicklern über solche Sachen redest, dann checken die das ganz schnell und sagen: „Hm, stimmt, ich muss ja jetzt mal hier einen Datenabgleich in meiner Anwendung einbauen, so dass dann die Anwendung sich wieder zusammenfummelt, wenn die Daten mal irgendwie wieder da sind.“ Dann machen die das und dann ist gut. Also dieses „eventually consistent“ ist dann ernst gemeint an der Stelle.

[00:49:21] Kommen wir zur nächsten Herausforderung, ich nenne das die „Data Possession Challenge“. Also der Herausforderung, wer eigentlich die Daten hat. Und da gibt's einen ganz, ganz einfachen Vergleich, den ihr nutzen könnt, um das Ganze eurem Chef zu erklären: Nämlich dieses Bild. Ich hoffe, das ist keinem von euch passiert, aber statistisch kann das halt mal passieren, ne? Jemand guckt nicht so genau auf die Umgebung und dann kommt jemand anders und zieht hinten die Geldbörse raus. An dem Beispiel kann man wunderbar ablesen, was jetzt eigentlich Eigentum ist auf der einen Seite und Besitz auf der anderen Seite. Genau dasselbe passiert mit euren Daten! Und du lachst schon, aber das stimmt wirklich! Ja, also der Dieb hat den Besitz und der Eigentümer kann eine Besitzstörungsklage einreichen. Sowas gibt's im Deutschen.

[00:50:26] Übertragen wir das mal auf SaaS, ne: Also ihr seid jetzt hier der Nutzer und ihr habt eine tolle SaaS-Anwendung. Dahinter ist natürlich wieder ein Rechenzentrum, ne, so ganz klassisch. Und da drin liegen jetzt Daten von irgendwelchen Nutzern, und am Ende auch die Daten von euch. Logo, ne, so funktioniert SaaS. Und jetzt ist es so, der Besitz ist hier beim SaaS-Anbieter und ihr habt natürlich das Eigentum an den Daten, das nimmt euch niemand weg. Soweit so fein. Haben die ein Backup vielleicht?

Publikum: [00:51:00] Nö.

Schlomo Schapiro: [00:51:00] Genau. Jetzt kommt natürlich die Störung in deinem Zugang, ne. Es gibt irgendeinen externen Faktor oder einen internen Faktor, der sorgt dafür, du kommst da nicht mehr ran, rein zufällig. Und was passiert jetzt? Jetzt hast du erstmal keinen Zugang zu den Daten, du hast das Eigentum, hast du noch. Aber du hast keine Nutzung mehr, ne. Also hier, jetzt haben wir natürlich kein Backup gehabt. Und das Problem ist jetzt, der einzige Weg an die Daten zu kommen, ist per Gericht, die Besitzstörungsklage, ne. Die „Gibt mir meine Daten wieder“-Klage. Wer das mal probiert hat: Also das dauert Jahre! Und wenn die Firma pleite ging, dann sind vielleicht keine Daten mehr da, die man dann per Klage zurückholen kann. Das heißt, es ist eine höchst theoretische Lösung, die praktisch überhaupt sinnlos ist. Bullshit. Und das ist das Problem mit SaaS und Besitz der Daten: SaaS nimmt euch den Besitz der Daten und das ist das Problem, was wir lösen müssen.

[00:52:12] So, noch mal ganz kurz, SLA ist auch eine Herausforderung, ne. Ich habe hier noch ein anderes Beispiel mitgebracht: So Koch, Küche, Restaurant, kennt glaube ich auch jeder zumindest theoretisch, ne? Also klar, ihr seid der Koch, die Daten sind in der Suppe und die Küche ist jetzt euer SaaS-Vendor. Der einzige Weg daraus ist halt die Durchreiche zum Restaurant. Soweit auch klar, oder? Das Problem ist jetzt, und das hat auch dieses Bild tatsächlich: Ihr seht, die Suppe ist voll lecker, ne? Das Problem ist nämlich, der SaaS-Anbieter interessiert sich nicht für eure Daten. In diesem Restaurantbeispiel: Das, was uns am Ende hier im Restaurant interessiert, ist doch ein leckeres Essen, oder? Aber der ganze Prozess hier in der Küche hat mit leckerem Essen nichts zu tun. Finde den Fehler. Es passt irgendwie was nicht zusammen.

[00:53:16] Und das ist jetzt ein Beispiel von Google Workspace Data Protection Implementation Guide. Da hat Google Workspace mal erklärt, wie sie so die Verantwortung zwischen Google Workspace und dem Kunden aufteilen. Und sie erklären sogar den Unterschied zwischen IaaS, PaaS und SaaS. Und wenn man das halt aufdröselt, kommt halt raus: Also, wenn du deine Daten selber aus Versehen gelöscht hast, bist du selber verantwortlich. Wenn du jemandem anders Zugriff auf deine Daten gegeben hast und er sie gelöscht hat, dann ist es „Works as designed“, weil Google ist nicht verantwortlich. Wenn du ein Konto gelöscht hast, dann ja, „Works as designed“, ne. Das Einzige, worum sich der SaaS-Anbieter kümmert, ist halt der technische Betrieb. Und das ist SaaS. Das ist ein Problem. SaaS-Anbieter scheißen auf eure Daten! Ist nicht wichtig.

[00:54:12] Also, worin besteht denn jetzt die SaaS-Falle? Ist ganz... und um die SaaS-Falle zu verstehen, die ist wirklich so, ne? Wir haben den Dude schon mal gesehen, der ist happy. Guck mal, wie happy der ist, obwohl er in der Falle sitzt! Das sind wir mit SaaS. Also eine Architektur, eine Erklärung aus der Technik heraus, ihr seid ja alle ITler. So, wir, SaaS, soweit so einfach. Wir schieben da Daten rein, ne. Wir machen Upload oder wir klicken auf Create und dann erzeugen wir halt Daten in der SaaS-Anwendung. Die SaaS-Anwendung gibt uns zurück einen Link, ne. Ich gehe auf Google Drive, sag „neue Präsi“, dann wird ein neuer Link erzeugt, hinter dem die Präsi ist. Dieser Link hat oben so ein kryptisches Ding drin, das ist die ID davon. Das heißt, immer wenn ich Daten anlege, erfindet die SaaS-Anwendung eine ID dafür. Und diese ID ist der zentrale Dreh- und Angelpunkt für diese Daten. Soweit keine Überraschung, oder? Und natürlich kann ich die Daten runterladen. Ich kann bei Google Slides Download PPTX machen, und dann kriege ich was, was so halbwegs funktioniert.

[00:55:29] So, die Daten liegen natürlich am Ende in irgendeinem Storage, und da ist auch wieder diese ID dahinter. Was mir der SaaS-Anbieter niemals gibt, ist halt Zugang auf diese Daten. Ich habe keinen Zugang auf meine Daten, ich habe nur hier oben quasi die Vordertür, aber nicht die Hintertür. Und das ist die Architektur von allen SaaS-Anwendungen. Wenn die Anwendung nicht so ist, ist es vielleicht eher eine Managed-Service-Geschichte und nicht eine echte SaaS-Anwendung. Das liegt daran, dass SaaS-Anwendungen auf eine extreme Skalierung und Mandantenfähigkeit ausgelegt sind. Das heißt, ich habe niemals meine Daten auf meinem eigenen Server, auf meiner eigenen Platte, sondern ich teile mir das immer mit allen anderen SaaS-Nutzern. In dem Moment, wo ich Zugriff auf die Daten hinten rum kriege, heißt es, ich habe da irgendwie eine private Instanz. Dann ist es mehr so Managed Betrieb und nicht klassisches SaaS.

[00:56:39] So, wo ist jetzt das Problem mit Backup? Na ja, ganz einfach: Mein Backup Tool kann natürlich jetzt nur diese Sachen nutzen, ne. Also mache ich einen Download, pack das in mein Backup Tool rein. Und zurückspielen, Restore, ist natürlich ich nutze den Upload-Prozess. Soweit so einfach. Das Dumme ist, ich kriege eine neue ID! Weil immer, wenn ich da was hochlade, erzeugt es eine ID, oder? Und das ist halt die Crux von SaaS. Weil Backup und Restore ist nicht mehr idempotent. Auf einem Fileserver kannst du Backup und Restore zehnmal spielen und es hat sich quasi nichts verändert. Bei einer SaaS-Anwendung stimmt das nicht mehr. Das zweite Problem ist natürlich, meistens ist das, was du runterlädst, und das, was du hochladen kannst, nicht ganz deckungsgleich. Und natürlich das ganze Drumrum, das geht verschütt, ne, also die Konfiguration. Kennt ihr eine SaaS-Anwendung, wo man die Konfiguration runterladen, wieder hochspielen kann? Ich nicht. ClickOps. Gutes altes ClickOps ist SaaS, ne: Klick, Klick, Klick, Config, Config, Config, fertig.

[00:57:58] Übrigens, ne, wenn ihr Spaß haben wollt: Setzt mal das Thema Change Management bei SaaS-Anwendungen um! So Vier-Augen-Approval, harte Nachvollziehbarkeit... das geht gar nicht. Also, wenn ihr SaaS-Anwendungen killen wollt, dann nutzt Change Management als Axt. Ist einfach architektonisch nicht vorgesehen. Das führt uns direkt zur nächsten Herausforderung, ne, wir haben schon das Beispiel. Also ich habe hier meine Folie und die hat halt dann so eine URL mit einem kryptischen Code, die ID. Und jetzt stellt euch vor, wenn ich jetzt alle meine Daten nehme, dann habe ich ein Lego-Modell, so die Analogie. Und als Unternehmen lebe ich ja davon, dass alle meine Daten miteinander vernetzt sind und irgendwie was zusammenhängen. Jetzt mache ich eine Wiederherstellung. Dann habe ich plötzlich eine Million neue IDs. Das heißt, aus meinem Lego-Modell ist ein Lego-Haufen geworden. Und ich nenne das Shattered Restore. Sprich, ich kann Daten wiederherstellen, gehe aber von einem funktionierenden schönen Ding in einen Haufen Müll und kann mir da dann meine einzelnen Stückchen wieder rausfischen.

[00:59:13] Und die traurige Wahrheit ist: Es gibt keine Lösung dafür. Weil dieses Problem hat seine Ursache in dem Architekturmodell von SaaS-Anwendungen, was sagt: Die SaaS-Anwendung ist Herr über die IDs und du kannst von außen diese IDs nicht wieder einspielen. Und das ist eigentlich der architektonische, technische tiefe Hintergrund der ganzen Probleme, die wir haben. Ne, so ganz tief unten im Untergrund der Technik, das ist das Problem und das ist der Grund, warum SaaS und Backup und Wiederherstellung Blödsinn sind.

[00:59:57] Ich gebe euch noch ein paar Beispiele und paar Lösungen, sorry, ich habe zeitlich anscheinend bisschen überzogen. Also Beispiel Google Workspace Backup und Wiederherstellung: Good news ist, man kann was sichern. Bad news ist, man kann vieles nicht sichern. Das geht los mit: Es gibt Dinge, die kann ich nur exportieren, aber nicht wieder reinspielen. Und es gibt noch viel mehr Dinge, die kann ich nicht mal exportieren. Stellt euch vor, ihr baut einen Geschäftsprozess, der auf Formularen aufsetzt, und ihr könnt die nicht mal sichern! Krank, oder? Übrigens bei Microsoft genauso. Wer jetzt denkt: „Ah, ich habe Microsoft, kein Problem“, stimmt nicht, ist genauso. Ja, oder die Notizen oder die Webseiten kann man alles nicht exportieren. Das ist krank. Das weiß auch keiner, weil es nirgendwo an die große Glocke gehängt wird. Übrigens, ne, die ganzen extra Sachen, die bei Google nett sind, die haben nicht mal Backup oder so, da könnt ihr knicken. Ihr könnt euch das alles noch mal auf meinem Blog durchlesen, da habe ich mal einen Artikel zu geschrieben, Vortrag zu gehalten, das noch mal tiefer aufgedröselt. Die Story ist am Ende: Friss oder stirb. Es ist halt, wie es ist. Weil das ist auch SaaS, ne: Friss oder stirb. So, wer macht Foto? Ich hasse das, wenn dann Vortragende so ein komplexes Bild aufbauen und dann das finale Ding eine halbe Sekunde zeigen. Ist total doof. Also, ich mache auch immer Fotos, weil dann habe ich irgendwie so mein Memory, insofern ich helfe euch gerne. Genau.

[01:01:51] Parallelbeispiel Microsoft: Ich habe mal die API-Dokus durch zwei KI gejagt, das Ergebnis ist halt genauso mau wie bei Google. Ich suche aktuell einen Kunden, der möchte, dass ich meine präzise Analyse dafür fahre. Habe ich Bock drauf, weil ich glaube, dass wir hier noch ganz viel Erkenntnisgewinn erzeugen können, wie weit eigentlich Microsoft 365 genutzt werden kann, wenn man compliant sein möchte. Welche Dinge man vielleicht abschalten muss oder wie man seine Nutzer instruieren muss, dass sie halt bestimmte Geschäftsprozesse nicht überall ablegen dürfen. Das Ganze führt natürlich in eine handfeste Risikobewertung, die dann auch in der Exitstrategie münden kann, weil man halt mal eine klare Auflistung hat, was überhaupt exportierbar ist. Also ich würde gerne so ein Projekt machen. Ich suche jetzt einfach jemand, der das haben möchte, der glaubt, dass ich das liefern kann. Und ich kann das super gut liefern, weil ich habe es für Google schon gemacht in meinem vorherigen Job, aber ich mach's nicht für Microsoft als Hobby. Sorry, nee, habe andere Hobbys. Das heißt, wenn ihr jemand kennt oder eure Firma sowas brauchen kann, dann lasst uns nachher drüber reden, ich würde es gerne machen. Und wenn ihr fein damit seid, veröffentlichen wir das gemeinsam und machen eine geile Story draus.

Publikum: [01:03:13] Frage zu Google... bei der Lösung, sprichst du da von diesem Google Takeout?

Schlomo Schapiro: [01:03:23] Nee. Google Takeout ist kein Backup. Weil Google Takeout ist kein Backup, weil du kannst es nie wiederherstellen, weil du musst es manuell triggern, weil du kannst es nur alle X Tage und so weiter machen und nicht ständig. Und du kannst es überhaupt nicht automatisieren! Es gibt keine API, um es zu automatisieren. Dass es große Dateien sind, ist noch ein Ding. Also es ist halt nicht inkrementell, aber okay, dann lade ich halt 200 TB runter einmal im Monat, who cares, ne. Aber nee, du kannst es nicht automatisieren. Das ist ein manueller Prozess, den Google per Definitionen dir nicht anders gibt. Und es gibt kein Restore davon. Also, ja, genau, ne, also hier suche Projekt.

[01:04:01] Wer hat Jira und Confluence im Einsatz? Nicht alle, cool. Also das haben normalerweise alle. Das ist ein Screenshot aus dem PDF mit dem Jira und Confluence Cloud – das Verhältnis Nutzer und Anbieter erklären. Und natürlich steht da drin: Backups machst du!

Publikum: [01:04:36] Warum? Na ja, ist ja logisch, warum sie das schreiben, weil…

Schlomo Schapiro: [01:04:44] Nein, es ist... ihr müsst euch immer in den SaaS-Anbieter hineinversetzen. Das ist logisch, weil sie haben ein Backup-Produkt! Das könnt ihr kaufen, für richtig viel Geld. Wäre doch Quatsch, wenn sie das dir gratis geben würden. Der Witz ist nur, dieses Backup-Produkt ist totale Grütze, weil es ist nur intern, es sind nur 30 Tage, du kannst es nicht herunterladen, du kannst kein Single Item Restore machen. Guckt euch lieber externe Tools an. Die können zwar nicht mehr sichern, aber geben euch mehr Handlungsfähigkeit. Das ist real. Das habe ich nicht erfunden, das habe ich nur klick klick klick rausgesucht, die Links stehen unten alle drin.

[01:05:25] Also noch mal zusammengefasst: SaaS ist total cool, es löst einen Haufen Probleme und es macht unser Leben einfacher. Und es ist halt so ein kleiner Honeypot, man schlittert da leicht rein. Und die Kehrseite der Medaille ist halt, alles was weh tut ist in SaaS halt mit... wir geben den Besitz an unseren Daten auf. Und das ist die Falle. So, um zu verstehen, warum das so ist, müsst ihr euch in den SaaS-Anbieter hineinversetzen. Und was ich jetzt sage, stimmt für alle SaaS-Anbieter. Kein SaaS-Anbieter... ne?

Publikum: [01:06:05] Ihr vielleicht?

Schlomo Schapiro: [01:06:10] Baustelle. Genau. Also erstmal: Kerngeschäftsmodell eines SaaS-Anbieters ist „kaufe billig Storage und Compute, verkaufe es teuer mit ein bisschen Verpackung drumrum und noch Added Value“. Ist erstmal jedes... jeder SaaS-Anbieter macht genau das, ne. Erstmal kein Hexenwerk. Krasse Standardisierung und endlose Skalierung. Und die Standardisierung macht's halt einfach zu skalieren und ne, ich packe alle zusammen und dann kann ich halt skalieren nach Bedarf und so weiter. Also das ist immer Hand in Hand, Standardisierung-Skalierung. Und dann ganz wichtig: Data Gravity! Das heißt, je mehr Daten beim SaaS-Anbieter schon drin liegen, desto mehr Daten kommen da rein, desto mehr Zusatzdienste werden von dem SaaS-Anbieter gekauft, weil die Daten sind ja schon da. Also jetzt mal 10 TB Daten zur Analyse woanders hin kopieren, ist halt nicht so einfach. Dann kaufe ich die Analyse lieber bei dem SaaS-Anbieter, wo die Daten schon drin liegen, und spare mir den Transfer. Also denkt bitte an Data Gravity, wenn ihr über SaaS nachdenkt. Und ganz wichtig: Jeder SaaS-Anbieter spart sich die harten Probleme und wälzt sie auf die Nutzer ab. Das ist Teil vom Geschäftsmodell SaaS. Warum? Weil es geht. Die Kunden sind so doof, die kaufen das trotzdem! Ich ja auch. Ist so, ist harte Realität. Wenn ihr als SaaS-Anbieter erfolgreich sein wollt, macht diese vier Punkte, ihr werdet erfolgreich sein.

[01:07:46] Wenn ihr verstehen wollt, wie man mit SaaS umgeht, müsst ihr verstehen, wie SaaS-Anbieter funktionieren und dann könnt ihr halt überlegen, wie das ausspielt. So, noch mal ganz kurz in der Übersicht. Ich nenne das nicht... ich nenne das Graceful/Ungraceful Degradation. Ihr kennt vielleicht den Begriff Graceful Degradation, wenn man so Anwendungsarchitekturen baut, die halt quasi, wenn es Probleme gibt, dann immer noch was liefern und man halt überlegt, wie quasi so das Feature-Set kleiner wird. Bei SaaS und Backup ist es halt anders, ne: Wir gehen von einem wunderschönen Schloss auf einer Insel bei der Wiederherstellung in eine Halbruine. Und wenn ihr mal Disaster Recovery braucht, dann ist es halt nur noch so eine Holzhütte, die so tut, als ob sie ein Schloss wäre. Das ist einfach die Realität.

[01:08:39] Und der Weg daraus ist ganz einfach: Ihr müsst euch mit nicht-funktionalen Anforderungen auseinandersetzen. Je mehr ihr nicht-funktionale Anforderungen rund um SaaS-Beschaffung berücksichtigt, desto mehr kriegt ihr diese Dinge in den Griff. Ich bin gleich fertig. Und es tut weh, weil SaaS-Anwendungen beschaffen halt Business Units und nicht immer IT. Es wird ja manchmal gefeiert, ne, so „jetzt können alle was machen“, aber keine Business Unit wird euch diese nicht-funktionalen Anforderungen berücksichtigen. Ich habe übrigens hier ein Standard-Vorgehensmodell dafür, nämlich einen Kriterienkatalog für den Einkauf von SaaS-Anwendungen. Wenn ihr Interesse dran habt, können wir gerne ein kleines Projekt machen. Ich zeige euch erstmal das Ding und dann auch können wir drüber reden, wie man das einführt. Da geht's so ein bisschen... ich habe das Konzept Business und Technical Stakeholder genannt, sprich eine klare Verantwortungsverteilung zwischen Business und Technik über: „Wer muss eigentlich was machen im Kontext Software und Anwendung?“ Ist am besten ein Gespräch, was man so mit der obersten Führungsebene führt, nachdem gerade irgendein Projekt richtig schief gelaufen ist. Dann öffnen sich die Ohren dafür.

[01:10:01] Genau, wie kommen wir jetzt raus, ne? Ihr seid ja hier, weil ihr rauskommen wollt. Also wie zerschlagen wir diese Abhängigkeit? Und ihr seht, jetzt sind die SaaS-Anbieter nicht mehr ganz so happy, weil wir entwickeln Aktionismus und tun was für uns selber. Und in meinen Augen gibt's einen klaren Weg in die Souveränität hinein. Und der allererste Schritt ist die Daten, ne, wir haben ja über Besitz und Eigentum gesprochen. Also fangen wir mal damit an, uns den Datenbesitz zurückzuerobern! Das ist das Allerwichtigste. Der zweite Schritt ist dann natürlich, mal über die Prozesse und den Betrieb zu reden, also eine technische Souveränität. Der dritte Schritt ist dann auch, sein Schicksal in die Hand zu nehmen. Das Problem heute ist, wir können ganz oft nicht entscheiden. Also eine Entscheidung, nicht Microsoft zu nehmen, ist meistens nicht realistisch und nicht möglich. Das heißt, wir haben keine Entscheidungsfreiheit. Die Rahmenbedingungen und Umstände, die schreiben schon das Ergebnis fest. Und im Kontext Souveränität ist mein Ziel natürlich, dahinzukommen, dass wir dann frei entscheiden können. Und um das zu tun, müssen wir halt mal mit der Datensouveränität anfangen. Der Rest kommt danach. In genau dieser Reihenfolge, nicht andersrum. Also die Möglichkeit, selber sein Schicksal in die Hand zu nehmen, ist das Ergebnis von harter Arbeit davor und der Datensouveränität und der technischen Souveränität.

[01:11:40] So, Lösung für Microsoft und Google Backup ist tatsächlich ein Synology NAS. Das ist ein Ergebnis aus meiner Analyse von 2022. Also Synology und QNAP haben beide eine Backup Software drin, funktioniert leidlich gut. Ist eine Lösung, die erstmal so eine Art Grundschutz schafft, sichert halt nur Mail, Kalender, Kontakte und Drive. Mit allen Einschränkungen, die damit einhergehen. Aber wer das nicht hat: Kauft es bitte! Tut euch den Gefallen. Das ist nicht teuer im Vergleich zu dem, was ihr kriegt. Und auch hier kann ich euch gerne helfen, das Konzept für eine größere Umgebung zu validieren. Also ich habe das natürlich für mich zu Hause, ich habe das auch für eine kleinere Firma mit 1000 Nutzern gemacht, das skaliert super bis 1000 Nutzer. Darüber hinaus weiß ich nicht, schaue ich mir gerne mit euch zusammen an. Wer nichts hat, bitte nehmt das! Es ist das beste Preis-Leistungs-Verhältnis, um da einen Grundschutz herzustellen. Die Dinge sind nicht so teuer und sie haben eine gute Software drin.

[01:12:48] Anderes Beispiel: Wir leben ja im Zeitalter von KI. Und wir hatten bei Tektit das Problem, wir nutzen so eine SaaS-Anwendung für die Zeiterfassung, ne. Als Consulting verkaufen wir Zeit. Das heißt, ohne Zeiterfassung schreiben wir keine Rechnung. Und unsere Zeiterfassung ist eine SaaS-Anwendung. Kein Backup logischerweise, ne? Ist für uns blöd, weil kein Backup heißt, wenn es knallt, schreiben wir keine Rechnung mehr. Also der Bezug zu „unser Geld, Business, Technik“ ist direkt. Die Lösung war dann: Ich habe mit Cursor AI und so einem Fuffi und ein bisschen Hintergrundbeschäftigung während langweiligen Meetings einfach ein Backup Tool geschrieben. Und das total easy! Das hat richtig gut funktioniert, ist natürlich Open Source und verfolgt den Datenbesitz als Ansatz. Und ich habe mich ganz bewusst dafür entschieden, die Wiederherstellung mache ich in der Zukunft, wenn ich weiß, wo ich und wie ich wiederherstellen will. Ich habe mir erstmal nur einen Export gebaut, der einfach jede Nacht läuft und mir die Daten sichert. Und es sind JSONs, ne, so ganz banale JSONs. Und ich weiß, ich kann, wenn ich dann ein neues Tool einführen möchte, wieder mit einem Fuffi in der KI mir halt den Importer schreiben, der diese JSONs, die ich schon habe, in das neue Tool reinlädt. In perfekt und hübscher Qualität mit Schleife. Und weil es so billig ist, muss ich es nicht im Vorfeld machen, sondern kann mich drauf verlassen, dass ich es dann in Zukunft machen kann, wenn ich es auch brauche. Und das ist übrigens eine Errungenschaft, die KI uns gerade gibt. Das ging vorher nicht. Ja, vorher hätte ich hier ein Entwicklungsprojekt mit Engineers und lalala gemacht, und es wäre tausende Euro. Also die KI ist hier der krasse Enabler schlechthin. Kunden, Projekte, Zeiterfassung, ne, also Stunden und so, dann die Rechnung, die Spesen, die wir noch erfassen müssen. Dann schreiben wir mal ne rein, was wir gemacht haben, was dann auf der Rechnung auftaucht. Das sind wichtige Daten. Es sind am Ende nur JSONs. Aber jetzt habe ich halt die Daten, vorher hatte ich sie nicht.

[01:15:12] So, ein weiteres Beispiel hier aus dem Hause Heinlein ist die Folie für Peer. Und ich find's cool, dass Peer eine Lösung geschaffen hat. mailbox.org hat ein Disaster Recovery Add-on, mit dem mailbox.org als Notfall-Groupware für eure quasi Umgebung fungieren kann. Es funktioniert so, dass man in mailbox.org dann quasi so eine Art Schatten-IT vorbereitet für den Fall, dass eure primäre Groupware ausfällt. Und dann kann man ganz schnell dort Nutzer aktivieren, die dann in Mailbox arbeiten und kommunizieren können. Ist super günstig, kostet echt nicht viel. Also Taschengeld, wirklich. Und erst wenn man es benutzt, dann zahlt man halt normale mailbox.org-Gebühren. Das ist ein ganz klassisches quasi Versicherungsprodukt, was euch hilft, die Kommunikation und Kollaboration im Unternehmen abzusichern. Und das ist ein konkretes Beispiel, wie man halt seine Microsoft 365 oder andere Groupware absichern kann gegen Ausfälle, gegen katastrophale Ausfälle. Auch hier, ich helfe euch gern, so ein Projekt umzusetzen, weil das genau wieder der Ansatz ist: Wir automatisieren blöde Sachen weg, um Handlungsfähigkeit zu erzeugen für unsere Unternehmen.

[01:16:33] So, jetzt müssen wir mal zur Sache kommen, ne? Wir haben gesagt, wir müssen die Daten wieder zurückholen, und ich nenne das Data Jailbreak, ne? So wie ein Handy, wir brechen die Daten aus dem Gefängnis der SaaS-Anbieter heraus und verwandeln sie in offene neutrale Formate, mit denen wir dann unabhängig agieren können. Und erzeugen die faktische Handlungsfähigkeit, damit zu tun, was wir wollen, wann wir wollen, wie wir wollen. Und das ist die Versicherungspolice! Eine handfeste praktische Police, die zahlt euch nicht Geld, die rettet euer Unternehmen, weil ihr die Daten habt. Wenn man das alles macht, kommt man zu einem Ding, das nenne ich Rettungsbootarchitektur. Und das ist mein Konzept für SaaS. Ich nutze gerne SaaS und ich kümmere mich um meinen Datenbesitz. Die Idee ist einfach: Wie so ein, ne... ich fahre auf einem Kreuzfahrtschiff und bringe mein eigenes Rettungsboot mit und das tuckert da hinterher. Und ich sorge einfach dafür, dass ich von allen SaaS-Anwendungen meine Daten halt selber habe. Und der Preis der SaaS-Anwendung ist nicht nur die Lizenz für die SaaS-Anwendung, sondern auch die Datenextraktion in meine eigene Hoheit. Das gehört zum Preis der SaaS-Anwendung dazu! Wenn ich das mache, kann ich guten Gewissens die SaaS-Anwendung nutzen und von den ganzen Vorteilen profitieren. Übrigens, ne, wie immer auf meinem Blog.

[01:18:05] Und das ist für mich der Weg, diesen Konflikt zwischen SaaS und „unser Überleben sichern“ und „verantwortungsvoll mit SaaS umzugehen“, wie wir den halt auflösen. Das ist mein Ansatz und ich glaube, ihr könnt diesen Ansatz nehmen und überall applizieren und damit eure Umgebung sicherer und besser gestalten und nebenbei auch alle regulatorischen Anforderungen natürlich erfüllen, ne. Sei es jetzt KRITIS oder Finanz oder Datenschutzgrundverordnung oder was auch immer euch umtreibt. Und es ist nicht teuer. Also sorry, einen Fuffi bei KI einwerfen, um ein Tool zu erzeugen, ist doch echt billig. Und dann ist es halt vielleicht einer, weil es ein größeres Tool ist, aber ist immer noch billig jetzt im Vergleich zu was man sonst hätte dafür zahlen können vor ein paar Jahren.

[01:18:53] Also wenn man das alles zusammenfasst, kommen wir zum Thema: Kennt ihr eigentlich eure Unternehmen? Wisst ihr, was für euch wichtig ist?

Schlomo Schapiro: [01:19:10] Ich meine, ihr seid eine Bank, ihr wisst es hoffentlich.

Publikum: [01:19:10] Aber alle anderen auch, ja, ihr müsst es wissen. Genau, genau.

Schlomo Schapiro: [01:19:17] Aber alle anderen sollten es vielleicht auch wissen. Und noch mal auf die Analogie zurück, ne, wir haben ja dieses Problem mit der teilweisen Wiederherstellung, und ich glaube, es gibt halt in der Mitte diesen goldenen Kern eines jeden Unternehmens. Den muss man wirklich gut kennen, verstehen, und für diese wichtigen Dinge, die das Unternehmen am Leben erhalten, die dafür sorgen, dass das Geld auch morgen noch reinkommt, dass wir alle einen Job haben, dass das Unternehmen weiterlebt, dass wir noch was tun können: Dafür müssen wir die No Restore Solution implementieren. Als Konzept, aber auch nur dafür, für den wichtigen Kern! Für alles andere brauchen wir es nicht. Diese Unterscheidung zwischen wichtig und unwichtig, die ist extrem wichtig und wertvoll.

[01:20:03] So, fassen backward wir zusammen: Wie kommen wir jetzt zu digitaler Souveränität? Wie führt das zu einem Ausstieg aus der SaaS-Falle? Also erstmal: Die grundlegenden Konzepte Backup und Disaster Recovery auch für SaaS umsetzen und berücksichtigen. Die No Restore Lösung aktivieren für alles, was wichtig ist, weil da haben wir nicht die Zeit für langfristige Wiederherstellung. Und der Masterplan sieht so aus: Erstmal Lifeboat, ne, wir schalten erstmal unser Rettungsboot ein und stellen ein Backup von allem her, zur Not mit KI und dem Backup Tool, was wir halt schreiben lassen. Seid so nett und macht Open Source, dann haben andere auch was davon. Ganz wichtig: Instant-on Recovery für Kritische Infrastruktur im Unternehmen, nur so könnt ihr überleben als Unternehmen. Und der Rest ist halt Kollateralschaden, akzeptiert es! Akzeptiert, dass ihr nicht alles wiederherstellen könnt. Ist so. Ist einfach die Konsequenz von SaaS, aber ohne SaaS schaffen wir auch nicht.

[01:21:22] So, das hier, ne, Backup alles, ist jetzt der erste Schritt, könnt ihr Montag gleich machen. Wenn ihr Hilfe braucht, wir helfen euch gerne, ist nicht schwer, aber wenn ich das mache, dann ist es Open Source, ne, also... Das Zweite ist natürlich die Triage von: Was ist eigentlich wichtig in eurem Unternehmen? Wenn ihr das noch nicht gemacht habt, macht es bitte. Das ist ultra wertvoll und bringt euch weiter. Und damit habt ihr einen Masterplan in die digitale Souveränität hinein.