By Bruce Jenkins, President, Ora Research

Siemens PLM’s agreement to acquire Polarion, a prominent provider of ALM (application lifecycle management) technology, will give the PLM vendor one of the last major pieces needed to complete what CEO Chuck Grindstaff calls its “systems-driven product development environment.” Over the past decade-plus, embedded software has become a major component of automobiles, consumer goods, medical devices, commercial aircraft, defense systems and countless other manufactured products, responsible for more and more of their performance, differentiation and customer appeal. ALM enables manufacturers to continuously integrate, verify and validate this growing software content.

With the increasingly central role of software in manufactured goods, the demarcation between product development and software development has become blurred. However, the digital toolsets that support product design and development have struggled to keep pace. PLM and ALM tools evolved independently, with each addressing different issues, work processes and engineering cultures. PLM focused on mechanical and electrical components, while ALM focused on software.

Challenges of ALM-PLM integration
For manufacturers, disconnects between ALM and PLM increase the risk of rework, delays and product safety defects, and hinder cross-domain innovation. But the effort needed to bring them together is far from trivial. For solution providers and clients alike, the central question is: What, exactly, should be the role of ALM in the context of PLM? How should the technologies be integrated to enact those roles?

First, there are substantial differences in development and lifecycle cadences between the comparatively long, slower-moving revision cycles of product components traditionally managed by PLM, and the shorter, faster-moving revision and update cycles of the software modules managed in ALM. How to link the two without imposing foreign, potentially counterproductive methods, conventions or work processes on the engineering cultures of either side?

Also, a key value proposition of many PLM—as well as ALM—vendors has been the authority and integrity of each one’s respective data repository as the “single source of truth.” Which database should serve this function in a combined world—ALM or PLM? Are there different levels of “truth”? How should this potential conflict be managed?

Finally, control-systems engineering has long been a far-downstream activity in many industries’ product development processes. Mechanical components and systems were designed first, then controls engineers were called in late in the project to design the control and feedback systems that would manage the product’s functioning. But today, the mechatronics revolution is sweeping away this outdated, no-longer-viable way of working. How should ALM be brought into a PLM framework to make it easier for engineering organizations to parallelize the development, integration and optimization of mechanical, electrical, electronics, software, control systems and other domains and disciplines?

Five levels of ALM-PLM integration
To begin addressing these issues, Siemens PLM will add the Polarion offerings to its Teamcenter software. Grindstaff says Polarion’s technology will integrate software specification, development, testing and simulation further into Siemens’ “systems-driven product development environment.”

Polarion CEO Frank Schroeder notes the acquisition caps two years in which the companies have already been working together. Earlier in 2015, Polarion released the first version of the Polarion ALM-Siemens Teamcenter Integration, which supports levels 1, 2 and 3 of Polarion’s five-level approach to integrating ALM and PLM:

• Level 1: Link & Trace—In Polarion ALM-PLM integration, the capability of creating a physical or logical relationship between ALM and PLM data assets is called a Link. Trace denotes the ability to automatically navigate this relationship.
• Level 2: Change & Propagate—ALM-PLM manages the impact of design changes down the development and production chain, and vice-versa. It also enables a failure of the related hardware or software components to be traced back to the elements that could have caused such failure.
• Level 3: Act & Communicate—This achieves the integration of processes such as task assignment, progress control and project management.
• Level 4: Align & Unify—Software concepts such as releases, branches, baselines and parameters are aligned to their product-specific counterparts to establish unique, combined configurations. This level also supports unification of the user experience (UX), allowing users to work in their preferred and familiar development tools.
• Level 5: Collaborate & Report—Engineers from multiple disciplines are able to collaborate and merge their areas of expertise to develop an optimal, multi-system solution. Process improvements are driven by metrics dashboards that provide a unified view of project status and enable users to quickly identify bottlenecks and issues, and implement effective mid-course corrections.

For engineering organizations, key business benefits promised by ALM-PLM integration include:

• Visibility across all assets—to improve search and locate information.
• Accurately linking firmware with hardware—to avoid errors, avoid damage costs and avoid reputation risk.
• Traceability of assets for engineers in all lifecycle phases—to reduce time wasted and enable effective collaboration across globally distributed units.
• Support for maintenance, repair and operations (MRO)—to quickly locate parts and manage defect fixes, and reduce inoperative time of broken products.