This episode is sponsored by the CIO Scoreboard
My guest this week is Barry Libenson, Global Chief Information Officer of Experian. During our interview Barry and I discuss what Experian is doing with innovation and his role in it.
Some of the big ideas we discuss:
- The shifts Barry sees of customers requiring access at the API layer to micro services so they can consume only what they want
- How to build a micro services environment for internal and external use
- How IoT is shifting what customers are asking for
- Taking costs and complexity out of the business
- Speeding up innovation
- Better experience for customers
- Agile performance to respond to organizational threats
- Smart Hubs
- The API Economy
- Tools for Microservices: Red Hat OpenShift, Pivotal Labs, Mirantis
- The importance of portability and use of portable containers for Azure and AWS using Cassandra, PostgreSQL, or MySQL or one of the more portable container.
About Barry Libenson:
Barry Libenson is Chief Information Officer (CIO), with responsibility for the design and delivery of Experian’s global technology strategy. Prior to joining Experian in June 2015, he was CIO of Safeway in North America. Earlier in his career, Barry held CIO positions at Land O’Lakes and Ingersoll Rand. Barry has a BA in Computer Science from Colgate University, and a MBA from Duke University. He was also one of the first employees at Oracle when they were only a $19 million dollar company.
[00:00:30] That whole question sort of, I mean what we're doing is really focused on how we speed up the pace of innovation and deliver you know an evolving way of working with customers. You know the historical, we kind of coming from a place where the historical way of delivering out locations to customers is being turned on its head in a number of different areas both in terms of sort of you know software as a service but also in terms of how information is consumed and a lot of what we're doing at Experian right now the emphasis is on addressing those two primary customer concerns. You know, the way they want to consume information and the speed at which we can deliver it to them and that's a challenge I think for everyone right now and something very much that's on the forefront for us.
So your customers are asking about how you can consume, how they can consume information, ways they can consume information and then and the speed? Those are like two of the key pieces they're asking for Experian? Is that, did I summarize that correctly?
Barry: Yeah and I'll give you a very specific set of examples.
[00:02:00] The first is that you know if you think back ten years ago everybody was pretty much delivering technology the same way with a few very very few exceptions, whether you know if you were an Oracle customer, an SAP customer, an Experian customer, a People Soft customer, it really didn't matter. You essentially paid the, you paid the software company and then they in turn delivered a software package to you that you installed and interfaced with that to run your business. The first big shift that you know we've been seeing steadily gaining traction is the whole software as a service model. People just simply don't want to consume, they don't want to buy applications. They want to pay by the drink. They want somebody else to run the application for them. They don't want to have to worry about what hardware it runs on.
[00:03:00] They don't want to have deal with any of that. They simply want to know that they're going to get the capabilities that they need when they need them and that they're willing to pay for that but instead of spending tens of millions of dollars up front they'd rather pay for it as they consume it and you know, you saw companies like Service Now and Salesforce.com and some sort of early trailblazers in the SASS world, we're very much embracing you know that as a delivery model for our customers but so with a certain set of customers that i would say will always consume our technology through an application for various reasons but we also have a whole series of customers now who are consuming the services that we provide as a service as opposed to installing an application. The second big shift is this whole API and microservices economy.
[00:04:00] So historically speaking you know companies like Experian or Oracle or anyone else whether it was, whether we were delivering the service to you in the cloud or whether we were delivering it to you as a, whether we're delivering the data to you you know in an application or you know through the cloud or on prim we were dictating the terms and conditions under which that data was delivered. The new model and it's interesting to sort of talk about one of the key drivers behind this which I'll come to in a second is this whole idea of setting up microservices in an API layer that allows people to connect to your services but only consume what they want. So if all you want is a single data element you can ask for that and the application or the API or the microservice will deliver just that piece of information.
[00:05:00] It won't deliver more than that or less than that and you can be very prescriptive about what you're asking for and what that allows people to do is create applications that they want to build using your, using our data to make better decisions and that's a big shift as well. One of the key drivers behind that has sort of been this whole internet of things. You know if you've got a thermostat in your house or an alarm system or solar panels or garage door opener, all of these things that connect on the network in your house or out in the world most of those have an API so that you can write your own interfaces to them and things of that nature and that model is very much carrying over into the enterprise software space as well where people are saying hey look, I don't want you know terabytes or you know big voluminous amounts of information.
[00:05:30] I just want these five or six pieces of information on Barry or on Mike or something like that and so just give me a simple model for getting just what I need. Those are the two big shifts that I would say we're seeing in, those are two of the big shifts that we're seeing in the market that's driven a lot of changes inside of Experian in terms of how we deliver capability.
Bill: So ...
Barry: Does that make sense? I mean ...
[00:06:00] Yeah. It absolutely makes sense and I have, I want to come back to that the microservices API piece for a second but you know I would like to start at the beginning and I would like to give our listeners, because we have listeners that of some guys that are just starting out as CIOs, some that are, so just getting started in their career, some that are mid career and some that I run into and this is very frequent are just really wanting to completely reboot who they are as a CIO and what they deliver to their organizations and maybe what we could start with where, how did, what did you trajectory look like? Like where, can you bring us back to like maybe college and like what does your trajectory look like to the point you're at today?
Yeah. So I'm going to be dating myself here which is okay but I mean my undergraduate degree is in computer science.
[00:07:30] So I got my undergraduate degree in computer science from Colgate University in New York back in the day when it was feasible for you to know everything there was to know about technology. So we're going back to the early 1980's here, late '70's, early '80's where you know there was three programming languages, a limited amount of hardware and you know basically you could learn or sort of know every programming language there was to know and you know that's sort of evolved. My first job out of college was as a software developer for Data General in Westborough, Massachusetts. I wrote code for four or five years basically in the mini computer world. From there moved into more of a sort of what I'll call a business liaison role where I was still at Data General but my primary role was to be the interface between engineering and the marketing organization and specific customers.
[00:08:00] So I worked very closely with General Electric, Westinghouse at the time, a number of other very large enterprise accounts and the challenge always was how do you find somebody who can sort of bridge the gap between the engineers and the sales organization to ensure that you know that what we're building is in the sweet spot of what the customer is looking for? From there I worked for a number of startup companies including having the privilege of being employee number 190 at Oracle back in the late '80's.
Barry: So I was bouncing between the West Coast and the East Coast. I was living in Boston at the time but was frequently in California. Oracle was a 19 million dollar a year company when I joined.
[00:09:30] So it gives you a sense for the changes that have occurred and then I spent about three and a half years at Oracle, then went and ran a software company in northern Virginia for about 11 years which ultimately I ended up selling and then took on the role of I was original the vice president of e-business for Ingersoll Rand. Ingersoll Rand being one of the you know very large diversified manufacturer, very much bricks and mortar at the time. This is sort of like 2000, you know right around 2000, 2001 and very much felt the need to move more into a digital economy, I was sort of tasked with driving that initiative. About six months after joining the company took on the role of chief information officer, spent about eight year at Ingersoll Rand as the CIO then went to Land O'Lakes, was the CIO at Land O'Lakes the butter or the diary and seed what most people don't realize is how big Land O'Lakes actually is. They own Purina feed.
Bill: Oh, wow.
[00:10:30] They're the largest distributor of feed in the United States, owned by half of Syngenta, and Monsanto, and their own line of their own brand and then from there went to Safeway which is the second largest grocery retailer in the United States, spent about two years there. Safeway was acquired by Cerberus and was going to be merging with Albertsons. Not something that was particularly appealing to me and that's when I came to Experian about two years ago. So I've always found technology to be absolutely fascinating. I'm very fortunate. I wasn't good enough to be a professional athlete at anything, so I think I have probably what I consider you know one of the best jobs out there. I'm doing something I really enjoy, getting to work with great people and you know getting to play around with the same kind of stuff that I would enjoy playing around with whether I was getting paid to do it or not. So it's a really fortunate situation for me.
[00:11:00] Well I'm really glad you shared that because I really like the people to kind of see kind of the lens of the trajectory of growth because what is one of the themes that we talk about is innovation and I like to break it into offense and defense and it's interesting, as soon as we jumped on our conversation you are completely you know offense. You're talking about customers. You're talking about delivering value to customers and you know I didn't prep you for that. We didn't like rehearse this at all.
[00:11:30] It's just the kind of the gear you went to and I like that because, but I also there's two different types of innovation and I want to get back to APIs and microservices in a second but I, but how do you, you know if you were in a room with a hundred CIOs and they're asking you questions about how you add value to the business do you break it down into offense or defense or how would you answer that question of how you think about how they should think about adding value to the business? What question would be the one that you would say they'd need to ask themselves?
[00:12:30] Yeah, it's a really interesting point and I think it's almost an evolutionary part of the process of me getting to, you know, to doing the job that I do. There's been a couple of things that have changed pretty dramatically over the last 20 years or so in terms of the role of the CIO in an organization. When I started doing this my job was to keep the lights on, make sure that the factory systems were operating, make sure that the financial systems were operational, make sure that everybody's laptops and desktop machines were running smoothly but we, you know nobody really perceived technology as a growth engine or as an enabler. You know and some companies did but a lot of companies did not. As a matter of fact I would say there are still companies today that don't but the vast majority of successful companies and companies that are growing obviously recognize how critical technology is, in terms of being a differentiator and an enabler.
[00:13:30] I think what every good CIO, well first of all the first part of that what I described the keeping the lights on that's become the new table stakes. I mean if you can't do that odds are you're not going to be successful with the other pieces and to some degree that's stuff gotten a little easier because the underlying technology's improved. I mean the hardware platforms have been simplified. There's more commodity hardware out there that things operate on. The software application world has gotten better. You have more SASS based solutions that make a CIO's job easier because they're not over, you know they're not necessarily responsible for running everything any longer. So that piece you'd better be able to do and there's really not a lot of conversation now.
[00:14:30] If you've got a company that's doing a monolithic ERP implementation you know that's sort of a different story and then you probably want to make sure you've got somebody on staff that's been through something like that, because it's non trivial but the real piece and the part of the job that I think is the most enjoyable is the working with my peers you know at the senior levels of the company to understand what the overall corporate strategy is and to talk about how we're going to use technology as a differentiator to drive our growth and to provide customers with a better experience and everything we do, you know we don't do technology for the sake of technology any more. I mean we, I have a personal role to make sure that the rest of the organization is well educated in the direction that technology's going and the capabilities that it can deliver but one of my other primary responsibilities and I think the responsibility of any good CIO is to understand the overall enterprise strategy and figure out where technology is going to play a critical role in enabling that and helping exceed expectations both of the business and of customers.
[00:15:30] You know almost everything we're doing inside the organization right now has either two components. One is either to try to take cost out and complexity out of how we operate the business but the second is how do we speed up innovation, how do we provide a better experience to customers. How do we make sure that we're, you know we're preforming in an agile way so that we can respond to feedback or threats more quickly then we were previously able to do? So it's really sort of that two prong strategy, you know driving innovation but also effectively managing cost at the same time as you're sort of keeping everything operational at the same time.
Bill: Can someone take, can you innovate by taking cost out? Like, do you, have you seen that? Like, reducing complexity seems to me a part of a unique capability that could be seen as innovative but is that how Experian and how you would look at potentially adding a lot of value from the CIO perspective?
Yeah. I don't think that, I mean that I think that they're, let's put it this way, they're definitely not mutually exclusive. I do believe that you know the reason that we want to take cost out is not so that it flows necessarily to the bottom line. It's so that we have it to reinvest in other areas. I mean you know we spend you know the same type of percentage of revenue on innovation and technology that most companies would that are technology companies but a much, I would really like to see that spend allocated largely towards innovation and growth and not towards support and running the mothership and complexity is, complexity drives that cost up. The more variations of platforms that you have the more different languages you use, the more different database or back end technology you have in place the less money you have to spend on innovating and driving growth because that complexity just inherently drives cost.
[00:18:00] I mean if you think about it, you know if I had one database provider instead of five I could get leverage with that one and potentially save a good deal of money but instead the spend is spent over five different providers and you can well imagine in a multi billion dollar company that takes on new, you know new, a dimension all its own because we're not just talking about databases. We're talking about programming languages. We're talking about hardware. We're talking about co-location facilities, data centers. You know, a lot of that you know complexity and by the way you know complexity's probably not the right word. The right word is probably more diversity because it's not that this stuff is overly complex. It's just you know there's just too many to choose, you know we just have so many to choose from that it adds to the cost drivers. That's, so I wouldn't, I don't want to make it sound like it's overly complex because it's not. It's just overly variable I guess.
[00:19:00] You know I do like the word complexity though because I think some culturally some organizations aren't ready for the CIO to play offense with innovation. They're still leaning into marketing and sales and such and so I often say to the CIO that they can be very very successful with their lens into the defense areas or into supporting offense and driving out complexity because like you said it adds that undue burden, but I like your point about being able to reinvest that into innovation and that kind of leads me to my next question because I know you have a very robust innovation lab at Experian and when I was talking to Eric Hallar a couple months ago he mentioned that he sort of has, he sort of meets with different business leaders and I never asked him about how you interact with the innovation lab. Maybe you could take a few minutes just to explain how that works within your, for you and within the organization's innovation lab.
[00:19:30] Yeah. I'm so glad you brought that up because Eric and I are super tight. I mean Eric's one of my closest friends inside the company and so I'm down in San Diego on a regular basis and I invite Eric. I almost view Eric and his team as an extension of my team. So for example I'm going up to Microsoft for a briefing next month and the first person I reached out to was Eric to say hey I'm going up to Microsoft. Do you want to, you know is there somebody from your team that you want to send with my team you know when I go up with them or do you want to come and same thing, I mean Eric and I you know have made joint calls at Cisco and Oracle and I mean we have a very close relationship and my team works very closely with his team. So my organization plays sort of two roles in conjunction with Eric's team.
[00:20:30] So you know what Eric's team is, Eric's team is kind of like the incubator in a think tank on behalf of the, on behalf of Experian and by the way Eric has teams that are geographically dispersed around the world. He's got, you know his biggest organization was in San Diego but he also has a team down in Brazil and he has a team in the U.K. as well all of whom do, provide a very similar function which is to work very very closely with our largest customers to sort of understand the technology that they're looking for what problems they're trying to solve and Eric and his collection of really smart PHDs sort of look at ways of applying technology like block chain or sort of using cellular phone data to help with fraud detection and you know a whole bunch of really cool sort of incubated ... Yeah.
[00:21:30] So what my team does is a couple things. One you know if Eric's having any kind of an issue inside the company, getting the technology that he needs or the support he needs, I'm the first guy he reaches out to. I mean I talked to Eric actually over the weekend because off the record just between us apparently some of my guys removed administrator access from a couple of his guys and that was a real problem. It turns out that it just, it was a, it wasn't intentional. We had, it had timed out and so we just needed to re-enable them but we provide them with their sandboxes, their hardware environments. We support them in terms of anything they need from an infrastructure perspective and we also work collaboratively with them to try to determine certain standards. So for example when we needed to pick a hadoop platform the first, you know one of the first people I reached out to was Eric to sort of say hey which, you know which of the hadoop distributions have you guys worked with?
[00:22:00] Do you have a particular one that you're you know that you like better than the others so that before we start to drive a standard we make sure that we're you know working with your team to not upset the alpa card. So it's a very very collaborative and by the way my chief enterprise architect also spends a lot of time in San Diego working with Eric and his team. I mean it's we're really you know my team is pretty much an extension of his and his is pretty much an extension of mine. I would say that as far as organization, and by the way Eric and I report to the same guy. We both report in to the chief operating officer.
So we're under the same umbrella as well. So it's a you know it's a really good relationship and we work on a lot of stuff together inside the organization.
[00:23:00] So when you guys are looking at ways, so he's, is he essentially floating amongst the business departments to look at ways to the customers are looking to consume information and looking at speed of the two major points you brought up earlier and then he's taking those back and then your, are you actually trying to figure out ways to kind of integrate what their findings are so it can scale across the whole organization? Is that a correct assumption?
[00:24:00] Yeah. Most of, a lot of what Eric's team focuses on is analytics and sort of looking at ways to solve complex math problems or technical or decisioning problems. So Eric's team tends to focus less on sort of like, like my team you know my organization was the one that said hey look we need to create an API hub for the enterprise so that we have a better way of sharing information both internally and externally. That's not something that Eric's team would do. On the other hand Eric's team came up with this really cool thing that we call mobile prequalification that he probably talked to you about. You know my team wouldn't come up with that. His, you know we provide, we help facilitate it by providing the environment that he needs to run it and to make sure that the network, our network is configured to allow them to operate that way but that's sort of the idea generation for that product came out of Eric's organization. Not out of mine.
[00:24:30] Okay. Okay. Excellent and so that leads me to the API piece. So I'm sure you've read the book Exponential Organizations by Salim and if you haven't and serendipitously it was interesting because one of the sections about the CIO is the use of APIs moving forward and specifically for the reason you mentioned which is the enabler to data access and that, so how did you come up with this idea of the API hub and how does it frame your thinking now moving forward with either how your organization consumes from others or how you're providing that to your customers?
[00:28:00] Okay. You asked a really good question about the whole API component. So let me give you the background sort of how that came to be because it's kind of a interesting story. So when I joined Experian two years ago one of the first things I noticed was you know we have enormous amounts of information that we either subscribe to or we get from the financial institutions but one way or another we, we are constantly getting, adding new data sources and adding to the data sources we have and well the data is all pretty much owned by Experian. We have multiple lines of business inside the company and as a result of our growth through acquisition we have a number, you know these data sources may reside or may get loaded into Oracle or DB2 or SQL server, any number of different data back end platforms and then there are, there's quite a diversity of data schemas in terms of how the data's stored.
[00:29:00] The issue with that was that if, you're in one part of Experian and you want access to a certain data source you could, you know we can give you access but the problem was the data schema, the complexity of how the data is stored made it very difficult for people to share information internally and so and the other issue was that as we started to consolidate these data sources onto a common set of platforms you ran the risk of breaking a whole bunch of interfaces and so the first idea was we're going to create an API hub that all of the lines of business can leverage to register entry points so that people can access their information internally, so that I'm in the credit services organization and somebody in the decision analytics organization wants to access my information I'm going to give them a bunch of API methods, entry points and microservices to get at that data so that I don't have to be engineers to help them write their code.
[00:30:30] Oh and by the way if I decide ultimately that I'm going to change from Oracle or DB2 or SQL server to hadoop or some other backend platform their code won't break because if they use an API hub to gain access to it and I change out the backend it doesn't change the API. It only changes the you know where the hub the data's stored and as long as we don't deprecate those API calls everything will be great. So the idea was to set up an environment that would allow to help accelerate innovation inside of Experian but by providing a set of microservices and API methods for sharing data internally. When and that was received you know very well. Everybody sort of agreed yeah this is something that would be really helpful to have. Then as we started to talk about it more and more I started, we started to hear not only was this something that would be useful internally but we started to hear that our customers would be very interested to having access to the information themselves that way as opposed to programmatically.
[00:31:00] They want to write their own applications and their own programs and they may only care about the specific data elements. So if we gave them an API entry point for doing that they wouldn't you know it would give them another way of accessing the information the way they want to instead of the way we want to dictate it to them. So there was actually two use cases that were originally identified for the API hub that we stood up but the original driver was to help drive innovation internally and then a secondary output was that you know customers we started to hear from some of the largest financial institutions that they were really interested in accessing the information through microservices as opposed to through an application portfolio.
So microservices allow you to not necessarily need to have a fleet of engineers trying recode, or coders trying to recode these changes but they can subscribe to the service they want and so you were trying to eliminate friction within cross departments needing access to this? Is that correct?
[00:32:30] Absolutely. Yeah. Your, that's exactly right. Right now the way a lot of people build applications is like totally different from, you know when I went to college you know you learn FORTRAN or C++ or PL1 or whatever the language was Dejor, and you know you had to write all of these services internally yourselves. I mean writing you now know you couldn't build a distributed application unless you were a PHD in computer science and you certainly weren't going to have a set of you know, the first inclination of these types of services was things like DCOM and Publish and Subscribe and CORBA, all the old sort of 1980's 1990's distributed computed models that were the precursor to APIs and microservices. The problem was that a lot of that stuff really struggled to get traction because it was so difficult to use. If you fast forward to where we are now these services now are very you know we have the internet which can be used as a connection mechanism over a secure socket layer.
[00:33:30] You don't you know, people are learning how to write these kinds of programs right out of school. Today I would say and I don't mean this in a negative way at all but today a software developer in many cases their job is to assemble the pieces and put them together. It's not necessarily to write code the same way and the more microservices and the more out of the box capabilities that you give to them that they can connect to or use the less code they have to write and so there is sort of this big movement towards and that's a big part of this whole push around things like platform as a service whether it's you know the AWS platform or the Azure platform or the Google platform. I mean there's underlying technology that runs in all of these platform is a service environments but the real objective is to make people more productive more quickly so that they're not having to write as much code. They're more sort of assembling Lego blocks as opposed to building the Lego blocks themselves.
[00:34:30] Yeah. I love that analogy about Lego blocks and it was I think you're, I mean you're right on. I was just with a CIO the other day and they were subscribing to APIs. They're putting an instance of SQL in the cloud in Microsoft's platform as a service and they want to subscribe to data coming from NIH because that data is needed for their customers and I love the way he was thinking about it and it's completely to develop a new revenue stream for that customer that needs data from NIH couples with theirs that this as an association provides and it's really combining point one point A and point B from two different sources. So I love how this Lego block mentality that you have because I do believe that is a real nice way for the CIO to add tremendous value because you said you were going to go to Microsoft, right, and you said you're going to be going there to kind of get an overview of their new capabilities? Is that the way what I heard earlier?
[00:35:00] Yeah. We're doing, it's just sort of, I mean we typically do sort of the you know our year is that we're on a March fiscal year. So at the beginning of each fiscal year we tend to go the meet with our largest technology partners just to understand sort of what their road map looks like. So we've got meetings with Microsoft to go over their roadmap for the next couple of years to make sure we understand how it's going to sort of interface with our roadmap.
[00:35:30] So if a CIO wanted to build microservices this capability this API development capability within their organization and they didn't necessarily have the full resources of Experian at their disposal what would be a good question that you could, that they could ask regarding their team that's number one, to see to find out what the skill gaps are that they would need and then what would be a good question that you could ask either for AWS or Dejor to really start the process of building that capability within their organization?
[00:36:30] Well I think the first thing you need to ask yourself in any corporation is do you have, you know do you have people that thing this way or sort of understand the need to build component ties a technology stack. In other words you know I'll give, the simplest example that I give people from microservice is the spell checking. You know, ten years ago if you wanted a spell, If you were building an application and it needed a spellchecker what did it do? You wrote a spell checker or you embedded a spell checker into your application as a piece of code. Today I can't help but think that nobody would ever want to build a spellchecker. You would want a basically, I mean the only thing that a spellchecker needs is you submit a word to it and it can only return, it returns either it's spelled correctly or it's spelled incorrectly and if it's spelled incorrectly it may give you a list of suggested words that you can replace it with.
[00:37:30] That's all a spellchecker does. That the perfect, that's, it's a perfect example of a very simple microservice that somebody could write. You pass it one thing and it returns a yes or no and in an array of suggestions in the event that the result was negative. That, now the, but the question sort of that I think any organization needs to ask itself is does, you know if you were building an application would you use microservices to achieve that result or would you write your own piece of code and if the organization comes back and says oh we'd write our own piece of code every single time then you don't have people that are sort of thinking with the right mentality for building a distributed application or building out a set of services. So I think the first thing you need to do is sort of access your organization and say you know see does it have the right thought process in place and the right skill set to do this kind of, to build things this way?
[00:38:30] So I think that's step one. Step two is sort of identifying you know you really need to, you do need to make some choices and I think that the question so for example we've selected Red Hat's OpenShift platform as our standard development stack for building applications on any platform. So it doesn't matter whether you're building in an AWS, in Azure, the Google Cloud, on prim, in co-location facility, you have to use containers and you have to use OpenShift as your platform because what that does is it gives us complete portability of the applications that we build so that we can run them anywhere we want whenever we want but as a, you know as somebody, now we picked Red Hat's OpenShift because it met most of our requirements but there are numerous other platforms that you could choose to do the same thing.
[00:40:00] I think that if you determine that you have an organization that's capable of doing this you need to pick the platform that you're going to standardize on as an organization in order to drive this type of process going forward. So whether it's Pivotal Labs, whether it's Red Hat, whether it's Mirantis, I mean they all have ppen stack implementations. You need to identify what your open stack implementation is going to be or what your platform's going to be so that you're not, you don't have you know five different parts of an organization all going off in directions. I mean they all may have the best of intentions and trying to do the right thing but I have a very big, having worked at very large companies and having run several software companies myself I'm pretty to me standards is a really big deal because it's, without standards you know complexity starts you know you'll end up with a lot of variation in how things are done which often reduces efficiency and drives cost up. So you know the two important things are capabilities and then picking the technology stack that you're going to execute with.
[00:40:30] Well we came, we sort of circled back around to complexity again and I know you didn't like the word originally but coming back to standards and making a choice in selection about the standard and, like you were saying earlier you're executing on this microservices vision on this API vision based on clearly the set of capabilities that you've put in place plus the set of tools and standards you've settled on. So when you're going out to Microsoft you're not asking them, you're saying this is what we've picked as a set of tools, now how do these tools work on your platform of the service for example versus going out with the reverse conversation?
[00:41:30] Yeah. I think that's a maturity question. I think that's, it's a good observation and a good point. I think it speaks to sort where you're at in the maturity curve of going forward. I'm sure that, by the way we did do the other previously. I mean I, we didn't, you know I wouldn't be arrogant enough to think that we do what the best platform was without doing any due diligence or research. So you know before we picked for example OpenShift you know we looked at every other, you know we looked at a lot of other options and considered them and we sort of decided that OpenShift was the best open stack platform for us but one of the things, and we've been very very clear with Amazon and with Microsoft that you know we are not going to be using native platform services. We're going to be using OpenShift on your platform because we want portability.
[00:42:30] We don't want lock, we don't want to end up locked in by using native services and they've now heard that from so many customers that they support all of the common suite of tools on their platform. So you can get Kubernetes, you can get [inaudible 00:41:57] containers. You can get any version of OpenShift that you would like and it will run on virtually every one of these major cloud provider's platforms because enough customers like us sort of said hey, we love what you're doing but we don't want to get locked in to a particular platform. So for example we don't want our software developers using DynaDB on the Amazon platform because DynaDB is native to AWS and while it has a whole bunch of great capabilities and it's really easy to use and it's really fast the second you committee to using DynaDB you lose the portability and you can't, you wouldn't be able to move something for example to Azure if it had DynaDB code embedded in it.
[00:43:30] So instead we basically have said you've got to use something like Cassandra or Postgres or MySQL or one of the more portable container, you know [inaudible 00:42:53] into a volume that's not a native service but that is portable. So yeah when we go, when we talk to Microsoft now or when we talk to Amazon or when we talk to Google it's more about tell us about the tools that are, that you have on the platform. Tell us about what you're building this platform across all the other cloud platforms. You know, what, where are you, you know where are you headed from a disaster recovery and business continuity perspective, how, what can we expect from a reliability standpoint? I mean we, in our business we obviously are looking a minimum of four 9's, preferably five 9's of uptime guarantee. You know, those kinds of things. Those are more of the types of conversations then, hey tell about your, you know tell us what are the differences between Azure and Amazon.
[00:44:00] Do you ultimately have the vision of being able to move between these different cloud environments with this containerized approach, like is it unreal or is it too big of a jump to say that you would want to be able to move a workload from like Azure to AWS in the future or is that too big of a leap?
Barry: No. That is not only aspirational. It is a requirement.
[00:44:30] We are incredibly prescriptive about the tools and the technology and the way applications are built so that it's a build anywhere, deploy anywhere type of model so that not only do we, we're getting the developers to focus on building what I would call truly native based cloud applications. So not only should they be able to be run on and moved from Amazon to Azure or visa-versa, we should be able to with a click of a button move them from Amazon to our own data center, from our own data center to Azure or as we need incremental capacity have certain components that can be run in the cloud as well as on prim.
[00:46:00] So we may actually, in some cases we have one application right now that the lion's share of processing actually occurs in the cloud but a big chunk of the application is actually still running on prem and the reason we built it that way is because it's got a lot of seasonality to it and we didn't want to have, if we had to invest in all of the hardware stack that was necessary to run it during peak 90% of the time that hardware would be sitting around and be idle or not necessarily consumed or we would have to put another workload on it whereas if we built it as a hybrid application where some of it's running in the cloud and some of it's running on prim as we need incremental capacity it can auto scale in the cloud so that if all of a sudden it's Christmas time and the utilization goes up in order of magnitude the cloud provider will automatically burst the capacity to meet our demand without us having to do anything whereas if it's running in my, if that chunk of it's running in my data center or our data center all of a sudden I get a phone call in the middle of the night saying we need to spend a million dollars to buy a bunch of additional blades to support the fraud application that's running McKenny because it's about to hit its limitation. Those are not phone calls we like getting. So you know this hybrid cloud development gives us a lot of bursting capacity that we didn't previously have.
[00:46:30] Well I love this conversation because it's essentially I feel that it's kind of the tip of the spear from a lot of conversations that a lot of people listening is you know what's possible and what are the guys that are, kind of the biggest problems having to face right now and I imagine with having that portability between clouds is not just the marketing pitch but something that you're going to, you're really forcing the vendors to make real by your requests and are you also requiring these workloads to stay in the U.S. or stay in North America? Is that something that falls under you?
Yeah. It varies. So we operate around the world and every country has different data residency laws. So in some case, so for example U.S. Data all reside in the U.S. They're not prescriptive about whether it runs in our data center or somebody else's data center but it does have to reside in the U.S. Other countries are not as restrictive about data residency. So for example India currently does not have a data residency law. So we can run our India bureau out of the United Kingdom.
[00:48:00] Now those things, the challenge for us is those are subject to change which is another reason why application portability is so critical because if we build out an applications that servicing a certain geography and it's running in one part of the world and all of a sudden a legislative law or a regulatory requirement comes forward that says hey that data all has to reside in Columbia or in Argentina or and it's currently not there. You can't it can't take you know months and months to move it and it can't cost millions and millions of dollars. So this model of using containers and having portable hybrid applications gives us the ability to not have to worry about data residency laws that potentially change on a regular basis.
[00:49:00] I love that. Well I want to respect the time. I think we're coming up close to the hour that we had scheduled together Barry and I. I really appreciate you for your time and your wisdom you're sharing with all of the people that are going to be hearing this episode and just one final question for you is and this, taking a shot in the dark here but I think it would be, you're going to give us an interesting answer is so you worked with Oracle when they were only a 19 million dollar company and I'd love to know what the most, what the best lesson that you've learned from your time with Oracle or for that matter if you've met Larry Ellison what you've learned from him and then and also like what else has been sort of the mantra that you have, has stayed with you through you career either through mentors or such that you can share with the audience as we wrap up?
[00:50:00] Yeah. I mean I do know Larry and did, have been fortunate over the last 30 plus years to get to interface with him and have also been very close with Oracle in virtually every one of my jobs either both in terms of their application stack as well as technical stake and have quite a few friends there still. Larry has and always will be one of the most brilliant people I think I've ever been fortunate enough to get to meet. The truth is it's very difficult to embellish a Larry Ellison story because there are so many of them and a lot of them there's always, there's quite a bit of truth to many of them but Larry was has and always been one of the greatest technology visionaries I, you know I've ever known.
[00:51:00] The thing, one of the most key takeaways for me from the early days you know back in the '80's at Oracle is Larry is one of the most fierce competitors I, probably is the most fierce competitor I've ever met in my life and when, you know there was, when Oracle was a small company there were quite a few database companies that were still you know in play. You had you know Ingres and Informix and Sybase and it was fascinating to sort of watch Larry's approach, systematic approach to competing and systematically taking out the competition sort of one by one with just an unbelievably relentless focus on the task at hand and you know I learned a great deal from that kind of you know perseverance and that single focus that I think has been useful to me throughout my career. You know, failure was never an option when you were at Oracle and it was a brutal culture but a tremendous learning experience.
[00:51:30] Tremendous number of brilliant technology people but you know that single focus of the company, the company's ability to sort of bring everybody together moving in one direction simultaneously was extraordinarily effective in terms of allowing the company to grow and become what I believe it's become today which is you know one of the largest technology companies in the world and you know the people that are you know the people that are most responsible for that in my mind are Larry and Sassa. You know two people I have an enormous amount of respect for.
Well I appreciate that and as we get wrapped up is there anything about that you wanted to let people know as far as how to reach you or anything in particular? Any ways that people can reach out if they have follow up questions for or clarifications of something you said?
Barry: Yeah. The best approach, I mean I'm on Linkedin. There's only one Barry Levinson on Linkedin to the best of my knowledge.
[00:52:30] It's and you know I do check my, I do you know check for activity almost on a daily basis. Happy to interact or you know exchange information with anybody you know through Linkedin that wants to you know keep the dialogue going.
[00:53:00] Well that's great and I'm going to put links to, I know you've written an API piece recently. I'm going to put links to that on the show notes, things to connect with you on Linkedin. Also more information about Experian, Experian's data labs, etc but I do appreciate you to your commitment to sharing your wisdom which is completely you know very very deep well of knowledge that goes you know back to the beginning of prior the real internet starting in '95. So it's quite a bit for people to learn from this today. I know I learned quite a bit as well and thank you for your time.
Barry: No, I appreciate it and I'm going to try not to feel old now.
[00:53:30] Well I think we need wisdom in these days as things get fast we definitely need people that have been there through it all because that is more wisdom than anything else needed at this point in time. So thank you.
Barry: Appreciate it. Great. Okay.
Bill: Bye bye.
- About Experian’s DataLabs
- How Hadoop helps Experian crunch credit reports – CIO.com
- CIO Secrets to Great Pizza: The CIO Interview with Barry Libenson, Land O’Lakes – Heller Search Assosiates Blog
- Experian CIO embraces APIs and microservices to improve data transfer – Computerworld.com
- We Too Often Ignore the Tradeoff Between Innovation and Efficiency – Inc. Magazine
- How Experian is Turning Big Data Into Big Dollars – San Diego Union-Tribune
Ways to connect with Barry Libenson:
* Outro music provided by Ben’s Sound
Leave a Review
If you enjoyed this episode, then please consider leaving an iTunes review here
Click here for instructions on how to leave an iTunes review if you’re doing this for the first time.