The term PLM has been around for about 15 years (see also my article on “PDM and PLM”), and a few years ago a new term, application lifecycle management or ALM, has started to emerge.

What is ALM and what is the difference to PLM, one might wonder. A very cursory explanation could be that ALM is to application software what PLM is to mechanical products. Or, in a few more words, ALM systems manage all aspects of the life cycle of application software, from initial inception to final obsolescence.

But wait, what about products that contain both hardware and software? Many products today are comprised of mechanical, electrical and electronic components as well as software. In fact, product complexity and software content in products has been increasing exponentially. From 2000 to 2013 the content of software per car, just to use one example, increased ten-fold from 1 million lines of code to 10 million lines of code. In the same time frame, the cost of software increased from 2% to 13% per car. And the projection is that by 2020, i.e. in just five years, there will be about 200 – 300 million lines of code per car (Source: ARTEMIS, 2nd IEEE Conference on Automotive Electronics, An Overview). And other products are following a very similar trend.

Now the problem is not only the amount of software per product, but also the increasing integration of hardware and software. Let’s continue looking at what is happening with cars: A few years ago cars started to have on-board navigation and entertainment systems. While complex in themselves, they require very little integration with other systems in the car, except maybe some buttons on the steering wheel and the loudspeakers. But now car manufacturers are starting to talk about, and some even already offer electronic driver assistance systems, such as lane departure warning systems, automatic lane change assistants, collision detection and avoidance systems, parking assistants, and even completely self-driving cars. The software in these cars now needs to integrate with and control the steering, the breaks, the accelerator, the transmission and many other mechanical systems.

But with increasing product complexity and integration also comes the need to manage, coordinate and integrate the development of the different systems and their hardware and software components. And that’s where PLM and ALM come into the picture and, unfortunately, probably lag behind the needs of the industry.

Today these two applications are separate and offer distinct functionalities. PLM systems focus largely on the development of mechanical, electrical and electronic products and components and offer very little functionality to support software development. ALM systems on the other hand focus on the development of software and offer capabilities such as requirements management, software architecture, computer programming, software testing, software maintenance, change management, project management, and release management, but offer little to nothing to support hardware development.

As a result, companies that develop products containing software and hardware usually need both a PLM and ALM system today. Their challenge then is developing integrated products with two applications that are often not well integrated and to decide what function should be performed in which system. For example, where should changes be initiated and processed that affect both hardware and software? And where should requirements be defined? In the PLM system, the ALM system, or in both? If it is done in the PLM system, how are requirements connected to software modules? If it is done in the ALM system, how are requirements connected to hardware components? And if it is done in both, how are high-level system requirements defined and pushed down to functional requirements in both the PLM and ALM system?

The solution today is to define solid practices and processes and a good strategy on what application does what specifically, as well as create a good integration between the PLM and ALM systems to ensure required data can flow as seamlessly as possible between the two systems.