Pourquoi il n'existe pas de framework/bibliothèques orientés "métier"?

Salut à tous.

On trouve beaucoup de composants, bibliothèques, framework "techniques" par exemple des frameworks pour :interface utilisateurs, test, OR-mapping, reporting, etc.
Mais je n'ai pas encore vu des frameworks orientés métiers ( par exemple des bibliothèques pour gestion de contact, pour gestion commerciale etc.). Je sais qu'il y a des ERP qui tendent à faire cela, mais les ERP sont des applications déjà toute faites, et non des composants/framework réutilisables.
Comment expliquer ce "vide"? je me demande même si c'est effectivement un vide car la nature a horreur du vide( pour moi c'est un grand vide car j'ai chaque fois l'impression de réinventer la roue quand je développe, mais peut être je fais parti d'une minorité)

Les frameworks métier obéissent à une logique plus commerciale.

Quand tu es à ce niveaux d'abstraction, autant finir le travail.
Les commerciaux ont besoin de montrer quelque chose qui tourne. Comme cela tu as les client qui veulent un produit tout fait, et les autres l'adaptent par plus ou moins de développement.

En plus ce qui fait qu'un framework est mature, c'est qu'il existe au moins une appli qui tourne avec.

A mon connaissance il existe des "Business Rules Framework" (voir Drools), je ne sais pas ce que ça vaut.

Un petit article ici...

C'est aussi parce que ce sont toujours des outils professionnels. Et le monde de l'entreprise n'est pas open source : quand on te paye des fortunes à développer, ce n'est pas pour retrouver ton code ailleurs, fût-ce sous forme de framework plus ou moins compilé.

Ca existe dans le sens ou ce sont des composants ou des modules d'intégration un peu comme ce qu'on trouve dans sharepoint, des produits style SAP ou même des ERP open sources comme quelqu'un l'a cité.

Par contre si tu veux faire une application pour gérer un club de pétanque par exemple, c'est clair que tu trouveras sans doute pas une gestion des cotisations toute faite sur le net. Même pour une gestion de clients simples, cela devient assez vite spécifique tant sur le plan métier (que doit-on avoir comme style de numérotation?), que sur le plan technique (quel est la base de donnée qui accueille les records?).

On a ca pour la carthographie : librairie GeoTools. plus métier on ne peut pas.

Les frameworks orientés métier, ça existe, mais ce sont des produits de sociétés spécialisées. Il y en a pour le monde de l'assurance, de la banque, etc.

En framework ? Tu as des exemples en banque/finance stp ? Je connais (de nom ou pas) beaucoup de progiciels, mais pas vraiment de frameworks.

Citation:

---

Envoyé par el muchacho

Les frameworks orientés métier, ça existe, mais ce sont des produits de sociétés spécialisées. Il y en a pour le monde de l'assurance, de la banque, etc.

---

Svp puis je avoir un exemple? je sais qu'on y trouve des progiciels, mais des frameworks/bibliothèque j'aimerais bien avoir un cas

Dans le monde de l'assurance, par exemple, il y a http://www.prima-solutions.com/index.id

Citation:

---

Envoyé par kisitomomotene

Mais je n'ai pas encore vu des frameworks orientés métiers ( par exemple des bibliothèques pour gestion de contact, pour gestion commerciale etc.). Je sais qu'il y a des ERP qui tendent à faire cela, mais les ERP sont des applications déjà toute faites, et non des composants/framework réutilisables.
Comment expliquer ce "vide"?

---

Les frameworks dont tu parles n'existeront jamais pour la bonne et unique raison que d'une boite à l'autre il ya une forte culture de boite et des méthodes qui sont propres.
Un framework c'est censé apporter le plus petit dénominateur commun pour apporter des solutions universelles...
Or dans une société les méthodes de travailne sont pas universelles..
du moins pour l'instant car avec les fusions-acquisitions et la mondialisation on fera la comtpa à Paris comme on la fait à New-York ou à Bombay d'ici quelques décennies..

Mais pour l'instant une comptabilité en France n'a rien à voir avec un bilan comptabilité à New-York.
Quand tu vois le nombre de codes pour la compta à mettre au passif ou à l'actif....

Bien qu'ils ne reposent pas sur un framework "classique", ils reflètent une présentation des services métiers pour qu'on puisse "composer". Des accroches (via SOA notamment) commencent à exister pour construire "au dessus".

- W

Citation:

---

Envoyé par Mat.M

Les frameworks dont tu parles n'existeront jamais pour la bonne et unique raison que d'une boite à l'autre il ya une forte culture de boite et des méthodes qui sont propres.
Un framework c'est censé apporter le plus petit dénominateur commun pour apporter des solutions universelles...
Or dans une société les méthodes de travail ne sont pas universelles..
du moins pour l'instant car avec les fusions-acquisitions et la mondialisation on fera la comtpa à Paris comme on la fait à New-York ou à Bombay d'ici quelques décennies..

Mais pour l'instant une comptabilité en France n'a rien à voir avec un bilan comptabilité à New-York.
Quand tu vois le nombre de codes pour la compta à mettre au passif ou à l'actif....

---

Je ne crois pas à ce que vous dites. Les ERP proposent un dénominateur commun à plusieurs modèles de gestion, et offrent les possibilités de personnaliser par paramétrage ou par programmation. Le problème c'est que les ERP sont monolithiques de l'interface utilisateur à la base de donnée. Si par exemple vous voulez développer une application spécifique qui comporte un module semblable à la gestion de stock, vous ne pouvez pas intégrer un composant gestion de stock d'un ERP dans votre application. Donc si par exemple ce module représente 30% de votre application, si vous voulez absolument réutiliser ce module, vous serez obligez de:
-(re) développer toute l'application dans l'ERP ou bien
- Installer tout l'ERP et utiliser les Web services pour intégrer, ce qui va impliquer la mise sur pied d'une infrastructure pour synchroniser les données de l' ERP et celle de votre application en back end
Et comme en plus les ERP coûtent cher, et ont une très large portée( la gestion de stock c'est environ 5% d'un ERP), je trouve que la meilleur solution finalement consistera à développer soit même le module des gestion de stock, et on réinvente la roue.

Certains ERP open source sont parait-il suffisamment bien fichus et utilisent une architecture à base de plug-ins qui permet au développeur d'ajouter certaines fonctionnalités sans créer son propre fork. Cela aurait pour avantage de permettre au développeur de continuer de profiter des efforts de la communauté sur le produit de base sans devoir y aller à grand coup de code merging.

Ca a surement des limitations mais je n'ai pas regarder d'assez près.

Citation:

---

Envoyé par kisitomomotene

Et comme en plus les ERP coûtent cher, et ont une très large portée( la gestion de stock c'est environ 5% d'un ERP), je
trouve que la meilleur solution finalement consistera à développer soit même le module des gestion de stock, et on réinvente la roue.

---

Oui tout à fait ça revient un peu au débat : projets client-serveur versus ERP tout intégrés :D.
Est-ce qu'il faut développer une architecture n-tiers avec applis frontales en Java ou .NET et un serveur de données derrière ou bien prendre un ERP ?..
C'est pour cela que les sociétés d'édition d'ERP facturent un maximum leur produit :mrgreen:
comme vous dites dans un ERP on n'utilise qu'un certain pourcentage des fonctionnalités.

J'avais bossé sur un projet avec ERP et effectivement le code développé ne faisait appel qu' à certaines parties de l'ERP.
La partie personnalisée était faite avec VB6/Active X

Moi je suis assez d'accord que c'est un manque, et on pourrait effectivement dans le futur voir apparaître des "briques" open source fonctionnelle, qui pourraient servir de base aux développement d'applications métiers custom.
La raison pour laquelle ça n'existe pas à mon avis c'est que les sociétés qui développe de telles applications sont plus réticentes à les donner à la communauté (pour des raisons de confidentialité, de concurrence....) que des framework plus techniques.

Il y a aussi, je pense, des raisons culturelles. J'ai toujours été éffaré de voir les différences totales d'approche des problèmes entre la SG et BNPP; deux banques qui fournissent pourtant le même genre de services. Un module BNP serait certainement inutilisable par la SG, et vice-versa.

En bref : le poids de l'existant rend, à mon sens, ce genre d'API inutilisables dans la plupart des cas(et c'est tant mieux pour moi, ça me permet de bouffer).

Pour ce qui est des métiers compta/finance, il faut aussi prendre en compte les réglementations... Et ça c'est autre chose que des "cultures d'entreprise" différentes.

Dans ce livre
Eric Evans consacre un chapitre sur les "analysis pattern".
C'est dans ce que tu recherches, j'ai lu le livre il n'y a pas de référence vers des sites particuliers. Mais si tu recherche des choses la dessus le terme correct c'est "analysis pattern" :)

ça existe ça s'appelle progiciel et ça coute cher ...