Cornelia Davis

My name is Cornelia Davis. I work for Pivotal. I'm a senior director of technology there.

I've been there since the Pivotal spin-off, about three and a half years, but I've been working with our Cloud Foundry product for about four and a half years. For the last three and a half years, I've had the tremendous opportunity to work with a great number of large enterprises on this transformative journey that they've gone through, where they've taken some of the things that we've already seen stories on this morning in the keynotes. And if you were in the room, I was just in the room with KeyBank the half hour before.

These challenges of these broken processes that are not allowing us, that quite frankly were processes that were built for a different day and age. I, for example, when I was in college 30 years ago, learned about the waterfall methodology. That was the best practice at the time. But those things aren't working for us anymore.

So I've had this tremendous opportunity to work with many large enterprises, many of whom are at this conference this week, in that transformative journey. What I want to share with you today is an outcome of those three or four years of experience. It's still obviously evolving, and I'll talk about some of the places that it's evolving, but I think we're going to have an awful lot of fun for the next 25 minutes or so.

You've seen the title of the talk, which is DevOps: Who Does What? It basically says, yeah, we've got these great ideas. We know the silos aren't working. But then how do I take those roles that I have in these silos today, and what is it that they do in this new DevOps world? So let's have some fun.

The first thing that I'll pose is, let's look at where we're starting from. So is this where you're starting from? And this is usually, you can cringe and you can put your head in your hand. We've got a whole bunch of what? Silos.

And across those different silos, we've got individuals that work in those silos. And what typically happens today is we have an idea and we create a project. Not a product, but we create a project.

I have spoken with the PMO office of one large organization, where I asked them, "Okay, when you've created that project, what's the first step?" And they said, "Oh, well, we assemble the project managers."

And I said, "Well, how many do you have?"

And they said, "On a given project, usually about 15."

And I said, "And how long does that take?"

"Oh, that takes about two or three weeks."

So that's the beginning of a project. You establish a project, and then this is the way it generally works. The first organization goes into the project and they do their work, and they create the artifact, and they throw the artifact over the wall. Earlier today, somebody depicted that as a queue. They throw it over the wall and they leave. That's the thing. They leave the project. And the next group comes in and they do their work, create their artifact, and so on it goes down the line.

So yes, this is probably a lot of you, your reality today.

It gets worse, though. If we take a look at this and we really study it, and we don't have to study it too deeply, the problem here is that these silos are locally optimized, and you don't end up getting a good global outcome.

My favorite example is AppDev and QA. AppDev is generally incentivized to hit the schedule. Did they release the set of features that they were supposed to release on time?

Now, what happens when you start getting behind? Well, the dev teams are asked to work nights and weekends. They get fatigued. They are also sometimes asked to cut corners: "Don't write the tests. Go ahead and just focus on the implementation." And what happens as a result? Well, quality degrades.

Well, they hand their thing over to the next group, quality assurance. What are they measured on? They're measured on finding bugs. What happens when quality degrades? They find more bugs.

So both silos are getting rewarded for their individual things, but the global outcome of a streamlined process to bring great value to a customer suffers.

The solution is to bring these teams together into a balanced team. Get rid of the silos and focus on a product. Product orientation instead of project orientation. We've already heard that theme several times today, but then here's the question: What do all these individuals do within that product development and bringing it to production?

The product teams, of course, they are measured on bringing customer value. So different product teams. There's a product team that gets measured on, did they provide the best imaging, the best images for products? Another one, are the recommendation engines resulting in additional sales? Those are the things that they're getting measured on, not arbitrary things like number of bugs.

So if these are the silos, and I changed the silos a little bit, but these silos here, if you look across the top, they probably sound very familiar. We have enterprise architecture group. We have this chief security office. We've got an infrastructure team, and AppDev, and maybe middleware, data, enterprise applications, and so on. And you can see that there's a whole bunch of roles or activities that people are going to do in there, like doing software architecture development or doing capacity planning.

How do these individuals and these activities get reorganized into the product team? Well, let's sort them. We're going to sort these individuals. We're going to put them into the sorting hat and see where they come out. But the question is, what houses are we going to sort these individuals into?

And here, we need to go off and set the stage a little bit more. I'm sure you're all familiar with this kind of eventual progression through here. That's the old world. That's the world that we created those silos. That's the world we were living in when we created the silos and the waterfall methodology.

We started to move forward, and again today, we've already heard people starting to talk about infrastructure as a service, providing more rapid ways of getting infrastructure assets to their development and their operations teams.

Now, if we take that one step further and we say, well, let's not just focus on infrastructure, but do application platform as well. An application platform that gives you application dial tone, that allows a group of individuals to really just focus on their application code. That's the next natural progression, and that's really where the industry is. There's a tremendous understanding, at least, of the value of an application platform, a cloud-native application platform, even while we're still learning how to implement those things.

Now, that application platform, if we have those delineations, that now allows us to do this. It allows us to define an application team, and that's the team that's responsible for the end user-facing application, the consumer-facing application, the partner-facing application, or even the internal application that, let's say, an associate is using in a retail space.

It allows us then to separate that application team from a platform team. The platform team is responsible for providing the platform so that the application team can do their thing.

Now, if you look at the responsibilities across these two different teams, you can see that they're very similar. The application team is responsible for configuring their environment, deploying their application, monitoring it, scaling it when it needs to be scaled, and deploying new versions when you need those new versions. The platform teams are responsible for exactly the same things. They're both product teams.

So the platform team, their product is the platform. The application team is the consumer of that product. The application team, in turn, has their customers, which are the end customers for the applications.

So with that grounding, we'll go back to this picture and say we're going to add a couple of more houses later, but the two houses we're going to start with are the platform team and the application team.

So let's go ahead and start sorting. Now, the first individuals that we're going to sort are relatively straightforward. We've got the application developers. We've got software architecture and server-side developers and client-side developers. So we've got people who are building the web services. We've got people who are building the JavaScript and the AngularJS and the Node.js and all of those things, and maybe an architect who's overseeing all of that.

And then we have some of the roles that were over here in this middleware group. We take those individuals that have the expertise around middleware and server governance, and we put them down in the platform organization.

Now, what's interesting here is that before they were over together in this middleware group. And so what we had was we had a middleware group that said, "We've got individuals that are responsible for understanding how to set up the middleware environment, as well as individuals who are specialized in building applications on that middleware."

Notice that we split those groups out because they're really responsible for two different products. One is responsible for the platform product. The other is responsible for building the product that is end customer facing. So that one's fairly straightforward.

The next one's also going to be pretty straightforward, and we're going to take some individuals from the infrastructure team, and they're going to be part of that platform team as well. So the platform team is responsible for taking all of the infrastructure assets and surfacing them through the right APIs to the development teams.

So what we did there in the first step with the middleware engineers were they were more upward-facing about the API looking up, and we've got, of course, the individuals who are really experts on the infrastructure. We have them working as a part of that team to make sure that we bridge the gap between the infrastructure and the API that's getting surfaced to the app team.

Now, the next one is really interesting. I took an individual that was out of the infrastructure team because often your change management individual reports into the infrastructure organization. They're responsible for making sure that before anything gets deployed into production, we have done all the checks and balances. We've tested everything, and one of those tests is we've tested this in our exact replica of production staging environment.

Does anybody have an exact replica of production staging environment?

Yeah. I saw one hand go up. You lie.

So that's the change management person. But really the way that they do it is they are going through and they have a bunch of controls that they're checking. Did you achieve this? Did you achieve this? Did you achieve this? And those controls happen for every single release.

Well, the chief security officer is doing the same thing from a security perspective. They have their set of controls. So I think everybody's familiar with this notion of with every application deployment, I have to go through a set of controls.

Now, you'll notice that I took those individuals and I moved them down into the platform team. And let me tell you a very concrete anecdote. I was working with a large retailer about a year ago, and we were meeting with the change control person.

And when we described what a platform makes available to you, the fact that the platform automates and allows you to automate so many of the things that had previously been done manually. We went down into the weeds. We went through the architecture, explained all the steps, showed him that by having the right platform, it's impossible for some of the things that could have happened before when you were doing deployments directly into infrastructure, that it was impossible to allow those things to happen in this environment.

And in a space of a day, we came up with a plan where what we did was we added just a little bit more into the platform. And the thing that we added into the platform was inserting records into an audit log.

And that individual was able to take the vast majority of the controls that were all approval-based and turn them into audit. And when you go from approval to audit, you move out of that line that blocks things from going into production and you shrink your timeline. Hugely powerful. Thank you.

So approval to audit is one of the things that's one of my best practices that I always talk with folks about. So we move them down into the platform team.

The next one is operations. So this is the DevOps Enterprise Summit. I won't spend a lot of time on this. The notion is that your product teams are not just responsible for development, but they're responsible for the product all the way through production, production support, and so on. So we've had operations get split out, used to be all in infrastructure, often gets split out over these different product teams.

The next one that's really interesting is capacity planning. I was with another large organization earlier this year, in January of this year, where I was talking to them about their capacity planning and their capacity. I was sitting with the infrastructure team, and they actually took out their manual, their IT manual, and they said, "Yep, it says right here that we are responsible for capacity planning."

So that was the infrastructure team was responsible for capacity planning for applications that maybe we didn't even know how they were going to be used.

So what we do, our old capacity planning processes had us trying to predict what our capacity needs were going to be, and we were almost always wrong. We ended up over-provisioning because it would be far worse to under-provision. But if we under-provision, then it was really, really horrible. So we did capacity planning in this very, very brittle way.

What we do now is we split capacity planning out over both of those things. The platform team is responsible for making sure that they have enough capacity at the infrastructure level and doing all of the measuring and metrics and modeling to know that, hey, when I hit 60%, I need to start acquiring additional hardware.

Or if you're up in the cloud, you don't have to worry about hardware. When I get to 80%, I'm actually going to start provisioning more virtual machines, let's say. So they're responsible for doing that metrics and that measurement and that monitoring and making sure that they have sufficient capacity.

The application team is given quotas, so the capacity planning down at the platform team projects an API that includes quotas. The app team is responsible for understanding what their quotas are and doing their own monitoring. And when they get to 60%, they request more quota. It's that request of more quota that's going to impact the capacity planning on the platform team. When they get to 80%, they start scaling their instances. So the capacity planning gets split out over both of those houses.

All right, so then the next thing is, and I'm not going to spend a lot of time on data because, quite frankly, as an industry, we're still sorting this out. Over the last three or four years, we've gotten pretty good at understanding how to split out everything at the application tier. We still have a bit to go on the data side, but that's the particular area that I focus on now.

But what we did there was we took the DBA and we took the data architect, and I'm not necessarily saying that we want to split them. The takeaway that I want you to take on the data right now is that notice that you need to have data concerns over in the application team. You need to have empowerment of the application team to do their own data.

Now, you might have, whether it's a DBA or a different role, you need to have somebody who's part of the platform team who's going to be providing those data solutions. So if you need a key-value store, or you need a document database, or you need relational databases, you need somebody as a part of the platform team who's going to provide those databases as services, as a part of the platform team, so that your app team can do self-service consumption of and programming of those data tiers.

All right. Now, for this one, I'm going to add another role, and that is the business. Everything here has been more technical roles, but I wanted to bring the business in because in order to sort the business analyst, I want to bring somebody along, and that is the product manager.

So I want business analyst and product manager. Business analysts often reported into the enterprise architecture team. I want them to be responsible for the app. So they make great product managers. Business analysts often make great product managers. But I don't want them to only be in IT. I want you to bring somebody that they can pair with from the business so that the business is directly on the team, not sending requirements over the wall to the app team.

All right, we're almost done. Wanted to make a little bit more screen real estate here because now we're going to get to the stage where we're going to add some new houses. We're going to add one new house to start.

Now, the first thing here is that I'm going to work a little bit on enterprise architecture. I'm sorry, enterprise applications. So I'm going to work on the red bubble on the right-hand side.

Now, some people often ask, this is a shout-out to where I came from, which is I came to Pivotal from EMC. I came to EMC from Documentum, got to Documentum from eRoom. Anybody know eRoom? Hey. Yay, there's always a few. That's awesome.

So enterprise applications such as Documentum, content management system. It could be PeopleSoft. It could be SAP. It could be any of those things. We've got enterprise applications, or even mainframes. So I'm building new apps, but I have to interface with those applications at the back end, those enterprise applications.

So the first thing that I want to say is you've got another product team here. Now, all of these product teams that I'm talking about, I've been talking about them kind of in this new fancy world. This is not typical for us to have. This is a little bit more typical of the, "Oh, well, we have the Documentum team, and they don't treat it like a product," and all of that stuff.

So the first bit of advice that I would give you here is I challenge you to start structuring your team that's responsible for the enterprise applications in a manner that it really mirrors what we're talking about here. Last year at the DevOps Enterprise Summit, there was a talk on the main stage about doing some of this on the mainframe itself. So you can apply some of these principles and these practices and processes to enterprise applications.

But there's a little bit more that I want to do, and I'm going to move the enterprise architecture team up there for a moment. And that is we're going to put a layer over the top of those enterprise applications.

Now, what's new about that? We've been talking about putting a services tier over the top of these enterprise applications for at least 10 to 15 years. And we've started to build out those services, initially SOAP services, right, and then RESTful web services.

But here's the thing that I want you to look at. This is a product team like any other product team. They're empowered to build out and surface the API that they need surfaced so that the other teams can build it.

Now, what's important here is that I don't want you to think of this legacy services team as just building a pass-through API where they take in a request and they turn around and they make the request to the back end. Because these folks here, because it's a monolith, are going to be revving their system at this pace, and those teams over there that need something from them are going to be revving at this pace.

So this team is also responsible for creating a layer that takes care of that temporal mismatch, so that when they need something from these folks over here and they can't get to it for six months, inside of here, you perhaps build a stopgap. You build an algorithm that is going to estimate some values, or maybe you create some type of a batch-loading process with a cache inside of here. So that's the business. It's not just the business of a pass-through API.

All right. My final roles and my final house. So we now have four houses. We've kind of got this enterprise application house, and that is what I'm calling the enablement team. And the last things that I'll say about here are enterprise architecture is often seen in a large organization as a policing function. We know best, and we're going to make sure that you all do what you should be doing.

I challenge you. This is very much cultural, and I've been with customers now over the last three years where we've seen this culture change happen, and even the enterprise architects embrace it. And that is you shift from a policing mindset to an enablement mindset. It's about running those workshops. It's about being out there and helping empower people rather than policing people.

And that's the final thing. And also, you'll notice that I shifted project management over to portfolio management. And that was my last slide on that. Let the wizarding begin.

Thank you very much.