25 Jahre Aras Innovator Architektur, für KI entwickelt

Der Inhalt dieser Seite wurde automatisch von einem Drittanbieter übersetzt.

Unternehmenssoftware scheitert selten daran, dass ihr Funktionen fehlen. Häufiger scheitert sie daran, dass ihre Architektur Veränderungen nicht aufnehmen kann.

Das gilt insbesondere für PLM.

Im Laufe der Zeit stellen Hersteller immer höhere Anforderungen an ihr PLM-Backbone. Sie müssen steigende Produktkomplexität, neue Disziplinen, Beziehungen in der Lieferkette, Compliance-Anforderungen, Integrationen, Betriebsmodelle und jetzt auch neue, KI-gestützte Arbeitsweisen unterstützen. In den meisten Systemen sammeln sich diese Anforderungen als technische Schulden an. Die Architektur wird schwieriger zu erweitern, zu aktualisieren und mit dem Geschäft in Einklang zu bringen. Irgendwann bleibt als einziger Weg ein disruptiver Neustart.

Aras Innovator® wurde entwickelt, um genau das zu vermeiden.

Was Aras Innovator über mehr als 25 Jahre technologischen Wandels hinweg relevant gehalten hat, ist nicht nur Offenheit oder Flexibilität im abstrakten Sinne. Es ist ein spezifischer architektonischer Ansatz: eine geschichtete, modellbasierte, serviceorientierte Plattform, die die geschäftliche Definition von der zugrunde liegenden Implementierung trennt. Diese Trennung ist der Grund, warum Aras große Plattformübergänge bewältigen konnte, ohne die Investitionen der Kunden in Daten, Prozesse und Lösungslogik zu gefährden.

Architektur ist wichtiger als Funktionen

Jede große Technologiewelle erzeugt Druck auf Unternehmenssysteme.

Die Webarchitektur hat die Bereitstellung von Anwendungen verändert. Die Cloud hat Deployment- und Betriebsannahmen neu definiert. Moderne UX hat die Erwartungen an Benutzeroberflächen verändert. DevOps hat die Release-Disziplin transformiert. KI verändert nun, wie Systeme unterstützen, automatisieren und schlussfolgern sollen.

Wenn Software eng gekoppelt ist, wird jede dieser Veränderungen destabilisieren. Das Datenmodell hängt vom Anwendungscode ab. Das Verhalten der Anwendung hängt von der Schnittstellenschicht ab. Integrationen hängen von spezifischen Implementierungsdetails ab. Anpassungen liegen zu nah an der Kernlogik. Infolgedessen wird die Weiterentwicklung der Plattform teuer, weil jede Schicht mit jeder anderen verflochten ist.

Das ist die Falle, in die viele PLM-Umgebungen geraten. Je stärker ein Unternehmen das System an seine Geschäftsprozesse anpasst, desto schwieriger wird es, die Plattform weiterzuentwickeln.

Aras Innovator hat von Anfang an einen anderen Weg eingeschlagen. Die Architektur wurde so konzipiert, dass eine Änderung in einer Schicht nicht automatisch eine Überarbeitung der gesamten Lösung erzwingt. Das klingt einfach, ist im PLM-Kontext jedoch grundlegend.

Die geschichtete Architektur hinter Aras Innovator

Aras Innovator ist als mehrschichtige Plattform aufgebaut: Repository, Plattformservices, Modellierungs-Engine, Anwendungen, Clients und Konnektoren. Jede Schicht hat eine klar definierte Rolle, und die Trennung zwischen ihnen sorgt für Beständigkeit.

An der Basis steht die Repository-Schicht, die die physischen Datenbanken und Vaults verwaltet. Diese Schicht ist auf Zugänglichkeit, Skalierbarkeit, Portabilität und unterschiedliche Bereitstellungsmodelle ausgelegt, einschließlich Cloud, On-Premises und Hybrid. Entscheidend ist, dass die Speicherung nicht als Geschäftsmodell selbst betrachtet wird. Sie ist eine zugrunde liegende Persistenzschicht.

Darüber liegt die Plattformservices-Schicht. Hier stellt Aras die gemeinsamen Funktionen bereit, die Datenverarbeitung, Workflows, Lifecycle-Management, Zusammenarbeit, Visualisierung, Föderation, Zugriffskontrolle und andere Kernfunktionen der Plattform unterstützen. Diese Services sind modular und lose gekoppelt. Das ist wichtig, weil sich Services weiterentwickeln können, ohne dass das Geschäftsmodell bei jeder technischen Änderung neu definiert werden muss.

Die nächste zentrale Schicht ist die Modellierungs-Engine. Sie ist wohl die wichtigste architektonische Entscheidung in Aras Innovator. Geschäftsobjekte, Beziehungen, Verhaltensweisen und Regeln werden als Metadaten definiert und nicht fest in die Plattform codiert. ItemTypes, RelationshipTypes, Eigenschaften, Berechtigungen, Versionierungsverhalten und andere Definitionen werden im System selbst modelliert und zur Laufzeit ausgeführt. Das bedeutet, dass die Geschäftsstruktur nicht im benutzerdefinierten Quellcode verborgen ist. Sie wird in einer Form dargestellt, die die Plattform verwalten, interpretieren und weiterentwickeln kann.

Auf der Modellierungs-Engine bauen die Anwendungen auf. Aras-Anwendungen sind keine isolierten Silos. Sie werden unter Verwendung desselben gemeinsamen Datenmodells und derselben Plattformservices aufgebaut. Product Engineering, Requirements Engineering, Systems Architecture, Simulation Management, Manufacturing Process Planning, Quality, Technical Documentation, Digital Twin Core und weitere Anwendungen basieren alle auf einer gemeinsamen Plattformgrundlage. Das ist einer der Gründe, warum Aras die Nachverfolgbarkeit des Digital Thread über Disziplinen hinweg unterstützen kann, anstatt nachträglich isolierte Module zu verbinden.

Darauf folgen Clients und Konnektoren. Benutzer interagieren über Web-Clients und andere Schnittstellen, während Konnektoren Aras mit CAD, Anforderungsmanagement-Tools, MBSE-Umgebungen, Simulationsplattformen, ERP und anderen Systemen verbinden. Da sie oberhalb des zentralen Geschäftsmodells und der Servicebasis angesiedelt sind, erweitern sie die Plattform, ohne sie neu zu definieren. Das ermöglicht Wachstum im Ökosystem, ohne die architektonische Kohärenz zu verlieren.

Warum eine modellbasierte Architektur die Upgrade-Gleichung verändert

Diese Architektur verbessert nicht nur die Erweiterbarkeit. Sie verändert die Wirtschaftlichkeit der Plattformentwicklung.

In traditionellen Unternehmenssystemen werden Upgrades teuer, weil benutzerdefiniertes Verhalten zu eng mit Implementierungsdetails verknüpft ist. Wenn sich die Plattform ändert, muss die Kundenlösung parallel überarbeitet werden. Das macht Modernisierung zu einem kompletten Austauschprojekt.

In Aras Innovator reduziert die metadatengesteuerte Modellierung diese Abhängigkeit. Da Datenmodell, Beziehungen, UI-Definitionen, Workflows und ein Großteil des Lösungsverhaltens als plattformverwaltete Definitionen ausgedrückt werden, sind sie besser von Änderungen im zugrunde liegenden Technologie-Stack isoliert. Die Lösungslogik ist nicht identisch mit der Infrastruktur, die sie bereitstellt.

Deshalb konnte Aras bedeutende technologische Veränderungen im Laufe der Zeit bewältigen. Die Plattform hat sich über Internetarchitektur, UI-Technologien, Cloud-Betriebsmodelle und DevOps-basierte Bereitstellung hinweg weiterentwickelt, ohne den grundlegenden architektonischen Ansatz zu verlieren. Kunden vermeiden nicht den Wandel, sondern die unnötige Neuerstellung ihrer Lösung bei jeder Weiterentwicklung der Plattform.

Deshalb sollte Low-Code bei Aras als architektonisches Prinzip verstanden werden und nicht nur als Produktivitätsfunktion.

Low-Code bei Aras bedeutet mehr als Geschwindigkeit

Die Low-Code-Funktionen von Aras ermöglichen es Unternehmen, Schemata, Formulare, Navigation, Berichte, Workflows und Geschäftslogik innerhalb des Plattformrahmens selbst zu definieren und weiterzuentwickeln. Neue ItemTypes verhalten sich wie vollwertige Plattformbestandteile. Konfigurierte Prozesse übernehmen eine konsistente Governance. Änderungen an der Benutzererfahrung können vorgenommen werden, ohne die Anwendungsgrundlagen neu zu schreiben. Geschäftsregeln können erweitert werden, ohne den Kerncode der Plattform zu verändern.

Das hat drei architektonische Konsequenzen.

Erstens reduziert es den Bedarf an fragilem benutzerdefiniertem Code, um reale Geschäftsanforderungen abzubilden.

Zweitens bleiben Erweiterungen im Einklang mit dem Betriebsmodell der Plattform, was die langfristige Wartbarkeit verbessert.

Drittens kann sich das Geschäftsmodell unabhängig von tiefgreifenden Infrastrukturänderungen weiterentwickeln.

Das ist ein wesentlicher Grund, warum Aras Flexibilität mit Upgradefähigkeit verbinden konnte. Die Plattform zwingt Unternehmen nicht dazu, sich zwischen aktuellen Anforderungen und langfristiger Nachhaltigkeit zu entscheiden.

Offene APIs und Ökosystem-Konnektivität erweitern die Architektur

Eine langlebige PLM-Architektur darf nicht an der Kernplattform enden. Sie muss auch ein breiteres digitales Ökosystem unterstützen.

Aras erreicht dies durch offene APIs, erweiterbare Schemata, Ereignisverarbeitung, AML, IOM, RESTful Services mit OData und clientseitige APIs. Diese sind keine Ergänzungen zu einem geschlossenen System. Sie sind integraler Bestandteil der Plattformarchitektur, um Integration, Automatisierung und Erweiterung zu ermöglichen.

Diese architektonische Offenheit spiegelt sich auch in den Integrationen des Aras-Ökosystems wider. Konnektoren unterstützen mechanische, elektronische und elektrische CAD-Systeme, Anforderungsmanagement-Tools, MBSE-Umgebungen, Simulationssysteme, PDM/PLM-Transformationen, ERP und mehr. Der strategische Wert liegt nicht nur in der Interoperabilität, sondern in der Kontextkontinuität. Externe Systeme können am übergreifenden Digital Thread teilnehmen, ohne dass Produktintelligenz auf fragmentierte Implementierungen verteilt wird.

Dieser Punkt wird im KI-Zeitalter noch wichtiger.

Warum diese Architektur gut für KI geeignet ist

KI wird neue Anforderungen an Unternehmensarchitekturen stellen, aber das Muster ist vertraut. Die Plattformen, die am meisten von KI profitieren, sind nicht die mit den spektakulärsten Copiloten. Es sind diejenigen, die KI einen gesteuerten Zugriff auf relevanten Kontext ermöglichen und sie innerhalb realer Geschäftsprozesse arbeiten lassen.

Hier hat Aras Innovator einen architektonischen Vorteil.

KI im PLM bedeutet nicht nur das Abrufen von Inhalten. Es geht darum, Beziehungen zu verstehen: Anforderungen zu Systemen, Systeme zu Teilen, Teile zu Änderungen, Änderungen zu Freigaben, Produktstrukturen zu Fertigungsdefinitionen, Qualitätsereignisse zu betroffenen Konfigurationen, Serviceereignisse zu digitalen Zwillingen. Genau diese Beziehungen verwaltet die Aras-Architektur über eine gemeinsame Produktdatenplattform und ein kompositionsfähiges Anwendungsmodell.

Ebenso wichtig ist, dass Aras bereits die für industrielle Umgebungen notwendige Steuerungsebene für KI bereitstellt: Berechtigungen, Lifecycle-Status, gesteuerte Workflows, Nachvollziehbarkeit, erweiterbare APIs und strukturierte Produktsemantik. Generische KI-Frameworks verstehen diese Aspekte nicht von Natur aus. Aras schon.

Deshalb sind InnovatorEdge und InnovatorEdge AI logische architektonische Erweiterungen und kein Bruch.

InnovatorEdge stellt gesteuerte Digital-Thread-Services über Low-Code-API-Management und Erweiterungsservices bereit. InnovatorEdge AI baut darauf mit agentischen Fähigkeiten, Workflow- und Guardrail-Orchestrierung, graphbasierter Suche, Toolbibliotheken und PLM-bewusstem Zugriff auf Kontext auf. Anders gesagt: Aras versucht nicht, KI nachträglich in ein System einzubauen, das nie für Erweiterbarkeit konzipiert wurde. Es erweitert eine Architektur, die Plattformservices, Geschäftsmodelle und Ökosystem-Schnittstellen bereits sauber voneinander trennt.

Für kontinuierlichen Wandel gebaut

Die beste Art, Aras Innovator zu verstehen, ist nicht als ein PLM-System, das mehrere Technologiegenerationen überlebt hat. Es ist eine PLM-Plattform, die so konzipiert ist, dass technologische Veränderungen den aufgebauten Geschäftswert nicht automatisch zerstören.

Das ist ein subtiler, aber entscheidender Unterschied.

Aras hat Bestand, weil seine Architektur die geschäftliche Definition von technischer Volatilität trennt. Das Repository kann sich weiterentwickeln. Services können sich weiterentwickeln. Clients können sich weiterentwickeln. Integrationsmuster können sich weiterentwickeln. Neue Erweiterungsschichten können entstehen. Doch die modellierte Darstellung des Geschäfts, die Produktdatenstrukturen, die Prozesslogik, Beziehungen, Berechtigungen und Anwendungsdefinitionen bleiben auf einer Plattform erhalten, die darauf ausgelegt ist, diesen Wert zu bewahren.

Das ist warum Aras Innovator seit mehr als 25 Jahren Bestand hat.

Und deshalb ist seine Architektur heute noch wichtiger, da KI zur nächsten großen Technologiewelle wird.

Um dieses Thema weiter zu vertiefen, lesen Sie das begleitende eBook, 25 Years Strong: Why Aras Innovator is Built for the AI Era.