GOING ALL in with DEVOPS by Andrew Agerbak, Kaj Burchardi, Steven Kok, Fabrice Lebegue, and Christian N
Total Page:16
File Type:pdf, Size:1020Kb
GOING ALL IN WITH DEVOPS By Andrew Agerbak, Kaj Burchardi, Steven Kok, Fabrice Lebegue, and Christian N. Schmid or too many companies, moving to In many cases, there is. Agile does a good Fagile software development is like job of breaking down silos early in the soft- finding the perfect new strain of grass ware development process. But it can seed—after months of searching—and achieve only so much on its own. To turn then planting the new seeds in your old themselves into digitally ready competitors, backyard. Your lawn may ultimately look a companies have to rethink the entire soft- little better, but it will take longer and the ware development life cycle. They need results won’t be as great as they would be agile, but they also need DevOps. if you had first removed the hidden tree roots, put in new soil, and rethought the DevOps is an approach that integrates criti- irrigation system. cal late-stage activities—like testing and deployment planning—into the code- Many mainstream companies—in financial writing part of software development. (See services, health care, manufacturing, con- Exhibit 1.) With its emphasis on running sumer packaged goods, and other indus- multiple activities in parallel and on multi- tries—have felt compelled to give agile soft- functional teams, DevOps represents a ware development a try. And they have break from the old “waterfall” model, in waited expectantly for the benefits. In theo- which planning, writing, testing, and de- ry, agile’s assignment of a business leader ploying code were discrete steps managed to development teams ensures that the by separate departments. most important software changes get done first, and its emphasis on short coding While many software companies use some sprints ensures that the changes are imple- form of the continuous software develop- mented quickly. The fact that the quick part ment and release that are the hallmark of doesn’t always happen has been discourag- DevOps, the approach (which continues to ing. It has some agile newcomers wonder- evolve and is starting to be referred to as ing if there’s something they’re missing. DevOps 2.0 or BizDevOps by some of its Exhibit 1 | Where Agile and DevOps Fit in the Software Development Life Cycle Plan Code Build Test Deploy Release Operate Monitor AGILE Business units Integrated business • Teams “own” and are responsible for development teams a software-based product or service IT development DEVOPS Continuous • Daily “builds” of error-free software Application integration development • Automated testing Continuous • Ability to update applications Application delivery automatically across environments maintenance IT operations Continuous • Self-service provisioning of hardware deployment • Automated releases of new software IT operations Continuous monitoring • Applications self-repair and autonomic operations • Capacity adjusted automatically WHO DOES THE WORK Standardized and automated • Virtualization enables server and storage constraints to be addressed automatically IT infrastructure infrastructure management • Modular architecture allows services to be provisioned quickly and cheaply Source: BCG analysis. more advanced practitioners) is a lot newer Today, virtualization makes computing and outside the technology and internet services storage capacity available with less opera- industries. Some traditional companies, tional complexity than before and at far notably in financial services, have some lower cost. But we still see companies tak- DevOps pieces in place, such as automated ing a month and 50-plus emails just to testing and mechanisms for provisioning provision hardware and gather all the nec- hardware quickly. (See “Leaner, Faster, and essary permissions. Better with DevOps,” BCG article, March 2017.) But the scope of these practices is Likewise, a control requiring multiple go- limited. The companies haven’t made the live approvals for new software may have overarching changes that would allow them been justified when there were only a few to capture DevOps’ full range of benefits. software updates a year and each one in- volved a critical part of a monolithic sys- tem. But it shouldn’t require two dozen Making DevOps Work people to approve a minor tweak—like To get the most out of DevOps, companies changing the color of the screen users see. must make changes in controls and gover- nance, IT organization roles, and operating With software now a key way of addressing models. fast-changing business and customer needs, the prolonged delays caused by controls Rethink controls and governance. Most big that have become irrelevant put companies companies’ approach to developing and at a fundamental competitive disadvan- releasing software reflects controls they put tage. The delays can pose a reputational in place years ago to maintain quality and risk and even a survival risk if a company avoid costly mistakes. The controls may is the target of a cyberattack. (See “Devel- have made sense at the outset. But as the op a Cybersecurity Strategy as If Your Or- pace of technological change has accelerat- ganization’s Existence Depends on It,” Oc- ed, the controls have lost their relevance. tober 2017.) Now they’re just obstacles. Governance is another area that requires For instance, a control about infrastructure adjustments in the move to DevOps. This provisioning—one of the hurdles that must includes adopting new approaches to fund- be surmounted before a development team ing. In agile, funding isn’t allocated on a can begin its work—may have been imple- project basis: for a set period of time, mented in the days before virtualization. against a defined set of deliverables. In- The Boston Consulting Group | Going All In with DevOps 2 stead, funding is allocated to critical “prod- teams, which are expected to make the ucts”—like a mutual fund company’s “my fixes. There is no one farther down the line account” function or a retailer’s order-and- who would even think of fixing the code, ship system—that require the attention of and no possibility of different departments teams for many months or even years. touching the same code simultaneously DevOps adds complexity by forcing compa- and working at cross-purposes. nies to figure out how to allocate some ap- plication maintenance and infrastructure Ultimately, the best test of governance costs within the product funding paradigm. practices is cycle time. If companies can substantially reduce the time between Another area where DevOps should trigger when they plan software and when they re- a governance change is in the decision lease it in a reliable, high-quality form, that rights related to cloud solutions. In the is a sign that their governance processes past, these decision rights belonged to the are working and that they have the techni- IT organization, and no one questioned cal capabilities they need. that. But that’s changing as more business units create software directly using cloud- Redefine the role of the CIO and the IT based tools. organization. If DevOps is to succeed, there must be changes—some subtle, some more We saw questions about such decision dramatic—in the role of the chief informa- rights at a company where digital product tion officer and the information technology development teams were pushing for direct organization. In companies that adopt agile access to an Amazon Web Services account, models, the specifications for new soft- and the IT operations group, concerned ware—and the coding work itself—become about standardization and security, was re- the implicit responsibility of business units. sisting. In truth, there is no single right an- If this relieves the CIO of responsibility for swer to the question of where the decision individual lines of code, in most cases he or rights should lie, for this company or any she still shoulders the larger burden of other. But it is an issue that must be tack- quality. That is, the CIO must still recruit led in DevOps, which redraws the boundar- and train software developers. He or she ies of software development along multiple must also put in place a better delivery dimensions. model, one that includes an operating environment—standards, services, process- DevOps should also prompt a change in es, tools, and infrastructure—that allows how companies deal with buggy software. developers to maximize their productivity. At companies that haven’t fully adopted The CIO must also front-load more activi- DevOps, there isn’t a “you built it, you own ties in the software development life cycle. it” governance philosophy. Instead, if an issue arises involving software that has The term of art for this sort of front-loading been released, IT support teams report it is the “shift left,” referring to how one through a ticket system (such as Service- would diagram various activities on a soft- Now), and the issue becomes the responsi- ware development life cycle chart. In bility of an application maintenance team. DevOps, technical staff that would once But the original developer of the code, hav- have sat in the IT operations function— ing gotten wind of a problem, may go back whose work kicks in later—are moved into in and try to fix it. The net result is that the product development teams, where they sometimes both the development and have a say in how the code is built. There maintenance teams end up working on the should also be input early on from those re- same software, at the same time, resulting sponsible for a company’s data architecture in inconsistencies, integration problems, and cybersecurity. The shift left of activity and stability issues. By contrast, at compa- and expertise is one way all the code that’s nies that adopt DevOps practices, issues being created—often in many different with released software automatically regis- business units—can get to market quickly ter on the backlog of the development and with the necessary level of security.