a16z Podcast - a16z Podcast: From Data Warehouses to Data Lakes

Episode Date: September 22, 2016

From the silver age of on-prem software companies like SAP and Siebel Systems to the golden age of enterprise software-as-a-service, we're now seeing an explosion of data. All types, all sizes, and all over the place. And much of it is a sort of industrial "data exhaust", where companies aren't quite sure what question to ask of the data but are being bombarded with data due to the variety of data sources available today -- from websites to sensors (and therefore data capture) everywhere. Before there is even a signal in the noise. So how do you solve a problem like this-Data? Beyond requiring new types of plumbing and integrations, enterprises now expect -- given the age of mobile, web, cloud, and heck, let's add millennials to the mix too -- self service. To be able to ask, get, fit (curve-fit), predict. To take back the enterprise from the patchwork of integration and number of vendors we all have to deal with -- the scope of which most companies in fact are not truly aware of. It's about the lifecycle of data in the enterprise, argues Snaplogic founder and CEO Gaurav Dhillon in this episode of the a16z Podcast, in conversation with Scott Kupor. It's in fact about the evolution of data overall -- from data warehouses to "data lakes": in stages, from purification (like wrangling data) to bottling (prepping for consumption by data scientists) to making sense of streams and streams of data! The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments and certain publicly traded cryptocurrencies/ digital assets for which the issuer has not provided permission for a16z to disclose publicly) is available at https://a16z.com/investments/. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

The content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security and is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. This is Scott Cooper. I'm here with Gora of Dillon, the founder and CEO of SnapLogic. And thank you, Gora, for joining us. Pleasure to be here, Scott. We're going to cover a bunch of topics and keep this as a very free-ranging discussion. But where I want to start is, I want to start with this thing that we used to call EAI Enterprise Application Integration. And the reason I bring this up is GORV was the founder many years ago of a company called Informatica. And what would be great, I think, to set the arc for was if you think about where we were in, you know, 96, 97th, for 2000, around the time that you guys were coming to life, what was kind of the enterprise computing challenge there? What were the platform issues?

If you drill back in that time, you have to look at the macro trends. What was going on was the year 2000 was approaching. And people were trying to business process re-engineer, and they just couldn't do it fast enough. So this was a golden age of companies like SAP, companies that no longer exist now, like Sebole and PeopleSoft. And there was a tremendous time for all of them. But what needed to happen, as that was going through, is people needed to now bring those things together. But it was sort of very much that you were bringing in that product and you were helping to replace the old mainframe stuff with the new business process. this is re-engineered ERP stuff.

And when you say people need to bring that stuff in, do you mean data? So was there information sitting in those applications that people needed to kind of be able to talk to one another as part of this reengineering? What was the nature of the IT problem people were trying to solve? At that time, it was more of a replacement of core applications like finance. I mean, it's open-heart surgery for the enterprise to replace finance. It's not simple. It's in many cases you have to report earnings quarterly, so you really have to get this window

just right. So the task that we built were how to get these big, big applications to work with some of the other applications that existed in the enterprise. But it was very much subservient to the big applications, right? If you bought something, say, from Oracle, somebody in Redwood Shores, California designed a way in which you balanced your books, and that's what you did. Now, you may need lots of other inputs and things to make it work. You may need a data warehouse to report on it. So you had certain amount of freedoms, but the freedoms were. were very much subservient, I would say, to what that big application was going to do.

So the business process itself was dictated by the key application vendors. And, you know, you were, and people often used to use this term, you know, maybe it was a derogatory term or not, but you were middleware to a certain extent, right? For sure. You were connecting applications, but with the kind of real business logic and business process being dictated by the SAPs and Oracles and People's Sauce and Siebel's the world. The other aspect of all this was that it was still a very limited audience of usage. Right. Remember, this is all before the World Wide Web. Yes.

It's hard to remember before I bad, but boy, it was even before the web. Right. This is the mid to late 90s. So we, things have changed quite a bit. Right. To drill down then. So for all the users of these applications, they tended to be fairly specialized. Business users, right, there wasn't a desktop on every desk and, you know, people

using email and all these other things. These were kind of highly specialized and highly trained people. So it was a lot of one-to-one connection of applications and a very rigorous framework. And so if you fast forward to kind of a little bit to today or a little bit to today or at least we pick up, you know, maybe in the modern web era, what's changed from an architecture perspective, what's changed from the types of applications, the types of data, kind of where these things reside? Like, what's the big overarching architectural shift that's happened since late 90s to get us to today that even, you know, requires the need for a company like a

SnapLogic or others that are doing things, you know, in a different fashion than what informatical is doing? This may seem radical, but besides the problem, everything has changed. Okay. It's the same problem. And things so. Same problem being what applications need to talk to one another. Indeed. And how does somebody make a complex enterprise run?

Because it is, you know, it's not just eight arms of an octopus. There's 1,800 connections in these companies, right? So you've got a very sophisticated clockworks to make a large company function. So the problem is still the same, but everything has changed. So let me take you through some of the changes. One is you have, of course, the web. What does this do is you're no longer building and installing applications. you are essentially using websites.

You don't just use the Internet to buy your books. You use the Internet to balance your books. If you're a Workday Financial user, you have a browser up, boom. If you're a Salesforce user, boom. So I think that's a profound change because the data types are now different. It's not just the world of rows and columns that it was in the 90s. It's a world of web data. If you ever sort of accidentally open up your browser into its squiggly rows and column,

into squiggly brackets, you've seen a JSON object. You know, and that's the data types are different. The network topology is different. Your data's not here. It's there. So I think that's probably the most profound one. Now, with that, though, is a millennial post-web generation where you have self-service as an expected requirement.

If you ever had the pleasure of installing Siebel Salesforce automation, it came with about five people whose job it was to do reporting for the head of sales, right? You couldn't just do it yourself. The fact that you can actually build sales reports on the. fly in a meeting is astounding. And this is where I think Salesforce has pioneered much of the no software wave in the enterprise and then there's an amazing work being done by folks like Service Now and Workday Now. So the self-service model has fundamentally altered the landscape. And then you layer in millennials who are friendly to computers and iPads and so on. And everything

is different today. So one other thing that I also at least have always thought is different is proliferation of applications in the enterprise. So, yes, I agree. We've got new data types. We have new data sources, right? Data now living and residing in other places. One of the things that we've often talked about here is the idea that with the development of SaaS and web-based applications, what used to be the governor on the number of applications and enterprise could do was how many applications could the actual centralized CIO actually manage and implement and support over time, right? And we've essentially eliminated that governor now. As you think about integration of data and other things across applications, I assume the sheer proliferation. of applications and business-level users as opposed to purely kind of these centralized IT-level users probably also, you know, kind of orders of magnitude changes the process. Crazy big. But that's not surprising, right? You expect with the web that people would use websites and so on.

What's crazy big is that people think they don't have a lot of applications. If you bet companies a dollar that they're using X number of SaaS apps, they're off, but not by half. They're off by like 10x, you know, because somebody in marketing is using something and they go, it's not an application. It's just a website. And you go, wait a minute, but you're using it to do a critical task. And you're doing this to do something that is important to the companies, a lot of data flowing from it, back and forth. It has all the implications in how it is part of your enterprise fabric, as if it were an application, it's just a website. So the sheer number of applications

that or websites in the enterprise now is at least 10x, in my opinion. But what's shocking is people think it's 2x. Right, right, right. Large enterprises, they've layered on all these new applications, many of which are now web-based applications. At the same time, probably we haven't retired many of those older applications, right? Right, right. And that is different, right?

So finance is not going anywhere. Let's say even the biggest companies you can think of, the web monsters. They run on good old financial systems that are like sure. Right. So that is not changing as much, although with Workday financials, we're seeing some proliferation, but everything else, going, going gone. certainly Salesforce automation or CRM, certainly help desk management, certainly human capital management. And if you go by job title and vertical in every industry, all those squares are lit up with SaaS applications.

So given those changes and look, obviously, we're now many years into it, but what's the real nature of the problem? We understand those architectural changes. What does it that makes the old way of doing things no longer applicable given those architectural changes? So I would say probably two things. One is the data types, fundamentally being different, require new kinds of plumbing. You know, this is digital plumbing we're talking about, but you're no longer using Rosen Columns. You're using a document model, the way the worldwide web works. The way browser talks to a website is the way these applications all function.

So I think that's a huge reason to rethink the core engineering that you might be doing, because if you use stuff from the last century, and look, it's good stuff, but it's designed for a certain time, at a certain point in time. And where we are today is the data types fundamentally being different. I think a very real catalyst of new kinds of technology. But sometimes we find that the even more important one is self-service. So integration has always been in the basement, in the dungeon in the enterprise. You know, you're glowing the dark people who come in and do integrations. And if they work, that's beautiful.

If they don't, you don't know why. And if it start working again, you don't know why. So having the ability to take that in a sense from the darkness into the light with technology that is self-service that works like SaaS is the next requirement. And that is becoming an absolute requirement. It's rather that people are shocked that that's not how things work. Right. And I think there are then a way of thinking about the radical benefits of going from manual labor, as it were, to having business people get the stuff when they need it whenever they want it on their own terms and be able to self-serve themselves.

So those two things are, I think, is. is sort of what's causing this to be a huge problem. That makes a lot of sense. So we've been talking about aggregation of data and there seems to be no end to it. I mean, what happens over time? Where does all this data go? What happens in the enterprise?

There's a software lifecycle in the enterprise. People have thought about how they stage data, how the stage applications and make them happen. I think you're going to look at a life cycle for data as well. You know, there's all this production of data that is happening at the edges and the core, at sensors around all the monitoring that we do, around all the new requirements that we have in somewhat of a scary world.

And so there's a life cycle of more data production, more data management, and actually more consumption. And it's a virtuous cycle. It feeds on itself. Because when people see the benefits of analytics, they want to go capture more. So it's a healthy trend. I want to shift gears a little bit. We've been talking about, you know, movement of data, right, and integration of data across

applications. But I'd love to kind of shift the conversation a little bit to analytics. What's the implication now? What is the role of analytics? What does it mean in terms of the utility to the business? user. So I think historically, we had reporting and business intelligence. We may have spoken about it as analytics towards the turn of the century, but that was always reporting. And if you think about reporting and business intelligence today, that's what my iPhone does. If I go for a

hike, I pull up my iPhone, it tells me how many steps I've taken. Right. So this rearview mirror historical perspective is no longer of incremental value to a technology company or to an investment Bank, you know, Jamie Diamond once famously declared that I'm not a bank, I'm a technology company, at J.P. Morgan Chase. So as people go through this, software eats the world phenomenon that there is a change in expecting new things. And what are those things? Those are things that you find at Fang, Facebook, Apple, Netflix, Google, etc. And those are predictive forward thinking analytics. Those are discovery engines, recommendation engines, machine learning, artificial intelligence, algorithms. Although I think AI is often frequently misused, I think

machine learning aptly describes things. And what those are are predictive types of things. What is likely to happen? So what we're seeing is a trend away from legacy data warehouses into data lakes, which are then consumed both by people using modern visualization products like, say, a tableau, and also by lots and lots of data scientists, which is a new job title, where you rub the data with the algorithms and you try to predict what will happen. So if we stay on financial sector just for a moment, what's an example is if we want to take a hunch where we manage some money and we want to take a hunch on the price of gasoline in Houston, Texas, for example, on Labor Day weekend.

What would we do? Well, we would reach out for historical prices of gasoline. We would reach for the commodity data. And we would try to have predictive algorithms go in a sense model fit. It's like curve fitting, but to a far greater degree, but to a broader audience. It's on a more massive scale and much more profound set of results that emerge. And for that, you continuously need to dip into the data lake, bring forth data, and you need to iterate on the algorithms. So this is what is happening, and this is causing a profound change in how people are thinking about analytics today.

Now, you look at the work of predictive analytics and you divide that into two halves. There's a data scientist. This is a person. She's an expert in algorithms. They might have emerged with a computer science degree or mathematics degree, some cases, economics degrees. And all of them need... We might have even called it statistics in the old place, right? That's a $100,000 discount on the salary right there.

That's not... That's why I'm not the marketing guy right here. That's the S word. Let's get rid of it. It's all analytics now. But you know, but you're right. The word was statistics once upon a time, curve-fitting, as its predictive models. And that's where the science comes from. But there are some modern things to it that didn't exist because we didn't have the compute.

Right. So all these decades of Moore's law have kind of made us think about algorithms that we couldn't even imagine that are sort of more heuristic in nature, more pair matching in a sense that just regression alone doesn't do. All those data scientists and people who are doing predictive analytics need to iterate the data with the algorithms. So you divide up that task into a, on the one hand, a data scientist who is talking to the business person, trying to figure out what might happen, the price of gas. gasoline in Houston, Texas. But that person needs to go either themselves or through help get data. So there's a data engineering task that has to go on. Capital One, who is, I would say, the original data science company, figured out tens of billions of dollars of business, giving credit cards to people who others had denied and making it profitable using data science.

And for them, this is absolutely core to their business. And of course, we know that the big web monsters use it, but you also see it used on, and traditionally it's been a big, deal in Wall Street, but now it's expected. And this is really mushrooming because of the increased computation available and the plummeting cost of hardware storage. So when you put those two together, you really get fire. You've got the ingredients of combustion there. So you use two words data warehouse, the old caveman model of data warehouse, and then you use this exciting new term data lake. That's right. So let's kind of unpack those a little bit. What was the problem again, five, ten years ago when people were doing data warehouses, what were they trying to

solve? What were the limitations that made things like predictive analytics hard? And then how did we get to this transition to this concept of data lake? So I think first of all, I would tip my hat to two visionaries and thought leaders in the industry, Bill Inman and Ralph Kimball. They came up for the concept and different perspectives. And there is actually a religious debate on forums on the internet to this day about which one is better. We stay out of it. We're like, look, it's data. How do you want it? But they really pioneered in different styles, a way of being able to deal with time series data along multiple dimensions. So for example, if you're in the retail business, you have a product, how has it done in regions over time? The most common three dimensions of

everything in revenue, how are my stores doing, how are my products doing, et cetera, et cetera. So historically, data warehouse went through this real sonic boom. in the 90s and the early part of 2000 because it was a resonance with the change from the mainframe to ERP. So when you brought in ERP, you're like, oops, we forgot about reporting. What do we do now? So then you had this second sonic boom in the world of business intelligence and ETL and data integration with Informatica to bring that forward.

And that was then. So that was what that term is. And look, they're still running in lots and lots of places. And you get a good historical perspective, but that is no longer enough. You know, that is a particularly in this millennial generation and particularly in areas like marketing and other places that is no longer enough and which is why you're seeing this fever about AI breakup. So when we go from data warehouse to do this concept of data lake, what's the difference either architecturally or what are the use cases? What are the things that this new concept of data lake enables? So Inman and Kimball came up with an organizing principle.

You know, data warehousing was never a product. Right. You couldn't go and buy one. It didn't exist. But it was an organizing principle to corral, Marshall, and get benefits from the data that you had in your enterprise. A data lake is at an earlier stage of development.

In the packaged furniture industry, for example, initially you go and get planks of wood, you saw them and you make furniture. And then somebody says, oh, we'll have furniture pre-made and you can paint it. And then someone comes along and they prefab it, you know, restoration hardware and bedbath and beyond. and IKEA, and you buy the stuff

and, like, my 80-year-old can assemble it with a screwdriver, right? So we're going through an evolution rapidly towards people thinking about a data lake as a place where you put all the data you can afford to keep modulo, i.e., without duplication. So get the data. If you can afford it, keep it. Because it may not have signal today. It may be noise, but as the algorithms improve,

and as computers get faster, which we know happens every 18 months, they double, you're going to be able to get signal out of the noise. Right. So the data lake fundamentally is about more data of more types of data. It is expected that you will have all sorts of data that is hierarchical or JSON, web exhaust, machine data. You know, the industrial internet where you have exhaust. Remember, the data warehouse was born in an age where most of the data was the barcode scan. Went to the grocery store. You bought shampoo or beer and you scanned it. And initially it was done just to speed up people at the checkout line. sell more, but actually the data warehouse industry dwarfed the supply chain industry on restocking because people said, wait a minute, that could be useful to me to know what's going on in what store and how people are buying this and correlations and so on and so on. And now we have that on, you know, on like a 10x or 100x larger volume because you've got exhaust from your website, your security sensor, your web traffic to your omnichannel sales

strategy, and all those data are coming in at a much higher volume. velocity and all this stuff. So data lake is fundamentally have different data types. In reality, you want to keep all of it. How do you wrangle that data? Then how do you move that data forward into a consumption by data scientists ultimately? So because there's a lot of it, that is a non-trivial task. So we think of it as a model where you have three stages. You've got the raw, sort of the water sitting in this lake, right? It's just the water that came in. And then there's some element of purification that takes place and some element of bottling that takes place. And we're seeing a lot of companies adopt that because they need a organizing principle. They need a place to hang their hat. They need to think about how to deploy these technologies industrially, how to go through depth test prod, and how to essentially mechanize what is today a very hand-built, lots and lots and lots of open source engineers running around in the enterprise. It's very hard to corral that and make it reproducible, make it secure and so on. Right. So if you think about where we are today, and then is it safe to say the architecture for today for predictive analytics is we've got the people side, we've got data scientists, obviously, who are incredibly

important here. But the architecture looks like multiple applications, some which are SaaS-based applications, some which might be kind of behind the firewall applications. And then you have aggregation of and creation of the data lake itself. And then on top of that, you would put what, reporting tools like a tableau or something else

like that would be the mechanism to actually surface some of that, or you think there's another stack now that comes on top that really replaces some of that? Yeah, I think visualization will certainly continue geodata gaining in importance. Because we have the geosignal. We don't have the geosignal. But if you have somebody coming to your website on their smartphone, you capture some geosignal,

and there's value in that. But I think just going back to it, first, you're going away from a batch architecture of the 90s to a real-time streaming architecture. Like, we want our stuff now. This is 2016, and, you know, we want to see a movie now. So you're going to go through a real shift towards streams of data coming in, a very, very large scale and a very big way in the enterprise. And that's, I think, the one thing that's taking place that we may not have talked about

and we see that all the time. But how are people consuming it is going to be through certain web apps. And sometimes you're just putting that signal into an app to make a decision. We're seeing precursors of this, for example, in ad technology. That market is so efficient in how they serve up ads. I mean, real-time exchanges where you bid high, low, and you put web ads. That sort of thing is going to happen for lots and lots of applications. And you're starting to see companies like Salesforce, for example, make investments in machine learning

to improve the efficacy of your salespeople calling it. out companies like Insight Sales. But what that is is pulling forward the benefits of these real-time trading exchanges that are informed by signals in those data about geolocation, biopreference, et cetera, et cetera. And all those changes are going to trickle down through every process on an industrial scale. So let's talk about where we go from here, right? So you've been obviously an active participant and, you know, studying this industry for probably more years than you care to remember. Or I care to confess. So where do we go from here? Does the data lake become a data ocean and, you know, what changes can we foresee over time

that actually might also cause interesting architectural shifts? So I think the data lake as an organizing principle is yet not fully formed. You know, it's like an object slightly out of focus. You can see the outlines of it, you know what it is, but you don't exactly have the recognition. But the thing that is changing, and this is where it'll be fascinating to see

the worlds of cloud and big data collide. And our hunch is that all the benefits of SaaS app and cloud apps, right? You don't have to go rack and stack. You don't need to worry about personnel and air conditioning, and you basically get into provisioning data, are going to intersect with the data lakes philosophy to where the data lakes might become cloud formations. You actually might have data lakes exist in Microsoft Azure or in AWS as S3 buckets or we'll see what Google does with BigQuery, Bigtable, that that is going to give view, in a sense, a turbo mode of execution around analytics, predictive analytics, where the

data platforms actually go to the cloud. And so the world we see is a world which is definitely streams of data. You have streams of data going. There's no longer a concept of, you know, batch or monthly, God forbid, or even overnight, it's all now. So you have streams of data coming through. You have a world that is hybrid for quite a long time. You'll continue to have legacy applications. Look, the mainframe is still alive. I was going to say, right. Yeah, it's older than both of us. Right. It's like the old Roman cities, right?

We build on top of the cities. We don't really start from scratch. The enterprise is a retrofit job. It always has been. You know, it's a retrofit job. Like ATM transactions, no matter how bad the cobal might be, it makes no sense to redo all the agreements between bank transfers into new language. You just throw more mainframes at it, more water cooling, you know, and so on.

So what you'll see is this layering of a new stack of web apps, cloud apps that are streaming data that are connecting to multiple data lakes, which are probably going to go to the cloud. For some machine data, factory floor data, powerplant data, it may not go just because, you know, bandwidth you can buy, but latency you get from God. Right. So that may not go. But a lot of other stuff, it makes so much sense to put your marketing data into a data lake in the cloud with Azure because you are going to have your website be the primary producer of data. Your on-premises data data is actually very small, and then you have a bunch of marketing applications in the cloud. So why do we just have the data lake in the cloud? When you think about the future, is there a rate limiting factor in your mind as to,

what prevents us from getting to the nirvana that everybody as a business analyst or any business user would love to, which is how do I actually get real predictive value out of my data? Is it the state of machine learning today? Is there a compute limit? This problem is very real, and it's shockingly large, even in 2016. A good chunk of what can make this happen. Is modern technology coming in? And finally, we have all these data are lassoed up in JSON objects and modern APIs to make out of many one. I had dinner with the CIA of a large retailer, and they might decide that the point-of-sale terminals should be iOS devices.

Somebody else might decide to do it in Android, because they might be doing it in Asia, and they might have more fluency with Android. Somebody doing it in San Francisco may have less. So as you do this, you really want the ability to create your own enterprise with intelligent choices of build and buy, and using something to glue it together. And that something gives you option values on the choices that you make and gives you self-service to be able to do that, about having to have a huge programming team and skill sets, matrices, and so on and so on. Yeah, so if you think about if I kind of sum up a little bit for folks, we've kind of almost gone full circuit

and hopefully we're going even farther down the circle, which is, you know, as you described, we've gone from kind of a world of the application vendors, the ERP vendors, in particular, effectively dictating the business process and therefore kind of data flows and how you think about analytics and everything else to take back your enterprise, right? Indeed.

The idea that essentially self-service, you know, as we've seen in so much, so much of compute where, you know, consumer self-service now drives into enterprise self-service that really allows people to get to the end they're looking for. The analogy I will use is, you know, it's like you don't have to listen to music the way the package did on the CD. You can have a playlist. You know, you can compose what you want to do hear. You take back your enterprise and you put together the things that you need, whether it's point-of-sale things or internet sensors or cloud applications to work with what you have on premises or what might be very mission critical for you, and you can have it on enterprise.

So, you know, we've been talking about architectural shifts, but there seems to be a broader organizational shift going on within the IT organization itself. You know, where do you see things going? There's a bunch of things going on. Technology is pervasive. It is as much a part of the enterprise as telephones used to be in the 70s or 60s. It's pervasive, right? So the roles are changing quite a bit.

there was this tension between the chief marketing officer and the CIO. I think they've largely kissed and made up because A, the CIOs are getting to be more business people and the marketing people are getting more technical. So that tension has disappeared in a sense. Now, with the CTO and the CIO is interesting. Most organizations have a IT CTO working for the CIO because what they do is that demarcate many of the more sophisticated technical problems. Security, for example. You have a chief information security officer.

You have a CTO who's looking at where should these applications run? Should they be on premise? Should be in the cloud? Where should these data go? What cloud should we pick? Should we have a multi-public cloud strategy? So at that scale, if you are becoming a better business partner as a CIO and you no longer have tension with the chief marketing officer or the head of people or the head of finance,

now you have, in a sense, to delegate what would traditionally be a CIO job, which is being a technologist, into someone who is a technologist working for you. Imagine you're a multibillion-dollar business. You have to worry about scalability. You have to worry about the optimal mix of on-premise and cloud computing for yourselves, storage optimal mix. You have to think about the mix for you all the time. In addition to that, you have to worry about security.

You have to worry about all the innovations that are happening on machine learning and predictive analytics and keep an eye on the competition. If you're in retail, you have to compete with Amazon, which has all this stuff baked in and is able to come out with new things like drones and so on. So it's a time of great challenge. It's a time of great change, but it's also a time of great opportunity. Well, thank you, Gorv, for spending time with us today. You're welcome, Scott. Real pleasure to catch up with you on this.

Thank you.