 And welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining today's DM Radio webinar. Leave IT alone, the best value of self-service sponsored by Looker. It is a deep dive in continuing conversation from a live DM Radio broadcast a few weeks ago, which if you missed, you can listen to it on demand at dmradio.biz under podcasts. Just a couple of points to get us started. Due to the large number of people that attend these sessions, you will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the upper right-hand corner for that feature. For questions, we'll be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you like to tweet, we encourage you to share highlights or questions via Twitter using hashtag DM Radio. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session and information requested throughout the webinar. Now let me turn the webinar over to Eric Kavanaugh, the host of DM Radio to introduce today's webinar and speaker. Eric, hello and welcome. Well, ladies and gentlemen, hello and welcome. This is Eric Kavanaugh, your host for the DM Radio deep dive. Yes, indeed, the title is Leave IT Alone, the vast value of self-service. I'm still cracking myself up about that title. I kind of like that, Leave IT Alone. We don't want to leave IT alone, obviously, but the general idea here is that we're moving in the direction of self-service. And we're going to talk about why that is and what the perks are of going to a self-service model, as many of you may have heard. I love this old maxim. It says something, but the fact that the achieving simplicity is actually quite complicated. There's a lot you have to do underneath the covers in order to deliver an elegant and robust and governable self-service solution. So we're going to talk about all of that today. So features speakers, Kenneth Kunanan of Looker. I love his title there on LinkedIn, Looker of the People. That's good stuff. It's yours truly on the right-hand side. Feel free to hit me up on LinkedIn anytime. Let's talk about where we have been and where we are today to set some context. This is a big data landscape of 2017 by first market. You can see there are tons and tons of companies on here. These are all the different companies that are somehow some way involved in big data. And the final show in a second is even more complex than that. So why am I mentioning this now? Well, if you think about self-service analytics or as we used to call it business intelligence, the bottom line is you're trying to analyze data to understand patterns to see where things are going. Well, in the old days, meaning five and 10 and 20 years ago, there weren't that many systems that you'd be pulling data from. You'd pull from your ERP systems. For example, your enterprise resource planning system. You might pull from your CRM system, customer relationship management. You'd pull from a few different systems to get that strategic view of your business. Well, compare that world. Let's say five, even 10, or my goodness, maybe 20 whole sources of data pulling into a data warehouse. Compare that to this landscape. Well, we're talking hundreds and even thousands of sources of data. Well, guess what? All these different sources of data have their own different systems. They have their own different data models. So the data is nested in different ways, and that can make life somewhat complicated. And we're also going to talk a bit about ETL versus API today on the call. ETL, of course, is the way of extracting, transforming, and loading data into a data warehouse. We'll get to that in a few minutes. APIs, Application Program Interface. Well, that is the new reality for cloud. Lots of companies are building these REST APIs. I love REST, Representational State Transfer. I think it's what it's called. And if you remember, that was one of the options years ago, and it was not supposed to be the one that was going to win. We used to suggest that SOAP was going to win simple object access protocol. But REST seems to have won the day since the primary way that companies are developing their APIs. Well, so this is the big data landscape. And look at this next slide coming up right here. I used this one on our last webcast. That's the Marketing Technology Landscape, or the MarkTech 5,000. Just 10 years ago, it was something like the MarkTech 300. And it was the 500 the next year. It was up to 1,000. Then it was 3,000. Then it was 4,000. Now it's 5,000 different companies that are doing automation for marketing, for online marketing purposes. This is extremely complicating. If you can try to imagine figuring out how all this stuff works, pulling data from all these sources, right? Well, what was the old way? So many of you know the star schema versus the snowflake schema, or that meant a different direction here, snowflake on the left, star on the right. These were the data warehousing models. But let's think about why we were doing data warehousing. And this is one of my favorite images used from the moving network. I'm mad as hell, and I'm not going to take it anymore. In the earliest days of DM radio, I would ask vendors and end users alike, when are we going to stop the madness of all this ETL, of moving data from this system to that system, moving data from that system to this system? You can imagine that over the course of 10 or 20 years, in a large organization that has lots of data sources, ETL scripts become like spaghetti mayhem. There are tons of ETL scripts everywhere. And every time someone wants new data in the warehouse, you have to do a new ETL script. Well, what happens? Obviously, there are mistakes made. There are errors, there are human errors, and there are some batch windows that aren't met. Things happen, and the data just doesn't get there. So, but this has been the standard. This has been how we do data warehousing and get business intelligence and analytics and so forth over these many years. Well, we have to remember that, first of all, trust is the core stone of any data-driven business. So, if your users don't trust the data, that's going to be a real problem. And trust, when it arose, is very difficult to get back. Once you lose somebody's trust, it's very difficult to regain that trust. And the same is true for data. So, if you think about, and again, this is just a bit of background setting here, how we got here, well, we had to design ETL systems and data warehouses the way we did because of old constraints. Stores used to be very expensive. Processes were slow. Network pipes were thin. And of course, consolidation, when you had only five sets of data or five systems you were pulling from was actually feasible, that was possible. As you start looking at the reality of today, where you have hundreds, and again, even thousands of different systems that you want to pull data from to get, for example, that customer 360 view. Or just to understand the overall positioning of your company in the marketplace. Trying to figure out what your competitors are doing. Whatever the case may be, there are so many more sources of data. And the bottom line is that the old model for data warehousing is simply not going to support these heterogeneous environments anymore. It's just not going to happen. And so what we're seeing is a bit of a trend now of leaving the data where it is. You're still going to have a long tail on data warehousing on ETL. All that stuff is going to be around for, I would argue, for decades, if not longer. The models are going to change a little bit. We're starting to see companies like Snowflake, for example, doing cloud data warehousing. Amazon, of course, has Amazon Redshift. And there's this also gravitational pull to the cloud, right? So we're going to have this hybrid cloud situation. And the bottom line is that moving all your data into a data warehouse just to enable analytics and then ultimately self-service analytics, that's just a non-starter going forward. You're going to need to find ways to federate queries, to pull data in virtually to enable decision-making and analysis. So things are changing. They're kind of changing pretty quickly. It's a long lead-up, a long on-ramp, I suppose. And now we're on that highway, and the cars are moving really, really fast. So things have changed, and we need to recognize that. And here's the last slide I'd like to throw out to you folks just as a way to set some context before we bring in my comrade Kenneth Cananen from Looker. I just saw this slide on a webcast this morning. So this is me being relatively agile. You can see the source down there. Interest site did some analysis of the S&P 500 and how long companies are on the S&P 500. So if you look at this, it's going up and down and up and down. But the point is the amount of time before you are disrupted as an organization and bumped out of the S&P 500 has collapsed. It used to be 30 years. It got up to about 40 years, and now it's down to 15 or so years. And at one point you can see it's down to about 12 years a few years ago. So what does that mean? It means that the status quo is changing so quickly these days that if you do not adapt, if you are not agile, you're going to get disrupted. I think of the classic poster children, Uber, Airbnb, and LinkedIn. And one of my favorite examples for those of you who are over the age of 35 or so, remember that whole publication called Who's Who? It was a publication called Who's Who? And you had to pay like, I don't know, 50 bucks or something to be listed in the Who's Who and it was very prestigious or so they said. To be listed, well, where's Who's Who today? It actually does still exist, but nobody knows about it because LinkedIn came along and disrupted them right out of the ballgame. LinkedIn is now the de facto standard for knowing who is who and which organization. It's amazing, LinkedIn is absolutely pulverized of Who's Who business model in the same way that Uber has just sent the taxi business reeling. And I have some personal experience in that space. I'll tell just very quickly an anecdote before we bring Kenneth in. If you think about how disruptive Uber is and they certainly have their issues from a corporate culture perspective and that's going all the way back to the beginning of their strategy because obviously they plan to spend a lot of money on lawsuits and fighting lawsuits from cities and organizations. But I have a friend who is in the taxi business and he got his medallion in New Orleans about 10 years ago I think and he paid something like $30,000 in cash and the transaction was between two cars in a parking lot at like two o'clock in the morning. Okay, that's not very transparent. So you can think about how excited he is about Uber. He's not excited at all. But what Uber did and what Airbnb has done and what LinkedIn has done and all these innovators from this most recent wave of cloud-born companies, they did several things. One, they focused intensely on the value of data and analysis. They focused intensely on building bulletproof infrastructure to be able to handle web-scale functionality, web-scale needs. I mean just to fact in on Uber and now some of these other services you can see where your driver is coming towards you. Think about how that changes the game compared to just waiting in the dark and hoping that your taxi driver would show up to get you to the airport on time. Well, and I recall this just a few years ago, three or four, but I wanted to help out my buddy. I said, no, I'm not gonna Uber. I'm gonna call the taxi company. And so I did and I got a busy signal and I called back and I got a busy signal and I called back again and I got a busy signal and I called back again and it rang and rang and rang and rang. And finally I said, what am I doing? I'm gonna call Uber and I got myself at the airport. So the point is that if you are not embracing data and analytics and really digging into it, you're gonna be in a lot of trouble and frankly the new wave is self-service because IT is simply not gonna be able to handle the amount of work necessary to cater to all these needs, to cater to new data sources, for example, to change the models, to do whatever. We need a new wave of analyst professionals who have the tools and technologies to serve themselves to figure out how to use this stuff. And that requires a lot of different things. It requires a whole new user interface, a whole new appreciation of UI. And this again is one of the new innovations that's come about just the last 10 years or so thanks in large part to mobile phones. Mobile phones to smartphones fundamentally changed how developers look at user interface and thank goodness for that. We're still a bit sort of in a disruptive period right now with respect to all that. But the bottom line is that developers and software companies now have a much greater appreciation for the importance of the user interface, a graphical user interface because there's less real estate. So what happened is developers had to decompose business processes and really get down to brass tax about what functionalities required at which point in the process in order to effectively guide the user and that's what you need for self-service. You cannot have the circa 1999 Adobe Photoshop user interface where you've got 13 options across the top menu and like 30 to 70 options down each file menu with even suboptions beneath those, you can't, that's just a labyrinth. You're not gonna be able to expect users to train for six months just to use some tool. UI must be intuitive these days and that's the direction that we're going. And with that, I'm gonna hand it off to Kenneth Kananen who's gonna tell us about what's going on these days. Kenneth, take it away. Hey, Eric. Eric, thanks for having me on. It's really great to be able to talk about this super important concept I think and kind of do a little bit of a deeper dive on this as well. So just a quick word about me. My name's Kenny and I'm the product marketing manager and analytics manager from Looker. And basically what Looker is is a data platform that makes it very easy to provide self-serve analytics to your users while also keeping a data governance around that self-service as well. And so we're gonna be talking a little bit about kind of in this section, what are the kind of market events that have led us to kind of realize this technology now and kind of what can you do even if you don't use a platform like Looker to kind of extend self-service to your users in your analytics organization. And so one more thing also is that I came from the support organization of Looker actually and I was very fortunate I think to come from that organization because it allowed me to really understand I think a lot of the problems that IT managers face when they're confronted with attempting to scale their analytics to their users. And so hopefully I can kind of share some of those little anecdotes as well along the way. Great. So in this presentation we're gonna try to answer three very basic questions around the notion of self-service. And they are how do we get here or what changes in business and technology practices have occurred in the past 30 years that enables to talk about self-service. Number two, what has changed? In terms of what has enabled us in terms of technology to change our business practices to operate in this way? And then three, what do we do about that? So what can we do now in regards to self-service that we couldn't do before? All right, so the first question is how do we get here, right? In the beginning it's really hard to, like, this is a hard-close graph given that databases and data warehousing concepts are very complex to the normal person but databases and even SQL were created actually to make accessing data easier for the end user. And so, you know, we can answer the question how do we get here by kind of taking a step back and looking at where we came from in the database and business intelligence market. So we can kind of go all the way back to the early 1970s when the relational database model was developed by Edgar Codd. And the relational database model was basically a way to separate the machines that stored the data and process the data from the applications that actually ran on top of that data. And so what that meant was that, you know, people were building applications that when people are building applications they don't necessarily need to know how the data is organized in the machine itself. So that was a huge boom for application programs because now you have this standardized way of writing and reading data to the database. You know, you had this way that there was now a model that extracted this sort of, you know, this very complex way that data was organized in the physical machine into things that people could understand like tables and rows. And so that made it very, very easy. It was a huge improvement from before where data was organized in things like file systems, right? And so, you know, Donald D. Chamberlain and Raymond Boyce actually improved on this by inventing structured English query language, which later called, of course, SQL. And this, again, made it even easier to access that data stored in those databases by developing a standardized language that looks a lot like the English language. And it's designed for that exact purpose. If you wrote a SQL query, it would look kind of like a sentence you would just ask a person around, you know, requesting data, right? And so what that makes is that it further abstracted the language that was necessary to work with this, to work with these databases into simple English phrases, right? And so what you can kind of see, you know, just starting along this path is that working with data, all of the developments in database technology and this intelligence technology are getting, are constructed in order to serve the user better and to actually make this technology even easier to work with. So kind of building on these developments, right? You had, in kind of the late 1980s, you know, composite BI stacks and monolithic BI tools, like micro-strategy and business objects. And of course, you know, these were really meant to provide a way for business users finally to access the data. But the data was also in a central and governed way, which meant that if I was a business user and I was accessing data, I knew that I was accessing a single source of truth that was centralized and also that was curated and monitored by the IT team, because it was the IT team that actually built and managed these tools. But, you know, of course this was subject to the limitations of the error, right? Because, you know, as Eric was saying, the database technology of the past was very slow. It was complex. It was hard to use. It was expensive. And so, you know, the data, of course, in these systems was rolled up and aggregated, and business users could only ask specific questions that IT analysts or the IT for the business, the BI managers, had programmed into the tool themselves. So it was, they were a little bit limited in terms of how they could actually access that data and what questions they could ask. So it wasn't a full self-service, but it did do a long, it wasn't a huge step into making the technology a lot easier to use and making data less scary and more accessible for the business user. And so it was a huge step forward for self-service. And so then, you know, in the 2000s, in the early 2000s, even kind of late 1990s, you know, everything kind of got blown apart, right? So our CEO, Frank, likened this basically to an exploding whale on a beach, right? So you had all these sort of composite BI facts that were sort of limited by the technological limitation of databases, but you also had, you know, due to the personal computing revolution, this growing comfort and growing familiarity and almost demand for more data-driven decision-making. And so a lot of self-service tools like Tableau, Excel, CLIC came as a way and as an answer to sort of sidestep the constraints of those traditional database models, right? And so they began to get traction in the 2000s. And so, you know, they did a really good job of circumventing the database, right? So no longer did business users have to wait in line or in a queue for their IT analysts to deliver them data or even, you know, waiting for them to code a specific, you know, question framework into their composite BI fact, right? Now what they could do is they could simply ask to pull a subsection of the data, a thumbnail, if you will, of the data, and then they could perform the analysis locally in spreadsheets or Tableau workbooks. And these were great because these tools were fun. You know, they could be run locally in your computer so they're snappy and quick. But of course, data governance was lost, right? You know, now, right, instead of having one centralized, you know, business intelligence tool where everyone was kind of working around the same tool and building on the big platform, you now have almost an explosion of workbooks and spreadsheets, right? And it becomes very hard to manage that and also kind of almost see through the lines there, right? So if you had a bunch of people coming to a meeting and you had finance that pulled one sort of extract from database, you had marketing pull another extract, you had sales pull another extract and they all did their own separate analysis. They came to the meeting and they were trying to perform the analysis on the same number, right? They come to me with different numbers. It becomes very hard to say not only who's correct in that situation, but also how do we even find out that right answer, right? Because there's no centralized mainstream of business logic there. So what, you know, development and cloud technology in this time also tried to answer that as well, right? So, you know, you've had data sources like Salesforce, Vendesk, Mixpanel, Google Analytics that actually start developing their own analytics within their applications, right? And so they was meant to be a form of self-service to the user. So like instead of actually providing, you know, in ETL it's your own database, you could just look at the analytics on the application that you were using. And so that was great, but, you know, over time it kind of provided users with this ugly trade off, right? So either you got all of the data, right? And you got it all uniform so you could take your Google Analytics data from this panel, you could take your sales data from Salesforce, your customer data from Vendesk and combine it all together into one spreadsheet, right? But of course that is not governmentable, right? And you don't have necessarily a system that organizes that and governs that. And then you have on the kind of opposite end, you know, this super tightly managed, you know, industry-leading analytics on these data sources without any way to really, you know, change or act or organize that data to your liking at all, right? So you were very limited as a business user between these two different paths. So, you know, and so, you know, now you're thinking, okay, well, that timeline, Kenny, that you just showed was 20 years ago, right? We're in the year 2017, almost 2018. What has changed in the market since these business intelligence tools like Tableau and Click have developed, you know? And so the answer is that a ton of things are different, right? And first and foremost is that we're now living in an age of modern databases. So remember that BI tools were created to escape and circumvent the limitations of databases in the past, right? So, and that was because databases in the past were very slow, they were not performant, they were very expensive to use. And so it really meant that you could scale that performance across the entire organization because of course that would either be too costly to manage or it could just be way too complex to manage as a user. You know, and people that have been around for, you know, a couple of decades know and understand the pain of running a pretty complex query against one of these, you know, legacy databases. It would take hours, sometimes even days, to run a query against that database and return and return a data set. And so now we see databases are extremely powerful. You know, they're massively distributed. They have, they can scale nearly instantly on the cloud and they're also being repurposed as services. So it's kind of built off of Eric's aerosanology of Uber, right? As a disrupting technology. Like you think of databases of the past as buying a car, you're essentially buying an appliance, right? You're buying the mainframe, you're buying the software to run it. You're buying also the person that has the specialized knowledge to run that. That is only a huge capital expenditure for you for an organization that might be doing data polls, you know, a couple of times a day, right? That will not necessarily, and will definitely not be using that database consistently 24-7. And so, you know, think about it as, you know, as you would buying a car, right? Like a car is a great, you know, it's a great investment if you're the longer you drive it, right? But of course, the longer you drive it, the more hours you rack up on it, the more it has to be maintained. It doesn't, it's going to break down eventually, right? And so now what do we have as an answer to that? If you, let's say, live in a big bustling city like San Francisco where parking is bad and you can't afford a car, right? Well, now you have Uber, right? Uber is repurposed as a service where you don't necessarily buy the car. You buy, instead, you buy membership to a service that allows you to get a car on demand anytime you want. And so that's really what databases are right now. So, you know, you have databases like Snowflake and like Big Court and like Amazon Redshift where instead of actually buying the database, right, you're not buying necessarily the machines and nodes that are required to run your queries on, you're instead buying the processing power that is needed to run a specific query at a specific point in time, because databases are now sufficient because they're basically millions and millions and millions of nodes of machines. And so because of that, they can scale out to however many people or however many people or queries are needed to run on them. And so as a result, they can be repurposed as services and as a result, they're a lot cheaper for the end user and for IT analysts now. And so what that means is that we can now couch all of our analytics on those databases. They can handle that load for us. The second part is that we're also now living in the almost a new world that understands the importance of data. And, you know, this we can actually give direct credit to the business intelligence tools of the past. And also, for example, and also the personal computing revolution, right? A lot more people are data savvy and technology savvy than ever before. And that means that there's a lot more data literacy out there, right? So that means that there's almost a demand and a hunger for more insights around data. And that's a really, really good thing. Because what that means is that you have more and more people that are gonna be more receptive to data. On the other hand, you also have this explosion software applications like Zendesk for customer success, like Lever for recruiting, Sales Force for Sales that capture more and more of your interactions as a business user on a day-to-day basis. So that means that more of your interactions are trapped and therefore can be measured and optimized. So because you have this sort of nice confluence of, you know, an increase in data captured through these software applications and an increase in data literacy and data demand, that brings a really good, it's a really good breeding ground for a new technology to arise. And so what this means is that we can also start building on these lessons from the past. You know, the tools of the past actually had a really, really great answer to the technological limitations that they were confronted with. And so as a result, they actually had a lot of good ideas that we can now start implementing for modern data platforms of the future, right? So the first one is, you know, taking this idea of a single source of truth. Composite BI stacks, like MicroStrategy and Business Objects, got it right in the sense that you absolutely need one source of truth that allows you to govern that data and to kind of to codify your analyst business logic in one place. So that is a huge, huge aspect of those tools that they got right. The reason why those tools weren't effective, necessarily, is because they were, again, were limited by the constraints of the databases of their time. And so they had to roll up their data into OLAP cubes and aggregates so that they could be accessed without, you know, construing too much cost in the database itself. The second lesson that we can learn is data discovery. And so that's really great from an organization that is, you know, for example, like Tableaus or the Clicks of the World, right? Giving the data to your business users so because they are the ones that are gonna know how to work with it the best was a huge, huge revelation that came from tools like Tableau and Click and even Excel. And so, you know, that idea of, you know, making sure that your marketing people have access to marketing data so that they can define their own KPI is a huge, huge, is a very, very important thing for those things that we need to take into account for modern business intelligence platforms. And the final thing is self-service. And so this is actually more from these data applications, right? Like Salesforce or Zendesk that have built-in analytics into their systems, right? And so, again, they make it very, very easy to see, to show you, for example, here's what your KPIs are and here's how to access them. It's a very streamlined user flow to access and get information and value out of those KPIs on those services. And so what that basically means is that we combine all of those. We can actually, we can then kind of make a data platform that works for everyone that provides a single source of truth and leverages the power of modern databases to enable self-service and data discovery. But here's where I'm gonna do a little bit of a turn, right? Because a lot of people really falsely equate this idea that technology is, like, if we have the right tool and if we have the right platform, that's it, our problems are solved. And I'm here to tell you that technology is not gonna solve everything. It's not about, you know, a lot of people think self-service is really like a kind of autopilot where IT can just drop the technology in the hands of their business users with, you know, minimal training and the business users are gonna instantly get it and there's gonna be instant adoption. And we've seen that that's not really the case because you're always going to really need people to tune, maintain, and manage the technology. That's never gonna go away. And so, you know, with that, you know, you wanna kind of think of accessing data or constructing a tool that's accessing data as grocery lines, right? So, you know, in the past, right, you had, if you take grocery lines, right, you have a cashier and cashiers, unfortunately, are not able to scale very well with the demands of people wanting to buy groceries, right? So if there's a huge sale or if there are, you know, if it's like the end of the work day and everyone's, you know, packing the grocery store, trying to get food for dinner, there's gonna be a long, not blind. And so, a lot of processors are solving this by using self-checkout lines, which allow those people to individually check themselves out and therefore it actually reduces the amount of human capital that is necessary to check an individual person out. And so, it's a really smart solution. But you also have to remember that there's not just machines that they've given to the grocery store and the people that are in the grocery store and saying, hey, this is it. Go ahead, go crazy, right? There's always a person on hand to manage those self-checkout foods. And that's really important because there's always gonna be those people that need help, you know, checking the groceries out. They're gonna be people whose credit card gets declined for some unknown reason or people that maybe need to be trained on how to use the individual checkout lines because they've never seen it before. Or maybe there's no materials and therefore that person needs to be on hand to grab more materials to make sure that they have shopping bags to carry the groceries out, right? So there's a bunch of reasons why you still need an individual person, a human being, that is technically savvy and able to manage those individual grocery lines. And so that's sort of how we see self-service is that it's not necessarily this idea of air-dropping a technology or a business intelligence tool into the hands of your business user and saying, all right, go crazy, that's it. Call me if anything breaks. It's really this idea of building a tool or having a tool that develops a relationship between IT and business users. And so the title of this webinar is really interesting, right? Leave IT Alone. And really, what I kind of see as leaving IT alone is you're leaving IT alone for the mundane requests, right? The requests that you should be able to do yourself, right? So if you think about what an IT person does without a truly self-serve solution, right? They're writing SQL queries, they're making data polls, they're maybe sending data from one place to another. Those are things that with the proper tool, the proper data platform, business users can do themselves. They can ask their own questions and answer their own questions with that tool. But what will always still be necessary is IT analysts will still always have that business logic. They'll still be the experts in that tool and also on the business itself. And they'll also be experts on the data sources. So if I'm a business user and I'm curious, for example, about if I see this technology that allows me to kind of answer any question I want, the first question that I'm gonna ask of that tool is, well, what question do I wanna ask, right? And that's what the IT analyst is there for. They're there to help train people not only on the tool itself, but also on the effectiveness of answering your own questions through that tool. And so that's gonna be kind of what we talk about. That's what I'm gonna be kind of closing with today in this next section of, well, so now that we have this and now that we have these sort of principles outlined for an effective organization, but we also have this awareness that IT is not going away anytime soon and in fact it become more important than ever. What do we do about that? How do we empower both IT and our business users? And so I'm gonna kind of give two things that you as an IT person can do, but also that you as a business user can do or get prepared to do in this new era of self-service. That is also robustly governed. And the first is to build trust in the data, right? That is super, super, super important. And again, Eric touched on this as well at the beginning because this is something that we're saying more and more with self-service tools, is that they simply don't allow for business users to really to build the right amount of trust in the data. And so we're gonna talk a little bit about how we can do that. The second thing is we wanna train our business users effectively. And what that really means is not only training them on how to use the tool, but also you wanna start understanding how to train them on why they wanna use the tool. Because the more people that are making, the more decision makers in your company that are using data to make those decisions, the better off your company is going to be. And so it is in your best interest as either an IT manager or a business intelligence manager to train them effectively on how to appropriately ask those questions of that tool. So let's first touch on building trust in the data. You know, the first thing that we need to note is that there's a couple of components to this, right? And these are outlined here. And the first thing is that everyone is accessing the same model. And what that means is that you're no longer having these multiple different areas that all contain disparate sources of business logic, right? Everyone is accessing the same model, which means there's a single source that can be verified or can be debunked. And that's really, really important for building trust because building trust is not about getting this right all the time. It's about identifying when there's a wrong answer or the KPI is wrong or the metric is wrong. You can trace that back down to a single line of code in a model and say, oh, this is where we got it wrong. This is, and altering that business logic and then having the correct number reflect and seeing that percolate down from the model to the actual numbers that are delivered to your business users. That's super, super important. The second part is that to build trust in the data, the analysts need to codify their knowledge. And notice that analysts codifying their knowledge is not necessarily this idea of getting your information, the information out of your analyst's head and into a tool. That's super important for self-service. But for trust and to actually build trust in the tool itself, codifying the knowledge of your analyst actually takes on a completely different meaning because it allows you to see what the actual business logic is and parse through that in one place. So if, for example, you ask your analyst or an analyst from a third party, for example, to provide you a metric and they give it to you and they give you this number, right? You're gonna ask, how did you come up with that? And maybe you'll understand it, maybe you won't, but the bottom line is it's all one to be in their head, right? If you're using a centralized model or centralized platform, you're actually able, analysts are able to codify their knowledge and business logic into one place that you can then parse and debunk if that knowledge is wrong. And so you can continuously update it and have those changes percolate through the model. So finally, sorry, the third point is that the logic, this business logic all also lives in one place. And the reason why that's important is that you get things, what you get benefits of centralization that you don't get with decentralization. And the first benefit is verse control. And so you can kind of think of this very, very similarly to Google Docs versus Microsoft Word, right? If you have a Microsoft Office document that you're sending, let's say if a locally run version of Microsoft Office, I'm not talking about like 365 Cloud. If you're running that locally, right, and you're making a change in Microsoft Office and you're sending that over email and your colleague is making a change and sending it back to you and then you're sending it to a third person. Did we lose you? No, so here. Can he? Sorry about that. There we go. Yep, sorry about that guys. So were we at verse control? Were they sending it off before then? Yep, you know that was right as you were saying that. No, it was, yeah, thank you. So the idea of having a version control model means that when you're sending a Microsoft Office document between, to all of your colleagues, what that eventually means is that you're not gonna be able to manage those changes in one place. When you use Google Docs, for example, though, every single change to that document is managed in a separate version that is saved in that document, which basically means that every single change you make is tracked and can be rolled back. And that's super important because if you make a breaking change in that document, for example, like if something happens and your cat jumps on the keyboard and you delete everything, right, you can easily roll that change back. Even if your computer is gone, because again, it's a host on the cloud, there's one version of it and all of those changes are tracked. You can't necessarily do that with a Microsoft Office document. You can roll back to a previous version, but if you've made substantial edits before then, all of those edits are lost. And so in a business analyst context or an IT context, this is actually super important because, again, once you're codifying your knowledge in one place, you're able to ensure that no change is actually lost and so that nothing breaks the system permanently. So if you make some kind of breaking change, those changes can be rolled back immediately. Or if you make a change in the analytics, if you make a change in maybe the business logic that you're using, those changes can be rolled back if there's anything broken. And so that also means that everything's auditable. When everything's in the same place, you can manage changes a lot easier there. And so finally, what this all means from the tied together is that it keeps everybody on the same page. So then kind of like if we're walking over to training users effectively on your data, this is also super, super important because, again, it's more than just empowering your analysts to codify their knowledge and delivering that to your users. It's also about making sure your users understand how to ask the right questions. And so I'm taking inspiration here from Carl Anderson, who was one of the head of analytics at Warby Parker. And Warby Parker actually is a really interesting model because they actually opened up their analytics to their individual store managers. So I mean, these are people that are managing Warby Parker's stores that are then getting up-to-date information on sales, on foot traffic in their stores that allow them to make on-the-fly decisions that will make their businesses, their individual stores, and kiosks more effective. And so the best way to do this, in my opinion, is to actually construct a curriculum that is built off of your users. And so here's a rough example of a curriculum that we're thinking through at Looker. So for example, we have data sources. So training your users on what are the data sources available to us and which ones are most relevant to you? Your users on data storage, right? So where does the data live in our organization? And how does it get there? So what are the databases that hold our data constructor data? And how do we transfer from one place to the other? We also have data access. So what are the different ways that you, as a business user, can access your data? So do you access it through Looker? Do you access through Excel spreadsheets? Can you access it through Slack? And then finally, why might we want to access one data one way or the other? What are the relative benefits of accessing data in one way or the other? Then you have data analysis. So then this is extremely important because it trains your users to ask the questions. How do we ask proper questions of the data? And what questions should I ask being in this role? And then finally, communication, which is a couple of things. It's both, what is the best way to visualize this data? And then finally, how do I present my findings so I don't extrapolate or stretch an interpretation? How do I provide feedback? Also, to my IT analysts and IT department, to make sure that they're aware of where things are breaking in my software. And so with that, that's kind of the main sort of central focal point of the presentation is that at the end of the day, there's never going to be a system that allows you to just airdrop technology to your business users. It's always going to be the fact that the technology is gonna be purpose built to construct a relationship between your IT folks and your business users and allow both of those groups to iterate on that relationship and iterate on that data so they can continue to make more important decisions with their data. Yeah, that's all good stuff. We have a couple of good comments, some nice chat going on in the chat window for those who are looking to engage there. Lots of good comments going back and forth. And you made several really good points, Kenneth, and I'd like to thank you for a really good engaging monologue there and telling the story of how we got here, but you talked about databases of old versus databases of today. And just as a reminder to people, applications are typically constructed in a way that is supposed to align with a particular database technology. And what I'm saying here is when you come up with new database technologies, you kind of have to rewrite the application to leverage those new technologies. And there are a lot of interesting things happening. So if you think about just the change in memory, for example, the fact that memory is so prevalent these days, well, a lot of old applications were designed with spinning disks in mind. And so when in memory becomes much less expensive and much more prevalent, that changes how you design the application. And I think this is one of the real disruptive aspects of our modern-day world now because as you suggest, these databases are remarkably different than those of 10 years ago, they're predecessors. And I think we're still kind of catching up on redesigning all the applications that leverage those databases, right? Absolutely, yeah. I mean, I think that the idea, I think that we're kind of moving towards is that a lot of these databases, especially the newer ones, are built around blob storage centers, right? So you have BigQuery that's built on GCP, you have Redshift that can access S3, you have Snowflake that is also built on S3, also has plans to access GCP. And what we're seeing is that, if you're configuring an application that is built on data in these blob stores, your database, you can actually then switch out databases as you need to, right? So for example, yeah. Yeah, so a really good example is, if I have my data in S3 on Redshift, and I'm querying my data through Redshift, I can also, it's still gonna stay in S3 if I wanna deploy Snowflake right on top of it. And so that's, I think, the portion of the debate that our founders actually uniquely interested in, especially because we were talking about, I think you were talking about the difference between APIs and ETLs. And what we've seen in the past, and the thing that I think a lot of you are familiar with is actually taking data out of these individual data sources and detailing them all into a data warehouse, right? So like, you would detail them all into Redshift or something, right? What we're predicting that we're gonna see in the future is that data sources are just going to have their data available on S3, or GCP, or one of those, or both. And so what that means is that databases of the future, modern databases, are gonna be able to access that data instantly where it lives. And so there's not gonna be any need, really, to write ETL to a data warehouse. You know, obviously this is like years out, but if you have a database like Redshift or Snowflake that accesses S3, you're going to be able to access the data instantly right where it lives because the data that the application, the data that the company like Salesforce or ZendF is storing is already gonna be there. And so it's gonna be real time and there's not gonna be a lot less latency involved because you're not transferring it anywhere. Yeah, so this is a really, really interesting point, right? There's actually a relatively new company that's come out called Aluxio. It's a tachyon rebranded basically. And they talk about in-memory speed for access to data from anywhere. And if you start thinking about the implications of that, well, goodness gracious, master data management is the crosshairs just for starters. But again, we're talking about a massive foundational shift in how you store and access and use data. And this, again, is gonna require some interesting changes. But I'd like to drill more into your comment a couple minutes ago about how if you take the proper approach, you can just switch databases out. I mean, is that basically because of access technologies improving bandwidth, increasing that kind of thing? Or is it because you've got what amounts to a data service layer, which I think is where Aluxio is going, which is feeding all these different applications? Yeah, that's exactly right. I think we're seeing that a lot of companies are kind of departing from this idea of a shared nothing architecture and moving more towards this idea of decoupling storage from compute. And the reason why that's important is because when you do that, you're able to scale both of them separately and for most, for these like voucher companies, infinitely, because you have data that resides on storage layers and that is separate from scaling the compute layers. And so for example, Snowflake, it uses S3 as its storage layer, right? But the main kind of power in Snowflake relies in the fact that you have this data services layer that is still powerful, that allows you to spin up individual warehouses and that are completely parallel and don't have any relation to each other. You know, BigQuery is the exact same way. In the sense that you have GCP, that is a separate storage layer that you store your data on. And BigQuery is more like a data service, a compute layer that then accesses that and can scale up or down infinitely. According to the queries, of course. And so that's what we see, I think, as gonna be the next iteration in database technology and that's what's gonna be, and more importantly, I actually would say with these, is that a lot of these services, because they're so sufficiently abstracted from the complexities of automating and upscaling these databases, they're actually a lot more simple to use. And so what that means for your IT team is that your IT team is gonna be way less encumbered by switching, you know, for optimizing, upscaling these databases because they're gonna be doing them either automatically or it's gonna be extremely dead simple to do so. Yeah, you're really speaking to one of the massive changes that's taking place right now and that is cloud architecture versus traditional on-prem architecture. And of course, on-premises, I mean the heterogeneity is into the stratosphere, right? And this is what you see in any very large organization. You have so many different source systems, so many targets, so many customer or employee-facing systems that are bespoke. They're unique to that organization and this is why the enterprise has been a really tough nut to crack for big players like Google, for example, and some of the others can even, right? But I think what we're now seeing is the evolution and the maturation of these cloud-based technologies in these services to where the benefits are so significant that you just can't avoid it. And I think you pointed out several of them, right? It's the scalability, being able to spin up and spin down according to need. That's a huge change, right? Yeah, yeah, absolutely. And just to couch this again a little bit in the language around spreadsheets and self-service, it's really important that this status kind of maintained because if you think about just the cost per user of a traditional kind of spreadsheet or workbook analytics self-service world, right? The cost per user for the IT team is going to go up exponentially because you're gonna have more and more spreadsheets that are circulated per user, right? So it becomes more and more encumbering for the IT team to do so. When you couch your analysis in a modern database, the cost per user to do analysis is trivial because as an IT team, that database is going to scale and up-size completely automatically and with very little input from you. And so I think that you also raised a great point though is that for a lot of enterprise organizations, their data stacks are very, very tailored and they're very unique and that's a really big strength of traditional on-premise data warehouse and providers like Teradata or Vertica, for example. But I think that's the question that a lot of IT managers are gonna have to ask themselves is what are we gonna be prioritizing the future? Are we gonna prioritize some scalability or is it gonna be a factor of these technology vendors? Is it gonna be them saying, how do you configure our technology so that it's enterprise ready and it supports a wide variety of applications? And I think that's probably gonna be the way that technology companies like Google and Snowflake are gonna tackle that. Yeah, that's another good point. We have a couple of good questions here from the audience. I'll throw one over at you. There was a bit of back and forth around the naming of fields and the naming of dimensions and the definitions of terms and so forth. And I think some of this can actually, maybe a lot of it can be solved by leveraging the capabilities of these new database technologies and kind of where I'm going with this is because of the ability to scale on whether it's processing or storage or whatever the case may be, you can have each set of users with their own lens into the same data. So if you say tomato, I say tomato, we're both talking about the same thing. We just have a different way of describing it. We don't need to force you to use my way or me to use your way. We can have lenses of the data that are aligned with a particular group's perception or definitions, so long as they're not completely incongruent with your version of the truth, you don't have to force people into pigeon holes anymore, right? We can each have it our own way. That's absolutely correct. And I think that you really, you talked about it in a really great way there in the sense that, you know, when you have different people that have different definitions for their business logic, largely when you don't have all those codified into one centralized model, those are all going to be in their own heads, right? And so you're not going to have necessarily that awareness even that there are these different definitions, right? When you start to codify those definitions and fields down into a centralized repository or centralized data model, you're able to actually gain quite a bit of awareness as to, okay, you know, finance is using this definition of maybe what a customer is, right? Sales is using this definition. Should they be using the same definition? If so, we should get in a room and they should talk about it, right? And if not, then we can easily code both of their different definitions into the data model layer. But that's kind of the point too that this forces a little bit is that it makes those conversations very, very transparent and very easy to see when you should have a conversation with a specific department or not and so it actually provides a way to organize the rest of your business around that kind of definition. And so a really great example of this is SendGrid actually. And this was at our joint conference. One of the analysts from SendGrid was talking about moving to a centralized data model like basically coming from a disparate sort of spreadsheet-based environment. And what he was saying was that it took some work to be able to kind of have those conversations and kind of put everyone in a room and say what are the definitions that we need to have consistent and what are the ones that we don't? But he said afterwards, people came away with so much more clarity around the organization of business. And I think that's kind of one of the biggest selling points I think of a model layer that allows you to have those conversations. Yeah, that's a really good point and I think to your comment just a moment ago here, a lot of the friction that causes trouble in organizations boils down to people feeling like they're not being heard or not getting in their way. And I think one of the beauties of these new architectures is that you can have your way. You can have it however you want so long as it's not disrupting someone else's view. And this kind of gets to a question that the attendee just asked and we'll wrap up here just a couple of seconds. But how do you govern the proper asking of questions? Data can be nuanced and the fact that it can easily be lost, et cetera, et cetera. Is there danger in analyzing the results incorrectly? That's actually a different question I was gonna ask. Someone just popped that one in there in the last second. But that's a good one. But the other question is as more and more self-serviced becomes part of the picture, how does one provide governance over the myriad data consumers and in particular the personal databases that they create and depend upon, well this gets to our whole issue here of silos. If you're all accessing the same data, you can have your different lens through which you view that data, but it's still the same data. So it's not that you have silos anymore, you've got one master's viewing area if you will of the real data and that's the answer. So you can have your version, you can debate interpretation, but you can't debate the data itself as being analyzed, right? Yeah, absolutely. I mean largely data silos were created really to kind of again circumvent the need for relying on this largely slow and centralized database, right? So you had this, if you had an IT team that was besieged by marketing, finance, sales, customer success, all of those different organizations, operations and all of those different organizations had to rely on IT. Like if you were in marketing, it was a lot better for you and it was more in your interest to just get maybe a replica or own individual clone of that database and use it yourself and keep it under your desk or something. I know that Thomas Tungus had the same, he did something very similar where he was, Thomas Tungus is one of our investors where he was at Google and he actually had a replica of the database underneath his desk that he would query himself. And so the idea is that when he saw Looker, he was like, oh, I don't have to, people don't have to do that anymore because it's built to handle modern databases and it's built to scale. That's it, that's a great way to close the webcast today. Fantastic presentation, Kenneth. That was wonderful. That's exactly what we want on a deep dive. Thank you very much for that. Thank you to all of our audience members out there for your great questions and Shannon, I guess I'll turn it back over to you to close this out. Yes, indeed, Eric, it was a great conversation. Kenneth, thank you so much. Thanks to Looker for sponsoring today's webinar. And just a reminder, I will be sending a follow-up email to all registrants by end of day Monday with links to the slides, links to the recording of this session as well. And thanks to all of our attendees for being so engaged in everything we do. I just love the chat that has been going on and it's just fantastic. So thanks to everybody and hope you all have a great day. Thanks, Kenny, thanks, Eric. Great, thanks guys.