[parisdevops] Application d'entreprise Was: Apache Camel est-ce un ESB ?
Gildas
> Perso, je le trouve très léger pour une application d'entreprise...
Bonjour,
Ah voilà une occasion unique de poser cette question qui me gratte et
me démange :
"Pour vous (1), qu'est-ce qu'une application d'entreprise?"
Quelle définition donneriez vous? Qu'est-ce-qu'une application doit
posséder comme qualités (ou défauts :)) pour être qualifiée
"d'application d'entreprise"?
Cdt
Gildas Le Nadan
--
(1) cela s'applique à toute personne inscrite à la ML, pas juste HBM :)
Ronan Amicel
>
> Ah voilà une occasion unique de poser cette question qui me gratte et
> me démange :
>
> "Pour vous (1), qu'est-ce qu'une application d'entreprise?"
>
> Quelle définition donneriez vous? Qu'est-ce-qu'une application doit
> posséder comme qualités (ou défauts :)) pour être qualifiée
> "d'application d'entreprise"?
Elle doit être très lourde, très chère, avec une interface utilisateur
très peu ergonomique.
(Et bien sûr, elle est de préférence écrite en Java...) :-P
--
Ronan Amicel
Aurélien Pelletier
mode troll OFF
HBM
http://goo.gl/ceyc0
Merci pour l'invitation au troll, je ne suis pas joueur ;)
Hassan
Software Architect
Gildas
> Voilà pour commencer :
> http://goo.gl/ceyc0
>
> Merci pour l'invitation au troll, je ne suis pas joueur ;)
Hello,
Cela n'est pas un troll, même si j'ai personnellement un apriori très
négatif sur ce qu'est un logiciel d'entreprise et c'est pour cela que
je ne l'ai pas formulé car cela aurait coupé court à la conversation,
or je suis sincèrement intéressé par la question.
Le "logiciel d'entreprise" est une notion souvent brandie, mais me
semblant finalement mal définie.
Devops c'est aussi (surtout) se parler, se créer un glossaire et une
vision commune.
Aussi j'aimerais que nous fassions un petit travail collectif sur ce
sujet, afin de déterminer une définition prenant en compte les points
de vue des uns et des autres (qu'ils soient négatifs ou positifs) pour
mieux comprendre pourquoi cela suscite tellement de débat/d'opinions
tranchées.
Je commence donc à synthétiser ci-dessous ce qui a déjà été dit :
Application d'entreprise
(neutre)
- de préférence écrite en java
(+)
- application dont le choix est peu risqué pour les décisionnaires
(-)
- lourde
- chère
- souvent peu ergonomique
Cdt
Gildas
louis gueye
- application qui répond à un besoin précis : servir des requêtes http (tomcat, jetty, netty), broker des messages (activemq, rabbitmq), avoir des capacités de recherche et d'indexation (elasticsearch, lucene, solr), annuaire d'entreprise (openldap), agréger des données et en faire des traitement (hadoop)
peu importe sa licence, sa taille, sa complexité, objectivement si elle fait ce qu'elle promet elle merite le statut d'application d'entreprise.
après pourquoi je la choisirais, c'est une autre question :). j'ai plus d'affinité avec les outils simples, fiables et de préférence opensource.
Sebastien Douche
> Le "logiciel d'entreprise" est une notion souvent brandie, mais me
> sujet, afin de déterminer une définition prenant en compte les points
> de vue des uns et des autres (qu'ils soient négatifs ou positifs) pour
> mieux comprendre pourquoi cela suscite tellement de débat/d'opinions
> tranchées.
Une application qui répond a des besoins d'entreprises (ce qui ne veut
pas dire que cela ne répond pas aux besoins des non entreprises).
Exemple classique : ldap. C'est rare de trouver des applications Libres
qui fonctionnent nativement et correctement avec du ldap. C'est
pourtant un besoin basique en entreprise.
> (-)
> - lourde
> - chère
> - souvent peu ergonomique
Et un support inefficace.
Mais est ce utile de lister les trolls ? :)
--
Sebastien Douche <sdo...@gmail.com>
Twitter : @sdouche
Bruno Bonfils
Le 24 oct. 2011 à 19:36, Sebastien Douche a écrit :
> 2011/10/24 Gildas <3ntr...@gmail.com>:
>> Le "logiciel d'entreprise" est une notion souvent brandie, mais me
>> Aussi j'aimerais que nous fassions un petit travail collectif sur ce
>> sujet, afin de déterminer une définition prenant en compte les points
>> de vue des uns et des autres (qu'ils soient négatifs ou positifs) pour
>> mieux comprendre pourquoi cela suscite tellement de débat/d'opinions
>> tranchées.
>
> Une application qui répond a des besoins d'entreprises (ce qui ne veut
> pas dire que cela ne répond pas aux besoins des non entreprises).
Perso une application entreprise = une application utilisé pour les besoins directs ou indirects (ERP, CRM, etc.) au vrai métier de l'entreprise
> Exemple classique : ldap. C'est rare de trouver des applications Libres
> qui fonctionnent nativement et correctement avec du ldap. C'est
> pourtant un besoin basique en entreprise.
Tu n'a pas du fréquenter assez d'applications, et de toute manière j'ajouterais qu'en entreprise (justement) ce n'est pas le rôle d'une application de gérer nativement le LDAP, elle doit plutôt se reposer sur du SSO dont c'est le métier.
Ronan Amicel
Mon hypothèse actuelle est que les caractéristiques d'un logiciel d'entreprise sont entièrement définies par la structure des grandes organisations qui les acquièrent, et en particulier par leur processus d'achat.
Configurable
Les grandes organisations vont généralement exprimer des exigences fonctionnelles spécifiques, qui nécessiteront une adaptation du logiciel.
En conséquence, le logiciel d'entreprise se doit d'être adaptable, configurable, extensible, programmable...
Un corollaire est que plus c'est complexe et intensif en main d'œuvre, plus ça fera la joie des consultants et SSII partenaires chargés de l'implémentation (cf. SAP).
Interfacable
Les grandes organisations vont avoir un SI existant, avec lequel le nouveau logiciel va devoir communiquer.
En conséquence, le logiciel d'entreprise se doit d'être compatible avec LDAP etc.
Contrôlable
Dans les grandes organisations, on fonctionne de manière hiérarchique, et il est important de tout surveiller, contrôler, auditer.
En conséquence, le logiciel devra pouvoir être géré de manière centralisée, comporter une gestion complexe des permissions et de la sécurité, et générer des tas de logs.
Usines à gaz
Le mode d'évaluation par checklist et par comparaison avec les autres produits concurrents pousse à empiler toujours plus de fonctionnalités.
Qu'elles soient utiles, qu'elles fonctionnent ou non, qu'elles soient bien intégrées entre elles, tout cela est moins important que de pouvoir les lister lors de la vente.
Choix technologiques conservateurs
Le processus de décision va impliquer un certain nombre de "gatekepers", parmi lesquels la DSI.
L'impératif premier de chaque personne impliquée dans la décision est de couvrir ses arrières (qu'on ne puisse rien lui reprocher en cas de problème ultérieur).
Il est donc dangereux pour la DSI d'approuver des solutions techniques qui ne sont pas considérées comme éprouvées, ou qui ne sont pas poussées par un fournisseur. ("No one ever got fired for buying IBM").
C'est comme ça que l'application "enterprise" lambda va être écrite en Java et tourner sur une base de données Oracle, pourmaximiser la validation par les décideurs techniques.
Prix élevé
Pour garantir un processus de décision le plus rationnel possible, et pour protéger les intérêts de la société en obtenant le meilleur prix, les entreprises mettent en place des procédures d'achat structurées : cahier des charges, mise en concurrence de fournisseurs, appels d'offres, évaluations, service achats, etc.
En conséquence, du côté du fournisseur, le processus de vente est long et nécessite une force commerciale dédiée et coûteuse.
Or, plus le coût de la vente est élevé, plus le prix du logiciel doit lui-même être élevé... (L'inverse de ce qui était recherché au départ...)
--
Ulrich Vachon
besoins business de son entreprise, mais pas à n'importe quel prix.
Elle doit être conçue avec simplicité et précision, quitte à faire du
très adhérant aux besoins du moment, après tout ce n'est que du code.
Donc peu importe importe la techno pour peu qu'elle soit simple,
robuste, adaptée et pour le mieux standard.
J'ai un bon exemple d'appli. d'entreprise codée sur CAMEL à faire
partager si vous voulez.
Ulrich
2011/10/24 Gildas <3ntr...@gmail.com>:
Benoit Garcia
J'écoute la liste depuis plusieurs semaines mais je pense que c'est mon premier message ici, j'en profite pour me présenter:
Je bosse en tant que consultant pour une petite SSII. Je suis généralement coté opérationnel mais mes missions peuvent m’amener à bosser avec (ou à taper sur) les Devs.
Je trouve l'idée d'un rapprochement Dev/Ops très intéressant. Développeurs et Opérationnels sont à la fois clients ou fournisseurs les uns des autres. Mieux on se comprend plus il est facile de bosser ensemble.
La liste permet d'avoir des idées de ce qui se passe dans la tête des uns et des autres, c'est pratique.
2011/10/25 Ronan Amicel <ronan....@gmail.com>
Mon hypothèse actuelle est que les caractéristiques d'un logiciel d'entreprise sont entièrement définies par la structure des grandes organisations qui les acquièrent, et en particulier par leur processus d'achat.
Configurable
Les grandes organisations vont généralement exprimer des exigences fonctionnelles spécifiques, qui nécessiteront une adaptation du logiciel.
En conséquence, le logiciel d'entreprise se doit d'être adaptable, configurable, extensible, programmable...
Un corollaire est que plus c'est complexe et intensif en main d'œuvre, plus ça fera la joie des consultants et SSII partenaires chargés de l'implémentation (cf. SAP).
Interfacable
Les grandes organisations vont avoir un SI existant, avec lequel le nouveau logiciel va devoir communiquer.
En conséquence, le logiciel d'entreprise se doit d'être compatible avec LDAP etc.
Contrôlable
Dans les grandes organisations, on fonctionne de manière hiérarchique, et il est important de tout surveiller, contrôler, auditer.
En conséquence, le logiciel devra pouvoir être géré de manière centralisée, comporter une gestion complexe des permissions et de la sécurité, et générer des tas de logs.
Au contraire plus c'est simple, mieux c'est. Par contre il faut que ça soit efficace et configurable.
Idem pour les logs. Je préfère avoir des logs minimaux mais contenant l'essentiel.
Usines à gaz
Le mode d'évaluation par checklist et par comparaison avec les autres produits concurrents pousse à empiler toujours plus de fonctionnalités.
Qu'elles soient utiles, qu'elles fonctionnent ou non, qu'elles soient bien intégrées entre elles, tout cela est moins important que de pouvoir les lister lors de la vente.
Encore une fois plus c'est simple, mieux c'est (KISS)
Choix technologiques conservateurs
Le processus de décision va impliquer un certain nombre de "gatekepers", parmi lesquels la DSI.
L'impératif premier de chaque personne impliquée dans la décision est de couvrir ses arrières (qu'on ne puisse rien lui reprocher en cas de problème ultérieur).
Il est donc dangereux pour la DSI d'approuver des solutions techniques qui ne sont pas considérées comme éprouvées, ou qui ne sont pas poussées par un fournisseur. ("No one ever got fired for buying IBM").
C'est comme ça que l'application "enterprise" lambda va être écrite en Java et tourner sur une base de données Oracle, pourmaximiser la validation par les décideurs techniques.
Le but est plus d'avoir une certaine stabilité.
Plutôt que d'avoir 14 SGBDR différents dans une société, chacun ayant ses particularités et ses procédures, n'importe quel DSI sensé préfèrera avoir un système hétérogène. Cela diminue les coûts, facilite le recrutement de gens compétents, etc.
A partir de la c'est plus facile de se tourner vers les leaders du marché (IBM, Oracle, Microsoft..)
C'est un cercle vicieux. Plus on les utilise plus il y a de monde pour les administrer et développer des applications. Et plus on les utilise.
Mais pour le coup, on peut renvoyer au premier point: La configurabilité.
Un bon DSI devrait préférer utiliser des applications capable de fonctionner sur plusieurs SGBDR pour ne pas dépendre d'un seul fournisseur (gestion des risques, tout ça).
Prix élevé
Pour garantir un processus de décision le plus rationnel possible, et pour protéger les intérêts de la société en obtenant le meilleur prix, les entreprises mettent en place des procédures d'achat structurées : cahier des charges, mise en concurrence de fournisseurs, appels d'offres, évaluations, service achats, etc.
En conséquence, du côté du fournisseur, le processus de vente est long et nécessite une force commerciale dédiée et coûteuse.
Or, plus le coût de la vente est élevé, plus le prix du logiciel doit lui-même être élevé... (L'inverse de ce qui était recherché au départ...)
Le fait que le processus d'achat nécessite un processus complexe chez un client fait que les revendeurs doivent s'adapter derrière.
Entre 2 logiciels qui ont exactement les mêmes caractéristiques, et qui sont produits par des sociétés identiques, je prendrais le moins cher.
Il manque, à mon avis, un point important, le respect de la législation.
Le fonctionnement d'une entreprise est réglementé (par exemple la comptabilité) et des lois différentes peuvent s'appliquer en fonction des pays (et donc entre différentes filiales).
De même, le marché dans lequel une entreprise officie peut être soumis à des lois particulières (en France les annonces immobilières doivent faire apparaître le diagnostic de performance énergétique par exemple).
Un logiciel d'entreprise doit, à mon avis, pouvoir gérer ce genre de choses.
--
Cdlt,
HBM
Les réponses de Benoit et Ronan sont de loin les meilleures définition d'une application d'entreprise, on peut ne pas être d'accord sur quelques points mais l'essentiel est là.
Je rejoins Benoit sur l'aspect de la législation, les entreprises qui manipulent des données sensibles (les données financières, la consommation téléphonique ou électrique des clients par exemple...) sont contraintes de permettre un certain control dans des endroits spécifiques du SI, des protocoles Humain Readable peuvent être exigés dans des endroits précis pour permettre ces contrôles. On peut même exiger des conversions de protocoles rien que pour ça !
Il y a aussi l'aspect sécurité qui n'est pas à négliger : Ouverture des ports, flux entre machines, politique des mots de passe, cryptage des communications... Bref, plusieurs règles à définir et appliquer en fonction de la criticité de l'application.
Une application sécurisée niveau 1 par exemple, tout le monde qui intervient là-dessus doit être capable de dire : Sauf dérogation particulière, voilà le mécanisme d'authentification utilisé, les flux ouverts, les endroits où trouver les logs, les comptes unix disponibles, ceux éligibles à une connexion distante...Ca facilite largement l'intervention des experts en cas de problème, on se concentre sur le problème et non pas sur "comment ça marche ce truc déjà..."
Concernant le support éditeur, là aussi ça dépend du contrat et de la 'qualité' du client, des fois il faut savoir utiliser la phrase magique : "Le problème est urgent, merci d'escalader le problème à l'équipe R&D s'il vous plait" et là comme par hasard la demande n'est plus traitée par le support niveau 1 en Inde mais plutôt aux USA :)
Bon personnellement, les gens qui me disent une application d'entreprise c'est lourd c'est moche c'est de la daube, moi je préfère les choses simples... Je leur dis restez bien au chaud dans votre startup, après tout, rien de plus satisfaisant que de se sentir le meilleur parmi les mauvais, c'est mieux que d'avoir à travailler avec les meilleurs architectes, administrateurs, experts des NTIC en France ou dans le monde dans certains cas... ;)
Hassan
Software Architect
louis gueye
Parce qu'il faut être dans un grand groupe pour faire du bon travail ?
J'aurai appris quelque chose aujourd'hui.
Sebastien Douche
> Bon personnellement, les gens qui me disent une application d'entreprise
> c'est lourd c'est moche c'est de la daube, moi je préfère les choses
> simples... Je leur dis restez bien au chaud dans votre startup, après tout,
> rien de plus satisfaisant que de se sentir le meilleur parmi les mauvais,
> c'est mieux que d'avoir à travailler avec les meilleurs architectes,
> administrateurs, experts des NTIC en France ou dans le monde dans certains
> cas... ;)
Félicitation ! tu as gagné le prix du mépris et de la prétention.
Brice Dutheil
Je leur dis restez bien au chaud dans votre startup, après tout, rien de plus satisfaisant que de se sentir le meilleur parmi les mauvais, c'est mieux que d'avoir à travailler avec les meilleurs architectes, administrateurs, experts des NTIC en France ou dans le monde dans certains cas... ;)
Ca marche pour tout le monde ça, y compris ceux qui sont dans des grosses boites.
HBM
C'est le monde à l'envers.
Bref, je retourne travailler sur mon application d'entreprise qui est moche, lourde, couteuse et plus vieille que l'informatique...
Hassan
Software Architect
Gabriel Kastenbaum
Gabriel Kastenbaum
louis gueye
- tout le monde pense que les applications d'entreprise c'est de la merde. Faux : on essaie déjà de définir une appli dentreprise.
- tout le monde pense que les grands comptes c'est de la merde. Faux : tout le monde connait leurs contraintes (on y est tous passés). Par contre on peut ne pas être d'accord avec leur mode de fonctionnement, d'ou le choix de certains pour des structures plus petites.
D'une manière générale c'est assez désagréable de se voir prêter des intentions que l'on n'a pas surtout lorsqu'elles sont négatives.
Recentrons nous sur le sujet, restons factuels et évitons les jugements/a-prioris et tout devrait bien se passer.
Gildas
> Hum, je dirais qu'il s'agit d'un application qui répond sur mesure aux
> besoins business de son entreprise, mais pas à n'importe quel prix.
> Elle doit être conçue avec simplicité et précision, quitte à faire du
> très adhérant aux besoins du moment, après tout ce n'est que du code.
> Donc peu importe importe la techno pour peu qu'elle soit simple,
> robuste, adaptée et pour le mieux standard.
>
> J'ai un bon exemple d'appli. d'entreprise codée sur CAMEL à faire
> partager si vous voulez.
>
> Ulrich
Cela me semblerait plus une bonne définition pour l'application conçue
"in-house" que pour l'application d'entreprise, non?
Cdt
Gildas
HBM
Une petite entreprise ou une startup possède un avantage capital, c'est celui d'être souple, légère et ouverte à l'innovation et à la prise de risque, c'est grâce à ça qu'elle trouve une place dans le marché, c'est un très bon argument commercial qui est très vendeur. Mais au fur et à mesure qu'elle grossit, elle perd petit à petit cet avantage et se case plutôt dans une catégorie supérieure avec un marché cible différent du premier. Ainsi elle laisse la place aux jeunes pouces de démarrer à leur tour.
Hassan
Software Architect
Gildas
> 2011/10/25 Ronan Amicel <ronan....@gmail.com>
>>
>> Mon hypothèse actuelle est que les caractéristiques d'un logiciel
>> d'entreprise sont entièrement définies par la structure des grandes
>> organisations qui les acquièrent, et en particulier par leur processus
>> d'achat.
>
> Sur le papier cela ressemble pas mal à ça oui
Sur le papier ou sur le terrain? Je trouve que les définitions de
Ronan sont assez objectives et précises (et je le remercie de s'être
prêté au jeu, je trouve le débat intéressant et constructif dans
l'ensemble)
>> Configurable
>>
>> Les grandes organisations vont généralement exprimer des exigences
>> fonctionnelles spécifiques, qui nécessiteront une adaptation du logiciel.
>>
>> En conséquence, le logiciel d'entreprise se doit d'être adaptable,
>> configurable, extensible, programmable...
>>
>> Un corollaire est que plus c'est complexe et intensif en main d'œuvre,
>> plus ça fera la joie des consultants et SSII partenaires chargés de
>> l'implémentation (cf. SAP).
C'est vrai que c'est souvent un aspect que l'on retrouve dans ce que
j'entends souvent qualifié de "logiciel d'entreprise", que ce soit des
frameworks/outils génériques (ESB, ETL, EAI, etc), des progiciels (les
PGI sont de bons exemples), sans compter les briques intermédiaires,
les Oracle Application Server et consors.
Cet aspect générique et configurable me semble un des aspects les plus
présents (fondamental?).
>> Interfacable
>>
>> Les grandes organisations vont avoir un SI existant, avec lequel le
>> nouveau logiciel va devoir communiquer.
>>
>> En conséquence, le logiciel d'entreprise se doit d'être compatible avec
>> LDAP etc.
Au moins sur le papier/dans les bullets points de la liste des
fonctionnalités. Par contre dans la réalité, les choses ne sont pas si
simples, parce que dans le cas du LDAP par exemple, il y a plusieurs
façon de le mettre en oeuvre et l'appli ne sera pas forcément
compatible avec l'approche mise en place dans la société.
Un des aspects intéressant et que cela force la mise en place de
contournements/verrues qui augmentent la dette technique
d'infrastructure en rajoutant des contraintes de configuration,
limitant l'évolutivité des plateformes et fragilisant l'ensemble : un
changement mineur de configuration ou de version logiciel sur un des
composants aura un effet de bords sur ces contournements se qui fait
qu'une modification mineure d'un élément "fera tout péter" un peu
partout.
>> Contrôlable
>>
>> Dans les grandes organisations, on fonctionne de manière hiérarchique, et
>> il est important de tout surveiller, contrôler, auditer.
>>
>> En conséquence, le logiciel devra pouvoir être géré de manière
>> centralisée, comporter une gestion complexe des permissions et de la
>> sécurité, et générer des tas de logs.
>
> En Je ne pense pas que la gestion des permissions doit être forcément être
> complexe.
> Au contraire plus c'est simple, mieux c'est. Par contre il faut que ça soit
> efficace et configurable.
> Idem pour les logs. Je préfère avoir des logs minimaux mais contenant
> l'essentiel.
Je pense que tous ceux qui travaillent en production partagent ton
avis, mais c'est vrai que l'auditabilité et la gestion des droits/ACL
est un élément qui revient souvent lorsqu'on liste les
caractéristiques de logiciels "entreprise ready".
Ce qui me fait penser à cet excellente présentation par Zed Shaw "the
ACL is dead" : http://vimeo.com/2723800
>> Usines à gaz
>>
>> Le mode d'évaluation par checklist et par comparaison avec les autres
>> produits concurrents pousse à empiler toujours plus de fonctionnalités.
>>
>> Qu'elles soient utiles, qu'elles fonctionnent ou non, qu'elles soient bien
>> intégrées entre elles, tout cela est moins important que de pouvoir les
>> lister lors de la vente.
>
> La par contre je ne suis pas certain de comprendre. Le client chez lequel je
> suis semble penser le contraire: 1 application = 1 fonction.
> Encore une fois plus c'est simple, mieux c'est (KISS)
La complexité et le côté "usine à gaz" me semble le pendant de la
généricité de certains composants/progiciels.
Que d'un point de vue "macro" le progiciel ne fasse qu'une fonction
(genre RH), soit. Pour autant, il est possible que ce soit une usine à
gaz, du fait de la multiplicité des environnements où il doit pouvoir
être mis en place. Que ce soit environnement technique différent
(seul, en cluster HA, avec DB intégrée, DB disjointe, sur windows, sur
linux, sur unix) ou fonctionnel différent (la réglementation RH en
Europe et aux USA est différentes), etc...
Au final ces différentes contraintes ont souvent été rajoutée au fur
et à mesure de la vie de l'application sous la forme de verrues et
sans pour autant que celle-ci soit refondue/refactorisée (on revient
sur la notion de dette technique).
J'ai aussi l'impression que l'effet usine à gaz est lié à la
différence de paradigme entre le monde "entreprise" et le monde "web"
: le premier privilégie le "scale up" et le MTBF (donc la complexité
et un coût élevé), le deuxième favorise le "scale out" et le MTTD
(donc la simplicité).
>> Choix technologiques conservateurs
>>
>> Le processus de décision va impliquer un certain nombre de "gatekepers",
>> parmi lesquels la DSI.
>>
>> L'impératif premier de chaque personne impliquée dans la décision est de
>> couvrir ses arrières (qu'on ne puisse rien lui reprocher en cas de problème
>> ultérieur).
>>
>> Il est donc dangereux pour la DSI d'approuver des solutions techniques qui
>> ne sont pas considérées comme éprouvées, ou qui ne sont pas poussées par un
>> fournisseur. ("No one ever got fired for buying IBM").
>>
>> C'est comme ça que l'application "enterprise" lambda va être écrite en
>> Java et tourner sur une base de données Oracle, pourmaximiser la validation
>> par les décideurs techniques.
>
> Le fait que le choix soit conservateur n'est pour moi qu'un effet de bord.
> Le but est plus d'avoir une certaine stabilité.
> Plutôt que d'avoir 14 SGBDR différents dans une société, chacun ayant ses
> particularités et ses procédures, n'importe quel DSI sensé préfèrera avoir
> un système hétérogène. Cela diminue les coûts, facilite le recrutement de
> gens compétents, etc.
> A partir de la c'est plus facile de se tourner vers les leaders du marché
> (IBM, Oracle, Microsoft..)
> C'est un cercle vicieux. Plus on les utilise plus il y a de monde pour les
> administrer et développer des applications. Et plus on les utilise.
Cela est vrai lorsque la DSI est amenée à donner son avis. Mais même
si cela n'est pas vrai, l'éditeur aura souvent lui-même ce type de
démarche, ce qui fait que souvent l'application sera écrite en java et
sera compatible avec les SGBD leader du marché (oracle), car c'est
plus facile à vendre et aussi plus facile de trouver les compétences
qui si l'appli était écrite en haskell par exemple (même si cela
serait probablement un meilleur choix :)).
Tout à fait d'accord dans le cas d'un progiciel (voir mon exemple sur
le cas de l'appli RH plus haut), cela me semble moins vrai pour les
composants génériques java de type "enterprise ready".
J'ai l'impression dans ce cas que le prix est lié à la quantité de
fonctionnalités mise en oeuvre.
Sachant que souvent la décision est le fruit d'un processus de type
"Big Design Up Front", on finit par acheter/privilégier le
composant/logiciel ayant le plus de fonctionnalités sans être sûr de
toutes les utiliser. Et une fois mis en place, les solutions
deviennent tellement adhérentes au socle déployé que le simple
changement de logiciel nécessite un véritable chantier (il n'y a pas
de test automatique mise en place dans ces contextes permettant de
faire du "refactoring d'infrastructure" en s'assurant qu'il n'y a pas
de régression, ce qui impose un chantier de migration manuel pour
s'assurer de l'absence des régressions en question).
> Benoit Garcia.
Merci pour ta contribution Benoit!
Cdt
Gildas
Benoit Garcia
Sur le papier ou sur le terrain? Je trouve que les définitions de
Qui n'est jamais tombé dans une société ou le DSI (ou tout autre décideur suffisamment bien placé) "couche" avec le fournisseur?
Et d'aller voir les équipes IT en disant "On a acheté ça. Vous pouvez le faire marcher maintenant?"
Cet aspect générique et configurable me semble un des aspects les plus
présents (fondamental?).
Pour rester dans le domaine des SGBDR (je bosse en tant que DBA, je pense que ça se voit?), j'ai trop souvent à faire à des progiciels qui ne fonctionnent que si l'utilisateur dans la base de données s’appelle "toto".
Certains éditeurs (généralement des petits) poussent le vice en codant en dur le nom de la base de données dans leur application.
Au moins sur le papier/dans les bullets points de la liste des
fonctionnalités. Par contre dans la réalité, les choses ne sont pas si
simples, parce que dans le cas du LDAP par exemple, il y a plusieurs
façon de le mettre en oeuvre et l'appli ne sera pas forcément
compatible avec l'approche mise en place dans la société.
LDAP n'est ni plus ni moins qu'un référentiel.
Certains l'utilisent pour l'authentification d'autres pour la gestion des accès.
Du coup il faut que le logiciel soit suffisamment souple pour accepter ça.
Un des aspects intéressant et que cela force la mise en place de
contournements/verrues qui augmentent la dette technique
d'infrastructure en rajoutant des contraintes de configuration,
limitant l'évolutivité des plateformes et fragilisant l'ensemble : un
changement mineur de configuration ou de version logiciel sur un des
composants aura un effet de bords sur ces contournements se qui fait
qu'une modification mineure d'un élément "fera tout péter" un peu
partout.
Il faut trouver un juste milieu entre avoir une infrastructure figée (qui nécessite de re-développer chaque application) ou au contraire une infra "poubelle" qui accepte le tout venant mais dont personne ne sait vraiment comment elle marche.
Je pense que tous ceux qui travaillent en production partagent ton
avis, mais c'est vrai que l'auditabilité et la gestion des droits/ACL
est un élément qui revient souvent lorsqu'on liste les
caractéristiques de logiciels "entreprise ready".
Lors des audits auquel j'ai eu à répondre, on m'a souvent posé la même questions: "qui" peut réaliser (ou a réalisé) "quoi".
Le quoi étant en général soit purement technique (lire le fichier de conf contenant le mot de passe) ou purement fonctionnel (extraire la liste des clients du CRM).
Le fait que l'action fonctionnelle peut être réalisée par des opérations techniques (se connecter à la base de données et lire la table) est généralement couvert par l'audit technique.
Ce qui me fait penser à cet excellente présentation par Zed Shaw "the
ACL is dead" : http://vimeo.com/2723800
La complexité et le côté "usine à gaz" me semble le pendant de la
généricité de certains composants/progiciels.
Que d'un point de vue "macro" le progiciel ne fasse qu'une fonction
(genre RH), soit. Pour autant, il est possible que ce soit une usine à
gaz, du fait de la multiplicité des environnements où il doit pouvoir
être mis en place. Que ce soit environnement technique différent
(seul, en cluster HA, avec DB intégrée, DB disjointe, sur windows, sur
linux, sur unix) ou fonctionnel différent (la réglementation RH en
Europe et aux USA est différentes), etc...
Pour être honnête, je n'ai aucune idée de la direction dans laquelle je voulais aller en me relisant..
Au final ces différentes contraintes ont souvent été rajoutée au fur
et à mesure de la vie de l'application sous la forme de verrues et
sans pour autant que celle-ci soit refondue/refactorisée (on revient
sur la notion de dette technique).
J'ai aussi l'impression que l'effet usine à gaz est lié à la
différence de paradigme entre le monde "entreprise" et le monde "web"
: le premier privilégie le "scale up" et le MTBF (donc la complexité
et un coût élevé), le deuxième favorise le "scale out" et le MTTD
(donc la simplicité).
Pour moi avoir un MTTR faible nécessite d'avoir un MTBF suffisamment grand pour éviter que tous les noeuds du cloud tombe en panne.
Du coup, avoir un MTTR faible est plus complexe et plus cher que de se contenter d'avoir un gros MTBF..
En tout cas j'espère que ce n'est pas lui qui gère ton cloud: http://xkcd.com/908/
Cela est vrai lorsque la DSI est amenée à donner son avis. Mais même
si cela n'est pas vrai, l'éditeur aura souvent lui-même ce type de
démarche, ce qui fait que souvent l'application sera écrite en java et
sera compatible avec les SGBD leader du marché (oracle), car c'est
plus facile à vendre et aussi plus facile de trouver les compétences
qui si l'appli était écrite en haskell par exemple (même si cela
serait probablement un meilleur choix :)).
Beaucoup (de plus en plus?) de produits fonctionnent sur plusieurs SGBDR.
Principalement parce que développer pour les gros (Oracle particulièrement) coutait cher et que les PME (clients de l'éditeur) n'ont pas forcément les moyens de payer le moteur.
Java et JDBC facilitent également l'utilisation de différents SGBDR et permettent de fonctionner sur différentes plateformes applicatives (Websphere, Weblogic, Jboss).
Il y a ensuite des logiciels ou la question ne se pose pas.
Je n'ai jamais vérifié mais je suis persuadé qu'Exchange nécessite une base SQL Server pour fonctionner.
Certains éditeurs sont spécialisés sur certaines plateforme. J'ai eu à travailler avec une boite qui ne certifiait ses produits que pour Weblogic/Oracle. Tu veux du websphere? Ca marche peut-être mais tu n'auras pas de support.
Cela reste généralement des marchés de niche.
le cas de l'appli RH plus haut), cela me semble moins vrai pour lesTout à fait d'accord dans le cas d'un progiciel (voir mon exemple sur
composants génériques java de type "enterprise ready".
J'ai l'impression dans ce cas que le prix est lié à la quantité de
fonctionnalités mise en oeuvre.
Le prix n'est lié qu'à une seule chose: La quantité d'argent que le client est prêt à payer.
Et que celui qui n'a jamais vu de remise de 50% par rapport au prix payé par le voisin lève la main.
Sachant que souvent la décision est le fruit d'un processus de type
"Big Design Up Front", on finit par acheter/privilégier le
composant/logiciel ayant le plus de fonctionnalités sans être sûr de
toutes les utiliser. Et une fois mis en place, les solutions
deviennent tellement adhérentes au socle déployé que le simple
changement de logiciel nécessite un véritable chantier (il n'y a pas
de test automatique mise en place dans ces contextes permettant de
faire du "refactoring d'infrastructure" en s'assurant qu'il n'y a pas
de régression, ce qui impose un chantier de migration manuel pour
s'assurer de l'absence des régressions en question).
Je pense que lorsque l'on achète un produit (cher en l’occurrence) il faut le rentabiliser. Donc on va bâtir le reste du SI dessus.
C'est encore plus vrai si le produit est important pour le métier.
Merci pour ta contribution Benoit!
--
Cdlt,
Benoit.
Benoit Garcia
2011/10/25 Gabriel Kastenbaum <gabriel.k...@gmail.com>
- innovation : vas mettre un mysql chez la bnp... Alors un Cassandra
Des boites aussi grosses que BNP ont généralement une équipe de R&D chargée de tester ce genre de produits et de définir leur cadre d'utilisation.
Si on me demandait mon avis, je dirais que ce qui manque à MySQL et Cassandra c'est:
- Le manque de support derrière.
Je pense spécialement à une grosse société capable de rendre des comptes tant sur le plan juridique que financier.
- Le manque de compétences en interne sur le produit.
Ce genre de produits (principalement Cassandra) est jeune et peu de personne ont de grosses compétences dessus.
Comment on gère quand une des rares personnes qui connait le produit disparait ou se fâche avec son boss?
Est-on certain de pouvoir trouver quelqu'un pour la remplacer au pied levé?
Cdlt,
Benoit.
Gildas
Le 25 oct. 2011 21:33, "Benoit Garcia" <benoit...@gmail.com> a écrit :
> 2011/10/25 Gildas <3ntr...@gmail.com>
>> Cet aspect générique et configurable me semble un des aspects les plus
>> présents (fondamental?).
>
> La encore pas toujours.
> Pour rester dans le domaine des SGBDR (je bosse en tant que DBA, je pense que ça se voit?), j'ai trop souvent à faire à des progiciels qui ne fonctionnent que si l'utilisateur dans la base de données s’appelle "toto".
> Certains éditeurs (généralement des petits) poussent le vice en codant en dur le nom de la base de données dans leur application.
>
Oui, j'en ai vu aussi. Mais si l'on se replace dans le contexte de la definition d'un "logiciel d'entreprise" la genericite et la configurabilite de la solution me semble tres importante et je ne suis pas sur qu'il vienne a la majorite des gens l'idee de qualifier un logiciel incapable de partager un SGBDR avec d'autres applis de solution "enterprise ready".
>> Un des aspects intéressant et que cela force la mise en place de
>> contournements/verrues qui augmentent la dette technique
>> d'infrastructure en rajoutant des contraintes de configuration,
>> limitant l'évolutivité des plateformes et fragilisant l'ensemble : un
>> changement mineur de configuration ou de version logiciel sur un des
>> composants aura un effet de bords sur ces contournements se qui fait
>> qu'une modification mineure d'un élément "fera tout péter" un peu
>> partout.
>
> Exactement.
> Il faut trouver un juste milieu entre avoir une infrastructure figée (qui nécessite de re-développer chaque application) ou au contraire une infra "poubelle" qui accepte le tout venant mais dont personne ne sait vraiment comment elle marche.
>
>> Je pense que tous ceux qui travaillent en production partagent ton
>> avis, mais c'est vrai que l'auditabilité et la gestion des droits/ACL
>> est un élément qui revient souvent lorsqu'on liste les
>> caractéristiques de logiciels "entreprise ready".
>
> Justement. Plus c'est simple plus c'est facile à auditer.
> Lors des audits auquel j'ai eu à répondre, on m'a souvent posé la même questions: "qui" peut réaliser (ou a réalisé) "quoi".
> Le quoi étant en général soit purement technique (lire le fichier de conf contenant le mot de passe) ou purement fonctionnel (extraire la liste des clients du CRM).
> Le fait que l'action fonctionnelle peut être réalisée par des opérations techniques (se connecter à la base de données et lire la table) est généralement couvert par l'audit technique.
>
>> Ce qui me fait penser à cet excellente présentation par Zed Shaw "the
>> ACL is dead" : http://vimeo.com/2723800
>
> Je ne connais pas. Je vais y jeter un oeil.
Je suis d'accord avec toi sur le point de la simplicite et je pense que de nombreuses autres personnes ici le sont aussi.
Pour autant, est-ce que la simplicite est une caracteristique fondamentale d'une application d'entreprise?
J'aurais tendance a repondre non, parce que les besoins d'auditabilite, la gestion des comptes et des autorisations, des workflows de validation, etc, ont tendance a etre complexes, surtout lorsqu'on veut pouvoir s'adapter a un grand nombre de cas de figures differents (ce qui rejoint mon propos sur l'usine a gaz).
>> J'ai aussi l'impression que l'effet usine à gaz est lié à la
>> différence de paradigme entre le monde "entreprise" et le monde "web"
>> : le premier privilégie le "scale up" et le MTBF (donc la complexité
>> et un coût élevé), le deuxième favorise le "scale out" et le MTTD
>> (donc la simplicité).
>
> Hmm. Tu est donc "Web" et "Dev"? :-)
> Pour moi avoir un MTTR faible nécessite d'avoir un MTBF suffisamment grand pour éviter que tous les noeuds du cloud tombe en panne.
> Du coup, avoir un MTTR faible est plus complexe et plus cher que de se contenter d'avoir un gros MTBF..
>
> En tout cas j'espère que ce n'est pas lui qui gère ton cloud: http://xkcd.com/908/
Tu fais fausse route... au moins sur qui je suis. Ta generalisation au cloud me parait curieuse. Pourrais tu expliciter?
Ma reference au MTTR > MTBF est a comprendre dans le sens des propos de John Allspaw (Etsy) qui l'exprime mieux que moi. Je vous invite a aller lire ses propos a ce sujet.
En gros, il dit qu'avoir de faibles Mean Time To Diagnose et Mean Time To Repair est plus important concretement que d'avoir un Mean Time Between Failure eleve.
Un MTBF eleve ne s'obtient qu'au prix d'une complexite et un cout accrue.
Avec pour resultante une plus faible adaptabilite/agilite de l'infrastructure, (et une tendance au Big Design Up Front), une difficulte de diagnostic et au final des pannes spectaculaires de temps en temps quasi toujours causees par de multiples facteurs.
Il y a egalement un aspect psychologique, des pannes simples mais frequentes (et n'impactant pas le service, hein, on met de la redondance via la scale out et ce qu'il faut, tout de meme) feront que les equipes seront plus sur le qui-vive et plus aptes a repondre a une panne qu'un systeme qui ronronne et qu'on finit par oublier.
Je simplifie a l'extreme son propos mais il y a toujours moyen d'y revenir!
>> Tout à fait d'accord dans le cas d'un progiciel (voir mon exemple sur
>> le cas de l'appli RH plus haut), cela me semble moins vrai pour les
>> composants génériques java de type "enterprise ready".
>
> Je ne suis pas certain de comprendre ce que sont ces composants génériques ni à quoi ils servent..
exemple : un composant JMS, un moteur d'EAI/ETL etc
>> deviennent tellement adhérentes au socle déployé que le simple
>> changement de logiciel nécessite un véritable chantier (il n'y a pas
>> de test automatique mise en place dans ces contextes permettant de
>> faire du "refactoring d'infrastructure" en s'assurant qu'il n'y a pas
>> de régression, ce qui impose un chantier de migration manuel pour
>> s'assurer de l'absence des régressions en question).
>
> Cela se comprend quand on aborde cela par l'aspect coût:
> Je pense que lorsque l'on achète un produit (cher en l’occurrence) il faut le rentabiliser. Donc on va bâtir le reste du SI dessus.
> C'est encore plus vrai si le produit est important pour le métier.
C'est encore un autre (vaste) debat .
Cdt
Gildas
Gildas
Le 25 oct. 2011 21:54, "Benoit Garcia" <benoit...@gmail.com> a écrit :
>
> Je répond juste sur un point:
>
> 2011/10/25 Gabriel Kastenbaum <gabriel.k...@gmail.com>
>>
>> - innovation : vas mettre un mysql chez la bnp... Alors un Cassandra
>
> Au contraire.
> Des boites aussi grosses que BNP ont généralement une équipe de R&D chargée de tester ce genre de produits et de définir leur cadre d'utilisation.
>
> Si on me demandait mon avis, je dirais que ce qui manque à MySQL et Cassandra c'est:
> - Le manque de support derrière.
> Je pense spécialement à une grosse société capable de rendre des comptes tant sur le plan juridique que financier.
Il y a des boites qui font du support sur mysql. Percona par exemple. Mais aussi redhat pour peu que l'on utilise la version livree avec une RHEL.
Par contre oui il y a la grande arnaque des "compensations financieres" dans le cadre des SLA.
Comprendre : vous payez un service 3000 EUR par jour dont depend 1 000 000 d'EUR de CA/jour. Tout le monde dort sur ses 2 oreilles car il y a un support gold en cas de probleme! Sauf que le jour ou il y a un probleme, le support met pas mal de temps a monter en puissance sur le probleme en question (lorsqu'il y arrive) et au final les compensations sont de l'ordre du montant paye par jour.
Donc au final, ca se termine par quelques jours d'interruptions de prod a 1 000 000 d'EUR de CA, mais l'honneur est sauf car il y a 3000 x le nombre de jour de compensation financiere de la part du fournisseur...
La vaste blague que voila.
> - Le manque de compétences en interne sur le produit.
> Ce genre de produits (principalement Cassandra) est jeune et peu de personne ont de grosses compétences dessus.
> Comment on gère quand une des rares personnes qui connait le produit disparait ou se fâche avec son boss?
> Est-on certain de pouvoir trouver quelqu'un pour la remplacer au pied levé?
Il y a beaucoup a dire sur "cette selection par la mediocrite" a mon avis.
Je pense que c'est un facteur limitant de la competivite des entreprises et que l'objectif de limite du risque n'est de plus pas forcement atteint, ne serait-ce que pour la tres grande partie des entreprises ou j'ai travaille, grosses ou petites, la gestion de la connaissance est tellement pitoyable que le depart d'une personne correspond toujours a une perte de connaissance seche pour l'entreprise.
Gildas
Henri Gomez
vues sur d'autres ML (comme les CC).
Au final, Apache Camel est-il un ESB ?
Sam Bessalh
Sent from IPhone
Ulrich Vachon
contrairement à d'autres...
2011/10/26 Henri Gomez <henri...@gmail.com>:
Benoit Garcia
Oui, j'en ai vu aussi. Mais si l'on se replace dans le contexte de la definition d'un "logiciel d'entreprise" la genericite et la configurabilite de la solution me semble tres importante et je ne suis pas sur qu'il vienne a la majorite des gens l'idee de qualifier un logiciel incapable de partager un SGBDR avec d'autres applis de solution "enterprise ready".
Une application qui ne répond à un besoin que seule une entreprise peut avoir et qui est incapable de fonctionner dans un autre environnement que celui prévu par l'éditeur.
Ce n'est heureusement pas la majorité mais cela arrive trop souvent à mon goût.
Je suis d'accord avec toi sur le point de la simplicite et je pense que de nombreuses autres personnes ici le sont aussi.Pour autant, est-ce que la simplicite est une caracteristique fondamentale d'une application d'entreprise?
J'aurais tendance a repondre non, parce que les besoins d'auditabilite, la gestion des comptes et des autorisations, des workflows de validation, etc, ont tendance a etre complexes, surtout lorsqu'on veut pouvoir s'adapter a un grand nombre de cas de figures differents (ce qui rejoint mon propos sur l'usine a gaz).
Effectivement, les entreprises professionnelles sont souvent des usines à gaz.
J'aurais tendance à dire que tous les logiciels le sont. Regarder ce que l'on peut faire avec Firefox.
Ce que je voulais dire c'est que les processus sous-jacents dont tu parles eux ne devraient pas l'être.
> Hmm. Tu est donc "Web" et "Dev"? :-)
> Pour moi avoir un MTTR faible nécessite d'avoir un MTBF suffisamment grand pour éviter que tous les noeuds du cloud tombe en panne.
> Du coup, avoir un MTTR faible est plus complexe et plus cher que de se contenter d'avoir un gros MTBF..
>
> En tout cas j'espère que ce n'est pas lui qui gère ton cloud: http://xkcd.com/908/Tu fais fausse route... au moins sur qui je suis. Ta generalisation au cloud me parait curieuse. Pourrais tu expliciter?
Si tes machines physiques tombent en panne plus rapidement que ce que tu peux les réparer cela ne marche pas.
Je ne connaissais pas la notion de MTTD et j'en avais conclus qu'il s'agissait d'une faute de frappe et correspondait au Mean Time to Recovery (MTTR).
Le MTBF est un minimum lié à la qualité des composants matériels.
Le MTTR est lié aux contrats de supports et aux délais de rétablissement.
Généralement pour avoir des contrats de services "haut de gamme" on paye cher.
Et il arrive qu'un contrat de support de ce type ne soit disponible que pour du matériel "haut de gamme" et donc très cher.
L'un dans l'autre, il faut à la fois le matériel très cher + le contrat très cher.
Si on ne veut pas de ce genre de contrats, on met une solution redondante (donc on double voire triple le matériel) et donc on paye plus..
Mais j'ai l'impression que l'on ne parle pas forcément de la même chose?
Ma reference au MTTR > MTBF est a comprendre dans le sens des propos de John Allspaw (Etsy) qui l'exprime mieux que moi. Je vous invite a aller lire ses propos a ce sujet.
Il y a egalement un aspect psychologique, des pannes simples mais frequentes (et n'impactant pas le service, hein, on met de la redondance via la scale out et ce qu'il faut, tout de meme) feront que les equipes seront plus sur le qui-vive et plus aptes a repondre a une panne qu'un systeme qui ronronne et qu'on finit par oublier.
Je simplifie a l'extreme son propos mais il y a toujours moyen d'y revenir!
>> Tout à fait d'accord dans le cas d'un progiciel (voir mon exemple sur
>> le cas de l'appli RH plus haut), cela me semble moins vrai pour les
>> composants génériques java de type "enterprise ready".
>
> Je ne suis pas certain de comprendre ce que sont ces composants génériques ni à quoi ils servent..exemple : un composant JMS, un moteur d'EAI/ETL etc
>> deviennent tellement adhérentes au socle déployé que le simple
>> changement de logiciel nécessite un véritable chantier (il n'y a pas
>> de test automatique mise en place dans ces contextes permettant de
>> faire du "refactoring d'infrastructure" en s'assurant qu'il n'y a pas
>> de régression, ce qui impose un chantier de migration manuel pour
>> s'assurer de l'absence des régressions en question).
>
> Cela se comprend quand on aborde cela par l'aspect coût:
> Je pense que lorsque l'on achète un produit (cher en l’occurrence) il faut le rentabiliser. Donc on va bâtir le reste du SI dessus.
> C'est encore plus vrai si le produit est important pour le métier.C'est encore un autre (vaste) debat .
On a déjà pas mal dévié du sujet initial je pense.
--
Cdlt,
Benoit.