4 ms·
| Sometimes by falling back to low-tech solutions My first thought in all this was wondering if there's a business opportunity for a consulting firm or startup
by emseetech 2y ago
| Sometimes by falling back to low-tech solutions
My first thought in all this was wondering if there's a business opportunity for a consulting firm or startup that designs and manages offline paper backup systems that can quickly and seamlessly integrate back with digital systems once they come back online.
- SoftTalker 2y agoThe problem is that if you aren't regularly training employees on those manual fallback systems, when you have to suddenly activate them, nobody will know what to do. Even if they have been trained on what to do, the processes will not be second nature. In real use, they will hit situations that the paper forms or training didn't cover, and will have to make up something on the spot, which they will each do differently. Fully comprehensive, regularly trained manual operations are very expensive to develop and test. Only the most safety-critical organizations will be able to justify and have the resources to effectively implement them. Air-traffic control, hospitals, nuclear plants, etc. And, they already have done it.
- hilbert42 2y ago"…offline paper backup systems that can quickly and seamlessly integrate back with digital systems once they come back online." It's not offline paper backups that are needed but rather the reverse—offline paper-based systems used as masters! The heart of any critical infrastructure—specifically the part of the heart that's the most vulnerable is comparatively small compared to the large masses of ancillary data and thus could be managed on a paper-based database (as they once were before computers). With computers and IT infrastructure as they're currently implemented—not as computer science says they ought to be—a secure filing cabinet/paper-based database is much more secure than an ephemeral one that has no physical or volumetric presence and which takes precious little to shove it from one end of the planet to the other. The caveat is of course, the database must be secured against physical access and located in a secure building, etc. Let me state why. Comparatively speaking, in recent times there are very few secure bank vaults and such that criminals have breached. The number is so small I can't remember when I'd last heard of a bank vault robbery. Another way of looking at it is to ask yourself when was gold last stolen from Fort Knox or the Bank of England, or $100 bills stolen from the US treasury/mint before their distribution. Why so few robberies you may well ask. We've had hundreds of years of experience locking up these valuables and although the current systems used to secure them aren't watertight and likely never will be, they're nevertheless sufficiently secure to the extent that the few breaches that do occur from time to time are manageable. With physical security, we've found a workable balance between security and workability. With the few robberies that occur it's not worth the effort of tightening security further, to do so would not only add considerably to the cost but also physical access would be more difficult thus less convenient to use because of the additional protocols that would have to be put in place to reach the higher security level. Also, think for a moment that if you could gain access to a secured paper-based database how quickly could you copy it, and how would you copy it? Right, both would be very difficult. On the other hand once an electronic database has been breached megabytes if not gigabytes can be sucked out within seconds. In practice, the electronic/digital world has nothing as 'bulletproof' as a physically secure system. Given the statistics—the rate of cyber breaches, personal data stolen, Bitcoin thefts, etc., etc. that occur not on a yearly but rather on a daily basis, one simply can't argue that collectively IT/electronic systems are more secure than physical, paper-based ones. Back to the physical database: a secure paper-based database would always be offline, if some data are needed from it then they have to be extracted manually, then vetted and encrypted before being put on line (that's if it's actually necessary to put highly secure stuff on line at all). As things stand, owners of information have a choice, store it in an electronic system and take advantage of the operational advantages that it offers or use secure paper-based storage and suffer the inconvenience. One can't have it both ways. The reason why we've so may data breaches is that the average punter far prefers electronic data systems for their convenience. On evidence, convenience is seen as more important, in practice its value far outweighs data security and integrity.
- g_p 2y agoAn interesting idea. Another commenter pointed out the need to train staff regularly on its use. Something else that would be a challenge for your idea would be how to handle the orders of magnitude efficiencies in scaling gained from digital technology. Emergency call centres often (or at least should!!) have these paper or card based backup processes - notes are taken on the card based on the call, addresses written manually, and the card is carried to a dispatch desk (perhaps sitting on a handheld radio if the main system is unavailable), passing information to response teams. Handling of each call requires more people, and gets you a much lower throughput (manually writing addresses, without lookups for spelling correction, reading them with phonetics over the radio to drivers etc). How many times have you tried to call a business during an incident or disruption and been unable to get through on the phone, because they aren't staffed to a level that can handle any significant % of their customers calling at once? (Often, these companies lack tech company style realtime status pages as well, which could arguably reduce call numbers). I do think there's some merit in trying to help organisations improve process and procedure resilience, but it doesn't strike me that it will be effective unless normal staffing levels are nearer the levels needed for "crunch" operations (or people are kept "on call" at extra cost to be available). There are however a lot of good lessons that should be learned from the wider fiasco around technology resilience and systems design, and part of that should include independent (with as close to entirely independent failure modes as possible) redundancy systems.