Charting a Course for the Enterprise

Exploring DevOps: Charting a Course for the Enterprise A Three-Part eBook by Sacha Labourey and Nigel Willie

Charting A Course For Enterprise DevOps Leading DevOps experts Sacha Labourey and Nigel Willie take an in-depth look at the DevOps of yesteryear, and the ongoing steps needed to navigate the world of DevOps today and, ultimately, build an innovative and collaborative DevOps environment. 1. Enterprise DevOps: 2. Enterprise DevOps: 3. Enterprise DevOps: An Introduction Understand Your DevOps Context is King Starting Point Before charting your DevOps journey, it is imperative to be Given an inherited technology Technologists often understand aware of why previous ways estate, along with embedded the technical landscape of working were abandoned. process and practices, it is they work in but in today’s Let’s ensure those challenges sometimes difficult to know environment, it is critical that are mitigated as the DevOps where to start. Creating a the technologist understand program gears up. capability matrix and defining their product from a business your current technology stack perspective to showcase value. can serve as a foundation. 1.

1. Enterprise DevOps: An Introduction If you are reading this ebook, we can assume that you are deliver discrete technical artifacts rapidly to production to interested in the process required to roll out a DevOps drive value to your business. initiative across an enterprise. If that is the case, we’ll also assume that you wish to successfully embed DevOps into Nigel Willie, an expert DevOps practitioner, will now wind the DNA of your enterprise and drive a transformation in the clock back over twenty years to his early days in the software delivery. In our view, companies who have made industry: a success of DevOps have recognized it involves cultural change across the organization and not merely the latest in “WhenIstartedwork,therewasasmallteamofussitting a line of initiatives driven from Head Office. together around a bank of desks. We had someone who represented the business, somebody who wrote the screens That said, your management will have objectives and a (albeitold3270greenscreensforbranchstaff),adeveloper, reward structure in place and it is critical you understand anindividualwhowrotethefunctionalspecifications, this if you are to be successful. You could consider someonewhowrotethetechnicaldesignspecificationsand delivering any transformational program as being similar atester.Theindividualwritingthescreenswouldaskthe to sailing into the wind. You can’t head straight to your businessrepresentativetowanderaroundthedeskandcheck destination but must tack. You need to know your ultimate if the green screen looked how they wanted it to look. destination, but you also need to know that which needs to be delivered for your key stakeholders — which may not “B efore any of us knew the correct taxonomy, we exhibited strictly be strategic. severalofthecharacteristicsofAgileandDevOps,albeitwith We should also state that we have a very simple personal noneoftheautomation.Inaddition,theassetswedelivered definition of DevOps and it is focused on outcomes, not were more monolithic and the cadence was far lower than capabilities. Successful DevOps provides the ability to would be acceptable today.” 2.

“Those who don’t know history are doomed to repeat it.” – Edmund Burke So, what happened? Why care about history? Before any transformation Business engagement (or lack thereof): A colleague once said to It is our belief that anybody commencing a DevOps initiative within your organization begins, me, “First the business moved us into the basement, then into should be aware of why similar ways of working previously were we recommend that you: another building, then another city and finally another continent.” abandoned and take steps to ensure those challenges are In many companies, IT lost contact with our business and became recognized and mitigated against as the DevOps program gears • Understand what outcomes a cost center that delivered solutions rather than being a close up. It is imperative that the business is fully engaged and you are trying to achieve. partner. It is critical that those of us in technology become better committed as key stakeholders in the value that can be gained at communicating with our business and understand what the from DevOps. You need to avoid the view of IT being a cost • Understand what objectives asset we are accountable for does in their eyes. I see far too and ensure that you can clearly articulate value. Ideally, your your board has, and identify many technologists with little business contextual awareness. business should start to articulate the value they see from which short-term objectives DevOps to others. add risk to the long-term Silo-ization: Within larger enterprises, there was a move to strategy. monoskilled pools. A large pool of developers, a pool of testers, Additionally, if your company previously moved into silos, an a pool of business analysts, a pool of DBA’s and so forth. This awareness of the rationale behind this is crucial. For example, • Understand why your moved us away from a product to project approach, with a pool look to put a process in place to identify when business demand company looks like it does of labor brought together for a specific task. I lived through this for product enhancements starts to increase or decrease to now, how you got here and process and know that it was driven by IT itself, or at least by ensure you avoid the perception that resources are not being what motivators led to the CFO’s within the IT part of the organization. The rationale came optimized. current culture and from the idea that product teams sometimes had downtime environment. when demand for new features was not pressing. By creating NEXT: Understand Your DevOps Starting Point >> pools of labor, the IT organization could react more rapidly to business priorities. 3.

2. Enterprise DevOps: I Wouldn’t Start from Here — Understand Your DevOps Starting Point There is an old joke in the UK about a couple of city dwellers providing thoughts and experiences on potential approaches driving through the countryside and becoming lost. After to identifying an automation foundation that enables DevOps several minutes driving around, they see a local farmer. in a large, established organization. Drawing next to him they wind down the car window. Create a standard taxonomy “Excuse me, could you tell us the best way to get to the of capability nearest town?” The farmer looks at them, nods, pauses and says: “Well if I wanted to go to town I wouldn’t start In large organizations, one of the key challenges is to ensure from here.” that a standard taxonomy is used. This assists in optimizing knowledge sharing and understanding the available solutions If you are introducing DevOps across a large enterprise you and experience in the enterprise. The enterprise architect will probably have a lot of empathy for the farmer’s view. function should own the Enterprise Information Management Given an inherited technology estate, along with embedded (EIM) solution and it makes sense for this to detail the standard process and practices, it is sometimes difficult to know capabilities you are looking to deliver. where to start. You are also likely to inherit at least some vociferous individuals advising why current practices have Defining these capabilities is critical. Technologists, as a rule, to remain as they are. are better at defining solutions than requirements. By focusing on capabilities rather than solutions (or tool We shall start by stating that it is a given that DevOps names) you drive a higher quality of debate. It is also adoption revolves around creating a culture that provides easier to identify gaps. In a cross-technology organization, it support for autonomy and removes centralized command can highlight surprising areas of strength. For example, the control behaviors. It is not delivering a raft of tools. That mainframe platform tends to have strong automated said, there is plenty of excellent content that details the deployment capabilities which are often missed when concepts and behaviors required. We are not going to continuous integration and automated testing is discussed. attempt to replicate that. Rather, we shall concentrate on 4.

Create a resource page where your capabilities, tools and Define your current technology stack information are readily available. The next step after defining your capability matrix is to detail within the organization. Finally, we should consider the gray This could include: the current solution(s) in each capability space. If you are market in technology. People across the organization are likely to • Capabilities fortunate, you will have an EIM solution that is comprehensive, be using solutions to problems which are not officially recognized • Solutions available for the current and already has all this information. It is more likely that or documented in the EIM. There may be solutions already in the capabilities your records will be, at best, partial. In the first instance, focus organization that will add great value at larger scale. Conversely, • Precis of each solution on placing the current technologies in the correct categories potential solutions may have already been tried and issues • How to obtain access to the rather than defining which solutions are valid and which are not identified. A culture that encourages communication and sharing available solutions strategic. If you can achieve a first pass quickly, this can start of experience and information will enable you to deliver more • Links to any training material to drive discussions and decisions. Stakeholder communication quickly and avoid replication of effort. Enabling others to feel they • Links to vendor pages is also critical. While not normally a fan of duplication, you can safely share information without repercussions is key. There • Links to social media content need to detail the solutions available to your engineers. Most is obviously a balancing act between encouraging innovation and (Stack Overflow, internal blogs EIM solutions are great as repositories but are not intended as avoiding an uncontrolled proliferation of technology. and forums, etc.) communication media. We recommend an approach that enables your community to understand the options available to them NEXT: Context is King >> 5.

3. Enterprise DevOps: Context is King Nigel was manning a booth at an internal DevOps it is very easy, and dangerous, for DevOps adoption to conference, and this conversation transpired: become synonymous with the rollout of automation via a set of tools. Automation is key, but it’s certainly not NIGEL: the sole task and a monomaniacal focus on tool adoption “So, how can I help you?” introduces many risks. TECHNOLOGIST: “I need all the DevOps tools.” One of the key aims of DevOps is the delivery of NIGEL: consumable content to the business more rapidly. As “Why do you need all the tools?” such, the product backlog will be more dynamic and TECHNOLOGIST: the need to be in communication with the business is “My manager has put it in our objectives to adopt increased. It is critical that the technologist understands all the DevOps tools by the end of this quarter.” their product from a business perspective as that will drive value from your investment. Nigel knew he had a communications issue; whenever targeting a mass market, his message needed to be One of the key concepts that can be used when talking simple. He also knew he had an issue about nuance to technicians is the Gartner Pace Layer principle. This and context. is not new or radical, but we believe it is very useful as a means of introducing context into discussions. We now have two issues that need to be addressed. In this section, we’ll concentrate on the criticality of contextual knowledge. In a technology company 6.

In our experience, technologists often understand the technical landscape enabler. You provide capabilities and make it as easy as possible for these to be they work within (and often are very keen to innovate) but are less confident adopted. DevOps and Agile is all about personal empowerment and with that about the business value of the product they own. At the trade fair, Nigel talked comes accountability. One of the key accountabilities of the technologists is to through the three systems the Gartner Pace Layer diagram highlights, after seeing understand the business context within which they work. It is critical that this is previous versions of the diagram (Figure 1) several years back. He then asked the communicated clearly with appropriate guidance to ensure that investment value individual where they saw their product (or aspects of their product) as sitting is maximized. within the three system types defined. From this, he then moved to a discussion of the areas of automation that would drive the most value for their business. For example, nobody in the business is going to be delighted if we start innovating around a regulatory reporting product. These are hygiene systems that require accuracy and resilience. There are still capabilities in the DevOps tooling chain such as automated testing, a focus on regression validation, etc. that increase confidence and add value. If you understand the context you are working in, you can make more informed decisions on your priorities. It is a given that there are interdependencies between different products within the enterprise portfolio. A technologist also needs to understand which other products have a dependence on their product and then use good architectural practices (API’s, microservices) to ensure that their product does not become an impediment to the cadence of change of others. In short, within a large organization we see the role of any central function as being an Figure 1: GartnerPaceLayerDiagramforDevOps 7.

Charting Your Course for Enterprise DevOps? Get Started with CloudBees Core If you are considering building a foundation for DevOps success, CloudBees® can help. We offer the ultimate continuous delivery solution architected for the enterprise. Teams using CloudBees deliver software 6x faster, on average — as fast as you can think it, you can build it, test it and deploy it. With CloudBees, you’ll get: On-Demand Capacity: Empower teams to focus on delivering value, not maintaining Jenkins®. On-demand provisioning enables teams to start new projects in minutes. With CloudBees, teams go faster…together! Centralized Management: Simplify your life with streamlined management of your Jenkins servers. Spin up new resources with ease. Upgrade instances once and copy configuration changes everywhere. Deploy Anywhere: CloudBees Core is made to install and run in a variety of environments. Deploy on Amazon Virtual Private Cloud™, a private cloud with vSphere®, Red Hat OpenShift Container Platform or on your own servers. Built-In High Availability: CloudBees Core ensures high availability with self-healing Jenkins infrastructure. Should a system interruption occur, resources automatically recover and your continuous delivery pipelines automatically restart, preventing costly downtime. Security and Compliance: CloudBees ensures everyone is on the same version, eliminating conflicts. You define access via roles and responsibility. Compliance just got a whole lot easier! Unify Your Toolchain: Frustrated by each team using their own tools? Unify your toolchain with CloudBees and reap the rewards of standardization. Provide a single, unified Jenkins experience to all teams. Start Your Free CloudBees Core Trial Today: www.cloudbees.com/get-started 8.

Enterprise DevOps: About the Authors Sacha Labourey Nigel Willie Sacha is a native of Switzerland and graduated in 1999 With over 20 years’ experience working in IT for one of the from EPFL. While at EPFL, he started his first consulting world’s largest financial institutions, Nigel has experience business — Cogito Informatique. In 2001, he joined managing and delivering global transformation programs. Marc Fleury’s JBoss project as a core contributor and Starting his career as a developer, Nigel’s most recent role implemented JBoss’ original clustering features. Sacha was to deliver cross-platform DevOps automation went on to become GM for JBoss Europe, leading the capabilities to the enterprise. strategy and helping to recruit the partners that fueled the company’s growth in the region. In 2005, he was appointed From his experience, he understands many of the challenges CTO, overseeing all of JBoss engineering. and mistakes involved in a DevOps transformation; indeed, he claims to have made most of the mistakes himself. Nigel In June 2006, JBoss was acquired by Red Hat has also had the good fortune to work with a lot of highly (NYSE:RHT). As CTO, Sacha played a crucial role in skilled individuals, both as colleagues and across the integrating and productizing the JBoss software with Red industry. Nigel is a great believer that every initiative is Hat offerings. In 2007, Sacha became co-General Manager individual and any observations he makes are intended as of Red Hat’s middleware division. He left Red Hat in 2009 principles or guidelines, not rules. and founded CloudBees in March 2010. Follow Sacha on Twitter. For more DevOps insights from Sacha and Nigel, www.cloudbees.com/blog 9.

About CloudBees is powering the continuous economy by building the world’s first end-to-end system for automating software delivery, the CloudBees Suite. The CloudBees Suite builds on emerging DevOps practices and continuous integration (CI) and continuous delivery (CD) automation adding a layer of governance, visibility and insights necessary to achieve optimum efficiency and control new risks. As every company in the world is now a software company, this new automated software delivery system will become the most mission-critical business system in the modern enterprise. As today’s clear leader in continuous CI/CD, CloudBees is uniquely positioned to define and lead the automated software delivery category. CloudBees puts companies on the fastest path to transforming great ideas into great software and returning value to the business more quickly. Backed by Matrix Partners, Lightspeed Venture Partners, Verizon Ventures, Golub Capital and Delta-v Capital, CloudBees was founded in 2010 by former JBoss CTO Sacha Labourey and an elite team of continuous integration, continuous delivery and DevOps professionals. Follow CloudBees on Twitter, Facebook, LinkedIn and Google+. ® The registered trademark Jenkins is used pursuant to a sublicense from the Jenkins project and Software in the Public Interest, Inc. Read more at: www.cloudbees.com/jenkins/about © 2018 CloudBees, Inc. CloudBees and CloudBees DevOptics are registered trademarks and CloudBees Core, CloudBees Jenkins Enterprise, CloudBees Jenkins Platform and DEV@cloud are trademarks of CloudBees. Other product or brand names may be trademarks or registered trademarks of their respective holders. 0618v00