Modernizing Commercial Data at Scale: AstraZeneca's Databricks Lakehouse Transformation

Summary

AstraZeneca migrated its commercial data estate from three legacy frameworks and 400+ pipelines to a unified Databricks lakehouse with Unity Catalog, Iceberg, and a custom Copper layer in their medallion architecture, achieving 50–70% cost savings and 47% productivity gains.
A multi-agent AI system automating code conversion, testing, and QA accelerated the migration by analyzing and converting legacy pipeline code that manual effort alone could not have handled at the required speed.
Four key lessons from the migration are: design the architecture before migrating, invest in metadata and tagging, apply AI end-to-end with a strong partnership, and prioritize team adoption and democratization to sustain value.

Modernizing Commercial Data at Scale: AstraZeneca's Databricks Lakehouse Transformation

Enterprise organizations running legacy data systems face a critical choice: modernize while maintaining business continuity or risk falling behind on speed and innovation. AstraZeneca transformed its commercial data estate from multiple legacy frameworks and 400+ pipelines into a unified Databricks lakehouse, powered by Unity Catalog, Iceberg, and AI-driven migration automation.
Learn how AstraZeneca designed and executed a data migration at scale without disrupting 24/7 commercial operations, achieved 50-70% cost savings and 47% productivity gains, and built multi-agent AI systems to automate code conversion, testing, and validation. Discover architectural decisions including the Copper layer, Liquid Clustering, zero-copy federation, and developer-first design, plus lessons on partnership, boring metadata work, team adoption, and why AI is now foundational to data modernization.
🤝

Chapters

FAQs

What is the Copper layer in AstraZeneca's medallion architecture?

The Copper layer is an additional tier AstraZeneca introduced in their medallion architecture on Databricks to address specific data staging and interoperability requirements during their migration. The architecture also incorporates zero-copy federation and Liquid Clustering alongside the standard bronze, silver, and gold layers.

How did AstraZeneca use multi-agent AI to accelerate their data migration?

AstraZeneca built a multi-agent system with specialized roles—a code converter agent, a testing agent, and a QA agent—to analyze and convert legacy pipeline code that presented a bottleneck when attempted manually. This AI-driven approach increased throughput and enabled developer adoption by reducing the time and effort required to convert each pipeline.

What were the business outcomes of AstraZeneca's Databricks migration?

The migration delivered 50–70% cost savings and 47% productivity gains, along with a simplified, unified data platform governed by Unity Catalog. The transformation positions AstraZeneca to support the company's 2030 ambition of reaching $80 billion in revenue and delivering 20 new medicines.

How did AstraZeneca maintain business continuity during migration?

AstraZeneca operated 24/7 commercial operations supporting approximately 40% of the company's revenue during the migration, requiring a strategy that kept legacy systems running in parallel. The coexistence approach allowed teams to migrate incrementally without disrupting the US commercial data operations that the business depended on daily.

Full transcript

[00:08] Good afternoon. Thank you for joining us today. Um You know, as I was sitting in the session this morning, the keynote session, all the announcements were incredible. And then I asked you I challenge you this question, what one thing are you going to take from that keynote session and walk away with and decide I'm going to action this?
[00:24] So, my name is Paul Koontz. I'm the commercial capability lead for AstraZeneca and I'm joined by my colleague Alessandro Moro from Databricks. And as I was sitting in the session this morning, I was thinking
[00:40] 3 years ago, in 2023, I was sitting in the audience and I was listening to Lakehouse be described. So, if you remember that summit, if you were there, if you don't, they were announcing Lakehouse construct, they were talking about medallion architecture, and advancements in Unity Catalog. And at that time, I was sitting there thinking, this is exactly what AstraZeneca needs
[00:57] to do. We need to transform from our legacy technology stack and take advantage of all the opportunities that Databricks is offering. So, I'm going to give you a little background about AstraZeneca here. There's a little forward-looking statement, right? That's required, I'm
[01:12] sure. So, AstraZeneca is a science and innovation-led company. We focus on primarily three therapeutic areas, oncology, biopharmaceuticals, and rare disease. And we really are focused on diversified portfolio across primary
[01:28] care, specialty care, and rare disease to try to improve patient outcomes. We have a global strength and presence, we're all across the world, and we are committed to people, society, and the planet. Again, science and innovation leads
[01:43] everything we do, whether it's developing new pipelines, accelerating how we bring new medicines to market, transforming R&D, uh trying to achieve industry-leading growth in our therapeutic areas, but all while delivering a great employee
[01:58] experience, a a great patient experience, leading on climate, equity, and resilience, and enabling an agile organization. So, last year, our CEO gave us this bold ambition. And he said
[02:14] by 2030, we're going to deliver 20 new medicines. We're going to lead in sustainable healthcare. We're going to be an $80 billion company. So, this is the perfect opportunity for us to improve the way we manage data for the US healthcare system. The US
[02:29] healthcare system is uh a data commodity-driven environment. We buy a lot of data. And uh the US business supports about 40% of the revenue for AstraZeneca. But, in order for us to achieve these goals, we had to pivot. We had to
[02:45] strategically rethink everything we were doing in our ecosystem. Get out of our legacy technology stack. And ensure that we could hit that $80 billion revenue ambition, which we're essentially in the US 40% responsible for, right? So, but keep in mind, commercial is a 24/7 organization. It doesn't stop. You
[03:03] can't just, you know, say to your business customers, "Hey, you can't launch new products. You can't work on product development. You have to pause. We have to move the data." IT for IT doesn't really fly in the uh in the business mind. So, we ruled out doing a 24-month lift
[03:21] and shift and then optimize. We're moving the entire ship while we're launching new medicines, while we're going 24/7, and we don't have time to worry about optimization later. We had to do it now. So, we are optimizing along the way.
[03:39] And we can't keep two platforms running indefinitely, either. So, while we have to migrate, you have to keep data in sync. We can't just run it forever, right? That kind of cost would uh destroy our program.
[03:56] So, we had a vision, right? A unified governed, secure lakehouse with integrated data services. So, we're going to build this yes for commercial, but the key here is we're going to share this data across the organization. So, I I talked before about the US healthcare system being a commodity data market,
[04:12] right? We have data sets as small as a couple million records and data sets like the anonymized patient claims data that is hundreds of billions of records in a single table, right? That data want to move it. You want to share it across the organization. And we want to share it with people like R&D, real-world
[04:28] evidence, medical affairs, so that they can use and leverage the same capabilities we have. By building it inside a Unity Catalog in Databricks in a lakehouse construct, we can do that. So, we I talked about transforming the the way the data is made available,
[04:45] security and authorization, but also we wanted to improve quality and understandability, right? Unity Catalog has the unique ability over any other technical metadata catalog to capture this kind of information. To understand user experience, lineage,
[05:00] business and technical metadata, all the tagging, all this is very important capabilities for our ecosystem. But, we had accumulated 6 years of complexity. So, again, being this very broad market
[05:15] uh in the US healthcare market data, you know, we started off with the initial version we lovingly called O2. And this was an RDS-based AWS technology stack. What that means is all of our configurations, our ETL was stored in RDS. So, it was inflexible. If you had
[05:32] to make any changes, you had to go into the table and add a column. We all know what that's like, right? Adding a column to a production system is is difficult. Plus, we were using EMR. We were running into some challenges. So, our second iteration of framework SFO did include
[05:48] things like Databricks runtimes. And then we really started to see the benefit of adding in Databricks runtimes, the power, the performance, the efficiency. We created our third version of a framework sharp, which had YAML files, right? Which is pretty much the de facto standard these days. Our DDL, our ETL,
[06:04] our cluster configs, all stored in the YAML files. But now think about what I just described, right? Here's three different frameworks managing data coming in from 100 plus data sources petabytes of data. We have It ended up
[06:19] in this complexity of having essentially four plus different patterns to bring data into the ecosystem. We were stuck in legacy Databricks runtimes and EMR. And you know, we had accumulated 400 pipelines loading tens of thousands of
[06:35] tables into our ecosystem. And to top that off, I have users in Glue, right? They're stuck in AWS using the data and I need to be thoughtful and considerate to them as we migrate. How do I support them? Right? While we're in the process of
[06:50] moving to the lakehouse. And last but not certainly not least, observability is key, right? When we had a problem in in our I actually our almost to be decommissioned current ecosystem in AWS, we never knew where
[07:05] the problem was coming from without a lot of investigation. Could be Airflow, it could be some ETL code, it could be a cluster config, it could be the actual data. You don't know. So enter the lakehouse. One platform, open formats, unified
[07:23] governance. We went all in on Databricks. So we leveraged Databrick Databricks asset bundles. We run our pipelines with Databricks workflows. We leverage Unity Catalog and all its capabilities, liquid clustering
[07:39] uniform. Now that came up this morning and it's funny cuz I feel like they kind of stole my tagline here, but like, you know, we all sit there with like Delta versus Iceberg. This is a big decision for the organization, but with Uniform, it's not. Right? At at the end of the day, you pick whatever one works best
[07:55] for you. If you have a reason to go Delta, fine. If you have a reason to go Iceberg, fine. But Uniform allows you to not worry about that. Your data can be federated out across AWS Glue Catalog, Ice or um Snowflake Horizon Catalog, or any other
[08:10] platform. So, you're going to see another thing here that's a little bit different. So, the Medallion architecture. So, I do want to call this out because we'll circle back why this is important later, but you see copper up there, and you might be wondering what what is this copper thing? Everybody knows bronze, silver,
[08:27] and gold. But copper was a thoughtful decision we made right up front, and I'll tell you why. So, there's really kind of four ways we get data in. We leverage Databricks Autoloader. That's usually typically for file ingestion. But some data just lands. When I say just lands, what I mean is let's say
[08:44] you're federating to an RDS database. The data's just there. So, your bronze source is already there. You could be using a tool like we use Fivetran to get data out of a cloud service. It just lands. You don't really have the opportunity to intercept it before it's instantiated. And then the
[09:01] last one, which is actually my favorite, if you can get a vendor or provider to Delta share the data for you, that's the best possible solution. But but again, now you're talking about data sitting in bronze that you have no control over how it landed. And if you think about a
[09:17] Delta share, all you need is the vendor to say phrases like, "We're only going to keep the data out there for 7 days." Or you actually sever the relationship with the vendor, and that bronze layer is just gone. Right? So, we created copper. Copper is now our historical.
[09:33] And we do quality checking between bronze and copper, too. Before we even decide to go and bring it into common data models in the silver layer, we want to make sure it's okay to keep progressing up the stack cuz typically the ingestion in the bronze is not the expensive part. The expensive
[09:49] part is silver and gold, right? So, we want to make sure it's okay before we progress it up the stack. And then the standardization, I mean, I'm just going to call it out. Everybody hates date formats, right? I mean, every vendor you're going to have data from gives you a different date format. So,
[10:05] it becomes very problematic managing that and all the ETL code. So, in copper, we standardize things like a date. But, we still keep the original historical context of the data provider.
[10:20] And so, additionally here, like I'm just going to call these two pieces out, right? Zero copy interoperability is key. You don't want to move the data. It's costly to move data. So, federating and and and honestly federation has come a long way in the last, let's say, 6 to 12 months, right?
[10:37] With the advent, I mean, Databricks continually improves federation. So, we kind of expect that all the time. They're just making it better and better all the time. But, like it with the advent of date of AWS allowing you to federate to an iceberg catalog or in this case Unity
[10:52] catalog, that's made a hugely uh a huge impact in our ability to migrate data. Now, imagine I'm trying to run two different processes and compare data and I have them both federated right there. One's native inside of the lakehouse and one's federated in, it might as well be native, right?
[11:08] And then the last piece uh uniform, again, don't sweat that decision, right? Uniform allows you to be interoperable with the rest of the ecosystem you have at your company. So, that this wasn't an easy move though. Again, I talked about how big the US uh
[11:26] business is to AstraZeneca. So, there were a lot of technical challenges and decisions we had to make along the way and some strategic pivots. So, I'm going to pass it over to Alessandro to walk you through some of those. Thank you, Paul. So, Paul walked through a little bit the
[11:41] journey of where AstraZeneca were coming from, and where I like to start in talking through the approaches we took along the way. I want to start from what I call the boring decisions. Not because they're boring per se, but because whether you have migrated already to Lake House or
[11:57] uh you're thinking about migrating to Lake House, this will come up in the first week. The first one will be around how should we design our medallion architecture? Secondly, how should we organize uh Unity Catalog? How many schemas? How many catalogs? And lastly, and this is very fundamental
[12:14] in my in my view is um what sort of developer experience do we want to provide on the platform? Sometimes this is an afterthought, but it it really made a difference not only in um uh the the outcome of the migration itself, but also in how foundational
[12:31] this was to leveraging AI through the course of the migration. I'll just step through a few of these decisions. Um Paul mentioned the copper layer, and every time we take a deviation from a standard, it's right I provide the right rational. In this case, we had two things to
[12:47] consider. The first one is really had to appreciate the uh breadth of the data sources the commercial business in AstraZeneca has from external vendor data, file-based data, internal delta sharing databases.
[13:04] And secondly, that this migration was not a lift and shift. In many ways, this was a fully architecture from the ground up, and in many ways we had to make uh decisions around the data model. So, copper gave us that conformance layer before we started changing things
[13:19] like implementing SCD types. So, moving from the traditional parquet full override, full refresh, enabled the team to move to incremental ETL, which was a huge uh well, huge source of saving from uh from commercial licenses.
[13:35] The second one that I want to mention is liquid clustering. So, Paul and I spoke at length about liquid clustering, how cool of a feature it is, but uh the question that came up, "Oh, should we declare the keys? Should we implement auto liquid everywhere?" And where we ended up was with a small prescriptive
[13:52] pattern where we said, "From bronze to up to silver, we should probably expect all of the or most of these jobs to be very predictable. And therefore, declaring the keys was a good idea. Instead, we decided to implement auto
[14:07] liquid on the gold layer, which is where we probably have a mix of predictable uh consumption patterns and serving, and then some that are less predictable. Um and lastly, in this area, I want to mention about simplified ingestion.
[14:22] The first point is Paul mentioned we were coming from a uh broad state with uh a lot of different tools uh that accumulated through the years. So, rather than saying, "Oh, let's just rationalize the tools," is shall we converge on common patterns? In this case, uh Fivetran is a a pattern in
[14:39] Azure Synapse Analytics, and we decided to converge on it for database ingestions. Autoloader is the main pattern for all files ingestions, and then Delta Sharing. Secondly, on the governance side, I mean, Unity We decided to make from the beginning Unity Catalog the brain of the
[14:56] platform. And um be very prescriptive about how we handle access, governance, the organization of the catalogs, and the schema. So, we went through proper detailed design around it. Um one of the things Paul mentioned is that um
[15:12] the commercial estate was and is um a multi-catalog estate. So, one of the decision we made is what's the least disruptive approach uh to keep the platform whole and to avoid end users from experiencing
[15:28] migration fatigue just at the beginning. So, we work together to build a bespoke sync between UniCatalog and N Glue. And once federation catalog federation came up, then we switched over to federation. And yeah, this was a huge enabler for
[15:45] the whole program. And lastly, the decision that took us maybe a little bit longer to make, but was really foundational, we took a step back and think, "Wait a minute, we're migrating from three different frameworks, many of some of them heavy config driven, where
[16:02] developers spend a lot of time changing parameters or tuning parameters and then let all of the framework handle all of the different changes." And we said, "Is that also what we want as a developer experience in Lakehouse?" We said, "Maybe this is an opportunity
[16:18] to offer a more modern experience on the platform." And we converged on the idea of using or building reusable patterns and templates that developers could draw from and build a whole range of Python utilities that developers could pick and
[16:35] choose depending on the task that they have to achieve. So, these were all very foundational to a lot of the AI decision that we made along the way. And I'll explain that in a second. So, migration begins. And while we made
[16:50] a lot of decisions right and we went through all of the data design, the reality of a migration is that at some point, we hit a throughput bottleneck. There's only so much capacity in the team and there were lots of repos that we had to migrate
[17:07] from the legacy frameworks. So, the main bottleneck we identified at the beginning was it's taking developers so much time to do the analysis of the code and then all of the translation to the new set of utilities and new framework.
[17:24] And together AstraZeneca challenged us, right? And said, "Can we, you know, we we are talking about AI a lot. Is this a good opportunity to experiment with it and see if we can do something different?" And so and so we did. It went It wasn't like magic bullet and everything worked
[17:40] magically at the beginning, but rather it was a journey of experimentations and we went through a lot of iterations to get to what I think is um probably a very good pattern for most AI-driven migrations and I'll I'll go through that in a second.
[17:57] Okay. So I'll go through these steps just showing that this was incrementally built. It's not like at the beginning we said, "This is This is it. We're going to We're going to do this." And we started addressing bottleneck by bottleneck until we
[18:12] uh we eliminated them. The first one was we mentioned, "Okay, analysis of the code, code conversion." Yeah, LLMs are pretty pretty good at doing that. And so we started experimenting with it. And the first area of focus was on building the converter agent.
[18:28] Um so what we did in this case is to leverage an in-house tool built by our professional services team and this is to run the analysis of the code, do the code conversion, and then manual self-validation, and automatically
[18:46] generate the bundle file. Now, what what was really useful in building this this agent, and this was through iterations, is first all of the work that I highlighted before around manual migration, so to speak, was really useful because it provided the
[19:02] label data for how we want the agent to understand a high-quality conversion. Uh secondly, we fed in all of the Python utilities as part of the target and in some ways it acted as a
[19:17] um let's say primitive form of agent skills which today you know everyone's probably familiar with. At that point we wanted to agent to go and fetch the right Python utility depending on the type of task or job that case that we had to migrate over.
[19:33] And and at that point we were able to unblock the initial bottleneck which was code analysis code conversion. So you can imagine that the next bottleneck down the down the road is that developers have all of these files we convert the code more than they can
[19:50] handle or churn through. So I'll talk through that in a second but the next iteration so the first part is the agent the second step was the developer input and this is something that was really critical. We noticed that agents were small as potentially
[20:06] expected inconsistent in how they applied certain logic especially the ACD types. So we decided that any of such changes we would be prescriptive about it and leave empty spaces in the code so that the developer would you know manually go
[20:22] in and add it to all of these um all of these scripts that we created handle business logic edge cases and then we would take the feedback from the from the engineers and use it to refine the instructions over and over again.
[20:38] Now it comes to the testing and QA agent we work with the AstraZeneca team again to come up to build essentially an agent that would handle unit test bug validation and diff reports to remove that extra layer of bottleneck. And once that was complete then
[20:54] we had essentially an end-to-end process to handle the migration of all of these different scripts and then let the developer again focus on deployment production and managing the cutover.
[21:10] The um I guess the change was quite remarkable. Um so we what started as an experimentation at the beginning and I'd say you know, a bold move from from from us as Anika and us and saying we need to take risk and we need to try things differently. It
[21:27] eventually paid off. And we saw a massive update in throughput across the migration. And so that was in my mind like a big accelerator. The second one was sometimes you don't need to change much. All of these models have as you've probably seen over the past 2-3 years
[21:45] are just getting better. So even changing like previous versions of Sonnet to newer versions of Opus already produce like higher quality results and more accuracy, uh speed. And lastly, probably the most important
[22:00] takeaway from this is uh um developers within the team became familiar with working with agents as part of their workflow and many of them through the migration and then post migration are thinking about okay, what
[22:17] agents do I need? How can I build them? Thinking about the skills that are needed. So it was also a mindset shift and uh in many ways I call this building enduring capabilities beyond just completing a migration. So with that said, I'm going to hand
[22:33] over to Paul to talk for the outcomes Excellent. Thanks, Alessandro. Yeah, and for the record I love Genie code. Um I'm going to say it now. I usually when I'm practicing I've been saying it later, but Genie code is the best. I'm not a developer. I know just enough to be dangerous, but the things you can do
[22:49] with Genie code, just understanding what is your business outcome, what is the data that you have accessible to you and let it fly. As long as you can validate that whatever it created is valid Genie code is incredible. So all right, two things. What did we deliver? What
[23:06] does it mean to the business? Cuz this is where it's important, right? So, the modernization, total cost of ownership reduction of 50 to 70%. And it depends on which process. Some are more, some are less, but at a minimum we're getting 50% savings on on all of these
[23:22] uh jobs running inside the lakehouse. But beyond that, the second bullet point's also super important. Sometimes people just want to hear about the cost savings and they don't This is an intangible benefit, but changing a data job from weekly to daily Sorry, I'm getting a little bit of echo. Um
[23:39] from weekly to daily or from daily to hourly is impactful for the business. This is important to them. So, if they can make more timely decisions, they can affect the business in a faster fashion. And we were able to experience this with all these capabilities, with
[23:54] the way we built the lakehouse and our technology. Along the way we observed the 47% productivity gain in folks that use the platform. So, whether you're a data analyst, you're an engineer building a pipeline, or a BI specialist, it's easier to use, it's more accessible.
[24:10] And then last but not least, this is a commercial organization, right? More than half of the employees in the US are field sales representatives. So, uh we experienced 45,000 hours saved in the field and increased sales conversion rates of 35%.
[24:27] So, the real important part though, why you're here, is to understand these lessons. Like, what did we learn along the way? So, that you could potentially take away. So, whether you're starting a migration or whether you're starting a lakehouse from scratch, hopefully you'll be able to take away some of these lessons.
[24:43] So, the first one, design before you migrate. So, 6 weeks of architecture saves 6 months of rework. This is key. So, you you sit there and we we he jokes about liquid clustering, but it was a a very passionate discussion around what is the best way to optimize our data, right?
[25:00] And but that's important. Have those conversations. Understand your use cases. Think through the challenges. We used to call it a pre-mortem, like how is your system going to die before you've created it? And think through those things. Delaying those high-quality decisions just leads to technical debt. And you
[25:17] know, actually it was said this morning, too. So, another tagline that was stolen from me. We're in IT, right? We cost a lot of money and we're too slow. So, you don't want to have to come back and rework something later down the line. Business customers never understand and appreciate that.
[25:33] And then, as he said, doing the boring stuff, like this last one is really important. So, Unity Catalog has the ability to tag everything, I mean literally everything. Tag it. Tag the tables. Tag the columns. Enter the business and the technical metadata. If you're going to take Genie and put it
[25:49] against your data, it needs to have that context. So, internally to AstraZeneca, we sometimes call ourselves AZ. And if you're from the UK, AZ. And but the state of Arizona is also AZ. So, you don't want your Genie space
[26:04] trying to triangulate data in the state of Arizona when you were really just being using it in the term AstraZeneca. Like, I'm an AstraZeneca analyst. So, make sure you do these boring things. They're tedious, but it will help you when you start to use Genie
[26:20] code Genie space spaces on your data. Pull the product features forward. Like I said, advancements in federation came along the way and we implemented them as soon as possible. Uh AI in the end-end process, like Alessandro said, like we would never
[26:36] have been able to complete this program if we hadn't implemented AI. And it's super critical. And it's, you know, inertia is a powerful motivator both in physics and in humanity. And it will be a bit of a challenge to convince people to not sit there and
[26:51] pour through thousands of lines of code and let the tool do it and you're just checking to see if it did it right. Um but it is imperative to build these things all the way through the pipeline. I mean, why stop at just code conversion, right? Have it test your data.
[27:07] With federation, you can just ask it to compare table A and table B. One's in your old platform, one's in your new. You'd be amazed at the stuff that it can kick out. Delta versus Iceberg, again, not a huge decision in my mind. With uniform, you can just enable it to any other
[27:23] platform. And then, you know, this one's important. So, this we were in the trenches in this thing, right? And the Databricks team we have a deep partnership with them. They're fighting the good fight along with us to try to get this project done. Take advantage of your Databricks
[27:39] colleagues. They're there to help you. And pull forward private preview features. I I get it cuz it's not GA and you're like, why would I put that risk on my organization? But to be transparent, they're not going to bring it forward to you unless it's
[27:54] very highly functional if not perfect already. But they might not like that I said that. But the reality is, right, these private preview features enable you to get a lot more done, to be more successful. And then share it back with them. Talk
[28:10] to the product team. Tell them your use cases. This is what we're trying to do at AstraZeneca, for example, and why it's important to us because then they will build it into the features. So, when it's actually GA, it meets the needs that you've been asking for. And it's not just us, it's everybody in this
[28:27] community. So, work with your Databricks partners. Share with the private previews with the product team. And then the last piece, the developers is is called out here, but it's not just developers. I'm going to expand it. You know, so again, inertia is a
[28:42] powerful motivator. So, you need to get your developers on board and say, "Look, I'm not trying to replace you. I'm trying to make you more effective, right? There is that fear out there, but it's not just the developers. So get your insights and analytics teams, the people who are making the decisions in
[28:58] your brands, get them hands-on the new private preview preview features. Get them in Genie spaces. Give it to your standard reporting analysts who aren't necessarily sequel writers and they they can't create elaborate, you know, notebooks to
[29:14] process data, but they can now with Genie code. So have them hands-on adopt. That's how you're going to be successful in the organization. So in closing, capitalize on Databricks and AI to meet the demands of your ever-evolving business. It's really not
[29:30] optional at this point. It's a requirement. Thanks.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.