The first thing to address here is how to define Application Lifecycle Management. ALM was born in some sense from the vendor community. Like BSM was born at BMC, a lot of contribution to ALM came from Borland and Microsoft, as part of the development tools and platforms they were creating. As a result the focus of ALM was on the software code part of the lifecycle, and development up to the point of the build and deployment process. Then, it gets passed over to operations management, going into ITIL and different disciplines.
That is something that limits ALM, making it incomplete, creating a lot of potential issues. Why? When we deploy, we don’t just deploy the software code, we are deploying the environment – the software infrastructure pieces and then the application code on top of it. For the application lifecycle, we have to look at it in the context of the whole environment lifecycle. In a sense, ALM should be expanded to ELM so that this process can produce the quality and speed that is expected from software engineering.
Look at the Entire Lifecycle
The first aspect to look at is the entire lifecycle. Referring to lifecycle, this starts at requirements, definition, design, and architecture planning and then goes to development testing and finally deployment. But it doesn’t stop in deployment. From here, you are dealing with the world of operations. ALM should be very tightly connected to this world, and so lifecycle comes to mean the operation of the software system when it is in production as well.
Today if you look at most of the tool vendors, ALM has one set of vendors, tools and teams. But for operations there are different tools, different teams, different disciplines. While DevOps is now trying to connect development and operations, for ALM tools and techniques we need to have a closer connection and integration into the operations world. This is one of the biggest gaps, particularly when we speak about ALM in today’s world, with increasing pace of change and complexity, and so increasing the risk of failure for the current ALM practice.
Agile Practices Drive ALM Toolsets
It is important to look at the trends in the industry that impact ALM practices. One is the pace of development. Agile development requires both to change the way the organization is structured, the processes and tools that are used, and definitely requires a very different ALM approach than a traditional waterfall model, where you release once in a certain period based on well defined, planned-ahead releases from a roadmap charting several years ahead. Rather, when you work in shorter cycles, introducing dynamic changes, many dynamic requirements enter your environment and the way you handle it should be very different.
There is a lot of information available on agile development practices and tools, however the question remains, how do you handle the entire lifecycle in agile conditions and how do you integrate your process when you start to work in an agile approach? It is not just development that does agile, it is also the operations side. Operations for an agile world is significantly less explored. There is less information about it, less tools, less practices, less experience which creates a conflict.
The pace of change is one thing that definitely impacts ALM. Look what processes you have in operations. You still have the same ITIL and COBIT that don’t speak about agile. The development side of ALM knows how to go agile, but operations does not. So ALM still gets stuck in the operations side.
Complexity of Environments
The complexity
