More businesses are turning to DevOps implementations to deliver software and updates with more efficiency. As much as business leaders know DevOps can help them to be faster and more agile, many of them are unsure how to get started. Many businesses even begin implementing DevOps only to run into unforeseen problems that hinder the process.
While DevOps can be beneficial, you do not want to make changes lightly. You need to know what you are getting into and prepare for ways the change can impact your company. Having a good team and providing them with the right infrastructure-as-code (IaC) tools will help, but there is so much more you need to consider before starting.
Here are five vital tips for successful DevOps implementations.
Evaluate Your Processes
You need to start by learning what DevOps is and what it means to your organization. Everyone on the team needs to understand what DevOps can do and the types of problems it can solve for your company.
Evaluate your entire development cycle from beginning to end. Look at the different processes that go into development to find different bottlenecks and inefficiencies. By finding the areas where your current processes come up short, you will be able to identify the areas to concentrate on when implementing DevOps.
Collaboration and Communication
Collaboration and communication are at the heart of successful DevOps implementation. You can get all of the best DevOps tools available, but if you do not have teams ready to work together and communicate, you will not achieve the full benefits of DevOps implementation.
If you are going to succeed, you need to instill a strong sense of collaboration and cooperation among teams. Beyond that, you also need to provide your team members with tools that will help them communicate and collaborate. Communications platforms and collaboration software can be just as important as the tools that contribute directly to development.
Set Goals
DevOps implementation is not just about getting the right tools and changing processes. You need to assess the operations of your company and set goals for the implementation. If you are just buying new tools without setting a new direction, the implementation will not result in that much change.
Another good tip is to start with one smaller, more easily achievable goal and then scale up from there. Changing everything at once might be too much of a disruption. Instead, select a smaller goal and once that is achieved, move on to goals that are larger and more complex.
Automation
Automation is a big part of what makes DevOps beneficial to modern businesses. If you are going to achieve the full benefits of the change, you should automate as much as you can. Whether it is scanning code for misconfigurations or automated testing, you can do a lot to make your operations more efficient by using a variety of different automation tools.
You may also want to take automation one step at a time. If you try to dive headfirst into automation, it might be a bit too much for your team to keep up with. Instead, take a manual process that has been taking a lot of time and toil from your team and implement an automation tool. Let your team monitor for a few weeks to see how it goes and then take what you learned and apply that feedback to automating more processes.
Know Your Key Metrics
Set your key metrics from the very beginning of the implementation process. Without metrics, you won’t be able to keep track of the progress you make. A lack of tracking will also make it difficult to identify issues that might be holding back your progress.
Most organizations will need to focus on three points: Lead time, deployment time and mean time-to-recover. Beyond that, try to think about your users when defining key metrics. What do they like? What do they care about? What makes for a more pleasing experience?
DevOps implementation is not simple. By taking the right steps to prepare, you can avoid the worst problems and put yourself in a position to respond well to the issues that do come up during implementation.
Avoiding these DevOps antipatterns can help organizations reap the benefits of implementations faster
It’s a given that all organizations at some point will suffer from poor development practices when trying to find the perfect balance between software development and IT operations. The good news, however, is that implementing DevOps can help you improve these processes and get them synchronized and working together in harmony.
However, understanding and mapping out the core issues and the common DevOps “antipatterns” that are holding you back from successful DevOps implementation is essential. This article will focus on the most common DevOps antipatterns that organizations tend to fall into and how to avoid or overcome them.
What Are DevOps Antipatterns?
At first glance, DevOps may sound like a pretty straightforward concept. At its core, DevOps is about bringing together separate but functional areas and bridges the gap between software development (Dev) and IT operations (Ops) with the ultimate goal of delivering software faster and with better stability.
That said, DevOps antipatterns can best be defined as ideas that are counterproductive to the DevOps culture. They include:
Blame culture: In this kind of culture, blaming and punishing people is the norm when mistakes are done. It can happen at an individual or organizational level.
Root cause analysis (RCA): RCA is a process that involves identifying the “root” cause of a problem or an event, as well as the appropriate actions to take to avoid a recurrence. It’s an iterative and continuous process that must be performed until data is exhausted or all organizational factors have been identified.
Human error: Human error is often cited as a root cause in RCA. This is also common in “blame culture” and someone has to be held accountable for mishaps and mistakes.
Silos: An organizational or departmental silo defines the mentality of teams that don’t share their knowledge with other teams within the same company.
4 DevOps Antipatterns and How to Break Them
Wrong Perception of Your DevOps Team
The perception you have of your DevOps team matters. It’s essential to consider the team as part of the entire process. Neglecting to provide them with structure, resources, and a positive working environment can increase your chances of DevOps failing. Furthermore, making DevOps teams more productive requires proper implementation of processes and tools.
How to Break It
A successful DevOps implementation requires more than just bringing people together. Structuring the team correctly and adding processes is vital if they are to succeed. Providing the necessary resources, technology and information security they need will get the best results.
Practices such as continuous integration (CI) and continuous delivery (CD) are both concerted processes that can be used to bring development teams together in alignment so software products are delivered quickly, operations are more simple to manage and no downtime is present during deployments that are detectable to the end user.
Poor Choice of Technology
Technology plays a significant role in IT; however, the rapid development of new technologies has made it challenging to separate essential and overhyped tech trends. For instance, DevOps itself is a powerful digital transformation tool as it plays a critical role in new software development and problem-solving. Nevertheless, many of the latest IT trends should not be worth your attention unless you and your team are willing to implement it correctly.
How to Break It
This antipattern can be broken by top-level and project managers who make the decisions regarding technology choices. Asking questions such as, “What does the organization need?” or, “How well will this technology work for us?” will help when choosing what tech is right for your organization. With thousands of tools and technologies available, you need such a mindset to make the right decisions.
Unclear Responsibilities in Teams
You may have come across this problem in many other non-IT projects. However, in both IT and DevOps teams, the consequences can be severe if solutions aren’t implemented quickly. If team members aren’t clear on their roles and responsibilities, this can lead to poor decision-making and unnecessary interference in other people’s positions.
How to Break It
First of all, you need to clearly define roles and responsibilities for everyone in the team. A clear definition of roles boosts productivity. For example, having a data scientist in your DevOps team can play a huge role in business success due to their very specific data analytics skills, techniques and tools. In fact, 89% of business managers agree that hiring a data professional will help to improve success at their respective organizations. There just needs to be active and consistent communication between team members for everyone to conduct their own roles and responsibilities efficiently.
Every team member should follow the strategies and plans in place so timelines can be monitored and effective top management decisions can be made. When implementing complex DevOps architectures that require teams and software to work together, poor decision-making will be an issue if roles are left unassigned.
Wrong or No Code Deployment
To put it bluntly, there’s no DevOps without code deployment. With this being the ultimate result, DevOps makes no sense if it fails. This is quite a challenge for several organizations, as having Dev and Ops teams working in harmony can seem impossible.
How to Break It
As mentioned above, code deployment is often a challenging task for DevOps teams. However, organizations can break the resultant antipattern by integrating the units correctly to enable a collaborative environment, a great strategy for successful DevOps implementation.
Such an environment will also make code deployment easier by reducing the need for a series of meetings and reviews, which ultimately delay teams from getting code to deployment.
NoSQL’s Key Role in Database DevOps
DevOps processes need to work in a synchronized manner to be successful. Issues with the database can cause it to slow down and affect the delivery of database changes. However, NoSQL’s unique approach is designed to simplify the process of DevOps implementation in the following ways:
Faster scalability
Many small companies fail to maintain peak performance with greater workloads. A more significant workload calls for better tools that can help maintain peak performance, subsequently making it easier for organizations to scale out.
More efficient technical support
Having technical support that doesn’t hold you back is key to DevOps success. The right NoSQL solution enables you to solve problems before they become full-fledged, expensive and time-consuming.
Faster adaptability
The changes that new codes bring for databases can be challenging. NoSQL makes it easier to deliver solutions to client requests, as it organizes them using dynamic indexing. Therefore, it verifies all queries before answering them with the appropriate index.
Platform testing
Testing is one of the critical steps you need to go through before actual implementation. Databases should be flexible enough to allow you to test queries without interfering with the real data. Testing helps to determine how new changes will impact the development process.
Conclusion
As you can see, there are many ways to implement DevOps systems in your business to deliver products faster, offer more technical support and automate essential tasks.
All of the requirements we have covered are necessary if a business is to scale and grow. Businesses need to ensure the correct strategies are in place, roles in the company have been clearly defined and common antipatterns have been identified and eliminated.
On March 15, I gave four keynote speeches on DevOps in Toulouse, France. As the main speaker of Econocom Club MEP 2018, an annual think tank summit organized by the European business-to-business digital services provider, I shared the day with 15 firms in industries as prestigious as financial services, energy, aerospace, aviation, and telecommunications and heard all about their implementation projects.
The lessons learned from this year’s summit are troubling, they tell a story the vast majority of DevOps vendors aren’t prepared to hear: They miss their client expectations. There’s a severe disconnect between what’s expected and what’s delivered.
Participant visions and approaches didn’t surprise me; they simply confirmed my point that DevOps is misunderstood. By stressing the implementation of Continuous Delivery (CD) toolchains—selling technology is more lucrative than transforming a business—IT service providers aren’t helping.
What do these lessons tell, exactly? if you’re an open-minded leader who understands that a new IT service delivery paradigm more focused on business concerns is needed, this is for you.
The Untold Frustration
In his opening speech, facilitator Fabrice Berne was inspired to ask participants while they introduced themselves to share the purpose and challenges of their DevOps implementation project.
What I heard didn’t surprise me; it was a mix of fascination and frustration—participants were at the same time excited to work on a DevOps project and frustrated because they weren’t getting the promised business benefits.
“The reason is, you all tackled your DevOps project the wrong way,” I said. “You started by implementing the CD toolchain, thinking tools on their own will deliver the expected business benefits. That illusion is widespread in the IT community!”
So, What is DevOps?
As my claim turned the atmosphere icy, I added, “DevOps can’t be narrowed to these tools—not even to agile practices and automation. It’s more than that. DevOps seeks to make the business competitive, wealthy and healthy by continuously delivering high-quality software.” And concluding my introduction, I made it clear: “The fundamental question is, How is business value created? Many experts, particularly techies, struggle to answer it.
“Let me say this straight: Most DevOps projects fail because certain experts erroneously spread the idea that the most important piece of DevOps is the CD infrastructure,” I said, adding, “The fact of the matter is these experts and the IT solution vendors they represent are creating confusion; through massive marketing hypes they force CIOs to address DevOps through the distorted lenses of the so-called DevOps tools.”
The Inconsistent Disparate Visions
The following chart results from a survey we conducted at ITaaSNow last year. It involved 2,681 businesses that were unhappy with their cloud and DevOps migration projects; we wanted to show how poor DevOps approaches lead businesses to failure:
Figure 1 – Disparate and erroneous visions that cause implementation failure
“As you can see, there’s no homogeneous perspective right now,” I told the audience. “It varies according to the business culture, objective and strategy or the DevOps architect’s understanding, experience and expertise. In most cases, these customized visions are incomplete and generate no business value at all.”
I picked two failure causes in the chart to demonstrate my point.
Starting with the notion that, “automation is the core of DevOps,” I argued, “DevOps primarily seeks to help generate business value. Generating business value is about identifying market and customer expectations, translating expectations into profitable service ideas, developing, deploying, promoting, selling them and continuously improving customer experience.
“Where did techies get the idea that to make a business profitable the only thing to do is to implement Git, Jenkins, Cucumber and Chef into a CD toolchain?” I asked, somewhat ironically.
Picking a second cause, “DevOps strategy should only stress software development activity,” I continued. “Thinking that isolatedly software development activities will generate business benefits without involving marketing, sales, testing and operations is a pure illusion. Once again, generating business value is a complex process that covers identifying market and customer expectations, translating expectations into profitable service ideas, developing, deploying, promoting, selling them, and continuously improving customer experience.
“Where did solution vendors get the belief that, software development alone is enough to generate business value?,” I asked. “That’s another myth they nurture!”
I then warned: “Make no mistake about it: All the visions represented on the chart are either incomplete or wrong. They do not reflect what DevOps is. You must acknowledge once and for all thatit is a business transformation effort, not only an IT capability implementation. Period.”
The Contrast with the Founding Fathers’ Vision
“Who better than its founders can provide the right vision and definition of DevOps?” I asked.
In his article, Adam reminded us, “Becoming better at building and delivering software is the stake. It’s not an optional piece of their strategy: It’s the future of how their customers want to work with them. Software is table stakes for survival.”
He added, “But the real answer lies in looking at what John, Paul, and Jesse were doing in 2009—not in the specific technical choices they made, but the style in which they worked, the essence of what they believed made them high functioning and successful. … Then the challenge begins: how to apply this new style to businesses trying to become better at building and delivering software.
“DevOps is about bringing together all the people you need to build and run your business effectively, and empowering them to move as quickly as possible toward their goals. Tools matter. Make no mistake: Trying to change the way you work without changing the mechanisms by which you do that work is a futile exercise in excruciating failure.”
He concluded, “Fundamentally, it is about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.”
With Respect to Techies, DevOps is Primarily a Business Operational Model
“If you paid attention to what Adam Jacob reported about Jesse, John and Paul’s vision, you probably noticed that it emphasizes two fundamental elements of high-performing businesses: the well-known IT infrastructure and the unknown operational model,” I told the audience.
Moving to the next slide, I provided evidences to my point, “As the picture shows, DevOps, according to its founding fathers, isn’t the CD platform, automation toolchain or the platform-as-a-service (PaaS) infrastructure solution vendors and certain consultants would like you to believe.”
Figure 2 – The Founding Fathers’ Vision
The slide seemed to clear up a doubt about what the audience had been hearing. I confirmed, “With all due respect to my fellow techies, as I’ve been implementing it, DevOps transcends software development issues; it’s a business operational model supporting your company’s competitiveness.”
Figure 3 – DevOps as the Business Value Chain
I told the audience I chose to represent it as a two-component system “because I wanted to make sure IT professionals and business leaders understand that implementing DevOps is primarily a business transformation effort for optimizing the organization’s operational model and IT infrastructure.” I added, “The operational model is the subset of interactions, staff and skills, processes and practices, values and beliefs, and tools that’s repeatedly mobilized across your organization to generate the expected business benefits. It’s where all its value propositions and competitive advantages—organizational agility, flexibility and velocity, innovation culture, more like it—are created. As (fellow speaker) Stephanie Carton puts it, the operational model is where DevOps culture is implemented.”
Anticipating the audience’s reaction to that point, I said, “It doesn’t mean CD toolchains are useless or doesn’t bring value, without them we’re dead. The point here is, business benefits result from an optimized operational model enabled by a well-engineered CD toolchain.”
I’m not the first one to go against the techie perspective of DevOps, I warned. “Ernest Mueller in his fantastic, “DevOps: It’s Not Chef and Puppet,” raised the red flag.” His message is clear: “If someone has a systems problem, and you say that the answer to that problem is Chef or Puppet, you understand neither the problem nor the tools.”
The Near Future of DevOps
In the first part of this article, I wanted to share with you the clarifications I made and more importantly, re-establish the truth on messages as erroneous as “DevOps means CD toolchain and Agile practices,” and “CD infrastructure or software development on its own creates business value.” They’re misleading CIOs and are taking hundreds of projects straight into the wall!
Figure 4 – DevOps Big Picture
In part 2 of this article, next month, I’ll tell you what we debated about the near future:
Why Agile and Lean practices will boost business competitiveness?
What is ITaaSNow DevOps Capability Maturity Model (CMM)? How does it enable continuous business performance improvement?
What is Artificial Intelligence for Operations (AIOps)? Why will it make DevOps the cornerstone of businesses’ digital strategy?
Stay tuned!
The Key Takeaways
This what I wanted to tell you about DevOps as we discussed it. The key takeaways are:
DevOps isn’t narrowed to agile practices and CD toolchains. Don’t fall into the trap of certain solution vendors who tell you that Git, Jenkins, Cucumber, Chef, Containers and microservices will boost your business performance. It’s false; things aren’t that simplistic.
DevOps combines an optimized operational model and a CD platform to bring together marketing, sales, post sales, software development, testing and operations into an application delivery capability that boosts your organization’s competitiveness.
Starting the CD toolchain implementation without optimizing the operational model is the surest way to take your DevOps implementation project into the wall.
DevOps implementation is primarily a business transformation effort, not just an IT capability deployment effort.
What matters isn’t applications and digital services delivery at the speed of light, but the timely delivery of added-value applications and digital services to the right market segments and business users.
According to Econocom’s feedback, most participants are reviewing their DevOps implementation strategy; they will make their operational model optimization the priority. Mission accomplished!
