Without end-to-end ALM process chains, even ALM-PLM integration is no help

The growing amount of software and electronics in smart connected products means that numerous companies are thinking about how they can better integrate their PLM and ALM processes, with the aim of ensuring traceability across domain boundaries. But this means that they are actually putting the cart before the horse. In many cases, their existing ALM solutions provide only partial and inadequate support for software development, which means that ALM-PLM integration remains piecemeal.

This dilemma is nothing new as it has existed for over 20 years. For a start, only a few companies associate the term ALM with software development processes. The term was coined by system providers around the year 2000 and has undergone two major stages of development. It all began when one of the providers began to buy software products together at random. Although the individual tools did what they were supposed to do, they were never properly integrated, which meant that traceability remained an illusion. An end-to-end repository and a uniform graphical user interface were and are in this case still nowhere in sight.

This era of system silos, with its numerous company takeovers (and insolvencies), gave birth to new solutions that were web-based, used standardized repository technology, offered improved user interfaces and could be centrally managed. What was and is still lacking, however, is a clear definition of which processes and methods ALM should cover and what tools are required to do this. Although everyone is talking about ALM, they all have a different understanding of what ALM is and different expectations. The solutions range from simple bug trackers to comprehensive ALM solutions that cover all software development processes and methods. 
 

But if nobody knows exactly what ALM is, the integration of ALM and PLM runs the risk of running aground. Companies that need end-to-end support for their software development processes buy basic ALM systems that take action too late, as is the case with bug trackers, or take action early in the development process in the context of requirements management, but once again terminate their activity too early. In cases such as these, the integration efforts tie up considerable resources and distract companies from their core business. In the end, only the system integrators benefit.

The same fate awaits organizations that purchase a test management system, which knows nothing about requirements management, in the belief that they finally have an ALM solution. This means that the integration of development remains a problem yet to be solved. Under these circumstances, compliance with functional safety regulations and further development towards process maturity can only be achieved with a great deal of time and effort. 

The consequence is that, after a few years, we are left without a clear idea of how we can support software development processes with PLM to the same extent as with some of the ALM systems. These systems have found new owners, who do not yet indicate whether they have a clear strategy for merging their ALM and PLM product lines. 

Companies that want to integrate software and/or mechatronic components in their products do not, however, need point solutions from the silo era. They need an end-to-end ALM process chain that is well integrated in the PLM landscape if they are to remain competitive. Together with PROSTEP's PLM experts, BHC can provide them with the best possible support when developing this process chain and integrating ALM and PLM.