Has DevOps killed Application Lifecycle Management (ALM)? If the question makes you dizzy, you’re probably not alone; after all, it seems like just a few years ago that ALM was a fresh, new idea — and a key component of most implementations of Agile. So what happened to ALM, and why would DevOps kill it (if that’s what actually happened)? First, a little history:

Before there was ALM (at least as a formal concept) there was PLM — Product Lifecycle Management. PLM developed in the automobile industry in the 1980s, as an integrated set of practices for managing manufactured products throughout their lifecycles. PLM integrated requirements and configuration management, computer-aided design and engineering, resource planning, product support, and all of the other key elements of a product’s lifecycle. To do this required not only integration at the department and project-management levels, but also integration of product-related databases, as well as software for management, design, and administration.

In many ways, ALM is the application of the principles of PLM to software development and operations. In retrospect, this was an inevitable development; the adoption of PLM itself was to a large degree driven by the availability and use of the software tools that made it possible. It didn’t take long at all for software developers to begin to apply the same kinds of tools and practices to their own industry.

As was the case with manufacturing, many of the actual management tools were available and in use well before the idea of integrated lifecycle management became current.   It was not at all unusual for a company to use a combination of individual, non-integrated tools and ad-hoc practices for things such as requirements, design, source-code management, release, testing, bug reports, and overall project management. Many of these tools lent themselves very naturally to the idea of integration — configuration, build, and release management, requirements and design, testing, issue management, and user support — and in many ways, ALM served as the theoretical and practical framework for putting together the pieces of an already-existing puzzle.

When ALM is implemented as part of a traditional, waterfall-style software development methodology, it tends to take on the characteristics of the methodology itself. That’s not surprising — integration makes existing practices more efficient, but it doesn’t necessarily change them, and ALM is at least compatible with a relatively inflexible, top-down style of management.

But ALM also fits into the Agile framework. Agile ALM tools work well with Agile’s rapid, small-group, design, code, and test iterations, and the overall ALM philosophy itself scales down easily from the traditional corporate-management world to the much more immediate world of Agile development. More than anything, ALM’s concept of full lifecycle integration dovetails the tight development lifecycle integration that is fundamental to Agile. To a considerable degree, Application Lifecycle Management as a philosophy is built into Agile, and the implementation of true Agile ALM has been largely a matter of finding or developing the right tools, and of scaling ALM practices to Agile. Agile would not be Agile without the highly-integrated approach that it shares with ALM.

And, of course, DevOps is itself a natural outgrowth of Agile, bringing operations into the Agile model of rapid, frequent-iteration development in the hands of a relatively small team. If anything, DevOps increases the level of integration, by extending it from development into operations, which means that it actually matches the full range of ALM even more closely than does basic Agile. Operations, after all, may account for even more (frequently much more) of an application’s lifecycle than does development. DevOps is front-line engagement of the entire application lifecycle, so DevOps management is by definition Application Lifecycle Management.

In many ways, then, DevOps is the ultimate outcome of implementing ALM within the Agile framework. But from a traditional management point of view, the result does not look at all like ALM, leading some people to wonder whether there is even room for ALM in the DevOps world. If DevOps is the fulfillment of ALM as applied to Agile, why doesn’t it look that way? What is it that would even raise the question of whether DevOps has killed ALM?

ALM, as implemented in the world of traditional software development, didn’t challenge the existing division of the application lifecycle into discrete phases — it simply integrated them into an overall system of project and data management. Agile ALM, however, blurs the distinction between those phases, and to a large degree, DevOps eliminates them altogether. Without any clear distinction between the various software development/support phases, it becomes difficult at first glance to see how ALM maps into the DevOps world.

This is a natural outcome of the DevOps system of continuous delivery; it makes no sense to try to break the DevOps cycle down into discrete phases that match traditional software development phases, because it consists of small, closely-connected steps that pay no attention to traditional phase boundaries. Traditional ALM, however, is based on discrete software development phases only because it grew out of an environment where those phases were the rule. If it had developed in an Agile/DevOps world, it would not have been based on sequential, waterfall-style phases. But then again, in an Agile/DevOps world, it would not have been necessary to formulate a separate concept of Application Lifecycle Management, because it is built into DevOps.

So ALM is far from dead in the DevOps world, and ALM tools have an important place in DevOps. The nature of those tools — or at least their focus — is somewhat different, of course. In DevOps, culture is a key element that was missed in ALM, integration is even more important, and management tools need to pull together and make sense of data from a variety of discrete applications. DevOps replaces the “start and finish one phase, then start and finish the next phase” paradigm of traditional ALM with something that is much closer to “dip into the stream here, and here, and here, and monitor and control the flow without stopping it.” The process and the tools may look (and be) very different, but the basic purpose is still the same — to manage the application’s lifecycle.