Architecture IT PLM : Objectifs par bloc (5/6 PLM Enabling Framework)

Posted on September 27, 2010

5_6_blocs

Je gardais spécialement ce bloc pour pouvoir le traiter en dernier avant ma conclusion. Je le gardais car je pense que c’est aujourd’hui le point sur lequel les performances et  la capabilité des outils ne bénéficient pas des dernières technologies et d’un enseignement des outils PLM déjà réalisés. Et ceci est dû en grande partie à un désintérêt, à une méconnaissance ou peut-être aussi tout simplement à une stratégie qui risque de trouver ses limites dans les prochaines années.

Je remets pour rappel le découpage logiciel sur lequel se base cette série d’articles:

PLMBlocs_small

Flexibilité fonctionnelle

Je ne dis pas que les divers framework utilisés aujourd’hui par les éditeurs ont été mal conçus, je dis surtout qu’ils n’ont pas assez évolué. Il était important de partir avec un premier niveau pour implémenter les requis des industriels. Aujourd’hui le dictionnaire de ces besoins même s’il évolue, permet de capitaliser certains process, d’harmoniser certaines pratiques pour au final avoir une idée plus claire des besoins d’une solution PLM. Avec une vision claire des besoins techniques d’un tel dictionnaire il est possible de redéfinir des frameworks qui permettent de les implémenter simplement et qui permettent aussi de prévoir les évolutions futures de pratiques dans le cadre de la gestion de cycle de vie du produit.

objectifs:

  • Offrir une toolbox permettant une grande diversité de fonctionnalités à implémenter.
  • Permettre la conception du système avec un minimum de code et un maximum de conception visuelle type UML.

Flexibilité d’échelle

“Think Big, Start Small”. C’est en général la démarche que l’on préconise mais rarement celle qu’on applique. Pourquoi? Deux facteurs imposent une approche rapide de la totalité du déploiement. La démarche économique de l’éditeur qui à travers une communication et une démarche de vente accélèrent la signature de contrats calculés souvent plus sur des licences utilisateurs que sur un volume fonctionnel. Le deuxième facteur est technologique et consiste en un manque de capacité d’extension de l’application. Ainsi non seulement il faut penser grand (ce que l’on préconise) mais il faut aussi spécifier grand pour être sûr que chaque évolution ne soit pas bloquée par la précédente. Ce manque de flexibilité d’échelle transforme le “Think Big, Start Small”, en un “Specify Big, start deploying Small”. Ce qui est radicalement différent car on demande alors au gens de spécifier une solution extrèmement complexe sans avoir de vécu sur l’outil.

objectifs:

  • Permettre de définir un modèle de données restreint qui pourra servir de base pour la suite sans pour autant spécifier le système complet dès le début.
  • Proposer un modèle économique qui soit aussi facteur du périmètre fonctionnel couvert

Evolutivité

La question d’évolutivité rejoint en quelque sorte la question de flexibilité d’échelle que l’on a traitée plus sur son coté fonctionnel que sur son coté infrastructure (la flexibilité d’échelle au niveau de l’infrastructure est assez bien traitée et de nombreuses personnes travaillent dessus en cette periode de cloud et de virtualisation massive). L’évolutivité va être, je pense, à la base d’évolutions et d’innovations majeures de l’industrie du logiciel dans les prochaines années. C’est clairement un des points sur lequel les logiciels ont encore des lacunes. On a amélioreé les outils pour que les logiciels soient développés de plus en plus rapidement, mais qu’en est-il des modifications?  Faire évoluer un modèle de données dans le temps amène de nombreuses questions par rapport à l’intégrité des données, le stockage d’informations structurées de manières différentes dans le temps pour représenter des objets quasi identiques…

objectifs:

  • Permettre la modification du modèle de données en automatisant les systèmes de vérification de conflit
  • Faciliter l’évolution des interfaces et des attributs des objets implémentés.

Transparence

Enfin, pour permettre d’avancer sur les sujets précédents il est important d’avoir des solutions qui permettent une transparence du modèle de données, des processus du framework et de la couche applicative développée sur cette base. Favoriser la capacité à tout moment de visualiser clairement l’application développée. Permettre aux blocs APIs, Interfaces, processus métiers de s’interfacer plus simplement. Peut-être faut il aussi un nouveau format de description d’une application? Partir de l’acquis d’EXPRESS, d’UML , Merise, etc… pour trouver un format qui soit plus lisible?

objectifs:

  • favoriser la lecture du modèle de données et des processus métiers
  • permettre un accès transparent et standardiser par les APIs

C’est donc sur ce bloc que j’encourage un plus grand nombre de personnes du logiciel à s’y intéresser car il y a sans aucun doute de puissantes solutions qui devront voir le jour ces prochaines années et qui peuvent prendre de court les éditeurs actuels pour qui, une remise en question du framework applicatif est excessivement lourd. Je travaille personnellement dessus, n’hésitez pas à venir discuter de ce sujet avec moi. Cette démarche doit mélanger des profils techniques sur les technologies logicielles pertinentes et des profils plus fonctionnels avec une sensibilité techno pour favoriser la communication des besoins pour remplir les objectifs précédemment cités pour le PLM.

Je concluerai cette série dans le prochain article. Et je produirai un livrable par la suite dans la démarche de capitalisation des écrits de ce blog.

Yoann Maingon


 

Yoann Maingon

Yoann Maingon is an Entrepreneur and a PLM enthousiast. He is our main blogger at Minerva as he has been publishing articles about General PLM concepts and Aras Innovator for more than three years.

More Posts

Download Aras Innovator