The goal of continuously delivering enterprise business value with information systems is as old as the technology itself, but as the technology has evolved, from punch cards in the '60s to mainframes in the '70s to the cloud computing services of today, there's been little change in how it can be used to deliver business value. A DevOps approach can change that.
Despite the passing of years and new innovations, the challenge remains the same: How do you successfully apply IT practices to improve existing revenue streams and unlock new opportunities?
It's a quest that keeps senior managers up at night, and leads to churn in technology and business divisions when desired business improvements fall short. Then the cycle starts again, with new leaders taking over the helm, bringing new ideas and optimism that, yet again, lead to mixed results.
What's holding enterprises back? The truth is that many organizations with IT success stories just got lucky, so you can't succeed by following in their footsteps. What's missing are a few DevOps best practices. You need to create cognitive frameworks that can guide how you manage information systems and technology and how you apply it to daily operations. These frameworks eliminate technology guessing games so you can deliver business value and improve economic performance.
Lessons learned from the auto industry
Some of the most common IT approaches in use today were developed in the automobile industry. Automobile manufacturing powered an industrial revolution in the United States in the last century, yielding successful management techniques and frameworks for manufacturing that were later adapted by other industries. While these approaches proved useful on the assembly line, they do not translate fully into the world of software delivery. Nonetheless, 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. This type of organization imposes a strict division of labor and creates siloed work areas within which people learn to function.
- Top-down execution. Although most work is sanctioned as part of a budgetary process, the biggest assumption made here is that the successful execution of product delivery should follow the same strict path used during budget planning and allocation. Once that's locked in, you're left with very little wiggle room later if you need to address key assumptions that were made at the outset of the budgetary process?something that typically occurs six to nine months prior to project kickoff. So, if any critical assumptions either change or become invalid at the time of project execution, there's not much you can do to revisit the monetary buckets allocated to the project. You have some checks and balances to contain costs, but a fundamental gap remains. This approach does not accommodate a much-needed feedback loop in the cycle.
- Strict waterfall. With this approach to software development, much of the business value remains locked in long release cycles. A strict waterfall approach requires coordination across large teams, with little or no opportunity to function independently once a change has been committed for a release cycle. This results in the premature lockdown of environments, and an error in one place can have ripple effects in unrelated areas, dramatically slowing delivery.
This top-down model presupposes success after a set of activities, whereas success in today's fast-paced world of IT can require extensive experimentation. Similarly, cross-team communication and coordination are a necessity, but organizational structures and incentives are not aligned to encourage workers to partake in such behavior. As a result, despite very lengthy planning, execution, and delivery processes, enterprises still struggle to deliver value. Instead, teams face what have become the hallmarks of software delivery projects: budget overruns, costly project changes, and ongoing employee churn.
One-off approaches: One step closer to breaking the barriers
Many people have attempted to address these limitations, and a few have taken approaches that successfully redefined software delivery. Some of the most popular approaches include:
- Test-driven development. TDD, an evolution of extreme programming, relies on the repetition of small development cycles to deliver incremental value in the software development process. To deliver software that's fully tested from the ground up, TDD relies on writing tests that will initially fail and then pass with reliable software code. Every piece of code produced using this method goes through one or more tests to validate a feature-stable implementation in code and traceability with requirements. With TDD, organizations pay attention to software quality, starting at the front end of the delivery cycle.
- Continuous Integration. This development practice, as defined by Thoughtworks, requires that developers deliver code into a shared source control repository several times a day. Each delivery goes through an automated build that makes bugs in the code easy to find. According to Martin Fowler, "Continuous Integration in itself doesn't get rid of the bugs, but it does make them dramatically easier to find and remove." It automates the process of finding defects in the development workflow, and eliminates guesswork about where those might be.
- Agile delivery and methodology. This approach has disrupted the software delivery world by shifting the customer focus to the beginning of the delivery cycle. Too often, teams spend a tremendous amount of time and resources building something that the customer supposedly wanted, only to find later that the product did not deliver the desired value. This was a big issue with the traditional waterfall delivery method.
There are other approaches you might consider as well. For example:
- The minimum viable product (MVP), based on lean startup methodology, focuses on building a product with a minimum feature set in order to quickly get a product out the door, and get immediate customer feedback to continue to evolve the product.
- Continuous delivery focuses on creating software that is always in a releasable state and can be deployed to deliver business value.
DevOps: The missing link
The problem with all these approaches is that they are viewed as having little or no connection to one another. How many times have you heard from a senior manager that approach X, Y, or Z "simply doesn't work"? In some companies, the word agile has become taboo after several implementation attempts yielded poor results.
Rather than focus on process or tooling problems that need to be addressed with these individual approaches, you need a larger narrative that brings everything together in a holistic way.
Without an integrated approach, these methods will barely make a dent in such foundational issues as the old command-and-control structures that are part of the problem. If you don't remove the barriers of communication within various functional teams, process changes that should bring improvements become just words spoken by a new cadre of managers. They're all talk, but no action.
Computer scientist Melvin Conway once 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) to software delivery are remarkable. It addresses the reality that lasting changes cannot be introduced without first assessing and addressing the communication structures of the team.
Most failed attempts to improve software delivery can be mapped to the lack of attention paid to team communication and organization. Fowler argues that teams organized around silos will continue to produce siloed systems. This sounds obvious, but here we are, nearly 50 years after Conway's research was published, still struggling to derive business value from IT.
Now we have the agile principles of software development, including this one: "The best software architectures, requirements, and designs emerge from self-organizing teams."
In other words, the most important factor if you want to introduce lasting change in your organization is to take into account the effects not just on process and tooling but on people as well. Netflix is a great example of an enterprise solution provider that focused on creating self-organizing teams comprised of people who have the autonomy to decide what and how to build, and that has spurred software innovation and measurable business value.
A holistic approach
DevOps as a movement has given a much-needed voice to this holistic approach. Self-organizing teams are at the heart of DevOps 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 the most mundane and error-prone tasks, enabling teams to focus on what matters: delivering business value.
You can't afford to ignore the inherent links between the three critical parts of successful software delivery: people, process, and technology. As technology continues to enable automation, more avenues will become available to harness productivity, and to unlock business value from it.
Adopting DevOps is not a choice anymore. It is the core competency you need to compete in the new digital world.
Image credit: Flickr
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.
