Under the Hood: What Makes an MDM Solution Truly SaaS (And Why You Should Care)

Hello. Good morning, good afternoon, or good evening, everyone.

Thank you so much for joining today's session, Under the Hood, What Makes an MDM Solution Truly SaaS and Why Should Care. Before we begin, I'd like to cover a few housekeeping items. So closed captioning is available.

Just hover over the virtual stage and click the CC button located at the bottom of your screen.

We encourage you to submit your questions leveraging the q and a tab in 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, which are available in the docs tab in the engagement panel on your right. 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 via email directly.

So our esteemed speaker for today is Tejas Parekh, Director of Engineering Platform at Tamr and part time lecturer at Northeastern. So welcome now over to Tejas.

Speaker 2

Thank you, Morgan. Welcome, everyone. Thanks for joining. Let me quickly introduce myself. I am Tejas Parekh, director of engineering at Tamr.

I lead our cloud infrastructure and platform engineering team. So when we talk today about what true SaaS looks like under the hood, that's the world I work in every day. But I'm also on the buying side. I buy a lot of SaaS services for our own platform here to run our services, and so I'm constantly evaluating them as well, using the same framework that I'm gonna talk about today.

Having sat through so many vendor pitches, it becomes important to be able to separate real SaaS offerings from SaaS.

On top of that, I teach master level cloud computing courses at Northeastern, where I been modernizing the curriculum to reflect how the industry actually works today. So I'll bring all three of those lenses to this conversation, builder, buyer, educator.

Now, I talk to a lot of teams when they're evaluating SaaS, and one of the things that keeps coming up again and again is everything's labeled as SaaS, but not everything actually is.

So today I want to give you a practical framework for cutting through that noise. We'll cover what to look for, what to question, and why it actually matters when you're evaluating a SaaS platform.

This isn't a product pitch, it's a buyer's guide.

But before we get started, we're just gonna do a quick poll here.

And I'll just briefly hand over to Morgan here as well.

Okay.

You all should have an option to take the poll.

If you can take it, that would be great.

And we'll come back to the results in a minute.

Alright, so here's the reality. Over the last few years, nearly every MDM vendor has rebranded themselves as SaaS or cloud native, and I get it. The market is moving in that direction. Buyers are asking for it. No one wants to be seen as a legacy vendor. But when you look under the hood, a lot of what's being sold as SaaS is really just the same old software hosted somewhere else. That distinction might sound academic, but real consequences for you and your team, in terms of cost, in speed, in how much of the infrastructure burden you end up owning.

And so let's dig into why.

So why is this conversation important? Because the market is at an inflection point. Many organizations, more organizations than ever, are looking to modernize their MDM, moving off prem, moving off on prem to moving onto cloud. Now, that's great, but it's created an environment where vendors who were a little bit behind on the trend in the industry have realized that we need to quickly fill this gap so that we can remain competitive. And so they have a very strong incentive to just label anything as SaaS, even if the underlying architecture hasn't fundamentally changed.

And the cost of getting it wrong isn't trivial. We're talking about implementations that drag on for over a year, surprise infrastructure costs, systems that don't scale when your data volume grows, and ultimately a slow time to value that undermines the whole business case you've built to get your project funded.

To make sense of this, I think it's important to put vendors on a spectrum. On one hand, you have got hosted or left and shift vendors. Basically, what these vendors have done is they've taken the same software that they run on prem, and now maybe it runs on AWS or Azure, maybe the vendor's hosting it for you, but it is still a single tenant instance. You still have to deal with upgrades, sizing, a lot of the same headaches that you have with the traditional on prem software. In the middle, you've got managed services. The vendor takes on more of the operational overhead here, but it is still a dedicated single tenant instance with version numbers and upgrade cycles.

And then on the far end, have the true multi tenant SaaS shared infrastructure, continuous delivery, elastic scaling, no version fragmentation.

Now this is the mental model I encourage you to use when you're evaluating any vendor, right?

Always ask yourself, where does the vendor actually sit on this particular spectrum?

Speaker 1

Then just real quickly Tejas, the poll on the right should be launched.

So I'm happy to share the results if you wanna stop sharing for

Speaker 2

a second.

Sure, I am just here.

Speaker 1

There we go.

Speaker 2

I cannot see the result for the fourth one, but it is There we go. So we're almost tied between three and four. Three is which is great. So we'll continue with our presentation.

And I think by the end, I think everyone would I hope everyone understands how to actually truly evaluate a SaaS platform.

Alright. So let's get practical. When we are evaluating SaaS platform, there's six things I personally like to look at and to kind of determine whether is the vendor of what the vendor is offering is truly SaaS, or if it's something that's been labeled as SaaS, but is one of those lift and shift a managed service offering?

And we'll see why each one of these things are actually important for us to maximize the business value that we get from actually using these services.

The first one is multitenancy. This is foundational. In a true SaaS model, all customers are running on the same platform.

Your data is isolated, of course, security and privacy are maintained, but the infrastructure is shared.

And this is what makes everything else possible. It is what allows the vendor to push updates continuously, to scale elastically, to keep the cost down.

If a vendor is spinning up dedicated instance for each customer, they're not true SaaS. They're managed hosting provider.

The question to ask is simple. Do all of your customers run on the same version at the same time? If the answer is no, or if it's complicated, that tells you a lot.

Personally, we had this experience at Tamer where one of the vendors that we were evaluating for SaaS was a big name company, big name tech company, which was a little bit behind, and they had a SaaS offering. And when we started the POC with them, we quickly realized that what they actually had was a hosted instance of their on prem that they were selling us as SaaS, because we would constantly run into issues with scale.

The data would get dropped or we wouldn't be able to make API calls, service would have outage, and as we kept asking probing questions, we quickly realized that what they had was a fixed size instance behind the scene.

It wasn't truly a SaaS model. So multi tenancy is very important because, and we'll see through the other criterias as well.

The second one is continuous uptake. In a true SaaS model, there are no version numbers. There is no upgrade from seven point two to eight point zero. The vendor ships continuous improvement. Every customer gets them at the same time. This is a huge deal because upgrades are one of the biggest source of pain when a platform isn't truly SaaS. They are expensive, they require planned downtime, and they often get deferred, which means that customers fall behind on new features, bug fixes, and more importantly, security patches.

Downtime isn't just a technical inconvenience. It's lost productivity for the team, right? So the question to ask the vendor would be, when was the last time customer had to schedule a platform upgrade?

And the reason this matters for us is we don't want to end up creating technical debt, which happens when upgrades are complex, requires downtime, and so we keep deferring them.

And over time, that's gonna catch up with us, and we'll have no option but to take significant downtime, which again, impacts the business.

Third, elastic scalability. With true SaaS platforms, you don't have to size infrastructure upfront. You don't even have to have the conversation about the SaaS platform's infrastructure.

You don't have to talk about how many nodes you need or what kind of instances you're gonna run your service on. The platform has to be able to handle it for itself.

If your data volume doubles because of an acquisition or new data source, the system just scales.

So what does this look like in practice? Basically, the auto scaling has to happen transparently behind the scenes.

Capacity has to be added by the SaaS platform. When the demand increases, they should be able to scale down when it drops, all without customer involvement.

The platform should be self healing. If a component fails, the service detects errors, recovers automatically, without the customer having to file a support ticket with the platform.

It's also important for the vendor to have proactive alert policies that fire on anomalies, like latency spike or resource limits being approached, so that this platform remains behind the scene, the infrastructure remains behind the scene, and we can continue to focus on the usage of the platform to solve our business problem, right? So the question to ask the vendor here would be, if my data volume doubles next quarter, what do we need to do from our side?

In a true SaaS model, the answer should be nothing.

But, you know, and if you want to dig deeper into this question and kind of verify this, ask them to show them monitoring and auto scaling capabilities that they have. If they cannot tell you or won't show you, then that's an answer by itself. And oftentimes we have done that at TEM, or when a prospect does come up with these kinds of questions, we are happy to show them how we do these things behind the scenes so that they feel comfortable using Tamer SaaS.

Comprehensive API coverage.

The platform should expose native REST APIs for core operations, reading, writing, searching, and managing data programmatically. This matters because whatever platform you choose, it needs to plug into your broader data ecosystem. You need to be able to automate your workflows, enable lookups into other applications, and push or pull data without manual intervention.

And a good signal here is the quality of the developer experience.

A company that has a good API coverage will have good developer experience.

Or we can say it the other way, if the company has good developer experience, they're gonna be API first company.

One of my favorite marketing billboards from a tech company I've seen in San Francisco was basically all it had was the company's name and it said, Ask Your Developers.

Because even if the developer did not use that product within the company, they knew about it just because how good their API first documentation was and the experience of using their APIs was, that it was a well known product within the developer community.

So, comprehensive API coverage matters. Mainly because a lot of these SaaS applications, they don't live in isolation. They have to integrate with other systems that you already have in place. And without APIs, that does not work.

Alright, fifth, transparent and predictable pricing. True SaaS should give you a clear pricing model where you can forecast cost confidently.

Now that does not mean that every SaaS product is gonna have a flat subscription based pricing.

Consumption based pricing makes perfect sense for many services that are out there. The issue is usually when the pricing is so opaque or unpredictable that you cannot accurately budget for the service. Or when some core platform capabilities that should be included, such as APIs, SSO, compliance tooling, they end up being paid add on.

One of the red line for me when I evaluate SaaS vendors is security should not be an add on. It should not cost me extra to have security with this service.

So, the question here isn't what will it cost to get that security, or what will it cost to use the product?

Basically, the pricing model has to be something that we can understand, so that we can forecast what our estimated cost will be. We can budget accurately.

I've had vendors where I've not renewed services just because they changed their pricing model, and it gets so complicated that no one understands. No one on their sales team, their account team could explain how that pricing would actually work, how I would actually budget or forecast for using their service.

And so even though the service was good, because I could not know how much it will cost and, you know, what that, how do you even account for it, we had to drop the service, we couldn't renew with them.

So having a good pricing model, that's predictable, that's transparent, is very important, you know, because I often see, when we sign up for these services, often see it as a long term partnership with the vendor.

If the pricing is not transparent, if I cannot forecast for it, I don't know how long or how much I can invest into using that service, and making it something that's critical for our daily operations here for our cloud platform.

Sixth, this is the simplest test of all, zero customer managed infrastructure. Ask the vendor what infrastructure will our team be responsible for managing? In a true SaaS model, the answer should be none.

Your team interacts with the UI, with the API.

Everything underneath, compute, storage, scaling, patching, monitoring, that's vendor's responsibility in the SaaS model.

Now, what's interesting is, you know, I've been on some of our calls with our prospects as we go through the pre sales process, and where they kind of ask these kind of questions, and as I walk them through our architecture and our infrastructure and how the platform works, sometimes there's a light bulb that goes on because they're like, Oh, we talked to this other vendor and they seem so much cheaper, but, you know, we realized that they require us to install a lot of things on our side, they require us to set up all this infrastructure, so what the vendor is actually doing is they're passing on the infrastructure cost to you.

So the service may seem priced competitively or cheaper, but that's because you're hosting a lot of infra to work with the SaaS service here.

And, you know, what that also means is it's not just purely infrastructure cost, overhead of IT team, it's the overhead of a DevOps team that has to maintain and manage these things as well.

And so you can see your cost kind of balloon when you do have infrastructure that you need to set up to work with a service.

So let's talk about some of these red flags, right? The things that I hear from teams that signal the vendor isn't quite what they claim.

We'll set up a dedicated instance for you. Sounds like a premium, but it's actually sign of a single tenancy model, where what they have done is basically taken an on prem solution and just started hosting it, maybe in Azure, AWS, or Google, and then offer you that as a SaaS offering. And you mention a portion numbers or upgrade schedules, true SaaS don't have that.

Being asked to make infrastructure sizing decisions upfront, before you even start.

This is the vendor passing on, or the customer being asked to absorb the architectural complexity of the product, which shouldn't be a case with a true SaaS model.

The onboarding timeline can be months or longer, with heavy professional services engagement.

True SaaS should be able to get you to value in weeks and not quarters.

Wig answers about multi tenancy, or oh, we're gonna deploy it in your cloud, again, is them offering a managed service rather than a SaaS offering on their end.

Now, I know what some of you are thinking, but is my data actually secure in SaaS model? It's a fair question, because, you know, always on every call that we talk about our platform or architecture.

The reality is that a well architected SaaS platform should give you a stronger security than what most organizations can build and maintain on their own.

So, what should you look for? Well, we definitely need encryption at rest and in transit.

That's stable states.

We want enterprise grade access control with SSO role based authorization, regulatory compliance support, consent management, data subject access request, ability to delete or purge records to meet a right to be forgotten requirements.

And we want to see security certifications, like SOC two.

A vendor should be able to point you to their trust portal or security portal, where you should be able to review these certifications that have been audited by a third party auditor, and gain confidence that, okay, the vendor has done all the right things, and they are doing all the right things, and they have proper controls in place.

The bottom line is, SaaS doesn't mean less secure. The question isn't, is SaaS secure or safe?

It's, can this vendor demonstrate the specific controls my organization needs?

So why does it all matter? Because the architecture choice that we make here cascades into everything team experiences.

With true SaaS, you're living in weeks, not months, your total cost of ownership is predictable, no surprise infrastructure bills, you're getting constant, new capabilities constantly without having to plan or upgrade project, you can scale when the business needs it, and most importantly, your team gets to focus on what they were hired to do, instead of managing the infrastructure.

When one of this is not true, every one of these things flips, right? Trying to value stretches out, costs creep up, innovation is catered by upgrade cycles, scaling requires support tickets, conversations, reaching out to people, and it's slow, it's time consuming.

Your engineering team becomes a DevOps team.

That's the real cost of getting things strong. So, just briefly how Tamer kind of stacks up against these things, against these criterias.

Tamer started off as an on prem offering as well, but TAMAR SaaS was built from ground up as true SaaS platform on top of Google Cloud.

On data isolation, TAMAR maintains physical separation of customer data, logical isolation of metadata, So you get the full benefits of SaaS without giving up isolation guarantees that enterprises require. The platform is continuously delivered, so there are no version numbers, no upgrade windows.

We offer comprehensive API suite with interactive developer hub. Pricing is subscription based with no hidden cost.

Security, like SSO encryption, GDPR, CCPA compliance are all included. In part of the pricing, is no SSO tax or security tax.

And Tamr has been AI native since founding in twenty thirteen at MIT.

So, let me leave you with these three that you can put to work immediately.

First, know the spectrum, every vendor you talk to will sit somewhere between hosted and true SaaS.

Your job is to figure out where. Second, ask the hard questions.

I've given you specific questions for each criteria today, use them. Don't let a vendor get away with vague marketing answers.

And third, evaluate architecture, not labels, right? What a vendor calls themselves on their website, in their marketing material matters a lot less than how their platform actually works under the hood.

And if you keep these three things in mind, you'll be in much stronger position to make the right choice for your team.

That is all I have got for today. I'm gonna hand it over to Morgan before we go into q and a if we have some time.

Speaker 1

Perfect. Thank you, Tejas.

Quickly before we dive into the q and a, I just have a few quick announcements. So first, we're excited to be sponsoring the Gartner Data and Analytics Summit, May eleventh through thirteenth in London. So if you're going to be there, we'd love to see you. You can find Tamer at booth number three zero eight, and we'll also be taking the stage alongside Glenn Hall, program director for data modernization, who will be presenting a customer success story.

If you could just go to the next slide, Tejas. Perfect. Thank you. We're also excited to be presenting at the Virtual Dataversey MDM Demo Day on May twentieth where Ravi Hussali and Elliot Kim from Tamr will be sharing a live AI native MDM overview and demo. So if you're looking to learn more about Tamr and other MDM solutions, registration is free.

We'll also be at, Snowflake Summit June fourth first through fourth in San Francisco. Our Tamr customer, Kartik Sambasamwin of A and M Healthcare will take the stage on June third to discuss how A and M transformed their data operations with real time AI native data mastering. So you can find us at booth number three thousand and three and pick up some cool swag if you're there.

And if you'd like to learn some more about Tamr and our AI native solution, you can schedule a demo with our team to see what true SaaS MDM looks like. And you can also read more about it in Tejas' blog post, which is linked in the docs tab as well.

Now let's shift into a live Q and A with Tejas for all of those who want to stay on past thirty minutes to learn more. If you haven't already, please submit your questions using the Q and A tab on your screen.

And let's get started.

So the first question we have is when evaluating a vendor's SaaS claims, what are the most common ways cloud wash deployments disguise themselves as cloud native solutions?

Speaker 2

Great question. I think one the ways to look at that is, you know, if they bring up infrastructure sizing, that's the number one giveaway that it is not a true SaaS offering, that it is something that they are labeling as SaaS, but it is a managed offering of their on prem software.

Speaker 1

Perfect. Our next question is how is a multi tenant architecture better performance compared to a single tenant or hosted deployments?

Speaker 2

It's more about cost rather than performance here.

Single in a multi tenant environment because every customer is using the shared infrastructure and the shared environment, the cost of the infrastructure is spread out across all the all the customers that are on the platform in a single tenant environment because the vendor to maintain the maintain the instances, maintain the infrastructure for each tenant separately, the overhead of infrastructure, but the maintenance aspect of it is also part of one of the customers, not pricing. So a multitenant offering will usually translate into a more reasonable pricing compared to something that's labeled as SaaS, but it's a single tenant hosted instance behind the scenes.

Speaker 1

Perfect. And our last question is what does it mean for future deployments to be decoupled from code updates in a true SaaS environment?

Speaker 2

So, you know, one of the things I talked about was continuous delivery of code on the SaaS platform.

Now delivery of the code and delivery of feature are two separate things, and so what this allows us to do is constantly keep releasing new things behind the scenes, keep fixing bugs behind the scenes, but the features are released when they're ready. This also allows us to give early access to certain customers by using feature flags. So we can get feedback from our customers early on in the development cycle before it is ready and released to everyone else. So SaaS truly allows us to do that. We can't really do that when, you know, we have a single instance where, again, we get an upgrade window where they can go enable that feature for us or install that feature for us within our instance.

So it has to be a true SaaS platform where we are able to continuously ship new features, get feedback, get early access to our customers as well. So everyone benefits from that, from being able to use feature gauge to release core release features versus how we release code on a SaaS platform.

Speaker 1

Amazing. So that is the end of our q and a portion. Thank you so much to everyone for joining us today. We hope you found the session valuable. Just a quick reminder, today's webinar will be available on demand, so we'll send out a link so you can rewatch it or share it with your colleagues. Before you go, we'd love your feedback, so a quick survey pops up and will only take a minute or two and will really help us to continue to improve and bring you the content you want to see. So thanks again for spending part of your day with us and we hope to see you at a future event soon.

Speaker 2

Thank you everyone. Thanks Morgan. Thanks.

‍