What do you think, how much time will be needed to deliver a program that can be run by just a single line of code?
The answers to this question, posed by Mary and Tom Poppendieck in their book called Lean Software Development, tell us a lot about the IT organization's ability to quickly and reliably bring new software to market and the resources it will need to devote to meeting the growing expectations of its clientele.
The waterfall approach to software development may appear antiquated, but assuming it has died out would be a mistake. In the waterfall model, a lot of work would be put into delivering adjustments to production, only to learn they were useless because the requirements had evolved or were no longer relevant. When compared to the traditional waterfall methodology, the early inclusion of various stakeholders in Agile Development's product development cycle was a welcome change. However, the promise was that with each cycle of 2-3 week sprints, there would be a "possible increase."
The truth was that the product changed rapidly in sprints, but adequate attention wasn’t paid to testing or to release procedures and processes. As a result of teams working in isolation (or "Silos"), relying on manual handoffs, pursuing incompatible objectives, and using varying definitions of "done," the delivery pipeline was clogged.
The outcome was only slightly superior to the waterfall method, but the product's value was reduced and customer satisfaction remained low. What the Agile movement failed to do was to break down the silos in such a way that it favours the completely synchronised teams with a single Definition of Done; this is what DevOps does.
By enabling end-to-end (E2E) automation via tried-and-true procedures and synchronised resources, it does define a unique set of methods for consistently providing more value to consumers. DevOps, in this sense, is PPT, the harmony between people working together, automated processes, and integrated tools. It's plausible to suppose that beyond this simplification, people have varied perspectives about DevOps, which eventually leads to a lack of definition. Yet, DevOps has always been linked to a few staple procedures.
Companies like Netflix, Facebook, and Amazon, among others, propelled DevOps into the spotlight by boasting about performing hundreds of product deployments daily. Netflix developed its own Simian Army, a collection of tools designed to cause as much chaos as possible within the company's infrastructure in order to evaluate its resilience and fault tolerance before automating its fail-over procedures and restoring service reliability. The world took notice of these lightning-fast rollouts, and businesses quickly began trying to imitate the success of these startups.
Adopting DevOps methods in Enterprise IT businesses was indeed a wholly distinct issue. Enterprise IT faces a number of obstacles that the aforementioned examples do not:
- Segmented global organisation structures in harmony with all of the business processes
- There are a lot of products for different kinds of devices, and they all have varied technological needs.
- Dedicated teams functioning in silos
- Large amounts of history and a reliable database or enterprise resource planning system
In such a complicated environment, it would be counter-intuitive and detrimental to Enterprise IT to try to mimic the techniques of the pioneers. It's also important to note that a large percentage of Enterprise IT projects, including those dealing with databases and other statically-structured systems, may not be a good fit for the DevOps methodology. For starters, such systems wouldn't need to adapt quickly, and secondly, they'd have their own set of specialised tools and procedures that typical DevOps principles and tools might not be a good fit for. However, DevOps is a natural fit for systems that differentiate and innovate.
The question is how IT departments at large organisations can start using DevOps.
The adoption of DevOps within enterprises should be viewed as a process, rather than a quick fix. Shorter release cycles, leaner procedures, and more productivity can result from steady but measured advances in collaboration, integration, and automation, all of which contribute to a broader shift in the organization's culture and its approach to its day-to-day operations. The establishment of cross-functional teams that are product-focused allows for the flattening of traditionally rigid organisational structures into a collection of "startup-like" teams that can function independently of one another. In the long run, cross-skilling can help minimise the number of distinct positions needed to conceive, plan, construct, test, launch, and monitor an application or a product. As DevOps evolves, the emphasis moves from simple "keeping up" to a more comprehensive "Continuous Innovation" culture.
