SAP BDC Connect and Databricks: Building a Federated Data Mesh

Summary

PostNL, the largest parcel operator in the Benelux delivering 1.2 million parcels daily, transitioned from a centralized data warehouse to a federated data mesh using SAP Business Data Cloud and the Databricks Data and AI platform with clear business domain ownership.
SAP BDC Connect, released in October 2025 as part of the SAP-Databricks partnership, enables Delta Sharing between the two platforms, and PostNL is among the first adopters in Europe.
The video shares both the benefits realized and the practical challenges encountered — including replication complexity, versioning, and cost trade-offs — from PostNL's production implementation of a multi-platform data architecture.

SAP BDC Connect and Databricks: Building a Federated Data Mesh

Integrating multiple data platforms while maintaining consistent governance and scale is a major challenge for enterprises. PostNL shares how adopting a federated data mesh architecture with SAP Business Data Cloud and Databricks enables their teams to own data end-to-end, accelerate insights, and maintain compliance across their entire logistics and commerce operations.
Learn how PostNL transitioned from a centralized data warehouse architecture to a federated data mesh with clear business domain ownership. Roel covers how SAP Business Data Cloud and Databricks serve different domains, how BDC Connect enables Delta Sharing between platforms, how data products and Unity Catalog establish governance boundaries, and the practical realities of managing a multi-platform data stack in production.
🤝

Chapters

FAQs

What is SAP BDC Connect and how does it integrate with Databricks?

SAP BDC Connect is a capability released in October 2025 as part of the SAP and Databricks partnership that enables seamless Delta Sharing between SAP Business Data Cloud and Databricks workspaces. It allows organizations like PostNL to share data between the two platforms without copying it, maintaining a single source of truth across their data mesh.

Why did PostNL choose both SAP BDC and Databricks instead of a single platform?

PostNL found that different business domains had different requirements, with SAP BDC better suited for SAP-native processes and Databricks better suited for advanced analytics and AI workloads. Their federated data mesh gives each domain the platform best matched to its needs while Unity Catalog enforces unified governance across both.

What is a federated data mesh and how did PostNL implement it?

A federated data mesh is an architecture where individual business domains own and manage their data end-to-end rather than delegating everything to a central team. PostNL implemented this by mapping business processes to data products with explicit domain ownership, then using Unity Catalog to govern access boundaries across both their SAP BDC and Databricks environments.

What challenges did PostNL encounter with their multi-platform data architecture?

PostNL encountered practical challenges including data replication overhead when data moves between platforms, versioning complexity, and the cost trade-offs of maintaining two separate platforms. This video covers how they addressed these obstacles in production, offering an honest account of both what worked and what required adaptation.

Full transcript

[00:08] Good afternoon everyone. Thanks for joining me on this breakout session. I know it has been a long and intense day, but I hope to still some energy for for the coming 40 minutes. Um Today I'm going to talk about our journey as PostNL in adopting both SAP BDC and Databricks as technology
[00:23] platforms um to support us in our data transformative journey that we're in. Uh in October last year, 2025, SAP and Databricks as part of their partnership released BDC Connect, which is a result of that partnership and that promises seamless sharing
[00:39] between SAP BDC and Databricks. Um PostNL is one of the first adopters, at least in Europe, of this partnership and this technology. And today I'm going to share you the um uh the some of the insights of the experience that we've had so far, the things that we liked, the things that we
[00:55] didn't like so much, um but also the obstacles that we that we saw and how we overcame those obstacles. Before going a bit more into detail about that, I'll talk to you a bit about PostNL as an organization, what we are, uh what we do, um the data journey that we're in and
[01:10] why we chose these two technologies in the first place. Because of course you could argue, why don't you just go for Databricks or for BDC um as a single technology platform for your for your data. So that's what we're going to talk about today. Uh briefly about me, I'm Roel Schouten,
[01:27] data architect in the IT architecture team of PostNL. It's a central team and as a team we support business and IT teams to realize the strategic goals that we have regarding data. I've been at PostNL for a bit over 11 years now uh and involved in this
[01:42] journey uh for the last 4 years. So from or designing the new operating model focusing on federated data governance, data mesh if you will, uh but also the platform architecture and the implementation bit. Now, about PostNL then, uh PostNL is an old
[01:59] company, over 225 years old, and we are the postal operator of the Netherlands. Uh we are a publicly traded company, uh so not a government-owned company uh for quite some time already. Um but besides postal business, we also are the largest parcel operator in the
[02:16] Benelux. So, that's the Netherlands, Belgium, and Luxembourg combined. Um and we have an asset-light e-commerce network across the across the globe. So, it's not just letters, but it's much more than than that. To give you an idea of the scale, we deliver about 1.2 million parcels a day in the Benelux,
[02:32] about 6 million letters a day in the Netherlands. Um so, whoever thought that the mail business was dead, it's certainly not yet. Of course, it's declining, but it's still a lot of mail on a daily basis. Considering we have about 8 million households in the Netherlands, so that's almost a letter per household per day.
[02:49] We have a a bit over 30,000 employees, um and 10 million unique consumer accounts. Now, that is important to us because as PostNL, we would like to be the favorite deliverer for our consumers, so people like you and me receiving packages. Uh and these accounts give us a
[03:06] a way of interacting with our consumers, listening to their preferences, and adjusting our logistics accordingly. Um so, we're heavily focused on how can we meet our consumers' uh preferences. We have quite a large physical network, retail locations, automated parcel
[03:21] lockers, uh and some things that I'm personally quite proud of where we're ranked number one on the Dow Jones Sustainability Index in the transportation sector. Um yeah, uh our ambition is to be net zero by 2040, and I think we're well on the way. Uh to give you an idea, and I know this
[03:37] is in the metric system, but 108 g per uh kilometer, which is less than my car does, so that's quite impressive given all the trucks and the uh the vans that we have to use in order to deliver. And about 33% of our fleet is electric for the last mile delivery, so the the vans that we use for delivery
[03:53] are mostly uh electric. We're also pushing hard on electric trucks. This is in a nutshell what PostNL is and what it does. If you look at our strategic goals, like I said, we really want to focus on the consumers having like choosing for us as their favorite deliverer. But of course it's also about
[04:10] revenue growth. We need to grow as a company, get more margin out of the logistics that we're executing. We are it's a logistics, so it's also called sometimes considered a utility. So, operational excellence is important. Also, we want to be sustainable.
[04:25] Traditionally, you would have to choose what I'm going to focus on. And we really believe that data and AI is pivotal in maximizing on all these dimensions. So, we no longer have to choose, but we can win on every area. Now, that's something that you do not
[04:40] like you don't change that in a day, right? And I think the journey that we're in is quite like recognizable for most larger organizations. Because we also come from a more centralized way of working with data. Central team, central data warehouses.
[04:55] Turning raw data into insights. And we are moving away from that. Like I said, to a federated federated governance model. Data mesh, if you will. So, I'm going to talk a bit about that journey and then go to why we chose
[05:11] these technology platforms and how we're using them. So, if you look at our current data platform, on a weekly basis we have about 2,500 unique users. Primarily, these are report users, but of course also data analysts, data engineers, and data scientists
[05:26] interacting with the platform. But about 80% of of this number is is report users. We ingest about 180 sources into our platform. Which is quite quite extensive. And that translates to roughly 150 terabytes of data in our standardized layer. Well,
[05:42] this is our source Uh, where we have our source representation basically, and it's in Delta, so it's quite highly optimized. But, the total data platform is bigger, of course, but just this gives you an indication of the amount of data that we're talking about from a source perspective.
[05:58] Now, if you look back 15 years in time, life was relatively simple, right? We had a central team, a central data warehouse, in our case it was an SAP BW system, uh, which gave us pretty consistent results. Uh, but as you probably know, SAP BW is not known for
[06:14] its flexibility and, uh, and scalability. And as the e-commerce business rose, uh, uh, and and grew, uh, yeah, we needed more of that flexibility for our e-commerce, uh, shipments and analytics, but also for marketing, for example. So, what we saw is that local stacks emerged to
[06:31] cater for these demands. Uh, which worked great, but in terms of a consistent landscape and consistent KPIs, um, yeah, it also had some had some consequence on that aspect. That became even a bigger problem in
[06:46] what what what we call the big data era. So, as bol.com, we decided in 2015 that we wanted to migrate fully to the cloud. So, all our applications running on, in our case, AWS. Um, and a strong focus on self-engineering, especially for our logistical software, because we believe that's where we can be distinctive. We
[07:03] wanted to build that ourselves. But, as a consequence, we also saw a lot in a big influx influx of new data. Um, and in order to cater for that, and also for, like, new use cases, for example, data science, um, yeah, we initiated a data lake. We saw even more
[07:18] of these local domain pockets of analytics emerge, um, which worked great in the beginning, but over time, of course, this started to be more and more complicated. From a overhead perspective, but also from a cost perspective, yeah, this became more and more unmanageable.
[07:33] Um, so, we felt like that we need to change this. This we we have to, uh, we're like, uh, uh, losing some consistency, also increasing costs, and in terms of flexibility and we also reached the the boundaries of what we what was possible.
[07:50] So, therefore, in 2023, we decided, "Okay, we're going to change the way that we work with data and our operating model." Um it's based on the philosophy of mesh, uh but we felt we also had to be a bit bit pragmatic about this because if you look at a company like PostNL, it's it's
[08:05] quite extensive. Maturity levels are different between the various business lines. Uh yeah, we have to cater for this. We have to be able to make it work for everyone and not just for a couple of teams that are mature enough. Uh one of the things that we decided upon is that we're going to have a central central platform
[08:22] uh that enables these domain teams uh in order to do that work. Um So, instead of having like giving local domain teams the responsibility to maintain their own stack, a central platform team that provides these capabilities.
[08:38] Um and we made the agreement all the existing platforms that we have would migrate to this new platform. That required, of course, quite some discussion because if you take some of the responsibilities away from from teams, um it can be a bit scary,
[08:53] uh but eventually everyone felt like this is the right approach in order to uh accelerate. One of the interesting things is if you go for an operating model like this, um you're not just saying, "Okay, well, we're going to
[09:08] give everyone the possibility to do like have some autonomy and build whatever they need." Before, you saw that teams were using data for their analytical needs and analytical purposes. If you no longer have a central team and you divide this responsibility across the organization, all of a sudden it's
[09:24] not just give me the data so I can do my analytics, but you also become responsible for a part of the data of the organization. And that's a really big step from what teams were like teams were used to. So, one of the crucial points here was
[09:39] to really make a clear, well, as we call it, a business domain map. So, divide the organization in business domains, but also very clear responsibility boundaries. What domain is responsible for what data? What entities does it represent? What data products, as we call them, sit
[09:55] on those boundaries of those business domains? Um, you have to go through this process because otherwise what you end up with is the silos that we were trying to depart from. So, this was really critical step in, in that process. This is just a
[10:10] bit of a a conceptual view of what it looks like. We have operating models in our organization, and then on those operating models we define these these business domains. Um, the funny thing is, what you see, the more mature teams, they already have figured out these boundaries typically.
[10:27] The less mature teams you really have to help. Like, what are you responsible for, and where do you depend on the data of other domains? Um, but in order to make this work, we realized that this is absolutely critical because if you don't have these clear responsibility boundaries,
[10:43] um, yeah, you will end up with the same uh, the same mess. From a platform perspective, so, the goal of the platform is really to enable these domain teams to take that ownership because that's what we ask them to do. You have to manage that data end-to-end, uh,
[10:58] and also do the product life cycle management on your data products. And a couple of things there we found very important. Um, so, yes, we want to give some autonomy to those domain teams. They have to be able to take up the responsibility and do the way, like, things the way that what they would like.
[11:14] But, of course, we also need a robust system. It has to work together. Um, if one domain doesn't deliver, it impacts everyone else. So, there are some rules and standards that everyone has to follow. Also, in Europe, uh, compliancy, especially GDPR, is like very important.
[11:30] Um, so, we also needed to provide the tools for the teams in order to be compliant. You can tell them like you have to be compliant, but that's often not enough. You also have to give them the tools in order to to meet those demands. Um,
[11:45] and we found mechanisms to really be strict on these domain boundaries. So you, as a logistics domain for example, you just cannot access Salesforce data right away. No, you have to go to the commerce domain and ask for that data. And oh yeah, by the way, the commerce domain has to do some transformation from the Salesforce data into a what
[12:02] does this actually mean? Like yes, it's a Salesforce table, but it's actually about our business customer or it's actually about our case. Um, that's something that we're quite strict, uh, what what we're quite strict on from also a platform point of view. So on a very high level, this is what it looks like. We have our sources at the
[12:17] bottom. Um, we organize the data in repositories per domain. Uh, we have a governance plane. In our case, that's Unity Catalog, in which we define the groups and the access permissions. And then we have our analytical consumption on top, BI platforms, AI platform, uh, some
[12:34] analytical apps. Uh, this is just on a very high level. We'll go a bit more into detail about this later on. I mentioned it before. Uh, we use the term data products, and I know this is a bit of a convoluted term nowadays. Um, but these data products are really
[12:50] important for us in order to, uh, provide a governance boundary, um, so to say. Uh, so it becomes very clear this is domain responsible for this bit of our enterprise estate, and that domain is responsible for those products. Uh, again, if you don't do that, the
[13:07] chance of silos is, uh, quite significant. Um, in our case, they work as facades. So as a domain, you expose your data product in a data product catalog per domain. Uh, you also have an internal catalog.
[13:22] So your intermediate models or transformations sit in your domain catalog, which is not exposed to other domains. So, if you want to expose something, you put it in your product catalog and from there you you make things available. Um on the right-hand side you see a bit of a graphical representation. So, like
[13:39] for example, domain A, on the bottom half you see the internal catalog with a couple of layers. Then there's the product catalog in which we expose our products. We have an exchange and marketplace, which in our case is Databricks Ontos. It's a field uh field product from uh from Databricks in
[13:56] which we do the exchange of these products across the domains. And then there's the analytical consumption stack Well, enough about the high-level architecture diagrams, but just to give you an idea of where we are departing from and how we how we are currently solving this new
[14:13] operating model. So, why did we choose these two technology stacks? Again, you could argue go for one of the two. Why why have them both? Because it also brings some complexity in our in in in management. Um again,
[14:31] we decided to map our organization in domains and domains have different requirements. Uh it's a bit naive to say, "Okay, one technology works the best for everyone." Uh so, based on the requirements per domain, but also the constraints, for example, migration roadmaps within that domain,
[14:48] uh and also the knowledge and the skills of these domains, we made the decision to go for both of these technology stacks. Uh to give you an idea, so this is again still very high-level, but now with the solutions drawn in. On the right-hand side you see
[15:03] our SAP BDC stack, where we have our finance and HR domain, um and they are primarily on S4 on SAP with our data. Um so, that was also one of the reasons why why we went for for SAP. On the left-hand side you see Databricks
[15:19] for all the other domains who don't have any footprint on SAP. On the lower bit, you see our landing zone, which is on AWS S3, where we just land the data and then pick it up in Databricks and transform it there. Our governance plan is Unity Catalog
[15:35] also for the products that we create in BDC. So, that's really our central central governance plane. And we use DBT Cloud primarily for two reasons. So, one reason is to lower the entry barrier for the domains that were not so mature in terms of adopting
[15:51] engineering best practice and modeling best practices. But also, since we are having this kind of bit of a distributed way of working, DBT Cloud is pretty good in doing this orchestration across these domains. So, for us, that was really a reason to go for for this technology.
[16:13] A bit more about HR and Finance. So, and here it says why DataSphere because by the time we made this decision, BDC was not even launched yet. It was We were just happy that it transformed from Data Warehouse Cloud to DataSphere at that point, but what we saw that HR and Finance have quite complicated requirements with
[16:29] regard to authorizations for the reports. BW was able to handle that pretty nicely. But of course, DataSphere is a different technology, but in the POC that we did, we realized that if you want to have a same similar kind of structure, the transition from BW is easier to
[16:44] DataSphere than to any other system. So, that was an important reason. Urgency, of course, as you probably know, the BW 7.5 system is getting out of support by SAP. Our contract is ending the end of this
[17:00] year. So, we had to move fast. Also, like I said, we are running S4. We were also in a migration there as well. So, a lot of moving parts in the HR and Finance domain. And our partner in this field, Interdobs,
[17:16] Uh, a lot of experience about like in our BW system, also a lot of experience with other customers with Data Sphere. Um, so that also give it gave us the confidence that they can deliver uh in the in the transformation bit. So, those things combined made us
[17:31] like gave made us decide to to adopt Data Sphere for especially these two domains. Um, which um yeah, we we of course knew the trade-offs here, but it like we we reasoned that this would be the best best solution. Then in January 2025, we got a call from
[17:48] both our SAP and our Databricks representative telling us something interesting is coming up. And 1 month later this announcement was launched by SAP. SAP and Databricks open a new bold era of data and AI.
[18:04] Um, at that point SAP Databricks as a first-party service in BDC was also announced, but there were also some talks about a if you have a brownfield deployment of Databricks, there's also going to be something in store for you. It's going to be easier to share data. So, we were excited about that.
[18:22] But in the weeks after, to be honest, we were a bit confused. Like, great, this announcement sounds great and all, but what can we expect now? What what what is the road map? How does this work? And to be honest, it was a bit vague from both ends like what what what we could expect.
[18:38] Up until October 2025. And that's when BDC Connect was was announced. Um, the tagline says, "Seamlessly access your SAP data in Databricks lake house with a few clicks."
[18:54] To us that felt with a few clicks, that sounds amazing. So, semantically rich SAP data with a few clicks in Databricks, no remodeling required. Um, well, what's not to like? Now we're going to look a bit into what that actually meant for us.
[19:14] This maybe sounds a bit negative. Um, it's of course a That's a movie reference. But, uh, we are a early adopter, like I said in the beginning. And as an early adopter, you know, if you adopt new technology, you're going to run into stuff. Um, on the other hand, we also believe in this partnership and in the vision that was presented to us.
[19:31] Um, so I'm going to start off with the things that we liked, then the things that we really did not like, and also how we overcame these obstacles. Uh, and end with a bit of the, uh, uh, uh, look into the future. The things that we see changing and happening, and also how
[19:47] we see how our organization is adopting these technologies. So, we're really going to talk about primarily, well, the the the red circle, right? Like the, uh, Delta Sharing that BDC Connect brings brings us. So, let's start with the good stuff.
[20:03] So, once we started using Data Sphere as a, uh, new solution for our BW system, we were able to migrate all our financial and HR models to Data Sphere from BW within a year. And I say migrate, but actually this is not a migration at all.
[20:20] It's a complete refactoring because they are so different, those systems. Uh, yeah, it's it's not a matter of migration. I know SAP offers some services like, uh, what was it called? Uh, um, BW Bridge. Thank you. I think there's now something else even
[20:35] that you can, like, uh, that one. Thank you. Yeah. Um, we we we chose not to do that. We really chose to start with a clean sheet entirely. Um, of course, there are advantages to a solution like Data Sphere or BDC
[20:51] nowadays. It's SaaS, so provisioning is a breeze. Uh, we didn't have to spend any time in in doing that. We have native SAP connectivity, so just getting your remote tables in the system was really easy, uh, and that saved us a lot of, uh, a lot of time as well.
[21:06] Uh, and we really saw a reduction in overhead because before we had this BW system, which is on-premise but we hosted it in the cloud. We had a cloud partner like helping us there, but also a platform team managing the actual BW system. Uh so, a lot of bits and pieces.
[21:23] Um the cost that we're now seeing with Data Sphere or BDC, yeah, it's significantly lower and also the overhead is much lower. So, from a cost perspective, it was a big win for us. One important note, if you're in a migration program like
[21:38] this, yeah, of course, like understanding what your BW system looks like, what is still relevant, what do you want to keep, yeah, that that that's probably the most critical part. I mean, once you know what you want to build, um yeah, the building phase is usually not the one the phase that takes much time. Um but this was something that of
[21:55] course we spent also quite some time on really understanding, what do we have and how relevant is it still? Now, if you look at the timeline, like I said, we deployed our Data Sphere tenant in December 2024. BDC was announced. We could not just simply upgrade our
[22:11] Data Sphere tenant, so we had to do a redeployment in March. Um of course, we were already building some stuff on on Data Sphere. Um in January 2026, we uh built all the models of HR and finance on on BDC. And in April this year, we had the first
[22:28] data sets shared between BDC and Databricks in production. Um so again, I think given the nature also of the product and the integration with of course S4, um yeah, this really helped us to achieve the the migration timelines that
[22:44] we that we planned. So far for the good stuff. But there was also some stuff that we did not like or at least did not foresee. Because again, we started building in Data Sphere on the HANA database. If you look at BDC Connect, what does it
[23:00] support? It supports sharing from the uh object store of BDC to data bricks. So, in our case, that meant we had to replicate the data from the HANA database into the object store, flatten it, and then share with the BDC via the
[23:17] BDC connector to data bricks, which also meant some remodeling on the data brick side. Uh from a domain team perspective, this is of course not ideal because you end you have a footprint on BDC, and you need to do stuff on data bricks as well.
[23:33] Also, we saw some limitations on uh an additional compute cost. So, if you are consuming data via BDC connect like on data bricks, you pay a bit of a premium over like your normal SQL compute. Uh so, yeah, there's a premium that you have to pay data bricks in
[23:49] order to use this use this connector. Also, once you consume data via BDC connect, uh it invokes API calls on the BDC side, but it's quite transparent like how much that actually is, and also what the cost is. So,
[24:04] um you don't really it's pretty hard to figure out like how much that actually is costing if you're running queries from data bricks on the data in in BDC. Um which for now was fine because we're like you know, we're we're growing, we started small, uh but of course you want
[24:19] to have this under control. Another thing that was really painful is that uh there's no product versioning in BDC. So, if you build a data product in BDC, and then you share it via BDC connect, if you want to make a change, change the
[24:35] schema, add a column, uh you have to build a new data product. Um so, that's quite cumbersome. And as a reaction, what you see that what teams are doing is sharing very wide sets as a product. So, you basically just send everything, so I don't really have to bother uh
[24:52] updating these products. Um but that's It's typically something you want with data products. You want to have them quite scoped and then add stuff later on. Uh so this did not really help in adopting that data product mindset. Uh another thing that is
[25:07] a bit annoying is the ability to get metadata out of BDC for example for a third-party data catalog. Especially if you're having two technology platforms, you want to have oversight of what is in those platforms, what the lineage looks like. Um yeah, if
[25:22] you don't then not going to cannot get that metadata out of the system yeah, you kind of lose that a bit. So again, that's not that's not ideal. So what does it look like in practice? This is not a technical demo, but I'm
[25:37] just going to guide you through the process that we are currently having in place. So first of all, in in BDC and in our case and in Data Sphere and the on Hana you choose the model that you want to you want to expose via BDC connect.
[25:55] Then we have to create a replication flow. So we have to like replicate that data into the into the object store the data lake files as local tables. Once it's there, you have to go to the BDC cockpit and
[26:10] create a data product out of it. So it's like known within BDC as a data product. Uh and then share that via the BDC connection. Once that's done it will appear in Databricks. Uh but it will appear in Databricks as a
[26:26] share via UI. You have to manually mount this share to a Databricks catalog. So in our case we have a finance and a HR space on BDC.
[26:41] All the shares are coming in on the same place in Databricks and from there we have to decide okay, this share goes to that catalog. This share has to go to that catalog. Um in our case it means that the platform teams are always involved because we don't want the domain teams to access that UI.
[26:57] Uh so, as a platform team, there's always a like a step that you have to do. Now, the amount of data products is not increasing by the tens every day, but still uh it requires the platform team to do to do something in this regard.
[27:14] Because our governance plane is in Unity Catalog, we still have to define that product in our Databricks system. So, finance and HR go to DBT, our transformation tool, declare that share as a data product, which can just be as simple as it just creating a view and putting that into the uh data product catalog, but it's
[27:30] still a step that they have to do. That's more like how we decided to to organize the system, but still it's a step in the process. Once that's done, they can share that data product across other domains that are working in Databricks. Okay. Now, we have stuff from BDC in
[27:47] Databricks as a product. Great. Now, we go the other way around. So, let's say uh we want to use a data product that is in defined in Databricks in BDC. What we do in DBT is we uh if we define a
[28:02] product, we call the BDC Connect as the SDK. Um and if a new product has been created, the BDC like we update BDC Connect so it's aware of this new product. If a product is adjusted, we also up update this in BDC Connect so it knows, okay, a
[28:17] new column, for example, has been has been added. This is something that the HR and finance team have to do. So, they have this new product, uh run that notebook via uh through DBT, and then BDC Connect gets uh gets updated. Um once that update is done,
[28:34] this data product appears in the uh sub-BDC. However, um you want to mount this product to the respective space in BDC because we have a finance space and an HR space and well, depending on for who
[28:50] the product is meant, you need to mount it to that space. So, what do we do? Uh for every share that we create, we use naming conventions like the the stage like is it the dev for dev or for production? Um is it for HR or for finance? And based
[29:06] on those naming conventions, we automatically mount that uh data product to the right space. Um and once we have done that, then we can of course integrate that product into the models that already exist in BDC.
[29:22] It's quite an extensive loop. Um but yeah, it works. It Teams have to get used to it that like they have to go through some steps. Um but by doing these steps, yeah, we can share data across these two technology platforms. Whether this is seamless and with the click of a button,
[29:38] I'll leave that up to you. Yeah, a few clicks. ClickOps, right? Um now, with all joking aside, again, um this is not what we were expecting in the first place. Uh but you have to be aware if you're an
[29:54] early adopter, yeah, you run into run into some things. Um and that brings me to the next bit because like again, it is certainly not all negative. Uh this was a press release from last month, I think. Um and this is also what you see
[30:10] like also in the talks today that we heard from Databricks. I spoke to Sub earlier today on the expo floor. Um the release of new functionality for this partnership is going at a quite a high pace. So, with this release from last month, you see that we can now share more semantically rich data with
[30:26] these with this BDC connector. So, column descriptions, column tags, primary keys, foreign keys, they are now also shared via BDC Connect. Which for us, the remodeling part becomes all of a sudden a much easier because you can already have these relationships in your sharing.
[30:42] Uh we're also looking at introducing ABAC for our access controls. If we can just reuse those sub-column tags, yeah, we can be much more consistent across these two technology stacks. Um So, again, it was pretty cumbersome, but it's
[30:58] getting better every every update. Another interesting thing that we see, for example, HR, who are primarily on BDC, they start to realize, like, "Hey, I have this B as a B system that fits our reporting needs, but I want to do other stuff as
[31:14] well. We have surveys, and we want to use document intelligence from Databricks to augment these data sets and and use that in our BDC models. So, now they're also leveraging tools that Databricks brings to the table.
[31:29] Um In the beginning, they were a bit reluctant, like, "Why should I also use this other system?" Um but now they also start to see the possibilities that this brings. And I think that's where the the major strength also lies. Yes, these are two technology stacks, and they serve, in our case, different
[31:45] domains. Um but it doesn't limit you to also use stuff from both both ends. Um And I think if I look a bit further in the future, also what we've heard today, like, how Databricks positions itself also with regards to agents,
[32:00] um is very interesting to see what that does. Uh if I look at SAP with the analytical models that we have in Data Sphere with Joule, um yeah, how can we integrate these systems to give a more also for for business users a more, like, simple simple landscape. You just ask your
[32:16] question, and ir- regardless of where the data actually lives and where it's being modeled, you get the right answers. So, I think I think that's some really something to to look forward to. So, a couple of takeaways. Um I've been talking about our journey as
[32:31] PostNL and the adoption of these two platforms. I think in general, if you're in like the my like transition to a federated operating model, it's Yeah, well, this is obvious, but still is very important. The way that you set up your governance and define your products, that's the
[32:48] most critical part in order to make this work. Technology just really it really comes It makes your life easier, but it really comes second. Regarding the technology, depending on the circumstances, it can really speed things up. In our case, it
[33:04] was a no-brainer to go for SAP for those two domains. Um yeah, and it was really really sped things up. Um but you should question whether your teams are ready. So, not just the teams that are working with this technology, but also your supporting platform team because two technology stacks also
[33:20] requires more expertise, more overhead, more coordination. Uh yeah, you have to be willing to put in that that effort. Um And the partnership of SAP and Databricks is really starting to to deliver. But again, um
[33:35] are you willing to spend that time and effort in order to understand these systems and also keep up with the the changes that they're they're introducing because it's a lot to digest every time. For PostNL, I can safely say this was the right choice for us in this stage.
[33:51] Um of course, everything is changing very rapidly, but I'm very happy that we that we went down this path. Um and I'm very excited to see what the what the future brings. That concludes my talk for today, and I see there's still some time left for for questions, so I'm happy to take to take
[34:08] those. Um Yeah, so we we don't know they don't really do performance benchmarks, but for example,
[34:24] we have our bits detail table, which is like all the order lines that we that we do. Um and expose is to Databricks and see okay, how long does that take if we just create a table? And we were actually quite surprised with the performance. So, it's it's really not uh you don't really take a very big performance hit. We we noticed so.
[34:41] Um that's not a benchmark, but we were quite surprised with the with the performance that we saw.

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.