25 ans d’architecture Aras Innovator, conçue pour l’IA

Le contenu de cette page a été traduit automatiquement par un service tiers.

Le logiciel d’entreprise échoue rarement par manque de fonctionnalités. Le plus souvent, il échoue parce que son architecture ne peut pas absorber le changement.

C’est particulièrement vrai dans le PLM.

Au fil du temps, les fabricants attendent davantage de leur socle PLM. Ils doivent prendre en charge une complexité produit croissante, de nouvelles disciplines, des relations avec la chaîne d’approvisionnement, des exigences de conformité, des intégrations, des modèles opérationnels, et désormais, de nouvelles façons de travailler pilotées par l’IA. Dans la plupart des systèmes, ces pressions s’accumulent sous forme de dette technique. L’architecture devient plus difficile à étendre, à mettre à niveau et à aligner avec l’activité. À terme, la seule voie possible est une remise à zéro disruptive.

Aras Innovator® a été conçu pour éviter cette issue.

Ce qui a permis à Aras Innovator de rester pertinent pendant plus de 25 ans de changements technologiques, ce n’est pas seulement l’ouverture ou la flexibilité au sens abstrait. C’est une approche architecturale spécifique : une plateforme en couches, basée sur des modèles et orientée services, qui sépare la définition métier de l’implémentation sous-jacente. Cette séparation explique pourquoi Aras a pu évoluer à travers des transitions majeures de plateforme tout en préservant l’investissement des clients dans les données, les processus et la logique des solutions.

L’architecture compte plus que les fonctionnalités

Chaque grande vague technologique exerce une pression sur les systèmes d’entreprise.

L’architecture web a transformé la distribution des applications. Le cloud a modifié les modes de déploiement et d’exploitation. L’UX moderne a redéfini les attentes en matière d’interface. DevOps a transformé la discipline des mises en production. L’IA redéfinit désormais la manière dont les systèmes doivent assister, automatiser et raisonner.

Lorsque les logiciels sont fortement couplés, chacune de ces évolutions devient déstabilisante. Le modèle de données dépend du code applicatif. Le comportement de l’application dépend de la couche d’interface. Les intégrations dépendent de détails d’implémentation spécifiques. Les personnalisations sont trop proches de la logique centrale. En conséquence, faire évoluer la plateforme devient coûteux, car chaque couche est imbriquée avec les autres.

C’est le piège dans lequel tombent de nombreux environnements PLM. Plus une entreprise adapte le système pour refléter son activité, plus il devient difficile de faire évoluer la plateforme.

Aras Innovator a emprunté une voie différente dès le départ. Son architecture a été conçue pour qu’un changement dans une couche n’entraîne pas automatiquement une refonte du reste de la solution. Cela peut sembler simple, mais en PLM, c’est fondamental.

L’architecture en couches derrière Aras Innovator

Aras Innovator est construit comme une plateforme multi-couches : référentiel, services de plateforme, moteur de modélisation, applications, clients et connecteurs. Chaque couche a un rôle distinct, et la séparation entre elles est ce qui garantit la durabilité.

À la base se trouve la couche de référentiel, qui gère les bases de données physiques et les coffres de stockage. Cette couche est conçue pour l’accessibilité, la scalabilité, la portabilité et différents modèles de déploiement, y compris le cloud, le sur site et l’hybride. Le point clé est que le stockage n’est pas considéré comme le modèle métier lui-même. Il s’agit d’une couche de persistance sous-jacente.

Au-dessus se situe la couche des services de plateforme. C’est là qu’Aras fournit les capacités communes qui prennent en charge la gestion des données, les workflows, la gestion des cycles de vie, la collaboration, la visualisation, la fédération, le contrôle d’accès et d’autres fonctions clés de la plateforme. Ces services sont modulaires et faiblement couplés. Cela permet aux services d’évoluer sans obliger à redéfinir le modèle métier à chaque changement technique.

La couche critique suivante est le moteur de modélisation. C’est sans doute le choix architectural le plus important dans Aras Innovator. Les objets métier, les relations, les comportements et les règles sont définis sous forme de métadonnées plutôt que codés en dur dans la plateforme. Les ItemTypes, RelationshipTypes, propriétés, permissions, comportements de versioning et autres définitions sont modélisés dans le système lui-même et exécutés à l’exécution. Cela signifie que la structure métier n’est pas enfouie dans du code source personnalisé. Elle est exprimée dans une forme que la plateforme peut gérer, interpréter et faire évoluer.

Au-dessus du moteur de modélisation se trouvent les applications. Les applications Aras ne sont pas des silos isolés. Elles sont composées à partir du même modèle de données partagé et des mêmes services de plateforme. Product Engineering, Requirements Engineering, Systems Architecture, Simulation Management, Manufacturing Process Planning, Quality, Technical Documentation, Digital Twin Core et d’autres applications reposent sur une base commune. C’est l’une des raisons pour lesquelles Aras peut prendre en charge la traçabilité du fil numérique entre disciplines, plutôt que d’assembler des modules déconnectés après coup.

Viennent ensuite les clients et les connecteurs. Les utilisateurs interagissent via des clients web et d’autres interfaces, tandis que les connecteurs relient Aras à la CAO, aux outils de gestion des exigences, aux environnements MBSE, aux plateformes de simulation, à l’ERP et à d’autres systèmes. Parce qu’ils se situent au-dessus du modèle métier central et des services de plateforme, ils étendent la plateforme sans la redéfinir. Cela permet la croissance de l’écosystème sans perdre la cohérence architecturale.

Pourquoi une architecture basée sur des modèles change l’équation des mises à niveau

Cette architecture fait plus qu’améliorer l’extensibilité. Elle transforme l’économie de l’évolution de la plateforme.

Dans les systèmes d’entreprise traditionnels, les mises à niveau deviennent coûteuses parce que les comportements personnalisés sont trop étroitement liés aux détails d’implémentation. Lorsque la plateforme change, la solution client doit être retravaillée en parallèle. C’est ce qui transforme la modernisation en un projet de remplacement complet.

Dans Aras Innovator, la modélisation pilotée par les métadonnées réduit cette dépendance. Parce que le modèle de données, les relations, les définitions d’interface utilisateur, les workflows et une grande partie du comportement de la solution sont exprimés comme des définitions gérées par la plateforme, ils sont mieux isolés des changements de la pile technique sous-jacente. La logique de la solution n’est pas identique à l’infrastructure qui la supporte.

C’est pourquoi Aras a pu traverser des évolutions technologiques majeures au fil du temps. La plateforme a évolué à travers l’architecture internet, les technologies d’interface, les modèles cloud et les pratiques DevOps sans remettre en cause l’approche architecturale de base. Les clients n’évitent pas le changement ; ils évitent de recréer inutilement leur solution à chaque évolution de la plateforme.

C’est aussi pour cela que le low-code dans Aras doit être compris comme un principe architectural, et pas seulement comme une fonctionnalité de productivité.

Le low-code chez Aras va bien au-delà de la vitesse

Les capacités low-code d’Aras permettent aux organisations de définir et de faire évoluer les schémas, formulaires, navigation, rapports, workflows et logique métier au sein même du cadre de la plateforme. Les nouveaux types d’éléments se comportent comme des composants natifs de la plateforme. Les processus configurés héritent d’une gouvernance cohérente. Les évolutions de l’expérience utilisateur peuvent être réalisées sans réécrire les fondations applicatives. Les règles métier peuvent être étendues sans modifier le code cœur de la plateforme.

Cela a trois conséquences architecturales.

Premièrement, cela réduit la quantité de code personnalisé fragile nécessaire pour refléter les exigences métier réelles.

Deuxièmement, cela maintient les extensions alignées avec le modèle de fonctionnement de la plateforme, améliorant la maintenabilité à long terme.

Troisièmement, cela permet au modèle métier de continuer à évoluer indépendamment des changements profonds d’infrastructure.

C’est une raison majeure pour laquelle Aras a pu combiner flexibilité et capacité de mise à niveau. La plateforme n’oblige pas les entreprises à choisir entre répondre aux besoins actuels et rester durables à long terme.

Les API ouvertes et la connectivité de l’écosystème étendent l’architecture

Une architecture PLM durable ne peut pas s’arrêter à la plateforme centrale. Elle doit aussi prendre en charge un écosystème numérique plus large.

Aras y parvient grâce à des API ouvertes, un schéma extensible, la gestion des événements, AML, IOM, des services RESTful avec OData et des API côté client. Ce ne sont pas des ajouts à un système fermé. Ils font partie intégrante de la conception de la plateforme pour intégrer, automatiser et étendre.

Cette ouverture architecturale se reflète également dans les intégrations de l’écosystème Aras. Les connecteurs prennent en charge la CAO mécanique, électronique et électrique, les outils de gestion des exigences, les environnements MBSE, les systèmes de simulation, les transitions PDM/PLM, l’ERP et bien plus encore. La valeur stratégique ne réside pas seulement dans l’interopérabilité. Elle réside dans la continuité du contexte. Les systèmes externes peuvent participer au fil numérique global sans fragmenter l’intelligence produit entre des implémentations déconnectées.

Ce point devient encore plus important à l’ère de l’IA.

Pourquoi cette architecture est adaptée à l’IA

L’IA va imposer de nouvelles exigences aux architectures d’entreprise, mais le schéma est familier. Les plateformes qui tireront le meilleur parti de l’IA ne seront pas celles avec les copilotes les plus spectaculaires. Ce seront celles capables de donner à l’IA un accès gouverné à un contexte pertinent et de lui permettre d’opérer dans de véritables processus métier.

C’est là qu’Aras Innovator présente un avantage architectural.

L’IA dans le PLM ne se limite pas à la récupération de contenu. Il s’agit de raisonner à travers les relations : des exigences aux systèmes, des systèmes aux pièces, des pièces aux changements, des changements aux validations, des structures produit aux définitions de fabrication, des événements qualité aux configurations impactées, des événements de service aux jumeaux numériques. Ces relations sont précisément ce que l’architecture Aras est conçue pour gérer grâce à une plateforme de données produit partagée et un modèle applicatif composable.

Tout aussi important, Aras fournit déjà le plan de contrôle nécessaire à l’IA dans les environnements industriels : permissions, états de cycle de vie, workflows gouvernés, auditabilité, API extensibles et sémantique produit structurée. Les frameworks d’IA génériques ne comprennent pas nativement ces éléments. Aras, oui.

C’est pourquoi InnovatorEdge et InnovatorEdge AI constituent des extensions architecturales logiques, et non une rupture.

InnovatorEdge expose des services gouvernés du fil numérique via une gestion d’API low-code et des services d’extension. InnovatorEdge AI s’appuie sur cette base avec des capacités agentiques, une orchestration des workflows et des garde-fous, une récupération consciente des graphes, des bibliothèques d’outils et un accès au contexte adapté au PLM. Autrement dit, Aras ne cherche pas à intégrer l’IA dans un système qui n’a pas été conçu pour être extensible. Il étend une architecture qui sépare déjà correctement les services de plateforme, les modèles métier et les interfaces de l’écosystème.

Conçu pour un changement continu

La meilleure façon de comprendre Aras Innovator n’est pas comme un système PLM ayant survécu à plusieurs générations de technologies. C’est une plateforme PLM conçue pour que les évolutions technologiques ne détruisent pas automatiquement la valeur métier accumulée.

C’est une différence subtile mais essentielle.

Aras a perduré parce que son architecture isole la définition métier de la volatilité technique. Le référentiel peut évoluer. Les services peuvent évoluer. Les clients peuvent évoluer. Les modèles d’intégration peuvent évoluer. De nouvelles couches d’extension peuvent apparaître. Mais la représentation modélisée de l’activité, les structures de données produit, la logique des processus, les relations, les permissions et les définitions applicatives restent sur une plateforme conçue pour préserver cette valeur.

C’est pourquoi Aras Innovator est resté durable pendant plus de 25 ans.

Et c’est pourquoi son architecture est encore plus essentielle aujourd’hui, alors que l’IA devient la prochaine grande vague technologique.

Pour approfondir ce sujet, consultez l’eBook associé, 25 Years Strong: Why Aras Innovator is Built for the AI Era.