What is data automation?
How is it different from iPaaS and workflow automation?
What is data unification and how is that different from identity resolution?
Let’s dive in:
Q. What exactly is Data Automation?
Originally, data automation was a data science concept to describe processing, normalizing, handling of data with automated techniques. So until Syncari, multi-directional data automation was only available to, well, first of all, it's available to anyone. But if you were trying to do it, it would be a lot of coders and data science that were trying to do that. So Syncari is actually bringing these capabilities, plus some MDM and CDP capabilities that we borrowed, to essentially business users with a no-code platform. In our case, it's targeted at go-to-market engines that go all the way from leads to billings inside of your go-to-market engine.
Q. Is data automation the future of iPaaS?
So the way I would answer that is, point-blank, data automation is not integration. And, rather, it's a way to generate a 360-degree unified view from all your systems, and then orchestrate the go-to-market processes across your business. Again, from leads to billings. The difference with Syncari is this distributed 360 view of your data is not centralized and it allows you to curate and share that with all your teams. And, you know, and that's a very unique position versus just simple point-to-point integrations that are moving data back and forth, whether they happen to be ETL point to points, or automation point to points, or whatever they happen to be data point to points. It's very different. The other big difference that Syncari has over iPaaS is these are stateful, multi-directional synchronizations. Now, everybody uses the word sync these days, but, truly, sync is to have data be identical in more than one place at exactly the same time. So, you know, point-to-point connectivity solutions, like iPaas, just can't touch the data at the level that we do.
Q. How is data automation different from workflow automation?
If you think about how workflow automations today work in most systems, they are triggered and have access to transitory data across two endpoints. And that truly minimizes your flexibility, whether it's an ETL, whether it's a integration, or whatever it happens to be, it's transitory data and it minimizes your flexibility in being able to create automations. And so what data automation, and especially Syncari, does is we take this data model view, a unified data model view, of all the connected systems. And you can use all of your data to orchestrate cross-system and cross-object automation.
The best way to think of it is if I wanna look up what's going on with an account based on a contact or lead that just came in, it's incredibly difficult or impossible to do with today's, you know, workflow automation platforms. So the largest difference is it can also transform data, normalize it, enrich it, calculate it, dedupe it, all centrally, and then distribute that end result to all the connected systems at the same time. And so, this ability to keep all your systems in sync and near real-time, you know, across all touch points is really what Syncari does.
Q. Would you say data automation is a team sport since it involves so many different teams?
That's a great question. We run into this all the time. The reality is you can think of it as either a team sport when you're using it for a few systems. The example here would be, like, let's say I'm a sales ops person. I'm just trying to get my sales systems to work more cohesively and be unified, and have the proper, you know, merge, dedupe, enrichment, and automations across those.
But, however, to truly align your entire business and to get business alignment across all your go-to-market teams, you have to, eventually, see this as a team sport. And if you think about this even further, the rev ops organizations in businesses today, have really emerged from the fact that they're trying to get alignment of their businesses from leads all the way through billings as a cohesive thing. So, in that case, it becomes a team sport over time, but it certainly, in many cases, starts out as an individual sport, if that makes sense.
Q. Which teams benefit the most from well-executed data automation workflows?
In our particular case, it's anyone that touches go-to-market. So whether it's product data activation from your product, if you're selling SAS, or whether you're trying to automate a fully congruent PLG motion journey from beginning to end, whether you're trying to get, you know, leads, contacts, accounts, you know, all of that out to, you know, billings and accounting systems congruent, you know, it requires, essentially, everyone to help out there, right?
🤔 Have questions?
Q. Where does data modeling take place when building these data automation workflows?
Yeah, so we try to take the pain outta data modeling out completely from the end user. If you look at Syncari, it's not about connecting two endpoints. It's about what does my data model look like as a result of running this stack that I'm using. And, so, we present the user with a unified data model of those systems. You know, there's a lot of moves in the marketplace right now to try and define a data model that's standard. That's never gonna happen. Every SAS company that is, you know, believes to be the source of truth for the business logic that they support, is gonna always have their data model.
So we took the approaches, like, we help you stick together the data model that you wanna see based on the systems that you decided to use. And for many of these systems, our connectors are super smart. They go all the way down to the schema level, and they not only sync data, but they sync schema from all of these systems. And we know how to map that schema across all these different systems. So if it's customer over here, account over there, you know, whatever, person, lead, contact, all of that is pulled together into one common view for the customer. And then they operate on top of that data model to perform the operations and automations that they want to do.
Q. What exactly is data unification? Is it the same as identity resolution?
No, no. It's very different. So the best way to think about this is in that data model that we just talked about, many systems can sync into the account object, let's say. Or, let's take the contact object at the moment. And so, I could have Salesforce, Marketo, Zendesk, NetSuite, et cetera, all feeding into my contact object, right? And I can normalize all of those into one canonical place. The ability to stitch that data together from all those systems, and to say that, "Hey, this is Arpit." When I say, "Arpit," and I change Arpit in one system, I know exactly the same record that I'm touching in all of the other systems.
Where in today's iPaaS technologies, let's say, I said, "Oh, well, I'm just gonna send over this email address as the thing, the key to sort of, the ID to send over to this other system." Well, guess what, if there's duplicates, and let's say, I did a find by email ID. I get one. Which one do I update? And this is why you see a lot of discrepancies in data across companies, because as their databases grow, more duplicates come into the picture, these iPaaS systems end up clobbering data all over the place. And so, what we've done is said, "Hey, as part of syncing, you have to make sure you're touching the right record for every object in your data model across all the connected systems." So we have borrowed some learnings from prior MDM stuff. So we have a Syncari ID and then we map every record from every system. We attach it to that Syncari ID across all the systems that we connect to, so that we know empirically which record to touch in each one of these systems based on the record that got touched in any particular system, if that makes sense. And that allows you to maintain congruency.
So if you think about it, if I don't have unified records across all these systems and I wanted to do global merge and dedupe, how do I know which merge and dedupe operations are running those systems, if I didn't have unification of that data across those systems? It's very important to do that all in one place. And what we see happening all the time in a lot of our customers is Salesforce is running their own merge and dedupe, Marketo's running their own merge and dedupe. Two different tools clobbering their data, then trying to synchronize this. It just becomes this huge mess. And then that also gets made worse by the fact that people wanna enrich the data through data providers. And where do I enrich the data? And when do I enrich the data? And then these things start ping ponging back and forth on updates. And so what we said is like, "Look, we have a canonical view of the data model. A canonical data set. You're gonna operate on top of that data set. And any operations that you do on that data set is gonna end up at the end systems in exactly the right way that you wanted it to be there."
Q. Since you earlier mentioned CDP. How would you define CDP and does Syncari, in some ways, replace a CDP?
You know, I guess I would answer that by saying that CDP was another attempt to centralize source of truth, right, from different endpoints. And try to get the data of your CDP back into the connected systems, not so trivial, right? So the best way to do it is we employ some CDP techniques as far as how we persist data and move data around, but our linkage back to the end systems is a thing that most of these CDPs can't do very well. Even the ones that have added, like, a persistency layer to their backend, they still can't get the unification done across all the connected systems to know that they're touching the right data.
So this is the thing we wanted to fix from traditional CDPs and iPaaSes that are in the market today. But in many cases, you used to think of us as being able to also write alongside CDP because they've got telemetry into systems that do a lot of different things, and we can actually read from a CDP and make that part of the overall unified data, right?
Q. Last question for you — I heard that you have a slightly different opinion about data warehouses being the central source of truth for data. Can you please walk me through it?
The reality is it's pretty straightforward. And every go-to-market system is really the source of truth. Again, for the business logic that it provides. CRM, market automation, accounting, whatever may be, that system has business logic and creates the source of truth. So just moving all that data, without consideration to how it needs to get across other systems, into a data warehouse doesn't solve the problem of how do I get congruency across the connected systems.
And if you can't get the right truth distributed to the right systems at the right time to take action with the business logic in each one of those systems, then you've really defeated the purpose of why the heck you were trying to organize that data centrally to begin with. And so what it turned out to be, for many companies, is a glorified reporting system off to the side. And it's like, okay, so I've got a reporting system off to the side, but I need to take action on some of the data that I've got in the data warehouse. What do I do? So of course, you know, we've created reverse ELTs, but those don't solve the problem because you haven't gotten unification across all the different systems. And so you can't get the right truth to the right place at the right time.
And that's the thing that's very different between centralized sources of truth and Syncari's view of the distributed source of truth across the connected systems.
🤔 Have questions?