The goal of using information systems to continuously deliver enterprise business value is as old as the technology itself. From punch cards in the '60s to mainframes in the '70s to cloud computing services today, technology has certainly evolved, but we have seen little progress in how it can be used to deliver business value.
Despite the passing of time and new innovations, the challenge remains the same: How do we successfully apply IT practices to improve revenue streams and unlock new DevOps opportunities? It's a quest that keeps many senior managers up at night and often leads to churn in technology and business divisions when business improvements fall short of what's desired. The cycle starts again with new leaders at the helm—whether senior managers, team leads, architects, or developers—with new DevOps ideas and optimism that, yet again, lead to mixed results.
What's holding enterprises back? I would argue that many of today's IT success stories are a matter of chance. What's missing are cognitive frameworks to guide how information systems and technology are managed and applied to daily operations—frameworks that can eliminate "DevOps guessing games" and deliver business value and improved economic performance.
Lessons learned from the auto industry
Did you know that some of today's common DevOps approaches were borrowed from the automobile industry? Automobile manufacturing powered an industrial revolution in the United States in the last century, revealing successful management techniques and frameworks that were later adapted for other verticals. While the following approaches proved useful on the assembly line, they do not necessarily translate fully into the world of DevOps and software delivery. Yet these techniques are still prevalent in IT today:
- Command-and-control team structures. Teams are organized in strict hierarchies, often with functional redundancies that replicate under each vice president or senior vice president function. This type of organization can impose a strict division of labor, creating siloed work areas.
- Top-down execution. Under this approach, most work is sanctioned as part of a budgetary process. This entails making a huge assumption: that the successful execution of product delivery should follow the same strict path used during budget planning and allocation. Very little wiggle room exists to reconsider key assumptions that were made at the outset of the budgetary process, which typically occurs six to nine months prior to the project kickoff. If any of the critical assumptions change or are no longer valid at the time of project execution, very little can be done to revisit the monetary buckets allocated for the project. Some checks and balances remain to contain costs, but a fundamental gap remains that does not accommodate a much-needed feedback loop earlier in the cycle.
- Strict waterfall. Much business value is locked up with huge release cycles. This approach requires lockstep coordination across large teams, with very little opportunity to independently function once a change has been committed for a release cycle. This results in a premature lockdown of environments, where an error in one place can have ripple effects on unrelated pieces, dramatically slowing down delivery.
The top-down model, in particular, presupposes success after a set of activities, but success in today's fast-paced and fluid world of IT and DevOps can require extensive experimentation. Similarly, cross-team communication and coordination are necessities, but the organizational structures and incentives are not aligned to encourage workers to partake in such behavior. As a result, despite very lengthy (and sometimes painful) planning, execution, and delivery processes, enterprises can still struggle to deliver value. Instead, teams are met with what have become the hallmarks of software delivery projects: budget overruns, costly project changes, and ongoing employee churn.
One-off DevOps approaches: One step closer to breaking the barriers
There have been various attempts to address the limitations of the traditional handling of information systems and technology in the enterprise. Some of them attempted daring feats that challenged the status quo and were successful in redefining software delivery and introducing meaningful change. Some of the most popular approaches include:
- Test-driven development (TDD). TDD is an evolution of extreme programming (XP) that relies on the repetition of small development cycles to deliver incremental value in the software development process. In order to deliver fully realized software that is fully tested from the ground up, TDD relies on writing tests that are fully expected to initially fail; the software eventually passes when it has reliable code. In essence, every piece of code that gets produced with this method goes through tests to validate each feature and gains stable implementation in code and traceability with the requirements. In a way, TDD brings attention to the quality of software to the front end of the delivery cycle.
- Continuous integration. As defined by ThoughtWorks, this DevOps practice "requires developers to deliver code into a shared source control repository several times a day." Each delivery goes through an automated "build," which makes bugs in the code easy to find. According to Martin Fowler, a thought leader in this space, "Continuous integration in itself doesn't get rid of the bugs, but it does make them dramatically easier to find and remove." It essentially automates the process of finding defects in the development workflow and eliminates guesswork about where they might be.
- Agile delivery and methodology. This approach has disrupted the software delivery world by shifting customer focus to the very beginning of delivery cycles. It is meant to address the fact that, far too often, teams would spend a tremendous amount of resources and time to build something, only to find later that it does not deliver the value the customer desired. As discussed earlier, this was also an issue with the traditional waterfall delivery method.
- Other approaches. Minimum viable product (MVP), based on the lean startup methodology, focuses on building a product with minimum feature sets in order to quickly get the product out the door, get immediate customer feedback, and then expand the product from there. Continuous delivery (CD) focuses on creating software that is always in a releasable state and can be deployed to deliver business value.
The missing link: DevOps
The problem with enterprise adoption of these approaches is that they are viewed as having little or no connection with each other and, as a result, aren't being employed to their true potential. How many times have we heard from a senior manager that approach X, Y, or Z "simply doesn't work"? In fact, at some companies, the word "agile" is now taboo after several implementation attempts with poor results.
Rather than focusing on process or tooling problems that need to be addressed for the individual approaches, what's missing is a larger narrative that brings everything together in a holistic way: DevOps.
Without an integrated approach, these methods have barely made a dent in the foundational issues, such as old command-and-control structures that are perhaps part of the problem. If we don't remove the barriers of communication within various functional teams, process changes that should bring improvements are relegated to just words spoken by a new cadre of managers—all talk, but no action.
Perhaps Melvin Conway, one of the earliest computer scientists, had it right in 1968 when he said, "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
The implications of his research (which later became known as Conway's Law) on software delivery are remarkable. Conway's Law addresses the reality that lasting changes cannot be introduced without first assessing and addressing the communication structures of the team. Perhaps most failed attempts by enterprises to improve software delivery can be mapped back to the lack of attention paid to team communication and organization. Fowler argues that teams organized around silos will continue to produce siloed systems. It sounds obvious, but here we are, nearly 50 years after Conway's research was published, still struggling to derive business value from IT.
The agile principles of software development clearly state: "The best software architectures, requirements and designs emerge from self-organizing teams." Therefore, the most important aspect of introducing lasting change in an organization is to take into account the effects of not just process and tooling, but people as well. Netflix is a great example of an enterprise solution provider that has focused on creating self-organizing teams composed of people who have the autonomy to decide what and how to build, spurring software innovation and measurable business value.
DevOps is a movement that has given a much-needed voice to this holistic approach. Self-organizing teams are at the heart of the entire DevOps movement—teams that bring software practitioners, designers, and key stakeholders together early in the cycle and create feedback loops. It also helps focus on automation of most mundane and error-prone tasks, enabling teams to focus on what matters—delivering business value.
We cannot afford to continue to ignore the inherent links between the three critical parts of successful software delivery: people, process, and technology. As technology continues to provide automation, more avenues will become available to harness productivity and unlock business value from it. Adopting DevOps is not a choice anymore. It is now a core competency needed to compete in the new digital world in which we live today.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
