Dave Swersky

My name's Dave Swersky. I'm an enterprise architect with PNC Financial Services, based in Pittsburgh.

A few little factoids about PNC: we've got roots in the Pittsburgh area tracing back to the mid-19th century. We're now the sixth-largest bank in the U.S. We have about 2,700 branches in 19 states, and we offer a wide range of financial services, including wealth management, corporate and institutional banking, and mortgage lending, in addition to our retail operations.

I've worked in EA at PNC for about six years, and most recently, I joined a new team focused on enterprise development standards. One of the missions of that team is to investigate and adapt DevOps practices.

Today, I'd like to talk to you about DevOps from the center out. As thought leaders responsible for discovery and implementation of new methods, we're in the center of a group of collaborators: development, executive management, management, IT operations, project management, and more. Each has a unique perspective and a role to play in any significant transformation.

DevOps is, at its core, a cultural perspective that impacts each one of these roles. So DevOps can and should be different things to different people. Each one of these roles is focused on different aspects of a given enterprise.

In this presentation, I'll start with a little background of what I've learned so far in my research on DevOps, and I'll talk about the best resources I've discovered to follow its development. I'll then talk about how to target the communications of the core concepts and theories to each stakeholder, from management to dev to ops and everything in between, individually first, and then together.

I'd like to start with my journey so far in learning DevOps. In early April this year, I joined that new team focused on enterprise development standards. In discussions with my new manager, we talked about DevOps and how it might apply to PNC. He tasked me to learn about DevOps, take the lessons back so we can evaluate it, pick it apart, and figure out how to apply it to our software delivery. Kind of a "tag, you're it" scenario.

As it happened, a week later, I was here in San Francisco at the ServiceNow conference, and looking at the sessions available, there was Gene Kim's session on DevOps. So I attended the session and, of course, I was absolutely fascinated. This was my first significant introduction to DevOps.

After the session, Gene handed out copies of The Phoenix Project, and I went and got my copy and chatted with him for a minute and went off to read a few chapters. About six hours and a few missed sessions later, I had read the entire book. I couldn't put it down.

Hungry to learn more, I read as much as I could find for the next month. Then in late May, I attended DevOpsDays Pittsburgh. The sessions there were illuminating, but I actually learned more about the state of DevOps from the attendees themselves.

DevOpsDays has focus sessions and then open sessions that attendees can propose and facilitate. I proposed a session on DevOps tooling, which attracted about 10 or 15 people. During the discussion, the topic came up of how we all came to be at that conference, and without exception, every single other person in the room said, "I'm here because my manager told me to come figure out what this DevOps stuff is."

I was surprised. I thought that DevOps was more widely known. Having read The Phoenix Project, and with about a month of research under my belt, I was the expert in the room.

Since then, I've attended another DevOps conference, and I've read a bunch more information. I've read Goldratt's The Goal, which was the inspiration for The Phoenix Project, and I've also conducted some informal surveys with current and former colleagues across all kinds of different roles: dev, management, ops, MIS, you name it, architecture. On a self-ranking of zero to four for DevOps knowledge, the average was less than one.

Pretty much everyone I talked to up to that point had never heard of DevOps. I actually had one guy nail it so well over IM, I think he may have looked it up.

DevOps is barely five years old, if you start with the first DevOpsDays in Europe in 2009. Looking at the literature, I've discovered another interesting statistic. Here are the number of books on Agile and ITIL on the subscription site Books24x7, and here's the same search on Amazon. As you can see, there are many hundreds of books available on each subject.

Here are the same results for DevOps: a whopping 116 on Amazon. To put this in perspective, the Agile development movement is almost 15 years old. Amazon lists 85 books published prior to January 2003. This tells you where we are in the DevOps story: barely out of the prologue. If DevOps were a flight from New York to LA, the wheels just came up, but the seatbelt light is still on.

I'm sure that many, if not most, of the attendees here today have been doing DevOps to some extent for some time, probably even before it was called DevOps. The last six months of research have shown me that we here are in the minority. There are relatively few in the IT industry as a whole who understand what DevOps is and what it's designed to do.

If you're working in an organization that has decided to implement DevOps, you work surrounded by people who are engaged with it day to day. For those who are engaged with it at that level, it may come as something of a surprise that in the broader IT community, DevOps is new to many and perhaps unknown to most.

That's the perspective I'd like to offer today, as one who's tasked with evaluating and then introducing DevOps to a diverse group of stakeholders who have little, if any, prior knowledge.

The DevOps challenge: learn these new concepts, take the lessons learned back to your enterprise, and communicate them to an audience that is likely to be completely new to DevOps. This is no small task, especially in a large, diverse enterprise.

Large companies, especially ones in regulated industries, tend to be risk-averse in the face of change. So if the small, nimble startups are unicorns, and the large companies are horses, the regulated industries are elephants. Of course, we wouldn't be here at the DevOps Enterprise Summit if we thought that being large or regulated precludes DevOps adoption. It does, however, present some unique challenges.

Like Agile, DevOps isn't a hard skill like Java or test-driven development. It's a set of values that, when adopted, influence the culture of an organization. These soft concepts can be difficult to convey in a business setting. It's important to distill the communication by focusing it on concrete ideas and concepts that are relevant to your stakeholders. I tend to think of it like sculpture: remove the parts that aren't DevOps to reveal the shape underneath.

To that end, let's first talk about what you shouldn't do to try to implement DevOps.

First, you can't buy DevOps. There are tools that support continuous delivery, continuous integration, and automation workflows from the developer's desktop all the way to production. DevOps would certainly be difficult to support without these tools and the skill sets needed to use them. However, buying the tools and hiring the skills alone isn't enough.

Speaking of hiring, you can't hire DevOps. There are postings online for DevOps engineer and DevOps developer. I think this represents a fundamental misunderstanding of DevOps. DevOps isn't a person, a team, or a role. It's a way of working across each existing role. Hiring a handful of people, even if they've worked in a DevOps-oriented environment before, won't do the trick. Those skills and experience do have value, but they're only the raw materials.

And finally, you can't dictate culture. DevOps is, at its heart, a cultural movement. You can't declare, "We're DevOps now," drop the mic, and walk away. Cultural change is fundamental change. It requires time and understanding of your resources, both people and tools, and a willingness to engage across the entire enterprise, top to bottom. Cultural change can be directed and fully influenced, not installed or imposed.

Now that I've regaled you with all the things you can't do to implement DevOps, let's talk about what you can and should do.

First, you can learn about DevOps, which is why we're all here today. There are important, fascinating, tangible things to learn that are unique to DevOps. This early in its development, there are plenty of opportunities to join in and influence the direction.

You can take the lessons you learn back to your enterprise and share them with your teams. Adapting DevOps to your process is just that: adaptation. DevOps isn't a strict, dogmatic system that has to be implemented precisely to be effective. If you're familiar with Agile, you've probably heard of the difference between doing Agile and being Agile.

Doing Agile is blindly following a prescribed set of rules and processes. Being Agile is recognizing that, by its very definition, agility is adaptation. There is no single right way to do Agile. There's the way that works for your teams to deliver software. This applies equally well to DevOps.

I'd like to point out that I'm deliberately avoiding the term teaching as it relates to DevOps. Teaching DevOps implies that there's some structured curriculum out there that you can learn and then deliver. To my knowledge, there's no such curriculum. I think it's better, then, to say that we're all learning the principles that support DevOps and sharing those lessons.

The learning doesn't stop there. When you go to start a DevOps implementation, you're learning the most important lesson, which is how it works in practice at your organization.

And finally, you can grow DevOps culture by working with your stakeholders to determine how DevOps can be applied to your organization. When I met Kevin Behr at DevOpsDays Pittsburgh, he told me, "The DevOps you bake yourself is going to taste far better than the DevOps someone else bakes for you."

This is exactly why we don't want to try to buy, hire, or impose DevOps. DevOps is a set of values and culture that you grow within your enterprise. I picked a bonsai tree here to represent that idea because they take years to cultivate, but the result is well worth the effort.

First I'll talk about some of the lessons I learned about DevOps itself, and then I'll share some of the resources I used to follow DevOps as a practice.

When learning a hard skill like Java or test-driven development or design patterns, resources are plentiful and well-defined. The goals associated with this type of learning are also easy to identify and communicate. "I want to write a client-server application in Java" is a clear goal that you can define and communicate, and then when you've succeeded, you can demonstrate your results to your friends and colleagues.

DevOps isn't so cut and dried. Even by comparison with Agile, which is also focused on soft skills such as communication, DevOps can be difficult to pin down. There is no Galactic DevOps Consortium to tell us what is and is not DevOps. There are no consultants that can draw a sharp line for us between how to do and not do DevOps.

DevOps is a set of values and culture. I think of DevOps as an operational philosophy. Philosophy is defined as the most basic beliefs, concepts, and attitudes of an individual or group. Philosophy goes deeper than methodology. Methodology is the how. Philosophy gets into the why of decision-making in an organization.

DevOps informs the way an enterprise communicates and thinks about software delivery, values time and resources, and measures success. There's a tendency for businesses to view their IT departments as a black box. Money and requirements go in one end and software comes out the other. DevOps takes that entire notion and turns it on its head, representing IT as an integrated value stream that is partnered with the business and exists to further business goals. This is a fundamental shift in thinking for many large organizations.

Here we have a representation of the software delivery cycle, and IT in general represented as a value stream that is broken down into discrete, connected stages. It's this perspective that's unique to DevOps.

DevOps shares many essential values with Agile and is in some ways the logical extension of Agile values outside software development. However, Agile is primarily concerned with the activity within the development stage. DevOps takes and integrates the whole system from the business objectives through development and back through continuous improvement.

Let's talk about the resources I've used so far to learn about DevOps. The most important single resource for me, I have to say, was The Phoenix Project, followed closely by Goldratt's The Goal. The Phoenix Project does an excellent job of concentrating the concepts and ideas of DevOps into a single resource and delivers it in a highly consumable, relatable narrative. I consider it required reading for anyone wanting to dive into DevOps in a meaningful way.

Conferences like this one are also high value. DevOpsDays was the conference that started the global conversation about DevOps. Those conferences are happening in cities all over the world. There and here, you can get concentrated, focused discussion on DevOps and talk to other practitioners about their wins and struggles.

At this point in the DevOps story, with relatively few publications available, social media plays a critically important role. Many good books start as blogs, and blogs are currently a great resource for learning how DevOps is practiced all around the world. Twitter, Reddit, and believe it or not, LinkedIn are actually really great resources. The LinkedIn DevOps group has led me to many excellent blogs and posts.

You may be sensing a common theme here. These are all interactive. Even The Phoenix Project, a physical book, has had revisions based on input from the community. Tim Hunter reinterpreted the Three Ways described in The Phoenix Project and sent his interpretation to Gene. Gene loved it so much he reblogged it and is including it in future printings.

This illustrates an important point about the development of DevOps. In the absence of the Galactic Consortium, it's the IT community that is running the development of DevOps through the ongoing conversation online, in media, and in publications.

How do you get DevOps started at your company? First, start the DevOps conversation with your colleagues. Get your people thinking about the goals DevOps is designed to achieve, share with them examples for achieving those goals, and then work together to adapt those methods to your unique challenges.

If DevOps is an operational philosophy which gets to the why of our decision-making, we could probably agree that it's worthwhile to discuss the philosophy of software development. The trouble is, if you send a meeting invite titled "Philosophical Discussion of Software Development," you're probably not going to get very good attendance.

We have to recognize the nature of the change, which is philosophical and cultural, that we're trying to influence, while also adapting to the language spoken in our organizations.

How do we translate these abstract ideas into something concrete, actionable, deliverable, and generally buzzword-compatible? Value propositions. Value proposition is a bit buzzwordy, but it's useful because it's a common term that everyone understands, and it's a why term. If I'm going to spend time, money, and resources on something, I need to know why.

What are the value propositions of DevOps, and who among your stakeholders will be most interested in each?

Sorry, I'm having a little trouble here. There we go.

Here we have the Three Ways related to both the theoretical basis for them and the value propositions that they offer.

Why is flow important in a business setting, as opposed to yoga? The theory of constraints, as stated in Goldratt's The Goal, tells us why. Passing defects down the line causes unplanned work, which is wasteful and prevents effective demand management. Low touch time and high wait time means the components of your system spend too much time idle, which leads to wasted time, lower productivity, and clogged backlogs, or inventory in Lean terms. These are the clear, hard value propositions that are easy to explain.

Why is feedback important? Separate groups that don't communicate cannot hope to improve a process they only see from inside their silo. Feedback provides the transparency between each step along the value stream and ultimately back to the originators of the IT request, which is the business. Successful businesses must constantly adapt to internal and outside change. Feedback provides the business the telemetry it needs to know which way to turn. The value proposition of feedback is improved change management, not only within IT, but also all the way back through the value stream to the business processes that IT supports.

Why is continuous experimentation and learning, I'll call it CEL, important? CEL reminds me of Stephen Covey's "sharpening the saw" applied to business. It's the green veggies, standing desks, and daily reflection that differentiates average from exceptional.

In practical terms, IT teams typically compose solutions from vendor products. This is a smart way to build solutions. However, by definition, these systems are commodities. Anyone can buy a vendor product. The differentiator comes from the practice you cultivate in supporting and developing those systems.

Given the freedom to conduct scientific experiments, which by the way means failing sometimes, IT teams have the space to innovate within their own domains and discover new delivery methods that work better. Process improvement by itself isn't enough to adapt to change. The processes themselves should be questioned regularly to determine if they're even relevant or necessary.

Albert Einstein said, "We can't solve problems by using the same kind of thinking we used when we created them." The benefit and value proposition of CEL is confidence and a proven track record. When a customer or a regulator comes asking if you can deliver, you're not smiling with your fingers crossed behind your back. You know the performance characteristics of your services. Your battle-tested systems and processes have been delivering under pressure before they ever hit production. At the highest level of, we'll call it DevOps maturity, that testing extends into production. All hail the Chaos Monkey, right?

Implementing DevOps does not guarantee any or all of these benefits. Each company must decide how to pick and prioritize the value propositions offered by DevOps and customize their implementation and practice accordingly.

Now we can talk about communication, who cares about what, and how to deliver a DevOps introduction that will start the DevOps conversation between all the stakeholders at your company. The idea here is to explain DevOps from a what-can-DevOps-do-for-me perspective. This isn't a sales pitch, and the idea is not necessarily to convince anyone of the values and virtues of DevOps itself. The first step here is to just draw a line around the value propositions offered by DevOps.

Executive management is going to want to know first, as it must, how much. Cost benefit is the way we evaluate the cost against the return. DevOps is a long play, so the overall cost is almost impossible to measure up front. Capital expenditures won't be clear until the DevOps conversation progresses to the solution stage.

DevOps introductions should then focus on the cost of doing nothing versus the cost of change. Step one: understand what DevOps can offer. Step two: decide whether your organization is ready to make that transformation. If nothing else, having the conversation has value. It may raise alternatives to a full-blown DevOps implementation, or it may lead to a long-term roadmap to DevOps.

The executive summary should focus on the theoretical underpinnings of DevOps, its Lean heritage, the modeling of the IT organization as a value stream, and what that implies about how to structure the overall operations within IT, and between development and IT operations. You'll want to discuss the theory of constraints and how it applies to an organization in practical terms.

Innovation is another good topic to discuss at the executive level. The true source of innovation at companies that don't profit directly from running software is the business, not the IT department. The business innovates in the delivery of products and services. The IT department innovates in delivering software that supports the business.

When delivery velocity increases and releases are small and frequent, there's less friction in the delivery cycle. Less friction and higher throughput gives the business the freedom it needs to experiment with new ideas at lower cost and risk.

The dev and ops introduction should start with the fundamental idea that dev and ops should not work separately. They're two parts of the same mission, so they should work together at almost every stage of the development, release, and support.

Developers and ops teams will be most interested in the effect that DevOps would have on their daily lives. You'll want to talk about the practical effects of DevOps on tooling and lifecycle management. You have one major advantage here: these problems aren't new to these teams. You probably won't have to convince them that passing defects down the line or making direct changes to production are bad ideas. They may struggle, however, with the idea that these problems can be resolved.

Project management also has a role to play. Project managers and business analysts are in a unique position to help with continuous improvement. Project management can facilitate discussions about the business and delivery processes as they execute. It can then provide feedback between dev and ops teams and back to management about opportunities for process improvement. This feedback can then drive business change management at the business process level and IT change management at the delivery and application levels. The project management introduction to DevOps should focus on the feedback and CEL aspects of the second and third ways.

There are a few common aspects and threads to weave into all introductions. DevOps is designed to solve problems. It's a set of values that, when applied to those problems, suggest a set of solutions. It doesn't prescribe any particular solution for any one of these goals.

For example, if we can agree that passing defects down the line is bad, that's our touchstone. As a company, how we prevent that from happening is entirely up to us. This perspective will help prevent debates over pure DevOps. There is no pure DevOps. There are the values we hold and the solutions we find to adhere to them, and each company can and should determine those solutions for themselves. This process doesn't have to happen in a vacuum, however, which is why we're all here today. We have a lot to learn from each other about the solutions we discover.

Here we can start what I call the DevOps conversation. This is an extension of the global, online, interactive DevOps conversation into your company.

Before starting the broader conversation, do your targeted DevOps introductions by role. A good way to manage those introductions at large companies is to break out a working group across those roles. The working group should be a representative cross-section of executive leadership, management, IT ops, development, and project management, as well as the ones that you define.

Like an organizational core sample, you'll want experienced people from each group who are well respected within their areas. They'll need to be able to contribute to the discussion from their perspectives and listen to the others' perspectives as well.

Introduce the concept separately by role, and then bring the working group together to discuss the big picture of what DevOps would mean to your company. If possible, use an open forum format to get input from each perspective with a general agenda to move the discussion forward.

The mission of the working group is to develop a consensus on DevOps strategy and answer key questions. Do we agree on a version of DevOps that works for us? Are we ready for DevOps? If not, what will it take to get there? Where should we start with our DevOps transformation?

The working group should ideally produce a document of understanding detailing these conclusions. This document can form the foundation of a DevOps implementation strategy.

DevOps should be discussed as a framework of goals and means. As the saying goes, a little bit of knowledge can be a dangerous thing. As your coworkers begin to absorb information about DevOps, they'll begin to form impressions about it. And there are a lot of myths and misunderstandings out there in those online resources. This can lead to what I call distractors: fodder for arguments about the how that distract from the fundamental values.

Here are a few of the most common.

First one: we already use ITIL, or Agile, or what have you. DevOps doesn't conflict with any of these existing methods. In fact, there's great guidance available on how to combine DevOps with all sorts of different methods and practices, such as ITIL, Agile, CMMI, Six Sigma, and many others. The flexibility of DevOps offers countless ways to adapt its general principles to these more prescriptive practices.

Next: we don't have the time or money or resources to cross-train. If that's true, then don't. DevOps isn't about doing different work. It's about working differently. Much of the discussion about DevOps online focuses on cross-training between dev and ops. There is certainly good evidence that cross-training has value and that it encourages collaboration, but how you achieve that collaboration is up to you.

Cross-training doesn't have to mean a six- or seven-figure program budget to teach your ops people Java. It can be job shadowing. It can and should be cross-team meetings. The dev and ops collaboration that's essential to DevOps must be done, but it can take many forms.

Next: we can't staff people around our Brent. The Phoenix Project uses a character named Brent to illustrate the hero culture suffered by many companies. Brent is the one guy who understands how the systems all work, patched together with long hours and spaghetti code. In the book, the solution to that problem is to form a team around Brent, freeing him to do the most important work. This is the constraint protection from the theory of constraints.

Staffing a team around Brent is one solution among many. Resource constraints can result from budget pressure, hiring limitations, or any number of other issues. The constraints must be protected. If your most important resources are too busy fighting fires to do the real work, the real work doesn't get done. How you protect those constraints is your special sauce. This is where the creativity of your team comes to bear in finding a solution that works uniquely for your organization.

And finally: we can't, don't want, or need to do 10 deploys a day. This is easily the most important distractor. The idea of doing 10 production deploys a day is enough to raise hives on any horse, to say nothing of the elephants.

Here's a perspective. Each one of us has one of these, a cell phone. I remember the first time I saw a camera built into one of these. My first reaction at the time was, "What is that good for? How is that useful?" Instagram and Pinterest and Snapchat and Facebook and citizen journalism all show us why a camera on a phone makes all the sense in the world. It doesn't take long to get it once you get your hands on it.

I think deployment velocity works the same way. Until you have it, it's hard to understand why it's of any value. Once you do have it, you won't know how you lived without it.

Should we roll out DevOps on faith and hope for the best? No, of course not. Once again, let's interpret and adapt. How about this: does deployment have to mean production deployment? Are your UAT and QA infrastructures matched to your production environments? I'm betting in many cases they are. Why, then, does deployment have to be to production? If you can accelerate your deployment velocity to UAT, where your customers can evaluate new features on demand, that has value, too.

"Slow down, you're delivering software too fast. We can't keep up," said no business stakeholder ever, right? I'm confident that your business will be thrilled with a backlog of new features to review. In fact, I'd argue that if the business is your new bottleneck, you've won.

If inventory's piling up ahead of UAT because you're delivering new tested features so fast, that's a DevOps success story. With effective release management, you can ramp up velocity to pre-production environments and then spool new features out into production as quickly as your regulatory or your security gates will allow. Your business is now free to dream bigger and take bigger risks with new ideas at lower cost.

This is just one way to adapt the idea of velocity to make it relevant to large organizations.

The outputs of the conversation will set the stage for the implementation strategy. First, what are we trying to achieve? Which are the most important to us, and how do we prioritize them? Gaining consensus on what you want from DevOps is a critical first step, and the next step is assigning stakeholder participation.

There should be a clear understanding of how each role across management, dev and ops, project management, among the others defined by you, participate in a transformation.

Some months after the initial transformation, you're all going to want to know what happened. Did we achieve the goals we set out to achieve? How well did we do? This demonstrates the critical need for alignment between DevOps, the goals you select as an organization, and the KPIs you use to measure success. A clear introduction to DevOps should lead to the selection of reasonable goals, which can then lead to effective KPIs.

So far, I've talked about what DevOps is, what it isn't, and how I've been listening in on the conversation for a while. Today, I've had a great opportunity to join the conversation and add my voice. My DevOps journey is just getting started, and my next step is to help craft an implementation strategy. After some work and discussion in that direction, I have a few thoughts on my way forward that I think can be applied generally.

As I've said, cultural change is a long play. When thinking about DevOps, ask yourself these questions. Where are we as a company? Are we ready for a shift towards a collaborative, integrated environment within and outside IT? Is there an appetite at all levels, across all roles, for this kind of change? Are we already doing some things in a DevOps way?

We're not looking for a go/no-go, green or red answer here. DevOps transformation will be an evolutionary change at even the most progressive, visionary organizations.

Can you catch up with the slides, please? Oh. You're off by one slide.

Are we off? Yes. There we go.

Great. Thanks.

Where am I?

Okay, and now I'm off here. Sorry.

Okay. As I've said, cultural change is a long play. When thinking about DevOps, ask yourself these questions. We've already done that, haven't we?

We're not looking for a go/no-go, green or red answer. DevOps transformation will be an evolutionary change at even the most progressive, visionary organizations. My advice is not to get caught up in an all-or-nothing mindset. Starting the conversation, regardless of where it leads, has value. DevOps transformation isn't a project; it's a roadmap. If someone says to you, "That'll take years to roll out," I'd say, "Yep, I think we're on the same page."

Finally, Gene asked us to include a slide on topics with which we're struggling and aspects of DevOps where we don't quite know how to proceed. After reflecting on this for some time, I think one of my greatest challenges will be how much is enough to call it DevOps.

Again, until somebody convenes the Galactic DevOps Consortium, we're left to figure out what DevOps means to ourselves, as individuals and as organizations. At this point, I'm not sure how much or what combination of elements will make us a DevOps shop.

In closing, if and when you do start to move in a DevOps direction, keep in mind that DevOps isn't a team. Don't split off a DevOps strike team and set them to work. Encourage and empower the representatives from your working groups to take those lessons and concepts back to their teams.

The deeper the conversation goes within your organization, the better I think your results will be. And finally, be ready to listen a lot to the conversation as it continues. Most importantly, listen carefully to the one that you start at your company. I've already learned so much about my company in a very short time.

These are the most important lessons you'll learn as you follow your DevOps journey. I look forward to hearing your voices in the global DevOps conversation.

Thank you.