The boundaries of what we mean by “application life-cycle management” continue to stretch and tear, like Arnold Schwarzenegger stuffed into a toddler’s jumper. While we still have to be careful about defining ALM so broadly that it’s no longer a meaningful category, it’s clear that the traditional list of functionality ― task management, build management, requirements, management, etc., etc.― is at least a couple of sizes too small. In fact, the amount of overlap with product life-cycle management (PLM) is so great that it may be increasingly hard to discuss them separately. They may be surprised to find how closely related they are, like Schwarzenegger and Danny DeVito in Twins, but the connection is definitely there.

Even without PLM tugging at it, ALM is stretching to fit the real development processes it ostensibly manages. As development teams are not indifferent to what happens after they hand off their code to the operations people, ALM has been expanding to include more elements of release and deployment. ALM can’t accommodate everything ops-related without ripping apart at the seams, but it does need some alterations.

PLM is a whole different consideration. Rather than expanding the definition of ALM, it adds another layer on top of it ― primarily to accommodate the realities of embedding software in other products (cars, refrigerators, medical devices, etc.). Because the number of these hybrid hardware/software products expands daily, the urgency of figuring out how ALM and PLM fit together as part of a common ensemble has been increasing.