Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
En général les progiciels sont monolithiques, et ne sont livrées sous formes de composant réutilisable. Est ce que je peux par exemple trouver un composant facturation (sous forme dll ou .jar etc.) que je peux intégrer dans une application spécifique que je développe, question de ne pas réinventer la roue?Envoyé par inconnu652000
je ne peux te dire, n'étant de la partie, mais de manière générale, c'est là que le bât blesse : suivant les entreprises, les pays, les réformes, les logiciels de facturation, de feuilles de paye, d'impôts, etc, sont très différents...
Il est très rare dans un "métier" que tout le monde soit assez d'accord sur la manière de procéder pour définir un "framework" global consensuel avec des add-ons standards.
Ou alors il faut une équipe puissante qui franchisse un certain degré de généralisation et publie quelque chose de simple , comme l'a fait le CERN avec HTML. (et encore ça n'était que le protocole, pas 'implémentation).
D'ailleurs, c'est un bon exemple le Web : tout le code des navigateurs actuel est dérivé de Mosaic, du NCSA. Et pourtant tu as IE, Firefox, etc etc...
Pourtant le protocole est standard, l'analyse de la fonctionalité demandée est relativement bien définie et assez simple... et on arrive quand même à des produits différents, qui n'ont pas le même code, le même comportement, qui ne sont même pas inter-opérationnels entre eux...
Alors imagine quand c'est plus complexe, quand cela dépend des lois, quand il y a des secrets de métier ou que les organisations / besoins organisationnels sont différents, quand il y a de la concurrence ou de la jalousie, etc etc......
(par exemple, essaye de mettre 2 toubibs d'accord sur comment ils établissent un diagnostic.... Ou 2 experts devant les tribunaux.... ou 2 mécanos de Formule 1...).
A mon avis le web n'est pas un très bon exemple car ils sont partis de rien, dans le sens ou http n'a pas remplacé une foultitude de convention préexistante.
La difficulté est bien là : quand chacun utilise ses petites magouilles dans son coin il est très difficile de leur faire abandonner pour les obliger à utliser autre chose à la place. Et de toute façon il y a plein de bonnes raisons pour ça (d'un poit de vue industriel), la première d'entre elles étant financière.
Je suis d'accord avec vous lorsque vous dites chaque domaine a ses particularités. Mais il y a des "bonnes pratiques" dans tous les domaines d'activité, et même si une entreprise a des particularités, le framework doit justement donner la possibilité d'étendre/surcharger ses fonctionnalités de base pour permettre des adaptations spécifiques.
De toutes façons les progiciels permettent déjà cela. Le problème des progiciels c'est qu'ils sont monolithiques, ne sont pas livrés sous forme d'un ensemble de composants autonomes et réutilisables dans divers environnements. Si par exemple je me rend compte que le module de facturation d'un ERP répond à mes éxigences, je ne peux pas trouver une bibliothèque correspondant à ce module, et la réutiliser dans mon environnement ( mon IDE, ma BD, mes classes etc..)
Piste de réflexion
C'est vrai que c'est une piste de réflexion, on va dire que je commence à avoir une petite expérience ... Les progiciels réalisés de cette manière en composants sont souvent trop liés aux spécificités d'un domaine et donc de ce fait plus vraiment des progiciels mais des applis hautement configurables.
Cela dit faire des composants métiers configurable, ok mais la configuration elle même devient du dev et donc on perd aussi la productivité et aussi quid d'un modèle de donnés faisant appel à des composants métiers configurable ayant chacun le leur ??
C'est un question trés difficile et nécessaitant beaucoup de travail.
Effectivement, cela pourrait être intéressant, mais là, cela nécessite de se poser la question suivante, à mon avis,
Que réalisons nous ?
* des solutions sur mesure (cas typique d'un dev au forfait), pour lequel, un concurrent peut nous demander la même application, avec des specs métier légèrement différentes (du coup des objets métier différents),
* Ou du progiciel qui conviendra et ne conviendra pas à la totalité des clients.£
Dans ce cas, tous le monde (utilisateurs) trouveras des avantages et inconvénients à utiliser le progiciel.
Ce qui distinguera alors les 2 produits c'est le prix...
...
La logique métier d'une entreprise, ça dépasse de loin le cadre de l'informatique. Fondamentalement, c'est l'organisation d'une entreprise, la manière dont elle fonctionne. Autant dire que c'est très fluctuant d'une entreprise à l'autre.
De plus, les éléments logiciels permettant d'informatiser cette logique, c'est ce qui permet à une entreprise de gagner un avantage concurrentiel. Aucune entreprise n'a intérêt à offrir ça à quelqu'un d'autre, que ça soit gratuitement ou moyennant finance.
Oui c'est possible
Cela existe oui puisque maintenant de nombreuses appli de gestion couvrant les divers domaines métiers open source existe donc n'hésite pas a "fouiller" sourceforge, framasoft, clubic ....
Pourquoi pas les recenser ici ?
La réponse est pourtant simple : pas assez de "cibles" potentielles pour que ce soit réellement demandé, donc c'est soit très cher, soit inconnu... Et quand une société galère à développer des modules métier, ils hésitent fortement à filer tout ça à la concurrence (et encore moins gratuitement !!)... Sans parler du client lui-même, qui pourrait décider de se passer des services de son sous-traitant, une fois en possession des briques de base !
Un exemple concret : il y a quelques années, j'ai été dans la stricte impossibilité de trouver une librairie gratuite Modbus sur le net, j'ai donc dû la développer moi-même de A à Z... Cela revenait même nettement moins cher que d'acheter des librairies toutes faites !
Je passe sur les bus de terrain spécifiques à certains clients, ou dépendants d'un matériel totalement introuvable pour quiconque n'est pas sous-traitant du client en question.
Il y a également des éléments technologiques qu'il n'est pas souhaitable de divulguer publiquement, soit par sécurité, soit par brevet. Dans certains cas, certains composants métier relèvent du secret professionnel, voire plus haut encore (confidentiel défense ou secret défense). Inutile de dire que publier de tels éléments logiciels, c'est chercher (et trouver !!) de grosses emmerdes... Donc, aucun sous-traitant ne vendra jamais le framework correspondant !!
Parce que ça rapporte plus de faire de la prestation de service pour le moment.
Mais demain ça pourrait changer il suffit de regarder salesforce pour figurer ce que ça peut être.
Quelques pistes à propos de librairies métiers opensource
Ofbiz par exemple, qui est un framework java pour développer des outils de gestion d'entreprise.
Marc4J / solrmarc / zebra : librairies métiers pour les bibliothèques.
En ce qui concerne l'assurance, faudrait voir du coté de ce site, s'il n'y a pas de librairie : http://www.opensourceinsurance.org/
Bonjour,
Je viens un peu tard, mais cette discussion m'est lancée quand je cherchais quelque chose à propos du framwork OFBiz et comment l'utiliser sous éclipse, si vous avez la moindre idée, s'il vous plaît, informez moi.
Et merci
N.B : l'application que je vais réaliser c'est en J2EE.
Cordialement,
LaGhyoute.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager