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

**kisitomomotene** · 09/07/2008, 18h17

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é)

**orden** · 09/07/2008, 23h56

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.

**madfu** · 10/07/2008, 10h50

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

Un petit article ici...

**guidav** · 10/07/2008, 12h14

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é.

**_skip** · 10/07/2008, 15h22

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?).

**eclesia** · 10/07/2008, 15h30

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

**el muchacho** · 11/07/2008, 08h31

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.

**guidav** · 11/07/2008, 12h37

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

**kisitomomotene** · 11/07/2008, 13h04

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

**el muchacho** · 11/07/2008, 21h26

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

**Mat.M** · 14/07/2008, 22h07

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....

**wiztricks** · 14/07/2008, 22h17

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

**kisitomomotene** · 15/07/2008, 10h43

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.

**_skip** · 15/07/2008, 11h27

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.

**Mat.M** · 15/07/2008, 16h11

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

.
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

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

**slevy** · 25/08/2008, 13h09

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.

**el_slapper** · 25/08/2008, 13h59

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).

**Furikawari** · 18/09/2008, 10h13

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.

**SlashEne** · 25/09/2008, 17h20

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"