Listen to this episode:
About this episode
In this episode of Behind the Data, host Matthew Stibbe talks with James Serra, Data and AI architect at Microsoft and author of Deciphering Data Architectures. James explains why the hardest part of a data project is rarely the technology, but getting a room full of people to agree on what the numbers actually mean. He traces his path from COBOL programmer at the Nevada Test Site, through a fantasy football software business that taught him performance tuning, to advising Microsoft customers on cloud data architecture. The conversation covers what it takes to get data AI ready, why a confidently wrong bot destroys end-user trust faster than a wrong report ever could, MCP servers as the USB port of data, and whether self-service BI has finally arrived.
Meet the guest: James Serra
James Serra is a data and AI architect at Microsoft, where he has spent over a decade running architecture design sessions with customers and teaching them how to build data warehouse-style solutions in the cloud. His career spans more than 40 years, beginning as a COBOL programmer at the Nevada Test Site in the 80s, before OS/2 and SQL Server 1.0 pulled him permanently toward data. Along the way, he has worked as a DBA and performance tuning specialist, led early data warehousing projects, and consulted for companies large and small. He also built and later sold a fantasy football software business that ran real-time scoring for tens of thousands of users. He is the author of Deciphering Data Architectures and blogs at jamesserra.com.
Key takeaways
- The hardest part of a data project is agreeing what the data means. Customers want a report, a dashboard or a bot, then start arguing in the room about what should be in it, what the numbers mean and who owns the data. Sometimes they have never had that conversation before.
- Getting data "AI ready" is an extra layer of work, not a shortcut past it. Beyond bronze, silver, and gold, there's another step: expanding acronyms, adding hints about what fields really mean, telling the bot that when someone says "person" they mean "customer". Reports run fine on presentation-ready data. A bot needs more.
- A confidently wrong bot damages trust faster than a wrong report. Nobody validates a bot's answer the way they would validate a dashboard before it ships, and you can't predict the questions people will ask. Gen AI is non-deterministic by definition, so the same question can return a different answer.
- Lose the end user's trust on day one, and you will never get it back. If the first report someone runs shows a customer twice, or a birth date in the future, the project is damaged. Involve end users in validating the data up front, and they are far more forgiving when something does go wrong.
- MCP servers are the USB port of data. One interface replaces a pile of bespoke API calls, so a bot can reach almost any data source or product quickly. That accelerates building the solution. It does nothing to clean the data underneath.
Chapters
00:00 Introduction to James Serra and his expertise
02:04 The importance of shared understanding in data projects
03:49 Using Gen AI and the challenges of data quality
06:54 The role of MCP servers and data interfaces
09:51 James Serra's career journey in data engineering
13:07 The motivation behind writing Deciphering Data Architectures
15:51 The hype and realities of data mesh architecture
19:53 The critical need for data cleaning and validation
24:09 AI as a layer of data maturity and its implications
28:00 The future of self-service BI and data governance
30:10 Final thoughts: Avoiding shortcuts and trusting the process
Episode transcript
Matthew Stibbe (00:01) Hello, welcome to Behind the Data with CloverDX. I'm Matthew Stibbe, your host, and today's guest is James Serra, who is a data and AI architect at Microsoft and author of Deciphering Data Architectures. Great to have you on the show, James.
James Serra (00:16) Yeah, great to be here. I'm excited about our conversation.
Matthew Stibbe (00:19) Me too. And we've had a nice chat before and I was admiring all of your historical computer software behind you there. And I definitely was drawn to Civilization, which is responsible for a sort of blackout of my life of about two months. So apart from old, old computer software, what are you geeking out about at the moment?
James Serra (00:43) Well, there's a lot of stuff to geek out about with technology moving so fast, and especially being part of a technology company, there's so much to keep up with and you never quite catch up. But of course the big thing is AI, Gen AI. And I work with a lot of customers and they're all talking about Gen AI and how to use it on their data. So that's really top of mind with everybody.
Matthew Stibbe (01:05) And you've written that the problem isn't usually a lack of data, it's a lack of shared meaning, a shared understanding. Where does that sort of show up in a business?
James Serra (01:18) Yeah, it's interesting too. Sometimes I would do architect design sessions with customers and they would come in and they describe what they're trying to... they need help building a solution using some data warehouse in the cloud on that. Sometimes we work backwards from a report or a dashboard.
And of course now Gen AI, they want to have some kind of bot where they can ask questions of that. And they need to take all the data and go through the process of cleaning it and joining and transforming it and mastering and aggregating it and do all that stuff in there. And it's kind of interesting when they all get in a room and they're talking about a report and they start arguing over what should be in the report, what do the numbers mean on there, what's most important. They've sometimes never had that discussion before on there.
And now with the Gen AI use cases they come in and they say, we want to use LLMs, Gen AI or bots on top of our data, but sometimes they don't quite know what the correct answer is. And so you have this challenge internally where they have to get the correct answer or figure out the importance of that. Now then they get into who owns the data, which comes up with another argument, and then are you properly cleaning the data? And then there's another argument there, on that. So there's a lot of stuff you gotta get through sometimes in order to get to that point where you're even building a solution and trying to create that report, dashboard or Gen AI model.
Matthew Stibbe (02:43) Do you think when people try and put something like Fabric data agent over the top of a database, it increases the requirement for getting that shared understanding and that sort of data hygiene right?
James Serra (02:59) Yeah, for sure. And I talk a lot with customers about getting data AI ready on there. So when you're using a product like Fabric data agent, which is essentially just putting a bot on top of structured and unstructured data, when it comes to the structured data on there, can it interpret it correctly? Because the bot will assume a lot of things.
For example, you can have acronyms and it can assume what an acronym means completely wrong. So you may want to go through your data and change acronyms to the full names on there. You may want to give it hints and say if somebody's talking about a person, they're really talking about a customer, and do all these things so the accuracy is higher. Because if you've used ChatGPT or Copilot or any of those others, you realize it can make a lot of mistakes. It has a little thing at the bottom too. Warning, there could be a lot of mistakes in here. And so the challenge is if you're asking that of data, you may not even know that the answer is not even correct because nobody's there to validate it like they would validate a report and a dashboard beforehand. So there's this really interesting situation where the bot is another front end to the data to ask questions in plain English, as opposed to already having, knowing the questions people are going to ask and put them in a report or dashboard. Now it's great because you give them an opportunity to dig in more about the data.
And ask more questions about it. That doesn't come out of a report and a dashboard. But there's also a big risk that the data could come back wrong. The answer could come back wrong. So you gotta really spend a lot of time prepping the data. And I would say reports and dashboards still have plenty of use, especially if the report is really important. It's financial numbers that are going to Wall Street, life and death, or just something that you can't be wrong. You still want your reports and dashboards, but you may want to dig in more with a bot in front of that, Gen AI, and ask deeper questions or different questions of the data. But with the knowledge that you always question it, that this data could be wrong. And if it's really important you either put it on the reports or dashboards or do a lot of checking when you get the answer back. But the problem is even with Gen AI and as correct as you make the data, the Gen AI by definition is non-deterministic. You can ask the same question and get a different answer on there. So you always gotta be aware of that.
Matthew Stibbe (05:16) Yes. And I think having AI systems that have a little bit more understanding of the structure of data and interrogate data in a structured way rather than as a text file, I think is really important. I don't think that putting "do not invent data" into your prompt is enough, right? You've compared MCPs and things that sort of interface with data as like USB cables, you can kind of connect things to other things. What does that change for people who are actually building and maintaining data pipelines?
James Serra (06:00) Yeah, sure. With an MCP server, that's why I say it's like USB back in the day, which I remember you'd have a computer and it'd have like eight different ports to connect peripherals to because there were eight different standards, if you want to call them standards on that. And then USB came out and it was a way to tell all the manufacturers to build products that use the USB port and the desktop computer makers to make available USB ports.
And so everybody was talking with the same interface. And MCP servers are the same thing. It's giving a front end for people to ask questions. That's it, everybody's using the same front end. So I can create a bot. And if I want to use an MCP server on any type of data or product, in the old days you would make different API calls. Now you can have this MCP server available and so I don't have to worry about the interface now. And that opens up a whole world because along with the... it's called skills, it's sort of a configuration or definition of what this data means. You can now easily create a bot, a front end to all this data or text or whatever's behind it.
The MCP server on there. So it makes it a lot easier to build a solution more quickly on that. And so now we're seeing, I see a lot of customers who are incorporating tons of different text and data. And there's an MCP server on some social media site, and I can just call that and pull the data in really easy. So you're able to greatly accelerate building the solution using more and more different types of data and text.
Matthew Stibbe (07:44) I think your mention of old interfaces, RS-232 and Centronics come to mind. And if you have one of these, old Macs have a SCSI thing and you have SCSI terminators, all that stuff. Takes me way back to the 90s. And I'd love to talk a little bit about your career, which, like mine, goes back into the mists of prehistory. Tell me a little bit about how you got into data engineering.
James Serra (08:09) Yeah, sure. I won't go into detail about... I started as a COBOL programmer back in the 80s for the Nevada Test Site and had always had a passion for programming language. I knew in high school that this is my career. It's gonna be coding. We called them coders and programmers back then, now they call them engineers. And I still remember back in '89 when I was working as a COBOL programmer, they brought in this computer with an operating system called OS/2 and it had this thing called SQL Server 1.0 on it. And it was a database. And I had been using mainframe and mainframe databases, but this was a whole different animal and it was just so much easier to use. And I kind of fell in love with data. And then since then, whenever I was coding, it was almost always against a database. And then over time I got more and more interested in the data. And at one job I decided I wanted to be a DBA. And so then got into maintaining and performance and all that. And did that for a number of years. And then came this idea of data warehousing back 20 years ago or more.
And I didn't know anything about data warehousing, so I started reading all the books and I was like, this is awesome. And I decided I want to get into data warehousing. So we did a project that was taking operational data and creating analytical data in this warehouse and making it available to end users. And that exploded. And that led into other careers where I was... and more into data when I had fantasy football websites and I learned about performance tuning and whatnot.
And that continued my fascination with data. And then after that, getting involved as a consultant, helping customers build data warehousing solutions, and then eventually joining Microsoft 12, 13 years ago, where I talked to customers and educate them about building data warehouse-like solutions in the cloud.
Matthew Stibbe (10:15) And like all great people, somewhere you were involved a little bit in computer games, or at least I think it was fantasy football leagues in your case. Can you tell us a little bit about that?
James Serra (10:25) Yeah. And back there I also have some of the early computer games on the Apple, like Tony La Russa and Earl Weaver Baseball. And my friends used to get together and we'd run baseball leagues and it was data related. You get all the stats and I love stats and you decide your lineups based on the stats and you keep track of the stats and all these old computer games that were fascinating at the time, but it was little dots on a green screen and that was the extent of the graphics in there. And they kept getting better and better. And I have the progression over the years of the better graphics in there. Of course nowadays you can't even tell if you're watching a game or real TV. It's amazing on there. But that's how I got involved with the early games and then started to enjoy fantasy football, and fantasy baseball became popular in the late 80s, early 90s in there. And I decided, as I was a consultant and I was always a commissioner of my fantasy football league in there, and I said, we go to the draft and you have these old magazines that you would use back in the day before the internet and you would use that to draft players. And I said, well I'm gonna use an Excel spreadsheet and put all my rankings in there. And I did that and then I said, well, I'm a coder. Why don't I write software for this in Visual Basic? So I wrote a software program and it helped me not only draft the best players, but keep track of everybody else being the commissioner on that. And it made everybody's life easier. And then I said, maybe I should try to sell this. People would be interested. I put a little ad in the Fantasy Football magazine and I don't know, wasn't expecting any sales and I got like a hundred and I was ecstatic. And then people said, hey, can you write software that runs the league? Because there was stuff out there in DOS, but it wasn't that good. And Windows was coming out. And I said, yeah, I can write stuff. So I wrote commissioner software and started selling it from magazines. And my wife has stories of us just sitting around copying disks and printing manuals and shipping things out. And you gotta send updates through the mail. And then this thing called the internet came around and I was like, ooh, this would be really good for fantasy football.
And so I rewrote all the software to work on the internet and run fantasy football sites and your drafts on the internet. And that started me... and as a consultant, I said, well, I made enough money, I can do this for the next year. We'll see what happens. And then that process repeated for like about 10 years. And I kept doing it until... and got involved in real-time scoring. But that really helped me to become a DBA, especially focused on performance tuning with real-time scoring and whatnot.
And there're having tens of thousands of people on the site expecting to get their scores updated every few seconds. And if it went a minute, you would get these angry emails calling you all sorts of names. And I have stories about where they got really bad with people threatening me because they didn't see their scores for 20 minutes and whatnot in there. Eventually I got tired of that and sold the company and got back into the world of being a DBA and getting more involved with data warehousing and working for various different companies, small, large, consulting. I've been doing it for 40 years and then eventually going to Microsoft.
Matthew Stibbe (13:45) And you wrote this book that's just behind you here, Deciphering Data Architectures. Tell me a little bit about what you were trying to solve with that book. What prompted that?
James Serra (13:57) Yeah, sure. What spurred me on is about five years ago there was a lot of hype about this new type of architecture, data architecture called data mesh. And before that we talked about modern data warehouse, data fabric, a data lakehouse, and then this data mesh came out and huge amount of hype, everybody was talking about it. And I read the blog and the book and I said, well wait a minute, this sounds really great in theory but I've been doing this for a long time. They're not talking about the challenges with the data mesh. And I remember reaching out to other old timers like me and saying, am I missing something here, and they said, no, you're spot on. And I said, I really need to write some blogs about this. And then it progressed to maybe I should write a book about it, because I was explaining to customers what a data mesh is. They'd come to me and say, we want to build a data mesh. And I go, do you really know what it is? And they go, I'm not sure. And I would explain it and they go, that's not at all what we thought about it. So I started building this deck, but then I found when I was talking about the architectures, and I talk about things like data governance and cleaning the data and ELT versus ETL and mastering data, and customers would say wait a minute, I don't know what those concepts are. So I would start explaining those concepts before they jumped into architecture. And I said, you know what, this would be good in the book. It's sort of all my life's work dumped into there. It was a complete brain dump. And I don't talk about products, it's all about concepts and architectures that have been around forever. And even data mesh is a combination of other various concepts that is just repackaged differently on there. But I remember those same problems we had when we talked about data marts and Kimball versus Inmon and all these arguments about what's the best approach in there, and where I saw them fail and that. And data mesh was talking about the same thing, but not talking about all the trade-offs that come along with it.
James Serra (15:51) For example, data mesh requires a whole big organizational change. And I said, you gotta know that people don't like change. So right off the bat, you're gonna have a lot of challenges with the data mesh approach in there. And so I said, let me just put all this in the book. And that's where it came. And it took writing every day for a year. And it was a great satisfaction. I wish I could say I made a ton of money and have a bunch of Lamborghinis in the garage, but they tell you up front, you don't make a lot, you don't make any money writing a book. You do it just for your own self-fulfillment and to build your brand. And so I did it for that. And it's been received very well. And I often tell customers, hey, a lot of what I'm gonna talk about is in my book, and I'll give them a copy of it so they can learn more. And that's the whole idea, is I just wanna educate people so they know more. When they're going to build a solution, they understand the concepts and the different approaches, and they're more educated and less chance for failure when they're building a solution because they understand the concepts better.
Matthew Stibbe (16:50) I think this is something we were talking about earlier, where you were talking to the CEO of some business about some data project, and he was like, can't we just put AI on top of it and be done with it? Is there a temptation perhaps from people who don't understand the technicalities to try and short circuit some of this stuff? They probably would say shortcut.
James Serra (17:15) Yeah, and it's sort of junk in, junk out, that term in there. If you have junk data and you put an AI bot in front of it, it's gonna be even worse than reports and dashboards because the AI is gonna go and make all these assumptions and incorrectly join data and come up with some crazy wild answers. Yeah, the LLMs are getting better, but it's only as good as the data that you've cleaned and mastered and joined and aggregated. And maybe you use a product that you can send a lot of hints to about the data along with the customer's question on there. And that's why I tell customers you have to get data AI ready and it's gonna take just as long, if not longer, than if you put reports and dashboards on that. Yeah, we have all these great tools and accelerators, but you don't shortcut the process. And I've always had a challenge with customers thinking "our data is pretty clean". And then I go, you know what? I guarantee I'm gonna dig into the details, because usually you're pulling all this source data over into a warehouse or a lakehouse.
James Serra (18:13) And as you pull it over, you look at the data and you're like, this is bad and that. And you go to the customer and you go, you have birth dates that are in the future, or people are 200 years old, and they're like, I didn't realize that. And it's because the front end required a person to put a date in there, so they put in anything. So they have all these gaps in there. And so you gotta now clean the data. You can fill the gaps, but what about all the data that's been wrong on there? So there's a lot that comes up with cleaning.
Matthew Stibbe (18:38) You must see the inside of more data estates in your role than most people see in the whole of their career. What are the most common failure modes in thinking about their data structure? I mean, data input you've mentioned already and controlling that, for example.
James Serra (18:58) Yeah, the biggest mistakes or failures of projects is not properly cleaning it, not spending enough time in your project plan to clean the data on that. There's a lot of performance problems that can come out because they may need to... it could be simple indexing in your databases or you got aggregated data. And it's not understanding all the different approaches you can take in order to get the performance. And the big part of that, if the performance or especially the data is wrong, and like mastering the data, you could have two customers that should be joined, their data, but you have them separate because maybe their names are misspelled or there's a junior in there. The issue I see is if you go and build a solution and then you give it to the end user and they run that report the first time and then go, well, why is this data wrong? Why is this person here twice? You lost their trust right from the get-go. And to get it back is nearly impossible. So you have to spend a lot of time up front cleaning data, working with the end user to validate it, making them feel like they're part of the project. So they have some input and they're more lenient if things go wrong. But keeping that data accuracy is so critical. Now extrapolate that to giving them some bot, some front end where they're asking questions where there's even more of a chance of data being wrong. And you spend all the time and say, look, just go ask any question, and they go and ask a question and the data is completely wrong.
Matthew Stibbe (20:20) And the bot gives you the most confident answer. It sounds like it totally knows what it's talking about.
James Serra (20:24) Right. Confidently wrong. And they may not even know it's wrong. Or you're testing it and you go, it sounds right, I don't know how to validate this. Because you don't know what questions they're gonna ask, so it can go all over the place. It's hard to validate it on that. So that's where there's a lot of time spent up front to make sure the data's accurate.
Matthew Stibbe (20:42) How do you go about selling this unglamorous cleanup work? How do you get a CFO excited about it?
James Serra (20:50) I reiterate that story about the end user's trust in that, and the idea that you're trying to build a solution that's gonna make that end user spend less time having to put all the data together. You're gonna make them look better to their managers, because now they can go with all these cool reports and dashboards and they can slice and dice and they may find ways of saving costs that they never thought was possible because you introduced some dashboard or some chat that they could use to dig into the details on that. So that's the payoff. There's a lot of work up front and sometimes you see people get deflated when you quickly create a demo, especially now with things like GitHub Copilot.
And they go, look, it's all working. It's production ready. I go, no, it's just a demo. Well, okay, just turn it into production. How long is that gonna take? A couple days? And you go, okay. Let me explain the process that's gotta go through to get something production ready.
Matthew Stibbe (21:58) Yeah, it's dangerous. We did an AI-assisted prototype of something the other day and it wasn't in any way the final thing. We were going to do quite a lot of coding and development work. But the AI did such a good job of producing some interactive bit of web functionality. And the client went, you just did that with AI and it took you a couple of hours. So what you are proposing to do is inherently trivial. We're like, no, no, no, no.
Matthew Stibbe (22:28) And it reminded me of a story that when I was really young and we had dot matrix printers, you remember those, MX-80 dot matrix printers, right? So I had an Apple ImageWriter and was talking to a graphic designer who had bought a laser printer and they were doing all their mockups to their clients, printed out on the laser printer, and nobody had seen this before and it looked perfect.
And then when they gave them the mockup and then they gave them the final version, and they'd done a lot of tweaking and designing and finessing and finalizing and thinking about it. But the physical quality of the two, the mockup on the laser printer and the mockup of the, sorry, the final version, they looked the same. They looked the same. And so the client couldn't see that any work had been done between the first version and the final version. What are we paying you for? So what they did was they started giving people the dot matrix printout, here's your first draft, and then when the finished thing came, they would give them the laser printed version so people could sort of tangibly feel the improvement. It's the opposite of your building trust story. Let's show them something crappy first and then we'll show them something good. Anyway, I don't know. I wonder if data, sort of the levels of data maturity are interesting. And you've talked about reactive, informative, predictive, transformative. And I think that's a nice ladder. Is AI like a fifth step or does it just really mean that you've got to do one, two, three, four right? Do you see what I mean? Is there some extra step of maturity that is AI maturity after those four?
James Serra (24:09) Yeah, I would say it's both. You still have the four layers of maturity, but now you have another layer. Maybe you can say it's part of the last step, but I'd like to break it out. And I say to myself, if I'm gonna update my book, I'm gonna start talking about adding that extra layer to get data AI ready, a whole chapter just on that, because it is extra work on there. Because usually you're gonna do two paths too. You're gonna get the data, you know, people talking about architecture, your bronze, silver, gold, and gold's really the layer where it's production ready. It's presentation ready, I should say. And that traditionally has been fine to build reports and dashboards off that, but now I would go from presentation ready to take that data and make it AI ready. So it may be changing the acronyms to something else, but having another layer that the reports don't need because they're running fine, but the AI may need to make it more accurate. And along with that data may be a bunch of hints about how to use the data properly in there. So that's why I like to think of it as a whole other layer that you're going to use, that if you then say your solution's going to take longer because now you have this fifth layer.
Matthew Stibbe (25:20) And I think this points to something that's been going on like a lot of things in IT, always about to be done, never quite reached, which is self-service business intelligence. And it's been the promise since pivot tables and even before that. Why have we never got there? Or have we got there now with good data and AI?
James Serra (25:47) Yeah, and I would say that to customers, that's the ultimate goal, is you want to build an architecture out, IT building architecture, to make the data presentation ready. So the end user can do the self-service BI. They can do the reports and dashboards or have a front-end bot asking questions. So they're not asking IT to do it. And when I was in IT, man, the one thing I hated was end users saying, hey, can you build those reports? And I go, I don't want to build reports. And I don't even know the data and understand it. Why am I doing it? Because the end user was like, well, the data's not in a format that we can build our own reports. We don't understand. You have all these tables and these joins. Well, we've come a long way. And if you look at in the Microsoft world or any of the products, they have semantic layers where IT can build the solution, the model, and have all those joins and present it to the end user so they can just start clicking and dragging the fields on a report and not have to think about how it's all joined on that. So we've gotten somewhat there and the tools have made it a lot easier. And now, for I don't know if it's good or better or worse, an end user can go to a lot of these tools and just say, create me a report, in Copilot in the Microsoft world. And it just builds the report.
They don't even have to know how to join things. It'll build them, but does it understand correctly the joins? And that's where again you can have this issue where they build something and they think it's right and it's completely off the wall on that. So your goal should always be self-service BI and IT, but the reality is you may accomplish some of that, but they still may come back because they find problems with it, or at the very least, IT's gotta monitor what the end users are doing to say, well, you know, you created this report or you got this answer, that's completely wrong. Did you know that? Because it goes back to they may not realize the answer they have is incorrect. So you have to have these checks and balances, auditing in place. And a lot of companies don't do that. They just give the tool and they assume that the end user knows the answer is correct. Or worse, they don't give the tool and then the user uses it anyway to generate the reports in there. And so you have to have this governance and this monitoring in place to make sure that if they are doing self-service BI, that they're getting the right answers.
Matthew Stibbe (28:10) Yes. I've often, I mean I'm a 20-year copywriter, which is a job that really isn't a thing anymore because of AI, but I've always said that writing is about half research, about a third editing, and about a sixth actually typing words, right? Most people think about writing, you just sit there and you're writing stuff, but writing isn't about writing, it's about researching, planning and editing.
And I think it's the same with data engineering. This is my hypothesis. You need to allocate time for testing and you need to allocate time for prepping and planning. Anyway, there you go. Matthew's theory of writing as applied to data engineering. We're almost out of time, James. And I'd just like to ask one final question before we wrap up. After 30, 40 years in the industry, what is the one thing you would like the industry to stop doing?
James Serra (29:10) Yeah, having done it 40, say 41 years now on that, it's the lack of realizing, especially when you get into data and data warehousing solutions, the time it takes and there's no shortcut process. You can't go in there to AI and say just go and take all this data and create all these reports and dashboards and self-service BI on that. There's a lot of work that goes on behind the scenes.
AI, the technology has accelerated building solutions, but you've still gotta go through all the steps. Maybe you can get through them quicker, but in the end, there's no shortcut to cleaning the data. Don't go to AI and just say clean all my data and think it's gonna be done with it on that. And sometimes the solution is gonna take even longer because in the end it's gonna be a better solution, because you're gonna give them more ways to use the data through reports, dashboards, and now front-end bots to it.
So there'll be a lot more features, it'll be a lot more useful, but it's gonna be more work to get there. And the customers and the projects, the solutions I see failing, is when people don't spend enough time in those steps and that. And so doing it 40 years, the same concepts and principles that I talked about in my book apply. You still gotta go through all those on that. And it's the people who think they can shortcut that process are going to build a solution that is going to fail, because the data is not going to be accurate and you're going to lose the trust of the end users and it's going to be hard to get that back.
Matthew Stibbe (30:48) Don't skip the hard work, basically. Yeah, fantastic. Well, fascinating conversation and also very enjoyable to meet a fellow sort of computer software geek. That brings us to the end of the conversation, James. And if you want to find James online, he's at jamesserra.com and his book is Deciphering Data Architectures, available at all good booksellers, as we say over here in England.
Matthew Stibbe (31:18) James, thank you so much for being on the show.
James Serra (31:22) Yeah, my pleasure.
Matthew Stibbe (31:23) And that brings this episode to a close. If you'd like to learn more about practical data insights or CloverDX, please visit cloverdx.com/behind-the-data. Thank you very much for listening to this episode. And for now, goodbye.
Resources
- Deciphering Data Architectures — James Serra's book on choosing between the modern data warehouse, data fabric, data lakehouse and data mesh
- jamesserra.com — James's blog, where he writes about data architecture and AI readiness
- James Serra on LinkedIn
- Model Context Protocol — the standard interface James compares to the arrival of USB
- Data Mesh— the architecture whose that prompted James to write his book
Related content
More from Behind the Data
-
Ethics, critical thinking and disambiguation in data with James Randall, CTO of Blackdot Solutions
-
Building high-volume, high-stakes, real-time data pipelines with Yossi Leon, Chief Technology Officer at FIA Tech
Share
