The intersection of ITIL and DevOps is an interesting one, and a topic that we have previously discussed. This topic is getting more and more air play as we see enterprises adopting DevOps practices like Continuous Delivery and Infrastructure as Code. After all, ITIL has been around for 25 years, and many enterprise IT organizations have adopted ITSM as their process/best practice backbone for delivering value to the business. But most IT shops are still not satisfied with their performance and are starting to turn to DevOps since it promises more agility and better quality.
How do ITIL and DevOps work together? How does DevOps impact ITIL? How do you implement Continuous Delivery in an ITIL shop? There are many questions that need answers. We’ve asked George Spalding from Pink Elephant to join us at the DevOps Drive-in on July 25th to help provide some answers. ITIL and DevOps – Friend or Foe? Let’s ask George and find out.
DevOpsDays attracts the best and brightest from both development and operations: the ones who want to change how companies deliver software and improve the value delivered to the business. These leaders are challenging the current state of IT, and for good reason. The status quo is lacking in quality and not responsive enough to the business. The DevOps leaders are looking at new ways to change the work culture, the processes that deliver software and the technologies and tools to delivery that competitive edge to the business. Their work is driving a “BIG FAT RETHINK” on the whole traditional “People, Process and Technology” for building and deploying software.
John Willis opened up this year’s DevOpsDays Silicon Valley with a keynote on the “Big Fat Rethink.” He used the latest DevOps survey to point out that IT Performance is a Competitive Advantage, and one of the strongest predicators of IT Performance is an organizational culture that exhibits high trust, cross functional collaboration, shared responsibilities and continuous learning. These are DevOps principles and a big rethink on the traditional waterfall approach with silos of expertise and responsibility. John also discussed the big rethink on “Software as Infrastructure” extending it to the network and the entire data center, proposing a big fat rethink on extending declarative and desired state infrastructure beyond server configs, packaging and VM provisioning. Software Defined Everything, a Consumable Composable Infrastructure that deals with the intra-relationships of components and can be selected and assembled in various combinations to satisfy specific user requirements. Software is powering the world and the DevOps crew gets it!
There was also a “Big Fat Rethink” on the enterprise applicability of DevOps principles and practices. Adam Auerbach of Capital One gave a great presentation entitled, “How Capital One put Quality in the Driver’s seat thru DevOps and other Best Practices.” He provided a terrific overview of how his team transformed Capital One’s software delivery using DevOps. Capital One currently has 30 teams leveraging DevOps practices, and they are running DevOps processes across all frameworks (Java, .NET) and legacy apps, including the mainframe. They are using Kanban and have leveraged the Scaled Agile Framework (SAFe) to bootstrap their DevOps teams. This was a terrific example of how an enterprise did a “rethink” on their software delivery process, and how indeed, DevOps is ready for the enterprise!
Finally, the conference offered up a “Bit Fat Rethink” on ITIL. There was an Openspaces discussion on the impact of DevOps on ITIL. The head of ITSM from Axelos was in attendance, and we discussed how Continuous Delivery is driving a rethink on Change Advisory Boards (do we need them?) and the whole ITIL Service Transition process. There was good discussion about ITIL moving forward and how DevOps and ITIL can complement each other. This will the main topic of our next DevOps Drive-in webcast featuring Pink’s George Spalding on July 24th. Please register now to join this interesting discussion.
DevOpsDays is a forum that challenges the current way teams, processes and tools are used to deliver software to the business. Lots to rethink about!
I’m always interested in what motivates people. What makes them change, improve, and innovate? I had an opportunity to attend both the Jenkins User Conference in Boston and the CloudBees Continuous Delivery Summit in New York City, both of which were sponsored by Serena and both of which were filled to capacity. There were a lot of motivated attendees, and I had an opportunity to speak with many of them.
All of them were interested in ways to transform their current way of building and delivering software using the patterns and practices of Continuous Delivery. Everyone knows that their current method is broken and that “small, agile and fast” beats “big, hairy and slow,” hands down. You could sense the urgency to address challenges with the deployment pipeline.
What struck me was the diversity of company types, sizes, industries and maturity levels. I spoke with companies that were building RFID services in the cloud for large retailers, companies trying to improve quality and cycle times for the production of embedded software in medical devices and companies struggling with constructing deployment pipelines for mobile and cloud environments. There was lots of discussion around where to start, how to deal with legacy applications and infrastructures and what tools to use. Improving quality and reducing cycle times by automating the deployment pipeline was the main topic for both days.
In New York, Forrester analyst Kurt Bittner opened up the CD Summit with a compelling presentation on the “Business of Continuous Delivery.” Kurt shared some very interesting insights, calling Continuous Delivery “Agile 3.0″ and stating that CD is the engine that enables businesses to obtain a competitive advantage by allowing them to handle a high rate of change. Maximizing throughput minimizes wait and waste and increases innovation rate, which Kurt defined as the percentage of application development spending focused on new capabilities vs. maintenance of existing capabilities.
The two events were also great places to roll out our new deployment automation software free trial. We encouraged those Jenkins users looking to extend their DevOps toolchains with deployment automation to check out Serena Release Automation, and we expect to see a lot of downloads in the coming days.
Continuous Delivery is already reshaping how software is being delivered. We have the successful “DevOps unicorns” as today’s examples but expect to see a lot more big enterprises telling their success stories soon. As William Gibson said (and mentioned by Kurt in his presentation): “The Future is already here — it’s just not evenly distributed.”
How far along are you in your Continuous Delivery journey? Leave a comment and let me know.
In order for you to deliver, you need to deploy fast and deploy easy. Fast deployments ensure fast feedback, enabling you to fix, enhance or change the product as fast as the market requires and faster than your competitors. This is market pull rather than company push. A system that pulls rather than pushes needs to not only be fast but also easy. It has to be easy because every check-in could be a release candidate.
Development teams have been developing and building applications quickly and easily through Continuous Integration and often using Jenkins. But, now they need to automate the rest of the deployment pipeline in order to get to Continuous Delivery.
If you are interested in reducing your cycle times and improving your application quality, and you live near Boston or New York, we invite you to join us at the Jenkins User Conference US East on June 18 in Boston and at the CloudBees “How to Accelerate Innovation with Continuous Delivery” seminar on June 19 in New York City.
We are very excited to partner with the host of both of these events, CloudBees, to help you deliver on the promise of Continuous Delivery. Come see CD in action!
Enterprise IT is struggling to meet the needs of the business, and I wish I could give you a pill to just fix it. I can certainly give you software, and that will take some of the pain away, but the big improvement needs to be in peopleware and culture. Building and deploying software requires considerable collaboration and coordination by different people, teams and organizations. DevOps is a cultural movement focused on removing the barriers between the teams and organizations to deliver more value to the business faster. You can’t just buy DevOps, you have to also transform this culture.
At last week’s Serena DevOps Drive-in webcast, I spoke with Mandi Walls from Chef about keys to building a successful DevOps culture. During the webcast, we asked the attendees what the biggest barriers were for DevOps adoption, and the majority said it was lack of collaboration and cultural barriers (see chart).
Want to learn more? Check out the recording of Mandi’s “5 Keys to Building a Successful DevOps Culture” presentation. It will provide you with practical guidance on removing those barriers and accelerating your DevOps adoption.
I recently attended DevOpsDays Austin 2014 and was very impressed by the event as a whole. The conference format provides a great medium for the attendees. The combination of thought leadership and technical presentation tracks along with Open Space discussions and Ignite talks, makes the two day event both informative and very interactive. Here are my three key takeaways from the event:
1. DevOps culture is still a big topic of discussion. Tools are a great enabler, but as the opening keynote speaker Andrew Clay Shafer (@littleidea), says in his post presentation interview, you can’t buy DevOps. In Andrew’s opening keynote presentation, he shows how different languages and tribal signaling leads to disconnects in both business and technical organizations.
Culture was another discussion point in the Enterprise DevOps open spaces I attended. There was a great discussion on how to get teams, organizations and management buy in. Whether you drive cultural change from the top down or bottom up, it is all about the people. Tools can influence behavior and help change culture, but “peopleware” is just as important as software. Clearly, this is a big topic that needs further discussion. In fact, we featuring Mandi Walls from Chef at our next DevOps Drive-in talking about this very subject.
2. Enterprise DevOps still lacks maturity. We need to continue developing the “how:” the patterns and best practices of DevOps for the Enterprise. Matt Ray (@mattray) provided a very good maturity lifecycle in his presentation “Helping Horses Become Unicorns.” He covered topics such as hardware management, OS management, infrastructure management, software deployments, incident management and even disaster recovery and postmortems, stressing both business and cultural issues. His assertion is that it is possible to transform a horse into a unicorn. I would say that enterprises don’t even need to become a unicorn. A faster, stronger horse FTW!
3. DevOps has not yet crossed the chasm but it’s getting a big push. Michael Cote (@cote) from 451 Research delivered a good presentation on “When is the DevOps Unicorn Going to Sprout Wings and Fly.” Cote mentions that over the next 10 years, mobile and cloud will initiate a massive rewrite or re-platform of applications, and that is demanding a new way of delivering software (DevOps). Cote reviewed the results of a 451 Research DevOps survey that gives a good view into the maturity of mainstream IT. His reference about white collar toolchains (e.g., Word and Excel) that don’t use version control rings so true. What I found particularly interesting is that almost 40% of the companies surveyed said that the one thing preventing them from reducing cycle times is human resource constraints. I think delivering on the DevOps principles (CAMS) would help with this constraint because the high performing organizations that I’ve seen are doing more with less and not more with more.
DevOpsDays is a great event organized around trying to solve a real hard and present problem. If you are involved with deploying or releasing software from development to production, I recommend you head to your local DevOpsDays event to see what the tip of the spear looks like. And, for a special event, join Serena at the special 5th anniversary of the founding of DevOpsDays in October in Belgium. It’s also the 5th anniversary of the first use of the term “DevOps,” selected as the hashtag for that first event by legend Patrick Debois.
For our May DevOps Drive-In webcast, we’re delighted to feature Mandi Walls, author of the eBook “Building a DevOps Culture,” published by O’Reilly. Mandi is a Technical Practice Manager at Chef and travels the world helping organizations increase their effectiveness using configuration management and modernizing IT practices.
She will join me in a discussion on the impact that culture has on driving successful adoption of DevOps practices. Register and join the webcast to participate in the live Q&A with Mandi and me, as this is sure to be an interesting discussion filled with tips and tricks for identifying cultural barriers and tearing them down.
CloudBees is a Continuous Delivery solutions provider and the Jenkins expert for the Enterprise. With CloudBees focusing on Continuous Integration and Serena Software being the expert in automating application deployments, this partnership provides a great integrated value chain for Continuous Delivery in the Enterprise.
I’m often asked, “How do you implement Continuous Delivery in the Enterprise?” Continuous Delivery (CD) can seem like an unattainable goal for many IT organizations. The first thing we need to do is to make sure everyone understands, “What is Continuous Delivery?”. I like how Martin Fowler describes it. Martin also states, “Continuous Delivery is sometimes confused with Continuous Deployment. Continuous Deployment means that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day. Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment. In order to do Continuous Deployment you must be doing Continuous Delivery.” Enterprise IT usually breathes a sigh of relief once they understand Continuous Delivery does not mean Continuous Deployment because in many Enterprise IT shops that is not going to happen, perhaps not even required.
So where do you start? We actually discussed this question in our April DevOps Drive-in. In fact, we asked the attendees, “Where are you on your Continuous Delivery journey?” The results were a bit surprising as only 8% said they had no plans to implement Continuous Delivery. Most were in the process of implementing Continuous Delivery and 25% are planning to implement it in the future.
To learn more and see a solution demo check out the recording of this DevOps Drive-in “Achieving Continuous Delivery in the Enterprise, powered by Serena and CloudBees” or visit us at the next Jenkins user conference in Boston on June 18th.
I’m not a golfer but every golfer has their favorite, most dependable iron. In Enterprise IT, its the mainframe. The mainframe has lasted over 50 years because of its resilience, dependability and because it just runs! The problem is that if you mention the word “Mainframe” to most IT professionals today their eyes glaze over and they get totally confused when terms like CICS, IMS or ISPF are mentioned. Deploying composite apps that have mainframe artifacts is currently an art reserved for the highly skilled. Serena Software recently held its quarterly Mainframe Virtual User Group and gave a demo on how Serena Release Manager’s Deployment Hub automates ChangeMan ZMF package deployments from a simple, easy-to-use graphical editor. Something any duffer like myself can do at a moment’s notice!
Whenever the words “Continuous Delivery” and “Enterprise IT” are used in the same sentence it rapidly turns into a page or at least a paragraph. That is because “Enterprise IT” generally means a big, diverse set of heterogeneous infrastructures glued together across many teams and locations that use many different tools and processes to develop and deploy software. Each enterprise has its own unique DNA that has organically evolved through generations of applications and technologies with its own historic set of artifacts and processes that have weathered the storms of innovation.
Continuous Delivery’s goal is to find ways to deliver high-quality, valuable software in an efficient, fast and reliable manner. It’s an effective pattern for getting software from development to release. However, mapping a set of automated deployment pipelines across an entire enterprise can be challenging and in many instances may take years to achieve or may never happen completely. Does that mean you should not start implementing Continuous Delivery? Absolutely not. Continuous Delivery is an ideal, an end state with continuous improvement every step along the way. This is something we are going to discuss at the next DevOps Drive-in Webinar. Don’t miss out! Sign up for “Achieving Continuous Delivery in the Enterprise, powered by Serena and CloudBees” today.