When I talk to folks about the software landscape in biotech, there are two opposing forces that seem to subtly have a huge impact on the decisions people make, both when designing commercial software and when choosing what to adopt. One of these forces encourages granular, modular, interoperable software. The other encourages all-in-one, monolithic, proprietary platforms. If you read those two sentences and think one is obviously the better option, well, this week’s post is for you. Below I want to explain why there are market forces that encourage both of them.
I’ll start with granular, modular, interoperable software because I suspect that that’s what most readers of this newsletter would vote for. The goal is to be able to build your “stack” by picking from different narrowly-scoped pieces that all work together with each other. Whether the pieces are open source or paid, this would give you the most flexibility. Maybe even enough flexibility that you wouldn’t be tempted to build everything from scratch. Plus there’s less vendor lock-in because swapping out a single module is easier than swapping out the whole system.
And while that lack of lock-in may be a concern for some of the bigger and older software companies, it’s a great thing for the newer players (and there are a lot of them today): You don’t need to spend years building out the functionality of a complete platform before you can start selling it. Just build out one piece that you can do better than anyone else and make sure it works with the adjacent components. Then when you’ve gotten as far as you can with that, build the next piece. There’s no external pressure towards scope creep.
Sure, there are some technical issues with building a modular ecosystem like this. You need standards that the ecosystem may not be mature enough to develop. It’s hard to build a billion dollar company around a narrow scope. So you need incentives for folks to participate. But I don’t think the problem is with software developers - Almost all of them I talk to would prefer to be part of a modular ecosystem.
Instead, the main reason this hasn’t developed yet seems to be because many biotech organizations - the people buying the software - don’t actually want it.
I know what you’re thinking - Why would anyone NOT want an ecosystem of modular tools that a biotech organization can fit together into the perfect custom system just for them?
The problem is that the folks who end up making many of these buying decisions aren’t software engineers and data scientists. The software engineers and data scientists are off coding their own completely custom tools. The people who buy software are biologists and executives. To them, fitting together a bunch of modular tools just sounds like work.
And they’re right - it is work.
There’s this weird phenomenon that I’m sure you’ve noticed by this point in your career: People with technical backgrounds and expertise tend to underestimate the time and energy that technical tasks will take, while non-technical people tend to over-estimate them. I guess it has something to do with our natural tendency to fear the unknown. But in this case, while they may be over-estimating the complexity, there is a cost and it’s real.
So the folks who are farther separated from the technical aspects of implementing these systems tend to be much more reluctant to take on technical work, even if someone else is going to do that technical work. They’d rather those people do technical work that’s closer to the science. They’d rather write one check to one software company. They’d rather not think about it, or force anyone else in the organization to think about it.
And so, all those software companies that would love to build narrowly scoped apps that integrate into a modular ecosystem end up feeling pressure from customers to expand their scope - add an ELN, run bioinformatics pipelines, design plate maps, you name it.
So, this is going to be one of those posts where I mostly write about why a problem is hard without offering any suggestions for how to address it. Maybe someday I’ll have a better idea, and I’ll write about it then. But for now, all I can do is tell the folks out there who would love an ecosystem of modular, interoperable, biotech software tools: This is why we can’t have nice things.
Thanks for reading this week’s Scaling Biotech! I really appreciate your continued support, and I read every comment and reply.
As a reminder, I offer several services to help connect biotech teams with tools, practices and expertise to make their organizations more data driven.
For Biotech Startups: Sign up for a free consultation call to clarify a problem you're facing and identify the best options to evaluate.
For Software Startups: Add your application to the upcoming launch of the Biotech Reference Stack so your target users can find you.
For IT/Informatics Consultants: Learn how Merelogic can help you write white papers and case studies to define and demonstrate your specialized expertise.
Great post. I would say many non-technical folks often UNDER-estimate software development effort. "You can just add this in right? That won't be too hard, right?".