Are you buying the model or the implementation?
There are two major hard parts about building a digital twin of a biotech lab: The first is the conceptual problem of designing the interfaces, workflows and schemas that will accurately and exhaustively represent how your lab and the larger organization operates in a way that makes sense to users. The second is the technical problem of implementing it all.
The first one is what I’m calling the model - it’s a conceptual abstraction that exists in your mind and in design documents. The second one is the implementation - the tangible and practical digital manifestation of the model. In upcoming posts, I’ll go into more detail about each of these, but for this week I want to look at how the two play into what’s arguably the most important decision: build or buy?
The build vs buy decision is always a question of trade-offs, but the considerations between the model and implementation are very different.
The calculus around implementation leans heavily towards buy over build because your own implementation of the same model probably won’t be significantly better than someone else’s. Yes, there’s a lot of software out there built on outdated technology with untold layers of technical debt. But if it works OK, then it’s probably not worth the cost of building it yourself. If you’re just looking at implementation, you always buy.
The model, on the other hand, is more of a mixed bag: On the one hand, every biotech organization follows a different model tailored to their unique scientific approach. So it’s very unlikely that the software available to buy will match your model exactly. Often this software can be configured to tweak the model, but the flexibility is usually limited. So the main appeal of the build option is that you can have a digital twin whose model accurately reflects your organization’s.
But designing the model is still hard - in some ways, harder than implementation. Turning the implicit structures and processes of your organization into a concrete specification requires a level of self reflection that does not come easily to many (or any) of us. So the fact that off-the-shelf software comes with a predefined model can actually work in favor of buy, as well as against it.
What this means is that the build vs buy decision often boils down to the following question: Can you buy software whose model is close enough to your organization’s model that the operational cost of the incompatibility is less than the cost of designing a better model and implementing it?
In the next few posts, I’ll explore what goes into one of these models, and what these incompatibilities look like. Then a few posts about implementation.
Scaling Biotech is brought to you by Merelogic. We’ll help you design and build your information architecture to support modern AI applications, ensuring you can turn your ML prototypes into tangible impact. To learn more, send me an email at jesse@merelogic.net