It’s safe to say that #DevOps hasn’t reached its demise, but it has certainly jumped the shark. Just like the iconic TV show Happy Days, which resorted to having The Fonz jump over a shark on water skis to keep its audience engaged, DevOps has become unwieldy and overblown.

This phenomenon is not new in the IT industry. We can draw parallels with Service-Oriented Architecture (#SOA), a methodology for systems architecture that was overshadowed by product vendors pushing their application middleware as SOA, despite its primary focus on messaging rather than service design. Consequently, SOA became synonymous with middleware and lost its prominence in industry discussions.

However, this doesn’t mean that SOA ceased to exist or is no longer practiced. It simply evolved into what we now know as microservices architecture, which is more about delivering application functionality through APIs that utilize JSON messages for communication. Unfortunately, revenue is not generated by modeling, architecture, practice, or methodologies. It’s the tools, products, and implementation services that generate revenue. DevOps started as a concept, but it has now turned into an industry.

The essence of DevOps emerged from the realization that close collaboration between development and operations teams could enhance software reliability by promptly responding to observations from production environments. Instead of following the traditional approach of accumulating changes for months while a release struggled, companies like Flickr, under the guidance of John Allspaw and Paul Hammond, fostered a culture that challenged conventional thinking and enabled more frequent updates.

DevOps wasn’t even a term when Flickr achieved these remarkable outcomes. John and Paul improved the software development lifecycle (#SDLC) without creating something entirely new. They took an existing process and enhanced it to meet the business’s needs. DevOpsDays aimed to bring together like-minded individuals to discuss these improvements and how others were tackling software development at an internet scale.

Today, every company developing any kind of software, whether it’s an extension for Salesforce.com, a mobile application, or a Robotic Process Automation (RPA) bot, wants DevOps. However, development executives should question which aspects of the SDLC are truly necessary to achieve their goals. Many have been convinced that they need the full-blown Rolls-Royce package when all they really require is a reliable Toyota Corolla. Moreover, engineering organizations often lack the proficiency to customize an SDLC to align with business demands. Additionally, they fail to recognize that each project may require unique SDLC customizations for optimal performance.

DevOps has jumped the shark because it is now haphazardly applied to development projects based on a model of developing highly reliable, high-availability systems at an internet scale. This is the primary reason why software development efforts often fall short of expectations, despite claiming to follow DevOps principles. DevOps is not a one-size-fits-all solution, and the process of building and releasing software is not a simple nail for the DevOps hammer.

However, certain ideas from the DevOps community are universally applicable to all software development efforts, regardless of the application or platform:

• Collaboration and trust between development and operations teams are crucial. These cannot be achieved through mandates and programs; they require time, working together, and understanding each other’s concerns and risk tolerances. Past performance plays a significant role in building this trust.
• Automation is essential. The SDLC should be managed through an automated process that incorporates agreed-upon configurations approved by all stakeholders.
• A system of checks and balances is necessary. In lean manufacturing, this is known as jidoka or automation with a human touch. At any point in the cycle, anyone should be able to halt the automation if they believe it will compromise the system.
• Feedback loops are vital. While software architecture and good coding practices address scalability to some extent, storage, network, and security impose limits on any system.

If you’re looking to succeed with DevOps, it’s important to appropriately identify the roles within your organization. If a person is responsible for setting up your CI/CD stack, developing infrastructure-as-code scripts, configuring Jenkins build automation, and other tasks related to build and release, consider hiring them as platform engineers. To truly thrive with DevOps, hire a head of software engineering who understands how to organize the environment, drive collaboration between development and operations, and lead the necessary changes to leverage a modern SDLC.