>> Live from San Francisco, California, it's theCUBE covering the IBM Chief Data Officer Summit. Brought to you by IBM. >> Hi everybody, welcome back to theCUBE's coverage of the IBM Chief Data Officer Event. We're here at Fisherman's Wharf in San Francisco at the Centric Hyatt Hotel. This is the 10th anniversary of IBM's Chief Data Officer Summits. In the recent years, anyway, they do one in San Francisco and one in Boston each year, and theCUBE has covered a number of them. I think this is our eighth CDO conference. I'm Dave Vellante, and theCUBE, we like to go out, especially to events like this that are intimate, there's about 140 chief data officers here. We've had the chief data officer from AstraZeneca on, even though he doesn't take that title. We've got a panel coming up later on in the day. And I want to talk about the evolution of that role. The chief data officer emerged out of kind of a wonky, back-office role. It was all about 10, 12 years ago, data quality, master data management, governance, compliance. And as the whole big data meme came into focus and people were realizing that data is the new source of competitive advantage, that data was going to be a source of innovation, what happened was that role emerged, that CDO, chief data officer role, emerged out of the back office and came right to the front and center. And the chief data officer really started to better understand and help companies understand how to monetize the data. Now monetization of data could mean more revenue. It could mean cutting costs. It could mean lowering risk. It could mean, in a hospital situation, saving lives, sort of broad definition of monetization. But it was really understanding how data contributed to value, and then finding ways to operationalize that to speed up time to value, to lower cost, to lower risk. And that required a lot of things. It required new skill sets, new training. It required a partnership with the lines of business. It required new technologies like artificial intelligence, which have just only recently come into a point where it's gone mainstream. Of course, when I started in the business several years ago, AI was the hot topic, but you didn't have the compute power. You didn't have the data, you didn't have the cloud. So we see the new innovation engine, not as Moore's Law, the doubling of transistors every 18 months, doubling of performance. Really no, we see the new innovation cocktail as data as the substrate, applying machine intelligence to that data, and then scaling it with the cloud. And through that cloud model, being able to attract startups and innovation. I come back to the chief data officer here, and IBM Chief Data Officer Summit, that's really where the chief data officer comes in. Now, the role in the organization is fuzzy. If you ask people what's a chief data officer, you'll get 20 different answers. Many answers are focused on compliance, particularly in what emerged, again, in those regulated industries: financial service, healthcare, and government. Those are the first to have chief data officers. But now CDOs have gone mainstream. So what we're seeing here from IBM is the broadening of that role and that definition and those responsibilities. Confusing things is the chief digital officer or the chief analytics officer. Those are roles that have also emerged, so there's a lot of overlap and a lot of fuzziness. To whom should the chief data officer report? Many say it should not be the CIO. Many say they should be peers. Many say the CIO's responsibility is similar to the chief data officer, getting value out of data, although I would argue that's never really been the case. The role of the CIO has largely been to make sure that the technology infrastructure works and that applications are delivered with high availability, with great performance, and are able to be developed in an agile manner. That's sort of a more recent sort of phenomenon that's come forth. And the chief digital officer is really around the company's face. What does that company's brand look like? What does that company's go-to-market look like? What does the customer see? Whereas the chief data officer's really been around the data strategy, what the sort of framework should be around compliance and governance, and, again, monetization. Not that they're responsible for the monetization, but they responsible for setting that framework and then communicating it across the company, accelerating the skill sets and the training of existing staff and complementing with new staff and really driving that framework throughout the organization in partnership with the chief digital officer, the chief analytics officer, and the chief information officer. That's how I see it anyway. Martin Schroeder, the senior vice president of IBM, came on today with Inderpal Bhandari, who is the chief data officer of IBM, the global chief data officer. Martin Schroeder used to be the CFO at IBM. He talked a lot, kind of borrowing from Ginni Rometty's themes in previous conferences, chapter one of digital which he called random acts of digital, and chapter two is how to take this mainstream. IBM makes a big deal out of the fact that it doesn't appropriate your data, particularly your personal data, to sell ads. IBM's obviously in the B2B business, so that's IBM's little back-ended shot at Google and Facebook and Amazon who obviously appropriate our data to sell ads or sell goods. IBM doesn't do that. I'm interested in IBM's opinion on big tech. There's a lot of conversations now. Elizabeth Warren wants to break up big tech. IBM was under the watchful eye of the DOJ 25 years ago, 30 years ago. IBM essentially had a monopoly in the business, and the DOJ wanted to make sure that IBM wasn't using that monopoly to hurt consumers and competitors. Now what IBM did, the DOJ ruled that IBM had to separate its applications business, actually couldn't be in the applications business. Another ruling was that they had to publish the interfaces to IBM mainframes so that competitors could actually build plug-compatible products. That was the world back then. It was all about peripherals plugging into mainframes and sort of applications being developed. So the DOJ took away IBM's power. Fast forward 30 years, now we're hearing Google, Amazon, and Facebook coming under fire from politicians. Should they break up those companies? Now those companies are probably the three leaders in AI. IBM might debate that. I think generally, at theCUBE and SiliconANGLE, we believe that those three companies are leading the charge in AI, along with China Inc: Alibaba, Tencent, Baidu, et cetera, and the Chinese government. So here's the question. What would happen if you broke up big tech? I would surmise that if you break up big tech, those little techs that you break up, Amazon Web Services, WhatsApp, Instagram, those little techs would get bigger. Now, however, the government is implying that it wants to break those up because those entities have access to our data. Google's got access to all the search data. If you start splitting them up, that'll make it harder for them to leverage that data. I would argue those small techs would get bigger, number one. Number two, I would argue if you're worried about China, which clearly you're seeing President Trump is worried about China, placing tariffs on China, playing hardball with China, which is not necessarily a bad thing. In fact, I think it's a good thing because China has been accused, and we all know, of taking IP, stealing IP essentially, and really not putting in those IP protections. So, okay, playing hardball to try to get a quid pro quo on IP protections is a good thing. Not good for trade long term. I'd like to see those trade barriers go away, but if it's a negotiation tactic, okay. I can live with it. However, going after the three AI leaders, Amazon, Facebook, and Google, and trying to take them down or break them up, actually, if you're a nationalist, could be a bad thing. Why would you want to handcuff the AI leaders? Third point is unless they're breaking the law. So I think that should be the decision point. Are those three companies, and others, using monopoly power to thwart competition? I would argue that Microsoft actually did use its monopoly power back in the '80s and '90s, in particular in the '90s, when it put Netscape out of business, it put Lotus out of business, it put WordPerfect out of business, it put Novell out of the business. Now, maybe those are strong words, but in fact, Microsoft's bundling, its pricing practices, caught those companies off guard. Remember, Jim Barksdale, the CEO of Netscape, said we don't need the browser. He was wrong. Microsoft killed Netscape by bundling Internet Explorer into its operating system. So the DOJ stepped in, some would argue too late, and put handcuffs on Microsoft so they couldn't use that monopoly power. And I would argue that you saw from that two things. One, granted, Microsoft was overly focused on Windows. That was kind of their raison d'etre, and they missed a lot of other opportunities. But the DOJ definitely slowed them down, and I think appropriately. And if out of that myopic focus on Windows, and to a certain extent, the Department of Justice and the government, the FTC as well, you saw the emergence of internet companies. Now, Microsoft did a major pivot to the internet. They didn't do a major pivot to the cloud until Satya Nadella came in, and now Microsoft is one of those other big tech companies that is under the watchful eye. But I think Microsoft went through that and perhaps learned its lesson. We'll see what happens with Facebook, Google, and Amazon. Facebook, in particular, seems to be conflicted right now. Should we take down a video that has somewhat fake news implications or is a deep hack? Or should we just dial down? We saw this recently with Facebook. They dialed down the promotion. So you almost see Facebook trying to have its cake and eat it too, which personally, I don't think that's the right approach. I think Facebook either has to say damn the torpedoes. It's open content, we're going to promote it. Or do the right thing and take those videos down, those fake news videos. It can't have it both ways. So Facebook seems to be somewhat conflicted. They are probably under the most scrutiny now, as well as Google, who's being accused, anyway, certainly we've seen this in the EU, of promoting its own ads over its competitors' ads. So people are going to be watching that. And, of course, Amazon just having too much power. Having too much power is not necessarily an indication of abusing monopoly power, but you know the government is watching. So that bears watching. theCUBE is going to be covering that. We'll be here all day, covering the IBM CDO event. I'm Dave Vallente, you're watching theCUBE. #IBMCDO, DM us or Tweet us @theCUBE. I'm @Dvallente, keep it right there. We'll be right back right after this short break. (upbeat music)

>> Narrator: From San Mateo, California, it's theCUBE, covering SnapLogic Innovation Day 2018. Brought to you by SnapLogic. >> Hey, welcome back here, Jeff Frick here with theCUBE. We're at the crossroads, it's 101 and 92 in San Mateo, California. A lot of popular software companies actually started here, I can always think of the Siebel sign going up and we used to talk about the movement of Silicon Valley from the chips down in the South Bay and Sunnyvale, and intel, really to a lot of software here in the middle of the peninsula. We're excited to be here at SnapLogic's headquarters for Innovation Day, and our next guest is Craig Stewart, he's the VP of product management. Craig, great to see you. >> Thank you very much. Welcome. >> Absolutely So, we're talking about API's, and we go to a lot of tech shows and the API economy is something that's talked about all the time. But really that has evolved for a couple reasons. One, is the proliferation of Cloud services, and the proliferation of applications in the Cloud services. We all know if you go to Google Cloud Next or Amazon re:Invent, the logo slide of absent services available for these things is tremendous. Give us kind of an update, you've been involved in this space for a long time, how its evolving what you guys are are working on here at SnapLogic. >> What we've seen change of late, is that not only is there a requirement for our customers to build API's, but also to then allow those API's to be consumed by their partners and networks out there. As a part of that, they may need to have more management of those API's, then we provide. We're very good at creating API's with inbound and outbound payload, parameters, all of those things, so we can create those data services via our API's, but customers then need to have a requirement now to add some functionality around. What about when I have a thousand users of these, and I need to be able to throttle them and those kinds of things. What we've seen happening is there's been this space of the full lifecycle API management technologies, which have been available for some time, and amongst those we've had Google Apigee kind of being the benchmark of those with the Apigee Edge platform, and in fact what we've done in this latest release is we've provided engineered integration into that Apigee Edge platform so that the API's that we create, we can push those directly into the Apigee Edge platform for them to do the advanced authentication, the monetization, the developer platform around it to develop a portal, all of those kind of things. In addition to that, we've also added the functionality to generate the open API specification, Swagger, as it's known, and to be able to take that Swagger definition to having generated it, we can then actually drop it into the API gateways provided by all of the different Cloud vendors. Whether it's Amazon with their API gateway or the Aggre gateway, all you need to do is then take that generated Swagger definition, and this literally is a right-mouse button, "open" API, and it generates the file for you, from there just drop that into those platforms and now they can be actually managed in those services directly. >> I want to unpack API lifecycle management, cos just for a 101 for people that aren't familiar. We think of API's and we know applications or making calls, and it's, "I'm sending data from this app to that app, "and this is pulling information from that app to this app." That's all pretty straightforward, but what are some of the nuances in lifecycle management of API's that your typical person really hasn't fought through that are A, super important and only increasing in relevance as more and more of these systems are all tied together. >> The use of those API's, some of the things around them that those platforms provide is some advanced authentication. They may be using, wanting to use OWA two-factor authentication, those kind of things. They may want to do some protocol translation. Many customers may know how to consume a SOAP service... generally Legacy, these days-- >> So funny that SOAP is now Legacy (laughs) >> It just cracks me up. I remember, the hottest thing since sliced bread >> Oh yeah! Oh yeah! I still have the Microsoft Internet Explorer four T-shirt-- >> When it was 95 Box too, I'm sure. But that's another conversation for another day. (laughs) >> The management of those API's adding that functionality to do advanced authentication, to do throttling... If you have an API, you don't want all of your back end systems to suddenly be overwhelmed. >> Jeff: Right. Right. >> One of those things that those full lifecycle platforms can do is throttle so that you can say this user may have only 10 requests a minute or something like that, so that stops the back end system being overwhelmed in the event of a spike in usage. That helps with denial of service attacks and those kind of things where you're protecting the core systems. Other things that they can do is the monetization. If you want to atrially expose an API for partners to consume but you want to charge them on that basis, you want to have a way of actually tracking those things to then be able to monetize that and to provide the analytics and the billing on top of it. There's a number of those different aspects that the full lifecycle provides on top of what we provide which is the core API that we're actually creating. >> Right. Is it even feasible to plug an API into a Cloud-based service if your service isn't also Cloud-based cos as you're speaking and talking about spikes, clearly that's one of the huge benefits of Cloud, is that you have the ability to spike whether it's planned or unplanned to massive scale depending on what you're trying to do and to turn that back down. I would imagine (laughs) if your API is going through that platform and you're connecting to another application, and it's Pepsi running a promotion on Superbowl Sunday, hopefully your application is running in a very similar type of infrastructure. >> Absolutely. You do have to plan for that elastic scalability. And that's one of those things with the SnapLogic platform, is it has been built to be able to scale in that way. >> Right. Now there's a lot of conversation too around iPass and integration platforms as a service. How do you see that mapping back to more of a straightforward API integration. >> What we're talking about in terms of API integration here, and the things that we've just recently added, this is the consumption of our API's. The iPass platform that we actually provide consumes API's, all sorts of different API's, whether they're SOAP or REST and different native API's of different applications. That we do out of the box. That is what we are doing, is API integration. >> Right. >> The new functionality that we've introduced is this added capability to then manage those API's from external systems. That's particularly where those external systems go beyond the boundaries of a company's own domain. It's when they need to expose those API's to their partners, to other third parties that are going to want to consume those API's. That's where you need those additional layers of protection. Most customers actually use those API's internally within their organization, and they don't need that extra level of management. >> Right. Right. But I would imagine it's an increasingly important and increasingly common and increasingly prolific that the API integration and the API leverage is less and less inside the building and much much more outside the building. >> It is certainly going a lot more outside the building because customers are recognizing their data is an asset. >> Right. Right. Then having it be a Cloud broker, if you will, just adds a nice integration point that's standardized, has scale, has reliability, versus having all these point-to-point solutions. >> Yeah, absolutely. >> I was going to say, As you look forward, I can't believe we're May 16 of 2018 already (laughs), the years halfway over, but what are you looking forward to next? What's kind of on the roadmap as this API economy continues to evolve, which is then going to increase the demands on those API's integration, those API's in management, as you said the lifecycle of the way all this stuff works together, what's kind of on the roadmap if we talk a year from now, what are we going to be talking about? >> There's a lot of... settling down of what we've delivered that's going to take place, and on top of that, then the capabilities that we can add to add some additional capabilities that the customers want to use, even internally. Because even internally where they're not using a Cloud service, they have requirements to identify who in an organization is utilizing those things. So additional capabilities without having to go beyond the boundaries of the customers own domain. That's going to be some things like authentication, it's going to be some additional... Metrics of what's actually being used in those API's, the metrics on the API's themselves in terms of how are they performing, how frequently are they being called, and in addition to that, what's the response time on those things? So there's additional intelligence that we're going to be providing over and above the creation of the API's that we're looking to do for those customers, particularly inside the organization. >> It's very similar requirements but just different, right, because organizations, take a company like Boeing, or something, is actually not just one company, there's many, many organizations, you have all kinds of now with GDPR coming out, cut of data, privacy and management restrictions, so even if it's inside your four walls, all those measures, all those controls are still very very relevant. >> Very much so. Providing some additional capabilities around that is pretty important for us. >> Alright. Well Craig, you're sitting right on top of the API economy, so I think you'll keep busy for a little while. >> (laughs) That's for sure. >> Thanks for taking a few minutes to stop by. >> Thank you. >> He's Craig Stewart, I'm Jeff Frick, you're watching theCUBE from SnapLogic in San Mateo, California. Thanks for watching. (techno music)