Before start reading: please consider, if this article is useful to you or if you just appreciate my work on it, to support me just sharing this article with your friends by your favourite Social Network. This would be a really appreciated help. Have a nice reading!
Last Updated on
I often loved to write in my posts about topics closer to my ICT job. I’ve posted, for example, a guide to move applications on Containers and even a funny interpretation of ITIL framework. In this article, I’m continuing this branch of my blog collecting some thoughts about DevOps adoption in Enterprises.
A Bit Of History
In this technology innovation age, ICT world is experiencing an evolving speed never seen before. Business needs are moving with fast changing rate and developers often work hard to stay in line with new business requirements and time to market can be a killing key value to reach ICT goals.
In first 2000s, Agile methodology started to spread between developers, but technology tools were not so advanced to allow them to take root in big enterprises (which moves main technology evolution streams).
With the introduction of containers in 2010s, a new development approach took to the field: application become volatile as their containers and storage persistence was dedicated only to those items which really need to live (data and configurations). Together with a DevOps organization, this enhances to gain great benefits in terms of costs and time to market reduction. According to Deloitte, organizations adopting DevOps see an 18% to 21% reduction in time to market.
But this revolution, even if radical and universally acknowledged as unavoidable, isn’t still widespread. Why? Because containers need a parallel organization revolution based on DevOps.
What Is DevOps?
Term DevOps derives from the aimed strict collaboration between “DEVelopment” and “OPerationS” departments, usually divided in big Enterprises.
In one of its publication, Deloitte defines DevOps “a software delivery approach, culture, or practice that brings development teams and other IT stakeholders together to achieve a common business goal of delivering work faster while maintaining excellence in quality” (Rif https://www2.deloitte.com/content/dam/Deloitte/global/Documents/About-Deloitte/gx_about_deloitte-agile-devops-advisory-transformation-delivery_Deloitte-Enterprise-Agility-and-DevOps-Brochure.pdf).
From Enterprise perspective, this publication includes 4 key components working together to reach faster deliver goals: People, Technology, Governance and Process.
In my opinion, this model the main stakeholder is missing: User. For example, term “faster” is too generic and should consider also user expectations. If deploy comes too faster than user expectations, then new functionality could change so fastly that user cannot familiarize with, loosing all advantages for new business needs and introducing lack of familiarity.
So, my concept on DevOps definition should be more similar to “a mix of culture, approach and technlology that brings Organizations to achieve the goal of meeting full User Expectations faster and faster”.
Keys To DevOps Success
Adopting DevOps paradigma is a complex process. There isn’t a defined way that meets all businesses and companies, because every business and every company has its history, its culture, its times. But we can identify a few items to focus on that could help to address the right path. In this, a great summary comes from a Gartner publication. Below, I’ve revisited these Keys to DevOps success with my experience.
1 – Identify Business Justification
In referred publication, my favourite paragraph is “A DevOps initiative must focus on business requirements and not on doing DevOps for the sake of DevOps, wherein the methods and tools become more important than what customers need”. DevOps adoption must be managed as a project, and all projects need defined and shared goals, management commitment and metrics to monitor progress. All these needs are naturally addressed when a Business Justification underlies the effort.
2 – Define DevOps For Your Organization
My personal point about this topic approach may be different from usual thinking. In my opinion, Organizations should manage DevOps transformation like a digital disruption change. They should map a completely new DevOps team focusing only on what users and business require. Then they should project the move (Step-by-Step like a continuous evolution made of small deployes) from current organization to new DevOps one. DevOps structures should avoid deformations coming from historical constraints.
3 – Select The “First Mover” Application
Companies must choose carefully first DevOps pilot project. Consider that during this first Proof of Concept people will be engaged both on processes definition and product delivery. So, a low critical profile project (with acceptable value and risks) will make possible to focus effort on best results both for product and organization evolution.
4 – Identify The Initial Team
In this key item I’m totally in accord with Gartner: when selecting members of the initial team, emphasize behavior over skills. Skills can be acquired by people over the time, wrong behavior is harder to correct and could drive to project failure. Give the team the right commitment over competence centers, so that the team can receive technical support when needed.
People from this team must also change over the time: you must avoid that DevOps could become just an new silo in your organization.
5 – Establish Objectives and Metrics
Metrics and incentives should help people to easily understand if they are going in the right direction. Furthermore, they should help teams to work together with the same target. Be aware to use these powerful tools assuring that each individual goals will never be a threat for team ones.
6 – Focus On Limits
Like many common changes in ICT, focusing on a few limitations that heavily impact your organization performance is the best way to fastly improve you results. So, identify production bottlenecks and work to solve them to have greatest value from new DevOps organization. Set up a virtuous habit to continuosly monitoring highest impact factors. Rank them being based on impact and solve periodically the top “x” of them.
7 – Learn From Each Error
Error is what distinguishes working people from NOT working people. An old boss of mine used to say: only those who work make errors. So don’t impeach who fails, but pretend to have a procedure correction for each error. This way your team will progressively build a stronger process which avoides failures and build on experience.
Common Mistakes To Avoid In DevOps
As said, DevOps adoption can bring company to a faster timeto answer users and market needs. Less time means also less costs and increasing in revenues. But a correct transformation process should avoid common mistakes which can drive to a failure in this change.
Warding Cultural Habits
DeoOps tranformation is also a deep change in collabotation culture between two worlds sometimes opposite between them: Developers and Operations. With this new paradigma, all of barriers broke down to form a new integrated team able to cooperate on the same page. This often requires hard work to dismantle old silos and disrupting existing status-quo. Motivations can arise when first positive results come out, fixing them to be observable and measurable.
Adopting DevOps because… It Is Trendy
DevOps can bring great advantages, but this doesn’t mean that it gives the same results for all business and all elements. Organization should carefully evaluate benefits from what it wants to implement and check that its goals are welcomed from its users and its market. Going into DevOps for DevOps sake could waste money, time and employees self esteem if it isn’t well thinked and focused with right targets.
Building A Closed And Dedicated DevOps Team
DevOps means collaboration and barriers disruption. Building projects islands in complex organizations is an effective risk. DevOps should be seen as a natural mutual support practice where different contributors (from development, operations but also quality assurance, security, procurement, etc) could attempt to work as a single body within the same path
Preferring Speed Over Quality
Thinking to DevOps as a magical way to speed up your organization product delivery may lead to undervaluate quality level keeping. This is another great risk to be monitored. Quality reduction costs could reduce or override revenue increase coming from DevOps adoption.
This is one of most common errors. This comes when an Organization records successes with one or two teams in adoptiong DevOps and forces all other teams to adopt the same successful tools and practices.
In line with ITIL best practices, you should consider each business, each structure and (maybe) eachteam as a value stream, having its own users, stakeholders and requirements. This often requires specifical tools and practices that could (not should) match with other teams one. So, my suggestion is to identificate a methodology that helps teams to reach DevOps adoption and make it a guide line (with its own life cycle including periodical revisions and improvements).
Focusing Only On Technology And Tools
In my experience, Customers are often more focused on adopting depliants than business improvement. Keep your attention on what your teams can give your customers. What technology and tools can give you comes after you have clear goals coming from users and teams.
Low Management Endorsement
This is another big mistake often experienced in Change projects. People tend to undervaluate tasks without management endorsement. This can lead to projects delay or failure. Commitment from Management assures correct support to teams involved in change and helps greasing gears between different teams.
Bad Lesson Learned Management
Considering issues solved as something belonging only to past (and unrepeatable) increases chances to experience it again in the future. Each issue should be consideres as an opportunity to improve your value. Issues must come to a solution and related improvements to avoid their occurrence in future.
With the number of Cyber attaks increasing year by year, security is taking on an increasingly primary role in ICT organizations. Security guidelines can go in contrast with work done in developing new services and bring great money wasting or great security risks if not managed from start side by side. DevOps adoption projects give organizations a great opportunity to fix mismatching requirements from past ages (where present). In fact, ICT world is appreciating DevOps and Security collabotation with new DevSecOps integration.
DevOps adoption is a challenge which can impact your organization in positive only if managed correctly. Like main Changes, it requires the right attention and the right people. But also requires a real and deep focus to your users needs to evolve from old jurassic business driven transformations to a successfull users driven transformation. This is what Steve Jobs really teached to the world and should be the basis on every modern Company evolution.