L'exemple que j'ai donné est plus orienté grande entreprise où il vaut mieux cloisonner métier / fonctions transverses / volet bureautique car cela correspond généralement à l'organisation rencontrée. Pour des PME, tu peux être tenté de regrouper un peu plus.
L'ETL est plus adapté aux grosses volumétries et permet AMHA, par un moyen technique, de forcer des interfaces standardisées (ou au pire d'avoir pléthore d'interfaces mais centralisées au niveau de l'ETL plutôt qu'en point à point d'appli à appli). S'il n'y a que le 2ème point qui est important pour toi, c'est une première approche d'urbanisation, obligeant à mettre en évidence des flux, qui peut être utile pour des PME par exemple. L'ETL est effectivement un moyen de dupliquer/transformer les données pour les mettre à disposition de manière standard dans plusieurs applications (orienté batch comme je disais).
Mais ce dont tu parles, ressemble plus à une approche référentiel (éviter de dupliquer l'information quand cela n'est pas nécessaire). Etant données les applications que j'ai rencontrées, je n'ai vu une démarche référentiel n'aboutir que dans 2 cas (en gros, beaucoup de monde confond encore référentiel et annuaire LDAP centralisé, alors que l'un est organisationnel et technique là où l'autre n'est que technique). Dans les 2 cas que j'ai vus, en grande entreprise encore, la mise en place d'annuaire a permis de traiter le volet fonctions transverses (RH, gestion des accès aux locaux, annuaire d'entreprise, ...) mais pas le volet métier (gestion client par exemple). Peut-être dans une petite structure est-il possible d'arriver à couvrir tout le périmètre.
Je doute tout de même un peu de réussir à mêler comptes unix, comptes applicatifs, comptes bases de données et les rapprocher des données personnelles, planning d'activité, ... qui font appel à des logiciels ayant des fonctions différentes (et des utilisateurs / finalités différentes). Eventuellement, tracer pour un identifiant unique toutes les déclinaisons dans les différentes applis et proposer quelques données partagées (et partageables...) pour éviter les resaisies et incohérences.
Mais bon, ce n'est pas l'outil qui fait l'organisation : il y a bien 2 projets distincts, l'un purement organisationnel / métier, l'autre technique de mise en place des outils/logiciels ; la technique ne remplace pas l'organisation, même si cela permet d'identifier un défaut d'organisation. Je te laisse googler pour les approches "top-down" et "bottom-up", c'est à la fois plus complexe et beaucoup plus simple que tu pourrais le croire, simplement ça ne se fait pas d'un claquement de doigt et tel un mécano de formule 1 il faut arriver à reconstruire entièrement la voiture lors d'une course, sans que le pilote n'ait à s'en apercevoir ou en soit pénalisé.
[^] # Re: D'ou l'intérêt du premier lien...
Posté par BAud (site web personnel) . En réponse à la dépêche Talend Open Studio 2.0.0. Évalué à 3.
L'ETL est plus adapté aux grosses volumétries et permet AMHA, par un moyen technique, de forcer des interfaces standardisées (ou au pire d'avoir pléthore d'interfaces mais centralisées au niveau de l'ETL plutôt qu'en point à point d'appli à appli). S'il n'y a que le 2ème point qui est important pour toi, c'est une première approche d'urbanisation, obligeant à mettre en évidence des flux, qui peut être utile pour des PME par exemple. L'ETL est effectivement un moyen de dupliquer/transformer les données pour les mettre à disposition de manière standard dans plusieurs applications (orienté batch comme je disais).
Mais ce dont tu parles, ressemble plus à une approche référentiel (éviter de dupliquer l'information quand cela n'est pas nécessaire). Etant données les applications que j'ai rencontrées, je n'ai vu une démarche référentiel n'aboutir que dans 2 cas (en gros, beaucoup de monde confond encore référentiel et annuaire LDAP centralisé, alors que l'un est organisationnel et technique là où l'autre n'est que technique). Dans les 2 cas que j'ai vus, en grande entreprise encore, la mise en place d'annuaire a permis de traiter le volet fonctions transverses (RH, gestion des accès aux locaux, annuaire d'entreprise, ...) mais pas le volet métier (gestion client par exemple). Peut-être dans une petite structure est-il possible d'arriver à couvrir tout le périmètre.
Je doute tout de même un peu de réussir à mêler comptes unix, comptes applicatifs, comptes bases de données et les rapprocher des données personnelles, planning d'activité, ... qui font appel à des logiciels ayant des fonctions différentes (et des utilisateurs / finalités différentes). Eventuellement, tracer pour un identifiant unique toutes les déclinaisons dans les différentes applis et proposer quelques données partagées (et partageables...) pour éviter les resaisies et incohérences.
Mais bon, ce n'est pas l'outil qui fait l'organisation : il y a bien 2 projets distincts, l'un purement organisationnel / métier, l'autre technique de mise en place des outils/logiciels ; la technique ne remplace pas l'organisation, même si cela permet d'identifier un défaut d'organisation. Je te laisse googler pour les approches "top-down" et "bottom-up", c'est à la fois plus complexe et beaucoup plus simple que tu pourrais le croire, simplement ça ne se fait pas d'un claquement de doigt et tel un mécano de formule 1 il faut arriver à reconstruire entièrement la voiture lors d'une course, sans que le pilote n'ait à s'en apercevoir ou en soit pénalisé.