Application Lifecycle Management (ALM) and PLM Integration: Ending a Long-time Debate?
ALM (Application Lifecycle Management) Integration Addresses Product Failures
Today virtually every industry’s products are software-driven, making the integration of ALM with PLM an important priority (VDC Research report). However, following a non-integrated approach has demonstrated a negative economic impact and set new records for product failures: Almost 64 million cars were recalled in 2015 due to embedded software issues. Segway recalled all of its electric scooters because a software glitch causing riders to fall off and get injured. Bosch recalled fire alarm systems that fail to sound an alarm when fire occurs. The FDA reported that software failures are responsible for 24% of all medical device recalls, the list goes on and on.
Getting It Right!
There are many aspects of an ALM-PLM integration you should consider, but none are more important than:
1) User experience and culture differences:
It’s unlikely that ALM and PLM will merge into a “one-model-fits-all” paradigm due to the significant differences in PLM and ALM semantics, culture, processes and data representations. These are differences that engineers from both sides have clearly expressed; “…don’t migrate, duplicate or even aggregate data from applications but maintain meaningful relationships across these data”, “don’t force me to migrate to PLM concepts that are meaningless for my domain”, “don’t migrate local engineering workflows but orchestrate workflows”, “don’t imply I should switch tools, give me the required data and relationship authoring/viewing functions from within my applications”, “don’t overwhelm me with data that irrelevant to me, but expose the relevant viewpoints for my domain”, “don’t suggest manually creating and maintaining millions of relationships between artifacts, you should capture and automatically create relationships based on my activities.”
What does it all mean? Point to point integrations and other common PLM-ALM data model concepts have prevented user adoption. Instead, it has to support interoperability schemes rather than integration scenarios where each side of the user experience is minimally altered.
2) The inherent complexity of embedded software development:
It’s extremely difficult to make complex processes perfect, so for a while integrating embedded software development tool and processes may have some limitations. Its complexity starts with millions of lines of code (cars have about 10 million lines of code!) being built using millions of keystrokes and unfortunately infallibility is not part of the human nature. Then it gets amplified as embedded software has to deal with functions distributed across real time systems where behaviors are extremely difficult to systematically predict and enforce.
Can we significantly improve that? Yes, but first there has to be some serious reconciliation of software engineering data and processes using architecture definition and model-driven product development methodologies. Here software decisions, from inception to end-of-life, can be made in context with all other engineering domain’s deliverables.
How Siemens PLM Software is Addressing the Challenge
It started with capital investments in Polarion and Electric Cloud. As strategic ALM partners, Polarion and Electric Cloud worked with Siemens PLM on multiple PLM-ALM use cases that span requirements interoperability, closed-loop embedded software development, integrated change orchestration and continuous integration of software deliveries. Since then our relationship with Polarion has grown even closer and on January 14th 2016, the Siemens acquisition of Polarion Software was finalized and Polarion has become an entity of Siemens PLM Software. The combined company will deliver even greater value, benefits, and capabilities for our customers.
How is our approach different from what other companies have pursued? First, it supports a multi-domain lifecycle integration framework where data federation and process orchestration capabilities efficiently respond to the expected user experience. Web technologies (RDF, HTTP, REST) provide search, view and edit capabilities on remote data. For example, it doesn’t require an ALM user to switch to PLM to conduct a search, or view and modify data residing in the Teamcenter PLM environment, or vice-versa, all controlled using data security access standards. Similarly it understands the dependencies of software data with other product data needed to intelligently assess the impact of changes. Traceability across ALM and PLM enables users to create and view linkages, as well as map data in context of particular product configurations.
Next, embedded software development has inherent cross-functional requirements, so software engineers can’t develop the expected system behavior without considering the dependencies with other product areas. Embedded software development presents substantial challenges to developers due to the extreme diversity of hardware components and system multi-physics the software has to work with.
For instance multiple algorithms styles must be employed to address signal processing, communication and real-time controls which require a closed-loop verification with electrical and electronics design/development. If not properly modeled in the context of the overall product early in the process the distributed nature of product functions and their interdependencies across many sub-systems could result in unpredictable and chaotic effects on the overall product behavior. These are some of the considerations driving our PLM-ALM use cases and solutions implemented using our architecture modeling, Imagine. Lab simulation and analysis, as well as a number of other modeling and simulation capabilities that can be leveraged from system inception through software implementation, testing and verification, all in the context of the overall product definition.
My key takeaway?
PLM and ALM integration is now happening faster at the process level with a closed-loop approach to systems engineering. In that context, expect to hear terms like “Product Line Engineering” and “Architecture Driven Model Based Product Development” a lot more frequently.
Stay tuned!
About the blogger: Pascal Vera is the product manager/evangelist for Mechatronics and Systems Driven Product Development initiatives and strategic planning.
