11/2/2015 | 4 MINUTE READ

Introducing Application Lifecycle Management

Facebook Share Icon LinkedIn Share Icon Twitter Share Icon Share by EMail icon Print Icon

PLM for managing software is not PLM. It’s ALM, application lifecycle management.


Facebook Share Icon LinkedIn Share Icon Twitter Share Icon Share by EMail icon Print Icon

Blame mechatronics. No, even before that: Blame the increase in software in today’s vehicles, whether firmware, application software, embedded systems, or mechatronics. “Software is quickly surpassing hardware’s dominance in product development, particularly within technologically complex products and industries, such as automotive, aerospace/defense, and medical device manufacturing,” according to Stefano Rizzo, senior vice president strategy and business development for Polarion Software (polarion.com).

Automakers using product lifecycle management (PLM) for managing the lifecycles of vehicles cannot be faulted for turning to these same systems for software development. It makes sense to use something PLM-like to hasten time-to-market, improve the efficiency of software development, solidify the collaboration between everyone involved in software development (including requirements specification, coding, testing, deployment, and continual software maintenance), and meet regulatory requirements.

One problem: PLM is not efficient at managing software development. Says Michael Azoff, principal analyst at the London-based Ovum Consulting (ovum.com), “In product development, software changes are far more frequent than hardware changes and keeping track of which firmware belongs to which hardware component turns into a monumental exercise in version tracking and traceability.”

Meet ALM, application lifecycle management.

ALM, says Azoff, is “the process by which information technology and software development organizations create, deploy, and operate software over its full lifecycle.” While product design for physical things and software things is increasingly computerized, the processes are different. Product development, says Rizzo, typically follows a “cascading waterfall approach”: product is conceived based on information from the marketplace, which is translated into customer requirements, and then into technical specifications; designed through a series of steps involving creation, refinement, testing, and validation; produced using various manufacturing methods; and then serviced (including repair, maintenance, and waste management), which is increasingly being considered early in product development.

Software development used to follow the waterfall approach, says Rizzo, but now it includes application project and portfolio management, project inception and requirements gathering, requirements management, design and use-case analysis, coding, testing and quality assurance, build release and deployment, and ongoing software maintenance. Software development is very much an iterative process consisting of “short, rapid `sprints’ with requirements changing frequently and many ongoing revisions,” says Rizzo.

Granted, “lean manufacturing” methodologies for developing physical products are similar to the “agile development” methodologies used in software development. And PLM does an excellent job at managing product-related workflows, specifications, designs, and versions, but it falls apart doing the same for software. Software development is simply too complex for PLM.

Other differences exist. PLM focuses on physical, manufactured “parts.” ALM focuses on software files and items (e.g., requirement document, software code, a test case) and changes to those files and items. Second, PLM is hardly browser based. ALM is, which enhances collaboration, development, test, and deployment. Says Rizzo, “It is not possible today for a user to perform a detailed 3D rendering and bill of materials with traceability links of a vehicle’s transmission displayed in China from a server located in Stuttgart.”

Next, PLM traceability focuses on the decomposition of a complete system; that is, a part or component as it relates to a subassembly, which relates to the finished (assembled) product. In ALM, traceability focuses on the links between files and items, even if they exist in different phases. For instance, says Rizzo, “A change to a requirement may impact a line of code, or require a new test case to be developed to validate the new requirement.” A problem occurs where PLM considers software a “part,” but does not consider the details in the lifecycle development of that chunk of software. This is especially true in mechatronics. “Software quality issues lie at the bottom of many costly product failures and may drive a product recall. And yet product engineers with their PLM tools lack the ability to get to the bottom of software related issues,” he continues. 

Mechatronics is forcing the need for both PLM and ALM, as well as the need to have these systems work together. The PLM vendors have taken notice. For example, one of the goals of the partnership between Siemens PLM Software and Polarion is the real-time synchronization of software, electrical, and mechanical development. The first product as a result became available in June: version 1 of the Polarion Connector for Teamcenter, which works with Polarion ALM 2015 and Teamcenter 10.1.4.

For $890, the connector permits integrated requirements management (such as the bidirectional referencing of software and product requirements), traceability at all levels (with no data duplication in either PLM or ALM), integrated software change management across both PLM and ALM, and closed-loop embedded systems and software. Benefits of this approach, explains Vera Sparre, Polarion’s director of global marketing, include increased productivity “through closed-loop software and product development from inception to end-of-life”; better quality assurance through “better modeling and simulation as part of model-based systems engineering for continuous software validation”; better “cost containment” through “effective software delivery and reuse, as well as optimization of software design decisions in context”; and better “scalability due to the proven enterprise infrastructure that requires minimal organizational adjustment.”

The integration of PLM and ALM winds up being a more-encompassing realization of what Siemens PLM calls systems driven product development (SDPD), resulting in a variety of benefits for both manufacturers and consumers. At the very least, according to Siemens PLM, ALM users no longer have to switch to PLM to search, view, and modify data residing in Teamcenter PLM, or vice versa. 

Hand holding a crystal ball

We’d rather send you $15 than rely on our crystal ball…

It’s Capital Spending Survey season and the manufacturing industry is counting on you to participate! Odds are that you received our 5-minute Metalworking survey from Automotive Design and Production in your mail or email. Fill it out and we’ll email you $15 to exchange for your choice of gift card or charitable donation. Are you in the U.S. and not sure you received the survey? Contact us to access it.

Help us inform the industry and everybody benefits.


  • What's Blocking The Move From 2D to 3D?

    CAD software vendors and pundits have long been predicting 'everyone' will soon be on 3D CAD. Why hasn't that happened?

  • Top 10 Intranet Deployment Considerations

    Intranets, those mostly private networks with the same look-and-feel as the World Wide Web, were virtually non-existent in Fortune 500 companies four years ago. Before you rush right out to deploy one, here are some things to think about.

  • What you see in PRODUCT VISUALIZATION is what you get

    Visualization is an affordable technology for quickly and realistically depicting data visually. Besides being great for marketing, visualization saves prototyping time and expense, and it lets users see physical conditions not obvious in 2D or 2 1/2 D.