{"id":2681,"date":"2016-07-12T13:01:49","date_gmt":"2016-07-12T20:01:49","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Teamcenter-Blog\/Application-amp-Product-Lifecycle-Management-An-integration-path\/ba-p\/355342"},"modified":"2026-03-26T08:54:22","modified_gmt":"2026-03-26T12:54:22","slug":"application-product-lifecycle-management-an-integration-path","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/teamcenter\/application-product-lifecycle-management-an-integration-path\/","title":{"rendered":"Application & Product Lifecycle Management: An Integration Path"},"content":{"rendered":"

If you\u2019ve noticed a higher number of recalls<\/span><\/a> making the news, you aren\u2019t alone: manufacturers are also noticing it. Many recalls are due to software issues which are the result of the increased product complexity and the combination of software and hardware. This trend isn\u2019t going away, so what can companies do to reduce or prevent product defects that lead to recalls?<\/p>\n

In my series about integrating application lifecycle management<\/a> (ALM) with product lifecycle management (PLM), I explore why this rapid advance of software-enabled products is contributing to increased product recalls. In part one<\/a>, I explained why companies can no longer use only ALM or only PLM to manage increased product complexity.<\/p>\n

Here, I\u2019ll discuss why ALM integration with PLM is the best solution to manage product complexity and the five factors companies must include to achieve full ALM and PLM integration.<\/p>\n

In today\u2019s complex product development environments, ALM and PLM play important roles in the development process. Each has its strengths and weaknesses, but each complements the other well.<\/p>\n

PLM systems manage, link and relate objects or information as parts. ALM manages software files and relates information based on those files<\/a>; this includes software code, change requests, builds, test cases and comments.<\/p>\n

Software exists in the PLM world as a single part, but the level of management frequently ends there. This is because PLM systems typically don\u2019t provide configuration management for software files and any changes made to them throughout the software lifecycle.<\/p>\n

Hardware and software development teams frequently employ different development methodologies. Hardware teams frequently employ a \u201cV-model\u201d, Waterfall or Spiral methodology where content it defined and processes for verification and validation are executed somewhat sequentially. Software teams frequently employ an Agile<\/a> methodology takes advantage of varying requirements and supports the rapid delivery of incremental features.<\/p>\n

Hardware and software also have different lifecycles. A product\u2019s lifecycle can span several years with relatively infrequent modifications that can take a few months to over a year; maintenance and service cycles can last for many years. The software lifecycle typically spans several months to a couple of years. It includes frequent modification cycles that last a few days or weeks; the maintenance and service cycle may only last a few years. Because there’s such a difference, hardware and software components must be linked and managed to ensure long-term compatability \u2013 which effective ALM and PLM integration does.<\/p>\n

PLM deals with hundreds or thousands of product options or variants, so configuration management<\/a> is an extremely complex undertaking. In the ALM world of software management, there are generally only a few branches or versions to configure. When hardware and software are combined there are so many variants and options that it\u2019s difficult to understand, manage and verify them all without good ALM integration with PLM.<\/p>\n

A good example of this is when a salesperson I know purchased a new vehicle. A warning indicator started chiming after a few days; it was detecting the failure of a vehicle option that wasn\u2019t even installed on his vehicle. The software on his vehicle detected an error code on the electrical control unit (electronics) because the wire-harness connector<\/a> (electrical) wasn\u2019t attached to the hardware for that option. The vehicle\u2019s product configuration hadn\u2019t been fully understood, tested and verified. Had the ALM and PLM processes been fully integrated, all viable hardware and software configurations could\u2019ve been understood and validated, thus eliminating this error.<\/p>\n

How to Implement True ALM Integration with PLM<\/h3>\n

What\u2019s necessary for a truly integrated ALM and PLM solution that helps companies reduce or prevent product defects? Effectively embedding software in any product requires ALM integration with PLM rather than trying to expand each solution\u2019s definition to include the other\u2019s capabilities.<\/p>\n

To efficiently develop embedded systems, a truly integrated solution can:<\/p>\n