Worldwide Locations
The popularity of DevOps has skyrocketed in the last few years and there’s a reason why—it can make a huge impact by bringing people, process and technology together. IT professionals and organizations are finding collaboration and continuous improvement easier than ever.
Barry Corless is Global Knowledge’s Global Product Director for DevOps and IT Service Management. He is a qualified instructor for DevOps, ITIL and SIAM and co-author of Global Knowledge’s “Adopting DevOps in an ITIL Environment” course. Barry has helped numerous organizations improve in a career spanning 30 years.
After watching this webinar, you’ll understand the essence of DevOps, including what it is, the business value, common myths, and be provided steps on how to gauge your organization’s readiness for adoption.
Viewers will gain a basic understanding of:
- DevOps origins, business values and business outcomes
- DevOps core concepts
- The truth behind some common DevOps myths
- How DevOps can interact with other frameworks and practices (Agile, Kanban, ITIL)
- Steps you can take to gauge your readiness for DevOps
- Why a holistic approach to DevOps education is critical to success
Q & A with Barry Corless: The Essence of DevOps
Q: DevOps introduces Continuous Delivery but does it require code changes to be immediately delivered from Dev, Test, Stage to Prod? Is it delivered by a single deployment tool or a team effort?
A: Continuous Delivery doesn't mean every change is immediately deployed to production. It means every change is proven to be deployable at any time. The next stage is Continuous Deployment where every change that passes the automated tests is deployed to production automatically. Continuous Deployment should be your goal but one should exercise caution where constrained by regulatory or other requirements. For example, I know many organizations that will automate to a staging environment but keep the actual production deploy as a manual intervention. The second part of the question is trickier. The mechanics of how you deliver this through a toolchain or indeed how the governance operates is very much down to individual organizations and their capabilities and constraints. What I’m trying to say is deciding whether continuous delivery or continuous deployment is right for your organization should be defined by business needs, not by tool or IT limitations.
Q: Are there criteria where DevOps should be tried—for example three-plus departments involved, novel products or services?
A: To be honest, there are numerous factors you should consider. Most pale into insignificance when measured against having the right culture, securing management support and the understanding of why you are doing it. I can see why your example might be good and bad.
Good:
- With three-plus departments, there is likely a fair amount of waste that can be eliminated and hence value to be delivered.
- A new/novel product or service will usually require a new way of working so there might not be as much “we’ve always done it this way” inertia.
Bad:
- If three-plus departments need to get involved in creating new product-focused teams, there’s a danger of variable levels of buy-in and enthusiasm as people arrive with “baggage” from previous inter-team encounters.
- A new product might be very high focus and if things don’t go well it could be easy to blame DevOps for failure.
Q: What is the minimum IT team size to practically tackle DevOps? We’re quite a small shop.
A: This is a tricky one. Fundamentally, you are never too small to learn and improve from DevOps practices and adherence to CALMS principles. Practically, I’d say 3 or 4. It really depends on organizational and individual capabilities. You need to ensure that coverage exists from design through the development process to production support.
Q: How would you apply DevOps within a large business transformation project such as a replacement of an HRIS?
A: I’ve seen a number of approaches to this. One that finds favor in many organizations is by understanding and adapting the way DevOps practices embed in another framework. I’d pick out Scaled Agile (SAFe) as a good starting point where portfolio and program level planning support an Agile Release Train which can be driven using DevOps practices and Agile/Product teams. The smaller product teams effectively have the architecture and integration direction (or backstop) of the enterprise and solutions architects. They in turn have taken direction from strategic themes emerging from their business and the business owner of the epics which are driving development work.
Questions answered in the webinar
Q: Is the environment really important for DevOps? What if you still have your own hardware but have virtualized its use?
A: The environment you deploy to is, to a certain extent, irrelevant. You’ll still look to automate as much as possible. Obviously it makes sense to use virtualized, configurable environments that treat infrastructure as code to gain the benefits from end-to-end code to deploy scenarios.
Q: Can you provide an example of a Start Small within an organization?
A: A UK organization we worked with had a process where they interviewed elderly and vulnerable people at their homes to calculate benefits they were entitled to. The manual process run by a small team involved collecting information by interview and manually entering that back at base. They also took photos of properties which they also uploaded manually. The whole thing was time-consuming and very prone to transcription errors. A new team used Agile and DevOps techniques to support a new integrated system that enabled use of tablets to collect information at clients’ homes. The system was small and self-contained enough not to cause a huge risk but big enough to display the benefits of switching to a more DevOps- and Agile-orientated approach. Benefits include quicker accurate payments, more visits per day by employees and satisfied customers. The ability to grow the application functionality in a regular cadence was a huge bonus.
Q: Does Ops include shipping and distribution to the customer/end user? Can you address the IKEA approach (using shipping to drive development)? Or even the Herman Miller approach to the end of the product lifespan and recycling/reusing materials?
A: If it is part of the value stream, why not? The feedback from the customer is key (feedback being one of the three ways in DevOps) and if the software supports that delivery then it’s in. Obviously, the way you channel that feedback into decisions about features might need to be thought through but as a rule, the closer you can get to your customer, the more successful you will be.
Q: From the Learning Team, who needs to help an organization to build DevOps capability? What learning models/approaches would you suggest?
A: A holistic, team-focused approach to learning is important. There still needs to be specialist skills but the team needs a wide range of generic skills. This includes understanding of DevOps practices, coding, testing, IT service management, security, Agile, Lean and the softer skills required to work in self-organizing, more collaborative teams. At Global Knowledge, we have defined the skills needed for DevOps roles using the Skills Framework for the Information Age (SFIA). We then map the training and education interventions that allow the acquisition of those skills.