Software: Build v. Buy
Explaining why you are on the wrong side of that debate and what you should be doing instead
Introduction
Normally we talk about healthcare and health insurance, but today is a little bit different, though the lessons we will learn are applicable to both healthcare and health insurance. Today, we are going to discuss whether we should build or buy software, and look at the pros and cons of each.
Let’s dig in.
The Big Vendors are Run by MBAs
The big vendors have exactly the same software problem you have and for the same reason: they don’t have the first clue how to build software. Further, you are already in the software business. I know this because everyone is in the software business.
The Problem
Building software is complicated. You know that, that is why you don’t do it. It is so bad that they can’t even identify people who can deliver. This is an entirely different kind of thinking from whatever industry you are in or running a business, though I would state that a good developer could easily run a business.
The Solution
Don’t buy software from the big vendors: ServiceNow, Salesforce, SAP. They are who they are because they can write a business plan, get funding, and have lots of business school contacts, not because they can solve problems.
The Corollary
Don’t buy software from the big consulting firms either. They certainly don’t know how to build software, they are there to bill hours. They are going to suggest what is quickest and easiest for their own bottom line. I have personally seen companies with some of these big packages with consultants at several hundred dollars per hour who sit and type data from one system into another all day long. Surely we all see the big red flags there. More on integration later.
Modifications
Many or even all of the big software application companies will, and even want, to modify their software for your particular purpose. Others, give you the package and want you to complete it according to your own specifications.
That sounds great! You get custom built software with enterprise everything, that just works.
Except that Epic Systems only has a few thousand installations and they employ tens of thousands of people and they make billions per year. Who do you think pays for all the employees, overhead to maintain those employees and profit? Do your own research and find out that an Epic installation averages over a million dollars per year to install and maintain. I’ve always said that I could automate the universe twice for that kind of money.
The Problem
Modifying software to fit a particular client is a really, really bad idea. If you are going to modify something, start from scratch and build the whole thing. You have the same headaches, but you get exactly what you want. Modifying becomes an administrative, security, and deployment nightmare. Now you have repositories for thousands of clients and any time someone needs a fix or a modification, your developers, or their expensive developers, have to go in and figure out what was done and how it was done and only then can they attempt to fix it.
The Solution
Purchase (or subscribe to) software that solves the general problem with non-proprietary tools. This obviates the need for your own developers, the biggest reason you bought the package in the first place.
Don’t let the Clients Modify the Software
The only thing worse than modifying your software to fit a particular client’s needs is to let them do it themselves.
The Problem
To the above problems of modifying at all, let’s add letting someone else do it for you. Now you have developers and engineers who do heaven-knows-what to solve a problem and what you end up with is unadministerable, unsupportable and probably continually broken. This is why we end up with PeopleSoft, Salesforce and ServiceNow developers in this dystopia that we call reality. Why in the world would you spend millions on a software package and then have to hire developers to make it all go? The mind boggles.
The Solution
Look for a vendor who solves the general problem, or solve it yourself. We talked about solving the general problem earlier. Here is what that means: When we were tasked with producing a system that could put a patient, a doctor, a nurse anesthetist and a colonoscope into a particular room at a particular time, we rejected the problem entirely. The scope was wrong. What happens when we need to add a nursing assistant or someone wants to sell our software to a different practice, ambulatory surgical center or hospital? We solved the General Problem. We reframed the problem to “Schedule Whitesnake at Reunion Arena in 1985.” Now we have a totally unrelated problem in the details, but in reality it is exactly the same. So we had to set up geography, not only the address but the various parts of the arena, like stage and seats and ticket booths, etc. Then we thought about equipment, not only guitars and amps but brooms and polishers and concessions. Now we need to think about personnel. Sure, we need the band, but we also need ticket takers and custodial staff and patrons to fill seats. Finally we needed templates to say “a concert needs these things” so that we could make sure we had all those same things for every concert. Once that was accomplished your Doc/CNRA/Patient/colonoscope/Room became trivial. We broke down the pieces of what scheduling itself looks like and solved those smaller problems first, then put them all together to solve the overall scheduling problem.
Since we used an unrelated scenario, we ensured that the pieces of a colonoscopy weren’t hard coded and the entire application was data driven. That means that we have people and places and equipment instead of doctors and CRNAs and colonoscopes.
We solved the general problem.
Security
You have bought millions of dollars of “Enterprise” software. Great! Stupendous. How is it secured?
The Problem
As stated earlier, the MBAs making the stuff you buy aren’t any smarter than you are. They write business plans, not software. How does their security work? Do they know? How are you going to integrate their security into your security? Are you just going to have everyone memorize 537 different usernames and passwords? Are you going to rely on two factor authentication (2FA) to keep your systems secure? Is 2FA built into their systems? Are you going to have to supply RSA dongles or even *gasp* cellphones to employees to handle the 2FA? How much is all that going to cost and how much of an administrative nightmare is it?
The Solution
I’ll bet you can guess that we are going to say build it yourself or find a vendor who makes everything you need with a single sign on (SSO) system. After looking at SAML and Identity server and Okta we decided to design and build our own security system. Sure it was easier to just buy or subscribe to one of the big vendors, but after looking at how their systems were designed and work, I was not willing to give them money. I know how to write software and they all came up lacking, as per above with the MBAs writing business plans and not software.
We broke down the scenario as with Reunion Arena above and solved the general problem: Authentication, proving you are who you say you are, and Authorization, proving you are authorized to see what you requested. Combined we call this “Auth”
When you log into our system(s) you are issued a globally unique identifier (GUID) that identifies your session. Each request to the database requires this GUID. It is not only the basis for our Auth, but our multitenancy. Discussing multitenancy is beyond the scope of this article, go look it up if you need to, but it only allows you to see the people and things associated with your company. In the case of the colonoscopy previously, we only show people, doctors, CRNAs, rooms and colonoscopes associated with that facility.
Combining this kind of Auth and multitenancy with solving the general problem means that we can write one piece of software that solves the problem for everyone, whether you are scheduling colonoscopies, Whitesnake, or fixing a broken toilet. One solution gives us the ability to administrate, maintain and modify, and keep it secure. That can’t be done with packaged and even modified software.
Nobody else on the planet uses this Web Token style Auth plus multitenancy at the database level. If you want to contact us, the addresses are at the end of this article, I will be happy to explain how it all works in detail or do it for you.
Integration
Wonderful, you have purchased and installed your modified software and you are convinced it is secure enough for your purposes (it isn't), now what? How do you make all these systems exchange information?
The Problem
You have several or even tens of disparate systems in several or tens of different programming languages. Do you hire "offshore resources” to look at one and type the same info into all the others, the way we detailed above?
No, you are brighter than that. You call your college buddy at Infosys or Cognizant to solve your problem. They send a team over with a dozen or so people at a few hundred an hour each. The team advocates for building APIs to integrate your systems.
APIs are real, hardcore development. Now you are running a development team anyway, and you have paid millions or tens of millions, or in the case of Epic, hundreds of millions for your installed application, plus a development team that you could have hired yourself for as low as $15 per hour.
This is one reason why you can’t hire the big consulting firms.
The Solution
Find a vendor that supplies everything you need so you don’t have to integrate anything, or build it yourself. We recommend finding a vendor to build it all for you.
What you need then, is a suite of applications that all use the Master Data Management (MDM) pattern. That means that anything the enterprise will need in more than one application, will be housed in a separate database that is accessible to all. The things include people, geography, equipment, capital assets, look up data, emails, phone numbers, social media identifiers and the like.
Combine that with the previously mentioned SSO and you have the starting place for something great. Without going too deep, the really important part about the information kept in the MDM are the relationships between the entities. For example, a person, a person entity, can have one or more phone numbers, one or more email addresses, one or more physical addresses, etc. These relationships make it possible to make the multitenancy previously mentioned work. A person can be associated with one or more companies giving them access to the clients of one or all.
All of that with no need for integration of any kind.
Reporting
If you don’t have integration, you don’t have reporting.
The Problem
Your fancy accounting system is really only keeping track of AR and AP. You really don't know how anything is going until the month is closed and the accounting done and everyone paid, both to you and from you, how you did. Without integration you have no recourse but to let the accountants run your business with minimum two week old information. You aren’t running a business, you have a tiger by the tail and you have your eyes closed. When that tiger turns around to bite you, you won’t, you can’t see it coming. You are flying blind.
The Solution
Find a vendor or build a system yourself that doesn't need integration. Better, partner with a vendor that specializes in building these systems and probably has one that they can just add you to.
With the MDM, SSO and application all as part and parcel of your process, and with these things all exchanging information, you could have a report that tells you, in the case of a colonoscopy above, what that particular operation costs, what it was billed at, if it has been paid for fully and how much you made. Read that again. Every instance of every process in your entire organization could have its own specific profit and loss statement (P&L) that takes into account the salary of the people involved, the equipment, the facility space, the power, the capital assets, the maintenance on those capital assets, everything you need to see how you did on that particular effort. An overall P&L then, is just an aggregation of those specific P&Ls showing you, the business person, how you did today, this week, this month and this year, up to the minute. There is no more flying blind hoping the tiger you have hold of doesn't bite you in the arse.
Further, just about everything is a report. How many days this year has an employee been late? What is a lifetime sales figure for another? Your entire tax return is just a report. If you categorize your income and expenditure correctly you can do your tax return with one click.
Hosted v. Installed
Now you have a secure, integrated and report friendly set of applications that run your entire business. Magnificent.
The Problem
All this software you bought requires installation. That is how they make their money. They have a price of however many million, then you think that your business is different (it isn’t) so they (or you) modify it then you hire developers to integrate all your systems together, so everyone has all the information they need to run the company. Then you hire developers to actually go write all the reports you think you need so you don’t have to worry about the silly TPS report that some low level, expensive lackey worked on for a week and still forgot to put the new coversheet on.
Finally, everything is coming together, and you are ready to make some real money with your shiny new system. Then they change versions and all your hard work is for nothing and has to all be done over.
Not only that but you have armies of network guys and helpdesk and engineers and all the things it takes to run a software company even though you bought and paid for the packaged solution. Yes, you are running a software company as we stated previously, and you scoffed.
The Solution
Don’t spend millions of dollars on a ‘solution’ with the problems we have identified here. Certainly, don’t spend millions of dollars on an installed solution that you have to administrate, maintain and troubleshoot yourself. Find a vendor that hosts a solution that does what you need it to do, with a general solution that doesn't need to be modified, or if you are going to have the headache of administrating, troubleshooting and maintaining a suite of applications, just build it yourself. We already stated that the big vendors don’t know anything you don’t know. Maybe the better solution would be to find a partner to help you build these generalized systems that will handle the general problem. That includes the problem you have.
We know that all businesses run exactly the same. They have some people, a facility, a product or a service, and a way to produce that product or service and ways to account for the raw materials or processes, or inventory or warehousing, ad nauseum. This is how we have generally accepted accounting principles (GAP). This is what we meant when we said that your business isn't different, earlier.
Versioning
You are in the money now! You have solved all the problems above and have a well designed and built, enterprise, secure, integrated system with reports out the wazoo.
Now the vendor puts out a new version and discontinues support for your old version.
The Problem
Since your software is installed, or is hosted in the cloud with a subscription fee, and only does the one thing, when the version changes, your integrations break.
Maybe it is just a little database change. Your integrations and everything built on them stop working. Maybe it is a big revision and the vendor is going from on premises, yours, to cloud based. All your work is for naught. Maybe they go from Java to Python or .NET and the data itself changes. All the APIs, the reports, really all your development, is worthless and must be started over.
The Solution
Find a vendor that provides everything you need, or build it yourself, knowing that the big vendors don’t know anything that you do not know (think about the big Crowdstrike debacle a few months ago where they took down hundreds of millions of computers worldwide),or find a vendor that will help you build a single system with the MDM, SSO and application architecture that you really need. To that we will add the Backend For Frontend (BFF) design pattern.
BFF is a layer between the MDM, SSO and application API layers that your new UI communicates with. The BFF is an aggregation layer that takes all the information any of your applications need and combines it into a one stop shopping kind of supermarket. This allows the individual MDM, SSO and Application APIs to be completely generic. If they are completely generic, they can be generated.
Generating the APIs involves software that looks at the database, writes stored procedures (best practices, but beyond the scope of this article), writes calls from the generic API to these procs and manages everything that isn’t User Interface (UI). The BFF then calls these generic APIs and combines all the disparate calls together to create one object the UI needs to present to the user.
We have this code generation tool designed, built and deployed. That means that we can be about 60-70% done with your new application the day the database is designed.
Conclusions
This is a little bit of a different article for us this week. Normally we present solutions that kind of sit in a black box of how and why. We see however, that companies are just doing this all wrong and could be doing everything they do better and more efficiently.
We have discussed why you can’t modify software either from the vendor or for yourself. We talked about security, integration, reporting and hosted v. installed, along with what actually happens when the version changes and breaks all your hard work. Finally we talked about a better way to solve all these problems.
We know you don’t know how to build software. If you did you wouldn’t be reading this, you wouldn't need to. Even the guys that design and build the very systems you erroneously depend on today need to read this. Clearly, they are doing it wrong too, either because they don’t know any better or because they need a paycheck and just do what they are told.
We aren’t constrained by that. We build the generalized solutions we discussed. Our premier product, Sentia Health’s Electronic Medical Records System, EMR, is designed to be general. That means it caters to all specialties. In fact, it doesn't even have specialties, it solves the general problem. You don’t need a different version for gastro or cardiothoracic or osteo or anything else, you can document the entire encounter on a single page. Even better than that, we document the entire patient encounter with the same code set: the UMLS. Gone are the days of diagnosis codes and procedure codes and medical coding at all. In fact, we have integrated health insurance into the EMR so we can pick up and pay for procedures performed in real time.
For the cheap seats, that means we have automated the entire health insurance industry. That will save the average consumer at least half their monthly premium.
If that level of automation sounds like something you would like to do for your company, 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.
