Application Lifecycle Management PTC: „Wir müssen ganz tief in das Thema Software eintauchen“

Redakteur: Franz Graser

Das Softwarehaus PTC ist durch Lösungen rund um Computer Aided Design (CAD) und Product Lifecycle Management (PLM) bekannt. Doch bei der Produktentwicklung wird Softwareentwicklung immer wichtiger. Chief Technology Officer Andrew Wertkin spricht über die Strategie von PTC.

Firmen zum Thema

Andrew Wertkin ist Chief Technology Officer (CTO) des amerikanischen Softwarehauses PTC.
Andrew Wertkin ist Chief Technology Officer (CTO) des amerikanischen Softwarehauses PTC.
(Bild: PTC)

Wie hat sich das Unternehmen PTC in den letzten zwei bis drei Jahren verändert?

Die Frage könnte genauso gut lauten: Wie haben sich die Kunden geändert? In den Unternehmen, die traditionell sehr auf mechanische Produkte fokussiert waren, hat eine Explosion stattgefunden – eine Explosion der Komplexität, getrieben durch Software und durch Innovationen, die durch Software ermöglicht werden. Diese Komplexität hat zu zahlreichen Initiativen rund um Software und Systems Engineering geführt, und dadurch hat der Begriff PLM eine breitere Bedeutung erhalten. PLM konzentrierte sich herkömmlicherweise auf die physikalischen Aspekte eines Produkts. Unsere Kunden müssen aber die Innovation so früh wie möglich im Entwicklungsprozess vorantreiben – auf der Ebene der funktionalen Architektur. Und sie müssen sicherstellen, dass sie das System analysieren und entwerfen.

So haben sich unsere Kunden verändert. Und so hat sich auch PTC verändert. Ein Teil davon war die Akquisition von MKS [der Hersteller der Application-Lifecycle-Management-Plattform Integrity, d. Red.]. Ein weiterer Teil ist unsere eigene organische Innovation. Ich bin wirklich davon überzeugt, dass wir unsere Kunden ganz früh in diesem Prozess unterstützen und deshalb tief in das Thema Software eintauchen müssen.

Planen Sie, die Lösungen rund um CAD und PLM und die Software-Lifecycle-Produkte in ein großes durchgängiges System zu gießen oder sollen die Dinge separat bleiben?

Unsere Strategie ist es, sicherzustellen, dass ALM und PLM voneinander trennbar bleiben. Trennbar deshalb, weil unsere Kunden durchaus stärker auf Hardware oder auf Software fokussiert sein können. Außerdem haben die meisten Kunden bereits eine bestehende Software-Infrastruktur. Sie brauchen einen flexiblen Weg, diese Technik zu adaptieren, um ihre eigenen Strategien umzusetzen. Und sie benötigen die Fähigkeit, Funktionen nach und nach zu erwerben. Wir glauben: Wenn wir uns damit beschäftigen würden, alles in ein großes System zu integrieren, dann würden wir ihnen diese Flexibilität nehmen.

Andererseits: Wenn man die Integration von ALM und PLM betrachtet, dann bringt es den Kunden einzigartige Fähigkeiten, wenn man beides zusammenführt. Wenn wir nun nicht nur die Produkte, sondern auch die Engineering- und Änderungsprozesse zusammenführten, die Problemreport- und Fehlerbeseitigungsprozesse, die über die beiden getrennten Systeme hinweg verlaufen, dann wäre dieser integrierte Ansatz sehr wertvoll. Aber wir haben eine Strategie, die darauf setzt, dass beides getrennt bleiben kann, und außerdem offen und interoperabel. Wir möchten sicherstellen, dass wir uns weiterhin um ALM-Kunden kümmern können, die unsere PLM-Suite nicht benutzen, und um PLM-Kunden, die unsere ALM-Plattform nicht verwenden. Also: Eine offene, interoperable und trennbare Strategie, die aber eine Menge Gegenwert bietet, wenn die Unternehmen unsere Technik auf beiden Seiten einsetzen.

Auf welcher Technik basiert Ihre ALM-Plattform?

Unsere ALM-Plattform ist PTC Integrity. Das Produkt wurde von uns akquiriert, als wir MKS einbrachten. Das ist eine Enterprise-taugliche ALM-Plattform, die in mehrfacher Hinsicht einzigartig ist. Einmal: Es ist eine einheitliche Plattform, die all die unterschiedlichen Aspekte von ALM verwalten kann: Von den Anforderungen über das Management von Modellen und die Code-Verwaltung bis hin zum Test-Management, zu Berichten, integrierten Metriken und natürlich zur Traceability.

Die Plattform basiert auf Java, sie ist eine Java-Enterprise-Applikation, und sie ist skalierbar, um mit den Bedürfnissen der Kunden zu wachsen. Sie verfügt über Repositories für Terabyte von Quellcode und andere Artefakte. Ich denke aber, das wichtigste Unterscheidungsmerkmal ist, dass diese Plattform die Prozesse und die Aufgaben für die Ingenieure sowie die Produkte für das gesamte Applikationsumfeld managen kann.

Außerdem verfolgen wir einen offenen Integrationsansatz mit den Werkzeugen, die die Ingenieure verwenden. Ob es sich um modellbasiertes Engineering handelt, also Tools wie Simulink oder für die Modellierung mit UML oder SysML, spezielle Aplikationen, die für Hardware-in-the-Loop- oder Software-in-the-Loop-Tests verwendet werden, Tools zur Automatisierung des Build-Prozesses – da gibt es eine Menge an Integrationsmöglichkeiten. Aber wichtig ist das solide Fundament, das alle diese Produkte verwaltet und steuert.

Viele Unternehmen sind ja Teil einer Wertschöpfungskette: sie produzieren Komponenten oder Systeme, die dann wieder in größeren Systemen Verwendung finden. Wie ist die ALM-Lösung für Prozesse geeignet, die Unternehmensgrenzen überspannen?

Es gibt heute ja Standards für die Integration von Daten wie das Requirements Interchange Format (ReqIF). PTC verwendet viel Zeit darauf, in Komitees daran mitzuarbeiten, dass solche Standards weiterentwickelt werden. Diese Standards stellen die Interoperabilität her, die dafür sorgt, dass Kunden nicht auf die gleiche Technologieplattform festgelegt sind und dass sie die Daten über die ganze Wertschöpfungskette hinweg lesen und verwalten können.

Aber das ist ein Beispiel für einen Datenstandard, kein Prozessstandard. Wir arbeiten mit Verbänden wie ASME (American Society of Mechanical Engineers) zusammen, um Informationen über Prozesse zu bekommen. Letztlich hängt es aber von der Fähigkeit der Software ab, ob Prozessketten über unterschiedliche Systeme hinweg geschlossen werden können, unabhängig davon, ob es dafür Standards gibt. In manchen Fällen erreichen unsere Kunden das mit Ansätzen, die auf Standards basieren, manchmal aber koordinieren sie untereinander auf Armlänge die Prozesse in der Lieferkette.

Gratis-Einstiegslösungen greifen oft zu kurz

Wie sprechen Sie Unternehmen an, die darüber nachdenken, eine ALM-Lösung einzusetzen? Es gibt ja Anbieter, die hier auf kostenlose Einstiegslösungen setzen.

Unser Fokus liegt auf Herstellern von Produkten. Dort beobachten wir eine regelrechte Explosion, was die Zahl der Softwareingenieure betrifft. Manche unserer Kunden beschäftigen bereits über 10.000 Softwareingenieure, bei anderen sind es nur hundert, aber auch dort ist die Zahl stark im Wachsen begriffen.

Viele dieser Leute haben durchaus schon kostenlose oder sehr preiswerte ALM-Einstiegslösungen ausprobiert. Aber ihre Anforderungen und Ansprüche liegen auf einer wesentlich höheren Ebene. Ihre Probleme kreisen darum, ob ein Produkt marktreif ist oder um das Änderungsmanagement bei Hard- und Software. Sie wollen die Prozessqualität messen, zum Beispiel nach Automotive SPICE oder CMMI oder welchen Prozessstandard sie dafür verwenden. Sie wollen einen solchen Prozess über ein weltweit verteiltes Engineering-Team ausbreiten.

Das sind Probleme und Anforderungen, für die wir glauben, einzigartig positioniert zu sein, um den Kunden helfen zu können. Ja, es gibt Open Source, es gibt sehr preiswerte ALM-Lösungen, aber sie helfen nicht unbedingt, wenn es um so komplexe Anstrengungen geht. Sie sind für kleinere Arbeitsgruppen sicher gut geeignet, aber wenn man ingenieurgemäße Stringenz und einen Engineering-Prozess über ein verteiltes Software-Team ausbreitet, dann helfen solche isolierten Lösungen nicht. Um integrierte Produkte voranzutreiben, muss man zum Beispiel sehr eng mit den Hardware-Leuten zusammenarbeiten. Deshalb glauben wir, dass unternehmensweite Ansätze der richtigere Weg sind.

In manchen mittelständischen Unternehmen wird Embedded-Software immer noch ad hoc entwickelt, weil die Teams keine Zeit haben, einen Prozess auszuprobieren.

Wir haben eine Initiative namens Global Software Development. Die Idee dahinter ist, dass wir diese Prozesse mitliefern. Oft bedeutet Softwareentwicklung ja – egal, ob man einen Wasserfall-Prozess oder eine Variante einer agilen Methode verwendet –, dass eine ganze Menge von Konfigurationsarbeit notwendig ist, um zum richtigen Prozess zu kommen. Wir wollen, dass unsere Kunden sicher sein können, dass sie eine Lösung einsetzen, die zu ihren Prozessen passt – selbst wenn es Ad-Hoc-Prozesse sind.

Selbst für ein kleines Entwicklerteam ist es wesentlich, dass sie ein einheitliches Repository für alle Artefakte der Entwicklungsarbeit haben. Aber auch wenn es ein kleines Team ist: irgendwann kommt der Punkt, an dem die Kunden sich Gedanken darüber machen, wie sie Software entwickeln. Wenn sie sich im Automobilumfeld bewegen, kann es sogar sein, dass sie sich einem Audit unterziehen müssen. Wenn es Qualitätsprobleme gibt, dann müssen sie sich um diese Fragen kümmern.

Das soll jetzt nicht heißen, dass unsere ALM-Lösung die absolut richtige Lösung für jede Firma ist, die Software programmiert. Wir denken aber: Wenn Software in einem Engineering- oder Fertigungsunternehmen eingesetzt wird, dann wird der Prozess zu einem integralen Teil des Engineering-Umfelds. Diesen Prozess zu erleichtern, wird dann entscheidend.

Viele Hersteller verfolgen unterschiedliche Ansätze, wenn es um ALM geht. Manche kommen von der Seite der Entwickler-Tools, andere mehr von der Datenbankseite. Welche Philosophie verfolgen Sie?

Unsere Philosophie ist sehr stark davon geprägt, den Lebenszyklus zu unterstützen. Wir stellen sicher, die Prozesslandschaft und die Aufgaben im Entwicklungsprozess abzudecken sowie das Konfigurationsmanagement aller Produke, die dabei entstehen.

Uns ging es dagegen nie um die einzelnen Entwicklungswerkzeuge wie etwa die statische Codeanalyse oder die Codegenerierung oder die Automatisierung der Testwerkzeuge. Es gibt eine ganze Reihe von Applikationen für spezifische Aufgaben, die im ALM-Umfeld existieren. Aus unserer Erfahrung wollen die Kunden ausschließlich die besten dieser Applikationen einsetzen. Und da es ja gewaltige Unterschiede geben kann – zum Beispiel welche Programmiersprache man verwendet, welchen Prozess man nutzt oder für welches Echtzeitbetriebssystem man entwickelt – ist es unausweichlich, dass man in den verschiedenen Bereichen jeweils das beste verfügbare Werkzeug nutzt.

Unsere Strategie lautet daher: Wir wollen, dass das Management der Prozesse, der Aufgaben und der entstandenen Produkte über die jeweiligen Tool-Grenzen hinweg funktioniert. Wenn ich zum Beispiel vier verschiedene Modellierungswerkzeuge nutze, kann ich die Traceability-Funktion über alle Werkzeuge hinweg einsetzen. Das ist für uns der Kern von ALM: Das Management all dieser Elemente, das eine Kontinuität und stetige Verbesserung hinsichtlich der Qualität und der Einhaltung von Prozessstandards ermöglicht und sichert.

Was ist für Ihr Unternehmen wichtiger – das CAD/PLM-Geschäft oder die Software/ALM-Seite?

Wir haben fünf Geschäftsfelder, auf denen ein ähnlich starker Fokus liegt. ALM ist eines davon, neben PLM, SCM (Supply Chain Management), SLM (Service Lifecycle Management) und MCAD (Mechanical CAD). Aus unserer Perspektive kommt jedem davon eine entscheidende Bedeutung zu. Historisch gesehen lag der Schwerpunkt bisher auf CAD und PLM, und das ist immer noch ein wichtiger Umsatzträger.

Aber ALM und SLM wachsen und sie wachsen stark. Wir haben MKS gekauft, damit der Bereich weiter wächst. Strategisch gibt es keinen Bereich, der wichtiger als alle anderen wäre. Uns kommt es darauf an, möglichst viele Prozesse aus dem ganzen Engineering-Bereich abzudecken.

Integration mit Electronic-CAD-Werkzeugen

Spielt Electronic CAD für Sie eine Rolle?

Wir haben natürlich Integrationen zu Mentor Graphics, Zuken und Cadence und anderen Tool-Herstellern aus dem ECAD-Umfeld, um sie in die physikalische Welt von PLM zu integrieren. Das bedeutet Schemata, Layouts und Stücklisten, Netzlisten und dergleichen zu verwalten. Wir verfügen über umfangreiche Fähigkeiten zur Visualisierung, um 3-D-Ansichten der Boards zu erzeugen.

Aber wenn man Software entwickelt, entwickelt man für ein ganz spezifisches Ziel. Elektroniker und Softwareentwickler brauchen einen ganz engen Kontakt.

Ja. Man muss sicherstellen, dass Änderungen über unterschiedliche Engineering-Disziplinen orchestriert werden, Wenn es also beim Prozessortyp oder der Speicher-Architektur Änderungen gibt und sich die Speicher-Ressourcen für eine bestimmte Komponente verkleinern, dann muss das über verschiedene Engineering-Disziplinen sichtbar sein.

In der Automobilindustrie haben wir es ja mit einer verteilten Architektur mit vielen unterschiedlichen CPUs zu tun. Und unsere Kunden versuchen nicht nur zu verstehen, wie man Software für eine bestimmte Architektur schreibt, sondern auch, wie man die Softwarekomponenten am besten verteilt. Daraus entsteht eine ganze Reihe von Problemen. Man braucht also ein Disziplin-übergreifendes Änderungsmanagement für Elektronik und Software. Das gilt aber auch für die mechanische Hardware.

Es ist noch nicht lange her, da entschieden selbst bei Premium-Automarken die Einkäufer kurz vor der Markteinführung, einen anderen Prozessor als im Prototyp zu beschaffen, nur weil er billiger war.Die Folgen für die Softwareentwickler kann man sich ausmalen.

Das lässt sich durch genaue Vorgaben im Anforderungsmanagement und im Requirements Engineering lösen. Wenn eine Spezifikation eher locker ist, kann es schon passieren, dass im Einkauf eine sehr späte Entscheidung getroffen wird.

Aber wenn wenn das Anforderungsmanagement auch die Beschaffung einschließt und den Lieferanten einbezieht, dann wird auch das ein immer kollaborativerer Vorgang. Dann passiert es hoffentlich nicht mehr, dass irgendein Erbsenzähler eine einsame Entscheidung trifft. Wir sehen heute, dass die Beschaffungsleute, die mit dem Einkauf strategischer Komponenten betraut sind, sehr viel früher im Prozess hinzugezogen werden. Sie sind Teil des Engineering-Teams und verstehen die Ingenieure. Sie bleiben nicht mehr in der Einkaufsabteilung und versuchen nicht mehr, unabhängig von den Entwicklern die besten Deals auszuhandeln.

(ID:36916550)