The whole idea of ALM, Application Lifecycle Management, is to take a holistic, comprehensive approach to application development. It's not a new concept, but as tools and techniques have improved over the years, ALM has been garnering more and more attention. After all, the more care and attention you give to the development process as a whole, the more likely you are to identify problems, fix bugs, complete projects on time, and keep the various stakeholders happy.
Fundamentally, Application Lifecycle Management will never change; it will always involve certain key capabilities including managing requirements, change management, configuration management, quality control and build control. But given these constants, how has ALM, and the way software companies approach managing the application lifecycle, changed over the years?
People, process and tools are the key cornerstones of ALM, and one obvious change over the past few years has been the process used. An Agile methodology is now the emerging process for moving through the lifecycle, but that's not really news to enterprise development community.
A more disruptive change is how ALM has been expanding both eastward and westward. While Agile always promoted the idea of continuous integration, ALM approaches are embracing that idea beyond development and crossing the border into operations. Progressive environments are breaking down the walls between development and operations, bringing them together into a unified DevOps team that can both continuously integrate and continuously deploy. No longer can development teams simply say to operations: "we did it to test, and we satisfied QA, so now the deployment problems are your worry." With greater automation and better lines of communication, organizations are saving money while reducing the friction between the development and runtime management of applications.
And ALM strategies and techniques are also expanding in the opposite direction to involve activities that occur long before application development even begins. ALM tools and participants are playing an active role in strategic portfolio decisions, while working to map decisions about what should get developed and what needs to get developed into the development process early on.
And of course, as ALM evolves, so has the tooling. One of the tenets of ALM is to promote a holistic approach to all aspects of development, yet the tooling has historically been highly fragmented. From developing user stories, to registering bugs, to doing the application development and design, there is typically a plethora of different tools that get used, with each of those tools poorly integrated 'at the glass', if they are even integrated together at all.
Significant steps have been taken in the industry to try and deliver the "One Tool to Rule Them All" in terms of ALM, and great strides have been made in developing tools that can synchronize everything from requirements gathering to scheduling deployments to bug tracking. But of course, few organizations ever settle on one tool, so to help with the holistic integration of more heterogeneous environments, standards, such as the Open Services for Lifecycle Collaboration, OSLC, have emerged, defining a set of standards that allow different software products to broadly integrate with each other.
So while the core tenets of Application Lifecycle Management remain the same, the ALM landscape has indeed seen some disruptive changes over the past several years. A greater focus on automation, the adoption of a more Agile approach to the process, the expansion of ALM to cover both DevOps on the back end and strategic product based decisions on the front end, and finally the delivery of tools that make working through the process easier are all important ways that the enterprise development community's approach to ALM is changing for the better.