Last week, I wrote about an open source project called Foam meant to help biotech teams build custom applications to fill in the gaps between their other software. But there’s one thing I should be very clear about - Foam is meant to make building software easier in the same way that saw mills made building a house easier: You no longer have to hand cut each piece of wood, but you still have to do a lot of building. So Foam should only be a last resort when you can’t buy software that does what you need. This week I want to argue that those situations are becoming and will continue to become much less common. (I hope Foam can help bridge this transition.)
Its a tough course to navigate, off the shelf tools can cover most cases, but they tend towards either generalized approaches or "no code" highly complex configuration. So you escape the high cost of software development but still carry the technical debt of maintaining the purchased tool and integrating with its neighbors. They get you there faster but still at considerable cost.
I also think there is a shift in the type of problems custom software is solving, it used to be more web portals and now is more in the data space.
That's a good point. I think this shift in the type of problems is accompanied by a shift to more technically inclined clients/users - data scientists as opposed to bench scientists.
This is a good post Jesse. It's something I think a lot about in the buy vs build. I think your analogy of building a house is a good one. There are tradeoffs with a custom build vs cookie cutter, personally I prefer somewhere in the middle (old house + reno)
Stay tuned for Sapio Jarvis...it is complete game changer for SDMS going well beyond these other solutions. It is being released shortly and will support 200+ instrument types but uniquely has built in science tools, powerful data searching/data visualizations, a knowledge graph and integrated analytics. Jarvis will solve the data problem that exists at biopharma...the days of glorified directory services and dumb data lakes are going to end...they have too.
Well on the house front, some modern homes can look cool in the right setting. I generally prefer the aesthetics of the older home (provided it has some modern amenities).
In terms of software/platforms, they generally don’t age well. I am intrigued with companies that decide to completely rebuild their stack rather than put band-aids on them. Unfortunately not many companies do that. Generally I prefer building on an existing foundation, that has good documentation, good community support, solid APIs and a good overall user experience.
Thanks for the post - it is close to my heart for obvious reasons: With UniteLabs, we're building a Connectivity platform for HW/SW integration with a code-first approach. The user is always going to be able to build integrations and workflows with as much flexibility and power as possible. Meanwhile, we try to abstract as much of the infrastrucutre and connecitivity diffuclty as possible.
Its a tough course to navigate, off the shelf tools can cover most cases, but they tend towards either generalized approaches or "no code" highly complex configuration. So you escape the high cost of software development but still carry the technical debt of maintaining the purchased tool and integrating with its neighbors. They get you there faster but still at considerable cost.
I also think there is a shift in the type of problems custom software is solving, it used to be more web portals and now is more in the data space.
That's a good point. I think this shift in the type of problems is accompanied by a shift to more technically inclined clients/users - data scientists as opposed to bench scientists.
This is a good post Jesse. It's something I think a lot about in the buy vs build. I think your analogy of building a house is a good one. There are tradeoffs with a custom build vs cookie cutter, personally I prefer somewhere in the middle (old house + reno)
Thanks, Steve! By old house + renovation, do you mean off-the-shelf software, augmented with scripts and connectors, or something else?
Stay tuned for Sapio Jarvis...it is complete game changer for SDMS going well beyond these other solutions. It is being released shortly and will support 200+ instrument types but uniquely has built in science tools, powerful data searching/data visualizations, a knowledge graph and integrated analytics. Jarvis will solve the data problem that exists at biopharma...the days of glorified directory services and dumb data lakes are going to end...they have too.
Sounds interesting! Looking forward to hearing more about it.
Well on the house front, some modern homes can look cool in the right setting. I generally prefer the aesthetics of the older home (provided it has some modern amenities).
In terms of software/platforms, they generally don’t age well. I am intrigued with companies that decide to completely rebuild their stack rather than put band-aids on them. Unfortunately not many companies do that. Generally I prefer building on an existing foundation, that has good documentation, good community support, solid APIs and a good overall user experience.
Thanks for the post - it is close to my heart for obvious reasons: With UniteLabs, we're building a Connectivity platform for HW/SW integration with a code-first approach. The user is always going to be able to build integrations and workflows with as much flexibility and power as possible. Meanwhile, we try to abstract as much of the infrastrucutre and connecitivity diffuclty as possible.