MetaDAMA - Data Management in the Nordics
This is DAMA Norway's podcast to create an arena for sharing experiences within Data Management, showcase competence and level of knowledge in this field in the Nordics, get in touch with professionals, spread the word about Data Management and not least promote the profession Data Management.
-----------------------------------
Dette er DAMA Norge sin podcast for å skape en arena for deling av erfaringer med Data Management, vise frem kompetanse og kunnskapsnivå innen fagfeltet i Norden, komme i kontakt med fagpersoner, spre ordet om Data Management og ikke minst fremme profesjonen Data Management.
MetaDAMA - Data Management in the Nordics
Holiday Special: Joe Reis - A Journey around the World of Data (Eng)
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
«Data Management is an interesting one: If it fails, what’s the feedback loop?»
For the Holiday Special of Season 4, we’ve invited the author of «Fundamentals of Data Engineering», podcast host of the «Joe Reis Show», «Mixed Model Arts» sensei, and «recovering Data Scientist» Joe Reis.
Joe has been a transformative voice in the field of data engineering and beyond.
He is also the author of the upcoming book with the working title "Mixed Model Arts", which redefines data modeling for the modern era.
This episode covers the evolution of data science, its early promise, and its current challenges. Joe reflects on how the role of the data scientist has been misunderstood and diluted, emphasizing the importance of data engineering as a foundational discipline.
We explore why data modeling—a once-vital skill—has fallen by the wayside and why it must be revived to support today’s complex data ecosystems.
Joe offers insights into the nuances of real-time systems, the significance of data contracts, and the role of governance in creating accountability and fostering collaboration.
We also highlight two major book releases: Joe’s "Mixed Model Arts", a guide to modernizing data modeling practices, and our host Winfried Etzel’s book on federated Data Governance, which outlines practical approaches to governing data in fast-evolving decentralized organizations. Together, these works promise to provide actionable solutions to some of the most pressing challenges in data management today.
Join us for a forward-thinking conversation that challenges conventional wisdom and equips you with insights to start rethinking how data is managed, modeled, and governed in your organization.
Some key takeaways:
Make Data Management tangible
- Data management is not clear enough to be understood, to have feedback loops, to ensure responsibility to understand what good looks like.
- Because Data Management is not always clear enough, there is a pressure to make it more tangible.
- That pressure is also applied to Data Governance, through new roles like Data Governance Engineers, DataGovOps, etc.
- These roles mash enforcing policies with designing policies.
Data Contracts
- Shift Left in Data needs to be understood more clearly, towards a closer understanding and collaboration with source systems.
- Data Contracts are necessary, but it’s no different from interface files in software. It’s about understanding behavior and expectations.
- Data Contracts are not only about controlling, but also about making issues visible.
Data Governance
- Think of Data Governance as political parties. Some might be liberal, some more conservative.
- We need to make Data Governance lean, integrated and collaborative, while at the same time ensuring oversight and accountability.
- People need a reason to care about governance rules and held accountable.
- If not Data Governance «(...) ends up being that committee of waste.»
- The current way Data Governance is done doesn’t work. It needs a new look.
- Enforcing rules, that people don’t se ant connection to or ownership within are deemed to fail.
- We need to view ownership from two perspectives - a legal and a business perspective. They are different.
Data Modeling
- Business processes, domains and standards are some of the building blocks for data.
- Data Modeling should be an intentional act, not something you do on the side.
- The literature on Data Modeling is old, we are stuck in a table-centric view of the world.
Dette er Metadema, en holistisk syn på, som en profesjon i Nordisk. Vær så god med de kompetensene vi har, og det er grunnen til at jeg inviterer nordiske eksperter i dat og informasjonsmanagment til å snakke.
Speaker 1Velkommen til denne helgspesialen av seseon 4 av MetaDema, og denne er jeg særlig overrasket over fordi vi har Joe Rees med meg. Hei, joe, hvordan går det? Hva er det? Hvordan går det? Godt å ha deg med, bare om konseptet av denne helgspersonen. Og dette er min mulighet til å reise utover Nordisk. Jeg har gjort denne podcasten for Nordisk-kommuniteten, med Nordisk-kommuniteten, men det er så mye som skjer i verden og det er så mange kreve mennesker som vi kan snakke med i tilgang til vår Nordisk kommune, så dette er den perfekte muligheten til å gjøre det. Og igjen, dette er episodeen som kommer ut rett før helsedagen og du har mye tid kanskje på hendene dine til å lytte til, så vi skal snakke listen to.
Speaker 1So we're going to talk about a bit of different things today. We're going to talk about data governance. Obviously, we're going to talk about data management. I want to have a bit of a stake in the ground. Figure out where are we at with data management. What's the role of data engineering? does it take over the role of data management? Broad questions, broad topic, but well, obviously I've got an expert here on data engineering and beyond. So Men, ja, det er sikkert at jeg har en ekspert her på data-ingeniøring og mer. Velkommen, joe. Takk for at jeg fikk til, du er fri til å introdusere deg.
Speaker 3Hei, jeg er Joe. Data-ingeniør, data-arkitekt, renoverings-data-scientist, author, podcaster, speaker. Hva annet? Kurs-kontent-kreator, utdann creator, educator, professor yeah, occasional athlete been in data space for a while it's 20 plus years, something like that, i don't know. Anyway, cramogian, cranky anyway, that's me.
Speaker 1That's a fantastic introduction. There are so many roles, so how did you get into data?
Speaker 3I'd always been interested. I should say telling my wife last night about it. We were just talking about careers. I'd always. Hvordan kom du inn i data? Hvorfor Jeg hadde alltid vært interessert i det. Jeg fortalte min kjøpestein om det i forrige natt. Vi snakket bare om karrier. Jeg hadde alltid hatt en interesse i data. Jeg husker at jeg var på Universitetet i Utah og jeg hadde slutte min matematikk og jeg studerte til å være en aktuar og jeg hadde eksaminer og klasser og så Jeg husker at jobbene jeg først så var i midt-2000-tallet, det var alt data analytics-relateret.
Speaker 3Det var mer for å ta det du kaller data-sjens nå. Jeg var ikke interessert i å gjøre BI-reporting. Jeg trodde det var litt bøy, ikke for å si at jeg likte det, men jeg tenkte mer på å anbefale mat til å løse svare problemer. Det var en klassisk knall-og-kast-situasjon. Jeg var veldig interessert i operasjonsforskning, linjære programmering og forkastning. Det var mange optimisasjonsproblemer. Jeg var interessert i å få en jobb og det var noe jeg ville gjøre. Jeg ble en del av et fag hvor jeg var i den samme jobben som en business CEOen som sette meg utenfor hans office. Vi jobbet på mange problemer sammen, så jeg ble en frontrøde til en veldig snabb-grunnskap. Jeg jobbet og ble embedt i business-opperasjoner, ikke bare i IT, som jeg synes var et unikt intro til å jobbe med data.
Speaker 3Å jobbe med data til å Det er en del av det. I can re-alert everything, so I go through waves like that. But yeah, i've always been in data. But the nice thing is I've been sort of in jobs that apply data to outcomes. It wasn't just like working in some back-office IT function. It was more kind of front-line A lot of forecasting, a lot of pricing optimizations, a lot of more applied data stuff versus being just kind of in the back-office. So, yeah, that's how I got. Det var mer det appliserte data-stuffet enn det som var i bakhånden. Det var sånn vi kom inn i det.
Speaker 1Du sa det i din introduksjon og jeg tror du skriver om det i boken din Du er en rekoverende datasjensker. Hvordan skjedde det å?
Speaker 3forandre til datanjening. I quick history lessons. The data science was. I think it was popular. The term was first popularized, or at least was first bandied about, in 2009, i think by DJ Patil and Jeff Hammerbacher, and they were looking for this kind of unicorn role of somebody who could work with data at scale at the time quote big data but apply statistical machine learning techniques to this data right.
Speaker 3So they were kind of looking for at that time syskale tekniske lønnsomteknikker til dette dataet, så de løp for, på den tiden, en unicorn. Men termene begynte å bli populære i de første 2010-tallene. Data er nytt olje. Det var en populær ting som kom ut. Da begynte man også å se denne rollen av datasienter som ble den sexieste jobben i 21. Århundre. Det er en del av hvor vi er med AI nå, hvor 10-tallet siden FOMO, feil av å misse ut var at hvis du ikke tar avdelingen av data og du ikke har en team av datasienter, så blir du forlatt av de som jobber med disse datasientene. Det jobber med datasientene ble interessant for et par grunner. En Well, the employing data scientist part became interesting for a couple of reasons. One is, you know, they think the notion was just find a bunch of PhDs, probably in physics or math, whatever. They're obviously going to be great at figuring out any problem in your business. So that was one brand of a data scientist. The track record seeks for itself. It didn't work out too well. I think people are trying to take what hedge funds and quant funds did and get physics PhDs, because that's you know anyway.
Speaker 3Jeg tror at folk prøver å ta hva hedgefondene og kvartfondene gjorde og få fysikk-phd-er, fordi det er, i alle fall, fordi de er gode til å løse problemer. Men hvis du prøver å oppleve det, jeg tror at finansiering er akutelt brukt fordi jeg tror det er mer pattern-rekognisering og finansielle data Oppgaven til algoritmer bruker seg bedre. Du snakker om ganske vanlige businessproblemer. Jeg vil øke utgiften på en måte. Jeg vil gjøre dette eller det Optimisere dette prosesset. Det er en funktionalt annen ting. Det var en av de første tingene jeg oppførte Å rushe inn i datasjens fra prosessutgifter og så videre. Men så har du også den andre siden, hvor firmaene hø.
Speaker 3Det er en del av det, and the job descriptions started to become very diluted. And why would that be? Well, i think you need to remember back around 10 plus years ago, there was a lot of discussion that the role of a business analyst was going to go away because data science would usurp and trump this role. You wouldn't need to do analytics anymore, because why do that when you have a smart person who can do analytics and machine learning? That was one thread And the other one was just the sheer optics. Right, do you want to be an analyst or do you want to be a data scientist when you're getting hired at a company? So you saw more and more dilution of the data science role. I also recall a conversation I was having this was a pretty common conversation where data warehousing was supposed to die, right Because and Det var en ganske vanlig samtale der data-verkstyrning skulle dø Og SQL skulle dø, for hvorfor gjøre det når man kan skrive Python og lage alt i Pandas?
Speaker 3Så vi går tilbake til i dag og det ble ikke ganske mye som ble lagt i pandas. Jeg tror det kom opp i 2015-2016, da vi var en gruppe venner, vi var litt på, som var litt jadet på data-science-krasjen og det var noe som var litt feil med det i den måten at det var overhypet og det gjorde ikke mye skjedd Og mange mennesker var, jeg tror, nesten karnivaldbarkere om data-science og så videre Og så hva du så var at mange men and so forth, and so what you saw is a lot of companies again, i think, had this illusion of the utility and the ease of doing data science right. Just get a data scientist and magic things will happen in your company. You come to find out again it's much harder than it looks and sometimes almost impossible, depending on things we can talk about. So that's where it came from. I got jaded on it.
Speaker 3I moved into data engineering because I had been hired as a data scientist numerous times, for jeg hadde vært høret som datasjenskjerning mange ganger for å gjøre maskinlæring, og jeg kom til å finne ut at det var bare noen data eller ingen data. På hvilken måte man skulle gjøre det forskjellige av det datasjenskjerning. Da tok jeg det på meg selv til å begynne å bygge systemer og infrastruktur og alt annet som jeg trengte til å gjøre mitt jobb. I just got sick of the whole thing. No offense to your data scientists out there. I love you to death. I get tired of your title.
Speaker 1I think some of the smartest people I've worked with have been those PhDs in data science. Just last year, i signed an AI strategy for a company and I had a group of data science PhDs I worked together with and they were just amazing, absolutely Fantastically structured. And there's one thing there that I find particularly interesting, and that is data science as a profession has evolved since 2009, and professionalized. There are PhD programs, there are master student programs at universities, but, weirdly enough, the same didn't happen for data management right, masterstudier at universitet. Men uansett, det samme skjedde ikke for datamangere. Vi finner bare datamangere masterprogram. Det er alltid om databaser, det er om datamangere, men noe som coverer datamangere som en profesjon er ikke virkelig der. Og jeg tror det samme går for datamangere, for jeg tror at en av grunnene til at ditt bok om data-ingeniøring var så lykkelig som det har vært er fordi det snakker om en stor gruppe mennesker som fant seg selv i en data-ingeniøringsspasje og trengte noen guidning, noe å holde på med, noe som identifiserer det. Jeg tror det er noe som gjør folk sammen.
Speaker 3I mean it's interesting If you look at a lot of the curriculum around the world universities. I mean data science was sort of a no-brainer right, because you could repackage a lot of existing classes and turn it into a data science degree And the thing is it was a hot job title too. So you'd be an idiot not to. If you're a university, thinking about the next programs you want to make, you're going to do data science. It's just sort of the prisoner's dilemma Are you going to be the data scientist? Are you going to be the university that doesn't do data science? Of?
Speaker 3course not right. I mean, it kind of comes packaged in different ways, like you might see a package as a degree in big data, which I would argue is probably not the best name for a degree because it's a bit of an outdated title. You might also have a degree, i think, kind of a data science light one is. There's a master's of business analytics, at least in the US. That sort of goes more over business analytics but they certainly go over machine learning, algorithms and approaches to that. You know. There's a master's of information systems, right, which is sort of a typical IT master's degree that you would get. There's even undergrads and information systems as well. And of course there's computer science and math, which has been around for ages and I think are good. I encourage people. If I were to pick some degrees I would urge people to go into. Maybe computer science, math, even philosophy, i think, are the three I would probably pick. They teach you how to think, especially math and philosophy. But data management has always been an interesting one. I think it more reflects the job title, popularity too. Data management is a very fuzzy field to a lot of businesses, at least in America. I can't speak for what happens in Europe, but in America, universities will work with industry in order to find out what are the hot things or the popular things they should be teaching the students, because it's a very market-driven economy. Students typically pay a lot of money for a college. Here. I don't think that's the case in Europe, at least as much And so the big difference, in the US at least, is the colleges and universities need to stay relevant with their curriculum.
Speaker 3I sit on the board of a university and I universitetene må være relevant med deres kurs, ikke sant? Jeg sitter på bordet av en universitet og jeg er akutelt forståelig av hvordan dette fungerer. Så datamanusjon er en av disse temaene hvor jeg føler at det er veldig opært. Det er en av de tingene du kan få som et sertifikat, kanskje gjennom DEMA, kanskje gjennom noe annet, men det er, i feel, like it's not an official degree, it's not an official program, nor is it taught really well, i think as a course.
Speaker 3Data engineering I would say that's actually becoming the next one. I know that there are several. There's a lot of courses actually on data engineering. Hannes Wilhuisen I actually got to hang out with him last week. He's the creator of DuckDB. He also teaches a data engineering class in Amsterdam and he actually uses my book for his class.
Speaker 3I didn't know this, and a lot of universities are using fundamentals of data engineering for their data engineering courses or something related to it. Now some of the challenges are I was lecturing at a very prestigious university recently and they want to do a data engineering program, a whole degree. But you've got to understand the administrative red tape to introduce a new program. Do not underestimate how slow universities move, even big ones, right. Probably bigger ones move slower. There's so much stuff you have to go through in order to get a program through that you know.
Speaker 3I think my book was used actually in an MBA class, which is kind of a counterintuitive one, and so obviously I offered to help design that curriculum if and when they're able to get to it. But in other cases I'm actively working on a whole degree program for data engineering. This will be the first of many, but it's being done behind the scenes with data engineering at least right. Even the US military is using my book for a lot of their curriculum And every big tech company in the world and pretty much every company seems to be using it.
Speaker 3But universities are an interesting one where I have this opinion that in tech and data, universities and colleges, i think, certainly need to keep up, but, more importantly, i think it's incumbent on professionals to stay on top of their own learnings, precisely because you can't expect, for many reasons under the hood, which you never see. You can't expect that a university is going to provide you with everything that you need, just for a lot of reasons. But it is a crying shame that data management isn't really its own curriculum at the university level, because I think, after all these years, it would be In fundamentals of data engineering. We call out data management as being one of the undercarbons of data engineering. You can't really do data engineering without data management. That's my long answer.
Speaker 1That's a good answer. Two thoughts to add on that. First of all, I think there's an important role of academia, and that is to have some kind of an independent role to check some truth in the dataverse. I feel like there's a lot of influential vendors, a lot of technology focus, a lot of sales focus in data, Especially when you look at data governance as a field. it pushes data governance into action. It pushes data governance into execution mode, which is a good thing to a certain degree. but then data governance is also kind of an oversight function, right, And if you push oversight into execution, who is checking who in the work we are doing? There's one thought.
Speaker 1The other thought I had is about data management and data engineering. I think that what you said is true. There is a bit more of concreteness to data engineering than there is to data management, And if we pair that with the technology focus that we just talked about, I think it kind of or at least I see some tendencies that stuff that we did in data management years ago is pushed into data engineering as well. Do you feel like data engineering has taken over data management?
Speaker 3I mean I could make a pretty strong argument that it's more popular I mean, just anecdotally, looking at the number of job titles out there of data management versus data engineering or data governance versus data engineering, i don't think it's a toss-up at all. It's very clear who's ahead on that one. Data engineering is an interesting one, right? Because what happened with that title is very similar to what happened with data science, data. Det som skjedde med denne titelen er veldig like det som skjedde med datasjens. Data-ingeniøringen var mer enn en stor datasystemsingeniør, ika. Du puttet sammen kustoms-solutionser som du bygde i ditt eget eget e-kamp, og disse er proprietariske. Jeg tenker på LinkedIn, facebook, google, mennesker som dette, hvor du bygger ting som Kafka, companies like that where you're building things like Kafka, dremel, big Query, just Amazon, dynamodb, redshift and so forth. These are systems that you had to build because off-the-shelf tools weren't doing it. But what's happened since then is you have a proliferation of amazing-to-use and easy-to-use for the most part open-source tooling and commercial vendors offering cloud-based solutions. The most recent popular, for det meste open source tooling, og du vet kommersielle vendere som tilfeller klubb-baserte løsninger. Den mest nære populære iterationen var den moderne datastakken, så det betød at du ikke måtte være så god av en ingeniør per se og kunne forstå distributerte systemer som du kanskje vil. Et av disse firmaene som fortsatt gjør det, som LinkedIn jeg vet at de har Venice og sånt, som er en nyere system, men det er supert lånevel ting, hvor det er virkelig, det er virkelig teknisk. Min venn, felix, jobber på Venice og han postet om Java-heapsizes og ting som det og å finne ut gøy detaljer om JVM-typer ting Det er ikke and figure out the gory details of JVM type stuff.
Speaker 3That's not the type of work you're typically going to be doing at most companies. It just isn't Like if you are good for you, but I think you're probably focusing on the wrong stuff, assuming you're using just kind of commodity stuff off the shelf, right. But what's happened is you know? so you had that low-level plumbing work, but now, similar to what happened with data science, a lot of other roles are now data engineering. So ETL developer, bi developer jobs that have been around for close to 30 years. Right Now, all of a sudden, what's old is new again and you used to be a BI engineer or BI developer. Now you're same tool or same skills, different tools, same shovel, different hole, and it's just kind of how it is right.
Speaker 3But what that also means is the title becomes samme skil, samme skjel, samme skjel, samme skjel, samme skjel, samme skjel, samme skjel, og det er bare sånn. Det er Det som også betyr at titlen blir veldig populær. For igjen, hvis du er interessert i denne typen av arbeid, hva skal du gjøre? Skal du appellere for et etl-utviklingsjobb eller et datateknik If you have half a brain, because that's the one that is the transferable job title to something else? right, you're not going to go for the one that's like a site-based developer or something antiquated. You might be working on that kind of stuff.
Speaker 3A lot of this is just repackaging of old things, but I think because of that, what you find is the popularity of data engineering might be slightly inflated by job titles, because more job titles are subsumed by that one. But it's also the recognition that increasingly, especially with AI, that data engineering is actually one of the most fundamental things you could invest in If you want to have at least production grade AI and analytical systems. So I think that's also part of it. But you point out the tangibility. So I think that's also part of it. But you point out the tangibility argument. I think that's an interesting thread too, because you build systems and it's tangible, right, you can see it sort of, but you can see the impact of it immediately whether it works or it doesn't right. It's sort of like if you're building a mobile app or a web app, it's like it kind of works or it doesn't, or mistakes and bugs. People will find them.
Speaker 3Data management is an interesting one. If it fails, what's the feedback loop? A software application? I saw this today. I was buying something from a vendor on a Black Friday or Cyber Monday sale and there's a bug. So I screenshotted it. I said it's not letting me complete this action. Send it to the customer service agent. Maybe they'll respond back, but at least that's a feedback loop. There's an error. I'm a user. Hopefully you can fix this. It's probably just an authentication issue.
Speaker 3Data management is an interesting one where, okay, something breaks, ie first of all, how do you know? And second, who's responsible and accountable for that? So these are always the biggest questions. And what does failure look like and what does success look like with data management? This has always been one of the questions. When I talk to business leaders and practitioners, they're like you know, all this stuff seems really cool but like and I'm sure it underpins everything, but I suppose the criteria is a lot more vague than when you're just building systems, right, or data science. You're building an algorithm for a model or an analysis, right. So I've had your take on this. Actually, how do you know you're successful?
Speaker 1Yeah, i think you're pointing at some of these issues that we are having in data management and data governance and that are actually pushing towards that tangibility, that pushing towards that. I read this daily now shift left in data governance. Don't really know what that means, but I think these are the things that push towards execution. Alright, because we, once we identify a problem, we are too far down the line. So we have that or we're talking about that in data quality management for years. Right, don't treat the symptoms, treat the cause. But how do you know what the cause is? right, yeah, if you're too far away from it. And I think that's the reason why a lot of the work we are doing in data management, data governance, is pushed towards that engineering, operational angle. I've seen this. What two weeks ago? someone posting about a role for data governance engineer. That's a new one. That's a new one. What does that mean.
Speaker 1Data governance data govops is also an interesting one.
Speaker 3What are they looking for? The reappropriation of ops is a particularly interesting one. Do you know what these roles, what kind of people or skills they're looking for?
Data Contracts
Speaker 1Well, when I arrived to it, it looked like a data management data manager, and I think that's why we need to take a bit of a break on the governance side and refocus on what data governance actually means to organizations, because we are focusing on how do we make sure that organizations adhere to the rules and policies we're setting in data governance Not so much about are we actually setting the right rules and policies? Are we actually ensuring the right, as you said, responsibility, accountability. It's more about how do we control it, how do we monitor it, how do we make sure that all that monitoring is automated as much as possible? Det handler mer om hvordan vi kontrollerer det, hvordan vi monitorerer det, hvordan vi sikrer at alt det vi monitorerer er automatisk så mye som mulig, og derfor har vi denne diskusjonen om datakontrakter, som ser ut til å være hverandre. Nå, kanskje det er bare meg Jeg mener det er fordi jeg er i datagov-bobbelen Men det ser ut til at.
Speaker 3Vi fokuserer veldig mye på hvordan vi implementerer datagov. How do we implement data governance, which in my mind is data management? The shift left argument is interesting. I mean for full disclosure. I invested in Chad Sanderson's company Gable.
Speaker 3Shift left to me, i think, it means shifting left towards the systems that produce the data, ie your source systems. Produce the data ie your source systems and having either a better relationship with the teams that oversee and hopefully govern that data, in anticipation that they may make breaking changes to your downstream systems. So this is sort of the flow we have now, where, because we're sort of, there's always the buckets right, there's the applications, software engineering, then there's like the data people over here and there's maybe data scientists sort of attached to that. Det er applikasjoner, softwareingeniør, data og data-scientist. Det er bare om å sikre at det er bedre samarbeid mellom de reiste og de reiste sider. Jeg synes datakontrakter er interessant, jeg synes de er nødvendige, men det er ikke annet's no different than if you've written software right And you create an interface file or something like that, if you remember those writing Java code, but it's like you're providing a spec or a contract about the behavior and expectations of the various classes and methods you might be writing In much the same way.
Speaker 3You know, a data contract just means like yes, does the schema meet the expectations I have for my systems that are downstream from the upstream one, right? If not, let's figure that out. But it also means you can't introduce breaking changes into data pipelines. But again, i think it's a good mechanism to at least make visible a lot of issues that up to now you know, weren't really highlighted. Right, the data team would simply accept it, accept the fact that they would get bad data from upstream. They do their best to, you know, duct tape and glue the data together and patch it up and sew it up and make sure at least it's somewhat presentable and useful for their downstream stakeholders, who are the, you know, if you're doing reports often business users and executives and so forth and no worse time to learn that your data is wrong. I had this happen to myself once with that CEO I mentioned earlier. We were in a meeting and the numbers I made were very wrong. I didn't even notice. And, yeah, that was, i think, the last time I did that one, but you know. So you learn the hard way on this stuff. So hopefully you know. But what I'm excited about with data contracts just a quick aside is you know, chad Sanderson came up with this idea, you know, and they noticed this at his work I think it was at Convoy or something, but they were using Kafka, right? so this is real-time streaming and I feel like real-time streaming I feel like real-time is the other one where, if you have faster connections between different systems, your feedback loop is that much quicker.
Speaker 3I think part of the challenge we've had as an industry, especially when we're talking about analytics, is because everything's been batch. Your time to identifying errors and dealing with them is your batch cycle time. If you've worked in manufacturing, which I have my background is in supply chain and manufacturing, i've done a lot of work there you want to try and resolve errors as quickly as you can, go to the root cause. You say, not just treat the symptoms. This is classic lean 101, right, but I think part of the problem is in analytics, especially because the feedback loop between discovering errors and the upstream cause of that is so disconnected by I analytics, for eksempel, fordi feedback-lupet mellom å utforske fordeler og det oppstående er så utsatt av en stor del tid du aldri kommer til å komme til ruten Og du utvikler ikke empati som du hadde om du jobbet på en kontinuerlig basis, altså en enkelte-tjeneste-forhold som du hadde i Lean, realtid, jeg tror, er en muligh opportunity.
Speaker 3Or streaming, i should say it represents an opportunity to shorten that window where you are getting the feedback and the team producing the data also gets the feedback Right. So I think that's one of the things I'm excited about. You know, as I think, with the commoditization of streaming data and that becoming, i think, more of a first class citizen, you know, hopefully that governance becomes actually easier in that sense Because you're just able to identify problems Quicker, because you have to Right, you can't just let it sit.
Speaker 1Definitely. I've been thinking about data Contracts in a different, different way, more related To data sharing agreements. That's a big one too. How can we and I mean Data is becoming a lot of organizations Part of the core business now? That's a big one too i en strukturell formatt i stedet for at. Vi har vært på det for år og vi har fått 200-pages PDF-er og da prøver du å finne ut hva som er i det. Så denne pushen er virkelig og denne pushen setter også en annen setning av behov og du må managere dem på en måte. Så der gjør det definitivt sens å deployere datakontrakter. Jeg Så det gjør det sikkert noe å utbytte datakontrakter. En ting jeg har spurt om er hvem som utbyr datakontrakter. Jeg tror det er der roen av datagovernevnsmessig til datarbeholdning er. Det må hende noen slags beskrivelseaktion før man kan gjøre den komputasjonelle. Man må beskrive problemet, man må utbyrde hva kontrakten bør betale. Du må beskrive problemet, du må designe hva kontrakten bør betale, eller du gjør oppgaveordninger i datasharing, for eksempel no-transcript.
Speaker 3are we talking about the conservative party or the more liberal party? Are we talking about the very libertarian party where it's like everybody just does their data gov ops on their own? If you're using the term ops in anything, that usually implies that you are doing it on your own, you're empowering your team to take it upon themselves to have the responsibility and accountability. As an aside, when I see a DevOps team, i sort of joke, because that was not the intention of DevOps. It was meant as a way for people to operate in a continuous workflow, but that's an aside, so I think part of it is an interesting question and it actually hadn't occurred to me until now. but, like in this day and age I suppose in any day and age, but especially now, since we live in the now to take a step back with the data contracts question who do you feel are responsible for data governance these days?
Data Governance
Speaker 1I think we've been doing data governance in a weird way, setting up our own data governance teams, that kind of sit in the back room. Vi har gjort data-regjering i en ulike måte sette opp data-regjeringsteamer som sitter i bakgrunnen og prøver å bestemme hva å regjere og hvordan å regjere. Jeg tror ikke det er mulig mer. Jeg tror vi må finne en annen oppgave til det som er mer integrert. Så på denne punkten, tror jeg vi kan gjøre noe på organisasjonalsiden. Når vi snakker om hva de gjør og hvordan de kontrollerer hverandre, så er det en annen historie. Jeg tror at regjering er et godt eksempel, fordi dette er hvordan min tro fungerer. Når vi snakker om datagoverning, jeg tenker på datagoverning som det legislative partiet som gjør regjeringene part right, making the rules, and then you have an executive part, enforcing the rules.
Speaker 1You shouldn't be the same people, right? This is what we call a police state, right? If it's the same people building the rules and enforcing the rules. So you need someone who has insight enough to understand what's going on, to create rules that apply, that make sense in the organization, but at the same time, be distant enough to control themselves. And I think that has been a bit of a challenging thing because we were doing. We were trying to do this in different teams, and that's why I like the idea of the federated data governance that it has been pushed forward now, where you rather do it collectively. You have kind of a forum or a meeting place where you meet and decide together and you and decide together And you have checks together.
Speaker 3Yeah, i agree with that, And it's interesting right now. A contemporary example is what I'm seeing in the United States. Trump's going to be president soon And he's committed to shrinking and probably destroying a lot of the US government. Why is that? There's a lot of waste in the US government. I don't think this is a surprise to anybody for å gjøre det for dyrt. Hvorfor er det sånn? Det er mye utrygg i USA-governmentet.
Speaker 3Jeg tror ikke det er en overraskelse for noen. Jeg er veldig bekymret for å se hva som skjer. Jeg tror det er mange regjeringsorganisasjoner, mange regjeringsoppdateringer, noen med gode mennesker, noen. Gjennom min egen personlige opplevelse, through my own personal experience, i'm like why do you even exist at all? But I feel like this is one of the things with data governance, for example, where you can probably have some comparisons. So what you mentioned the back office team, sort of the shadow governance team, whatever that comes up with these rules and tries to I think the enforcement part is the interesting one. You can come up with all the rules you want for me and my team if I'm an engineering team, unless there's some for meg og min team om jeg er en ingeniør. Uansett, om det er noen måte jeg er holdt tilgjengelig til disse reglene, eller mer enn det? har jeg en grunn til å bære disse reglene som du har kommet opp med? og nå må jeg følge dem? for hvilken grunn? Hvis jeg ikke har en grunn, vil jeg kanskje ignorere deg, for du har ingen hår.
Speaker 3I'm probably going to ignore you. Is what's going to happen? because you have no teeth to do anything about it, right? and also, you didn't bring me along for the ride, so why do I care? you're just another person taking up my time, right? who thinks you understand my job, you think you understand what my mandates are, but I I have different incentives from my boss, most likely, and if my boss isn't aligned with it or say I am the boss, right, either way, it's like you know, if you're not working with me now, you're just giving me a bunch of extra work, and I don't know anybody in the world who likes that. Winfrey, do you want me to give you a bunch of extra work to do? you know, in your already busy schedule, you probably don't.
Speaker 3Right, overveldende data-governance er at. Det føles som om de har gode intentsjoner, men det blir en kommitté av vass som skaper mer vass og mer problemer enn det løper, og så er det noe jeg har opplevd. Det er en lille løsning at de kan gi oss mer regler nå. Så unnskyld om det er forståelse Jeg føler at for at the end of the day, because it's like cool, are they going to give us more rules now? So, unless there's enforcement, right. So I feel like enforcement needs to be if I know why I need to enforce rules and it's in my vested interest to do so like it just makes everything better and everything runs better and it doesn't get my company in trouble. Sure, i'll build that in.
The Problem of Ownership
Speaker 3As software engineers, right? One of the first things you do is you write tests for your code. Why do you do that? Because you don't want things to break. Why? Because you probably care about your sense of craftsmanship hopefully, right And you don't want to affect downstream systems and your own system and have things break all the time. That's why you do unit tests, integration tests and so forth. To me, that's a governance thing, just like data governance. It's like you're governing your process. But again, if I don't have a reason to care, or if you're just going to create a bunch of extra work for me, like, yeah, i think you know, i think you're right, this is part at least in my opinion, this is part of the reason that data governance is it needs a second look right now. I don't think the current way that it's been done, where it's just top-down command.
Speaker 3Det fungerer ikke særlig når man snakker om, feks, datateknologiske firmaer. Data er produktet, vi er en teknologisk firma. Denne topp og nedkjøpende kontrollen fungerer ikke alls i dette tilfellet. Det fungerte bare i IT-tiden, da alt var kontroll og kontroll. Det fungerer ikke i dag. Det er det problemet vi har med datagoverning.
Speaker 1Du er på punkt med det, Men det er også noe om hvordan vi sikrer at vi er tilgjengelige for våre aksjoner. Vi kontrollerer det Og jeg tror at ja, datagoverning Hvorfor gjør vi datagoverning i en annen måte enn vi har gjort IT-gøverning eller korporatgøverning at data governance? why are we doing data governance in a different way than we have done IT governance or corporate governance? Why don't we find the same mechanisms and apply them to data? Why is that so hard for us? And I think part of that is because we have a different relation to data. I'm not going to go deeper into that. That's philosophy, right, But I think people have a certain relation, a certain ownership to data.
Speaker 1Another thing that irritates me is when people say we assign ownership. How do you do that? How do you assign ownership to people? That's just not happening, Like ownership of data. Yeah, I've done a project years back on implementing SharePoint. Right, I'm sorry, The shift to SharePoint. That was an interesting one, because people have such an ownership to their data, to what they have created and their folder structures and whatever, because it gets so tangible, right. This is how we put the way our mind works into data, which is really interesting A folder structure that fits everyone. We did that years back. It doesn't work And I think it's theme for data regjeringen generelt. Du kan ikke forstå disse reglene når folk ikke sier seg inn i dem og ikke ser seg i disse reglene.
Speaker 3Det minner meg på Dwight Schrute i Office den amerikanske versjonen i minst. Han ville alltid prøve å være regjeringsforstående i Office, men ingen lærte forstår i offensivet og noen har vunnet, ikke sant? Det er bare Dwight, han er en dork. Så det er det. Jeg føler at mange av dette er. Ordning er en interessant ting også, ikke sant? Så jeg har en kabine oppe i byene i Wyoming, ikke sant? Så i USA har du atleger, ikke sant? Hvis vannet passer til ditt eget eget, du kjøper den vannet. Men hvis du vet noe om vann, som jeg tror de fleste bruker på daglig, du har ikke vann, det går. Du har ikke vann. Det går til landet, men det går til andre menneskers land. Det går til publikum, privat land eller noe annet. Så du må være en god støver av vannet hele tatt. Hva skal du gjøre? Dump en masse toksiner i det I nærmest i vann. Dump a bunch of toxins in it in your neck of the woods, just because you can.
Speaker 3And I feel like this is what the ownership of data sort of alludes to is that ownership fails to recognize that data is a continuous thing. It flows right, just like ideas flow, knowledge flows. You don't own ideas and knowledge per se, maybe from a copyright standpoint and IP. But it's like you don't stop the flow of ideas and knowledge, and data is what facilitates this in your organization. Vi stopper ikke flowen av ideer og kjærlighet.
Speaker 3Data er det som gir oss mulighet til å organisere. Å si at man har egen data betyr at man har egen grunnlag for hvor data kan og ikke kan bli konsumert, men det er for noen ulike perspektiver, absolutt klart. Jeg kan ikke dele dette data med noen mennesker. Men det er også en myrkig tema. Hva har du egentlig? Hva har du egent? It's a very murky topic. What do you actually own at the end of the day? Because every data is derivative of something else. It also implies silos, which are another thing. Right, so now we can get that. But that's one of the scourges of making data work is the fact that Conway's law is just sort of this inevitable thing in most companies.
Speaker 1That's a really good point and I think that what people have tried to do with the data product mindset trying with the data product mindset, trying to set boundaries to the data right Package it up and then you can have an owner for that certain product, rather than data as a fluid element. I think that's hard to do. Right, there are certain products that you can pack up, but really data, as you said, it flows across the organization. We did a workshop a couple of years back, when Data Mesh was new, on data domain ownership and how to define boundaries between data domains. It's so hard. I do.
Speaker 1Because people have a certain connection to that data for a certain point of time. But I mean, as you said, data is like water It flows beyond and it's connected.
Speaker 3This has been one of the hardest things I've been writing about. Right now is there's a section in my new book on data modeling where I go through business processes, domains and standards. Right, these are some of the building blocks of data and data models. But precisely what you just said, when I'm writing about data domains, i'm like well, crap, okay, so it's not as easy as it sounds. Right The Ok, så det er ikke så lett som det ligner.
Speaker 3Det letteste er å oppføre den samme bærende konteksten som domain-driven design snakker om. Jeg tror det er mye merke til det, for sikkert Deiligheten er at funksjonaliteten av kode. Når du skriver en softwareapplikasjon, det er en diskret ting som depiserer en business-prosess eller noe slags ting du prøver å automatisere med en applikasjon. Differensene med data er hva er start og slutten av det. Det er der du kommer inn. Det er en kontekst av data som er veldig fraktelig. I denne måten, det er ikke nødvendig å forstå domener som Erik Evans beskrev dem, i min mening, to veldig gode in that way. So it doesn't neatly apply to domains like Eric Evans described them, at least in my opinion.
Speaker 1Two really good points there, fantastic. So one of the things I think that's the entire idea of making boundaries to data. I think that's a bit of that IT legacy. Right, you have certain data that flows in certain applications, but the applications don't grow according to how data grows, and I think for years we had that application-centric view on our IT landscape and that really is a legacy that we're still working with and trying to navigate within organizations.
Speaker 3Yeah, it departments. Right, it's like you buy the software, you maintain the software. Data has always been sort of en byproduct, ikke sant? Business exhaust er det som det alltid ble beskrevet i dag, og så har du det jeg kaller det mørke området av data, som er sprøydskap. Det gjør at verden går rundt, men ingen vil noensinne snakke om det, for det er en svrt spørsmål å snakke om. Hvis det ikke er i en system, så går det ofte inn i Excel.
Speaker 1Jeg har en hel del om data og IT. Jeg vil høre om det noen gang.
Speaker 3Vi kan snakke om det på podcastene.
Speaker 1Du har jo sagt om ditt bok om datamodeling. Har du mer innhold på det?
Speaker 3Jeg jobber på det nå. Jeg tror at det jobber med mixmodellart. Du kan finne mange tidligere drafts og seksjoner på praktiskdatamodelingsubstackcom. Men noen ting er at jeg føler at datamodeling er en av disse temaene som er korte til alt vi gjør i data. Du modeller data i en måte der det er godt struktureret og representerer faktene, menneskene, hva du vil kalle dem, i ditt business, i eventene og så videre, eller du gjør det haphazard og jeg tror alle vet konsekvenserene av hva som skjer når du målger dine data utenfor dine målger. I både fall er det data, men ikke alle data er det samme. Ikke alle data er like. Så det er egentlig, jeg tror, å reintroduere det temaet av datamodeling til praktisjonere, uansett om du jobber i software eller om du jobber i analytikk, maskinlæring og så videre. Jeg føler at det jeg har opplevd er at praktisk kjøp, kompetens og skil om datamodeling har faktisk forandret over de siste 20 årene. The practice, knowledge, competencies and skills around data modeling have actually declined over the past 20 years. There's a lot of reasons why we'll get into, but if data is this important to the world and we treat it the way we do, i feel like we're doing a huge disservice to the industry and to the longevity of our profession. I feel like bad data modeling is one of the root causes of a lot of issues that I see, whether it's broken data pipelines, whether it's people don't believe the data applications, breaking machine learning models that probably aren't as good as they could be. So it's getting back to basics, right.
Speaker 3So this book covers Well there's a couple things too. The other thing I noticed is the literature on data modeling. It feels like it's very old, because it is. We're still stuck in this table-centric world where we're talking about data modeling approaches for relational database, the relational model, which is great. It's a work of art, i would say. If you're using a relational database, use relational model. It works wonders.
Speaker 3But the world's moved beyond tables. It moved beyond tables a long time ago. You have text data, you have images, video, audio, all this other stuff, metadata, artifacts from machine learning, right Models and so forth, like graphs, all this stuff that you know are now widely used, probably in all sorts of systems. So the notion is teach people the techniques across various use cases of applications, analytics, machine learning, of how to work with data across different modalities of data, different forms. I think this is a thing that has been missing Meanwhile, we're still stuck talking about whether we should use a type 2 or type 3, slowly changing dimension. I'm like these are arguments I'm not interested in at this point. The world's moved beyond this discussion. I think the data modeling needs to catch up to where the world is, because right now I feel like we're just sort of making it up as we go along because there is no standard reference about it. So that's the book that I'm working on right now.
Speaker 1But we had a thought to that that I think is particularly interesting here, and that is I feel like many organizations have outsourced data modeling to vendors, to applications, and really data modeling has never been about describing the data. It og data modeling har aldri vært om å beskrive data. Det er om å beskrive business og hvordan business fungerer. Så det er veldig fundamentalt å forstå hva du gjør i ditt organisasjon.
Data Modeling and Data Knowledge
Speaker 3Åja stor tid og det er selvfølgelig noen interseksjoner. Jeg skrev en hel seksjon, så håper jeg at denne uken. Det er en kjaptere på app-modeling men section. So hopefully this week the chapter on application data modeling is out. But you know, it's interesting because when you start getting into modeling data for streaming right like modeling events for streams like you can't decouple the model from the physical limitations of the framework you're using, right like you literally could try. You're absolutely right. So it's like the business process you're trying to describe in this event, for example. So how do you think about that, given the limitations of the fact that you have to have sub-second latency typically under milliseconds, and all these other physical considerations, i'm taking a realistic view of the data modeling as well. It's not like I'm going to sit here and say this needs to encompass the business value argument and all this other stuff. It's like great, except for the fact that you're dealing with a system, too, that has certain like physical limitations and requirements, like if it's a distributed system. You know how do you think about things like time, right for your business process. So it's like you come to find out time is a very murky thing when you're talking about distributed systems. Okay, so which time is correct? If you have, i don't know, say, 10 different machines, what's the consensus? So it's interesting because when you talk about business process too and you talk about data, traditionally data modeling discussions have always been sort of this ivory tower thing like let's make sure we're capturing.
Speaker 3Takk for at du så på. Så du er absolutt rett. Ta i høyre det business-stuffet. Og også vet du at hvis du skal gjøre det i realtid, vet du at det ikke er det samme som å gjøre si data-varehus-modeling. Tror ikke at de er det samme, har ikke en mening. Du kan ha en mening, du finner ut det svære. Så jeg tror det er en del av det også. Men jeg tror du er absolut the business process you're trying to model, the business problem you're trying to solve with your model. Because what I often see with people when they model data, it's just almost like a cargo cult in some ways, especially when you talk about analytical data modeling.
Speaker 3Let's do the data vault approach. Why would you choose data vault? What are the pros and cons of this? Should I use data vault with a Kimball model or should I en Kimball-modell? eller skal jeg bruke Kimball og sette? Skal jeg bruke en stor table? Skal jeg bruke virtualisert bare en masse kjører som har ingen manifestasjon i verden. Men ofte hva du ser er at folk ikke svarer business-kvester med dette. Det er bare å svare fordi du ikke har en hol, a holistic context of thinking about the business. As you see with today's data practitioners where it's like you know you use certain tools and you just have like a thousand SQL scripts all over the place. You have no coherent business data model. You have a bunch of answers to a bunch of random questions, but you have not looked at the bigger picture to understand what is the broader question that we're trying to answer. So anyway, that's a bit of a tirade, but I'll get off my soapbox.
Speaker 1That's a fantastic tieback to all the problems I'm seeing in data governance. Yeah, like what? Focusing on the pieces and not on the whole, and you put out a lot of bait here for me to talk about, but there's one thing we need to talk about before. But there's one thing we need to talk about before we finish up the podcast, and that is the data governance book, and I've been working for almost a year, together with Jason Herr, on gathering our thoughts on data governance, on data accountability, on what is going on in the data world, and then, sadly enough, jason passed away now, in November.
Speaker 3Yeah, that was a bummer for the audience. Winfrey and Jason working a book together. It's actually associated with the book that I'm writing and it's going to be on the same label. Stay tuned for details on that. And Jason, in particular, is going to be on the same label. Stay tuned for details on that. And Jason in particular. Man, i was so much looking forward to just the stuff that you guys are going to come up with. The guy is such a titan in the industry. Yeah, it was crazy. I think we were talking on a Friday and he was saying you know, i've got some bad news. I've got a couple months left, right, and it should be good. I'm. Jeg har noen dårlige nyheter. Jeg har bare et par måneder til. Det burde være bra. Jeg vil gi det mitt all I morgen. Neste uke fikk jeg en e-mail fra hans kjøp.
Speaker 3Det var trist. Jeg var på en plan og var om å forlade til Pittsburgh, og jeg tørte. Det var svært.
Speaker 1Jeg hadde min ukelig møte med ham på mandag og ikke til å vokse. Jeg hadde en følelse i munnen min at noe var feil.
Speaker 3Ja, det var vanskelig. For dette boken er det ganske bra. Håper du kan kjøpe opp delene. Det er vanskelig. Når en person som denne går på, er det bare å håpe at du kan gjøre rett til deres legacy, og Jason har en stor like that moves on, it's you know. All you can do is just hope that you can, you know, at least do justice to their legacy, and Jason's got a big one.
Speaker 1So He definitely has, and that's the intention right to focus on his legacy.
Speaker 3Yeah, yeah, but I feel like this book's going to push the field forward. You know, i'm honestly interested in it because it's an area where I feel like I'm a complete idiot I don't know anything about. You know, data governance, i think, especially on the level that you guys do right. So I was just interested to you know, selfishly, to learn, you know, from you guys, i think, in a book that will hopefully help push the field forward, right, and that's you know, just, it would have been a privilege to work with you too, but you know we're working together on it, so it's still going to. Så det blir fortsatt fantastisk, men ja resten av deg.
Speaker 1Jason, det var kraftig, ja resten av deg, men vi fortsetter å jobbe på boken. Vi fortsetter å jobbe på det. Det bør være en legacy.
Speaker 3Ja, jeg tror det har lagt et fly i oss. Det må ikke bare være godt det må være fantastisk. Det er det vi ønsker, jason, og det er det vi ønsker, jason. Det er det vi ønsker for verden, for publikum. den nye publiseringen som jeg skal annonsere neste måned. Ideen er at jeg vil gi folk som Winfrey, jason og andre at de kan lide, å lide de beste bøkene ikke bare bøkene, men bøkene som vil forandre industrien og forandre industrien og støtte forhånden.
Speaker 3Det kommer ikke mange av dem, men bøkene kommer ut og alle er greie. Jeg er sikker på at det kommer. La oss prøve å slutte på en litt høy nød.
Speaker 1Vi har snakket om så mye i den siste uka. Vi har snakket om datagoverning, datamodeling, datamanager, datainjering. Vi Vi har snakket om datamodeling. Vi har snakket om datanærings, datanærings. Vi har snakket om datasjons. Kan vi komme til hele fjellet? Wow, ja, fantastisk. Er det noe i det særlige som du tror at læreren bør ta bort fra denne samtalen? Noe som du tror jeg har en kall til aksjon her.
Speaker 3Du vet det er interessant. Jeg skrev en artikkel om the weekend and we're recording this on the 2nd of December. So over the weekend I wrote about one of the biggest issues that I see in the industry, which is the knowledge and skills gap, right Where I think we have a lot of amazing tools, probably a lot of amazing frameworks out there, but I don't feel like we're at we're not using these tools to the fullest potential. I don't think we're operating at the fullest potential we can as practitioners, as leaders, and som vi kan som praktisjoner, som ledere og som en industri i stedet. Så jeg håper at jeg vil gjøre personlig min ting er koldt aksjon for lyttere. Gå og lese klassikkene, gå tilbake og besøk mange av de kanoniske tingene som hjelper å bygge dette området. Hvis du er i data-verkstav, gå og lese Building the Data Warehouse by Bill Inman. You know that's the book that started it all. You know Ralph Kimball's Building the Data Warehouse Toolkit. You know Data Vault, data Governance Books, even DEMA. Go read that. Understand the context of where we come from as a field. Don't just take things second hand and say, oh yeah, i guess that's all I need to know. I mean, there's a lot to know in this field. So invest in your time, invest in your skills and, i think, pay tribute to those who came before you. I'm actually going to be spending this week with Bill Inman over at his house, so it's going to be a lot of fun just to hang out with him. And you know, we're very close friends and I just think that, like you know, getting to know somebody like that is awesome.
Speaker 3Å kjenne noen slik er fantastisk. Fordi jeg kan kjenne hele området. Jeg kan ta et stort argument. Han er en utfordring for området, så han hjelper å skrive det. Det er kult. Men når du begynner å forstå konteksten av hvor alt kom fra, så har du en dypere oppfølging for skilene og din kjennelse for hvordan du anbefaler det Og du forstår også the skills and your knowledge and how to apply it And you also realize how much you don't know. I think it's kind of overstated enough. I think a lot of us feel like we know a lot of things. There's so much more to learn. But take the time, put that investment in. That's my call to action.
Speaker 1You're speaking to the heart of someone who studied history.
Speaker 3Definitely.
Speaker 1Thank you so much for the conversation Yeah and thanks for having me.
Speaker 3Ja, takk for konversasjonen. Takk for å ha meg på ditt helsespesial. Det var supercoolt, ha det bra.