Cornelia Davis Talks about Software Transformation in Enterprises

1. [...] Cornelia, why don't you take a moment to introduce yourself to the InfoQ audience?

Rags's full question: Welcome InfoQ audience. With me, I have Cornelia Davis at the Collaboration Summit. Cornelia, why don't you take a moment to introduce yourself to the InfoQ audience?

Sure. Thanks, Rags. My name is Cornelia Davis. I'm the CTO of the Transformation Practice at Pivotal and I was here at the Collaboration Summit and I did a talk on Transformation and Platform and how those come together. I am a technologist by background, been in software computer science my whole career and have found that technology is not enough. So we'll talk a little bit about that today I think.

2. I was at the talk obviously yesterday and I learned quite a few things as well. But what does transformation exactly mean? What does it mean to a developer an architect or maybe even an enterprise developer who is I don't know in the middle of like a 40,000-member company or something like that? What does transformation mean to that developer?

Yes. So it's interesting. Let me give you a little bit more of my background, a little bit of my history. So I have been with Pivotal since the spin off almost three years ago and been working with Cloud Foundry and I was in the field facing capacity where I was explaining, as I said, I'm a technologist. I was explaining the technology of the Cloud Foundry Platforms to individuals. And so I would explain to them how they can deploy code and how they can manage code and operate the code and someone and I found myself spending just as much time talking about non-technology things and that's really where the transformation comes in is that in order to use a new platform like Cloud Foundry which is fundamentally different than the client server platforms that we have from the previous era, they need to change other things as well.

So for example, when you are going to deploy code into production, today there is a multi-step process where you have to do things like add entries into DNS and you need to add entries into a load balancer and then you need to set firewall rules and all of those things. And the way that developers and the way that application operators worked today is that they are very constrained by those processes, so it's not just a matter of writing code, it's not even just -- In fact, even developers very often don't write a lot of code. They spend a lot of time doing things like writing specifications, getting approvals and submitting forms and all of that stuff.

And so when a developer is working in a large organization and they want to do things more agile, they are often times constrained by those processes that are in place. And so transformation is not just transforming the individual. It's really transforming the whole organization to do things like rethink their processes around the new platform, re-think their processes around the new requirements. It used to be okay that we release software every two years. It's not anymore. We need to really software every two days or two hours.

3. [...] Agile Devops and all that is not completely new but cloud, containers and all that is relatively new. How does this affect the transformation again, with the new enterprise?

Rags's full question: I think again, in your talk, you talked about Amazon which releases pretty much every minute of something like that. So, Agile Devops and all that is not completely new but cloud, containers and all that is relatively new. How does this affect the transformation again, with the new enterprise?

Yes. So fundamentally, I just alluded to it a moment ago but fundamentally, the transformation starts with the need to bring value to the customer in a different way. I just alluded to it where we said we used to deliver value to a customer every two years. We'd give a new release. And now what we want to do is we want to continuously deliver value to a customer. So it's really about that constant evolution and part of the reason that we wanted -- One of the ways that we can deliver value to the customer continuously is by showing them things all the time, showing them something, getting their feedback, making adjustments, pivoting on that feedback that we get back. So it's all about that rapid iteration and it's those short feedback loops that's really again transformation is about bringing value to the customer in a new way and it's all about the short feedback loops.

So how we tie that to containers? Containers are really -- they are fantastic but it's really just an implementation. It's one of the elements that allows us to do what we are trying to do which is deliver value to the customer more quickly. So containers allow me to very rapidly provision things, try things out, get feedback back, dispose of those containers and those containers are not only supporting -- When we give it -- deliver it to the value to the customer at the end but it supports the entire software development life cycle. It allows the developer to rapidly iterate on things and constantly be for example from scratch when they do a deploy so that it's easy for me then to do that same deploy in production and not for example have drift between my development environment and my production environment. That's one of -- containers are just one of the elements that supports that.

4. [...] What would be your recommendation to somebody who was starting off this transformation process? Would it be better to go with the platform that's -- has some history versus kind of roll it on your own? Is there a point where it's better to roll it on your own versus using a platform that's established?

Rags's full question: Kind of keeping around the same line, I think the platform is critical but it's not the only piece. So I could kind of roll my own platform, if you will, but Kubernetes, Mesos, Docker, name the different technologies out there. What would be your recommendation to somebody who was starting off this transformation process? Would it be better to go with the platform that's -- has some history versus kind of roll it on your own? Is there a point where it's better to roll it on your own versus using a platform that's established?

Well it really depends on a couple of things, the first thing that I'll say is as you already alluded to, companies like Amazon and Google and Netflix and Facebook, they have been building those platforms that support the way that they bring value to their customers. They have been building those platforms for some time and those platforms support kind of this very streamline DevOps cycle, the question about whether you want to build your own platform or you want to consume one is really what your company is in the business of doing.

So many of these companies, company like Google, well they were the pioneers in creating these absolutely massive internet scale platforms. So there wasn't a platform ten years ago for Google to deploy their value add which is either search or Google apps or something like that. So they had to build that platform to support that and they built a platform that's very specific to the things that they needed in that. So the question is when you go to a company like a financial services company or a retailer, is your business about building that platform? Or are you bringing value to the customer by bringing a better loyalty program if you are in retail for example.

So it's where do you want to spend your cycles and are you bringing value to an -- bringing value to your customer by creating your own platform or can you just leverage a platform and really focus on the value add to your customer base? By and large; it is in most cases the answer for large enterprises like that the answer is don't build your own platform. That's the undifferentiated heavy lifting. Ten years ago, we didn't have that. We have that today.

5. [...] Can you talk a little bit about the direction of Cloud Foundry in general and how it's going to help in the transformation process?

Rags's full question: Obviously you came from the Java world, the Java EE world and now you went down to Cloud Foundry. Can you talk a little bit about the direction of Cloud Foundry in general and how it's going to help in the transformation process?

Right. So Cloud Foundry was developed right from the get go with the different set of abstractions. So when we talk about the old stacks J2EE, it was still within this client server model and I want to say it again. It was within the client server model. So servers were really still the fundamental abstraction that we had to deal with. So yes we layered the J2EE stack on top of that but when it came to actually delivering those applications to the consumer deploying them into production, we still had to deal with servers.

Now Cloud Foundry fundamentally starts with a different abstraction. They say really to get closer to the value that we are bringing the customers, what are we delivering the customers. Well we're delivering digital experiences, i.e. applications. So the fundamental primitives that Cloud Foundry is based on are applications and then ancillary services that are leveraged by those applications. So services would be things like data bases or message queues, those things that developers used to really bring those applications to consumers and so Cloud Foundry from the get go has always has that has always had that as the central abstraction.

And that having that is a central abstraction supports the developer. It supports the operations individual which increasingly we areblurring the lines between those things. And of course it is again the abstraction that we are delivering to the consumer. So that's been the core of Cloud Foundry from the beginning. What we're doing with Cloud Foundry moving forward is keeping that as the core abstraction and we will start to layer more and more things around that core abstraction. So for example, an application would be an API. So layering more sophisticated routing services around that application, more sophisticated identity access in those things around the application that continues to be the core abstraction that we layer more and more services around.

6. [...] What has been your experience so far at Collaboration Summit?

Rags's full question: We are at this Collaboration Summit and some of the thing or a lot of things and it seems like there are a lot of overlaps for example. Blockchain is talking about identity. Identity is something that I think even the Cloud Foundry Platform can benefit from, right? So this collaboration summit is really about kind of collaborating amongst these different standards. I think it's great. What has been your experience so far at Collaboration Summit?

Ah, yes. Okay, so the Collaboration Summit has been fantastic. Right from the beginning from Jim's opening keynote where he laid out kind of this grand vision of bringing these things together and certainly also the open source, I do have to take a moment to just say again, I work with very large enterprises and a big part of the transformation journey is a cultural journey. So I talked about this very rigorous kind of command and control processes that we are trying to move people away from and moving towards a culture that is a bit more that is considerably more open source-ish in the culture is a big part of that.

And so that's been a significant thing for me at the Collaboration Summit as to really be thinking about that open source culture and how we bring that to organizations and there have been talks on that and that's been really fantastic. So it's not just the standards. It's all of those other things that wrap around it, the way that we deal with IP and the way that companies have to change the way that they deal with IP in this new world. It's a cultural transformation there as well.

So it's that -- One of the most interesting things though of course has been the CNCF, so the Cloud Native Foundation which is really a group that's trying to pull together all of those disparate standards and initiatives. It's not only standards but initiatives under this Cloud Umbrella because Cloud encompasses so many different things. It encompasses image formats and Docker and as well as orchestration standards and all of those types of things. It really encompasses all those things.

So when it comes to something like the Cloud Foundry Platform, there is -- You mentioned for example identity. So the Cloud Native CNCF is trying o pull -- is doing some of that. It's pulling the other and saying identity is important across all of these different things. Identity matters for orchestration. It also matters for a Cloud Native Application platform like Cloud Foundry. And certainly Cloud Foundry will start to adopt some of those things.

For example, Cloud Foundry is looking at runC which is something that is being addressed within the CNCF as well. So Cloud Foundry is very much looking to become even more and more pluggable. We're already pluggable. We have pluggable things, build packs for example are pluggable, you can bring your own runtime environment into Cloud Foundry and there is a -- It kind of defect standard, build pack standard that we are using for that. We're also bringing in runC as an alternative container. And those are the types of things. So we will continue to do that within the Cloud Foundry ecosystems for sure.

7. [...] ny closing thoughts on -- kind of advice to developers of where to start with the journey, the transformation journey?

Rags's full question: I think we covered pretty much everything that we wanted to cover. Any closing thoughts on -- kind of advice to developers of where to start with the journey, the transformation journey?

Yes. So what I would say is I think my closing remark is going to be a little bit about the thing that's run through the whole conversation which is that a platform like Cloud Foundry is fundamentally a new shift, the IBC and various other organizations call it the third platform, the first platform being main frame, the second platform being client server and the third platform now being this fundamentally different platform. What I would say to developers and operators, anybody who is dealing with software, any stage of the software development life cycle is that this new platform and these new primitives allow you to rethink the processes that you have around that. It allows you to transform those processes and in fact to be able to really truly use this new platform and these new primitives, you have to rethink those processes.

If you look back on the last two or three decades and my son is in computer science now in college and they are still learning all of those things that are primarily centered around that client server model. They are learning about three tier architectures. They are learning about MVC and even the software development practices that are being taught or centered around that.

What we are going to see now in the next ten years and 20 years is we are going to see everything shift and ten years from now computer science students in college are going to be learning about abstractions against this new platform and that's what I would challenge, developers and operators is to start thinking about things differently. We truly are at the cusp of a new platform which allows you to rethink all of your processes. It's an extraordinarily exciting time to be in the space and so I would -- I think my final words would be one of my favorite quotes in one of my favorite movies is from the matrix and that is "Free your mind."

Rags: That's a great place to stop and thank you everybody for listening. Thank you for doing this.

Thank you, Rags.