Microsoft Corporation (MSFT) Earnings Call Transcript & Summary

All righty then. Pratik, welcome, and I want to welcome everyone here in the audience as well. We're going to talk a little bit or maybe a lot a bit about data governance and how that fits in with the rest of the data stack. If the term makes you a little uncomfortable or feels a little unfamiliar -- by you, I don't mean you, Pratik. I mean the audience. Don't worry. We're going to try and get that nailed down first.

In fact, if I may launch right into a question, Pratik. And this is important to me because I've sort of been around the Microsoft data stack for a long time, and then I went out into the wilderness and covered big data, and Microsoft wasn't there yet. Now of course, it's all come together. So definitions are important. So I'm wondering if you would happen to have like an elevator-pitch length description of what data governance is. And also, because I hear people conflate terms a lot, how does governance differ from or -- and/or overlap with data security and data protection? No pressure, but there's our level-set question.

Thanks. Sounds good. I would have probably had a different definition when I came from the -- prior to the acquisition of BlueTalon into Microsoft, which is mostly in the security space. But I think as we start understanding and talking to a lot of customers, the best synthesis of that idea that I can come up with is data governance is any and all activities that are designed in a company to make sure that the consumption of data is easy, accessible. And whatever data is being consumed as broadly as possible is trustworthy. Like fundamentally, you can pivot it. Does that involve security? Does that involve data quality? Does that involve master data management? But think about -- the easiest way to think about it is, in my opinion -- and this is kind of what also resonates with a lot of larger enterprises that are trying to solve this holistically, is really describe what data the company has and then being able to say, okay, is it -- what controls or sensitivity or remediation I need to apply to it so it's consumable in a trustworthy fashion by lots of business users?

All right. That sounds rosy, but I'm wondering because every -- look, every time we hear about a new data technology, it's exciting, it's shiny and it's new. And then it comes down to implementation. And sometimes, it's hard. Sometimes, things get bogged down a bit. So when it comes to governance, where are you seeing your larger companies, your larger customers, excuse me, run into problems, if I can just sort of be blunt about it. And also, what about the practitioners within those companies?

Yes. So that's a great question and actually kind of funny. The largest customer of governance is actually Microsoft itself. So you can imagine we learned from our own internal struggles, if you will, at the time of GDPR compliance but also having talked to several hundred sort of larger enterprises that are trying to solve the problem because a lot of these organizations have recently onboarded chief data officers or somebody in that role. These tend to be VP of data and analytics, can be data stewards, governance leaders. These are the ones that tend to be practitioners. And then spending time with them, the key kind of challenges turn out to be really, even now, a lot of people run into the problem of lots of different, disparate systems, like hundreds of different systems in typical large companies. And it's -- also, these are non-homogeneous systems. Somebody may have databases. Somebody have big data applications. Somebody have stuff in the cloud. So you have a very sort of heterogeneous data estate that most of these people are responsible for managing. So what we end up finding out is a lot of people do 2 things. A, they buy 4 or 5 or 6 different products, add a lot of -- glue code in between, add a lot of engineering, even then spend a lot of time sort of appropriating human capital. If I just take the learnings from Microsoft itself, when we first started -- even prior to my coming to Microsoft, actually, the best result of that is to go see privacy.microsoft.com. If you actually look at what it took to power that dashboard, it's a way -- as a consumer of Microsoft's product, I can go in and say what data does Microsoft have about me as part of "data subject's right to request" sort of servicing. But it took us a lot of human capital to populate that. And what we learned was in 500-or-so plus systems, you needed to regularly look and crawl for the data estate, do some content inspection, do some metadata inspection to identify, does this particular system have data about individuals, is it identifiable, is it not identifiable, and then tie it to an identity. Now If you start thinking about that, even if you didn't take into account the ability to tie into individuals, just knowing where is my sensitive data versus not, that problem itself is pretty painful for people to do because it requires people to agree on a definition of what's sensitive then figure out how I'm going to actually, at scale, classify my thousands of tables in MySQL server on-prem to millions of Parquet files in cloud store, how do I sort of manually tag that. It's impossible to do it manually. So automation was the way to do that. So we, Microsoft, wrote our own scripting and coding in a way to automate that. And it turns out that a lot of people are struggling with how do you combine those things together. And being able to eliminate human capital and business process with automation, that's the only way we can make things tractable. So -- and then that's kind of our point of view on what it takes to solve data governance, the first phase of it anyways.

Yes. So you already preempted my follow-up questions there, which was mostly around automation. And because I feel like in the old days of governance, before big data was a thing and the number of systems was small enough where you could contemplate doing it manually, even if that wasn't the best idea, people did contemplate doing it manually. So -- but you're saying basically, automation isn't just a nicety. It's not just the convenience. It's an absolute necessity, I think, is what you're saying. Because otherwise, you're going to miss stuff.

It's not even that. So what we found is what people were really focusing on, which is really what hit at home, is when we talk to the data officers and stewards and practitioners really that were assigned, oftentimes, we found that people that have been put in the position of data stewards and ownership tend to be business users. They tend to be recruited into this role because they kind of know what the line of business is, what data is about there, the best qualified to make an answer about that line of business. But oftentimes, this is a secondary job for these folks. They're not like doing this day in, day out. And oftentimes, the data estate that they're going after, the lines of business in individual -- let's say one of the largest banks in the East Coast, there are 5 or 7 different lines of business, depending on how you count it. They have maybe 20 data stewards responsible for an entire asset wealth management business.

Wow.

To expect them to have these 20 people scale out the automated classification of millions of Parquet files, is not practical. So some -- but at the same time, you can't just like tell data engineers to go do that because then they'll be writing scripts all day long and going on doing that. So what we really need is some way for stewards to articulate how to classify the data in simple rules in the way that they understand, a business user can understand and articulate them, and then have software and automation and tooling take care of the manual -- I guess the hard kind of recurrent job of looking at the content, applying a tag and things like that. And that's where software is really good, right? That's what it's really designed to do, sort of laborious, continuous, repetitive thing to kind of keep doing it populated. Otherwise, what you end up happening to do is data stewards focusing what they think is the most sensitive part and then kind of go deeper in the subset of data estate, miss out the rest of the data estate, and then their view of what data the organization has is very stale or it's onetime.

Got it. And hopefully, there's a way to -- even though the humans don't have to do all of the grunt work, they're not locked out of the process. There's hopefully a way for the stewards to spot-check what's going on, make sure that's happening the way it ought to and make sure that some of the algorithmic things are looking good. If for no other reason, then I have confidence in it.

Oh, yes, yes, yes. That's one of the things we actually -- so the other thing I found responsible was there's a sense of control that people have. Like I saw this table, I'm going to tag it so I know what is there. But then there's the sense of like unease that comes in from saying, "I don't want to take the script. Is it going to catch everything or not?" So I think the other side of this is, okay, great. It's unrealistic to expect that you're going to spot-check every single thing and you're going to catch everything. What if you could really think about it and pivoted as -- at kind of a different way. Let's say if I knew the metadata about my data, obviously like across the entire data estate, in one place, it's much more compressed than data. Your 100 terabytes of data is not going to generate 100 terabytes of metadata about that data. It's going to probably be much smaller. And let's say if I could interrogate it. And if I could interrogate it, I could do assessments to say, "Okay, how -- where in my data estate is sensitive data in one place or the other? And how much of my data set is really tagged? How current is it?" So now instead of me just interrogating, spot-check individual things, I can see things that's aggregate. Then I can then focus in on one specific area, "Okay, I want to go check that." And by the way, if you happen to have it all in one place, then what you can do is you can then start explaining and communicating that, "Hey, this part of data estate, we've done good curation on. But this part of the data estate, we haven't validated. So there's kind of a workflow process and sort of continuous process management across the whole thing. You're not going to remove human element from everything, but you can do the part that -- the thing that humans don't enjoy, which is laborious, repetitive work. So that's my perspective anyways.

Machines are usually good. That's what they're there for. But yes, you can get sort of delegator's remorse if you lose all the control. Hey, you were talking about sensitive data before. And we've been reading, it seems like for a couple of years, about our new 4-letter acronyms, GDPR and CCPA, the General Data Protection Regulation in the European Union, and the California Consumer Protection Act over here, which -- and by the way, those regimes affect more than just Europe and California. So that takes us to this notion of sensitive data or PII. And I think everyone knows what it is at a high level, but -- I don't know. I feel like beneath the high level, then it gets a little complicated. Could you give us a nuanced understanding but also help us understand if sensitive data is just a thing with a formal definition that's invariable or if there's a subjective sense to it. In other words, one company's -- one organization's sensitive data may not be so at another organization. Is that a thing?

Yes. That's a leading question, Andrew, and you know it. Yes. So that's what we found...

I would never do that.

I know. I know. The funny thing is -- we found is when we first started, people had this buzzword, and there's like a whole host of companies and people trying to solve the problem of sensitive data discovery for a fair bit of time. My understanding, as far as I can humbly understand it, it basically boils down to what can I automate in terms of analysis to find out a set of data patterns that I can say is a particular one way or the other, right? And so what we found actually in trying to take this problem, we started from a really good approach. Because of our GDPR compliance journey, we had to figure out where is all e-mail addresses, where is all national identifiable things. These are things that are sort of generally transferable across most organizations because everybody who substitute GDPR is going to know, are you tracking e-mail addresses, phone numbers, marketing analytics. Like those are generally transferable. But then there's a whole set of other identifiable information like the identifier in Azure AD of a particular person's Live account. Is that identifiable? What about tokens, is that identifiable? So I think depending on which business you are, you definitely have to have a view of what's sensitive to you. Now we just took a lens from security sensitivity, right, from the GDPR compliance sensitivity. PII and PHI, personally -- health identifiable information, is -- has actually even preceded GDPR and CCPA, where you had to figure out, okay, does it contain member-identifiable numbers if you are a health care company. So I think in a nutshell, our conclusion we learned from them -- from this thing is most companies have to rely not just one regulatory regime but also multiple. And oftentimes, they get data from lots of different places so they have contractual obligations, which means some things are going to be repeatable. Some things are very specific to that company. Some things are very specific to that industry. And you have to account for all of those, so which means that not only do you have to jump-start somebody's GDPR compliance journey with sort of pre-built-in classifiers, but you also have them have to provide end users and end companies an ability to define what's sensitive to them. Now you can't make it super complicated. So if you have 6,500 different classifications at some point, you're -- no one's going to be able to act on top of it. So one thing we learned from our Microsoft information protection journey is people take a look at classifications, facts, about the data that this is an e-mail address and a personal -- first name or last name. Those are facts. How can we combine together rules that say, if I find a first name and last name or an IP address attached to a first name, that should be considered as sensitive or public or confidential or business. So these kind of distill down to 3 or 4 different sensitivity labels and levels. And we have found just heuristically from people doing this on their productivity data for a very long time -- is that model of a few aggregated sensitivity definitions built on top of lots of facts about different types of data works really well to be specific about sensitivity so you can take and act on it but be aggregated enough so they're meaningful in sort of a business conversation.

Yes. It sounds like getting to that balance may be the whole zen of this. Since you were talking about -- since you're talking about journeys, compliance journeys and governance journeys, the more I've read about the GDPR and CCPA, the more confused I've become about what compliance really is and the more confused I become as to whether that's really defined out there. But I imagine Microsoft must have had to say, "Okay, compliance, as we're going to define it, is this." So I don't know. I'm wondering, a, if that's the case; b, in general terms, what compliance looked like in terms of internal goals. And also, you were talking about kind of the distribution of the data estate. I know from working with Microsoft for years, there's not one Microsoft. It's lots of different companies. It's lots of different teams, each with differing kind of standards. So I imagine there's got to be so many databases, data marts, warehouses, data lakes. And I know this would never happen, but maybe even stuff in Excel files, maybe even in those old Access databases. So how did you hurt these cats?

Yes. So actually, the funny thing is there's peers of mine on our team that run the entire business of figuring out what it means to be compliant with GDPR for Microsoft because they run the operations of that privacy.microsoft.com dashboard I was talking about. That's run under sort of our Azure data governance team, peers of mine who can operate that. Now if I -- when I first arrived to Microsoft, I asked the team like how do we even tackle this. And if you want to really find out -- either feel good or find out how about hairy situation here, there were lots of lawyers involved trying to figure out what exactly it is. And then by the way, this whole journey started prior to 2018 when the laws became effective. So we have some time to figure all this thing out. But in sentences, it was a lot of communicating with different stakeholders and organizations inside the company to see, "Okay, what does identifiable mean? What is a user identifier? Is this data subject? What do the obligation assessments look?" After climbing to that journey, in a nutshell, I think the synthesis of that journey is first step starts with mapping and identifying whether certain piece of data contains identifiable information or not to the extent that once you can figure that out, then everything else kind of flows from that. Once you figure that out, then you can start doing data subject access rights request to say, "Okay. Somebody is going to find out what data does my company have about it. I can only answer that question once I've classified it." So in my opinion, there's 2 or 3 or 4 different types of obligations you have to service in order to be compliant with GDPR. But in essence, it all starts from, do I know very specific identifiable information about somebody, in what format and what's the scope of that or not? If it is, great. I can put that control in that subset. If it's not, then I don't have to deal with it in a certain way. As far as I can synthesize using my non-lawyer brain and experience -- sharing the experiences with our peers...

Yes. That's why we have you here as a guest. Otherwise, it would get unruly. Yes. Go ahead. Sorry.

I don't have...

So cool. Now you were also just kind of talking about -- well, all of this activity -- I mean some of this is technology, some of this seems to be practice, and some seem to be precedent. And I was going to thank you, by the way, because I think a lot of smaller companies are waiting for the bigger companies to do enough trial and error with the EU and with California to actually get to some publicly understood sense of what compliance really is. So you guys have been guinea pigging that for us, and we thank you. So that's a good thing. But how -- in addition to setting the precedent, how did you take all of that internal activity and kind of bottle it and productize it? And we have had this thing on the Azure Cloud for a long time called the Azure Data Catalog. Now we're in preview with Azure Purview as something I assume you know a little bit about. By the way, it's very awkward to say Purview preview, but I'm getting used to it. So to what extent did -- I mean they're very different kind of products and platforms. To what extent did the internal activity influence the paradigm shift from one to the other? And in general, as I said, how do you take your experience and kind of -- I don't know, capture it in a product that just feels not so easy?

Yes. And I think you're absolutely right. It's a kind of funny thing. It is now within my purview to talk about this new holistic data governance solution that we've created. Now so basically, to -- simply put, our first thought was a pretty naive one. At Microsoft, we are very client-oriented, if you couldn't tell that from all our conversations. But the idea was, okay, the step 1 was cataloging the data. The Azure Data Catalog, the first version of it, is actually on Azure Portal right now. You can go provision it. It's very limited. It didn't have unlimited classification. You could only have one. So it was really a way for us to figure out, okay, final results of the outcome of classification we could store in one place. That was the original idea. But as we started learning from it, we realized that what customers and people really needed to do was find out the automation around it. So that kind of kicked off a whole journey inside to say, "Okay. We built this automation of scanning classification." Every sixth hour, all of our data estate gets refreshed and cataloged again so that we can classify that. So our sort of classification scheme is current probably up to 6 things, and we're operating on sort of millions of records of data. We service about 17 million on subject right request every day. So if you kind of look at that scale, we realize that we have to build some capabilities and technologies to service our internal base. Then we realized like we actually have a Platform as a Service platform, Azure, to kind of provide that. So then we started with creating something called Purview, which is -- it started with a way of creating a data map, a graph of all the data estate. So we created a platform that built that. Then we added to that a serverless capability to automatically scan and classify data. And then we put user experiences on top that are in that business users. And this learning from our journey with Azure Synapse, which was taking multiple, disparate, connected activities for data engineers, data wrangling, data prepping, data serving with technology then putting kind of an integrated experience across all of them. So we used that experience to create a PaaS offering as well for data governance. It's called Azure Purview. Now the whole idea here is that today, we allow you to automatically scan and classify or create that data map, experience it through self-service data access, self-service discovery of data. Over time, once you have the data map, then you can imagine for us building security compliance controls or assessments, data quality assessment, master data management things. So those are the things that we are developing right now as we speak. And in fact, part of my -- the reason -- or the logic for acquisition of BlueTalon was, "Hey, instead of buying a data cataloging tool, a data security tool and a data quality tool and an assessment tool, could we build those inside?" And by the way, BlueTalon, as a stand-alone company, was great, but you actually still have to go through the installation step of adding that. Now with BlueTalon acquired into Microsoft, we can take our cataloging journey and then embed the agents inside of the data services we own ourselves that allows us to give a better, more seamless experience back to our customers using our data estate. And for the customers that are using things like Teradata's or Oracle's on-prem, we can leverage our open-source heritage, Ranger, Apache Atlas, to kind of reach that coverage. So this is going to be a multiyear journey. It's not immediately accessible. It's not a light switch. But over time, our aspiration is to simplify that journey for everybody as a whole.