You’re Doing it Wrong: Spreadsheets

Lloyd’s of London ran on spreadsheets in 1689.  The Sumerians did in 3200 BCE.  Haven’t we progressed at all?

Introduction

We are taking a step back from healthcare and health insurance to bring you a new series: You’re doing it Wrong.  In this 15-part series we will discuss all the things that the bizdiots do and are doing that are counterproductive and raise the cost of their own products and services and consequently the cost to you, dear reader, the consumer.  This first installment is kind of a bellwether, the canary in the coal mine, that shows that bizdiot thinking is rampant: Spreadsheets.  We are taking a break from healthcare because there is no new real news.  The AI hype is just getting worse, and will never pan out, the EMR vendors haven’t realized that you can’t document encounters with text or language, insurance companies rip off everyone, so we are stepping back and looking at the bigger picture.  If you need your weekly dose of healthcare, read our article detailing how we have saved healthcare in the US: Saving Healthcare: Putting all the Pieces Together

The Situation

Spreadsheets are good for two things: causing bottlenecks and corrupting data. Here is what they are not good at:

1. Not type safe/no error checking
   Your spreadsheet requires a percentage between 0 and 10.  Type in rutabaga.  It goes in just fine with no errors
2. Hidden errors and formula mistakes
   Studies show that up to 90% of spreadsheets contain at least one significant error, often due to hard‑coded numbers, circular references, or outdated formulas. These can go unnoticed until the data is used, leading to incorrect results.
3. Hard‑coding and lack of maintainability
   Writing formulas with fixed numbers (e.g., =A1*0.05) means changing a rate requires manual updates across the sheet, risking “orphaned” formulas.
4. “The gap” problem
   Adding new rows to a list without converting it to an Excel Table can cause formulas and PivotTables to miss the new data.
5. Performance and stability issues
   Large spreadsheets with complex formulas, macros, or many charts can slow down or crash applications like Excel. This is especially common when switching between worksheets or using certain add‑ins.
6. Data corruption risks
   Opening files with macros or VBA projects can sometimes corrupt the workbook if the macro is enabled incorrectly. Similarly, network‑based files may not update as expected.
7. Collaboration and sync problems
   In cloud versions like Google Sheets, users may report app not loading, server not responding, or slow performance. These can disrupt real‑time collaboration.
8. Security and accessibility issues
   Spreadsheets can be vulnerable to malicious macros, and some special characters in filenames or paths may not be fully supported. Accessibility features may also be limited compared to dedicated tools.
9. Automation and integration bugs
   Add‑ins, automation workflows, and integrations can fail to load or behave unexpectedly after updates

Those are just the problems with spreadsheets themselves, they don’t cover the real loss in productivity.

1. Email is insecure
   There is nothing keeping your emailed spreadsheet from being intercepted and opened by bad actors.  
2. Tribal knowledge
   All the business logic in your sheets is locked into your sheets.  You have no way of centralizing and documenting that.  Moreover, everyone has to either have the sheet mailed to them or just know where it resides.  
3. Workflow thinking
   Linear thinking is promoted by spreadsheets.  Fill out the spreadsheet, mail it to your boss/coworker for approval.  Get approval, open it again at the end of the month and do the monthly/quarterly/yearly reports.  Linear.  That causes the bottlenecks mentioned above.

The Logical Conclusion

Because of the linear, workflow thinking, the inherent data ‘silos,’ the lack of type checking, and the manual processes, all it takes for your company to fail is someone else to NOT use spreadsheets.  

The Short Answer

You need a database application.  Databases are robust, type safe, and fault tolerant.  With a database, all those reports you have to produce are a single click away.  

The Slightly Longer Answer

There is more to it than just the database of course, there is some kind of User Interface (UI) an Application Programming Interface (API), a reporting engine, and of course building or having it built and hosted.  Let’s examine these in more detail.

The User Interface (UI)

Sentia usually tries to do some kind of web/mobile interface.  That allows you to see your application from anywhere in the world.  We use Microsoft’s Blazor for all our web development, obviating the need for almost all legacy JavaScript.  Blazor allows you to run real, compiled C# (see sharp) code in the browser instead of having to learn this week’s JavaScript Framework like React,  Angular or Vue.  Note: JavaScript is not type safe either.

Back End for Front End (BFF)

Phil Calçado, formerly of SoundCloud, came up with the Back End for Front End (BFF) pattern that allows us to not only tailor our output for the screen it's displayed on, but it also allows us to bring disparate data sources together as native. The reason to use disparate data sources will become apparent in a moment.

The Application Programming Interface (API)

We at Sentia generally generate an API with all the Create, Read, Update, Delete and Search (CRUDS+) capabilities built in.  We also include exact search, fuzzy search, and retrieving related data.  There is a method, for example, for getting students by class in a school database, and classes by student, out of the box.  When we say automagically, we mean we have an application that generates that code for us.

The Database

The database has several features that make it fast, robust and fault tolerant.

• Type Safety
  If you need a percentage between 0-10, you can’t type in rutabaga, not blowing up your application
• Indexing
  Exactly the same way your old set of encyclopedias had an index that tells you where to look for a particular piece of information, so does your database, making it fast.  To be clear the database indexes the data and uses that index, you don’t have to use it personally.
• Transaction Log
  This is where every data exchange gets recorded.  Generally, you get a play by play of everything that has happened since the last backup so you can play the transactions forward and recover a database if someone just pulls the plug or the server fails.
• Backup and Recovery
  Databases have facilities for backup and recovery; they do this on a schedule so there is always a recent copy.  Most companies also move the backups offsite to insure against an act of nature.  Disaster recovery is something that is planned for and tested and doesn't need to be a source of angst.

Master Data Management (MDM)

This is the repository of all things Enterprise.  People, both employees and clients, addresses, emails, phone numbers, all things that we will need in more than one application all go here.  This is so we don’t have duplication and therefore versioning and a single source of truth.  Change it here and it is changed everywhere.

Single Sign On

This is the repository of all things Authentication and Authorization; this is the source of truth for identifying users and to make sure they are who they say they are and for figuring out what they can see.  This is its own application and has this information for all other applications in your suite.

BFF Revisited

Since the MDM and the SSO are separate applications, the BFF brokers those requests natively to the correct source of truth.  This means that for every application there will be at least three databases and APIs, all coordinated by the BFF.  As an aside, the APIs themselves are all generated with the CRUDS+ methods automagically.  We don’t touch this code unless there is a performance issue.  That means that it is all basically free out of the box for the business

Security

Enterprise security has to be built in with the design.  Having a Chief Information Security Officer is useless, as the security has to be implemented at the pointy end, not in a boardroom or the C-Suite.  At Sentia we use an OAuth style token with a JASON Web Token (JWT or “jaht”).  That JWT has a claim called SessionGUID (Globally Unique Identifier) that is used to authenticate the user and their own session.  This is fairly standard in the industry.  What is new and unique to Sentia is to use the SessionGUID as the basis for both the multitenancy and security.  Data is only accessed through stored procedures, and all stored procedures require this SessionGUID to return any data.  That means that even if a bad actor completely stole your database, they couldn’t get your records.  

Reporting

This is the culmination of our application.  Want to know what Bob accomplished last week?  There is a report for that.  Want to know what Bob cost the company and what literal profit Bob contributed?  There can be a report for that.  In fact, you should be able to pull a profit and Loss on any entity in the enterprise.  What you SHOULDN'T do is pull down data from the database to slice and dice in your spreadsheet.  Find your answer directly without the middleware.  

Logging

At Sentia all data is logged into the ELK stack database( ElasticSearch, Logstash and Kibana).  This is a document database solution that allows all the logs to be kept and searched in one place with a built-in web interface.  If something bad were to happen. We can consult the logs for your suite of applications and find the problem quickly

Conclusions

We have shown a way to do whatever it is that you are doing better than you are doing it.  The particular nit we chose to pick was spreadsheets, but all the points here are salient to your enterprise applications as well.  This is a replacement for not only your spreadsheets, but your ERP, ATS/HR suite, sales management, ticketing applications, everything.

At the risk of sounding pedantic for repeating myself, if you don’t do this someone else will, and they will put you out of business.

We have shown a way to streamline, automate and integrate your business.  This system can replace all your Enterprise software and the need for integration, less expensively than what you are doing now.  This is not a cost center; this is a profit center.  By making your employees more productive, less harried and having less tribal knowledge, we can increase profits through productivity.  Implementing this system is the only way to do something different and avoid doing the same thing and expecting different results.

About AI: Sentia has tried and discarded AI.  In very narrow limited scopes, there was actually a small increase in productivity.  That increase was not worth the cost both in terms of cash paid for the tokens and having to explain things to the AI several times and fix the 10% of the results that were worth fixing.  AI is not the path forward.

Remember this is part 1 of 15 in this series.  I will be putting out one or maybe two articles per week.  If you liked what you read contact us here, on our site, SentiaHealth.com, our parent company SentiaSystems.com, or send us an email to info@sentiasystems.com or info@sentiahealth.com.