Listen on
Overview
Life science R&D runs on data, yet many organizations operate with fragmented, manually managed systems. Lab instruments, LIMS, and ELNs generate data with a “10x more complexity” than typical business systems, due to the inherent variability of biology and the rapid iteration of scientific discovery. This complexity leads to lost data, extensive manual entry, and significant delays in crucial milestones like IND filings—effectively reducing scientific capacity by 10-20% and hindering machine learning initiatives.
In this episode, host Ross Katz speaks with Nathan Clark, CEO and Co-Founder of Ganymede and a former product leader at Benchling, who explains how this unique data challenge necessitates a specialized, code-centric approach. He discusses why traditional data integration tools often fail in biotech, Ganymede’s developer platform for automating instrument and application data flow, and how this bottom-up automation builds the foundational dataset required for advanced analytics and AI.
The conversation explores the common pitfalls of a “data swamp” strategy, the need for agile, value-driven data initiatives, and the critical role of rigorous metadata threading. Listeners will learn actionable insights into structuring their lab data environment to accelerate R&D and improve compliance.
Key Takeaways
Life Science Data Demands Code, Not Low-Code
The “10x complexity” of biotech data—driven by biological variability and iterative R&D—means no-code or low-code integration solutions are insufficient. Effective data integration requires a developer platform and code-centric methods to precisely contextualize and transform data from diverse, often file-based, lab instruments and complex LIMS/ELN schemas.
Metadata Threading is Biotech’s Critical Unsolved Challenge
The lack of standardized instrument APIs and reliable metadata capture across lab systems forces scientists into manual data handling, consuming 10-20% of their time. Solving metadata threading by automating instrument data into structured systems of record would accelerate drug development significantly, acting as a crucial foundation for any data-driven R&D.
Agile, Incremental Data Initiatives Deliver Faster R&D Value
Large-scale “digital transformation” efforts often stall and become “data swamps” without immediate, tangible value. Biotech organizations should focus on small, demonstrable wins—like automating specific manual data entry tasks—to build momentum, secure institutional buy-in, and validate their data strategy, ultimately leading to sustained progress in multi-year R&D journeys.
AI Readiness Starts with Workflow Automation, Not Just Data Lakes
Building a solid AI foundation in biotech requires automating the capture of rich, contextualized data directly from lab instruments and scientific workflows. Simply centralizing raw data into a data lake without proper parsing, transformation, and integration into systems of record provides insufficient context for meaningful machine learning or deep analytical insights.
Related: CorrDyn provides data engineering services that ensure your systems can handle complex data, while our data quality expertise helps clean and standardize scientific outputs. We also specialize in helping biotech manufacturers gain data value and offer thorough data assessments to identify strategic integration opportunities.
Full Transcript
Jason: Hi everyone, this is Jason, producer of Data in Biotech. Before we get started, I wanted to let you know about our latest white paper. It’s a comprehensive guide to implementing machine learning models in biotech manufacturing. It’s a complete overview of all the potential problems of ML adoption, and more importantly, how to solve them. To download it, simply visit connect.corrdyn.com/biotech-ml. We’ve also dropped the link in the show notes of this episode. Okay, let’s get into it. Welcome to Data in Biotech, a podcast from CorrDyn where we explore how companies leverage data to drive innovation in life sciences. Every two weeks, we sit down with an expert from the world of biotechnology to understand how they’re using data science to solve technical challenges, streamline operations, and further innovation in their business. This week we sat down with Nathan Clark, CEO of Ganymede. During the interview, Nathan unpacks the challenges of integrating lab instruments and data in the biotech industry, and how Ganymede is attempting to solve this through its developer platform, a platform that is designed to help automate data integration and metadata management across life sciences. This was a super technical discussion between Nathan and Ross covering everything from data analysis, metadata threading, and being agile to unlock deeper insights and faster decision making. Here we go.
Ross Katz: Nathan Clark, welcome to the Data in Biotech podcast.
Nathan Clark: Thanks Ross, looking forward to it.
Ross Katz: So just to kick us off, can you give us a little introduction to your background and what brought you here today?
Nathan Clark: Yeah, so I’m one of the co-founders of Ganymede. We’re a data platform for connecting lab instruments, connecting applications in the lab, connecting every piece of data in the wet lab for scientists and automation. At Ganymede, I like to say I’m our head of solutions, so I cover our commercial team, solutions design, pre-sales and engineering. Prior to that, I worked at Benchling. I was the product manager for some of Benchling’s data products, the Insights BI tool, we built out a machine learning team there, and love all things lab data as you can probably tell. Before that I had a life in finance, in financial technology and originally as a bond trader. Very different world. I still love finance too, but my destiny’s in biotech, so having a blast.
Ross Katz: So where did the idea from Ganymede come from?
Nathan Clark: I think ultimately it’s centered around how the world of data infrastructure has evolved outside of biotech, outside of life sciences. The general data infrastructure for what people often refer to as the modern data stack is very cloud native—ETL tools for moving data in a clean and modular way between different databases and systems to get data into the place it needs to be for analysis and decision making. You get tools like Fivetran, Snowflake, Databricks are huge original drivers of that, and then a billion different ETL tools. A lot of what had happened was people realized the paradigm of saying everything is self-contained apps with APIs—that’s fine. You can build as a software engineer a way to consume or drive APIs in an event-based way: ‘I need to do this, go do this,’ or ‘I need to get this data point, go get this data point.’ But for data science and analysis use cases it’s different—you need to do large bulk, big-scale analyses on things. You need to make decisions across many data points at once, so it’s not suitable to just get data as a trickle over an API. The ETL world was born, now ELT everyone likes to say, where you extract data in bulk from a database or an API and pump it out and get it loaded into the place where you do the analysis. What struck me when I went into life sciences and started observing how companies like Benchling work, how lab instruments work, how people consume PDFs—some of the very first designs I had related to Ganymede were based around parsing certificates of analysis received as PDFs from a CRO and saying, ‘How do I take that PDF file and represent it almost as a database I can use in ETL?’ What distinguishes life sciences, thinking about ‘What if Benchling is like Salesforce?’—Benchling is very much like Salesforce—‘What if all these LIMS systems are the Salesforce side of what needs to be a broader ETL ecosystem? How do we bring this data infrastructure revolution to these really complex internally structured systems with really rich schemas?’ What distinguishes it is that one side of what you’re integrating is probably a file on a Windows computer. How do you touch that as a database? That’s not a clean online database. And things like your LIMS or ELN or MES batch record, whatever you want to get data into or out of to drive the structure of what’s going on, those also have incredibly complex schemas compared to anything out there. It’s a classic business automation problem, except it’s worse by a factor of ten. You need a really robust system for manipulating and making sense of data structure. All that to say, a lot of the inspiration was: ‘How do we deal with what makes the life sciences ecosystem unique and complex and make it so that you can move around data despite that? Despite the network challenges of a file on a Windows computer or the data structure challenges of schema richness?’ When we did that, turns out everyone wants to use it to integrate lab instruments, so here we are.
Ross Katz: That makes a lot of sense. In order to ground what you’re saying in an example, you say there’s 10x more complexity in terms of the data structure. Can you give us an idea of where that complexity comes from and what it looks like from the perspective of a tool like Ganymede that’s trying to integrate all of the data together?
Nathan Clark: To your first question of where does the complexity come from, there are two reasons. One is this is human biology. This is not something designed from the ground up to be rational or comprehensible. Going back to my experience on the fintech side—payments and financial technology, there’s an aspect of stuff having grown organically over time, but it’s still designed by humans to be comprehensible and rational. ‘This is a credit card transaction’—that is an object that makes sense to everyone, that is distinct, that you can control and design. But in the life sciences, biology is evolutionary. There’s no quarter for comprehensibility, and any time you try to say ‘Here’s the central dogma of DNA to RNA to proteins,’ you immediately start violating that. DNA doesn’t fully encode the state of a cell, obviously. And what are cells? You start getting into extracellular vesicles and messages being exchanged between cells. It’s so rich and impossible to pin down. Everyone’s definition isn’t just different because of human error—it actually needs to be different because people are studying different layers. Two people’s definition of a cell will not be the same for good reason, because they’re studying some unique aspect of it. That’s the problem—the ‘for good reason.’ That’s one thing. The other side is that people are doing R&D. They’re trying something new. They’re not optimizing a system or using existing rails of concepts—they’re discovering something new, so they’re rapidly iterating on the data structure too. Data structures aren’t just complex in space, they also change very quickly over time as people learn what they’re figuring out. Those factors make it pretty bad. To your second question, what does that look like? Even small labs with a dozen people will have 30, 40, 50 different data objects to care about, whereas a Salesforce deployment for a sales team will have a dozen canned objects and maybe one or two customizations. It’s a completely different order of magnitude in terms of the complexity ratio to company size.
Ross Katz: That makes a lot of sense. How does Ganymede approach providing a data integration solution that serves all the needs of these diverse organizations?
Nathan Clark: One thing I’ll note is it’s not just the applications that have that complexity, but the lab instruments too. One of the things we quickly realized as we started getting into lab instruments was the best way to think about data coming off a lab instrument is that it’s also a database. It’s almost arbitrary in terms of its internal structure and it needs to be arbitrary. One of the insights we had early on with the application layer was that anyone can connect to an API—what matters is how you make sense of the data inside and how it’s structured. The same is actually true for lab instruments too. Anyone can parse many of these files, they’re not hard to parse. What matters is how you actually consume and contextualize the data once you have it. From our perspective, lab instruments and the application side are very similar. From Ganymede’s side, what we said very quickly was, ‘This just needs to be code.’ No-code is completely unable to be as expressive as you need to make sense of this data. Sometimes when people build systems they look at complexity and say, ‘This is so complex, therefore I need to make it easy for business experts to describe it themselves in a non-code way.’ We tried this in the 90s with the whole Java sea of objects turning into UML diagrams, which didn’t really go anywhere—the problem is not that code is text rather than nice building blocks. The inherent complexity is so high that no matter whether you’re using building blocks or line code, it’s not doable unless you have an expert in business analysis and an expert in turning that into clean abstractions. That’s why from the get-go we said we need to create a developer platform that can handle both creating the connectors and mapping them in code to handle that complexity. Instrument connectors can have a fair amount of out-of-the-box pieces, but it’s always going to be a template. Any time people create lab instrument connectivity it’s an exercise in having a template and then doing some last-mile wiring, which can be the majority of the work to actually get it to flow. We said, ‘That’s going to have to be code—someone’s always coding it anyway, so let’s make that experience as easy as possible.’ It’s been a great paradigm because it lets us move much faster than anything we’ve seen out there.
Ross Katz: Should I think about it that you’re building the canned integrations with different instruments and systems and putting that in the hands of a technical team at one of your customers, who then takes it the last mile of the integration and helps with the contextualization—connecting the dots between what really matters to the business about their specific data? Am I thinking about that right?
Nathan Clark: That’s exactly right. I used to say we have a two-layer product platform, now I say we have a three-layer platform—a humongous amount of overhead to manage as a small team, so kudos to our software engineering team and our scientific engineering team. The three layers are: our core platform itself, supporting a developer platform that’s very good at letting you write code in a Jupyter notebook interface that then actually runs against a Windows computer to go grab log files periodically from some system. The next layer is the connectors—the templates that our scientific engineering team maintains across different instruments and apps, including common PDF reports from CROs and CDMOs. Those connectors are built and live in our product layer, in a layer any user could touch. Then there’s a third layer: the transforms. What do you do with the data once it’s connected? How do you actually move it, reshape it, or analyze it to make it flow? That’s where clients can come in. We at Ganymede often do that ourselves too—a white-glove services approach for our clients. But that’s definitely the first line where clients who have developers or people who want to dig in can do it themselves. Having clean separation of responsibilities—pure business logic versus connector logic versus the developer platform—and an appropriate software development life cycle for each layer is really important.
Ross Katz: That makes a lot of sense. It sounds like one of the big challenges of connecting the dots across these different systems and layers is tracking the metadata about what’s happening inside a given system so you know how to integrate across the different data sets. Am I right about that?
Nathan Clark: 100%. That’s the bane of our existence in a way, but that’s also why we exist. If you have a lab instrument that creates some output—a file or data ready in an API—how do you know what that data is attached to? That’s back to the problem of it being a database with a random record in it. If you want to do something with that, you need to contextualize it. There’s a whole spectrum of maturity of how deliberately you can thread through metadata, but it’s necessary one way or another. You have to associate data being generated in a lab with—we call it the unit of account internally—some sample ID, experiment ID, batch record ID, or something that lets you say ‘This is what this information is about.’ Finding a way to tie that output data to that ID lets us take it, process it, and put it where it needs to go to automate data entry into that application. We see a whole spectrum: many people just don’t capture it at all—their mechanism of tracking this data is that they don’t. When it comes time to file an IND, you are quickly in hell. ‘I gotta go to this Windows instrument PC over in this lab and—it’s not booting up because the vendor disabled it and is bringing a new PC.’ We’ve seen people have to put on a bunny suit to go get data from pressure-controlled potentially toxic environments. Real hardcore data science. Sometimes people start to gather data centrally as their perspective matures, but we call that sneakernet—going physically into the lab to get a USB stick or emailing it to themselves. As people go further they start saying ‘I need to sync all this data into a single place,’ so they develop a data strategy to have the raw data synced somewhere. But then you still have to manually associate data. People have to manually pull from a list—if they’re filling out an experiment, they’ll pick the file that this went to. It works, but it’s difficult. You still have to go find the file. You still have lots of files that never get associated with an experiment—and after a few months no one remembers what those mean. You can push the files in and force people to add context to every file, but ultimately there’s no substitute for a more deterministic method where you say: during this time, everything from this instrument is associated with this experiment. That’s a step forward—you’re not touching files directly, you’re saying there are instrument runs and there’s context somewhere, and the files are just an intermediary. We think it’s best to define that in your ELN, batch record, or LIMS system—that’s a great data entry front end and data structure back end for this. Files can flow in, whether you build it in Ganymede or from scratch in something like AWS. The gold standard is when the instrument can emit data or files with that metadata already on it—then you can pick it up, parse it, and already know what to do. The question is how the instrument knows what the metadata is, and the answer is you have to tell it. You have to either kick it off automatically from a system like Ganymede or load a config file or plate map with all the metadata IDs—those unit of account IDs like a sample—onto the instrument to start it. That’s how we frequently integrate. We call it a full loop: start in the system of record like the ELN, LIMS, or batch record, and when someone registers an experiment or kicks off a run, that triggers us. We take information from that application, put a file or kick off something on the instrument through one of our agents, and then our other agent collects the data when it comes out and puts it back. It’s a loop, but the ideal is you shouldn’t have to do anything other than put your metadata into your system of record, press play on the instrument, and then it all flows.
Ross Katz: It strikes me that it’s not just Ganymede that needs to be in the loop—there needs to be a way of managing data in your system of record, your ELN or LIMS, that enables this kind of workflow. Am I understanding correctly that in your ELN or LIMS you’re loading the plate map, config, and all the metadata about the samples you’re running, and then you go into Ganymede and say ‘I intend to use this plate on this instrument’ and trigger the workflow from there? Or how does that closed-loop work from a process perspective inside a company?
Nathan Clark: I’ll call that the silver standard. Gold standard is that Ganymede is never touched—it’s just running continuously in the background, either polling or getting a webhook or event from the system of record saying ‘Someone just registered a plate map, created a new unit op section, or started a new batch record section with these parameters.’ When we see that, we say ‘Someone’s doing this—I’m going to load that onto the instrument.’ From the user’s perspective, they’re only in their batch record, ELN entry, or LIMS sample form, and when they give the required input information they just see a file appear on their instrument PC to use as a config. In some cases the instrument can automatically start. The instrument runs, the output is automatically captured, automatically parsed, analyzed, and put back into the system of record. It really is as simple as: ‘I put the required inputs into my system of record, I press play on the instrument or maybe not even, and then the outputs appear.’ That is all it should be. You fill out the information you need in your system of record, then you purely focus on scientific decision making. But gold standard is hard to achieve—there are a million fractal ways that lab instruments and workflows prohibit it, or the particular ELN or LIMS systems people are using don’t have the right integration interfaces or even APIs at all in some cases. We always find a way, but that’s why having a developer platform approach is so essential to handle when it doesn’t go smoothly, which is frequent.
Ross Katz: It sounds like you start from that gold standard where they’re never really interacting with Ganymede—all they’re doing is interacting with their ELN or LIMS and with the instrument directly—and the metadata is just magically captured. But depending on the nature of the instruments that need to be integrated, there may not be the middleware necessary to enable that, so Ganymede creates tools at varying levels of the stack to glue the systems together in whatever way is optimal for that ecosystem. Am I thinking about that right?
Nathan Clark: That’s exactly right. That’s where it’s so important for people to think about this and to really treat their lab as a data object. If you’re going to get to that perfect golden future where people are living entirely in the system of record and not having to move data around much, you do have to have a really crisp structure to that system of record. You need to design it very deliberately up front. That can be very difficult and it’s a little different than people think about naturally. Creating it in an automation-centric way is a complex and different perspective. But it’s a healthy one: the business of R&D is generating data to answer a question. The questions and the data mutate very quickly, but taking that data-first approach—what data structure do you want to answer your question in the abstract, then encoding it into the system of record and using that to drive the automation—that’s the process we usually drive people towards.
Ross Katz: What are some of the nightmare scenarios for companies that don’t take their metadata as seriously as you’re describing? You mentioned someone applying for an IND who has to put on the suit and go into the lab to pull files off. What do you see companies having to retroactively change to avoid those scenarios?
Nathan Clark: The milestones people reach around things like INDs or later stage FDA filings are great catalysts for illustrating what those nightmare scenarios look like. The answer is a ton of work. They’re good illustrations of what is actually a continuous problem throughout the R&D life cycle—if you’re losing data, if you’re having to do all this manual data entry work, that’s going to slow down your science quite a bit. But it’s hard to notice outside of the moment when you’re forced to reconcile everything up to the data maturity level required for an IND filing. That can be months and months of work. Many person-years, where people have big initiatives for a month across everyone in their lab to go get all the data, sort it, parse it, potentially re-run experiments in many cases—not for any good reason other than the data was missing or doesn’t make sense. That persists throughout the life of organizations. A good example: we spend a ton of time looking at what scientists are doing with their hands because our view is it all comes from driving the full end-to-end automation—getting data from lab instruments all the way through to automating data entry in the system of record. In manufacturing environments especially, people ask, ‘What is the difference between Ganymede and MuleSoft or Ganymede and Boomi?’ And I always say: ‘Is your actual scientific decision-ready data going into your system of record? Is your batch record automatically being filled out, or are people still typing stuff in?’ The answer is they’re still typing stuff in because you need that analysis in the middle. That typing into systems of record can consume entire days—scientists, technicians, operators spend 10 to 20% of their time filling out these systems. It gets worse as processes scale up, because central data consumers—IT, compliance, data science—want more and more metadata captured. People end up taking all of Friday afternoon filling out their ELN entries, which is horrifying: that’s a lot of time, and they shouldn’t be doing it only on Friday—they should be doing it throughout the week as they do their work. That’s the scenario people are often in, and it can be hard to point at it and tell clients ‘This is a problem’ because they say, ‘I can always hire more scientists.’ But you really can’t. You have someone doing the experiment—they’re already doing it. You don’t need more bench work, you just need that same person to fill out the data. They’re only operating at 80% of their capacity because they’re wasting 20% of their time going to get files off a USB stick or trying to remember what sample this was to find the right file to attach to their ELN entry.
Ross Katz: Yeah, how does Ganymede assist with that workflow automation that you’re describing about the—
Nathan Clark: The answer always starts with stopping the bleeding as quickly as possible. We’ve recently segmented out what we call the SDMS layer of our product—the scientific data management system layer for getting data from the full end-to-end core integrations layer, although they go hand-in-hand. What we always say is: first, let’s look at all the data in your lab. What does it mean? Do you have it contextualized, or do you know what context you’d want to track on it? Then go through and inventory where that data lives, who is generating it, what its purpose is, where it flows. We start from the assay outward. We always start by interviewing the scientists: ‘What are you doing with data? What files are you using? What data entry are you doing in what systems?’ And everything has secret Excel somewhere along the way. As much as I love Excel—it’s an amazing tool—it is a sign that something has gone awry when you’re trying to do a standardized process. There’s secret Excel, secret data entry everywhere, secret file management things that people are doing that central informatics people can’t even see. The biggest thing is just understanding what people are trying to do and where the data is flowing. We have all sorts of different tools for getting and managing that data, but the main one is our Windows agents. These are executable programs you install and define in the Ganymede cloud—you can manage the logic of how they run in the cloud, because if you’re trying to pick up file A today, tomorrow it might turn into file format B. The logic can be managed in the cloud, then you download and deploy it and it runs as a service on the Windows computer. Usually it’s just picking up a file, but we constantly see edge cases in what it means to have ‘just a file.’ Instruments will have one run create seven different files in some unique folder structure—sometimes that structure is dynamic and you can’t anticipate it. Instruments will just overwrite the same file over and over because that’s how they were designed; logs can be that way. Recently a client told me their instrument appends to the same file over and over until the end of the month when it’s wiped and starts anew. To capture data from each run off that, you have to have logic that says ‘Every time this file is updated I’m going to get all the updates and call that a new run.’ That requires code. You can’t anticipate that. That’s why we’ve designed the platform to give people a way to automate all this interpretation and file-finding. We’re not going to say ‘Here’s an out-of-the-box file watcher.’ There is one, but people say ‘It’s not actually a file every time,’ and then we say ‘It’s just a one or two line code change to accommodate that,’ and then it starts flowing.
Ross Katz: What is the impetus typically for a company to look at their systems and processes and realize they need a tool like Ganymede to enable the data integration they haven’t been able to achieve before?
Nathan Clark: There are three scenarios. One is companies that already understand this—and although I’m going over a lot of this as if it’s purely our perspective, we’ve learned it from the industry. There are a lot of really smart people in biotech who understand these problems, especially informatics and IT folks, and anyone in lab automation, process development, or data science. People will organically develop a data strategy and say, ‘I need to figure this out. I can’t have scientists leaving files on random PCs. I want a central data repository.’ They’ll start with something like SharePoint to manage files, then realize it’s generic, incomplete, still just a file storage system. It doesn’t contextualize the data the way they need, and it can’t handle things like log files that get continuously overwritten. They start building automation on top of it, start seeing they can parse a lot of this and build scripts, but it becomes unwieldy quickly. We’ve designed Ganymede to be an out-of-the-box data layer the way leading enterprises and leading tech biotechs have designed it when they have infinite engineering team resourcing. I spent a lot of time early on studying Ginkgo and looking at their tech stack—they have an amazing perspective—and a lot of Ganymede is asking ‘Could we offer that out of the box?’ That resonates with people who have a data strategy and know proactively that they need a data management system and need to automate what people are doing. The second scenario is the painful one where people ran into IND issues or their data has become so unwieldy that it’s obvious to everyone there’s a problem. We’ll usually go in, and that’s even more consultative because we need to go through how to think about the data strategy—something we do a lot. The third interesting scenario is large pharmas with a big digital transformation strategy they’ve been working on. They’ve built out the central layer, got data going into something—a big data lake, a central PubSub bus, Kafka, MQTT layers. Then you’ve got the data—okay, there it is. What do you want to do with it? That’s where there’s a turning point: ‘Now there’s still more work to be done. We need to actually analyze this data, put it into systems, and also contextualize it further, which requires driving the instruments on the other side too.’ We come in and say, ‘We’ll take that data—if it’s already in a PubSub thing, we don’t need the Windows agents—and do the next stage: make sense of it, contextualize it, and analyze it.’ We see that a lot in companies with strong manufacturing IT and software departments, because in manufacturing everything is event-based and runs through data historians and middleware. But that breaks down in R&D or QC—you don’t want event-based data, you have big analytical batch sets. They put everything into central PubSub systems but can’t do anything with it because it doesn’t have the right context to drive the analysis.
Ross Katz: How does Ganymede help with the next step once the data is in a structured format, and what do workflows look like for companies leveraging the data Ganymede is helping to integrate?
Nathan Clark: Two big pieces. One is we have very strong connector templates for applications like batch records, LIMS, ELN systems, sometimes even QMS or inventory systems. Those are pretty stable connectors—you can get a lot going without much customization, although there’s still some. There’s a lot of value in just having those connectors to say, ‘I have my raw data, I want to put something into my system of record,’ and we supply that connector even if we’re not supplying the instrument connector. If we have the raw data from PubSub, we might still need to do some parsing or transformation on the instrument side. But the next question is, ‘What do I want to put into my system of record?’ The classic case is a bioreactor. People will have millions of time series data points over weeks of bioreactor data—that’s not suitable for any system of record. You’re trying to say, ‘Was my production run good? What is my titer? What does this metabolite look like?’ That’s a single data point or a few data points as a series of checkpoints every six hours. It needs to be crunched down. That’s where the analysis comes in: we take the PubSub data, we have the connector to the app, but to actually get that raw data into the app, you don’t want the raw data—you want it analyzed. That’s where our code analysis environment is really good: it feels like a data science pipeline except it’s actually touching your real systems on either side. That’s what gives you the flexibility to quickly automate and iterate on the analysis and transformation in between. That’s what’s required to make the data flow.
Ross Katz: For the customers that have data science teams, how are they interacting with Ganymede? Are they leveraging the data exhaust coming out of it and doing analysis in another environment? Are they doing analysis directly in Ganymede?
Nathan Clark: It’s a mixture of the two. We love it when data scientists want to use the platform. We have a lot of out-of-the-box tools built into Ganymede, like our analysis notebooks to leverage the data. We also have a pretty rich dashboarding layer on top of our data or anything else people want to connect to it. But plenty of people want to do their own analysis outside of Ganymede, and that’s fine. We almost always—even when automating instrument A into system of record B—also take that entire lineage of data from raw to parsed to analyzed and put it into their data infrastructure if they have one. We work a ton with Snowflake and love putting as much data into Snowflake as possible. That’s how data scientists experience the Ganymede platform: ‘This is a magic wand for putting more and more rich, contextualized data into my Snowflake than ever before.’ As for what they do with that data—I’ve built out machine learning teams at multiple companies. This is a really hard domain to get machine learning or AI going because the data is not that big in the scale of things. Even the million-data-point time series data isn’t that big, and the context is so varied. It’s very hard to assemble a fully contextualized data set and ask the question: what are you actually trying to model? The way we help support data scientists is by giving them this rich contextualized data set. We’re adding more and more context fields onto the data so that people can actually get going on their machine learning journey. We always say: in this space it’s so hard, you really have to get simple statistics going first. Can you do a linear regression on your data set before you do machine learning? Maybe it’s not that useful, maybe you need to derive deeper insights, but do it as a hello world because that invokes the question: linear regression on what? Do you actually have all the columns? Do you actually know what you’re regressing? Everything flows from there. That’s how we support data scientists—build that AI data foundation for you, give you the data on a silver platter, and then let you go from there.
Ross Katz: It feels, given the diversity of customers you serve, that there’s a lot of process mapping up front as part of your sales or implementation process. Is there an implementation engagement your services team does when you first kick off with a customer?
Nathan Clark: Definitely. It varies a ton based on the customer’s need, but the answer is always yes in some form. If the customer has a narrow scope and has already done a lot of the work to get their business process modeled and properly implemented in their system of record, that makes it much easier—it can be a month-long engagement or even just a few weeks to look at that, ingest it, identify the data points we need to get or write to, and go from there. But with many customers there’s more to do—maybe they’re somewhere on their ELN or LIMS implementation journey, maybe they’re moving from paper batch records to an MES. There are so many ways this can be complexified. We have a pretty great implementation team that can get into the weeds on consultative work if needed. We also have a good partner network—plenty of partners and consultancies that come do the business analysis or system of record implementation work to get it to the point where it’s ready. I think it’s quite important to do both hand-in-hand. People often want to say ‘I’m trying to figure out my electronic systems before I look at automation.’ But the data-centric mindset is to say you should be thinking about what are the different data sets in your lab that you need the physical world to generate, and then how do you move them into different systems. We always say it’s best to do it all hand-in-hand and think about the automation layer first. That also influences and drives considerations in the system of record implementation—you truly need to capture every single data point in the system of record beyond even what you need scientifically. Operational things also help drive some of that. It’s ultimately a much better world.
Ross Katz: As you think about potential customers out there—biotech companies that are starting to get their data integration and metadata management practices in order—is there any advice you would give about laying the groundwork for the data future they need to create for themselves?
Nathan Clark: Probably the biggest piece of advice—and we’ve seen this in the last 10 years in big pharma where they enacted huge digital transformations and then you also get what we call the data swamp rather than the data lake, because you have all this raw data and no one’s touching it—is: be agile about it. Agile in this context means make sure everything is delivering value, make smaller changes more incrementally, and measure the value as you go. You can’t make a huge jump all at once. You need to be demonstrating value as quickly as possible, which means saving scientist time. When you think about speeding up your multi-year R&D life cycle, you will get there. When you think about an AI initiative across all your labs, you will get there. But it’ll take years, and in the meantime scientists aren’t seeing value and you aren’t validating that you’re going in the right direction. You want to learn as quickly as possible. You can also lose institutional buy-in from executives: ‘Markets are bad now, it’s 2023, 2024, not a fun environment compared to 2021. We need to cut costs. Sorry for your whole digital transformation.’ We’ve seen that happen so many times. That’s why we always say be more incremental—focus on what immediate value you can deliver within a month, which ends up being time savings, automating a specific piece of what scientists are doing. It’s very bottoms-up. You need both the top-down initiative and vision, but the missing piece a lot of people lack—it’s a different paradigm and just very hard to execute on—is that bottoms-up component. If you want to build a good data set for AI, you should automate what scientists are doing with their hands. That’s a non-obvious thing, but people start seeing it and then realize it’s very hard and that’s really the work to be done. AI comes from having a good structure in your ELN, LIMS, or MES—another non-obvious aspect. You need the building blocks: building blocks in terms of the data and in terms of delivering smaller incremental wins so you can build momentum for the multi-year journey ahead.
Ross Katz: In my experience with data-driven digital transformation, demonstrating value every step of the way and building a longer-term roadmap from small initiatives that are valuable in their own right is a really good piece of advice. What about the roadmap for Ganymede? What do you have on the horizon that you’re excited about?
Nathan Clark: One interesting thing we’ve found in the last few quarters that’s really gaining resonance is more productized and templatized analysis systems and data systems for what we can do with the data. We’ve done a ton of work on instrument connectors and application connectors. We have connectors for pretty much everything common out there and can easily build more. But increasingly people put data into Ganymede and are doing really incredible things on the client side—implementations we’ve built like asset utilization, managed AI or machine learning analysis, building out a digital twin in Ganymede to say ‘I want to automate my entire process development life cycle and workflow, or do predictive DOE using all this data.’ We have a big partnership with Elemental Machines, which provides environmental sensors for temperature, humidity, pH, and gluing that data set onto everything and seeing what happens. Some really interesting insights come out of that—‘This instrument always seems to be faulty but we can’t figure out why. Turns out the sun is shining on it through the window and not on the others, so it runs hot and the plates evaporate faster.’ What we’re really excited to be launching soon is a broad suite of what we call data products, built on top of the Ganymede platform—out-of-the-box solutions and visualization layers for things like DOE, asset utilization, and reliability. We’ve been building this with a lot of our clients and have a pretty robust system. It’s always templates that require some connectivity and mapping, and with data products it’s a bit of what you give is what you get—if you want to fill in more data, you need to integrate more data sources to add more context. But what we can do with that context leads to really unique outcomes that require different systems to be integrated and that people haven’t seen before: true predictive maintenance, true automated DOE. There’s a lot we can do there.
Ross Katz: Awesome. And before I let you go, just one last question. What’s the biggest unsolved challenge that you see in the biotech data ecosystem today, either one that Ganymede touches or one that it doesn’t?
Nathan Clark: Metadata threading, honestly. Metadata threading and having instruments either emit data in a clean, easy-to-parse format or—even better—be online in an API. If every instrument just had a web API that let you kick it off with an ID and then get data back with that ID on it, that would solve a lot of problems. Genuinely, it would accelerate life sciences medical development by five, ten percent—life changing for millions of people, and it’s a data standard. That’s why we’re in this business: to make an impact on patients’ lives. In the meantime, Ganymede’s business is to help manage the fact that most instruments in life sciences workflows aren’t that simple, but still try to get to the point where it feels that simple for the scientist.
Ross Katz: Nathan, it’s been amazing having you on, really appreciate the time and look forward to connecting down the line.
Nathan Clark: Thank you Ross, it’s been great.
Jason: And that’s it for this episode of Data in Biotech. If you enjoyed the episode, please subscribe, rate, or leave a review in your podcast platform of choice. See you next time.
