Listen on
Overview
Traditional R&D experimental design often leads to wasted resources and slow progress. This episode reveals how applying Bayesian optimization can accelerate biotech R&D by 30-95%, offering a path to faster market entry and significant cost savings. For data and engineering leaders, this represents a direct impact on operational efficiency and competitive advantage.
Wolfgang Halter, Head of Data Science & Bioinformatics at Merck Life Science, shares how his team developed “Baby”—an open-source Bayesian optimization library—to precisely guide experiments. He explains the shift from static, classical experimental design to an iterative, probabilistic approach that incorporates prior knowledge and uncertainty. The conversation covers how this method balances exploration and exploitation, optimizes multi-objective problems like balancing cost and quality, and the powerful role of transfer learning in utilizing past data for new insights.
Halter also addresses the broader data challenges facing biotech, including the prevalent use of Excel, fragmented data models, and the need for greater standardization and modular thinking across R&D labs. He provides practical advice for data professionals entering the field.
Key Takeaways
Bayesian optimization delivers significant R&D time savings.
Traditional experimental design often wastes resources by not incorporating previous knowledge or uncertainty. Bayesian optimization, as implemented in Merck’s “Baby” library, can accelerate R&D campaigns by 30-95% by iteratively guiding experiments to optimal outcomes, balancing exploration and exploitation. This directly translates to faster product development and reduced material costs.
Transfer learning multiplies the efficiency of new experiments.
Starting new experimental campaigns with prior knowledge from similar past projects drastically reduces the number of experiments needed. By “warm-starting” Bayesian optimization with non-uniform priors, organizations can achieve up to 95% time savings, highlighting the compounding value of well-structured historical data assets.
Lack of data standardization hobbles cross-lab insights in biotech.
Despite advanced analytical tools, the biotech R&D landscape remains fragmented by reliance on Excel, manual data collection, and non-interoperable vendor systems. This absence of a universal data model prevents organizations from generating unified insights across labs and fully utilizing automation. Addressing these foundational data quality issues is critical for large-scale R&D efficiency.
Adopting engineering’s modularity can transform R&D data flow.
Natural scientists’ “end-to-end” thinking, while valuable for deep understanding, often overlooks the need for standardized interfaces between research components. Applying engineering principles like modular design and “API-first” approaches to experimental workflows and data collection would create clearer boundaries and enable more efficient data sharing and analysis.
Related: CorrDyn deeply supports biotech and life sciences organizations with advanced machine learning solutions and robust data engineering. Learn how to unlock data value for biotech manufacturers.
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 Wolfgang Halter, Head of Data Science and Bioinformatics at Merck Life Science, a leading global science and technology company. During the interview, we discussed the BayBE project at Merck, an open source library they have built for Bayesian optimization and how it’s used for experimental design and to accelerate innovation across the group. In some cases offering time savings of 50%. The pair discuss the benefits and challenges of Bayesian optimization, including the need for standardized data models and Wolfgang also shares some advice for young scientists and engineers in the biotech industry to get ahead. Here we go.
Ross Katz: Wolfgang Halter, welcome to the Data in Biotech podcast.
Wolfgang Halter: Hi Ross, thanks for having me.
Ross Katz: Awesome, well just to kick us off, could you just give us a brief overview of your background and career to date?
Wolfgang Halter: Sure. So I studied Engineering Cybernetics at the University of Stuttgart. I focused during my studies on systems biology, did my PhD in synthetic biology also in Stuttgart with a few stays abroad. Since 2019 I started as a data scientist at Merck for the life science business of Merck and today I’m leading the data science team and the bioinformatics teams since 2021.
Ross Katz: Awesome. So why do you do what you do? What motivated you to take this path?
Wolfgang Halter: It’s a good question. I think it’s an urge for efficiency. I know this is very stereotypical, but I really have the feeling that there are so many valuable insights oftentimes covered in data and for me it’s a real pleasure to unpeel those insights and to leverage them to make things work more smoothly and more optimal in some sense.
Ross Katz: Awesome. And so, can you just talk a little bit about the mission of Merck Life Science as well? What kind of work does it do and then also how does it relate to the Merck Group more broadly might be helpful as well.
Wolfgang Halter: Sure. So let’s start with the Merck Group. The Merck Group is divided into basically three sectors: an electronics business, healthcare business and the life science business. For Merck Life Science, the main mission is really to impact life and health with science. That means we are a service provider as well as producing products for the life science industry, for other pharmaceutical companies, and we envision a world where our innovative products and services and digital offerings help to create solutions for people and we want to do that across the world and to ensure a sustainable future for generations to come. That’s the main vision of the company. That means also we work usually in a very much partnership-focused relationship with our customers, with our patients and, with different goals in mind: working on life-saving therapies, diagnostics and preventative solutions as well as ensuring scientific breakthroughs and tackling the really hard challenges of research and development. It’s all about challenging the status quo and being innovative in everything we do.
Ross Katz: And so, as a data science team, how do you support that work?
Wolfgang Halter: The data science team here at Merck Life Science is embedded into something that’s called Analytics Center of Excellence. We are really a hub around data analytics in general. We have lots of teams that are also supporting the whole journey around data analytics, from data ingestion to data governance to creating insights using that data to creating applications that then help solving certain problems in the business. The data science team itself, we really support that journey with a focus on creating insights with the data that we gathered. In particular, we are trying to craft AI and bioinformatics solutions to accelerate innovation in life science. That’s the core of our part and then one very important side business is also providing skills as a service to the whole company whenever they need something like that and to upskill the people in the company to foster the data-centered view in everything we do.
Ross Katz: Interesting. So as a center of excellence, you’re charged with disseminating insights directly but also helping to build tools and embed capabilities in different parts of Merck Life Science that enable the business to drive insights and improve efficiency more broadly. Am I thinking about that right?
Wolfgang Halter: Yeah, absolutely. Yeah.
Ross Katz: Awesome. I know that your team has been working recently on a tool related to design of experiments, DOE. Previously we had Markus Gershater from Synthace on to talk about DOE and I’m interested in the work that your team has done related to DOE. I know that you’ve been working on an open source tool called BayBE, am I pronouncing that correctly?
Wolfgang Halter: Yeah, I- yeah, we call it our baby, so yeah.
Ross Katz: Okay, yes. If you wouldn’t mind talking a little bit about how your team integrates with design of experiments more broadly at Merck Life Science and how that led you to the development of BayBE.
Wolfgang Halter: BayBE stands for Bayesian back end, and that already tells you what it is about: at the core it’s a toolbox around Bayesian optimization. Bringing that together with design of experiments shows you a little bit our way of thinking in that area. We started our first design of experiments use cases about four years ago when I also started at the company, and there were probably some more of them around before I was there even. My colleagues and I were coming more from the scientific and academia world so we were also thinking, why are people still doing this old-fashioned design of experiment approach? There are so much better methods available these days. But when you look into the offerings, public offerings like vendors and professional softwares for that, you don’t find too much going beyond classical DOE. That’s where we started developing more probabilistic-based approaches, more iterative approaches where you take into account all the information that you have about your system with each optimization step. That’s at the core of BayBE.
Ross Katz: Interesting. I think it’s worth spending a little bit of time on what were the classical approaches to DOE and why is the Bayesian approach the right alternative to that?
Wolfgang Halter: For me, the classical approaches are the ones where you look at maximizing your information content and you basically design your experimental space just based on the parameter space that you have. But you usually don’t take into account what kind of experiments you already did in that area. And if you do, you always do a full factorial or something like that, either way with a limited or new parameter space. With BayBE, it’s different because we really incorporate all the knowledge into the priors that we have about the parameter space. That gives us a predictive model about where we expect the highest outcome at what probability. The key here is really including probability measures in your design because that allows you to do a nice balance between exploitation and exploration where you say, ‘I really expect something to be much better than what I have experienced so far in that area,’ but another area also looks promising, so I’m going to focus on those two while those where it’s just very unlikely, you don’t do any experiment at all. It’s really this incorporation of uncertainty and previous knowledge about your system. That’s the difference.
Ross Katz: Interesting. I’m going to try to say back to you what I heard to make sure I’m understanding correctly. In classical DOE, you had a sense of what your parameter space was — the variables that you can change in order to influence the experimental outcome that you care about. I noticed in BayBE, you’re targeting yield or something along those lines. The classical approach is picking points inside all of these different parameters that are widely spread so that you can see broadly speaking in a static view what the space looks like and then choose the optimal point in that space and work from there. On the Bayesian side, what I hear is that there’s this iterative approach where you set up the parameter space, but then you’re gaining information about different relationships between these parameters and your target and also being able to quantify your uncertainty about where in that space might be worth exploring, and then you can select the next best experiment or set of experiments based on where you want to resolve uncertainty — where you want to explore — and then where you want to exploit what you know already, where you want to continue to optimize toward the best possible set of parameters. Am I thinking about that right?
Wolfgang Halter: That’s exactly right. Absolutely. When you look at it in terms of batches, in a classical way you do a whole design of an experiment and then you have to test your entire design — depending on how well you want to cover your parameter space, that’s a lot of experiments usually. With Bayesian optimization or BayBE, the best approach actually, if you can afford it and if your experiments don’t take too long, is to really go iteratively, step by step. Do one experiment, then look at the next one, and let the algorithm guide you through that parameter space. That really ensures the best balance between exploitation and exploration phases. It doesn’t mean that you can’t do batch experiments — oftentimes we work with 96-well plates and you have the space, so why not run 96 experiments at the same time? That helps speed up things. But the Bayesian approach allows you to get a huge information gain from batch to batch.
Ross Katz: Interesting. In this context, going iteratively one experiment at a time would be optimal in terms of resource utilization, but there’s also a speed component where you might want to parallelize a lot of these experiments. You mentioned a 96-well plate — you’ve got machines that only do 96 experiments at the same time and so you might as well leverage that capacity in order to optimize your throughput. Are there other considerations you bring to the table when advising different units within Merck Life Science about how to approach Bayesian optimization and when to parallelize versus when to be more sequential?
Wolfgang Halter: It really depends on how long it takes for one experiment to run. If one experiment takes a few minutes, then it’s not necessary to go ultra-parallel. However, if you’re looking at stability experiments where you put something in a freezer for three months and then test it afterwards, that’s your limiting factor. You have to treat those differently — you can’t do that sequentially. That’s the main deciding factor for how you set up your sequential versus parallel design. The upsides are really mostly about speed: getting to better results faster with fewer iterations. It also helps to save a lot of resources. You ideally spend less chemicals and less materials in your experiments. That’s also something that defines your approach. How much importance do you want to put on resource saving versus time saving? You have to choose your weights in a multi-objective optimization problem.
Ross Katz: Interesting. In order to clarify things before I ask more about the benefits and how it’s being used internally, could we take an example experimental campaign — the kind that might be done at Merck Life Science or somewhere similar — and walk through how a person or a team goes about structuring a campaign in BayBE and where the insights come from through that process?
Wolfgang Halter: The general points are always the same. It starts with an optimization problem — you want to make something more optimal. Sometimes that could be the formulation of a therapy or it could also be in a digital space like fitting the parameters of a digital twin model. That’s your starting point. The first step is figuring out the search space. What are your parameters? What are the variables you can vary to influence your target? Let’s take cell culture media — a very nice example. You have many, very many components in cell culture media that you can vary. So it’s many parameters at the same time and most of the time even on a continuous scale. It’s not even like choosing zero or one, but choosing any number between zero and one. The search space is quite big and a mix of continuous and discrete variables, which is usually not a very easy problem to solve. Then you have your search space, you’re looking at your objective again. We often start with: we want to create the best cell culture media. At some point you need to formalize that and think about what ‘best’ actually means, and really defining those objectives is not easy because you often have many different objectives that are competing with each other.
Ross Katz: On that objective front, is that thinking about quality and quantity, for example? Making more of something might mean you make a lower quality of something and so you need to weight the two objectives against each other and help the model understand how to balance quality versus quantity. Am I thinking about that right?
Wolfgang Halter: Yes, it could be. Cost versus quality, for example — those two objectives could be competing. If you choose raw materials that are of lesser quality but cheaper, you may achieve the same outcome at a lower price. For us, we didn’t encounter that too often to be honest. Most of the time we’re looking at things like ensuring pH in a certain range, but at the same time you want to have a certain activity of your proteins. pH and activity also influence each other. That’s the different objectives — and it could be quite a long list in the end. We have the search space, we have the objectives, and then we translate this using BayBE. It’s a super simple interface. You translate this into an optimization problem and then you get started. You get your first recommendation for your first experiment. People conduct that first experiment or first set of experiments. They play back the results into BayBE and they get the next round of recommendations.
Ross Katz: Is there an end point? How do you know when you’re done with this kind of process, or is it just that you reach some threshold where you feel like this is good enough?
Wolfgang Halter: That’s a very good question because that’s also one of the advantages of Bayesian optimization. You can actually get a measure of how much information gain you can expect with additional experiments. That’s something you can’t get from classical DOE. In classical DOE you can say, ‘Maybe I just need to make my search grid finer and conduct even more experiments or extend my search space somewhere.’ With Bayesian optimization, you usually get a good measure for how well you covered your search space already and how likely it is that you’ll find something even better. That’s actually a feature we’re working on right now — implementing dynamic stopping criteria.
Ross Katz: Interesting. I’m assuming that you developed this open source library because you were already doing these things internally and thought that having an ecosystem around this would be valuable. Could you share a little bit about why you decided to open source it?
Wolfgang Halter: It was a process. We started, as I said, with one design of experiment use case. We tackled it with a Bayesian approach. After that we encountered one or two more of those use cases and we reached out in the company and realized there’s a huge potential for these kinds of applications. But each of them needs to be tailored in one way or another. Initially it started out of getting more efficient internally — to be able to scale and deliver use cases faster. Then at some point we said, ‘This is not just for us.’ We can also partner up with academic institutions and get some input from other partners working on these problems. That was basically the idea to go open source and share this with the community to also get input back.
Ross Katz: And has that input been valuable — formative in the tool to date — or are you mostly hoping that over time it will continue to help the tool develop?
Wolfgang Halter: We open sourced it in December of 2023 so it’s really relatively fresh. But we have been working together with the Acceleration Consortium in the past already, even before open sourcing it, and we already got some really valuable input through them. We are hoping to expand that even further.
Ross Katz: Turning back to BayBE and how it’s used internally, what has the adoption been like? From data scientists on your team, from biologists or bench scientists across Merck Life Science, how’s it being used today?
Wolfgang Halter: There are different levels of answers to that. At core, BayBE is a software development kit — it’s really made for data scientists to develop things. We have this hub of developers of applications that is still there. Every application that we roll out using BayBE is adopted very fast and really well, and we have a long list of projects waiting to be implemented. Even though BayBE is speeding things up tremendously, we’ve collected quite a few projects in terms of demand. Since we open sourced, we also allowed OEMs to work with it for things they develop with us, and we get really good feedback on how easy it is to use and implement. That has been very valuable and showed us that we are on the right track.
Ross Katz: Are you able to share any examples of the applications you’re developing? You call it Bayesian back end for a reason — it’s a toolkit for developing the back end of an application, but there’s a variety of different front ends and use cases. Any examples would be really interesting.
Wolfgang Halter: One example is a product based on finding viscosity-reducing excipients. These are excipients you put into your formulation that reduce the viscosity, which you need to be able to administer drugs in the right way. We developed a tool that allows you to test just a few excipients with your protein and then it suggests ideal combinations to find the best excipient combination for your protein. This is something we offer our customers to use because we also distribute some of those excipients. If you had to test all combinations of those excipients, it would take a lot of time, effort, and resources. We try to minimize that so our customers can speed up and get to market faster.
Ross Katz: Interesting. So it’s a way of enabling your customers to scale faster, which has benefits for you as well. It sounds like time savings, both internally and externally, are a big value. Do you have any estimates of how much time you’re able to save in a given domain?
Wolfgang Halter: We certainly have some experiences, and we can find numbers in the literature. Some numbers in literature claim this approach leads to 95% time savings. What we experience is more in the area of 50%, which is still huge. The minimum is really 30%, so 30 to 50% is something that we consistently see in the projects that we conduct.
Ross Katz: Interesting. As you have different customers and business partners coming to you asking for applications of Bayesian optimization to their particular problem space, how do you think about prioritizing which use cases you go after? Is there a way to bundle multiple use cases together in a way that’s smart for your team?
Wolfgang Halter: The latter is always what we think about first — can we serve someone’s need with an application we already developed for another group? Oftentimes that’s already the case, and that’s the best case scenario. For other needs, we really look at the potential impact of the solution. We try to prioritize based on how we can create the most value for our customers and the company.
Ross Katz: Interesting. I’m imagining that having all of these different campaigns and the data they collect is really valuable intellectual property. Do you somehow store for later, leverage, combine, or analyze the data that these experiments are throwing off in a way that yields more insight?
Wolfgang Halter: In principle, any experiments conducted in the lab are gold. They give you a snapshot of a little bit of truth about the world, and you really want to conserve that well. That’s one of the biggest pain points in large corporations with many different labs — storing that data in a meaningful and intercompatible way so you can make sense of it as a whole. We are not there yet. My vision would be that you have a uniform data model for research and scientific insights where you can feed all your experimental data in and then throw BayBE on it and get the perfect recommendation for any problem you’re looking for. We’re not close to that vision. But for the applications we have developed around design of experiments, we do see these individual campaigns where BayBE is running. One of the key features we just rolled out is transfer learning — learning from past campaigns. When you do this viscosity experiment and you look at proteins that are similar, you can learn a lot about how proteins behave with those excipients and get a warm start for your DOE. Maybe that’s not the best example because proteins can behave quite unexpectedly, but in other domains — cell culture media or model fitting — these warm start features are where we get from 50% to 95% time savings.
Ross Katz: And so the conditions for that kind of transfer learning — the parameter space and the objective have to be the same or at least similar enough? How do you think about when transfer learning can be applied to a given campaign?
Wolfgang Halter: Right now the status quo is that the parameter space — at least in terms of what kind of parameters you have — needs to be consistent, maybe you expand the parameter space, but at least the physical properties are the same. You can extend it to unseen parameter spaces, but you need some overlap. Without the overlap you don’t gain anything. That’s the main limitation right now. But it’s not something that you can fix around.
Ross Katz: That makes sense. And is transfer learning in this case being used the same way we use it with regard to neural networks — literally taking an optimization algorithm that’s a neural network and transfer learning it to a different campaign — or is this transfer learning in another context?
Wolfgang Halter: You can think of it as changing your priors — your prior information about your parameter space. When you don’t know anything, you have to start with uniform priors and work a bit until you get some more information about your distribution of parameters. But if you start with non-uniform priors, you can already look in the right regions.
Ross Katz: To summarize: in Bayesian optimization you start with a prior, and a uniform prior means we know nothing — the answer could be anything within the parameter space. But if you already have a set of priors about where in that space the optimization is likely to be, you’re going to get there a lot faster. Because Bayesian optimization is so powerful, even if your prior is completely wrong — even if the transfer-learned prior is wrong — all that leads to is the need to gather more data, and eventually Bayesian optimization will get you where you need to go. Transfer learning can just get you a lot closer a lot faster, which leads to more time savings. Am I thinking about that right?
Wolfgang Halter: Exactly. You can think about it in terms of optimizing your way to work in the morning — what routes work how fast, which really depends on traffic. If you know nothing about the city you’re living in, it won’t matter because you have no experience. The routes might be the same length, but you don’t know if one way is more congested than the other. If you live there for some time, you get a feeling that on Fridays you should probably take the highway and on Wednesdays you may want to take the small roads. That kind of knowledge is exactly what those priors are — they give you a first idea of how things usually look. It may change. You may get on the road and at the first intersection see, ‘This is not going to work today, there’s a parade somewhere, I need to divert.’ That’s exactly what Bayesian optimization will do — after your first data point that is outside of what your prior suggests, it will pivot.
Ross Katz: Right. There’s exploration and exploitation happening, so even if you’re in the wrong place, the exploration will lead you eventually to the right route — to use your metaphor.
Wolfgang Halter: Exactly.
Ross Katz: This method of learning from experiments seems like the clear best path of what we have available today, which makes me wonder what has stood in the way of adoption of Bayesian optimization previously? Is it just that the open source toolkit didn’t exist before and now it does, or is there something else?
Wolfgang Halter: There are several factors. Even classical DOE is not utilized to its full potential when you look at how people in the labs do scientific experiments. The user interface and the gap between the developers of DOE methodologies and the ones using it in the end — that’s probably the biggest challenge for DOE in general. Tools like Synthace that you had earlier on this podcast can help significantly to lower that entry hurdle. That was certainly one of the biggest bottlenecks in the past. For Bayesian optimization in particular, it’s also a matter of computational power. When you look at transfer learning especially, you need computational power. Even when you have many parameter dimensions and take into account all the data points collected in the past, the standard Gaussian process approach eats up memory and computational resources. That’s something we’re facing still, even now with seemingly unlimited cloud resources. We see it is computationally hungry, and we’re working on solutions to make it more efficient — particularly for larger domains with many data points while still being able to do transfer learning. That’s certainly one reason it didn’t get much attention maybe 10 years ago. But there are so many things where you think in hindsight, ‘Why didn’t they do it from the beginning?’
Ross Katz: There’s also a cultural aversion between practitioners of frequentist statistics and Bayesian statistics — probably an element of that in there as well, and the extent to which classical methods have a hold on people’s worldview. With the time we have left, I’m interested in zooming out and getting your perspective on what you think are the biggest challenges currently facing the biotech industry at large regarding data handling, data analysis, and data science in organizations like yours.
Wolfgang Halter: We touched on this earlier — the universal data model. That’s the vision I would like to get to. Right now we’re seeing still way too much Excel. There’s a lot of manual data collection still being done in the lab, and this is really hindering some of the advances. Particularly when you look at cross-lab insight generation — that’s one of the biggest challenges in digitalization in the lab. The electronic lab notebook, for example, is something many people treat as an electronic form of paper. But it can be so much more. It’s not just a different way of writing things down. It needs to be — as I mentioned earlier — this connecting layer between your information. For that you need to treat it differently than just jotting down information. You need to bring more structure and standardization into those processes. That’s certainly one problem. There are data standards for experimental data, but we haven’t reached a good level of adoption. There are also a few competing ones. All the vendors creating lab equipment are each basically following a different standard or different interfaces and APIs. That’s just complicating this vision of a connected data layer for the R&D world.
Ross Katz: I’ve heard a lot about the idea that automation can resolve this problem of a consistent data model because at least the machine you have is collecting the data points you need — but that’s predicated on all of these different machines coming together on a data model that’s at least relatable or combinable.
Wolfgang Halter: Exactly. Automation can be one of the solutions, but it is a chicken-and-egg problem because for automation you also need a certain level of standardization and the right interfaces that can talk to each other.
Ross Katz: Interesting. You come from an engineering background and have come into the field of biotech R&D. How does that color your perspective on the problems biotech R&D faces here?
Wolfgang Halter: That was very surprising to me at the beginning, honestly. Even during my PhD I pivoted a little bit away from regular engineering into the biological sciences. For me it was very different because in natural sciences, researchers really think end-to-end. They think of their research problem from the very beginning — from the atoms to the therapeutic sometimes. It’s a very well-integrated thinking that natural scientists have. That’s really good because you go deep on your topic. What it prohibits is creating interfaces. Coming from engineering — the key dogmas of engineering and I think why the industrial revolution worked out so well — is these concepts of modularity and orthogonal design. Designing things in complete isolation of the neighboring modules. Being able to do that allows you to narrow down on just your module, look only at that, become excellent in exactly that module, and then feed everything out to your neighboring module. This modular thinking is something I believe is missing in the natural sciences because of this end-to-end thinking. That’s something I wish we can move toward more in the future — and it comes back to the data standard. It’s exactly the same thing: you need standardized interfaces, and then you can stay within your domain, do whatever you want, as long as the interfaces don’t change.
Ross Katz: There’s so much there and I feel like I could have an entire other podcast about this topic alone. It almost comes back to Adam Smith and the level of specialization and how that enables the creation of value at different parts of the value chain. As we wrap up, do you have any advice for young scientists and engineers who are looking to learn more about biotech and contribute to its growth?
Wolfgang Halter: We still have too many siloed disciplines. Even if you are studying biology or chemistry or data science, I would encourage people to go out and look at how other disciplines are approaching things. It’s still astonishing to me how similar certain fields of research are — with just a different language. Get inspiration from other industries, other areas. Look at how they solve problems, what their biggest problems are, and try to understand their language. That’s really important. As a natural scientist, I would particularly look at how engineering approaches problems, how software engineering approaches certain things. What I mentioned about modularity is nothing new for a software developer — companies like Amazon are preaching the API-first approach. That’s nothing else but the modularization of your designs. We can learn a lot from that in the natural sciences. And coming back to the ELN: don’t think about digitalization as a process of replacing paper. It’s much more powerful than that.
Ross Katz: Fantastic. Where can people learn more about you and your work and Merck Life Science?
Wolfgang Halter: I encourage you to check out our homepage, merckgroup.com. We are also present on several social platforms like LinkedIn, or particularly look at our GitHub account, which is EMD Group. There you can find BayBE. You can check it out, clone it, adjust it. You can find a few other libraries there as well. Feel free to give that a look.
Ross Katz: Great. It’s BayBE, B-A-Y-B-E, Bayesian Back End — we’ll put the link in the show notes and in the blog we write about it as well. Wolfgang, thank you so much for joining us today. It was a really insightful conversation and I look forward to connecting down the line.
Wolfgang Halter: Thanks, Ross.
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.
