5 Key Factors to Consider in the MDM Solution “Build vs. Buy” Debate

Speaker 1

Good morning, good afternoon, or good evening, everyone. Thank you so much for joining today's session, the five key factors to consider in the MDM solution built versus by debate. Before we begin, I'd like to cover a few housekeeping items really quickly. So closed captioning is available.

Hover over the virtual stage and click the CC button located at the bottom of your screen. We also encourage you to submit your questions leveraging the q and a tab and the engagement panel on your right, and we'll do our best to answer questions at the end of the presentation. And if we're unable to get to your question, we'll follow-up with you directly. We've also added some additional resources, are available in the docs tab in the engagement panel on your right.

So there, you can find some additional related content.

Today's webinar will also be available on demand after we wrap up, and it will be sent to you directly via email.

So today, we are joined by two leaders who bring deep expertise in enterprise data management and AI.

Kicking us off is Tamer's chief executive officer, Anthony Dayton, who brings decades of experience driving innovation at the intersection of data and artificial intelligence. Alongside him is Nick Laferriere, Tamer's Tamer's vice president of engineering and one of the key architects behind the Tamer platform. We're delighted to have them both with us today. So welcome, and over to Anthony.

Speaker 2

Alright. Thanks a lot, Morgan, for that introduction. Excited to jump in here and share with everyone. Over the course of this webinar, we're gonna do sort of in a two sort of pieces, if you will.

First, we'll set a bit of context for the ongoing debate that I think is happening, and it's changing very, very rapidly. Things are are shifting around literally week to week. But then we'll spend bit more energy digging into some of the details. And as the title of the webinar suggests, we'll leave you with five key ideas to think about when you think about this buy versus build debate.

But before we get into the the details, I think it is worth sort of noting that where we sort of sit in the arc of the history here And it is reasonable to say that things have really changed significantly, and they've changed significantly in the last six months, the last twelve months, and, you know, even over the course of the last two years.

You know, if you roll the clock back more than two years ago, I think the buy versus build debate within the enterprise was, you know, kind of a solved problem. Most organizations generally went to purchase packaged software. The concept being that if there was a product on the market that did a task, it was almost certainly a better path to use package out of the off the off the shelf software than it was to try to roll your own.

And now, today, we have these coding agents. I'll often pick on Claude code because it's sort of top of mind, but there's Copilot and Codex and and others that you can and anyone literally on this call can install Cloud Code.

You can sign up for even for the twenty dollars a month plan, although in fairness, you probably will end up paying more than that. But in any case, you're gonna you'll you'll pay relatively little amount of money. And you can ask the coding agent to build you a piece of software that does a bunch of stuff. And you can do this as an individual or software teams, and Nick will talk about this in a bit, but, you know, software teams are using this stuff in fury. So you can you can have large groups of people and augment those teams with these coding agents. And so I think it's a very reasonable question to say something that might have taken you a large team of people months and months of building and testing and shipping can be done in a few days.

And one obvious place to think about that is in the context of master data management. So when we dig into the details, we'll spend a little bit of energy thinking about is MDM really a place where you wanna think about a buy strategy, or a build strategy.

But before we do that, let's do a little poll and get some feedback from you, the audience. And I will stop sharing so that the poll shows up.

There you on the on the right, you will see the the sort of different options. One little mistake that I made in testing this is not to hit the submit button. So make sure when you pick your answer that you also hit the submit button so that it gets that it actually registers in the system, not just, you know, going in as a as a selection, but it's actually as submitting.

And we'll give it a few seconds for folks to vote. And, you know, the the part of what I'm trying to do here from a polling perspective is understand where you stand as an organization in terms of your use of these coding agents.

It looks like there's and this is actually relatively consistent with what we see generally, is that most organizations are trying, testing, and working with this stuff.

There's relatively few that are doing almost nothing, but there's also relatively few that are using it to write or or engage with the bulk of the code that they write as an organization.

So, you know, this is a a way what I would have expected.

And and just, you know, this is the the the there's people are trying stuff. They're testing it. They're using it, but they haven't, again, begun to use it with So super helpful. And then, actually, Morgan, I think you need to stop sharing in order for me to there we go. Thanks. Start sharing.

Excellent. So, you know, with that as a backdrop, that sort of raises this question of of buy versus build. So let's dig into some of the details of this.

The first and most important thing to take away, and if you don't remember anything else from this presentation, just remember this one idea, which is I think in the past, this used to be a buy versus build choice that organizations really and often, we would even hear people going through an analysis of buy or build.

There really is a buy and build option. It's really the question to be asked is, what am I going to build? What is custom to me? And what am I gonna use off the shelf? What is available in the market that I can consume and use? So think about this as a buy and build, not a buy or build, and and that, really, these things are not mutually exclusive.

And so that, of course, begs the question, what should I buy and what should I build? How do I think about differentiating between those? And I I think, again, historically, we would have thought about this holistically. We would have said, here's the business problem I have. I'm gonna buy a tool for that or I'm gonna build everything from scratch.

I think the mental model to have today is thinking about this as different layers of the stack. So there are a whole set of capabilities which are foundational, what we might call foundational infrastructure. These are the underlying infrastructure that we're building from. You can think of this as the plumbing that everything you're gonna build sits on top of.

And these are things like databases, CRM applications, security frameworks, MDM platforms, these sorts of things. And these are the kinds of systems and capabilities which and we'll get into the the detail of this that you can build from.

And then there's a set of capabilities which are business specific. So these are things like agents and workflows and UI experiences that are very unique and bespoke to the business problem or company that you are. And so the way I the mental model I would have here is spend your resources to build the pieces which are differentiating and business specific on top of a foundation that you can buy.

And so that gives you, in a way, the best of both worlds because you can build from something to the specific requirements that you have. So let me put this into a little bit more stark relief for you. And this is a thought experiment that I went through probably six months ago now.

And I I thought to myself, imagine if I wanted to build a CRM system. So imagine we have a software company. We sell software. We wanna have a system for tracking accounts and opportunities.

Should we buy that, or should we build that? And if I was gonna build it, what would I build versus what would I buy?

And yeah. So let's take a look at that. So in that thought experiment, imagine if you were to go ask you know, fire up Claude Code and literally just say, hey, Claude. Build me our CRM system. I'm a software company. I sell to large enterprises.

Go.

There's a lot that Claude could build in that scenario. Yeah. They might build a lot of that application logic. So we might have a very specific sales process that we wanna build into that. We might think about lead scoring systems as the slide indicates commissions, but there's a lot of rules that are specific to us.

We might have different words and names to describe the types of companies and the attributes we care about. So the schema and things like that would be pretty specific. We might want a very specific UI for our users.

And we would think about, you know, a lot of the glue code that brings all of this together. That's all stuff Claude would be really good at doing. But what Claude wouldn't do, for example, is build a database. So if you're building a CRM system from scratch, it would even Claude wouldn't say, okay.

Well, to build a CRM system, I need a database. So I'm gonna start from first principles. I'm gonna build a database and build up from that. No.

It would just go use an off the shelf database, and, you know, wire in on top of that. Other examples, you wouldn't, from first principles, build an authentication system. That would be a terrible idea. Probability that you would build a a, you know, an authentication system that wasn't very secured, very high.

You wouldn't build things like email and payment systems. Again, the opportunity for fraud or for bounce in the example of email, bounced emails. There's a lot of sophistication on the covers there, and there are really good systems out there for just plugging into that that sort of system. So and I would encourage you to even consider doing this.

Grab Codex or Clog code and just ask it to build a CRM system. You will see that it will do very much the same things that I just described here. So I think that's a good thought experiment and a good way to start the the journey of, like, how do I think about these different things?

So when does doing it yourself makes makes sense? So and before we dig into the the details of exactly the five things to consider, what's the sort of framework for thinking about? So the the way I would think about this, and Nick, we should chime in as well here, but this where you have small amounts of data, you know, it's a kind of prototype level thing where you have a simple or singular source of data.

If you're if you're thinking about connecting this or this sits on a on a particular business process with one kind of user or one kind of system and where you're thinking about a you know, in the context of MDM where you might think about where you have a bunch of expertise on the MDM prob problem. So here is the sort of the simplest case, like a small amount of data on a single source with with a singular consumer of the data and you have an experienced team.

You know, a a simple MDM system probably makes sense. But, Nick, any thoughts?

Speaker 3

Yeah. So not to steal too much from the later slides kind of going into it. But there's definitely just like BI kinda had a revolution where people could self-service it, doing some queries on top of, an Excel. Amazing with Cloud.

Here's an Excel. Go do it. There's still the common limitations of having it then write back and manipulate data and do the next steps, it falls over. But when you just have something small enough, fits into an Excel sheet, you can give it to Claude, actually a couple ad hoc things, it does really good.

When you start wanting to make things more repeatable and build on top of it and not just have it be something that I have this one peculiar question I want answered, you start to see, like that's when you start getting into the master data management style approaches to problems so you can make things more repeatable. And I think a lot of this kinda dovetails hand in hand with if you you're on this webinar, you've probably seen some of our previous stuff, or I'm sure you've had emails about the MDM journey in your inbox, of, like, kinda where you are in that. And, like, one of the things to think about is that there's very much for most software solutions, there's a level of progressive complexity where it starts out as a really simple problem and, like, those really, really simple ones that you just wanna ask a one time thing, LLM's great for it.

They're amazing. What happens when you get into the you have to live it every day and use it every day and kinda build on top of it where there's a lot of kind of hitting complexity and where it's still a little bit better to say, like, hey. Let's take a systematic approach to this, and this is where buying off the shelf solutions geared towards that problem space can really be beneficial.

Speaker 2

So let's let's give people the five things to consider. Yeah. Yeah. For it.

Speaker 3

And it's like this goes into a little bit of kinda what I was touching on before.

So we'll kinda go through these one by one.

But like, let's just dive right into the first one. Yeah. So for the scalability, like, as I was mentioning before, scale is a big difference here depending on kinda what you're doing. Like, in the world where all your records fit into one Excel sheet and you have, like, one or two people, we've talked to prospects before that are literally fine as they are today as a business with an Excel file in a SharePoint that an individual user checks out.

That does start to fall over at a certain point. Skell has that hard limit of a million rows or it's a million in change, and then you can no longer fit into Excel, and you have to start just thinking about, do you go down the access road versus the database? And then even then, like, a database, something like Postgres, you start getting up to five, ten million records and more. You're starting to think about how do I index this?

How do I structure it? Do I need a DBA to tell me what to do? Well, Cloud can be your DBA, but then you start getting into if you're doing something like buying reference datasets from someone like Dun and Bradstreet or ZoomInfo, those are regular in the hundreds of millions of rows, and you need to do some actual data engineering there. And, like, you start getting into the point where Claude's gonna even prompt you back and say, hey.

What's your environment look like? Which one of these six options do you wanna kinda build from? And you have to you have to under like, you have to have expertise to then be able to kind of pick those together and kinda build those out versus if you're kind of buying software, the vendors has to solve that problem. They own that, and that's where you don't have to worry about it anymore.

You just have to worry about does your plan have access to that much capacity. And this kind of dovetails with the kinda next one that's a little bit more specific to the MDM space around any resolution.

It's one of these kinda classic things of is the more it's any resolution at its core. If you're asking that new approach of, I wanna compare every record to every other record in the system to see if they're the same, that's like, to get over technical is an n squared problem that blows up drastically at scale.

And there's an art to how you stitch that together in a science, and that's where the origins of tamer came from all the way back to our original academic papers coming out of MIT, and where all of our original patents were. And it's like, think just in any resolution alone, it's like nineteen patents that we have around how do you solve that problem of, hey. I have a new record that comes in. Does it match my existing records? And this is, like, hand in hand to scale problem of when you start actually talking about you may have a hundred million records in your database. How do you do that comparison?

Just taking something naive like Elasticsearch doesn't necessarily get you the best results. There's a lot of things that leaves off the table. There's a lot of feature engineering that's missing, and how do you build that all out? That's not something as especially as you have more data variety that you really wanna be doing yourself, that can eat up a lot of your time just on this one facet and this one feature, when there's so many other things that go into kind of building an MDM system.

Because in this, like, gets into the the next slide around the kind of governance aspects that if you do that thought experiment of ask Claude to build you a system, it's really good at doing all the obvious feature requirements and walking through, like, what does the core system need to do? They're getting better at surfacing the nonfunctional requirements that you might wanna do, but it will usually see, like, oh, that's something you're gonna eventually get to.

And when you're actually in an enterprise environment or you are in a regulated industry, this stuff isn't like, this is not table stakes. It's no longer nice to have, or you wanna know who accessed the record, who, edited it, what did they do since the suggestions on it, have, like, the enforcement and all your, like, standard AAA stuff around authentication, fine grained authorization, auditability tied into your SIEM.

That stuff that it's not the best use of tokens to properly do that when it should be turnkey most of the time. So there's a certain aspect to it of, like, you start thinking about building software. There's a small thing, but having it be able to plug and play into all your other systems is something that, like, is often forgotten about. And, like, this even happens in our sales processes. Countless the number of times where we go through sales process, do a demo, do a POC, talk about how great the data is, how they're gonna use it as a business.

Procurement team steps in and pulls in a security team, and it's like, well, show me all your certificates. Show me how you do this. Show me how you integrate to a seam. And then it slows things down quite a bit, and it's, like, one of, I think, the least favorite parts of the sales process from my perspective, but it's also one of these things that just like it people can kinda put it on the back of their mind, also happens to Claude when you're asking it to build a point solution to you. It's so eager to solve the problem right in front of you that it sometimes forgets and glosses over some of these things, which also kinda fits into the mental model of, like, going next to hidden cost to trying to build it yourself.

There's this great kind of analogy one of my friends, had one night when we were out catching up where he said when he started building software ten, fifteen, twenty years ago, viewed software more as you were, like, a craftsman that's building, like, a fine piece of furniture or, like, hey. I wanna do you a master carpenter. I build a really nice cabinet. Once it's done, it's done. I can sell that to my customers. What's beautiful about software is you can sell it repeatedly. And the idea is that you have a physical kind of good at the end, and it just works.

That's less and less the case nowadays. It's software, I think, is closer to actually being more of a garden where you have to constantly care. You need to water it. You need to pull weeds out. You need to protect it from animals. And there's a constant level of effort that goes into maintaining a software.

And it's getting worse actually with the AI tools where it's the one of the whole points around for Claude Fable, like, Fable and Mythos being told is how fast it can detect CVEs. Every package now has a CVE. If it doesn't today, it will tomorrow. And a lot of the maintainers, because of the rate of these, have switched over to kind of the core packages you having to upgrade.

They're not maintaining backwards release branches for long periods of time. So in the case that you are building something, no one's writing all their own libraries from scratch, but the libraries aren't being maintained for as long as they used to be, and you have to upgrade. There's there's this flywheel of every week, here's a new list of CVEs that you have to upgrade all your dependencies to and stay on top of. And it's increasingly like, I know my team feels that of we integrate with Google's Gemini APIs every three to six months.

You need to upgrade the model, change the endpoint that they do it. They change how they do rate limiting and how we have to do capacity management.

When you're just building something nowadays, there's the overhead of maintaining it over time is as high as ever, if not higher. And it's a very can't get the time to, like, an initial MVP is much faster. Like, this is where I'm very intrigued by, like, the poll we had at the beginning of these these concepts of do we eventually get to that thing where software is fully self maintained and we have whatever super intelligence of AI and you build an AI software factory and everything just maintains itself. It'd be amazing if we get there. We're still not there yet, and that's something that I think, like, self driving cars may be two years away for the next ten years before it actually becomes a thing, but there's a hidden cost to kind of this cycle of this that often gets overlooked.

And then moving on to kind of the last major run around the skills here to solve something like an indie resolution problem at scale, you kinda need some expertise here. And, historically, we could kinda rely on people to a certain degree to, like, sit down, learn how something works, and build the application for it. And the what we used to be of, hey. Did the person that built that functionality walk out the door? Because software engineers switch jobs all the time, and how do you kinda maintain that team core?

In the more modern world, talk to a lot of teams, especially the ones that are aggressively adopting AI tools that are building more than before.

A lot of the engineers' understanding of what that thing's actually doing is more superficial than ever.

So you start running into this problem of, hey. If we're gonna buy, build everything instead of buying tools, your team is increasingly kinda stretched thin on just how much context they can hold in their heads to actually have the knowledge of what that system's doing.

And how do I adapt that like, adapt to new patterns over time or extend that system as we grow as an organization. And you end up having to almost start over when you're like, hey. In three to six months, I need to add a new feature because I now want things in a little ENC API instead of just a batch output. Or, hey. We're doing a data warehouse migration. Oh, I need to refigure out my data connectors. You're almost starting cold each time for that, and that's increasingly gonna be a problem and something that, like, I know we spent a fair amount of time inside our engineering team figuring out how do we make it easier to manage that context, both for the agents and also for people and improving our documentation game for it.

There's my prediction is there's gonna be a similar thing with the data and having context graphs or having a bit of a moment again. And I think it there's a reason why companies that are doing memory for AI is looking at knowledge graph and looking at kind of data management practices and how to play those together. And there's a really interesting kind of synergy that's part I think it's gonna happen over time for how these play well with each other.

So with all that said, I think leaving off on the kind of the skills aspect of it, it kinda brings the question that I think me and Anthony probably has bumped into is, what do we want our engineers working on? Like, what do you want your engineers working on?

And the question kind of boils down to, do you want them working on stuff that's core to your business and kinda core to what you want them to be, or do you want them doing other things? And I think this ends up being the question. It's like, there's still a finite amount of human capital to spend on building stuff, but I think increasingly the hot topic is what's your token spend? And you still need to make a decision on what do you wanna spend your tokens on. So, like, in addition to just where you're gonna spend your engineering capacity, where are you gonna spend your token budget in terms of building stuff internally versus entry buying stuff off the shelf?

Speaker 2

So, again, for the poll, feel free to respond to the poll on the right side of your screen. And, again, don't forget to hit the submit button like I did. Don't be me. Hit submit so that the poll results actually come through.

And yep. Again, where would you spend that extra engineering capacity if you had it? Are we ready for the the results? Excellent. Alright. Here we go.

I don't think that's right as a result only because I think we oh, the

Speaker 3

Yeah.

It looks like this.

Speaker 2

Oh, I see. Yeah. So there are there are the results that are sorry. You have to scroll down a little bit.

So okay. So the the on the on the results set, you have to I have to sort of scroll down. So it looks like the majority of people are looking at integrations across systems and essentially workflows and integrations, which actually makes a ton of sense and actually maps nicely to the next place where we're gonna go in the presentation.

So let's do that.

Here we go.

Alright.

So, yeah, we can, you know, broadly you know, from our perspective, if you're not building the core MDM system, that doesn't make sense as Nick pointed out. What should you be focused on?

Well, I would suggest two things. One is integrations, and the second is thinking about downstream agents. But maybe, Nick, do you wanna comment on that?

Speaker 3

Yeah. I think increasingly, what we're gonna see is that the integration surface area is gonna change. What an integration looks like to an agent is different than a human. And, like, there's that growing trend around headless services around and I think more than ever, the kind of how your APIs are designed and your user experience around your APIs, including MCP, is front and center and not just how kinda humans interact with it. And there's a lot of work to kind of shifting systems over to being consumed both by alarm agents and by humans and making sure that it works good for both and play well together.

And there's a, I think, a lot more value that can be leveraged from trying to figure out what are your existing business processes and how can they benefit from data and how do we improve that process and potentially automate it than focusing on how do I serve that data and or how do I, like, directly manage it myself?

Speaker 2

Yeah. Like, on this point of integrations, one of the things that Claude is fantastic at is if you pointed at an API set and say, you know, I have this API and that API, and I need to connect them. It's the sort of thing Claude loves because it's very testable. It's very standard.

It's very easy. And on the agent side, it's often the case as even the polling suggested that the business process behind those agents is pretty specific to your business and thinking about tying agents into an MDM system. You know, Tabor, we have this concept to bring your own agent that you can plug in. That's a really powerful construct because you can really think about the specific business logic that you wanna apply to that mastered and clean, organized, up to date data.

So just to sort of wrap up here, we'll take some q and a.

The the kind of key things to take away here is there is a big change. So I think it's very fair to say that software development as a as a kind of discipline, as Nick pointed out earlier, maybe, you know, not as much a craftsman type behavior, but more of a volume behavior and thinking about things that are very specific. There really is a a big difference. But our view is that MDM in particular is exactly the kind of candidate for a platform technology that ought to be plugged into the specifics of your business as opposed to made specific.

And this idea of buy versus build, again, think about both of those things and think about what you wanna build and what you wanna buy. And in particular, these data foundations are not an area of great potential for building from scratch. You should take these as given. They should have well formed APIs that you can plug into easily and focus your expertise, energy, and tokens to use your framing, Nick, on those last mile integrations and business specific workflows.

So with that, a couple kind of takeaways for everyone on the call. You can scan the QR codes literally right from your computer and download a couple things. As a as a reminder, there are also links on the right side on the docs section.

And, with that, maybe turn it over, to you, Morgan, if there are any questions that have come up, that you, think we should answer.

Speaker 1

Yeah. Perfect. Thank you, Anthony and Nick. That was awesome. Before we dive into q and a, I just have a few quick announcements.

So if you're joining us in Cambridge this summer, Tamer will be at CDOIQ symposium, July twenty first through the twenty third. So feel free to stop by and connect with our team and keep the conversation going on all things data and MDM. And if you're interested in diving deeper into the five factors that we covered today, check out our recent blog post on the build versus buy debate that you can find in the docs tab.

It's a great companion piece that you can take back to your team when you're ready to make the call. And lastly, if you'd like to learn more about Tamr and our AI native MDM solution, you can schedule a demo with our team or download our newly updated MDM journey ebook for a deeper look at how we help organizations modernize their master data management.

So now we can shift into a live q and a with Nick and Anthony. So if you haven't already, please submit your questions using the q and a tab on your screen.

So let's get started. The first question we have is, is there a rule of thumb for when MDM makes sense? For example, I think of such a solution if I only have two to three major systems that collect most mess master data. I realize there are many aspects to this, but any comments would be useful. If it helps narrow it down, they also asked if we could differentiate between analytical and transactional MDM.

Speaker 2

Yeah. So maybe I'll start, and then, Nick, you can chime in. But in general, I'm not sure that the number of systems is the right metric to think about when you're thinking about an MDM challenge. I think it's the volume of data.

And it's also think about it in the context of the particular entity you're describing. So if you have a a large number of customers, more than a couple, you know, a hundred or even in the low thousands, as Nick pointed out earlier, that's really an n squared problem. So thinking about resolving those customers is gonna become computationally difficult once it starts scaling up. And, again, it goes up at the square, so, you know, even small increases have a big impact.

Obviously, more systems makes it more challenging, but I think data volume is the key the key metric. And maybe we pause there before we jump into analytical versus transactional, but I don't know if Nick, if had any commentary there. Yeah.

Speaker 3

I think the the data volume, and I think to a certain degree, the systems is almost the data variety. But, like, even with inside one system, you can have multiple different data varieties that you're trying to deal with and trying to kinda stitch those together.

But, yeah, I think that's right in that. And then I think the other metric in terms of diving into the analytical versus transactional is that, to me, the biggest differentiator there is how fast do you need the data and the latency in terms of the data. Or for the transactional, you want the latency subsegment tied into core business operations versus the analytical.

It can take some time if it runs overnight, takes twelve hours, updates the dashboard generally fine. That one, I think, is a little bit more, I guess, support to walk through than necessarily the the kind of mix of data volume variety and number of systems. Sure.

Speaker 2

Yeah. That's a great point because, you know, if you're onboarding a customer, you need that to show up immediately. You can't have the customer waiting or or have two different systems fighting over what's the correct spelling of the customer's name. Whereas if you're updating a dashboard, to your point, if that happens overnight, that's probably fine.

Cool.

Next question, Morgan.

Speaker 1

Yeah. Awesome. The next question we have is why do you think the ongoing costs of a homegrown MDM solution are often underestimated? So what things get missed?

Speaker 2

Sure. So maybe, Nick, do you wanna do you wanna take that?

Speaker 3

I think the biggest one is the kinda hitting cost of how much it actually takes to maintain software nowadays, where it's just the conversation I had with my friend that I mentioned, we took an old project off of GitHub that was, like, five or six years old and tried running it, and we couldn't get it to install.

And it was something, like that was with, like, pinned packages for most of the core packages. Like, you'd be surprised just how much software can rot without kinda constant maintaining of it. And, like, that's the thing I'm probably most worried about as there's more software with kinda AI going forward is that who's maintaining all of that, and how do you do that over time in a kind of a secure, sane manner without, ballooning cost.

Speaker 2

So I definitely agree with that from the software perspective. As it relates to MDM specifically, I think another thing to think about is the data variety and shape that you have is often changing, and that itself is also it's the data it's the data drift, if you wanna call it that, that's another source of change. So even if the system is in place, as the day as you bring on new sources, if you did acquisitions or if you just decommission or recommission sources, that's gonna shift.

Yeah. So just add that as another hidden cost that that comes in.

Speaker 1

Perfect. Our next question might also be for Nick, but it is where would you draw the line between what an engineering team should build in house versus what they should buy? So how do you help customers think through the trade offs?

Speaker 3

Yeah. I mean, this is something that I think has changed over time as kind of these new apps have come to place. It used to be the simple thing. Like, is this a core business problem that that have? And if it's core to us, we're hundred percent building it. And, like, if it's core to the thing we're, building and shipping in our business, we're gonna build it. Anything outside of that, I'm gonna look to a separate vendor.

Now it shifted a little bit, and it's more of, I think, forecasting to what's going to happen and where are we gonna grow into. Where if there's a service that, hey. We know our usage is gonna be stable to it and it's not going to be changing very often, we may actually look to build it now instead of buy it. Now the kind of tricky thing is when you're dealing with data and real world, like, data associated with real world events, those are constantly changing. So that's where it gets a little bit tricky, like, for the MDM as, like, as Anthony was just mentioning. You're constantly acquiring new customers.

People get married, change their last name, they move addresses, etcetera. I think increasingly, everyone's probably having CFOs drive them to pick lower cost things that then shift around. They're like, you're changing interfaces and kinda connections to things. And I think the kind of more modern question is, is this something that in six months, in twelve months, in twenty four months, am I gonna be using it more or less than I was now? And is this something I'm gonna grow and build into where I don't wanna have to constantly be spending ongoing kinda effort into building that out versus knowing that that system's there for me when we get to that next level of complexity and we're ready to use it.

Speaker 1

Perfect.

And then it looks like we just have one more question.

Given AI accuracy challenges, can AI based MDM solutions be put in production? If yes, how do you achieve a hundred percent master data accuracy?

Speaker 2

Yeah. It's a great question. First, I would say the one really important capability in an AI native MDM system is determinism and explainability. So you want it to be the case that if you send two records into the system that you're always gonna get the same answer back and that the system can explain why it made the decision it made.

We've put a lot of investment in that at Tamer and make it make you have confidence that and and this also gets back to, you know, questions around governance and things like that. Oftentimes, organizations will want to have confidence that they can explain why the system did what it did. As it turns out, just as a funny side, it's also a place where large language models can be extraordinarily helpful. We can give it a very complex set of output from the model and say, explain this in English. And it does a really nice job of writing up what you might write up as an email explaining why it made the decision it made.

So I think I would start there. The second part of the question, which is how do you achieve a hundred percent master data accuracy? I will respectfully suggest that shouldn't be the goal. Or, you know, obviously, the goal should be a hundred percent, but you'll never achieve the goal. It's never possible to get to a hundred percent. Really, the question to ask is, each day, is the data better than it was yesterday? And am I focusing my limited resources and energy on the most important and critical parts of the data that need to be better?

And the reason I say that is date as Nick pointed out earlier, data is always changing. You're onboarding new sources. And then the real world is changing as well. As Nick pointed out, people change their name.

They move. Companies merge. They divest things. They change their names as well. Go ask Google Alphabet.

You know? So you're gonna find that the date the real world is changing. Your data is changing. And so the real focus is on keeping up with that change as best as humanly or machinely as possible.

Speaker 1

Perfect. Well, I think that is all for the questions for today.

So thank you so much for joining us. We hope you found this session valuable. Just a quick reminder, today's webinar will be available on demand, so we'll send out a link that you can rewatch it or share with your colleagues. Before you go, we'd love your feedback. So a quick survey will pop up and will only take

‍