ALM, PLM, SE, MBSE, Digital Thread — wer sich mit Produktentwicklung beschäftigt, bewegt sich durch ein Dickicht aus Abkürzungen. Das Gemeine daran: Die meisten dieser Begriffe haben in ihrem jeweiligen Kontext durchaus ihre Berechtigung. Aber wer die Zusammenhänge nicht kennt, was wo wie im Kontext steht, für den ist das schlicht verwirrend. Bullshit Bingo eben.
ALM ist dafür ein Paradebeispiel: Application Lifecycle Management. Mal ist ein Management-Ansatz gemeint, mal ein Tool, mal etwas ganz anderes. Zeit, Licht ins Dunkel zu bringen.
ALM als Management-Ansatz
Einerseits steht ALM für einen ganzheitlichen Management-Ansatz: Es geht darum, den kompletten Lebenszyklus einer Anwendung bzw. einer Software zu begleiten: von der ersten Idee über die Entwicklung und den Betrieb bis hin zur Wartung und zum „End of Life”. Im Idealfall sind dabei alle Disziplinen und Beteiligten eingebunden: Entwicklung, Test, Betrieb, Qualitätsmanagement, Product Owner, und so weiter.
ALM ist dann die Management-Klammer, unter der Prozesse klar definiert, Übergaben reibungslos und Informationen transparent sind.
ALM als Tool-Kategorie
In der Praxis wird ALM aber mindestens genauso oft als Synonym für eine bestimmte Klasse von Software-Tools verwendet. Namen wie Polarion, Codebeamer, Jira, Azure DevOps oder IBM Engineering Lifecycle Management sind in vielen Unternehmen längst feste Größen. Diese Tools bieten meist eine ganze Palette an Funktionen:
-
Anforderungsmanagement
-
Testmanagement
-
Aufgaben- und Bugtracking
-
Änderungs- und Konfigurations-Management
-
Nachverfolgbarkeit (Traceability)
-
Reporting und Automatisierung
Das Ziel: Möglichst viele Schritte des Entwicklungsprozesses in einer Plattform zu bündeln, um Medienbrüche zu vermeiden und die Zusammenarbeit zu erleichtern. Oft mit Schnittstellen zu Source-Verwaltungen wie Git oder ähnlichen.
Übrigens ein Markt in Bewegung: Polarion gehört inzwischen zu Siemens, Codebeamer zu PTC. Die großen PLM-Anbieter haben sich ALM-Werkzeuge gezielt ins Portfolio geholt. Schon daran sieht man, dass die Grenzen zwischen den Kategorien alles andere als fest sind. Dazu später mehr.
ALM jenseits der Software-Entwicklung
Viele dieser „ALM-Tools” werden heute längst nicht mehr nur für Softwareprojekte eingesetzt. Manche Unternehmen nutzen sie als zentrale Plattform für das Systems Engineering, also das Management komplexer Produkte, bei denen Software nur ein Baustein unter vielen ist.
Mir ist auch schon begegnet, dass ALM schlicht als Synonym für Requirements-Management-Tools verwendet wird. Nicht ganz falsch: Im Anforderungsmanagement liegt tatsächlich eine der großen Stärken der üblichen ALM-Tools. Aber sie stehen eben für deutlich mehr. Wer ALM auf Requirements Management reduziert, lässt einen Großteil des Potenzials liegen.
Gerade in regulierten Branchen wie Automotive, Medizintechnik oder Luftfahrt zeigt sich noch ein anderes Muster: Dort sind ALM-Tools oft vor allem wegen ihrer Dokumentations- und Nachweismöglichkeiten im Einsatz (Stichwort Traceability), nicht nur wegen klassischer Software-Entwicklungsfunktionen.
ALM, PLM und Systems Engineering: Wer steht wo?
Wie oft wir uns intern schon darüber „gestritten” haben, ob ALM nun neben PLM steht oder ein Teil davon ist: ich habe aufgehört zu zählen. Die Auflösung ist ernüchternd und beruhigend zugleich: Beide Antworten stimmen. Es kommt darauf an, worauf man schaut.
Bei reinen Software-Produkten ist ALM das Pendant zum PLM (Product Lifecycle Management): Es umfasst alle Aufgaben des Lifecycle-Managements, nur eben auf die Software bezogen. ALM steht dann neben PLM.
Bei mechatronischen Produkten (physischen Produkten mit Software-Anteilen) ist ALM dagegen typischerweise ein Teilbereich innerhalb des umfassenderen PLM: PLM steuert das Gesamtprodukt von der Idee über Entwicklung und Fertigung bis zur Außerbetriebnahme, während ALM sich um die Software-Komponenten kümmert. Falls man diese Trennung überhaupt so machen möchte, denn im Idealfall sind beide Welten technisch und organisatorisch eng verzahnt. Etwa über Schnittstellen und durchgängige Traceability, damit Anforderungen, Änderungen und Nachweise über alle Disziplinen hinweg konsistent bleiben.
PLM und ALM beschreiben das ‘Was’, Systems Engineering das ‘Wie’ und die Tools sind das ‘Womit’
Und wie passt Systems Engineering ins Bild? Auch hier hilft die Unterscheidung vom Anfang:
Versteht man ALM als Tool-Kategorie, ist die Sache klar: Das ALM-Tool ist ein Werkzeug, Systems Engineering der Methodenbaukasten. In der Praxis werden ALM-Tools deshalb gerne als Plattform für das Systems Engineering genutzt: sie unterstützen genau das, was SE methodisch fordert: Zusammenarbeit über Disziplinen hinweg und durchgängige Nachverfolgbarkeit von der Anforderung bis zum Test.
Versteht man ALM dagegen als Management-Ansatz, wird es kniffliger. Dann ist ALM (wie PLM auch) eher ein abstrakter Überbegriff für das Was: welcher Lebenszyklus, welche Artefakte, welche Verantwortlichkeiten gemanagt werden. Systems Engineering beschreibt das Wie: mit welchen Methoden entwickelt wird. Allerdings nur für einen Teilbereich dessen, was unter ALM fällt — bspw. Bugtracking, DevOps und Support sind klassischerweise kein SE-Terrain.
Wenn man es auf eine Formel bringen will: PLM und ALM beschreiben das Was, Systems Engineering das Wie, und die Tools sind das Womit. Wie jede Formel vereinfacht sie, aber als Kompass durchs Begriffsdickicht taugt sie allemal.
Fazit: ALM ist, was man draus macht
Wer von ALM spricht, sollte deshalb immer kurz innehalten und klären, was genau gemeint ist:
-
Geht es um den übergreifenden Management-Ansatz?
-
Um Entwicklungsmethoden für Software-Entwicklung?
-
Um ein bestimmtes Tool oder eine Tool-Kategorie?
-
Um einen ganz speziellen Anwendungsfall, wie Requirements Engineering, oder Unterstützung anderer Systems Engineering Capabilities?
-
Oder um die Rolle von ALM im Zusammenspiel mit PLM für das Gesamtprodukt?
Die Antwort ist meistens: „Kommt drauf an.” Und das ist auch okay so, solange alle Beteiligten das gleiche Verständnis haben. Das Bullshit Bingo vom Anfang entsteht ja nicht, weil die Begriffe falsch wären, sondern weil sie ohne Kontext verwendet werden.
Eines noch: ALM ist kein Projekt, das man einmal durchführt und abhakt. Es ist ein Feld, das sich mit den Produkten, den Entwicklungsmethoden und den regulatorischen Anforderungen weiterentwickelt. Das macht es herausfordernd und dauerhaft relevant.
ALM ist vieldeutig — und das ist in Ordnung. Wichtig ist, dass alle Beteiligten dasselbe meinen. Und dass die gewählten Tools, Prozesse und Methoden zu den tatsächlichen Anforderungen passen, nicht zu einem generischen ALM-Bild aus dem Lehrbuch.
Sie planen eine ALM-Initiative oder stecken mitten in einem der Themen? Sprechen Sie mich gerne an — ich begleite bei BHC und PROSTEP Unternehmen bei Strategie, Tool-Auswahl und Umsetzung. Anbieterneutral und aus der Praxis.
Häufig gestellte Fragen
Was bedeutet ALM (Application Lifecycle Management)?
ALM steht für Application Lifecycle Management und wird in der Praxis doppelt verwendet: einmal als ganzheitlicher Management-Ansatz, der eine Software von der ersten Idee über Entwicklung und Betrieb bis zum End of Life begleitet, und einmal als Bezeichnung für eine Tool-Kategorie wie Polarion, Codebeamer oder Azure DevOps. Welche Bedeutung gemeint ist, ergibt sich erst aus dem Kontext.
Ist ALM dasselbe wie PLM?
Nicht ganz, es kommt auf das Produkt an. Bei reinen Softwareprodukten ist ALM das Pendant zu PLM und steht gleichberechtigt daneben. Bei mechatronischen Produkten mit Software-Anteil ist ALM dagegen meist ein Teilbereich innerhalb des umfassenderen PLM, das dann das Gesamtprodukt über Hardware und Software hinweg steuert.
Welche Tools zählen zu den klassischen ALM-Tools?
Zu den bekanntesten ALM-Tools zählen Polarion (Siemens), Codebeamer (PTC), Jira, Azure DevOps und IBM Engineering Lifecycle Management. Sie decken typischerweise Anforderungsmanagement, Testmanagement, Aufgaben- und Bugtracking, Änderungs- und Konfigurationsmanagement sowie Traceability und Reporting in einer Plattform ab.
Wie hängen ALM und Systems Engineering zusammen?
Systems Engineering ist der Methodenbaukasten, ALM-Tools sind dafür oft die Plattform. Versteht man ALM als Tool-Kategorie, unterstützen ALM-Tools genau das, was SE methodisch fordert: Zusammenarbeit über Disziplinen hinweg und durchgängige Nachverfolgbarkeit von der Anforderung bis zum Test. Versteht man ALM als Management-Ansatz, beschreibt SE eher das ‘Wie’ für einen Teilbereich dessen, was ALM als ‘Was’ umfasst.