Here’s the formatted transcript with punctuation, capitalization, and paragraph breaks:
---
Hi and welcome to the Data Strategy Gurus podcast. Today we have the VP of Technology, Mat Jé, former MarkLogic but now integrated with the Progress Data Platform. Matthew, welcome to the show.
Welcome. Thank you, Mat. You had a very impressive career in data and technology. Can you tell us a bit more about what initially sparked your interest in data management and what keeps you motivated in this ever-evolving field?
So I'm blushing a bit now. Thank you for the compliment. And we've got a similar sort of background, so I'll have to return a compliment as well. Some of my early projects were actually squarely in the structured data world—e-commerce and coding platforms—but always with an industry and practical focus.
My first real foray into data management, as we think about it today, was actually in 1999 when I was the co-founder of a startup looking at data management and data exchange in the manufacturing supply chain. Ever since, I've looked at data from a "how do we employ data, how do we leverage data, how do we operationalize data to do things differently" perspective.
I've explored all aspects of it: search engine, taxonomy and ontology management, classification, metadata management, knowledge graph. So, you asked what my motivation is, what my vision is—it's to help you understand and act on the data you have.
I understand that you're not in the data space because you came from a technical background, but more from the business side. So you feel if you have that data, those insights, how they can help the logistics and supply chain where you came from. That's your different take on the data management approach, I suppose.
I mean, it's about the practicality of it, right? I've moved throughout the years from research—I actually started back in the day at BT Labs in a research department—so I've seen both sides. We still have both sides in our teams because keeping abreast with the latest technology is really important. But I think democratizing those technologies and making them useful is really critical as well.
Sometimes when I discuss with prospects, customers, or partners and look at the data science element—which is really interesting and fascinating, don't get me wrong, I love it as well—but I always need to have that vision of how it's going to make a difference for someone and how we can drive it to simplicity as well.
I know we're probably going to explore GenAI and those sorts of things later on in our discussion here, but often in those conversations, we go hyper-technical really quickly and forget that we're here to solve a business problem. A business problem is led by a business analyst or someone who runs their operation—it's not a data specialist or an IT specialist. They want to be able to use data for their process, but they're coming at it from a process perspective.
It's nice that you already touched upon GenAI and artificial intelligence, the large language models, and the semantics. What is your feeling on the current state of data management with this evolution—with AI supporting data management, supporting decision-driven organizations—and what are the biggest challenges organizations are facing these days?
We're at a very interesting juncture in time. We've got two forces—one is economics. We clearly have seen a fairly drastic change in the economy around us in the last few years. Once upon a time, if you wanted to make more revenue, you'd go out and sell more. Selling more is actually much harder now, so people...
---
(Note: The transcript cuts off abruptly at the end, so the formatting stops there.)
Are trying to make the most of what they have, you know. And what does it entail? What's it entail? Analyzing your data, understanding your market, understanding your own behavior, optimizing better customer intimacy. So a lot of those things are actually data-driven, very, very data-driven. So moving from a "let's go out and sell" to "let's analyze our data and operationalize it and make decisions based on that data." So that's a very interesting inflection point on how organizations are thinking about the data.
The second inflection point clearly is technology. We've already mentioned generative AI twice in five minutes—no, that will come up again. But it has an associated impact on how we prepare data, how we leverage data, and bring data into that space. So what are the challenges here? Well, we've got a big need to change culture around data. And that goes from building—really building—our data stewards and empowering them, to identifying and giving the right tools to our data citizens, to thinking about architectures differently. Yeah, that's a lot. What is going on?
I think you made a smart remark on how back in the days, when you wanted to make more revenue, you had to sell more. Does that mean now, with technology and data and the insights we are capable of leveraging, those margins and improving that? So we're really into the business process optimization part, thanks to the technology and the data, if I understand what you're saying. So that's definitely one aspect—optimizing processes, interactions, supply chain, etc. All of that can be driven by data.
I think there are other dimensions as well—micro-targeting of your customers. You know, when you understand your customer needs, when you understand your customer interactions, you can provide the right product, the right service, at the right time without going for a full blast to everyone. There are also optimization or productivity enhancements by bringing the right data to the right person at the right time. You know, if you think about a lot of knowledge graph, a lot of data fabric work that we're doing, those types of projects are typically about making sure that within a business process, you've got all the data you need to make the decision at the point you need to make it—instead of having to reach out to different team members, maybe create an internal support request for someone to go and look back at a contract or find the right data in a data silo somewhere. So there's a lot of optimization there, which is not necessarily cost-cutting or anything. It's about enabling people to do their job better.
Yeah, it's cutting down those silos, and the technology helps us better combine those organizations where before you really had to put out that request and then unify it in your own way. MarkLogic, the company you came from—which has now been acquired by Progress—is a leader in unifying that data and integrating that data. Can you explain the approach that MarkLogic took on integrating that data, and what are the advantages now of being embedded in the Progress data platform ecosystem?
Sure. I mean, as you just mentioned, MarkLogic and the Progress data platform now—you know, we're building around it. Our objective here is to really unlock the value from complex data, to make it easily discoverable, fit for purpose, to build high-value, high-power applications nowadays, to deliver this intelligence and support your AI journey, of course. What do we do behind the scenes? I mean, we integrate data wherever it is coming from—so breaking down data silos. We're actually storing the part of data we care about—usually metadata, knowledge graphs, those things, etc. You know, we provide querying and retrieval capability on top of that.
Here is the formatted transcript with punctuation, capitalization, and paragraph breaks:
---
Have really powerful way to create, govern, and secure data. And because storing data, managing data, and reaching data is one thing, but using it is another. I mean, we have—we are building and have built over the years—really good capabilities around exploring and analyzing that data.
So, what are the pillars of our technology? I mean, first of all, a truly multi-model database. You know, we can manage documents, graph, relational, geospatial, semantic, temporal data in a single engine. You know, we have really high-performance search and query capability, so we can run complex queries across all of your data and get really accurate and subsecond results.
We have powerful data integration and data management capability. So, integrating data—that's DataDirect, part of the portfolio, which is part of the platform—really impressive way of creating data and adding semantics and metadata management with semantic agile modeling, etc. So, we have Smart Mastering in MarkLogic as well as part of the Data Hub and Data Hub Central product. So, really powerful metadata and data management capability overall, complemented by a comprehensive suite of tools for developers and business users.
Why? Because we want developers to build applications faster, to reduce time to market. And why business users? Because, as we mentioned—as I mentioned already several times—we want to put our tools, our capabilities, in the hands of the people that run the business with their data. I mean, it's really important that a data project doesn't go at the pace of an IT project. We can power it for everything to do with the integration, running the platform, but we need the data to be in the hands of the business users to move at the pace of the business.
Are you referring that there is a difference in speed between IT and the business part? I mean, never heard about that, but I'm just laughing. But I do understand what you mean. So, you provide as well, with the Progress platform, a way for businesses to easily create their data products and make data more accessible. Then you put it through IT. I mean, it has its value by governing it, by providing the architecture, making sure it runs 24/7, it's stable. I mean, that needs to be done.
Sometimes, if you see it comes from the business, it's not so solid as it should be. It's not so secure as it should be. So, that's the part where I see IT still needs to be knocking on the door and say, "Hey, guys, we need to slow down." Slowing down not because we do things so slow, but we need to do these things to make solid solutions in such a way.
Absolutely, absolutely. I mean, the infrastructure part—you know, all the plumbing, the connection, the integration—all of those things, when those have to be governed, you know, go through a normal IT lifecycle, etc., etc. Where many data projects break down today is when the data and the data interpretation is actually treated as a data-as-a-project-lifecycle artifact. Data moves at a much faster pace. Its interpretation is different.
We need, essentially, we're bringing data agility in the same way that engineering teams have been moving to an agile model, so you can deliver incremental functionality—you know, shippable incremental functionality—at the end of each sprint. And you're supported by a shared IT organization that makes sure the infrastructure on which you run is secure, governed, etc.
We want to do the same thing with data—right?—build data agility. Instead of an engineering scrum team, you've got a business scrum team thinking about the data product, thinking about how they need to interpret data, user data in their operation, supported by an IT organization which provides them with the software and the infrastructure to operate in.
Does that mean that the data platform from Progress and all the tooling around that now provide the two different modes where you can have the exploration part, which goes pretty fast?
---
The transcript is now formatted with proper punctuation, capitalization, and paragraph breaks while preserving every spoken word exactly as it was said.
On the speed of data, and that you can once you have that data product developed or that vision for the data or the decision you want to take with your data, and then move it through the slower path from it be fully governed, fully secure, and you can easily switch between the two of those.
I'd go even further than that because we completely separate the infrastructure parts—software, which is governed, etc., and goes through the lifecycle as normal—from the data part, which is using a more information science, data science, librarian-type workflow. So without changing the software configuration, you can change the modeling in an ontology and try a new data scenario, try a new data interpretation in a matter of hours—in a matter of minutes, in fact.
And not only that, but from a technology perspective, because it is all semantics and W3C standard-compliant, you can actually have several of those interpretations running side by side. And even at query time, you can say, "Oh, I want to run through the lens of this world or that business domain or that process." So there's no hard-coded scheme out there, no hard-coded view of the world, no predefined data reduction.
And I think data reduction—loss of precision—is actually something we talk a lot about in our projects because earlier in the cycle you do data interpretation, typically the more information you lose. Yeah, it's data agility.
And when you say we can look through the different lenses—well, the traditional schooled data warehouse builder, dimensional modeling, data guy—we've had the discussion of one version of the truth, where Bill Inmon, one of my former guests as well, was very proud of providing that. But we've learned over time that there are different versions of the truth depending on which department or where you are in your environment. And that's important—that you can easily switch those views but still on the same basis, the same foundation.
Exactly. Because based on who you are, where you are, you might have very different information needs, even though your queries are the same. It might be based on access, it might be based on local translations, it might be based on regulations—all sorts of things. I mean, we do a lot of projects in the pharmaceutical space. Well, even if the research data is the same, even if the molecule is supposedly the same, it might not be manufactured in the same way because a recipe might change depending on the local ingredients.
The brand might also be different depending on the market. The reporting requirements may be different. The little leaflet you get in the box may be different because that's based on local regulations. It doesn't mean the product is different—I mean, conceptually, it's the same thing. People might not have the same symptoms because symptoms are also something that varies depending on where in the world you live.
So it's interesting—I mean, we could go on for hours on that. But if you think, if you go back all the way to the root of ontologies and semiotics—not semantics, but semiotics—the relationship between the words we use, the objects in the real world, and the concept behind them—that mapping varies drastically depending on audience.
Yeah, fully understand what you're talking about. Now, with generative AI and the large language models coming in, and we're talking about different perspectives—I mean, people have used ChatGPT already for the last year. And where you see—well, there it's pretty clear that you can add a different role, and depending on the role you give it to the large language model, you get a different outcome. But telling you the same thing—but depending on the role you give it, you get a different wording. That's...
That's exactly what you're referring to, I think. And how do you see these large language models revolutionizing the space of data management? Will that help us in building better solutions, more valuable solutions?
I mean, it is profoundly changing the field of data management—no doubt about it. From a technical perspective, because it gives you new tools and new approaches, new ways of interpreting a corpus, new ways of serving a corpus.
From my perspective, it's also really interesting because it is driving a very different type of adoption for metadata and data management. A lot of customers, a lot of prospects are coming to us saying, "Hey, we've started this GenAI project, but it's not really performing the way we want. Why?" Well, what have you given it as an input? You know, for rank strategy, etc. It's like, "Well, the data we have." Well, guess where the problem lies, right?
So, from an adoption perspective, GenAI is really interesting because it is fueling the need for better data. Our customers, our prospects, our partners are all telling us horror stories where customers have tried to use their data as-is to drive a GenAI solution. Same old, same old—I'm not going to say "garbage in, garbage out" because actually, the GenAI solutions are making a good job at hiding some of that. But the reality is, if you want precise, accurate, and trustworthy answers on private data today, you need a RAG strategy.
Today, you need the right level of security, the right level of understanding, the right level of search. And that goes all the way back to our story of breaking data silos, moving from an application-centric architecture to a data-centric architecture, having a knowledge graph, having a data fabric from which you can actually surface the right data at the right time.
The conversation we just had about micro-targeting our users, about understanding our users' behavior—all of that goes right back into the way we search our fabric to include the right fragment in the RAG to support a GenAI response generation. So, from that adoption perspective, we're seeing a renewed interest in data management and in metadata management and search technologies in general.
Associated with that, I suppose you'd say, is a more social perspective, which is: data is becoming cool again. You have people trying things with ChatGPT, trying their own AI/ML pipelines and MLOps, and it's great, actually. Socially, I'm now answering questions about stuff we do in our research labs, and it's actually really interesting—people didn't pay attention 10 years ago.
However, you were asking about impact and changes. One big impact and change we're seeing actually in the way we interact on a lot of data projects is a realization of the legal and threats associated with how data is used. So, DLP, privacy—all of those things are fueling a lot of additional inquiries, a lot of additional time spent on projects designing what should have been gathered for all along.
But certainly, organizations are now understanding that their data—the minute it's out in an LLM—may or may not belong to them, and they may or may not be in control, and there are unknowns. So, we're seeing a lot of activity with security teams, with legal teams, with procurement teams around how you handle this new landscape.
So, what you're seeing here is that previously, we had to pay attention to the governance and the security of the data, but because it was more siloed—let's call it like that—people were not paying so much attention to it. I recall the days where you said, "Okay, I need access..."
To the server, to the database, here are the admin rights—full open. Whatever you do with it, uh, you could do as a developer kind of everything on the server. But you're very well aware of the security breaches, the privacy regulations, and all of that—what you need to take into account and be careful with. Because you see so much valuable information, uh, which shouldn't be for all eyes. But there is a kind of trust towards developers to develop that product.
Now, with the large language models, this information is easier to go out of the organization. So people become more aware of governing that, of protecting the privacy of all the information which goes into the model. And that's where they now become more aware and paying more attention to that part of data management.
Absolutely. So, you know, until relatively recently, the majority of security work associated with projects was doing rule-based control, compartment security, etc., within the database—making sure that the data in the system or in the fabric, in the search interfaces, you're reaching the right person. Now, we're seeing a lot of organizations go beyond that and either contractually or through systems, making sure that once that data is served in the application, there's actually traceability beyond that—if it's sent out to a customer, uh, if it's actually shared with another coworker. You know, all of those sorts of things.
And especially, you know, restrictions around using that data in training LLMs in AI or machine learning projects, etc. So, yeah, there's definitely a recognition now that using data for the purpose of training has risks. It doesn't mean we shouldn't do it; it means that we should understand the full scope and accept the risk when we want to accept the risk. So it's a different approach.
I feel like when you say "we," you have two minds again in different developing solutions. If you want to be innovative, creative, you have to—well, you're building less secure and governed solutions because you want to go fast, and that is slowing you down. On the other hand, if you want to have it protected, that takes ages before you have the regulations in place and so on. So that's a bit what I see—where you have to find the tradeoff. Do we use that data, take the risk, to go faster to build really an innovative product as such? Or do we really put the foot on the brake and, uh, within the next 100 years, maybe we have the next large language model—and not at the speed where you see every week you have a new version of an open-source large language model?
Technology goes at such a fast pace. I mean, I've been diving into large language models now in depth for the last six months, and if you see—you take frameworks like LangChain, it changes every week. Documentation changes, the complete framework changes after months, and, well, it's hard to stay on top of it—on the development and on everything that's on the market to build those solutions. And I think that's going to be a challenge now for most of the people to understand, one, on what is possible with the technology, but as well on capturing that capability and using that to build the innovative products.
So, talking about that, how do you see the data management space evolving over the next two, five—uh, five to 10 years? And what emerging trends should data professionals and executives be paying attention to?
Well, data quality, of course, is a big one for me—data management, right? Metadata management as well. Um, so five to 10 years—I mean, you've seen the pace of change right now. I mean, in some of those topics, it's hard to predict what's going to go in two weeks. So, um, that said—and back to—
Here is the formatted transcript with punctuation, capitalization, and paragraph breaks:
---
What we said a few minutes ago—there's this very big dichotomy, you know, difference in swim lane and pace between our industry and manufacturing and IT users, regardless of the industry they're in. And our research—so if you look at projects in production or projects that are dealing with data at scale, I think we're still in the early days of data fabric and knowledge graph and all of those things. So there's still a lot of technology to be developed, a lot of technology, a lot of processes to be simplified to make it applicable and make sure it's rolled out and successful in those environments.
I mean, we're still seeing the same three big hurdles, you know, for our customers, which is the plumbing, the data quality, and actually operationalizing your data. So, you know, that's the order in which, as an organization, you need to jump, and the order in which you're falling as well. And just something like plumbing—I mean, you just said it a minute ago—LLMs, new models coming out on a weekly basis, right? The modern data stack is fantastic, you know, it's great, it's composable, but for many, it is too composable, and they don't know where to go anymore.
You know, and that results in projects which are—it's fantastic for research projects, for production projects—you know, what framework do I use? What technology? What API? It's changing on a weekly basis, on a daily basis in some cases. Hold on, I've just come in this morning—my API, you know, my call doesn't work anymore. What's going on? So, you know, one thing that we're really working on in a Progress Data Platform is making sure we've got an end-to-end story so you don't have to reinvent that plumbing.
And if you think about the strengths of Semur, the strength of MarkLogic, the strength of DataDirect, the strength of Corticon—you know, the strength of another Progress product that we're using for visualization—yeah, we have all of the elements to really make high-power, high-value applications. And the data platform strategy is essentially creating a blueprint so, as a customer, you don't have to reinvent the wheel. You can follow a proven recipe so your data projects can be integrating with data sources all the way to delivering value in a business application—yeah—as soon as possible, as fast as possible, minimum time to market, minimum complexity, minimum investment in the commodity, in the plumbing.
Because where the value lies, from a business perspective, is in the data quality. You understand your data. You are producing that data for a reason. So what is that reason? Can you model it? Can you actually identify it in context? And how can you leverage it to change the way you do business? You know, and very often, projects are completely submerged in the quagmire of choosing the right moving API and the right component for the day, then they completely lose track of the rest of the data journey.
Now, of course, I imagine there'll be some stabilization, some consolidation, and we're already starting to see that consolidation. But we need to provide, I think, as an industry, actually, some guidance on how to compose the right architecture to achieve the right data quality so you can operationalize your data, all the while maintaining security and helping you enforce governance. At the end of the day, without governance, you won't have trustworthy data. Without security, you have all sorts of breaches, reputational issues, and you'll be caught up in the crossfire of solving your data security breaches rather than solving your business problems, right? So back to square one.
So we have a lot more possibilities because we have so much choice of technology, but it's only made it more complex. So that's my takeaway from what you just said. But as a—
A vendor you're helping customers as well with the blueprints where you say, "This is what we've tried. We've put a lot of research in it. We know this solution works. Maybe you have so many other different vector databases. What is possible? We know for this type of problem, this is the best to use. This is the plumbing you can use. This is the visualization, and this is how you can build your product. If we see you have a different need, we can revisit and give you a different blueprint and then migrate from the previous one to this newer one with your new requirements."
If I understand absolutely, and one thing I'll probably jump on—you just said, "This is the best one. This is the best one. This is the best one." Well, actually, you don't necessarily need the best one. You know, sometimes the best one's actually too complicated, too expensive, or whatever—too hard to manage. It's the right one for the use case. You know, for example, we may not have the best vector database ever in MarkLogic, but because we vector as well as all of the other data types that we support, all the other query types that we support, all of the other indexing strategies that we support, it's actually the best for the use case because it allows you not only to operationalize your data, do your analytics, but also serve your data through, you know, RAG for Gen solution. So it's about how do we optimize the architecture and the product capabilities and make the right choices on the way to deliver an enterprise solution.
Yeah, I mean, it's kind of a flashback. I mean, I've just built a large language model solution as well, and I had so many choices like you said—the vector databases, the transformers, the embeddings, all of that part. And because it was very new, I thought, "Okay, with what I read, I go for just an SQL database, which is easily accessible. You can look at your data. You can see the metadata, how it works." Come on, if you didn't use MarkLogic, it's too expensive—no, I mean, I think it's a good use case definitely to look at MarkLogic with the semantics and put that in place. But you're absolutely right where I said, "Okay, this is what I feel is the best one," and I know depending on once I have the full solution built, I can revisit all the individual components and I know where we can optimize if the outcome is not what I'm expecting. But first, I need to build the solution with the individual components and then evaluate that part.
So looking at that on a more personal note, what values guide you in your personal journey, and how do these influence your vision for the future for data and analytics? Well, I think I opened with that already. It's making data and the knowledge within that data accessible so you can act in informed ways. I mean, we could call that democratizing data management. You know, it's leveraging your data—that's what I've actually tried to achieve and what I've actually worked on in pretty much every single one of my roles for the last 25 years, essentially.
And how does that influence your vision of the future? Well, clearly, one-sided and very focused on the data management and analytics, but it's about use case. It's about identifying high-value use cases, identifying where data can help. Yeah, because if you look at the way we operate today, 80% of data is unstructured. The vast majority of data that organizations are producing, exchanging, is not useful for decision-making. The 20% that lives in a relational world—that's what we put on BI dashboards, that's what our management teams are looking at on their weekly stats and scorecards. It's such a small fragment.
Here is the formatted transcript with proper punctuation, capitalization, and paragraph breaks:
---
Of the overall data landscape, we've got to actually make decisions. So, you know, changing that status quo is really the motivator here. You know, and can we bring the full context at the point of decision? And the full context comes from understanding the full scope of the data and interpreting it in the right way. So, you know, going back to semantics, that allows you to understand the context of the data from the point of—or, you know, why was it created in that way?
And some of it is technical, absolutely. And that's why we've got, you know, all the product suite that we have to help you in that data journey. But a lot of it is also data science. A lot of it is also library science—I mean, good old traditional looking at data, talking to the data producers, understanding what they mean, what they've tried to do, why they did it. And sometimes, you even today, you've got some absolutely fantastic answers.
It's a critical mindset. It's that challenging—and just what you see—not always believing. I see that as well with, you know, we have that with the ChatGPTs. You put a question forward, you get an answer, but you always need to challenge that answer. Is it really right? And you need to be sure that it is factually correct in such a way. So that demands a critical mindset of how you look at your data and how you take that information.
It's like the journalist back in the day. They were forced to just double-, triple-verify all the information they got. But now, with the speed at which they need to work, it's getting abandoned sometimes. They get a fact, and they think it's true and give that out, and then don't do the double fact-checking.
Now, thinking about that, what advice would you give to newcomers that are entering into the data and analytics space and make that really their business, their world map, to be successful?
Be curious. Yeah, curiosity is actually the number one skill here. You know, because we often talk about data mining as one of the starting points of creating your data journey, because you need to understand what you have and what it means and all those things. Yeah, you need to be curious about how data came to be and why was it produced the way it is. You know, what was meant by the author? What is needed by the audience?
Some of it is, you know, business acumen. Some of it is technical. Some of it is, you know—the bottom line is, if I look at all of my teams, the successful teams are those that are not losing the curiosity over time. You know, keep trying to discover. You know, it's ultimately—data management is your detective work, and you need to be on your feet, you know, looking, scrutinizing all the time.
Yeah, everyone could be a data citizen. Everyone is a data citizen. You know, some people might not know it yet—it's only a matter of time. But do organizations need to provide a bit more time for people to allow that exploration? Like you say, "Be curious," which is very general, but then you add onto it—it can be technical, it can be business, it can be data-related. So it's not only in the domain where you are or are a specialist, but be more holistic in being curious across the business where you're working in such a way.
Absolutely. And you know, some of the more—I was going to say interesting—some of the more successful projects that we've seen were completely, you know, organized in ways that are non-traditional. You know, we had a really interesting project which started as almost a one-man show from a doctor in a line of business.
---
(Note: The transcript cuts off abruptly at the end, so the final sentence remains incomplete.)
Um, that was actually a bit puzzled by some of the data that he was observing, and he started building models, doing things in R and doing all sorts of things. We met him in one of the interviews at that client. The client didn't even know that they had such a doctor in the organization that was looking at data. We had some fantastic conversation, and he became one of the data stewards for one of the big projects. He brought his experience of the field, broadest experience of, you know, what things mean in the context, and how you combine what the data says with clinical science, with your interpretation of how you interact with a patient to actually do essentially data science but with the human in the loop and an understanding of the human side of it.
You know, and I think that's what I mean by curiosity—always keep all of the variables, all of the dimensions of the project in mind when you're designing solutions, when thinking about the results, when you're thinking about the algorithms. And if you go at it from a purely technical angle, you might get something interesting, but is it true? Is it relevant? Is it going to make a difference? Yeah, stay interested, stay motivated, and stay energized, and you will find your answers of what you're looking for.
Uh, Matt, we're coming to the end of the show. I always close up with "data is connecting us all," but music is connecting us all as well. So I would love to hear, what is your favorite band or favorite type of music?
It's a very hard question because I've got quite an eclectic taste, so I'll give you a few elements of answer. So, I'm actually a saxophone player. I don't play a lot—whenever I got time, I try to do a little bit still. Right now, I've got a couple of scores on my stand—one from Piazzolla and one from Astor Piazzolla, so "Café 1930," really interesting, love them.
That said, you know, on the other end of the scale, tonight is actually a brief festival, and we're going with the family to watch Sting. So there you go.
Oh, he's still performing? So that's interesting to hear.
Yeah, yeah, yeah, yeah. That's quite a variation—taste of music, but really, well, this covered a lot of music with my guests which I've never heard before, so this is the fun part for me to close up.
Matt, it was so much fun having you and interesting on the Data Guru Strategy Podcast. So thank you for coming and having this very nice chat.
Thank you for having me. Always a pleasure.
