Merging Data Vault and Medallion Architecture Patterns with Patrick Cuba - Episode #58

Welcome to the Agile Data Podcast, where we talk about the merging of agile, product and data patterns in a simply magical way. Welcome to the Agile Data Podcast. I'm Shane Gibson.

Hi, I'm Patrick Huber.

Hey Patrick, thanks for coming on the podcast. Today I want to talk about this term that you've coined, modern Data Vault stack. What intrigues me, having a look at what you've written, is you've taken some Data Vault patterns and you've taken the Medallion Architecture patterns and you've blended them together in a way that people can understand how to apply Data Vault modeling into Medallion Architecture. But before we do that, before we deep dive into that set of patterns, why don't you give the audience a bit of a background about yourself?

No worries. I've been around in the data space for a long time, maybe too long. My background is I was a hardcore SaaS architect. Think of a SaaS architecture and maybe I've heard of it or maybe I've worked on it per se. And I actually came across Data Vault at a customer site. We were a few contractors out in Brisbane actually, and the information architect wanted to, or actually discovered this thing called Data Vault. And as a bunch of contractors, we thought, all right, we should get trained on this stuff. And to better support our mutual customer. We did, and we quickly realized how patented Data Vault can be. Looking at each other, we thought, wait a minute, we could write or design a tool that could automate these patterns. Some way, somehow, you map what is a hub, what is a link, what is a satellite, and then you let the code take over as deployable templates. And then build a Data Vault model. Of course, us being contractors, the first gig, we make mistakes, but that's the agile way to go, and we learned through iteration, through collaboration, and so on. And over the years, as we became more interested in what other people are doing with Data Vault, so I met in Brisbane at the time Roland was there, Roland Vos, so I met him in person. He's a great guy to talk to, to bounce off ideas, and he was pushing the, the BIML type of implementations for Data Vault. I subsequently joined a Data Vault consultancy and was doing that sort of full-time and delivering either WhereScape-based Data Vaults or advising customers on whatever they're doing in their space with regards to Data Vault. And that included NoSQL platform, which my background in developing a Data Vault solution or tool helped in developing their Data Vault stack because they decided, we don't want to use a tool, we want to build our own, which was really exciting because at that time, I didn't know a whole lot about Scala and Spark and that kind of stuff, but I learned a lot from working with those guys. So, I was learning from what their expertise was and they were learning from what my expertise was. I was super grateful for that engagement because it was originally a 2-month gig, but with, I guess, people can tell when you're enthusiastic about something. That gig itself turned into 1.5 years of, oh yeah, okay, we can now also do this or do that and so on. And it built from there. I joined Snowflake nearly 4 years ago. And to be completely transparent, I was not intending to do any Data Vault work because it was about getting customers onboarded onto Snowflake. I was a big fan of Snowflake already. But there is a need for, how do we do this on Snowflake, for example? And common questions, which has led to me developing patterns and experimenting with things and creating blogs, which is something I enjoy doing, and webinars, is things around, okay, Snowflake doesn't have referential integrity in terms of indexes and primary keys and so on. What do we do now? When I joined, there was a clear need for somebody to fill that void, which luckily for me, I did have the time to experiment and develop. And when Kent decided to part ways with Snowflake, semi-retired, marketing asked me to write some blogs about Data Vault, which at the time I thought, okay, about Data Vault on Snowflake, how do I turn that into something that's consumable? and I came back and I said, great, I've got an idea for a series. So it ended up being like 12 blogs in a series which built on from the very basics, what's partitioning, what's pruning, what's all the essential things, which actually talks about big data in general, 'cause everything is file-based now, everything's blob store. What does that mean on Snowflake and how do you manage that? And what we were discussing just before the start of this, it is the partitioning, of course. It is, okay, let's throw more memory at it, but it's not always the right solution, but The third important thing, to me at least, is what algorithm are you enabling by the data model that you're using? And it's not just Data Vault, it's any type of model. Sure, you've answered the business question. Sure, you've modeled, let's say, dimensional model, which in Data Vault is a satellite. But how have you structured that so that you're actually using the right algorithm? And just before the start of this podcast, we were just talking about my history and stuff, and It's not to be arrogant in my opinion, but a lot of this stuff is not documented very well, unfortunately, but it's been around for decades already. And in my opinion, it seems to be forgotten because in today's modern data architecture, I think data engineers are asked to do a lot, a lot more than what they're originally scoped to do. And they're overburdened with learning and keeping up to date with all the new technology that's coming out there, all the new tools, or this does this thing better, or that does this thing better. But at the core, you're still running on a data platform, whether it's Snowflake, Databricks, BigQuery, whatever. What is it that you need to do to take advantage of that at best? And that's a space that I found myself in Snowflake. Guys, let's go back to first principles of why we're using this database in the first place. Whether it's Data Vault or not.

Interesting your background, 'cause I've done a lot of work in SaaS in previous lives as well. And it's always intrigued me that Brisbane was the origin point for Data Vault in Australasia. Got adopted there early and then fanned out. It's really, really weird if you track all the Data Vault implementations in Australasia over the years. So the other thing you did do though was that during COVID you wrote a book around Data Vault implementation. So there's a whole lot of detailed knowledge there around Data Vault modeling and how to implement it, the actual technical implementation rather than just the modeling technique. I just wanna talk about this idea of Data Vault and Medallion Architecture because they're two terms and patterns that often get treated in different ways. So before we start, just need to do some anchoring. When you talk about Data Vault, how would you describe what you're talking about?

I'll start with, and I will read this portion because it's very short, but it is the definition and I've used it in presentations to describe Data Vault. This comes from the inventor, Dan Lunstead, of course. It's a system of business intelligence containing the necessary components needed to accomplish enterprise vision in data warehousing and information delivery. Now, I've used that definition specifically at actually multiple conferences last year, but I focused on the words enterprise vision because there's a lot to pack in that short sentence, which is probably why I think it's very valuable, not only data warehousing, but information delivery and business intelligence. But the enterprise vision for me says, okay, what are we actually doing with this data model? Let's take away Data Vault for a second. If I was to model a third normal form or information mart as Kimball, the three main things I'm always after in a data model are the business entities, what business entities is this business entity related to, as in interactions and transactions and business events and whatever. And then the state information of those entities as well as the relationships. So hubs, links, and satellites. Why pick Data Vault over another data modeling technique? So far, from what my experience and what I've seen, nothing in the industry takes advantage of the OLAP platform's capabilities quite like Data Vault does. And nothing embodies those three things as well as Data Vault does today, in my opinion. There are variances in techniques and opinions, of course there are, because people come from various backgrounds and they build their models and their architecture to suit their use cases and their consumers, so to speak. And I've spoken with quite a wide range of different implementers around the world, especially with my role in Snowflake. And I bring up concepts like business key collision codes and that kind of stuff. Some of it resonates very well. Some of it does not. Some of it's, why are we doing that? And it's a fair point because maybe you're not integrating 30 different data sources into a single canonical model. That's fine. Then maybe you shouldn't consider Data Vault. I'm quite happy to say, looking at your use case, I think the complexity is not worth it. You should stick to Kimball modeling. It's much easier for you. It doesn't look like you're going to be changing a lot of things in your data model anyway. And that's the gist of the Data Vault in the first place is I can easily integrate by business key for those hub tables. And if, as my organization evolves and there's more data sources or existing data sources change, the Data Vault model is designed to ingest those non-destructively.

I think the key is there's the Data Vault modeling technique, the patterns around hub sets and links, pit tables, bridge tables, the physical modeling, and then there's everything else around it. So when people talk about Data Vault 2.0 and they talk about Dan's approach, that is a way of working. There's a form of framework methodology, bunch of patterns that is more than just the modeling technique. When I talk about Data Vault, I focus on the modeling technique because that's the piece that I use. I don't use the rest of the framework, and that's okay. I have my own way of working of which Data Vault is a key. And I also follow Joe Reese's approach to mixed modeling art. So we will use One Big Table, Activity Schema, Data Vault, stars sometimes, where it makes sense, where it has value given the context.

Absolutely.

And for today, I wanna talk about the modeling patterns, cuz that's what intrigues me of medallion. The second question then is, how do you describe medallion architecture? If I said to you, what is medallion architecture? What's your anchoring statement? What do you use?

We were talking about things that, that hasn't changed in 20 years or, or longer before starting this call. It's nothing new in my opinion, medallion architecture. It's very well marketed in my opinion. So everybody seems to go, oh, I do Medallion Architecture. What is it that, that you're doing? I'm landing data, I'm transforming and cleaning it, and I'm making it available for presentation in some model, modeled form that's easy to ingest. We've been doing that for a long time. And that's my premise of Medallion Architecture. Okay, we've landed the data. Okay, what are we gonna call it? So in the industry, there's been various terms describing the same thing. But if you speak to somebody from a particular background, they say, oh no, but it's slightly different. We're doing this. So you're landing raw data and then not doing anything with it and then transforming it. Okay. So that's your bronze layer. Is that what it is? Yeah. Yeah. With reference to what I've done with customers or worked with customers is especially in the last year, there was a big customer that I worked with that's actually New Zealand-based, and they didn't like the name Medallion or bronze and silver and gold. So we use different naming for it. It's like a curated zone, coherent zone, and intelligent zone. I thought, actually, that's a pretty good description. It's doing the same thing, but it's more descriptive what exactly what we're doing with the data. So when we landed, we were using the platform's ability to do classifications and tagging and so on. We call it the curated zone because it's been curated and we try to automate it as much as possible. The coherent zone, I really like the name that they used instead of the gold layer or integration layer because of what they defined as coherent data, which kind of aptly describes Data Vault in a sense. They had a wonderful definition. They said coherent data is data that lives a connected life. 'Wow, actually that's pretty good. I like that,' which exactly speaks to how Data Vault works in terms of integrating at the hub tables. And another customer called it a SEL is a source-aligned layer, and then the EDW is integration layer. So, it just maps very nicely. And we were mixing a topology of data mesh with Data Vault, but we were of the opinion that completely decentralized doesn't work. Particularly for this operator model, that we wanted to enrich the existing data using existing or maturing patterns as we were defining them, and having consumer domains use that enriched data, bring their own business case, and if we already are supporting certain data or certain source data that they need, they can already pinch and pull the data they need from the integration zone. For me, short sentence, it's nothing new. We've been doing it for years. I've spoken with colleagues who even describe data mesh in a similar way. Aren't we doing this already? Even data contracts, which is another topic with another professional I was spending, or just having a beer with in Europe. Isn't that an interface contract? Yeah, it is.

I agree. So for me, I see Magellan Architecture. Is a layered architecture. So, what I try and do is go back to core patterns. And all it's doing is describing layers or buckets, and you set a bunch of principles, policies, or patterns to say, this is going to happen in this layer, this is going to happen on this layer, and this is going to happen on this layer. And I think you're right, it's been buzzwashed, marketected by a certain vendor, but this idea of a layered architecture has value. That is a valuable pattern. And we compare it to the big data days of Hadoop of just stick all your data in one big bucket and don't have any layered architectures. We ended up layering the architecture in the code layer. So our code would logically layer the data and it'll be physically stored. So we always layer it because otherwise we get a big bucket of crap that we can't deal with. Now what's interesting for me though is terminology's changed over time. We used to talk about persisting staging area. We used to talk about the EDW layer, retail presentation. There's been lots of different words. Layer 1, Layer 2, Layer 3 was always a good one because 'cause then you didn't have to be clear about what each one did. And in our product, we talk about landing, history, design, and consume. I can say landing and history kind of feels bronzy to me, but we treat them separately for a bunch of reasons. And then in your diagram, you've got Data Vault sitting in silver. You're saying the core modeling technique for Vault is silver. Whereas there's a book coming out on O'Reilly around implementing Medallion Architecture, And the designed layer that can form coherent layers seems to be in gold, and silver seems to be just a cleansed version of the source system data, maybe an ODS. And I've only scanned it, I haven't read in detail. One thing I love about patterns is they should be relatively clear with a good boundary and a good description. One thing I hate about architecture is actually it's so bloody confusing that it has no value because Your silver is not their silver and probably not my silver. So it's around being very clear what it is and what it isn't so somebody can adopt it. You've done a really great Medium post, which I'll put into the podcast around it, where you break out bronze, silver, and gold, and then you overlay the architectures and a whole lot of other stuff. So I just want to talk through that because you kind of also map the aliases. Bronze is a form of ODS, silver is a form of EDW. Gold is a form of consumer. So is that how you see it? Is that you're basically taking patterns that you've used in the past and then you're mapping them to the Medallion language to say, this happens in this layer, this happens in this layer, and this happens in this layer to give you clarity when you're doing an implementation.

So it's actually an excellent way you described it there, that it's, because in fact, that diagram or that article per se is something that I could walk back a few years, started with a particular customer and they wanted to do these layers. So, we had a few more layers than that, but within each layer, like sublayers kind of thing, you could almost call them subdomains almost. And in fact, what I put out there was sitting in my backlog of things to talk about or describe for over a year, in fact. It's since joining Snowflake, it comes to maybe November where everybody starts to quiet down. And then I'm sure you're the same where you've got this backlog of ideas. Okay, I've got time to really think about these things more, more, or mature them, or maybe it's worthy of having its own article that I'd like to get out there because one, I'm not dictating how things should be, but this is what I've seen work. Um, happy to discuss it, happy to, for it to be challenged. So that diagram there, excellent way that you put it, that one person would say gold is this or silver is that. That architecture in particular has evolved through, let's say, 3, 4 years. Because in my current role, when I join at a customer site there, especially if it's, they're going Greenfalls or vanilla, the usual What do we do? What are we aiming towards? And we whiteboard, and whiteboarding is remarkable, by the way. I'll throw that in there. And one of the first customers, it was really extremely helpful. It was just after COVID happened that everybody got into the same room. We knocked out what our layers, what we want in a 1-hour workshop. And I've taken the same pattern and you always work with very smart people, very intelligent people who know what they want and then say, oh, I like that, but what if we do X, Y, and Z? If you notice in that article there, I try to parameterize all the layers, but every single one of my layers starts with those letters lib_. Right? Before working with this one particular customer, I didn't have that. I just went cell, cal, bell, which is another common pattern. But he's a data scientist. He's a head of some department and he liked the terminology having these locations as libraries. So, LIB, library. And SAS background, you got some work in SAS. Everything was a library. I thought, actually, that's a pretty good idea. I like that idea because we also expanded what we had as SELCALBEL that I presented. So, well, I'd really like a lab area, you know, ah, actually, that's a good idea. What's it for? What do we do? And his requirement was, I want my lab to have access to everything. And this is where my experience came in. So you don't really want that. It's a great idea. You do want access to production value data, but you don't want to just give access to all that data willy-nilly. We need to design this properly. So that's how that pattern evolved as well. And I've subsequently memory hold that. And when a new customer has a similar requirement, say, what do you think about this pattern? And then the pattern has evolved since then. And with that Kiwi-based customer, when I joined based on an existing blog, they already had some picture from their blog in one of their Miro boards. Yeah, that's mine. Yeah, yeah. We like some of these things here. We don't like this, but we like a bunch of things here. And then I worked with them as well. And then that has evolved as well, you know, which is awesome because I think that's one of the things of consulting is that you get to work not only in different industries, but you also work with very smart people around the world, data scientists, engineers, and whatever. And you can see, okay, actually this pattern that you guys have suggested, I like it.

And you iterate, like you said. I remember a diagram I did many, many years ago, which had 7 layers because I wanted to be very clear about where something went. If you're gonna do that thing, that pattern goes in that layer, and it has to go in that layer. And it became like this immutable architecture that didn't work, because actually, every now and again, the rules had to be broken for whatever reason. And then what I found was, as you explain it, it became too complex. I was like, oh, you know, 7, that's too many. I'll just go work with somebody that does 3. And I'm like, yeah, but there's actually 12 in there if I break it down.

So my layers had 7 as well at one stage, by the way.

Being able to articulate and teach or coach or share a pattern in a way that's explainable and then actually being able to implement it. So I just wanna go through yours because with Data Vault and with Medallion or a layered architecture, there's some intriguing stuff in there for me, cuz it aligns with the way I think and do it, but it seems to be different than the way some other people describe, especially with a Data Vault architecture. And so the first one is, in the bronze, I think you are talking about a persistent staging area. So I'm gonna describe it. You're saying that the physical structure of the tables or files mirror the source system as much as possible. Is that true? So the structure is based on how we see it in the source? Yes. Okay. And so often in the Data Vault world, we're told no persistent staging, that the raw vault, the design model data is actually the initial data. So it becomes the bronze layer. And then maybe there's a transient landing layer where data kind of turns up briefly and we do something with it and we delete it because the raw vault becomes the immutable trusted representation of the source data over time. So did I read that right, that you are in your current architecture, you are saying there is a form of source-specific structures that are persistent?

This is also my, let's call it pet peeve about Data Vault in the globe. There are multiple definitions of the same thing, which you found, I found. And if I was to label it as some of it is blog-based data vaults, so people read blogs and then don't know which data vault they're talking about or they're describing, which confuses a lot of what's been put out there. The way I have defined it, or at least I've consulted on it, is yes, there's data landed, as it looks like from the source, and it's, let's say, landing zone, bronze zone, or whatever, and it's got a whole bunch of things in there, perhaps things that should not be in there, and perhaps things that are superfluous to our business case. But sometimes we don't know. A business case comes in, says, I need this data, and you get more than what you asked for. That's fine. It gets curated, and then it goes to the next layer. Now, I split landing from raw vault, and raw vault is where I think hubs, links, and satellites live. And hubs, links, and satellites in Data Vault 2.0, at least, do reflect the source, but it's the only place where you have applied some conformity. So, satellites look exactly like the source, in fact, but they have been conformed into a true change structure. So, your source could be snapshot, could be incremental, could be whatever, could be semi-structured, could be unstructured even. But when it gets to the Raw Vault, we've taken what we needed because not all data is, is of equal value and structured into a Raw Vault satellite, which then only tracks true changes. I could get snapshots for 10 days in a row, but if nothing's changed, then you're not gonna get new records loaded into that satellite. We also load link tables, Raw Vault link tables. Which depicts the business process that we are interested in, in getting from the source. And we of course have modeled the hub tables. I've seen some implementations where they've gone, oh yeah, we've modeled 300+ hub tables. What are you doing? That doesn't reflect the enterprise vision of your business. How can you have 300 hub tables? You should have hub account or hub customer or something. That is something that represents enterprise vision. So, hubs become your, let's say, your pin that holds all your data platforms or your software landscape together, and the links and satellites, you can have as much as needed, really. So the other reason why we want to split it is what I said earlier, that not all the data that, that is landed in the landing zone is, is of equal value. You can easily truncate that and, and purge it and archive it if needed. And the auditable data is in your data vault, and it's only tracking the true changes against it. It also gives you the opportunity to split your identifiers into its own satellite table. So a PII satellite, should the GDPR Article 17 come along, the right to be forgotten, you only have to manage that satellite and still have that aggregated analytical value coming from the rest of the Data Vault model structure. And I've written an article to suggest, only a suggestion because these things require much higher level, above my pay grade input, as to say, what is identifiable for a person, account, or whatever, where in that article I suggested, okay, look, you don't delete that record per se, you obfuscate it permanently. So it's the one place where I suggest you take the original record and then you scrub it completely, but don't change the hash diff because if a source system happens to have that same person arrive again, you can detect that and it will not get loaded. You record that detection, say, hey, hold on, that source system still has information about that person we shouldn't have data about anymore. And that becomes even more intelligence above the Data Vault intelligence per se. The other thing that I emphasize in the medallion architecture, it's a way I deliver Data Vaults as well, is when you take that raw Vault as hubs, links, and satellites, which is an interpretation, of course, where does the business Vault come in? I've seen in the wild that there's different, wildly different interpretations of business Vault. The one that I feel works really well is having it sparsely modeled. So if you needed to transform that raw data into something that's not available in the source system or some intelligence that you feel that needs to be in, in your Data Vault, you simply expand it with SAT_BV_ whatever with those persisted attributes from that business rule that you've developed, and that inherits the same auditability as the rest of Raw Vault. So you end up with hubs, links, and satellites, which are purely raw Vault that reflects the source, but you also end up with extensions of that raw Vault being business Vault links and business Vault satellites with that intelligence that is sparsely modeled and you can then use in things like pits and bridges and information mods and, and deliver what you want from it.

It's interesting because Vault is so well described and there are a set of immutable patterns you can't break. A hub only holds the key and some extended metadata. It never holds context. That is always in a SAP. A link is always a relationship between hubs, ideally around core business process. There's a bit of Vault shaming out there where the other patterns that aren't so immutable, they're opinion-based and they're valuable, you get shamed if you don't follow them. And it's gonna be interesting with medallion architecture when it starts becoming more opinionated, whether we start seeing medallion shaming. So let's just go through a couple of those, cuz these are some of the ones I struggled with when I started my Data Vault career earlier when I started using it.

So, how long ago was that, by the way?

Just curious. Probably only, only about a decade, maybe 12. So I'm still a newbie. I was working in teams where we implemented it. I wasn't physically implementing code myself. So one of the benefits of Vault is this concept of satellites. It is a pattern. It is an immutable pattern within reason. And one of the benefits we get for it is it gives us change capture detection. It gives us historized records over all time, all changes, and that is an immutable pattern within the set.

I like to use Roland's definition. He calls it only true changes.

And so we get SCD-2 for free, basically, because that's what the pattern implements. I would find very rare reasons, very rare to have a context where we don't implement that pattern. Yep. In fact, even then, if I'm not going to implement that pattern, I'd say use a different modeling technique. Do something other than Vault.

You mentioned earlier activity schema. I did do experimentation and I wrote an article of how to do that in Data Vault because it's pretty similar in the sense that it breaks up raw data into transformed data, your business vault, which it layers very nicely. Not strictly Vault, but it actually, you can reuse the same sort of flow and architecture for it.

If I want to rack and stack a bunch of core business processes, customer orders product, customer pays for order, store ships product or order, customer returns product. And I want to see time between, how long does it take between the order being placed and being paid? I want to figure out numbers that move, then Activity Schema racks and stacks that data in a way I can answer that question really quickly.

And repeatably, like any pattern, that's the selling point of Activity Schema.

And then I can apply that to feed off links. I can apply that to feed off hubs and sets. And that was where we've been experimenting. Do we say we're only going to feed off one of those or do we make it optional? Because when we have choice, it comes with a cost. It's the same as going from hubs and SATs to a DIMM. Yeah, it's a repeatable pattern. So one of the benefits of these modeling techniques is you should be able to write small blocks of code that get reused time and time again, like a YAML template effectively. So then we get into some that become more context sensitive. So source-specific vaults. This is where effectively the hubs are bound to a system. So let's have an example where I've got Salesforce as a CRM, and I've got an e-commerce ordering system that has customers. So Salesforce holds customer, the e-commerce store holds customer. Now, ideally, the, the vault pattern says conform them as a single hub, grab the keys, rack and stack them in that hub, because it has value. And then each of those source systems can have a SAP where the raw version of that data is sitting against that. And there is value in having this one hub that holds a bag of keys effectively. And yes, we have things like key collision and conformity of the keys and a whole lot of complexity that comes when we grab data from two systems that's not aligned, where the customer ID in Salesforce is not the customer ID in the e-commerce store. But racking and stacking them into that hub has value. However, if our context is there's more value right now of implementing a source-specific bulk pattern, then it's okay. You just gotta justify why that pattern has more value. Than the default pattern recommended for Vault.

That's a good point because John Giles has written excellent articles on top-down modeling, which is exactly what we always go for. And your source systems will change over time as you mature, and we've seen that a lot. Agree that there is some source Vault modeling involved. Then the question comes down to where do you solve that complexity? I've seen, and I've worked with, and also designed different ways of doing it depending on how complex the problem is and how much baggage you want to carry. Because a former colleague, maybe you've worked with him or spoken with him, Nils Erbisson, I love some of his one-line analogies. One of them that sticks out is you have to pay the Pied Piper somewhere, right? And I think it's also something of a challenge sometimes working with data engineers in particular because Data Engineers focus on automation, why do we need to do some of this Data Vault modeling complexity? And for me, you have a choice. Either you're paying for that, let's call it technical debt, upfront, or you're paying for it later. And the way I see it is the sooner you deal with that complexity, the cheaper it is going to be for you. Because the later on you try to solve this in your, let's say, Medallion architecture, the more you're going to have the problem proliferate across your business. And there's a whole bunch of problems with doing that. One is, as the whole world, modern data stack world, moves to consumption-based pricing, you don't want to repeat the same complex problem over and over again. You want to solve it once. Second problem with that is doing the inverse, of course, is If you don't solve it upfront, then you're leaving it up to the users to solve it. And who's to say they're going to solve it the same way? So now you've got multiple versions of the truth, right? As you say, bringing those raw vault key complexities, solving it upfront, you've got choices. Either the best choice is something I used to call, it's actually using Medallion sort of terminology. I said, first prize, Gold, second prize, and I, I didn't even call it last prize, I called it wooden spoon. You want something, it's just no good, you're gonna have to pay that complexity all the time. First off, can we solve it in the source? There is a 50-50 chance it won't be because let's say your source system is SAP or Salesforce or something, they're not going to change the way they do things for you because they've got a huge customer base of their own that they need to look after. Okay, so what's the next choice? Pre-staging. Can we solve this stuff before it even gets to staging? It's a possibility. How complex is that going to be? Or do we have the budget to solve it now? Is there some pattern we have to build or is it something we can solve temporarily or, or whatever? Then the next is, okay, we solve it in Business Vault. We've, we've brought everything in Raw Vault. It looks like the raws. but we solve it in Business Vault. So now there's a cost. There's this consumption that's happening that you're persisting as Business Vault structures, but there's that complexity you now have to take on. The last place, the wooden spoon, of course, is if you leave it to users because you're gonna take that same logic and you say, yeah, run this. So you're gonna run it every time. It's just gonna explode. So ideally, that to me is one of the key points of doing data modeling properly, it's gonna be cheaper for you in the long run. And you need to solve the complexity upfront because not only are you dealing with the cost of running the same query over and over again, you're simplifying what is the definition of those things that you've described, whether it's in the business glossary, defining business terms, or modeling the business concept model.

For me, it's about once you've made those decisions, articulating what they are so anybody else can understand them as much as possible.

Oh, absolutely.

So I'll give you an example. In your diagram, we talk about bronze, bronze being persistent staging, matching source system data's there. We talk about silver being coherence or what I call designed. We're going to model, design, conform, change the data so it's fit for purpose. And then consumer domain or intelligence zone or gold is around how people access it and making it fit for purpose for their consumption. And so I can look at your design and I can go, My guess is if we were going to conform customer, if we had customer keys in different systems that are either based on the same rules or not, we are not going to conform it in bronze. We're going to do no work to match those keys in bronze. We're going to do all that work in silver, and we're going to expose that work in gold so nobody else has to do it. And then we go, okay, so now it's very clear for me that conforming keys, single view of customer is silver. Now we come to the next level of complexity. Are we going to have a single hub that has all the customer keys, or for whatever reason, are we going to have source-specific hubs to begin with and then do the conformed hub later? And good practice says conformed hub, but there may be a reason that I want a Salesforce customer and e-commerce customer to begin with. But I have to describe why I've picked that pattern because it's not the standard pattern. And I should be able to be challenged on that, to say, actually, given that context, that's not the right pattern. But once we know what it is, then we can change in the future, but change has a cost. The next one is business vault, because business vault is the one that's kicked my ass so many times over many years. And so, good practice says now the pattern is raw holds the data, and then we create additional business vault objects, where we need to infer, conform, do change, where we have to touch the raw data and do bad things to it so it's fit for purpose, we do that as a business vault object, but it's just an extension of the raw vault structures. Whereas sometimes, and in the past I did this, I would go and copy the data from raw to business for a bunch of reasons.

Okay.

Now, I will still do that sometimes if I had to. If there was a reason why taking a copy of raw and representing it as business vault with the inferred data attached, and that raw to business is a direct copy of most of the raw things. If for some context that had value to me, if that was the best way of getting the work done, and I can live with the duplication of data, and I can live with automating it to make sure that raw and business records that are one-to-one don't get out of sync, then that's okay. But as you can just see, I've just added a whole lot of cost, increased storage, increased complexity of synchronization, the chance that it's going to get out of sync, automation of that movement over and above the inferred. So I have a whole lot of complexity I'm introducing to adopt that pattern, but it's okay as long as I describe why I'm willing to infer that complexity. For you, you've got raw and business sitting in silver, and I think later on you go through about business being inferred objects.

Okay, so a couple of things. I avoid duplication at all costs, and that sparsely modeled business vault is purely like one of the principles I like to infer with customers is let's talk about Business Vault in particular. What are we doing? We're capturing some soft rule or some change that is not able to be solved in the source system because ideally, and I say this just so that I can plant a seed in a customer's mind, is in a perfect world, there would be no Business Vault. Everything should be solved by source. Think about it that way. So you need to keep your business vault as small and tiny, smallest footprint as possible. But then why do we have any of this conformity or anything in the first place? Raw sources are not always gonna have the data you need in the form that you want. So we do have business vault, but does, does that mean in, in my mind that you replicate raw vault as it's, it maps from the source as this attribute's called this and this attribute's called that into something that's now called something else because it conforms to the way you define things. Couldn't you just do that in the view? So in that architecture pattern that I've got there, I've got raw and business vault in the same layer because I'm only extending what I need. And why I've got the business vault there is because I want to say to consumers, which have their own layer, own domain, the Gold layer, pick and choose what you want, and here's shared business rule outcomes. Because the other point that I also wanna make before I elaborate on that one is that I like to define to customers, say, look, think, also think about Business Vault as a separation of business rules and the outcomes. So when you're creating the business rules, they should be declarative, they should be idempotent, meaning that if I rerun it over and over again, I will always get the same result no matter what. By separating the business from rule vault, I could implement any rule I want in any language I want. It doesn't matter as long as it's still declarative. So if that rule seems to be written better or preferred to be written in Python, for example, it shouldn't limit how I use the Data Vault in, in any way or form. The outcome of that would just be mapped to business vault links and satellites because hub tables come from source Business keys are not defined in the Data Vault, they are mapped in the Data Vault, and that just extends what I've got in the middle silver layer. Now I have Intelligence Zone with its own business fault there, notice, because you could reuse the same patterns and reuse the same philosophy to extend the integrated layer with your own satellites and links that are, or maybe shouldn't be shared with other domains. So you've extended it into your own consumer domain, defined them as your business vault per se, but in essence, it's still extending the existing raw vault. So it's not redefining hub tables, not redefining any links or satellite. It's just taking what's shared and saying, I need to have my own intelligence solved in this way. And there's good reasons for it because this is a pattern that, that I presented at that customer and they've taken what they liked and thrown away what they don't like, of course. They like this concept of extending what we call their own private business vault. Because let's say, of course, our goal is single version of the truth, but what if you have a department, let's say treasury, where the data should not be shared? Or I have these transformations that in fact, if you have access to it, it may even pollute what you're trying to get out of the same integrated vault. And, and then that's why we've really extended it that way.

And that's where it's key because when I look at the diagram without the context, I've got two business vaults and business vaults are a thing and that's really weird. But what you are now saying is we're using the business vault structure. So we're using a business vault modeling technique, which is the same as Roar of hubsets and links. We are now saying that it's following an only new, so where we need to change or infer data, that is the only thing that goes in that vault. and that can be in the silver vault, business vault, or the gold business vault. But now the demarcation between those two patterns is who can do the work to create the objects in that vault, gold versus silver, and who can consume it. So now it becomes around data team design and operating model and security.

This pattern was based on a customer who was doing a hybrid form of data mesh. So they wanted people to own their, let's say, copy of the data. It's not really a copy, but their, their business case with the data. Absolutely. So you mentioned the word stream-aligned. Absolutely. That's exactly what we were going for.

It's about explaining those patterns. So now I can know when I do work in the shared business vault in silver or when I do work in the private business vault in gold, because you've given me the rules and then I know where to do that. So. Another example is where we rename fields.

Yeah.

Yeah, where we rename attributes. Again, it's one of those things that you should be very clear where you expect it to happen. Do we rename the fields in bronze? Well, with the architecture you have and the architecture we run, probably not. Not very often. We do every now and again when the name of the field breaks the tool that's landing the, that we store the data in, right?

You could simply do it as a view, right? Because we've got multiple consumers, They may have their own preference for certain things, which is fine. When I worked with this customer, I, again, I learned a lot because at that time I had heard of domain-driven design, but I hadn't really spent any time actually studying what it actually means. So when I joined them, I, of course, you want to deliver and you want to consult as best as possible and still make sense what you're delivering. So, I read Eric Evans' book, which particularly the strategic design perspective was excellent. It actually gave me a lot of material to work with and at least deliver a vault that they're expecting. And one of the funky names that they use in domain-driven design is anti-corruption layer, which I love that name because it implies that whatever happens in this layer does not corrupt the downstream. Area, which is all around microservices. Actually, if we're going to serve all these domains, these consumer domains, why don't we create anti-corruption layers? Like, you see the data this way, and you don't need to persist it as physical structures. You just use those OLAP patterns of star joins and everything and deliver it as a view because it will be performant. If it starts to prove that it doesn't, then we might use things like dynamic tables or something like that. But mashing those two concepts together sold it really well with the customer. Another example of where domain-driven design, at least the terminology or the linguistics of it, helped us a lot is when I was describing the hub table as well. We earlier talked about conforming keys and everything like that. We, at least the way this team was working, was describing source models and source systems and relationship to ourselves. They talked about different patterns like provider-consumer. There's different patterns in how you treat that source system because maybe it's a legacy system and so on. But after reading that book, I said, guys, for the hub table, we should define a relationship, which comes from the book as well, called the shared kernel. What does that imply? It means that this artifact out of our Data Vault, you can independently build your links and satellites that you need to solve your use case. But that artifact is the one thing that we need to share and manage crucially for the platform success. Because like we discussed, you will have account keys that maybe come from a source system, but don't map to the account key that actually the business will refer to. Because they're not gonna care about a Salesforce ID or KSafe ID. They have no idea. Who cares about those digits? I wanna know what the, the account number is. So where do we solve that complexity? How do we manage the potential collision if two systems come together and they have the same key value, but are actually two different business entities? And that's why that shared kernel concept became a crucial thing for us to manage within the platform.

For me, I do conceptual modeling based around some data vaulty stuff, some core concept stuff, some who does what from BIM. That's how I think about it.

And I use some of BIM as well, by the way. Some good stuff in there.

Good patterns. And so I talk about core business concepts, customer, supplier, employee, but often what we'll find is weak concepts. Something where we'll see a hub, but it's not really one that's used everywhere. Or we'll see an admin concept, you know, status change on an invoice, there's a weak concept. If we talk about a process, somebody enters invoice, somebody reviews invoice, somebody approves invoice, those are admin processes and they create weak content. Text, but they're still valuable for reporting. And what you're kind of talking about is master concepts. So this idea of master data management coming in as a pattern, which is that core concept of customer actually should be mastered once and reused everywhere.

I have an upcoming blog on it, by the way.

Makes sense. So, you know, single view, single list, all those kind of behaviors. Let's go back to that renaming though. So there's many reasons we will rename. We'll rename so it fits the data storage platform that we use if we have to. We'll rename so that it kind of gives us more context around, and we may rename the physical column if it's a physical storage. We may rename the metadata or the alias or the description if that's what we use. We may rename to fit our conceptual model. We may rename to fit our physical model. We may rename to fit our business model. Finance call that thing different to HR, and we're okay renaming them. The way you've described it, I believe that you're saying you'll pretty much do that in Gold because now you're doing domain-specific naming.

Ah, there is a sub-layer within the integration area that's called CAL, Common Access Layer. So there might be some conformity applied there if you wanted to create a view as an anti-corruption layer where, okay, we've conformed these columns to these names, but it doesn't impact the physical columns because Of course, a benefit of doing this renaming separate is, let's say that the source evolves as a column that happens to have the same name as what you've called something else, then what do you do? I like the idea that we came— that we use a discussor of anti-corruption layer because also we might evolve what our column names look like at some stage. Use case, sure. And we can have as many anti-corruption layers as we want. It gives us that flexibility and that same data source for that anti-corruption layer doesn't change.

What I talk about is I talk about principles, policies, and patterns and how they're different. I'll give you an example. You said that one of the things you do is you avoid duplication at all costs. So that is a principle. Your principle is I am not going to duplicate data unless I have to, but I guarantee every now and again you have to. You apply that principle as much as you can, and you apply the alternative when you are forced to. A policy is something that happens, and if I don't follow it, I get fired. The data stored in Bronze will match the source system. If I go into Bronze and I start modeling and conceptually modeling and master dataing, I'm breaking that policy. And ideally what we want is we want computational governance. We want to write code that tells me when somebody breaks that rule in that system. Maybe I write some code, which is useful anyway, to say, check the schema of that table in bronze, check the schema of the table we got given. If they don't match, somebody's inferring, conforming, doing bad shit in there, flag it, send them an alert so they can fix it. But then we get things like renaming. And renaming is something that actually we use multiple times in multiple different places. For multiple different reasons. So our principle could be rename as few times as possible, maybe. We're probably not going to have a policy around renaming.

I think it's going to happen a lot. Have you seen SAP columns?

We're not going to have a policy of only rename here because that's just bullshit and you can't enforce it because it won't be true. What we now have is renaming patterns. How do we describe those? Okay, so one of the things we want to do is we want to rename columns or fields to give it a business term so that it's available to be consumed by the user. Where is our pattern for that? Do we ideally want to do it in silver and surface it all the way through? Do we ideally want to do it in gold? If we're using Power BI versus Tableau versus Dataiku, does it matter? Does the consumption tool, last mile tool, affect how we rename? There's a whole lot of decisions. So now what we have is a repository of patterns for renaming. And you can go, well, this is the problem I've got, or the pattern that most people use. Is here. And what we know is humans are good citizens 9 times out of 10, but they're also lazy in a good way. If I can find a pattern that somebody else has implemented that has code and I can reuse it, I'm going to use it because it makes my job so much easier and I probably won't get yelled at. Renaming is one of those tasks that actually becomes fraught and therefore is a very large pattern base. The other one is data quality rules, the ability to clean data. That is the other core engineering practice applied in multiple different places. And all the layers. So we just treat those as a set of patterns. Where do you normally put metrics?

Metrics is a broad term. What do you mean?

Formulas where I calculate, infer a number. A divided by B, A plus B, percentage of, change over time as a percentage.

Depends. If it's something that's repeatable, idempotent, declarative, it should be a logical asset in my mind. And the outcome is the extension of raw vault, business vault. Satellite or link. Got a few examples on the top of my head, but one of the most complex ones was this example that I worked with a customer before I even joined Snowflake, where this particular customer is in the home loan market and don't see value or don't make a lot of money on credit card as a business. By regulation, I think, I can be corrected, when you offer home loans, you must have also offer a credit card product. The business was like, we're not going to spend a lot of money on the automation software for credit cards, but we need the core things it needs to do. It needs to be able to stand up to changing credit cards, as in it gets lost, stolen, new card is issued. And you can have a single card, like an isolated card, or if this customer wants to have secondary cards to give to his family or wife or whatever, that it needs to support those two patterns. And they went into the market and they selected software that does that. Sounds great. Sounds good. Solves the whole credit card thing. They're in compliance. However, there's future compliance. There's more compliance that came out. One of them is being able to say, what is the credit card exposure for an account? Not for a card, but for an account. Because they need to report on this account to the regulators. So the source system has no concept of an account. It only tracks cards. What do we do then? For this particular use case, the answer was right in front of us. The very first card issued to any customer is their account number. That never changes. Whether it's transferred to a new account, that lineage and all those cards associated with that lineage is then grouped into that account. So our first card issued to a customer is an account. That's how the source was modeled into a link table, is just purely on cards. But then in our business vault, we needed to represent it to what it looks like for the business. So we built a pretty complex business rule implementation. It did recursion in the SQL, and the output was this table. It said, okay, this is the first card. That's our account number. And then we populated, it's not really a same as link, but it looked like one where, because it's obviously referring to the same hub table, but one of them was being assigned. That's our account number. And that was built as part of the integration zone because the rest of the business would benefit from that complexity that we solved upfront. So the renaming and all the business rules and stuff had to be in, in a zone that's going to be shared by everyone. Whether what they call it, like if it's still cards or accounts, is really up to the view that renames or whatever, which is again our anti-corruption layer. Back then I didn't even know too much about an anti-corruption layer, so we just called it a view.

What I do is I talk about facts, measures, and metrics because I want to be able to teach people what the difference is. And the fact word is the best I've got, but it does cause confusion for data people. So when I talk about a fact, That is a number that's come from a system that's immutable. So quantity, they are facts because they were given to us. And that is the fact of the number. We can infer something later, but that's the fact. A measure is the things we do to it. We, we sum it, we average it, we count it. They're all those aggregation types because then I can measure average amounts, total quantity. And then metrics for me are formulas. I teach people it's like Excel where I go this divided by that, that times that, that over that. Those metrics where we're inferring something based on a bunch of facts or a bunch of measures or a combination of both. So once I give them that, that pattern semantics, then it's okay, where are they going to be done? And those ones, again, they're like renaming and data quality. They get done all over the place to a degree. So there's value in having those metrics, those A/Bs late in the gold layer, because then we can dynamically calculate them based on the context of the user. If I go average amount by product versus average amount by channel.

They're also not super complex and may not require an auditable backend to it, so it maybe doesn't need to be saved in a physical Business Vault Satellite or Business Vault Link, right?

But it could actually be a Satellite table in Business Vault that's virtualized.

It can be, and that's actually a good point because in, in my consultation, even recently, I think last week, it's like, oh, I think the Architects are saying, we're going to have virtual business vault as much as possible. Okay, maybe that's a principle, maybe that's a policy, I don't know. But think about it this way. If you are building a view over raw vaults and you're applying these calculations, what you're saying is that calculation is true for the whole history of that raw vault satellite. Now, if that evolves, if that changes, what do you do then? Especially if somebody's trying to query a historical value from 2 years ago. Does that business rule outcome still hold value? What's the alternative? Are you going to start putting hard dates into your view definition, which now you're starting to build technical debt into your views itself? And every time you run that query against that satellite, you're recalculating that every time.

You know, or are you going to build something really cool where effectively when you hit that view, it's parameterized and then that view is an aggregated view of a bunch of other views. And it's basically got a query path, which says, hey, I'm querying this at this time. So it's applying the business logic that was valid as at that time against the data that was available at that time. But then, hey, let's go one step further. Let's let them choose that period of time. So I want to see the data at that period of time, but I want to see it based on a business rule as at now. Now, what we're starting to do is we're starting to build a massive amount of complexity. Absolutely. But the question is, is it needed?

And what happens if you want to change one of those views in the stack?

Yep, what breaks? And then what happens when we put a trillion rows in there every day or a billion rows?

Yes.

So at that stage, we're going to want to materialize it or physicalize it. We're going to want to have the machine, the expensive technology we're using, take care of some of that response. These are all the things that happen with patterns. They're not immutable.

I'm not saying I'm outlawing views as business fault artifacts. What I'm saying is you need to decide how you define what is physicalized and what's a view. If it's something like that's cheap, that's this divided by that, and you're okay with the view, go for it. You don't need a historical tracking for all time for this value. Don't do it. But if it's complex, like the, the, the business rule that I described, where it involves recursion, calculating what is their account, and it has to deal with new accounts and existing cards, whether it's in the same account and stuff, then you don't wanna be repeating that all the time.

And so to answer your question, virtualizing the business vault is typically a principle. Ideally, we wanna virtualize the business vault as much as possible. We want views. That's our principle. And then we have patterns that say, here's how you create a view in Business Vault. And then here's how you create a physical table or whatever when that view doesn't perform or doesn't deal with the context of the logic. Because now what we say is it's a principle, not a policy. Because a policy says, if you ever physicalize the Business Vault, you get fired. It's a rule, it's immutable, it's a policy. That's how I think about it, because otherwise we get too dictatorial when we know it's not gonna scale, where we know there's always gonna be use cases that break the majority of our rules, 'cause they always happen. And that's okay, but we don't want them to happen by default. We don't want everybody writing their own dbt scripts that have no conformity across the organization. And when I end up with 5,000 of them, I've got a problem. Time-wise, we just need to close it out. So one of the things that's interesting for me is semantic language. Because you've worked in the data domain for a long time, like me, you switch terms interchangeably. You talked about landing, you talked about producer, you talked about intelligence, consumer, gold, silver.

It's the world we live in, mate.

And so the key thing we've got to remember as data people is we know we can switch it in and out. And because we're talking patterns, I can keep up when you change the term of what you're talking about. I could still see that diagram and go, oh yeah, no, he's talking about that one. But actually people that haven't been in the data world for a long time or aren't as experienced can't. So what we want to do when we talk about these patterns, so we talk about Data Vault, Medallion, whatever, we want to see if we can standardize our language to other people as much as possible to help them come on the journey with us. And then the other thing we want to do is use analogies. So you used some great ones, you had some great ones from Knowles and Rowland. And the ones I tend to use for Medallion for layered architectures, I talk about kitchens. I talk about a storeroom where data comes in, a kitchen where we do all the heavy work, and then a server or a consumption restaurant where people use it. And so for me, Magellan architecture, like you said, it's been around for ages. We had layers. We, and I tend to model my data architectures like you do. I have a storeroom where I just land the data in and it matches source and I rack and stack it and make it immutable for me. I have a kitchen where I go and design it and change it and make it fit for purpose and do a whole lot of bad things to it because the source system didn't do it properly. Then I have a place where we can consume it and I'll apply different modeling patterns and different other patterns into that place where everybody else goes and gets it. And then I have some policies. Does everybody have to go to gold? Do they have to go to the servery or are they allowed in the kitchen?

With this New Zealand-based customer, we actually said, you don't have to model everything into, to Data Vault. If your use case, you need an answer now. Go straight to your consumption layer if you need to. But if you want to inherit the maturity that we are building into the platform, then you should consider modeling it into the Data Vault.

And it's context. If you want to go build it yourself and maintain it yourself, then go feel free. We still needed then to have the conversation about could they see gold only, or could they see silver, or could they see bronze as the policy? Who's allowed to go into what layer? And then to do that policy, we need to know what's in the layer and what isn't. If I'm a machine learning expert, potentially I want to go hit bronze because I want all the behavioral raw data because that's what my ML model needs. I probably can't use the consumer data in gold because you've done a whole lot of stuff to it that will affect my model potentially.

Potentially, because I've had customers who want access to both because the outcome they wanted to build as a business vault. In that diagram, I've got an area called lab. Lab, you either had the intelligence area where each domain has their own lab, they do their own thing, or we had this shared lab zone. But the outcome ideally was you've built this engine or rule, the outcome should be idempotent, meets the same business rule criteria, which principles, you shouldn't run the same thing and have two different results. That doesn't make sense. Unless you're an LLM. But the outcome should be repeatable that you can say, all right, we can either extend the shared business vault or shared data vault with our extensions, or this needs to be a private thing that actually one of the outcomes was a metric vault as well. So not metric as in the intelligence like Splunk type of logging stuff, but actually like a metric store where it's used downstream for inference.

It's a bunch of policies. You can say the policy is a machine learning engineer's allowed to hit raw, allowed to hit bronze, but their results have to be persisted in silver or gold. Two policies, policy of access and policy of where you land that data so it's managed in the future. We want to write rules, we want to write code that tells us when that policy's been broken. So we can go in a conversation to them and say, okay, their policy was broken, it's going to be for one or two reasons. You didn't follow the rules, so I'm going to go and give you a fine, or whatever the corporate culture is for telling somebody off. Or you found a context that breaks our policies and this was the only way you do it. What was the context? What are we missing? Because it means we're missing something. We're missing a use case, we're missing a behavior, we're missing a pattern. And then we update our pattern library and we update our policies and that.

We definitely set principles up front, but we also, as a principle on its own, said that these can evolve. You think of these as guidelines instead. If you do have a use case that doesn't fit our patterns, then what is it? Because it, it could come from different angles. It could be an actual extension of the existing patterns, or maybe you, you've interpreted something in a way that now we've solved for it. But everyone's human, everyone, hopefully everyone's human. Everyone comes in with their own perspective on what they've done in the past or their experiences. And perhaps it does fit an existing patent. It just hasn't been interpreted that way.

Yeah. And writing up patents so somebody else can read them and understand what they are, the context they are valuable, and how to apply them is bloody hard. Even just writing that article you wrote around how you apply Data Vault models to a medallion layered architecture, the number of contexts that affect those decisions is massive. And so, you talk about batch and streaming, we haven't even talked about where that happens. So there's a whole lot of lenses, and that's why patterns and clear articulation of the patterns you're applying are useful. Look, we're out of time, so thank you for that. If people want to read more of what you've written, get a hold of you, what's the best way for people to find you?

LinkedIn is the best. I respond to LinkedIn, if not immediately, in a few days. I do continuously still push out articles and stuff, and usually it's based on not just what I've observed, sometimes out of experience with customers around the world, because I'm kind of filling that old Kent role in terms of advising on how to build a Data Vault, and I'm not prescribing 100% you must do it this way. Or that way, but at least giving guidance. So the best way I think is LinkedIn.

And then you write primarily on Medium, so people can go and find your Medium articles where you publish that. And then again, shout out to, you've got a book on Amazon. So people want to see technical implementations of Vault and how to take the concepts and actually—

That one is very technical, yes. Yeah.

But it needed to be written because there were lots of books on how to model it, but not how to implement it. So it filled that gap. Excellent. Thank you for your time. It's been great. And I hope everybody has a simply magical day. And that, Data Magicians, was another Agile Data Podcast episode. If you wanna learn new patterns that you can apply to craft your own agile data way of working, head over to agiledata.com. .io.