Available online at www.sciencedirect.

com

ScienceDirect
Procedia Technology 26 (2016) 405 – 412

3rd International Conference on System-integrated Intelligence: New Challenges for Product and
Production Engineering, SysInt 2016

A critical view on PLM/ALM convergence in practice and research

Andreas Deutera*, Stefano Rizzob
a
OWL University of Applied Sciences, Liebigstr 87, 32657 Lemgo, Germany
b
Polarion Software GmbH, Kesselstr 19, 70327 Stuttgart, Germany

Abstract

The Internet of Things (IoT) is the main driver for industrial smart products produced by an increasing number of manufacturers.
The overall functionality of smart products is a combination of mechanical, electrical/electronic functions (hardware functions)
and software functions. For hardware and software there are different lifecycle models: Product lifecycle management (PLM)
focuses on hardware, application lifecycle management (ALM) focuses on software. Smart products force manufacturers to
converge both lifecycle models step by step. Although seemingly important, the research community leaves this innovative area
mostly up to the PLM tool vendors and the ALM tool vendors, resulting in them driving the convergence.
This paper points out the mismatch between industry and academia regarding the PLM/ALM convergence. We encourage academia
to increase research activities and we propose potential research topics.

©
© 2016
2016TheTheAuthors.
Authors.Published
Publishedby by
Elsevier Ltd.Ltd.
Elsevier This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
Peer-reviewunder
Peer-review underresponsibility
responsibility
of of
thethe organizing
organizing committee
committee of SysInt
of SysInt 2016 2016.

Keywords: PLM; ALM; OSLC

The Internet of Things is changing the world. More and more physical items are turned into smart products. Smart
products are connected to each other creating completely new business scenarios. For example, they can be updated
over the air, they can self-diagnose and send repair/replacement alerts before they break down, or they create value to
the customer by offering and activating on-demand features. Smart products are intelligent. In order to fulfill all these
scenarios smart products are not pure physical items anymore. They have software inside.

* Corresponding author. Tel.: +49-5261-702-5305; fax: +49-5261-702-85305.

E-mail address: andreas.deuter@hs-owl.de

2212-0173 © 2016 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).
Peer-review under responsibility of the organizing committee of SysInt 2016
doi:10.1016/j.protcy.2016.08.052
406 Andreas Deuter and Stefano Rizzo / Procedia Technology 26 (2016) 405 – 412

These trends challenge the manufacturers of smart products. Traditionally, they have been and some of them still
are, manufacturers of purely physical items. In order to design, develop, produce and service physical items
manufacturers implemented hardware related lifecycle models, called product lifecycle management (PLM). PLM is
defined as the business activity of managing a company’s products across their entire lifecycles in the most effective
way [1]. However, the software within the smart products is not managed by PLM.
The software is managed by a different lifecycle model called application lifecycle management (ALM). ALM
“indicates the coordination of activities and the management of artefacts (e.g., requirements, source code, test cases)
during the software product’s lifecycle” [2].
It is claimed that PLM and ALM are processes not products [3,4]. It is true that implementing PLM/ALM requires
a clear process definition. However, manufacturers can only claim that they have implemented PLM or ALM, if they
have a PLM tool or an ALM tool in place and are improving their usage continuously.
Although to some extent similar, ALM and PLM are two different lifecycle models. Therefore, both ALM and
PLM are required when developing a smart product. Two lifecycle models, and two different tool chains, are used for
the same product. This is inefficient and leads to inconsistent data management, insufficient transparency about results
achieved, incomplete documentation and other disadvantageous points [3].
To overcome these drawbacks, both lifecycle models should converged. PLM tool vendors and ALM tool vendors
have started this convergence in practice. However, the research community leaves this innovative area to the tool
vendors.
In this paper we point out the mismatch between the research activities and the industry activities regarding
PLM/ALM convergence. In section 2 we explain briefly PLM and ALM. In section 3 and 4 we summarize related
research work and related industry work. We finish with proposals for potential research topics and a concluding
discussion.

1. PLM and ALM

The management paths of the hardware development and the software development diverged in the last decades.
The hardware path created PLM, the software path created ALM. As both models address the general product
engineering process from the idea of a product to its delivery, they are to some extent similar. For example, they
consist of dedicated phases, incorporate workflows and link components to each other. Typical phases of both process
models are defined in [5] (Table 1 and Table 2).

Table 1. PLM Phases [5]

Phase Description
1. Conceive Information is gathered from the marketplace, customer requirements are determined
and the product is imagined and technical specifications based on this information are
created.
2. Design The product’s initial design is created, refined, tested and validated using tools such as
CAD. This step involves a number of engineering disciplines including mechanical,
electrical, electronic and software (embedded), as well as domain specific expertise
i.e., automotive engineering.
3. Realize At this stage, the product design is complete and the manufacturing method is
determined, with this phase addressing tool design, analysis, simulation, and
ergonomic analysis.
4. Service In this final phase of the product lifecycle, we enter the service phase, which may
involve repair and maintenance, waste management and end of life (disposal,
destruction) of the product.
 Andreas Deuter and Stefano Rizzo / Procedia Technology 26 (2016) 405 – 412 407

Table 2. ALM Phases [5]

Phase
1. Application project
and portfolio management
2. Project inception
and requirements gathering
3. Requirements management
4. Design and use-case analysis
5. Coding
6. Testing & QA
7. Build release, deploy
8. Application performance
Description
An investment analysis is performed and business case developed prior to the
inception of a software project.
Marketplace information is gathered, potential users/customers of the application are
interviewed, and data is gathered to form documented requirements.
As requirements evolve or change, the requirements document also must evolve to
analyze impact on development schedules, delivery date, resources, etc.
The underlying architecture of the software code is set out, and various use-cases are
developed to model the user’s possible interactions with the final system.
Application code is written or, in the case of an enhancement, extended or revised.
The software is systematically debugged, performance, load and stressed tested, with
necessary revisions made to the code.
The final release is compiled, the release is finalized, and the application is deployed to
production.
The ongoing maintenance of the application, including enhancement bug fixing over
the application’s lifecycle until the end of life phase.

PLM and ALM are cyclic process models. The first phase starts again whenever a new revision/version of the
product/software is created. This is repeated until the end of life of the product.

2. Related research work

We performed a systematic mapping study. The aim of a systematic software mapping is to determine the coverage
of a research field [6]. We followed the specific guidelines for software engineering given in [6]. As ALM belongs to
software engineering this method is valid for our research question: What is the research coverage of PLM/ALM
convergence?
We searched in following databases: IEEE Xplore Digital Library, ACM Digital Library (expanded with ACM
Guide to Computing Literature), Springer Link and ScienceDirect. For the latter ones, we restricted the search to the
disciplines “engineering” and “computer science”. We used the search string: (“ALM” AND “PLM”). As ALM and
PLM are well established abbreviations this search string is precise enough to find papers addressing joined topics of
ALM and PLM. As ALM is a new discipline, we limited the search period from 2005 to present. We conducted the
search in calendar week 02/2016. Table 3 shows the initial search results.

Table 3. Search results

Database Total number of publications Number of relevant publications
IEEE Xplore Digital Library 33 2
ACM Digital Library 4 3
Springer Link 19 5
ScienceDirect 20 1
Total 76 11

After reading the titles and making an overview of the abstracts we excluded many publications, which clearly did
not use the abbreviations ALM and PLM according to the meaning in section 2. Furthermore, we excluded all non-
English publications and eliminated double entries. This reduced the number of possible relevant publications to 19.
Finally, we studied the publications in detail. We analysed whether they address common issues of PLM/ALM
such as configuration management, interfaces or general importance of collaboration. This reduced the number of
408 Andreas Deuter and Stefano Rizzo / Procedia Technology 26 (2016) 405 – 412

relevant publications to 11 [3,16,17,18,19,20,21,22,23,24,25]. Some of them are keynote announcements or workshop

descriptions [16,17]. The content of these publications are summarized as follows:
x General importance of PLM/ALM collaboration without detailed suggestions [3,16,19,23,24]
x Collaborative use-cases [22,25]
x Architecture and technology [17,18]
x Using ALM to develop PLM solutions [20,21]
The small number of 11 publications is an indicator that PLM/ALM convergence is hardly covered as a research
field. A well covered research field would lead to many more publications, e.g. there have been 167 relevant
publications on software product size measurement methods until the year 2014 [7].

3. Related industry activities

A manufacturer of smart products implementing PLM and ALM processes has to deploy at least two different
software solutions, one for each lifecycle model. Because ALM and PLM are different process models there are many
different vendors selling PLM software solutions and ALM software solutions. As explained before, this parallel and
disconnected tool environment is inefficient when managing smart products.
To better meet manufacturer needs, tool vendors have begun the convergence of PLM/ALM. Examples are given
from Vector, IBM, Siemens and PTC [3,8,9,10]. The convergence has three dimensions:
x a business dimension
x a technical dimension
x a user dimension
The business dimension addresses the business strategies of the industry. Large tool vendors such as Siemens, PTC
and IBM have acquired ALM vendors (Polarion, MKS and Rational, respectively) in order to integrate software
engineering know-how and ALM know-how into their product portfolio. Smaller vendors cooperate with partners
who implement interfaces.
The technical dimension addresses the implementation of combined PLM/ALM software solutions, e.g. the
interface technology. Open Services for Life Cycle (OSLC) is a recent popular attempt to provide a technical
framework to implement such interfaces [11]. Originally the IBM internal approach to integrate ALM tools, it is now
an open standard and extends the reach of the specification to PLM/ALM. It provides a framework for the integration
of lifecycle management [12]. The IT departments of manufacturing companies are responsible for deploying OSLC
based solutions. However, the users don’t care about these technical implementations.
The user dimension, of course, addresses the needs of users. The user wants harmonized workflows, an integrated
user experience (UX), redundancy-free data, etc. This is the core of PLM/ALM convergence. We pick one concrete
example from the industry to demonstrate a practical implementation regarding the user dimension.
Siemens is the vendor of the PLM tool “Teamcenter”. Polarion is the vendor of the ALM tool “Polarion ALM”.
As mentioned above, Polarion is now part of Siemens. Although the acquisition has just recently been announced,
Polarion and Siemens were already collaborating for some two years to define an approach to PLM/ALM integration.
Siemens and Polarion plan to converge their PLM/ALM solutions in several steps. There is no “big bang” solution.
In each step, a specific level of integration is reached [13]:
1. Link and Trace
2. Change and Propagate
3. Act and Communicate
4. Align and Unify
5. Collaborate and Report
The integration levels 1 and 2 are already implemented and deployed. Siemens Teamcenter Version 10.1.4 or
later, and Polarion ALM Version 2015 or later are required to run them. The companies are now implementing
levels 3 and 4. Level 5 is, to some extent, a longer term goal. Table 4 shows the description of these integration
levels.
 Andreas Deuter and Stefano Rizzo / Procedia Technology 26 (2016) 405 – 412 409

Table 4. Integration levels Siemens Teamcenter and Polarion ALM [13]

Integration Level
1. Link and Trace
2. Change and Propagate
3. Act and Communicate
4. Align and Unify
5. Collaborate and Report
Description
PLM items are linked to software artefacts.
Navigation between both systems is possible.
Impact of changes can be assessed in any
direction. Changes can occur at requirements
level or at design/production level.
Orchestration of all activities in hardware and
software development. Integration of both
processes.
Unification of user experience with a delegated
UI. Alignment of hardware variants and
software variants.
Collaboration of hardware and software
engineers. Single user interface for all team
members including dashboards.
Examples
Link a product requirement to a software requirement.
Find all software test cases connected to a product test
case.
Link a product defect to a software defect.
Find the product component(s) impacted by a software
defect.
Change a product test case and propagate the change to
the software test cases.
Change a product requirement and propagate the change
to the impacted software user stories.
Fix a software bug and update the product BoM.
Change the status of a software change request to
“analyze” when a product change request enters the
“evaluate” state.
Automatically create a product defect when a software
bug is discovered.
Assign a test run task to a software tester when a new
product testing round starts.
Find the software source code running on a specific
product version or variant.
Find the software variants that can be installed on a
product.
Navigate the full BoM (with product and software
artifacts) in the context of a product configuration,
without leaving the PLM environment.
Define and monitor unified product and software KPIs.
Co-engineer a product.
Implement and measure product and software process
improvements.
Software and hardware engineers as part of the same
team.

Siemens and Polarion agreed that it has been proven in practice that ALM cannot be used to develop the hardware
part of a product, and PLM cannot be used to develop the software part. Their final goal, PLM/ALM convergence, is
driven by the desire to deliver a unified user experience, allowing access to dispersed information related to smart
product development in one linked and well-managed data structure that, besides supporting collaboration between
product engineers, can ensure product maintainability in the long term.
In order to evaluate the announced level of integrations, the Siemens Teamcenter Version 10.1.4 and the Polarion
ALM Version 2015 SR2 were installed at the OWL University of Applied Sciences. Additionally, a special connector
needed to be installed. After the technical installation, the product development of a USB stick was simulated. The
product requirements were entered into Teamcenter. The software related requirements were linked via an OSLC
interface from Teamcenter to Polarion. Linking the requirements leads to a UI integration. A user working with
Teamcenter can see the linked software requirement, because the Polarion UI of this software requirement is integrated
in Teamcenter. The same is possible for a user working with Polarion, he can see the Teamcenter UI in Polarion.
When a change is propagated within Teamcenter, it can also be linked with Polarion artefacts. This leads again to
integrated UI’s.
The evaluation showed that the integration levels 1 and 2 are implemented in practice. However, there have been
issues noticed which need improvement. Most of the issues address the usability when linking items between both
tools.
410 Andreas Deuter and Stefano Rizzo / Procedia Technology 26 (2016) 405 – 412

4. Recommendation to the research community

There is a disconnect between activities by industry and research activities regarding PLM/ALM convergence. Is
this an issue? We would answer, yes. It is because we are convinced that the future business success of manufacturing
companies will, among other things, depend on efficient product lifecycle processes and tool chains. The earlier
manufacturers improve on this the better they are prepared for stronger market competition due to digitization.
Academia has, among others, the task to support industry to improve its competitiveness.
We see several potential research topics. The following list is considered as an initial set of ideas. We encourage
the research community to find many more:
x Design of integrated or common PLM/ALM data models.
x Definition of new approaches, or extension of actual methods (Lean, Agile, Enterprise Agile, etc.) to
morph software and hardware teams working on smart product development.
x Design of unified use cases, supporting a better user experience by means of user interfaces and user
interactions with PLM/ALM solutions.
x Design of PLM/ALM key performance indicators (KPIs) and measurement systems monitoring quality,
efficiency, costs, process improvement, effectiveness, etc.
x Design of meaningful reports, dashboards for KPIs and measurements.
x Create a research foundation to support the development of standards for smart product development,
validation, verification, conformance, safety, security etc.
x Design of efficient collaboration between different engineering teams (local, global) with creation of
barrier-breakers among cultures, traditions, comfort zones, etc.
x Empirical research on all these topics following clear guidelines [14].
The research community cannot address these topics without the cooperation of PLM/ALM tool vendors and the
manufacturing companies. It is hardly promising to investigate purely theoretical solutions. However, such industry-
academia collaboration should be planned and performed carefully considering the following success factors [15]:
x Buy-in and support from industry management
x Collaboration champions on site
x Researcher’s attitude and skills
A champion is a person passionately dedicated to a research topic, not just a person assigned the responsibility.
Management support implies the genuine commitment by management to a research topic. Academia naturally
considers research more important than the industry. In order to create a suitable research environment in companies,
management support is needed but researchers must also adapt to the needs of the practitioners.

5. Conclusion

Nowadays, software and hardware are colliding into the “Things” of IoT. This requires PLM/ALM convergence
as ALM cannot be used to develop the hardware part of a product, and PLM cannot be used to develop software.
Convergence includes the definition of integration approaches and product roadmaps, the design of data-linking
structures, open standards for interfaces and the investigation of use cases for the integrations.
This paper addresses the state-of-the-art of PLM/ALM convergence in research and practice. First, the terms ALM
and PLM were defined. A systematic literature review was conducted to find relevant research publication. The
industry activities were presented with details of the activities of Siemens and Polarion. The paper finishes with
recommendations to the research community.
PLM/ALM convergence, as a research field, is hardly covered at all. We found 11 relevant publications, some of
which only address this topic very generally. PLM and ALM vendors are much more active than academia. They drive
the PLM/ALM convergence, creating solutions for the customer.
We recommend that academia increase its research activities on PLM/ALM convergence, as it is a critical business
success factor for manufacturing companies. We also encourage manufacturing companies to seek support from
academia when designing PLM/ALM solutions. When both parties collaborate, efficient solutions can be created.
 Andreas Deuter and Stefano Rizzo / Procedia Technology 26 (2016) 405 – 412 411

However, success factors for industry-academia collaboration such as management support and champions on site
must take place.
Admittedly, there can be challenges to the validity of our findings. We searched in four scientific databases. There
are others. Consequently, we may have missed relevant publications. Furthermore, we used the terms “PLM” and
“ALM” as search strings. There may be publications addressing our research issue but not using these terms. However,
given that we found so few publications in four leading scientific databases, and that PLM/ALM are widely-used
terms, it is unlikely that there are many other relevant publications with a scientific context.
We did not ask manufacturing companies if they have already installed solutions for PLM/ALM convergence.
Therefore, in order to evaluate the industry statements, the PLM tool “Siemens Teamcenter” and the ALM tool
“Polarion ALM” were installed at the OWL University of Applied Sciences. It was proven that first levels of
PLM/ALM integrations are implemented and can be used by manufacturing companies. Therefore, even if PLM/ALM
convergence is not broadly deployed in the industry yet, it will be soon. It is time for academia to cover this innovative
research field. This paper names the reasons and proposes detailed research topics.

References

[1] Stark, J.: Product Lifecycle Management: 21st Century Paradigm for Product Realisation. Decision Engineering. Springer-Verlag London
Limited, 2011.
[2] Kääriäinen, J.: Towards an Application Lifecycle Management Framework: VTT (179), 2011.
[3] Ebert, C.: Improving engineering efficiency with PLM/ALM. In: Software & Systems Modelling 12 (3), S. 443–449, 2013.
[4] Azoff, M.: Software Lifecycle Management (Technology Evaluation and Comparison Report). http://www.ovum.com/research/software-
lifecycle-management-technology-evaluation-and-comparison-report/. Accessed 08 Jan 2016, 2011.
[5] Rizzo, S.: Why ALM and PLM need each other. https://www.polarion.com/resources/download/why-alm-and-plm-need-each-other-
whitepaper. Accessed 07 Jan 2016, 2014.
[6] Petersen, K., Feldt, R., Mujtaba, S., Mattsson, M.: Systematic Mapping Studies in Software Engineering. In: Proceedings of the 12th
International Conference on Evaluation and Assessment in Software Engineering. British Computer Society, Swinton, UK, pp 68–77. 2008.
[7] Bajwa, S. S., Gencel, C., Abrahamsson, P.: Software Product Size Measurement Methods. In Proceedings of International Workshop on
Software Measurement and the International Conference on Software Process and Product Measurement, IWSM-Mensura'14, S. 176-190,
2014.
[8] McAveney, R., Architect, C., Corp, A.: ALM-PLM Integration for Systems Development. In: GLOBAL PRODUCT DATA
INTEROPERABILITY SUMMIT, pp 1–18, 2015.
[9] Azoff, M., Baer, T.: ALM for Engineered Products: The software economics of using PTC solutions for software-rich product development.
http://www.ptc.com/File%20Library/Solutions/All%20Solutions/Ovum-WP-PTC-ALM-for-Engineered-Products.pdf. Accessed 10 Dec 2015,
2014.
[10] Azoff, M.: ALM-PLM integration: Why it matters for multi-domain engineering. https://www.polarion.com/resources/download/ovum-wp-
polarion-alm-plm-integration. Accessed 10 Dec 2015, 2015.
[11] Open Services for Lifecycle Collaboration. http://open-services.net/. Accessed 12 Jan 2016.
[12] Haq, E.U.: Tool integration using OSLC. Master Thesis, Mälardalen University, Sweden, 2013.
[13] Rizzo, S.: Improve Product and Software Development by Integrating ALM and PLM. https://www.polarion.com/
resources/download/improve_product_and_software_development_by_integrating_alm_and_plm. Accessed 12 Jan 2016, 2014.
[14] Kitchenham, B.A., Pfleeger, S.L., Pickard, L.M., Jones, P. W., Hoaglin, D. C., El Emam, K., Rosenberg, J.: Preliminary guidelines for
empirical research in software engineering. IIEEE Trans. Software Eng. 28(8): 721–734, 2002.
[15] Wohlin, C., Aurum, A., Angelis, L., Phillips, L., Dittrich, Y., Gorschek, T., Grahn, H., Henningsson, K., Kagstrom, S., Low, G., Rovegard,
P., Tomaszewski, P., van Toorn, C., Winter, J.: The Success Factors Powering Industry-Academia Collaboration. IEEE Softw. 29(2): 67–73,
2012.
[16] Hubaux, A.: What research in software product line engineering is not solving in configuration. In Proceedings of the 18th International
Software Product Line Conference - Volume 1, 2014.
[17] Kennedy, S., Jiu, L.: Facilitating Collaboration and Interaction across the Enterprise with OSLC. In: Proceedings of the 2013 Conference of
the Center for Advanced Studies on Collaborative Research. IBM Corp, Riverton, NJ, USA, pp 374–375, 2013.
[18] Wielsch, M., Bieniek, R., Grams, B., Lassig, J.: Dynamic integration of ALM tools for agile software development. In: 2013 IEEE/SICE
International Symposium on System Integration (SII), pp 567–573, 2013.
[19] Ebert, C.: Global Software and IT: A Guide to Distributed Development, Projects, and Outsourcing. John Wiley & Sons, Inc, Hoboken, NJ,
USA, 2011.
[20] Kul'ga, K.S.: Object-Oriented design of PLM systems. Russian Engineering Research 29(12): 1285–1289, 2009.
412 Andreas Deuter and Stefano Rizzo / Procedia Technology 26 (2016) 405 – 412

[21] Kul’ga, K.S.: Integrated automated information system for manufacturing enterprises. Russian Engineering Research 32(1): 78–84, 2012.
[22] Bricogne, M., Rivest, L., Troussier, N., Eynard, B.: Towards PLM for Mechatronics System Design Using Concurrent Software Versioning
Principles. In: Product Lifecycle Management. Towards Knowledge-Rich Enterprises: IFIP WG 5.1 International Conference, PLM 2012,
Montreal, QC, Canada, July 9-11, 2012, Revised Selected Papers, vol 388. Springer Berlin Heidelberg, pp 339–348, 2012.
[23] Kääriäinen, J., Välimäki, A.: Applying Application Lifecycle Management for the Development of Complex Systems: Experiences from the
Automation Industry. Software Process Improvement: 16th European Conference, EuroSPI 2009, Alcala (Madrid), Spain, September 2-4,
2009. Proceedings, vol 42. Springer Berlin Heidelberg, pp 149–160, 2009.
[24] Kääriäinen, J., Välimäki, A.: Impact of Application Lifecycle Management - A Case Study. In: Enterprise Interoperability III. Springer
London, pp 55–67, 2008.
[25] Zhong, H., Wachs, J.P., Nof, S.Y.: Telerobot-enabled HUB-CI model for collaborative lifecycle management of design and prototyping.
Computers in Industry 65(4): 550–562, 2014.