Digital Sovereignty Is More Than a Piece of Paper: Why Backup Is the Only Way Out of the SaaS Trap
We celebrate our "Cloud First" strategies and lull ourselves into a false sense of security because our contracts guarantee us "ownership" of the data. But when the plug is pulled - whether by technical outages, geopolitical tensions, or a blocked credit card - the brutal truth is revealed: We have ownership, but we do not have possession. We are tenants in our own business, and the landlord has changed the locks.
Digital sovereignty does not mean avoiding the cloud. It means having the choice and the ability to leave or continue operations at any time, even if the cloud is no longer there.
In this talk, we dismantle the "Sovereignty Illusion" of modern IT architectures. We expose why SaaS services are technically often "No-Restore" environments and why regulatory compliance (DORA, NIS2) is no guarantee of actual operational capability.
The solution is surprisingly pragmatic: We use classic Backup and Disaster Recovery methods not just for emergencies, but as a strategic tool to reclaim our data sovereignty. We demonstrate concrete architectures for freeing data from the SaaS trap ("Data Jailbreak"), neutralizing it, and transferring it into your own "possession" - ideally onto your own servers or independent infrastructure.
This session is a wake-up call for everyone who doesn't just want to believe their data is safe, but needs to know it.
We at Tektit Consulting are happy to support you in developing your own SaaS data jail break and take you on your journey towards greater data sovereignty. Let us start together with a brief SaaS backup discovery to develop your individual roadmap.
Transcript
Schlomo Schapiro: [00:00:00] Digital sovereignty is more than a piece of paper, and the way out of the SaaS trap is simply backup and disaster recovery. And today I want to tell you a bit about why this huge topic doesn't actually hurt that much and how we can focus our attention slightly more on non-functional requirements when dealing with SaaS in order to solve fundamental problems and challenges for our companies and organizations. And actually to help them use SaaS sensibly without putting all their eggs in one basket, without only having the risks. So my goal is actually: use SaaS without regretting it later. Because I actually believe you won't get rid of SaaS, and I'll show you a few reasons why SaaS has its right to exist and it's just there.
[00:00:56] Just briefly, right: We love SaaS. Well, I actually like SaaS. I don't feel like being an admin all the time anymore; I did that long enough and at some point you don't want to anymore. Small intro: Backup, Disaster Recovery. It's really just a small intro; it's about the other things then, of course.
[00:01:21] Trap: SaaS is a trap, how do we get out? Data Jailbreak as a buzzword. And very importantly: I want to familiarize you with the concept of a Minimum Viable Company. So what is actually the core of your company that matters? And of course, a master plan here: How do we move forward now? What are we doing tomorrow? What can you do tomorrow... okay, maybe Monday after the holidays... what can you do Monday to ensure that you are doing the right things, nudging the right things?
[00:01:58] So we need SaaS. And yes, I believe in SaaS. I did admin work long enough and it's a great job. And when I went to ImmoScout, I suddenly realized I didn't have to tell customers how awesome IT works anymore by going into my basement via VPN and demonstrating my server there. Because at ImmoScout, I had a data center instead of a server. And back then, I went completely to Google with my private IT, Google Workspace – G Suite at the time, it was still free. With that, I disposed of the entire email, PIM, groupware, everything stack that was running in my basement (including DNS) and never regretted it because it saved an extreme amount of time. I was already in the legacy trap, back then it was still SLES 10. I sat out the updates until the bitter end, of course. And those who still know the old world, moving to SLES 11... it's just not that easy, you had to rebuild a lot and it was also big and relatively complex, of course. All manual operation, because back then I wasn't so modern with automation, right. I only started printing the T-shirts about 10 years ago; this is all nearly 20 years ago now.
[00:03:14] And I stand by the decision, and for my family, the switch to Google Workspace was exactly right. And so to speak, we have profited infinitely from the SaaS thing. First of all, I got it for free for 10, 15 years (G Suite 10 users free) and when it started costing money, I gladly paid for it because it's worth it. The money is much less than what I would otherwise invest in admin for my own stack, and so it's still worth it for me. And I'm talking about my family as an example, but you can also read on Heise: G Suite no longer free? Stop whining, Google makes the best offer . That caused a huge outcry back then.
[00:03:59] And I believe my personal example is just representative of what takes place in most companies as well. Namely: You can no longer manage IT tasks alone with one or two admins in the basement. I mean, by any stretch of the imagination, you can't anymore. That means we, right, are this dude – we are also being courted by the SaaS providers. They make an effort and they do it well. And in the end, we get something out of it too, so it's kind of a win-win story.
[00:04:33] Just as an example of what we want, such a banal example is: We want a flying car, right? Who doesn't want that? I want a flying car, I hate driving, I hate standing in traffic, I hate those hours on the highway. I would love the flying car, it's totally cool, my dream too, exactly in the keep-it-simple version. Yeah. The reality is, of course, if you built it yourself, it would look something like this: a bit stressful, a lot of work (right, they're all sweating) and it's somehow highly complicated. I don't know, have you ever seen Laputa? It's a Japanese cartoon about a flying city. Yeah, it's in that style and they're all working like crazy, but they have a flying city.
[00:05:22] The SaaS reality looks like this: Up here everyone is happy, underneath is the complex machinery and how it reaches us is of course like this, right: We fly on clouds and that's it. And that is the SaaS story, and that is a success story in the economy and in the market. And that's why it has its right to exist.
[00:05:43] And today we all live in this bubble, whether we want to or not. Right, you all have a cell phone or such a smartphone with no buttons. Right, so "real men have buttons" is long over. So today we all have a smartphone without buttons. Exactly, today you can only say "real men have HDMI ports," but even that will soon be over.
Audience: [00:06:09] (Laughter)
Schlomo Schapiro: [00:06:18] But uh, right, it's just the way it is. And anyone running around without a smartphone today or, I'll say, with a "neutral" smartphone, is quite consciously forgoing many achievements of modern times and saying: "No, don't need it, don't want it, have somehow a different trade-off." And you are on a lonely island with that, right. I meet these people very, very rarely and I admire it, because unfortunately I don't put myself through it. So I see the value, I see the point, and then I say: "No, in my own risk assessment, I'm not that far."
[00:06:53] That means we all live in this SaaS bubble. And that is a fact. Because we cannot change the fact, we have to work around it. And that is actually the story I want to sell you today: How do we work around it?
[00:07:03] So here's a super pragmatic example. And I suspect you've all asked yourselves this question. I have somehow... you take photos. Smartphones now also help you take photos. Then you have lots of photos. And since Google broke the location history thing, I use Photos as my location history. That means I just take photos and then later I see on the map where we were. Super practical. And I can zoom out later, oh look, I took a photo there, oh we were there 10 years ago, that's cool.
[00:07:44] And if you look at it: 8 TB, 300 €, right, one drive, so easy. Plug it into a PC, put some software on it, done. Maybe it's not that great after all. Then you could take a Synology . I researched earlier, so now for 1100 € you get the Synology with real Synology drives and then you have your 8 TB of redundant storage there. And by the way, there's software on it that manages photos and automatically uploads the photos from the cell phone. That works really great and suddenly you have your self-sufficient non-cloud photo archive with modern features like face recognition and a map and all sorts of features you'd like to have.
[00:08:31] Or you go with what your cell phone comes with, there's Google and Apple which are roughly on the same price level for the 8 TB, you pay a whopping 600 € a year. Every year. If you don't pay anymore, then you also won't have the photos anymore at some point, right? So it's quite a commitment, a real commitment. And I know plenty of people who do exactly that, right, whether with Google or Apple it doesn't matter. I know plenty of people who live completely in the Apple ecosystem, have terabytes of data, photos, their whole life there and also no exit strategy. And a very bad dependency by the way, much, much worse than everything we are discussing here.
[00:09:26] Exactly, you could also be a pro and say, I'll take Adobe . It costs a bit more, has even more features. I even had to call to find out the price, it's not on the homepage anymore, really.
[00:09:42] What do you have here in sum? You make a tradeoff between sovereignty and control, which is of course very high with the drive on one hand, and convenience and features on the other. Right, so it's clear now, right, Adobe Photo Cloud has features till you drop, we can't keep up with that here on the left with "homegrown." In the end, you always decide between effort and money. It's always the same game and every discussion about SaaS or IT or anything can be broken down exactly to this point. That's you or your boss, who doesn't know any better either. So you can whisper something and that's it: It's always money against effort. Time against money, right, your time, other people's time. Or just less effort, but also fewer features, fewer capabilities.
[00:10:43] Exactly, just to wrap this up, there is also Immich , and hosters for it, there is also Ente , another photo thing, quite new. There are other solutions, they're all cool. Currently, for example, I use Synology as an additional backup layer for my photos. Primarily it's here and I pay a bit more than that, but for the whole family. Also no secret, we have 10 accounts times 160 € per person per year. For that, however, we have 20 TB of storage, so storage comes out of the socket, so to speak, and is never gone, because it's my understanding of modern life, right? Power comes from the socket, network comes from the socket, mobile data, it all comes from the socket. I don't want to deal with it running out anymore. That's what development is good for.
[00:11:38] Exactly, and I use it as a backup and invested in that a few years ago and I'm super happy with it. And it just shows that even as a private person you have to deal with these topics nowadays. You can't ignore it and that's a bit of a challenge. I quite often have conversations with people and then I tell them a bit: "Well, all your logins depend on your blabla@icloud.com or @me.com or whatever address. Do you actually realize that it could be gone at any time? And how do you get into your things then?" Really, and then we talk about own domains and why you need your own email and lalala. That affects everyone. And that's why it's a matter close to my heart to talk about digital sovereignty in the context of backup and disaster recovery, because that simply represents the solution for everyone. So, let's talk about the companies, right, enough about private nonsense.
[00:12:44] So the fundamental problem, every IT landscape looks like this at its core: right, we have admins, we have servers, we have networks, we have lots of networks, because as long as people are sitting in the office, it just doesn't work without a network. And things like printers, PCs, laptops, you also have to look after them. And that is perhaps a core task of IT departments in companies, namely ensuring that all employees can work properly. For that, I have to put technology on their desks and then in the back make sure that the technology can do something. Stupidly, there are also a lot of specialist applications around it that also exist. Now comes a quiz question: Who can resolve all the abbreviations? If you don't ask now, I assume you can resolve them all. ATS, Applicant Tracking System, it's about recruiters, recruiting management... jokes aside, I've done a bit of research and a bunch of them have also encountered me in consulting practice or in various roles in different companies, and I've been allowed to introduce them.
[00:13:59] The reality in IT is: every specialist application, every department needs something. And that leads to a lot of problems, because in the end it's like this: IT drives the business. IT is central and integral to everything we do. There is no corner in the company that doesn't do something with IT, that can work because of IT. Yes, even the caretaker service has a ticket system and if the tickets don't come, then the caretakers have no work either. So IT drives, controls and manages. And that means in reverse, every business unit of course needs its own IT solution. And you cannot be a little king in the company if you don't have your own application.
[00:14:53] Well, it's also a sociological, cultural, political, organizational problem. If you are a company and have 100 people but no specialist application, who are you then? This too of course leads to more applications logically. And because IT drives innovation, or innovation is based on IT, applications are of course also becoming more special and complex and complicated. And while you are talking and just thinking about the zoo you already have, the next business unit has of course already introduced another application. Through the back door, right? Shadow IT has become even worse because of SaaS, because anyone with a cost center can now introduce IT, and they do.
[00:15:49] All this first of all leads to silos, because I as a cost center owner of a business unit of course first of all make IT for myself, not for the company, and solve my problems. And then I don't care how well it's integrated with other things, so I have a silo. And for us IT folks, that creates problems without end. Problems, problems, problems.
[00:16:14] Now you ask yourself: What has that got to do with SaaS? Well, only because of SaaS can we manage that at all! Managing all that without SaaS is hopeless, just doesn't work. And that is exactly the point why I believe SaaS is indispensable in the world. SaaS is a success model for users, for customers, because they actually derive many advantages from it. One thing is: I simply have clear predictability. I have a problem and I only pay for the solution to my problem. And I don't pay for: I build an IT team that somehow learns a new application and creates a lot of overhead. And converting this CAPEX to OPEX is extremely valuable for companies because it shifts their economic basis, away from large investments towards more running costs that can also be reduced in an emergency. Right, if I have a SaaS application that is paid per user, then I just kick half of them out and I've reduced half the costs. If it was an on-premise application, then I already have the investment in the basement and I can't even save half. Sounds harsh now, but folks, that is an argument from an employer's point of view. Even if it hurts us, it is an argument and that's how the economy thinks. For the economy, investment costs are like "concrete gold," a problem. And many companies want less hardcore investment and more running costs. And that's where SaaS plays perfectly.
[00:18:02] The other thing is of course flexibility, yes. I have much less lead time to introduce a new application. I have much fewer integration depths, efforts, technical pains, right. A credit card is enough, we can start working. Those are hard advantages for SaaS. And the world needs that and uses it. Again, those are the reasons why we won't get rid of SaaS. And very importantly... oh, this one is also important by the way, right: Only because of SaaS can everyone use awesome software, so to speak, because this scaling from small to large is just there. So let's take an example, right, I use Google Workspace, a huge groupware solution. An alternative would be Open-Xchange (OX App Suite). Does anyone know that, ever heard of it? Do you know how much effort it takes to operate Open-Xchange? Do you have that? Yes, yes. How many admins do you need for it?
Audience: [00:19:04] (Unintelligible) ...maybe...
Schlomo Schapiro: [00:19:08] ...to change the light bulb? Joke. So I also know Open-Xchange, I know it from larger environments too and it's just nothing you can operate as a small application. It's a big thing. Yes, and I definitely couldn't operate it for myself at home, no chance. Really hopeless. But if I want to have really good PIM software now or a groupware, then I have to solve the problem. And that's where SaaS... reduces this entry barrier, I can simply use it. And I therefore believe that SaaS solves this "everyone can use good software" problem. Yes, the tradeoff is dependency and strong coupling and so on, but you get a solution first. And if I want a solution and need it right now and my company is finally supposed to take the next step, then maybe I prefer that.
[00:20:13] Very importantly: companies often have a focus problem. Get bogged down in a thousand things and deal with a thousand things that are not their core business. And SaaS solutions, especially in IT, actually help to bring back the focus to one's own value creation, the core value creation, by saying: everything that is not our core value creation, we do externally. And whether I commission a service provider to maintain servers for me or buy in a SaaS provider to just provide the software is almost the same. There's no big distance, right. I have a big loss of control in both, I don't have much of a say anymore, I simply use it. If it doesn't work, then I can go there and complain, and they ignore me. It's no big difference. And everyone who has dealt with a large municipal data center, I believe you can all... I wouldn't be surprised if you say: "So with SaaS I have better quality." Yes, those are simply... that's just how it is, right. Exactly, and that's the reason why SaaS is a popular, so to speak welcome, successful solution for all the corporate applications that we just need. It is what it is.
[00:21:31] So, how do we deal with it? And to understand that, I unfortunately have to take you on a small excursion towards backup and disaster recovery. This is a talk (video on YouTube) from last year, which is quite intense and extensive. You can watch it on YouTube . What I have here are just a few small excerpts from it that now specifically pay into our SaaS topic, so to speak. But there's much more one can put oneself through regarding backup and disaster recovery, check out. Therefore, my recommendation: watch the video. If you just type in the title, YouTube will spit it out for you.
[00:22:19] And perhaps the most important point is again a basic understanding of Business Continuity or the ability to continue one's business. I thought about how one can actually define it. I'm a big fan of definitions. One definition, summarized: we just stay in business. And this "no matter how" is the decisive point. For a company, it is extremely important to survive in crisis situations. And for KRITIS and cities and so on, right, naturally much more so, but also for every company it is an inherent noble task, challenge and duty to secure its own survival. I think that's undisputed, right? Starts with job security and ends with investors who don't want to see their money swim away.
[00:23:36] So, another quick look at the basics. And I hope you all know it already. It's simply important to me that we talk about the same thing and mean the same thing. So, a timeline, a time axis, and of course at some point you make a backup or want to. All backups, yes, I'm coming to that. Oh very good! So make another backup, and another backup. And as it is with Murphy, exactly while the backup is running, things go bang. It doesn't go bang between two backups. It goes bang while a backup is running, otherwise it would be boring. Exactly, then comes Headless Chicken Mode, chaos, somehow magic, we do something. And then we've managed a partial restore because we are cool admins. And then there's reworking, and then we've managed a large-scale restore, and life goes on. The rest was collateral damage. So much for the basics.
[00:24:41] Very important terms: RPO, Recovery Point Objective, you absolutely have to use when you talk to people about it, because otherwise strange ideas arise in people's heads. And I always remember it: how old is the stuff we are restoring? So, travel into the past. And the other thing is of course the Recovery Time Objective (RTO). So, how long does it take at all? And because I always can't remember what RPO and RTO was, I thought: so the RPO is what we have in our pocket, right, and that's what we start doing something with. And the RTO is what we then do. So having and doing is RPO and RTO. And now I can remember it. And for me, that image is the basic position of the dance. We'll come back to that later. When you talk to people about backup and disaster recovery, please always talk about this image and use these terms and ask people: "How much travel into the past can we allow ourselves? How much is it worth to you to travel less into the past?" Because it's even worse, you have to coordinate 426 systems with each other. I have a slide for that later, of course. It used to be simple, right. It was simple when we had a server in the basement and it did everything.
[00:26:16] Exactly, so the next ultra-important thing you have to explain to people over and over again – and there's unfortunately no way around it: Backup is not emergency recovery. They are two different pairs of shoes and they are fundamentally different. And having one by no means means you can also do the other. So, I hope I'm not surprising anyone. Restore is always an individual thing, right? When I do a restore, I restore a file, a LUN, a server, an anything. Right, restore is individual. And emergency recovery, disaster recovery, is in contrast always everything. So not one file, but all files. All LUNs, all servers, all data centers, whatever your scaling is right now. All users. This transition from "individual" to "many," that is the difference between backup and disaster recovery. And when you start talking about it, you suddenly notice that maybe the backup strategy is really just a backup strategy and includes neither restore nor disaster recovery.
[00:27:39] Because this individual restoration story always takes place if the ingredients for it are still there. So, I restore a file if the file server is still there. I restore a LUN if the storage is still there. That means this restore always has the context of "my world still exists and I maybe accidentally deleted something." And the disaster recovery takes place exactly when all that is not there. I have to restore all servers because, well, they are not there. And that's why the problem with disaster recovery is: we have no time. And time is the biggest problem in disaster recovery. So here, time is the biggest enemy of everything at that point. And then we talk about an RTO of one day. One day, right? But we don't have all that: no server, no storage, no data center, no internet. But on that day we are live again, right? So that's the challenge of disaster recovery and why I find disaster recovery much more exciting than backup, actually. So here is where the music plays.
[00:28:52] So, I've thought of three principles to enclose the whole thing in framework conditions. So very important: Backup is there to enable restoration. Backup is a means to an end, restore is the goal. That's why every discussion of mine starts with "Tell me how the restore works, and then I'll tell you which backup you need for it." Not the other way around. And when you start talking and thinking like that, you suddenly notice that you get requirements into play that were unclear before.
[00:29:32] Now of course the escalation, right: A comprehensive backup and an automation of restoration lead to disaster recovery and that leads to business continuity. In exactly this order. That's why I run around in "Automate" T-shirts, because automation is just the way we get into the scaling from that one thing to "all things." That's just too much for manual operation. And the third, very important and always a surprise: Please use the same backup to enable restoration and emergency recovery. Exactly the same backup! Because you already have a copy of the data, don't need another one. Also super expensive otherwise. So those are my three principles to actually get backup and disaster recovery holistically under control.
[00:30:25] Now let's look very quickly at a few challenges. So number one: Time. Time is our greatest enemy and it's always running away from us. And by the time we've started working, half the time is already up. For example, right: 140 TB SAN, is that big or small? So, opinion?
Audience: [00:30:45] Small.
Schlomo Schapiro: [00:30:46] Small. Right, it's small. The stark truth is, 140 TB SAN is small. It's... I can still remember how 140 TB SAN, that was like, yeah, at the university you might have that. But otherwise nobody had it. And today it's somehow small. LTO9 is still widely distributed and sort of the gold standard. And now imagine that fails. If you calculate that, you come to virtually 5 days just copying (and nothing goes wrong), to rewind this whole thing. Banal mathematics. Sounds good at first, right? Yes, wait, wasn't there RTO one day?
[00:31:35] More exciting question is: First of all, is a week okay at all, regarding restoration? Secondly: What is the company actually doing externally while we are dealing internally with the restoration and nothing exists? Perhaps all the ground is already slipping away from us externally. Or how long does it actually take to get a new SAN and install it in the basement before I can even start this week of restoration? And my favorite question, from the automation glasses, is of course: Can I somehow test and validate that? How do I know that I'll manage? How do I know that this technology works? Well, I haven't tried it out. We had promised the provider that it would work like that, but had we tested that? Sorry, I know really few people who test that regularly. Very few companies afford themselves that. So a bank maybe or a pharmaceutical company or so, that somehow have hardcore requirements, such compliance requirements, but which normal company tests that at least once a year? It's not feasible, in my eyes. So it's a real problem, yes. It's somehow, you should do it, that's totally obvious, but in reality it's difficult.
[00:32:54] So what is the SLA of all that now? And I always say, that's RPO plus RTO and praying, hoping and a lot of luck. Right, that's the factual SLA of the restoration process. And that is of course an unknown. And how do we get this unknown out now? Because my goal is to beat time in the whole game. And the idea is totally banal: Well, if I get rid of the restore in my process, then I can beat the RTO. And these uncertainties. And the way to beat it is through automation. So I do it every time, right? Every backup I restore immediately. Somewhere else. If I've done that, then I have a spare system that I can use. And then my process changes from "I try out whether I can restore" to "I switch over to an already restored system that simply works." And thus I can create a fixed RTO that I have also tested and validated, with a hard promise through a real test. Sounds simple and is really hard. Please don't be fooled by the fact that I tell it so beautifully here. It is hard.
[00:34:21] You need resources. But you have virtualization, that helps a bit. For some things, not for everything.
Audience: [00:34:30] Yes, it could be that a jumbo falls into our airport. At the data center it is...
Schlomo Schapiro: [00:34:44] Yes, if you look at DORA and the BSI law now, it's in there. It doesn't say where you get the money and how you should pay for it, it only says that you have to do it! Exactly. Transferring it once again to the original image, right. So I call that the No Restore Solution, because it just takes the restore out of the emergency process. And we have the backups of course. The difference now is, after the backup comes the restore, the validation, then I have my recovery system lying around already. And yes, that is sometimes difficult, resources, effort, money, whatever, but the basic idea, that is actually valid and works super well. That gives me first of all a possibility here to check whether my backup and my restore actually work.
[00:35:35] I can tell you from my own experience, that is not a self-evident point. We experienced it live during ImmoScout times. Back then we had Subversion (SVN) and built a great backup system around Subversion. And then we once said, let's automate and test the restore. And then it turned out: our Subversion could not be restored! Because there was a data error somehow 10 million revisions back and everything after that couldn't be restored. And we then had to have a developer from the Subversion team come, so to speak, who repaired our Subversion with a hex editor. And we only found that out because we did this automated restore test. Imagine if we hadn't done it and we had needed it once and only then noticed, restore doesn't work, is broken. So for me that was truly the lesson learned: what you haven't tested is probably broken.
[00:36:36] Exactly, right. Then comes the backup, it goes bang, that's all like before. And then I just switch over. That goes fast. And then I have my recovery time fixed, independent of the amount of data, the amount of systems and whatever. And así I have a fixed RTO, which just depends on my architecture effort and no longer on the amount of data or the systems. And that is the No Restore Solution. That is a basic concept, an architectural concept so to speak, that you can apply to many things. And it is my recommendation: use this approach to actually make your emergency recovery concepts testable, provable and also reliable. And to really comply with the required restoration times, not just as nice paper on the wall, right. Hence the title of the talk: Digital Sovereignty Is More Than a Piece of Paper. That is automation that one has to build.
[00:37:37] So, let's come to the next challenge for all KRITIS friends here. We are in Germany. And in Germany there is regulation. And it determines our lives. No matter what we do and no matter where we do it, regulation determines our lives and we don't get around it. I've summarized that once. All the regulation can be wonderfully summarized, I call that the eleventh commandment of IT: it simply says, you have to do your stuff properly. There is no way around it. And yes, one can formulate that nicely biblically, I just say: do it properly. Take care of the difficult things, take care of the difficult things in time, and then all is good. You can gladly take it as the eleventh commandment, stick it on the wall and say: "Hey folks, we have to do that too."
[00:38:47] For those who would like to have it documented a bit more: I've gone to the trouble of collecting a few quotes from the relevant regulations. This is the revised slide compared to the previous talk, by the way. We now only have the BSI law , into which the NIS-2 regulation has been absorbed, for all critical infrastructure and providers of some great cloud, SaaS, or other solutions. Software providers, so quite a few fall under it who didn't before. Then in the financial economy there's DORA on top, next to it, with it, it's virtually the same thing in green. And if you think you are off the hook, then I bet with you, the General Data Protection Regulation will catch you after all! It says the same thing in there too. Actually a surprise for me when I read through and researched the whole thing: the General Data Protection Regulation says you are not allowed to lose data. Yes, one tends to think more that you have to protect data, I'm not allowed to collect data blablabla. Yes, true, but if you have the data, then you must store it and protect it carefully and ensure that it is not accidentally lost or gone. That means the entire topic of backup, disaster recovery and so to speak successor exit strategy of SaaS providers is all included there in the General Data Protection Regulation. That really affects everyone. So there is hardly a company that manages to slip past the General Data Protection Regulation. And even as a private person you are already affected there if you somehow use WhatsApp or snap a photo of a friend and haven't asked for permission beforehand and had it given to you in writing so to speak, to file it away.
Audience: [00:40:34] Huh? No, no. Checked off.
Schlomo Schapiro: [00:40:38] And then you go to a daycare party, take photos there and oops, you're caught after all! Yes, it is what it is, right? It's just the summary, read it through or give it to an AI and ask questions against it. The only thing that isn't in the regulations is where the money comes from to do it, and where the admins are supposed to come from who then implement it. Somehow they took the shortcut there.
[00:41:14] Let's come to a little fun part. I've brought a self-test for you and there's also something to win here. Namely, whoever passes the self-test gets a certificate issued by me. Exactly, and then off we go. Now everyone hands up. As a start. Come on, don't fall asleep, everyone hands up. So, and now you can keep your hands up if you fulfill the first requirement: so, you have backups.
Audience: [00:42:07] (Unintelligible) Whatever you want to play right now...
Schlomo Schapiro: [00:42:09] I hope so, we already have... exactly. The problematic word here is of course "extensive," right, because yes, all have backups, but how much, what, are difficult, right? Okay, but all are still in. So, do we have documentation for that? Hm, yes exactly. I can tell you, in my last talk two managed it until the end. That is meant seriously. I hope that you all stay with me now.
[00:42:36] Exactly. So, have you ever done a so-called Business Impact Analysis? So just a what-if story, right: if that fails, what breaks then? Is prescribed in all the regulations by the way.
Audience: [00:42:54] Sorry. Yes, yes.
Schlomo Schapiro: [00:42:54] Have you ever made a comparison between the restoration times and what your business actually wants or would need in order not to lose money, or to lose adequately little money? Right, so somehow marry technology and money, beyond the "it always has to be one day." Have you tried it out? Nationwide, right? Exactly. Have you practiced it? Would be the next thing then. Sorry.
[00:43:43] And now of course exciting: third-party solutions. Vulgo SaaS, but not only SaaS, so every kind of third-party solution. In regulation there is no distinction whether that's Microsoft with SaaS or DATEV, right, is also SaaS. Or whether that's simply a service provider who operates something in your basement or in theirs. There is simply on the one hand the topic of also validating responsibility. So specifically DORA, which said: yes, the managing director is now personally liable for the quality of the third-party providers in his house and the implementation of the requirements. And very importantly: you need an exit strategy. But it is not sufficient to have an exit strategy. You also must have the data... in the regulation it says "easily accessible," I would translate it with open formats actually, the regulation writes about neutral data formats. You must be able to get the data back out of the stuff! Very important point. So an exit strategy without that is not enough.
[00:44:53] I'm sorry that I couldn't take anyone with me here now. I nevertheless have five copies and you can gladly pick something up afterwards. That's so stick it on the wall or whatever, right, then that would be the certificate. We can take it as a to-do list. Exactly, so whoever manages all that is then certified. You can now buy expensive consultants and let them write metric tons of paper. Or perhaps with us, quite pragmatically, let us help you with the implementation. And we ensure that you don't do bullshit and don't play Bullshit Bingo on the wall, but instead produce real results. That's what I like doing: hands-on, concrete, works, provable, automated.
[00:45:32] Yes, let's talk about SaaS and Cloud, right. So catching clouds is somehow a difficult hobby. And the core problem is just, it's far away. So, and the greatest challenge in my eyes is the incredible decentralization. That's so the classic data center that you perhaps have here and there, right: server, virtualization, storage, another backup storage, a tape with it, the classics. That is already complicated and difficult. But now imagine there comes much more with it. There comes exactly the same, but 100 times more with it! And whether you now call that Cloud or SaaS is more a matter of taste, it's in content exactly the same. Cloud is a data center from someone else. And SaaS is: you don't even have access to the data center, but instead you only use the software. So it's even further away. But the problem of decentralization, this spreading out into infinite area, that's just the same.
[00:46:42] And as you said, right, how do you want to restore that? And somehow even make it consistent? Because that is the consistency challenge that exists here, right. We now have here such a distributed landscape of some applications that run somewhere in the world, and typically they communicate via queues, via pipes, pipelines, whatever with each other. So asynchronously, because synchronously it wouldn't work at all. But that means I suddenly have such lines in which stuff lies and there I have state in it. And then the very first question that I ask myself is: okay, how do I synchronize a backup now across my entire IT landscape? Or how much data do I actually have hidden in-transit? So they've left one system, are slumbering in the queue, the next system hasn't touched and processed them yet. Quite pragmatic problems. And whether SaaS, Cloud, Multi blablub, at the moment where I just have this decentralization, I arrive there.
[00:47:59] And the sad thing is, there is no good solution, but instead the application architecture must master the merging of temporally different backups and so on. That means the data consistency as a problem I must also solve in the application again. I cannot solve it on the infrastructure level anymore. And that is a discussion that I personally have already led quite often with application developers. Talk once about how they can no longer assume backup and disaster recovery is a problem that infrastructure takes off them. Is not! Doesn't work. Just doesn't work. Is an illusion. When you start talking about the concrete scenarios and talk concretely: yes, how do we do a restoration, right? We don't talk about backup, we talk about restore. And from the restore story the suitable backup then results. And when you talk with developers about such things, then they check that quite quickly and say: "Hm, true, I must now build a data comparison into my application, so that then the application fumbles itself back together again if the data are once somehow there again." Then they do that and then it's good. So this "eventually consistent" is then meant seriously at that point.
[00:49:21] Let's come to the next challenge, I call that the "Data Possession Challenge." So the challenge of who actually has the data. And there's a quite, quite simple comparison that you can use to explain the whole thing to your boss: namely this image. I hope that hasn't happened to any of you, but statistically it can just happen, right? Someone doesn't look so precisely at the surroundings and then someone else comes and pulls out the wallet in the back. From that example one can wonderfully read off what ownership is now actually on the one hand and possession on the other. Exactly the same happens with your data! And you are already laughing, but that really is true! Yes, so the thief has the possession and the owner can file a possession disturbance lawsuit. Something like that exists in German.
[00:50:26] Let's transfer that to SaaS, right: so you are now here the user and you have a great SaaS application. Behind it is naturally again a data center, right, so quite classic. And in there lie now data from some users, and in the end also the data from you. Logo, right, así SaaS works. And now it is so, the possession is here with the SaaS provider and you naturally have the ownership of the data, no one takes that away from you. So far so fine. Do they have a backup perhaps?
Audience: [00:51:00] Nope.
Schlomo Schapiro: [00:51:00] Exactly. Now naturally comes the disturbance in your access, right. There is some external factor or an internal factor that ensures you don't get to it anymore, purely by chance. And what happens now? Now you first of all have no access to the data, you have the ownership, you still have that. But you have no usage anymore, right. So here, now we naturally didn't have a backup. And the problem is now, the only way to get to the data is by court, the possession disturbance lawsuit, right. The "Give me my data back" lawsuit. Whoever has tried that: so that takes years! And if the company went bankrupt, then perhaps there are no data anymore that one can then pull back by lawsuit. That means, it is a highly theoretical solution that is practically completely pointless. Bullshit. And that is the problem with SaaS and possession of the data: SaaS takes the possession of the data from you and that is the problem we must solve.
[00:52:12] So, once again very briefly, SLA is also a challenge, right. I've brought here another example: so cook, kitchen, restaurant, everyone knows that at least theoretically, right? So clear, you are the cook, the data are in the soup and the kitchen is now your SaaS vendor. The only way out of it is just the pass-through to the restaurant. So far also clear, right? The problem is now, and this image also actually has that: you see, the soup is totally tasty, right? The problem is namely, the SaaS provider does not interest himself for your data. In this restaurant example: that which interests us here in the end in the restaurant is surely a tasty meal, right? But the whole process here in the kitchen has nothing to do with tasty meal. Find the mistake. Something somehow doesn't fit together.
[00:53:16] And that is now an example from Google Workspace Data Protection Implementation Guide. There Google Workspace has once explained how they divide the responsibility between Google Workspace and the customer. And they even explain the difference between IaaS, PaaS and SaaS. And when one unravels that, it turns out: so, if you have deleted your data yourself by mistake, you are responsible yourself. If you have given someone else access to your data and he has deleted them, then it is "Works as designed," because Google is not responsible. If you have deleted an account, then yes, "Works as designed," right. The only thing the SaaS provider takes care of is just the technical operation. And that is SaaS. That is a problem. SaaS providers don't give a shit about your data! Isn't important.
[00:54:12] So, wherein consists now the SaaS trap? Is quite... and to understand the SaaS trap, it really is like that, right? We've already seen the dude, he is happy. Look how happy he is although he sits in the trap! That's us with SaaS. So an architecture, an explanation from technology out of it, you are all IT folks after all. So, we, SaaS, so far so simple. We push data in there, right. We do upload or we click on create and then we create data in the SaaS application. The SaaS application gives us back a link, right. I go to Google Drive, say "new presentation," then a new link is created behind which the presentation is. This link has up there such a cryptic thing in it, that's the ID of it. That means, always when I create data, the SaaS application invents an ID for it. And this ID is the central pivot and anchor point for these data. So far no surprise, right? And naturally I can download the data. I can do download PPTX with Google Slides, and then I get something that so halfway works.
[00:55:29] So, the data lie in the end of course in some storage, and there is also again this ID behind it. What the SaaS provider never gives me is just access to these data. I have no access to my data, I only have up here virtually the front door, but not the back door. And that is the architecture of all SaaS applications. If the application is not así, it is perhaps more a managed-service story and not a real SaaS application. That lies in that SaaS applications are laid out for extreme scaling and multi-tenancy. That means, I never have my data on my own server, on my own drive, but instead I always share it with all other SaaS users. At the moment where I get access to the data through the back, it means I have somehow a private instance there. Then it is more like managed operation and not classic SaaS.
[00:56:39] So, where is now the problem with backup? Well, quite simple: my backup tool can of course now only use these things, right. So I do a download, pack that into my backup tool. And playing back, restore, is naturally I use the upload process. So far so simple. The stupid thing is, I get a new ID! Because always when I upload something there, it creates an ID, right? And that is just the crux of SaaS. Because backup and restore is no longer idempotent. On a file server you can play backup and restore ten times and virtually nothing has changed. With a SaaS application that is no longer true. The second problem is of course, usually that which you download and that which you can upload is not quite congruent. And naturally the whole drum around it, that goes lost, right, so the configuration. Do you know a SaaS application where one can download the configuration, play it back up again? I don't. ClickOps. Good old ClickOps is SaaS, right: click, click, click, config, config, config, done.
[00:57:58] By the way, right, if you want to have fun: implement the topic of change management with SaaS applications! Such four-eyes approval, hard traceability... that doesn't work at all. So, if you want to kill SaaS applications, then use change management as an axe. Is simply not architecturally intended. That leads us directly to the next challenge, right, we already have the example. So I have here my slide and it just has then such a URL with a cryptic code, the ID. And now imagine, if I now take all my data, then I have a Lego model, así the analogy. And as a company I live after all from that all my data are networked with each other and somehow hang together. Now I do a restoration. Then I suddenly have a million new IDs. That means, from my Lego model a Lego heap has resulted. And I call that Shattered Restore. Specifically, I can restore data, but go from a functioning beautiful thing into a heap of rubbish and can then fish my individual little pieces out of there.
[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] And the sad truth is: there is no solution for that. Because this problem has its cause in the architecture model of SaaS applications, which says: the SaaS application is master of the IDs and you cannot play these IDs back in from outside. And that is actually the architectural, technical deep background of all the problems that we have. Right, así quite deep down in the underground of technology, that is the problem and that is the reason why SaaS and backup and restoration are nonsense.
[00:59:57] I'll give you a few more examples and a few solutions, sorry, I apparently overstayed a bit on time. So example Google Workspace Backup and restoration: good news is, one can save something. Bad news is, one can not save many things. That starts with: there are things that I can only export, but not play back in. And there are many more things that I cannot even export. Imagine you build a business process that sits on forms, and you can't even save them! Crazy, right? By the way with Microsoft exactly the same. Whoever now thinks: "Ah, I have Microsoft, no problem," isn't true, is exactly the same. Yes, or the notes or the websites one can't export all that. That is crazy. No one knows that because it is not hung on the big bell anywhere. By the way, right, all the extra things that are nice at Google, they don't even have backup or así, you can bend that. You can read all that once more on my blog, there I've written an article about it once, held a talk, unraveled it once more more deeply. The story is in the end: eat or die. It is just how it is. Because that is also SaaS, right: eat or die. So, who does photo? I hate that when then speakers build up such a complex image and then show the final thing for half a second. Is totally stupid. So, I also always take photos, because then I have somehow my memory, insofar I help you gladly. Exactly.
[01:01:51] Parallel example Microsoft: I've once hunted the API docs through two AI, the result is just as poor as with Google. I am currently searching for a customer who wants me to run my precise analysis for that. I feel like it, because I believe that we can still generate quite a lot of gain in knowledge here, how far Microsoft 365 can actually be used if one wants to be compliant. Which things one must perhaps switch off or how one must instruct one's users that they just are not allowed to deposit certain business processes everywhere. The whole thing naturally leads into a hands-on risk assessment, which then can also flow into the exit strategy because one just has a clear listing once what is exportable at all. So I would gladly do such a project. I am just searching now for someone who wants to have that, who believes that I can deliver that. And I can deliver that super well because I've done it for Google already in my previous job, but I don't do it for Microsoft as a hobby. Sorry, no, have other hobbies. That means, if you know someone or your company can use something like that, then let's talk about it afterwards, I would gladly do it. And if you are fine with that, we publish that together and make a cool story out of it.
Audience: [01:03:13] Question about Google... with the solution, are you talking about this Google Takeout there?
Schlomo Schapiro: [01:03:23] No. Google Takeout is no backup. Because Google Takeout is no backup, because you can never restore it, because you must trigger it manually, because you can only do it every X days and así on and not constantly. And you cannot automate it at all! There is no API to automate it. That it are big files is another thing. So it is just not incremental, but okay, then I download 200 TB once a month, who cares, right. But no, you cannot automate it. That is a manual process that Google by definition doesn't give you differently. And there is no restore from it. So, yes, exactly, right, so here searching project.
[01:04:01] Who has Jira and Confluence in use? Not all, cool. So normally all have that. That is a screenshot from the PDF with the Jira and Confluence Cloud – explaining the relationship user and provider. And naturally it says in there: Backups you do!
Audience: [01:04:36] Why? Well, it is after all logical why they write that because…
Schlomo Schapiro: [01:04:44] No, it is... you must always put yourself into the SaaS provider. That is logical because they have a backup product! That you can buy, for really a lot of money. Would be nonsense if they would give you that for free. The joke is only, this backup product is total dross, because it is only internal, it are only 30 days, you cannot download it, you cannot do single item restore. Look rather at external tools. They indeed cannot save more, but give you more ability to act. That is real. I haven't invented that, I've only click click click searched out, the links stand below all in there.
[01:05:25] So again summarized: SaaS is totally cool, it solves a heap of problems and it makes our life easier. And it is just such a small honeypot, one slides easily into it. And the flip side of the coin is just, everything that hurts is in SaaS just with... we give up the possession of our data. And that is the trap. So, to understand why that is así, you must put yourself into the SaaS provider. And what I say now is true for all SaaS providers. No SaaS provider... right?
Audience: [01:06:05] You perhaps?
Schlomo Schapiro: [01:06:10] Building site. Exactly. So first of all: core business model of a SaaS provider is "buy cheap storage and compute, sell it expensive with a bit of packaging around it and still added value." Is first of all every... every SaaS provider does exactly that, right. First of all no witchcraft. Stark standardization and endless scaling. And standardization makes it just easy to scale and right, I pack all together and then I can just scale as needed and así on. So that is always hand in hand, standardization-scaling. And then very importantly: Data Gravity! That means, the more data already lie with the SaaS provider, the more data come in there, the more additional services are bought from that SaaS provider, because the data are already there after all. So now copying 10 TB of data for analysis somewhere else is just not so easy. Then I rather buy the analysis from the SaaS provider where the data already lie in, and save myself the transfer. So think please about Data Gravity when you think about SaaS. And very importantly: every SaaS provider saves himself the hard problems and rolls them off onto the users. That is part of the business model SaaS. Why? Because it works. The customers are así stupid, they buy that anyway! I too. Is así, is hard reality. If you want to be successful as a SaaS provider, do these four points, you will be successful.
[01:07:46] If you want to understand how one deals with SaaS, you must understand how SaaS providers function and then you can just think about how that plays out. So, once more very briefly in the overview. I don't call that... I call that Graceful/Ungraceful Degradation. You perhaps know the term Graceful Degradation, when one builds application architectures así, that just virtually, if there are problems, then still deliver something and one just thinks about how virtually así the feature set becomes smaller. With SaaS and backup it is just different, right: we go from a beautiful castle on an island at restoration into a semi-ruin. And if you ever need disaster recovery, then it is just only still such a wooden hut that acts así as if it would be a castle. That is simply the reality.
[01:08:39] And the way out of it is quite simple: you must deal with non-functional requirements. The more you take non-functional requirements around SaaS procurement into account, the more you get these things under control. I am finished soon. And it hurts, because SaaS applications are procured after all by business units and not always IT. It is sometimes celebrated, right, así "now all can do something," but no business unit will take these non-functional requirements into account for you. I have by the way here a standard procedure model for that, namely a criteria catalog for the purchase of SaaS applications. If you have interest in it, we can gladly do a small project. I show you first of all the thing and then also can talk about how one introduces that. There it's about a bit... I've called the concept Business and Technical Stakeholder, specifically a clear distribution of responsibility between business and technology over: "Who must actually do what in the context of software and application?" Is best a conversation that one leads así with the topmost management level, after just some project has gone really wrong. Then the ears open for it.
[01:10:01] Exactly, how do we get out now, right? You are here after all because you want to get out. So how do we smash this dependency? And you see, now the SaaS providers are not quite así happy anymore, because we develop activism and do something for ourselves. And in my eyes there is a clear way into sovereignty. And the very first step is the data, right, we've talked after all about possession and ownership. So let's start with that, to reconquer the data possession for us! That is the most important of all. The second step is then naturally, to talk once about the processes and the operation, así a technical sovereignty. The third step is then also, to take one's fate into one's hand. The problem today is, we can quite often not decide. So a decision not to take Microsoft is usually not realistic and not possible. That means, we have no freedom of decision. The framework conditions and circumstances, they already write down the result. And in the context of sovereignty my goal is naturally, to get there that we then can decide freely. And in order to do that, we must just once start with the data sovereignty. The rest comes afterwards. In exactly this order, not the other way around. So the possibility to take one's fate into one's own hand is the result of hard work before that and the data sovereignty and the technical sovereignty.
[01:11:40] So, solution for Microsoft and Google backup is actually a Synology NAS. That is a result from my analysis of 2022 . So Synology and QNAP both have a backup software in it, works reasonably well. Is a solution that first of all creates a kind of basic protection, saves just mail, calendar, contacts and drive. With all restrictions that go along with it. But whoever doesn't have that: buy it please! Do yourselves the favor. That is not expensive in comparison to what you get. And also here I can gladly help you to validate the concept for a larger environment. So I naturally have that for me at home, I've also done that for a smaller firm with 1000 users, that scales super until 1000 users. Beyond that I don't know, I look at it gladly together with you. Whoever has nothing, please take that! It is the best price-performance ratio to manufacture there a basic protection. The things are not así expensive and they have a good software in it.
[01:12:48] Another example: we live after all in the age of AI. And we had at Tektit the problem, we use such a SaaS application for the time tracking, right. As consulting we sell time. That means, without time tracking we write no invoice. And our time tracking is a SaaS application. No backup logically, right? Is for us stupid, because no backup means, if it goes bang, we write no invoice anymore. So the reference to "our money, business, technology" is direct. The solution was then : I've written with Cursor AI and such a fifty and a bit of background dealing during boring meetings simply a backup tool. And that totally easy! That has worked really well, is naturally Open Source and pursues the data possession as approach. And I've quite consciously decided for it, the restoration I do in the future, if I know where I and how I want to restore. I've first of all only built me an export that simply runs every night and saves the data for me. And it are JSONs, right, así quite banal JSONs. And I know, I can, if I then want to introduce a new tool, again with a fifty in the AI write me the importer that these JSONs, which I already have, into the new tool loads. In perfect and prettier quality with loop. And because it is así cheap, I don't have to do it in advance, but instead can rely on it that I can do it then in future if I also need it. And that is by the way an achievement that AI just gives us. That didn't work before. Yes, before I would have done here a development project with engineers and lalala, and it would be thousands of euros. So the AI is here the stark enabler par excellence. Customers, projects, time tracking, right, así hours and así, then the invoice, the expenses that we still must capture. Then we write once in what we've done, what then appears on the invoice. Those are important data. It are in the end only JSONs. But now I have just the data, before I didn't have them.
[01:15:12] So, a further example here from the house Heinlein is the slide for Peer. And I find it cool that Peer has created a solution. mailbox.org EVAC has a disaster recovery add-on, with which mailbox.org as emergency groupware for your virtually environment can function. It functions así that one prepares in mailbox.org then virtually a kind of shadow IT for the case that your primary groupware fails. And then one can quite quickly activate users there who then work and communicate in Mailbox. Is super cheap, costs really not much. So pocket money, really. And only when one uses it, then one pays normal mailbox.org fees. That is a quite classic virtually insurance product that helps you to secure the communication and collaboration in the company. And that is a concrete example how one can just secure one's Microsoft 365 or other groupware against failures, against catastrophic failures. Also here, I help you gladly to implement such a project, because that is exactly again the approach: we automate stupid things away to generate ability to act for our companies.
[01:16:33] So, now we must come to the point, right? We've said, we must fetch the data back again, and I call that Data Jailbreak, right? Just así a cell phone, we break the data out of the prison of the SaaS providers out of it and transform them into open neutral formats with which we then can act independently. And generate the factual ability to act, to do with it what we want, when we want, how we want. And that is the insurance policy! A hands-on practical policy, that doesn't pay you money, that saves your company because you have the data. If one does all that, one comes to a thing that I call Lifeboat Architecture . And that is my concept for SaaS. I use gladly SaaS and I take care of my data possession. The idea is simple: así a, right... I drive on a cruise ship and bring my own lifeboat with me and that chugs behind there. And I just take care of it that I have my data from all SaaS applications just myself. And the price of the SaaS application is not only the license for the SaaS application, but instead also the data extraction into my own sovereignty. That belongs to the price of the SaaS application with it! If I do that, I can with good conscience use the SaaS application and profit from the many advantages. By the way, right, as always on my blog .
[01:18:05] And that is for me the way to resolve this conflict between SaaS and "securing our survival" and "to deal responsibly with SaaS," how we just resolve that. That is my approach and I believe you can take this approach and apply everywhere and with it design your environment safer and better and incidentally also fulfill all regulatory requirements naturally, right. Be it now KRITIS or finance or General Data Protection Regulation or whatever moves you. And it is not expensive. So sorry, to throw in a fifty at AI to generate a tool is after all really cheap. And then it is perhaps one because it is a larger tool, but is still cheap now in comparison to what one otherwise would have been able to pay for it a few years ago.
[01:18:53] So if one summarizes all that, we come to the topic: do you actually know your companies? Do you know what is important for you?
Schlomo Schapiro: [01:19:10] I mean, you are a bank, you know it hopefully.
Audience: [01:19:10] But all others too, yes, you must know it. Exactly, exactly.
Schlomo Schapiro: [01:19:17] But all others should perhaps also know it. And once more back to the analogy, right, we have after all this problem with partial restoration, and I believe there exists just in the middle this golden core of every company. That one must really know well, understand, and for these important things that keep the company alive, that ensure that the money also tomorrow still comes in, that we all have a job, that the company lives on, that we still can do something: for that we must implement the No Restore Solution. As a concept, but also only for that, for the important core! For everything else we don't need it. This distinction between important and unimportant, that is extremely important and valuable.
[01:20:03] So, let's summarize backward: how do we come now to digital sovereignty? How does that lead to an exit from the SaaS trap? So first of all: implement and take into account the fundamental concepts backup and disaster recovery also for SaaS. Activate the No Restore solution for all that is important, because there we don't have the time for long-term restoration. And the master plan looks así: first of all Lifeboat, right, we first of all switch on our lifeboat and produce a backup of everything, in case of emergency with AI and the backup tool that we just have written. Be así kind and make Open Source, then others have something from it too. Very importantly: Instant-on Recovery for critical infrastructure in the company, only así you can survive as a company. And the rest is just collateral damage, accept it! Accept that you cannot restore everything. Is así. Is simply the consequence of SaaS, but without SaaS we also don't manage.
[01:21:22] So, this here, right, backup everything, is now the first step, you can do Monday right away. If you need help, we help you gladly, is not hard, but if I do that, then it is Open Source, right, así... The second is naturally the triage of: what is actually important in your company? If you haven't done that yet, do it please. That is ultra valuable and brings you further. And with that you have a master plan into digital sovereignty into it.
We at Tektit Consulting are happy to support you in developing your own SaaS data jail break and take you on your journey towards greater data sovereignty. Let us start together with a brief SaaS backup discovery to develop your individual roadmap.
Comments
Post a Comment