Unknown: Hello, and welcome to the Data Engineering Podcast, the show about modern data management.
Atlan is the metadata hub for your data ecosystem.
Instead of locking your metadata into a new silo, unleash its transformative potential with Atlan's active metadata capabilities.
Push information about data freshness and quality to your business intelligence,
automatically scale up and down your warehouse based on usage patterns, and let the bots answer those questions in Slack so that the humans could focus on delivering real value.
Go to data engineering podcast.com/atlan
today. That's a t l a n, to learn more about how Atlas Active Metadata platform is helping pioneering data teams like Postman, Plaid, WeWork, and Unilever achieve extraordinary things with metadata.
When you're ready to build your next pipeline or want to test out the projects you hear about on the show, you'll need somewhere to deploy it. So check out our friends at Linode.
With their new managed database service, you can launch a production ready MySQL,
Postgres, or MongoDB cluster in minutes with automated backups, 40 gigabit connections from your application hosts, and high throughput SSDs.
Go to data engineering podcast.com/
lunote today and get a $100 credit to launch a database, create a Kubernetes cluster, or take advantage of all of their other services. And don't forget to thank them for their continued support of this show. Your host is Tobias Macy. And today, I'm interviewing Sabine Thomas about Xyng Data, a mobile friendly business intelligence platform. So, Sabine, can you start by introducing yourself?
Unknown: Hey, everyone. It's a very long time listener. My name is Sabine Thomas.
I am the CTO and cofounder of Xyng Data.
Unknown: And do you remember how you first got started working in data?
Unknown: Yeah. Absolutely. I think not to give away my age, but 1 of my first jobs out of college was
working on a reporting system for an HR data
software company and remember diving into SQL dialects. We were using
an early version of SQL Server back then, but a lot of it was being able to construct the right pivot tables to be able to get at the data fast. So
that was my first foray into it and to being able to work with data and have loved it since.
Fast forward a couple of years,
and I find myself this is early 2010. I found myself
working at Rakuten where I was the director of engineering there. At Rakuten, you know, fairly big in the ecommerce space. And so my task there for the teams that I was managing was actually
working on their data infrastructure for payment data.
And this is around the time for Hadoop and
Apache Spark wasn't even 1.0 at that time.
And so it was a great interest space to be in to be able to process these large volumes of data, seeing how the shift from Hadoop to streaming data was was making its way. And so, yeah, so that's sort of my forays into data now with Xyng Data.
Unknown: So in terms of the Xyng Data project, can you describe a bit about what it is that you're building there and some of the story behind how it got started, and why you decided that this was where you wanted to spend your time and energy?
Unknown: So Zing Data, at its core, is
simple social business intelligence for everybody.
And we say that because we ourselves ran into that problem set,
where I, as
in engineering and engineering leadership
and in product management,
never fully had access to data at my fingertips. There was always something that I had to go pull up on my laptop or my desktop
to be able to query stuff. And so in the middle of a meeting, in the middle of some active, you know, product discussions,
not being able to see what the analytics look like, user data look like, or product usage data look like seemed to be a problem. And so having faced this ourselves, we said there's gotta be a better way to access it. That's the problem statement we started out with.
And, you know, to prove that out, we built the ZingData, an early version of it, mobile focus to be able to have everyone access to to data at their fingertips.
And a good number of engineering challenges that came up as a result of it, and we can dive into that. But just as a use case, we found that extremely useful for ourselves.
And then when we put the product out there, we were quite surprised by the the types of users signing up.
People who would traditionally would never have had access to a data engineering team or a partner or data visualization software.
We were seeing people like truck drivers signing up,
inventory managers at warehouses
signing up. Again, traditionally, non
data use cases that had organically signed up and just told us the problem set is actually a lot bigger than we thought.
Unknown: With this idea of mobile access to business intelligence,
On the 1 hand, you can say, Well, I've got that with any web based business intelligence platform because I can load the site and I can look at the charts. And I'm wondering if you can provide some
nuance and distinction to what it means for business intelligence to be used in a mobile context.
Unknown: Yeah. Absolutely. So the premise here is, you know, I think with the result of the pandemic,
everybody's been displaced in some fashion. And surprisingly,
we've seen people
have a good amount of their work done, not just at their laptop, but on their phone. If you're using Slack, there's a huge percentage of people that are just using it directly
to get work done on their phone. So we're looking at 76%
of monthly active users are people using Slack on their phone. Same way with Google Docs, GSeeps. So there's a good slot of productivity use cases that can be done mobile first.
But the challenge there is in the context like you mentioned,
existing BI software,
the interactivity
of having a display on a mobile browser
and then having to pinch and try to be able to get into the zoom of the actual data
is quite problematic. And that itself is a use case scenario I personally have have dealt with.
Beyond that, there's a whole engineering back end architecture
difference as well in how you represent that's made to be mobile first. Our data is ubiquitous. We have a mobile app, we have web apps as well. So we've seen how you can represent data differently, but in the way we've
architected it, the architecture to be able to represent on mobile first is quite different. Things you have to take into account are like, small form factor. If you're looking at a dataset
on your phone,
there is no reason for you to pull down 40, 000 rows from a SQL query result. That just doesn't make sense, and that doesn't help you do further data analysis.
There's also interactivity. You know, I mentioned the pinching and heavy to, like, squint into the results to be able to get that. You know, interactivity with mobile apps is almost second nature at this point. You know when you open up an Uber to, like, tap to be able to swipe to, like, a long press to be able to get to certain actions. And these are actually the basics of how we've designed our app as well. So there's, like, an interactivity difference there.
And then I think the last thing here is sort of like the query composition piece. When you're looking at your results, if you're trying to pull up sales data by region,
we know that you're on your phone, you're in a particular location,
you have particular
connectivity, 3 gs or 5 gs, whatever it is, you are backgrounding the app to go into another app and then come back to this.
So the mobile architecture to be able to handle all that is pretty complex, and that's we've taken a long hard look at being able to design this right from the ground up. And I think we've done that very well with ZincData.
Unknown: To your point about that query composition,
having been somebody who has used my phone for a number of things that most people don't bother, like SSH connections, etcetera,
I don't imagine that
sitting there and writing long or complex SQL queries is something that I'm really gonna wanna do on a mobile device. And so I'm curious if you can talk to some of the
kind of real world usage of what types of queries people are actually wanting to write or generate from a mobile device, the types of questions that they're trying to answer in that mobile context versus a more full fledged data exploration that they might be doing on their laptop,
and some of the ways that you think about how to enable them to maybe answer more complex questions than what they are going to want to sit and write out all the SQL on their phone keyboard?
Unknown: Yeah. Absolutely. Writing out SQL on your mobile keyboard is generally not advisable.
And so this is where we've thought of how that interactivity works. And so we actually have a low code interface where you can kinda tap into a table,
long press into a column name, and select the filters you want, all of this without having to type in SQL. So there's a mechanism there that allows you to be able to get to a result pretty quickly. And on the back end, we're doing pretty intelligent query composition to say for the categories and the attributes you're trying to view in your query result, here's what the ranking in the window function looks like, and we will sample that data down for you if it ends up being in a large
result set. So that's sort of like the query intelligence layer, if you will, that's happening behind
behind the dataset. But then to be able to handle connections, you know, SSH connectivity,
direct peerings
across AWS networks, VPC peering, SSH tunneling to be able to get even more granular access. All of these things are key tenants of how you would access data normally within enterprises,
even cross department. And so these are all the things that we've designed for
to be able to to kind of leverage the broad access patterns.
Unknown: Another aspect of
a mobile business intelligence system is that when you are mobile, there are particular ways that you want to interact with the data versus what you would want to do on a laptop or from a kind of full
data exploration suite.
And I'm curious if you can talk to some of the interaction patterns that have become
common in these web based or desktop BI systems
and where that breaks down moving to mobile? And then conversely, what are some of the interaction patterns that are unique to mobile
that wouldn't make sense in a web or desktop first environment?
Unknown: Yeah. Absolutely. You're right. Thanks for clarifying that. So in
the sign ups that we've seen, again, we've done very limited marketing at this point in time, so all the usage we've seen has been completely organic. And so in the sign ups that we've seen,
there's this concept of a deskless workforce, which is folks that are never at a desk working. They're always on the go. And the typical persona here is, you know, your salesperson or field sales folks that's going from meeting to meeting. But then your CEO as well is doing the same thing. Every people in your c suite are also traveling between locations. And at various points in time, are trying to get access to data and are not being able to pull up a laptop to be able to get those results. Or inevitably, we'll shoulder tap somebody on the data engineering team to say, can you give me sales by region because I want it cut this way. In the usage that we've seen, the example that I mentioned earlier around
warehouse
for man trucking company that
actually ships trucks. It's a pretty interesting use case. They have a usage pattern of being able to get access to what inventory data looks like at that point in time and as they're running from warehouse to truck and back to warehouse.
And this is not somebody who's at a laptop. This is not somebody who's at an office per se. It's probably in the truck trying to get patterns around what the warehouse inventory looks like. And so and from them is being able to make decisions around trucking patterns and, route patterns. So that's 1 use case that we've seen. Another use case that we've also come across has been,
national
concert operator, 1 of their biggest concert operators.
We had a venue operator
setting up for a pretty large concert,
plug in the Xyng data app to
her Google Sheets data
of seating chart info. And so she's running around in this concert venue trying to organize seating categorization
and is looking at Xyng app to be able to get those queries. And so this is, again, a use case of somebody not at a desk
would not be able to
pre render these charts by asking somebody on a data team. So these are all live ad hoc type queries that we think are best use use
the best use cases for something like Xyng.
Where it kind of breaks down from your desktop to mobile,
I think for us, you know, the way we see it is ubiquitous access. If you're doing something on your mobile, you should be able to pick up where you left off
on your web and be able to continue that data analysis and the the exploration there. And that's what we've designed for. We keep that as a core tenant of our design principles.
So you can run a query on your phone,
get access to a result, be able to comment and tag somebody else on that thread saying, hey. Why are sales
seemingly dropping down during this week and be able to pick that conversation in that thread and that query on web. So for us, it's more ubiquitous.
Where we see there be a difference between,
you know, more desktop
based querying is where somebody needs to
look at maybe a very small result set and be able to cut that in 4 or 5 different ways and then be able to write write a machine learning model on top of that. And we think that's a different use case that Zoom necessarily does not solve for, nor are we interested in at this point in time, but I think that's where we see, some amount of difference.
Unknown: Are you struggling with broken pipelines,
stale dashboards,
missing data? If this resonates with you, you're not alone.
Data engineers struggling with unreliable data need look no further than Monte Carlo, the leading end to end data observability platform.
Trusted by the teams at Fox, JetBlue, and PagerDuty,
Monte Carlo solves the costly problem of broken data pipelines.
Monte Carlo monitors and alerts for data issues across your data warehouses, data lakes, DBT models, airflow jobs, and business intelligence tools,
reducing time to detection and resolution from weeks to just minutes.
Monte Carlo also gives you a holistic picture of data health with automatic end to end lineage from ingestion to the BI layer directly out of the box.
Start trusting your data with Monte Carlo today. Go to dataengineeringpodcast.com/montecarlo
to learn more.
As far as
the native app capabilities versus just designing a mobile optimized web experience,
You touched on this a little bit as far as being able to understand, okay, what is their actual connection type? What are the resources available on the device? I'm wondering if you can just talk to some of the ways that you are
engineering around this mobile native capability
and some of the
features that would be effectively impossible or at least exceedingly difficult if you were to try and stick with a web first implementation?
Unknown: 1 example that always has bothered me in the past with other solutions has been a long running query. You are running something against your retro cluster or your Databricks cluster, and it just takes time to crunch and compute.
And it is not feasible to have that longer response time when you're on a mobile phone.
So for us, you know, a core way for us to solve that has been push notifications
for long running queries. You issue a query,
you background the app, go do something else, answer a couple of emails, and you would push notify on your mobile phone to say, we have your results.
Also, if you are in a common thread in the results set, you can tag somebody and they get a push notification as well, and they get dropped right in those query results to be able to analyze further. So we think this is a real good example of a use case that, you know, you just couldn't do easily enough with web. There are web sockets that you could have to do a persistent connection. But in that mobile use case, this is just much more native in that scenario.
Unknown: In the
architecture of what you're building at Xyng Data, I'm wondering if you can talk to the breakdown of what are the types of operations that you're doing in the mobile device,
how you think about being able to manage intermediate datasets so that you don't have to constantly be streaming information back and forth between the mobile client and the back end system
and just some of the
engineering challenges that you've had to work through as you've gone from idea to where you are now?
Unknown: Yeah. Absolutely. And I think that's something we're still iterating on. There are some really good
technologies out there that have come out in the in the most recent few weeks, I mean, Postgres, Wasm,
to allow you to be able to run that completely in browser. It's been pretty interesting. There's DuckDV that gives you
really good, you know, single core performance, you know, when you're running it on mobile. Those are the compute resources are obviously limited. So there's some interesting projects out there that I think we can kinda leverage on. For us right now, we focus very much on the query intelligence piece, which is how you construct that query to be able to get you the most interesting data quick and fast, and then be able to iterate on those queries.
So I I think there's a future where we could kind of integrate that, where you would be actually seeing,
you know, more fine grain analysis happen on
your device's silicon.
But I think there's few nuts and bolts to figure out there before we can do that. But that's been a core part of our thinking, which is to be able to not have to run this on the mobile phone given it's limited resources and RAM. What's the best way to construct that query to limit that, to rank it, to window function it so that you get the most appropriate real result set. So for the user,
they have this initial dataset that they can run future queries off.
Unknown: Digging a bit more into the
mobile side of things,
I've done a little bit of work on building for mobile app clients, but it's definitely a very large and constantly evolving ecosystem.
And I'm wondering if you can talk to some of the ways that you've thought through
how to implement the actual mobile app where you are likely targeting both iOS and Android. So are you doing kind of the React Native approach? Are you building native apps for both? Are you using 1 of the toolkits that allows you to cross compile for different endpoints? You know, so are you using you know, building it on Go? Are you using, you know, just the app native toolkits?
And then
in that context as well, how do you think about being able to
abstract the shared usage
that
is agnostic to the runtime and being able to then add the customizations
for different device capabilities.
Unknown: Yeah. I think app development
frameworks have come a long way, and they continue to iterate
every couple of years as seemingly a new framework.
We've paid special attention to how other startups
have done this. You know, Uber, when it first came out, had just an app for the iPhone and then later on added Android. I think the way we thought about it is for tooling like ours, for a product like ours, which
is essentially bringing data analysis into the palm of your hands, you know, what is the thing that gives you the most global reach?
And surprisingly, the United States and its mobile device usage
for, you know, productivity apps is, I think, a lagging behind compared to other economies.
If you look at emerging economies, they've sort of jumped the gun completely from dial up all the way to wireless 5 g to which, you know, mobile phone is primarily your primary computing
device. So we thought about that. We know that the stats between iPhone and Android usage are very widely outside the United States. And so for us, it was important to have something cross platform
from day 1. Our SDK of choice has been Flutter,
you know, that Google put out,
I'd say, about 6 years now if I if I get my math right. But Flutter itself has been evolving pretty quickly over the past
few years to the point that when we started out with Flutter, we got out of the box cross compilation for iOS and Android, but it hadn't had anything for web at that point. And that only came later after we'd had already had a few iterations of the Zynq data app. So it's pretty interesting to see the pace of innovation and what's happening,
and obviously something that cannot be done, you know, just a few years ago. There have been other toolkits like Cordova that allow you to do this cross compilation, but there's always been issues with being able to get good usage around, you know, memory and GPU power.
Flutter for now is able to solve that for us. We are seeing some limitations that, you know, may cause us to pursue a more native app
path. I think for us in the stages of business we're in, you know, the Shutter allows us to have sort of a a universal
code base that applies to
3 interface mechanisms,
allows us to get changes and iterations out there faster.
That's been key for us, but I think there's a future where we may dive into more native app variants. Flutter does allow you to do
plugins that you can sort of tool on top of the compilation to give you more native interfaces.
And so that's something we're actively exploring right now.
Unknown: An interesting point that you brought up is the question of
usage of mobile devices in developing economies and in places where
computers and laptops aren't the kind of initial computing experience. And that also
brings up some interesting questions about, for those types of users, what are some of the additional features that are useful or necessary beyond just being able to
look at some data, maybe dig into it a little bit, because I know in the feature set that you have right now, you have the capability of being able to
download a rendered version of a report or being able to download a CSV of that data. And as somebody who's living in a first world country, my first reaction is, well, why would I wanna do that on my phone?
Right. Why do I care about that? But I'm curious if you can talk to
some of the ways that you're thinking about the
needs and requirements
for some of these other types of users who aren't necessarily in a developed economy or who don't have a laptop and a tablet and a phone and all these other different computing devices to be able to work from.
Unknown: Yeah. Absolutely. So, you know, 1 use case that we've seen,
Latin American
retail chain, they do a small kind of furniture supplies, not a grocery chain, but they have about 8 stores.
And they are currently using us to track inventory levels.
The sign up came from, like, an Android device,
and that was just the primary mechanism for this 1 inventory manager that's tracking us across these 8 locations.
And
their mechanism of accessing data has been primarily mobile. There's been no laptop usage or no desktop usage that we can tell of.
And for the feature set that we have,
1 thing that really applies to them is our ability to sort of create
alerting data on time series data that you can get pushed out 5 for.
This completely absolves, you know, the need for a data engineering team or anybody to create an airflow job. You
can, from your phone in about 4 or 5 taps,
look at, you know, usage data, be able to
sort of provide levels,
and then create a push notification alert so that as that data changes, you get notified on that phone. And so this is a use case that we saw this user do and kinda surprised us to understand why they would need to track this, but it's just something that's just so native for this person to be able to manage all these locations. Not having had this access, I think they would have had to hire, you know, few more folks to be able to split that task out. But with Seeing Data, they're able to make use of this use case.
Unknown: The other side of that equation is that
when you do have a cellular connection as your primary method of accessing the Internet,
that adds some constraints in terms of the volume and complexity of data that you want to be working with. And I'm curious how you think about that balance
on the server side and also in the user experience aspect of helping people understand
how to do their subsetting, maybe how to do some of their filtering so that they're not dumping the entire table to their phone, also taking into account things like constraints of storage space and memory on these mobile devices
and how you think about being able to provide an interactive experience for those users
while still being able to get useful information and not be hamstrung because of that kind of limited bandwidth.
Unknown: Yeah. Absolutely. I mean, 1 thing that we kind of don't ever take for granted
is good strong connectivity. So, you know, by designing for,
like, limited and and spotty network
from the ground up, we're able to take all of those design decisions into our back end. So 1 thing that we do
when you've connected us to any of your data sources, is that we're able to
compute from the data types of the tables that you're interested in looking at or the columns
that this looks like time series data, and will automatically do a relative date searching for you.
So
this doesn't mean that you need to pull down sales data for the last 10 years if that's the only database that you have. An automatic default in that scenario
is to be able to pull down last 7 days. And those are things that the user can pull again, drag and drop between. But that's an example of a smart default that we think, you know, really speaks to this use case where somebody's out in the field, spot a 3 g connection because, you know, 5 g is yet to get there, but once they get access to this 1 data. So that's an interesting use case. Other smart defaults that we think about take into account, you know, multiple fields. If we can tell you that this is, you know, time series data with monotonically increasing values on these particular attributes, that tells us that this is something that can be aggregated on. So for a data type that is, you know, your integer to begin to float, we can aggregate on that, and that becomes an a filter option that is already done for you or you can choose
from. It makes no sense to show an aggregation
option on the string data, which you kinda see with other BI vendors, but for us, that is a smart default. So it kinda takes all this cognitive load from the user to have to think about what is the underlying data, but be able to more think about the type of question and the answer they're trying to get to.
Unknown: Data engineers don't enjoy writing, maintaining, and modifying ETL pipelines all day every day, especially once they realize that 90% of all major data sources like Google Analytics, Salesforce,
AdWords,
Facebook, and spreadsheets are already available as plug and play connectors with reliable intuitive SaaS solutions.
Hivo Data is a highly reliable and intuitive data pipeline platform used by data engineers from over 40 countries to set up and run low latency ELT pipelines with 0 maintenance.
Posting more than a 150 out of the box connectors that can be set up in minutes, Hivo also allows you to monitor and control your pipelines.
You get real time data flow visibility with fail safe mechanisms and alerts if anything breaks, preload transformations, and auto schema mapping precisely control how data lands in your destination,
models and workflows to transform data for analytics and reverse ETL capability to move the transformed data back to your business software to inspire timely action.
All of this plus its transparent pricing and 247 live support makes it consistently voted by users as the leader in the data pipeline category on review platforms like g 2. Go to data engineering podcast.com/hevodata today and sign up for a free 14 day trial that also comes with 247
support. Because of the fact that you are giving some of this exploratory capability through the mobile experience, it also suggests that the people who are using it aren't necessarily going to be supported by a large team of data engineers and analysts. And I'm curious how that also influences the way that you think about the product that you're building and who you're building it for and how to
Unknown: surface some of these concerns around the vagaries of data and how to work with it. Yeah. That's exactly the point. So our research as we were building the company out, talking to numerous sets of folks, 1 thing that we commonly heard
from a lot of data practitioners and people in data engineering teams of these big SaaS companies
is just the amount of work that they they have to keep up with and the number of tickets that they've got to be able to respond to these report requests.
And so, you know, a data team is just not an infinite resource, and yet they have all these asks. And and we know that at least, you know, a good chunk of these questions are very simple questions
that
is most 4 to 5 lines of SQL
that your highly paid data science team should not be working on. And so this is where we think about
sort of the democratization
of this tech to be able to make it
really simple, giving you this easy button to be able to do your own data exploration by giving you these smart defaults
will lead to higher data engagement.
That's sort of the genesis of how we thought about, you know, this query composition techniques,
these, query intelligence layers that we needed to build in based on the underlying data. And so by empowering these folks, by making them
be able to self serve, we think they'll be able to ask smarter questions. Now we still want the data science team involved in doing these highly complex analytical workflows,
these machine learning models that they need to be appropriately spending their time on. But let the 40, 50% of other easy questions be sort of self-service,
and let that be something that the teams can work on with an app like Zinc.
Unknown: As you have gone from your initial conception of
the problem that you were trying to solve and the ideas that you had about how you were actually going to approach it and what the solution would look like And working through those initial design steps and working with customers to where you are today,
I'm curious what are some of the useful mistakes that you've made and some of
the assumptions that you had that have been
invalidated
or challenged or that that you've had to change in the process?
Unknown: Yeah. Absolutely. I think 1 thing is thing I brought up earlier, which is, like, this difference between emerging economies, global usage of BI versus,
you know, BI usage in in the States and Europe and how there's a difference there.
So earlier on, our first few versions of of Zendesk data was completely app only. You have to download the app to be able to interact with any kind of data. And the more we
engage with users, the more we realize ubiquity of access is actually important. And so the later addition has been the web access where you can actually
run these queries with these smart defaults with the same point and click mechanisms,
Not necessarily the tap and the swipe and the and
the drags, the similar point and click mechanisms, but aimed at a web workforce.
So that was something that we, you know, didn't think we needed initially.
Did the research, you know, based on user feedback, was able to get that out there pretty quickly. Now we have, you know, similar functionality across all 3 of that. Other things we thought about initially was
how much time should we really spend on
the data connector piece? And, you know, we
thought it will be important to have
data connectors for,
you know, your MySQL Postgres
and then leave it at that and then be able to to iterate on product features based on signal from users.
The more we talk to folks, the more engagement we saw, we just realized there's this wide
swath of of underlying database tech, and I think increasingly so in, you know, in your conversations, you've probably seen that as well over the last 5, 10 years where, you know, people are running the gamut, right, from your Google Sheets database to to MySQL, Postgres, to all your AWS equivalents of those, and then, you know, your data breaks and data lakes. So that was sort of a a later realization for us that we kind of had to spend
some amount of time on a regular cadence to build out these connectors
and to make sure that those support all enterprise use cases, which is things like SSH tunneling, you know, things like custom certificates. You know? Doing that was a sort of a later addition, but we were able to to centralize on that pretty quickly. I think a third thing that we saw was
also kind of related to this database connector tech and how we
did our dialect parsing. You know, there's they're all NCSQL
99 compliant is what they say, but there's still differences that we've come to realize.
And so our initial version of our sort of query intelligence layer in the back end
had very distinct
mechanisms for dialect parsing
and then the query composition
and to account for these different anti SQL variants. And then when we started to add more connectors, we realized how really that code started to become.
And so there was a quick effort by our team to be able to centralize and and sort of coalesce that into
sort of an extensible framework where we could add dialects, but only things that had changed. And so that was effort that we put time into, and we've certainly benefited from that. You know, the pros and cons for such an effort, which is now if you've got centralized code, the testing
regimen needs to be up to par with every release, and so we had to invest time in that as well. So that was just a case of things that we recognize we have to do. But, you know, with any startup, sequencing is always a thing. So
Unknown: Yeah. The frustration over ANSI SQL not actually being
a recurring theme that has come up many times over, like, a series of interviews. Yes. So
Some part of me wonder if it's nefarious to a point where you kind of get this automatic lock into a database vendor because of user SQL, but I don't know. That's a broader theory there. That's part of the reason that the Postgres implementation has become so ubiquitous as kind of a self fulfilling prophecy of, oh, we'll just use the Postgres version because other people use it, and then we'll you know, engine that's just gonna use the Postgres dialect because that's what other people are using, and so it's become this snowball where everybody just says, okay. We'll just use the Postgres dialect.
Unknown: Yes. Exactly. Yep. So 1 thing that is on our to do list from our future standpoint is SQL Server Integration. It's strange that that's the 1st database I ever worked with in a professional setting, and that is something we'd be able to connect with. But there are strong differences there in in the
in the, anti SQL compliances there. So Absolutely.
Unknown: And the additions, having written some fairly gnarly T SQL,
Been a while. But
Unknown: Right. T SQL, PLSQL. Yes.
Unknown: And so for an individual or a team who is implementing Xyng data, I'm wondering if you can just talk through the typical workflow of going from,
we've got it set up to, now I actually want to start building out a suite of reports and being able to enable some exploration or maybe some of the ways that
a small data team can help provide some guidance and guardrails for other members of the business.
Unknown: We've initially
and purposefully made tried to make that dead simple in terms of how you'd be able to connect to a data source. So the steps would be you go to Zendesk data, you sign up, and then there's a simple drop down to be able to add, you know, creds for any kind of data source you're connecting out to. So if it's something like a Google Sheets, there's a lot of info related to that, to your Databricks or BigQuery.
There's JSON you can drop into to be able to connect out to that. And then then configuration settings for client certificates and SSH channels if those are the things you want to set up.
After that,
you now have access to this data source. You are also put in what we call the default organization.
This is our concept of of business unit or enterprise or anything that that you want to extend it to. You can then invite colleagues into it. And from that point on, you can also
limit
access to certain tables or data sources
for different invitees.
So there's
an intuitive RBAC that's built in as well for data that's almost implicitly
required.
And so from that point on, anybody can start asking questions of their data based on the access level they have. There's this tap to query mechanism where you can kind of go into a table, tap on columns, set the right filters, and you get access to a chart representation
if the query allows it or a data table representation.
And from that point on, you can share that result with colleagues. And then they now start to get pulled into that query result, and you can have a collaborative thread based on those results.
Another key thing that's different for Xing Data is how we've
thought about the home screen interface. When you first
have Xyng on your phone or you're on the web app and you go straight to that home screen, you kind of see
a knowledge graph of questions that have been asked by your colleagues. And they're ranked almost similar to, like, a news feed or a TikTok feed where you can tell, you know, these are popular questions that people in my network or my company graph have asked
and commented on. And so there's sort of a company knowledge base that's being built as a result of these data questions. And so that's sort of the engagement mechanism we really think about, which is you're on your phone, you're able to see what people are asking.
You're able to start getting results right away and not having to construct a query from scratch. And we think this is the best way to really get people more broader access to data.
Unknown: Another aspect of what you're building is
being mobile first. There is a certain set of patterns and questions that people are going to want to use for interacting with it. I'm curious if you see it as being the primary or sole business intelligence system that users
implement or
if it is also often used as an augmentation
to other business intelligence or data exploration suites that might be available to an organization?
Unknown: I think for where we are now, you know, again, just kind of relating back to the spectrum of users that we're seeing from this deskless workforce type users that have never interacted with the data team to
people
in divisions inside of a really big SaaS company are using us because they can't get time on the data team.
So just given the spectrum of users,
I think, you know, we are a really good solution for these folks to be able to get access to the data. So in in those scenarios,
for the product manager who's at a big SaaS company and
has waited a month to get a turnaround on on the report they've asked their analyst team, ZingData would be sort of an augmentation to their existing
tooling.
For the person who has never had any kind of data engineering team or any kind of visualization software,
we would be their primary mechanism.
I think long term, the way we think about it is, you know, we really focus on the use case. We really focus on how people are interacting with
data
now and into the future. I think if we do this right, we will become the primary mechanism.
Because if you've made this really simple, more people are going to want this and more people will want to engage with the data, which is the ultimate dream of, I suppose, any data data team.
Unknown: In your experience of
building Xing Data, both the technology and the business and working with your customers, what are some of the most interesting or innovative or unexpected ways that you've seen the product used?
Unknown: We continue to be surprised by this. I think the example that I put earlier around the concert operator
using us to look at seating chart info was something that we hadn't
thought to ever manifest as a BI use case. We've actually seen, you know, sign ups from
a national pizza chains as well, where they wanna track levels of tomato sauce in the different franchisees. And so that's another use case that is, you know, atypical for what I think is a typical PR use case, you know, inventory management.
I think we will continue to be surprised by the use cases here. You know, when we make something as simple as we have done with Xyng, I think it starts people's thoughts around
how to best use this. If I can use it for this, why can't I use it for that as well? So why limit myself to only just sales sales data? Let me look at product usage data. Why just limit myself to that? Let me look at, you know, developer commit data. Like, there's quite interesting use cases that we've seen. But I think these are 2 good examples that we've seen that we've never thought would be reality.
Unknown: And what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?
Unknown: For us as a startup and working with some really interesting enterprises, it's it's been interesting for us to see and evolve
sort of our road map based on what we think is going to be important and what enterprises want now. I think for us as Zendesk data, we're kind of bridging the gap between
where we see a future
to where we are now, which is enterprises primarily use, you know, visualization software on their laptop. So I think for us, learning has been how to bridge that gap, how to sequence the feature sets correctly. So
we are kind of solving for both use cases. We can
help the farmer who is out in the field,
wanting to look at his machine
IoT data versus, you know, the person who's at the big SaaS company wanting to look at product usage data. So, you know, web interface, for example, was 1 good example that we kind of initially didn't think we needed to have, but then later came to the realization that this was a big part of it. Those have been interesting, I think. I've mentioned the thing around data connectors, how there's been a broad usage around different types of databases.
And we'll continue to evolve. I think we the future is pretty interesting for us to see what else we can bring in.
Unknown: And so for people who are interested in being able to access their data away from their desk or away from their laptop, what are the cases where Xyng is the wrong choice?
Unknown: Yeah. Absolutely. I think Xyng data really shines
for the 40 to 50% of us on data teams right now, which is, you know, give me product data, usage data,
user data, and so on. This 4 to 5 lines of SQL that people can easily query off of. I think we really shine in those use cases. You can certainly construct more complex
SQL. We actually have a full SQL editor as well that you can kind of save as a question and be able to share out. Where we think Xyng is probably not the best choice at present, and I think this is probably a gap that we'll cover later on as we evolve, is probably where you need to do really deep analytical models
where you need, you know, a Jupyter Notebook to be able to crunch through the different iterations
and the different possibilities.
And I think these are where you have your data science teams to really help with. I think in those cases, at present, using data would not be something we'd use for that. We still think that that's a gap that we can really close in the next,
few months to a year, and I think that's something we're really looking forward to. But at present, this is where we are.
Unknown: As you continue to build out the product, what are some of the things you have planned for the near to medium term or any particular projects or problem areas that you're excited to dig into?
Unknown: Yeah. Absolutely. We are just deep heads down into product and feature development.
1 thing that we continue to spend and budget time for is,
increasing
the database connector list that we have. So SQL Server, for example, will be something that we'd like to be able to add to our lists, Azure Synapse, and the other
technologies there will be would be things that we'd love to plug into. So those are the things on our product to do list.
And then sort of expanding on our enterprise feature list, you know, audit log availability,
surfacing those up in in the console to be able to really get access to that. I think those are, you know, just a few key features that we know we need to build on and our budgeting time towards. But I think there's also more interaction and more mechanisms we're we're keen on developing as well. So the ability to do
table joins
via a gesture map, so you can kind of long press and drag into tables, and it will automatically construct the CTV for you. Those are pretty cool things that we're really excited about, and we have a few early concepts that we're kind of iterating on at this point.
Are there any other aspects of the work that you're doing on Xyng data or the overall space of mobile first access to business intelligence and data assets that we didn't discuss yet that you'd like to cover before we close out the show? I think 1 thing that I've seen come up, has been kind of interesting has been, you know, sort of a natural language interface to ask some questions of data. And, you know, we thought long and hard about this as we were setting up the company
as to what a solution for something like that would look like. And in every sort of prototype that we'd set out, we almost found that tapping and swiping into your data
was a lot faster than being able to chat
or natural language into something. We think there's quite a gap in being able to ask
cleanly, you know, a natural language question of your data and getting the appropriate results. And so, you know, that's something that always comes up as we do demos. It seems like people are really intrigued by the concept of what we do as in data, and and natural extension to that is to have, like, a voice interface to it. We continue to think about it. I think there's there's still some ways to go, and we will possibly have an answer to this. But it's pretty interesting to see how in a phone and in an app that we have with Zoom, you can get results really quickly by just tapping and swiping. And so that's 1 intriguing thing that I think, keeps being brought up.
Unknown: For anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And as the final question, I'd like to get your perspective on what you see as being the biggest gap in the tooling or technologies that's available for data management today.
Unknown: Yeah. Absolutely. So my info should be on there. Feel free to reach out to me, Twitter or LinkedIn. I'd love to connect with folks. I think you'd be great kind of a great audience.
I am really enamored by the number of tool sets that there are out there for problems that we've had for quite a while. You know, I mentioned my first job out of college is writing reports in T SQL for SQL Server. And to be able to have a data cataloging solution, to be able to have things that would do data lineage orchestration,
you know, those will be dream
tools that we just didn't have back in those days and so glad to have now. I think there's an interesting feature here where it still seems like there are point solutions for a lot of these things. And to be able to really get, you know, a pipeline and infrastructure up from the ground up, It requires you having to work with 25 to 30 different tools. And so and there's also differences a bit based on your underlying database tech. So I think it's it's an interesting future. I think there's some consolidation that could really benefit a data practitioner.
And then also, you know, the target market which we serve, which is the data consumer. And so we think long and hard about that, but I think the future is bright, and it's quite promising to see, the number of folks working on this.
Unknown: Alright. Well, thank you very much for taking the time today to join me and share the work that you're doing at Xing Data and helping people be able to
gain better and more democratized
access to their data assets.
Definitely appreciate the work that you and your team are doing for that. So thank you again for taking the time, but I hope you enjoy the rest of your day. Absolutely. Thanks so much, Tobias. It's a great show. Love listening, and thank you for the opportunity.