You are not too special

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organization

Conway’s law

Comme l’énonce parfaitement la loi de Conway, nous avons tendance à suivre un biais qui nous amène à percevoir uniquement ce qui rend notre organisation si spéciale. Cependant, les organisations tout comme leurs projets disposent souvent de nombreux points communs entre eux. En réalité, malgré l’apparente unicité de notre projet et de notre organisation, est-il pour autant nécessaire de construire une architecture sur mesure ? Actuellement, nous voyons arriver la deuxième voir la troisième vague de projets de Master Data Management (MDM) et d’Intégration d’Information. Avant de commencer, les décisionnaires sont confrontés à un problème délicat : quelle architecture choisir ?

MDM dit « collaboratif »

Initialement conçu comme une architecture pour les données « produits », ce modèle a rencontré depuis un succès dans les autres domaines. Le concept réside dans la saisie de la donnée dans un seul et même endroit. Puis, tous les systèmes reçoivent une copie des données (single source of truth), ainsi il est plus simple de contrôler la qualité des données. Exemple classique de cette architecture : un CRM comme outil de saisie centralisé qui va ensuite permettre de distribuer les données client dans les autres systèmes. Ce qu’on aime : L’approche simple et transparente pour l’ensemble des utilisateurs. Ce qu’on oublie : Le temps et la qualité de synchronisation sont à surveiller, en outre, il y un besoin important de contrôle des doublons dans cette source (vérification de données avant la création).

MDM dit « consolidation »

Cette architecture avec un arrière-goût de BI est utile si le souhait est d’obtenir des données consolidées sans rien imposer aux systèmes sources producteur des données. L’idée est de laisser certains systèmes tourner de manière indépendante, puis les résultats de saisie dans ces systèmes sont consolidés pour la consommation/restitution par d’autres systèmes (single version of truth, aussi connu en tant que « golden record »). Ce qu’on aime : Pas besoin de modifier certains systèmes, les flux sont créés uniquement pour les systèmes dont on souhaite récolter les données. Il offre l’avantage de mettre à disposition une source propre et unique pour la BI. Ce qu’on oublie : Aucune amélioration de la qualité des données dans les systèmes sources. Par ailleurs, pour une réussite du projet, il est nécessaire d’offrir une excellente qualité de rapprochement et de traitement des données.

Les quatre architectures « pures » peuvent être utilisées seules ou se compléter entre elles suivant les cas d’usages ou les différents types de données. Ainsi, en conditions réelles d’utilisation, vous pouvez utiliser le style collaboratif pour la saisie et la maintenance, tout en permettant au style registre de vérifier la conformité et les flux B2B. Idem, on peut utiliser un style registre en temps réel comme un « back bone » pour les batchs du style consolidation.

Liste non exhaustive des questions importantes à se poser pour réaliser le bon choix :

1. Avez-vous le besoin et/ou le droit de synchroniser les données entre tous les systèmes ? Si « non », les architectures transactionnelle et collaborative ne sont pas faites pour vous.

2. …au moins pour une partie de systèmes ? Si « non », l’architecture registre est votre seul choix.

3. Pouvez-vous modifier les systèmes opérationnels existants ? Si « non », l’architecture transactionnelle « complète » n’est pas compatible car vous pouvez encore faire certaines synchronisations, mais imposer les règles de qualité sera bien plus compliqué.

4. Est-il important de garder le niveau de doublons bas ? La réponse « oui » élimine un certain nombre de solutions techniques sur le marché, mais toutes possibilités architecturales sont encore ouvertes.

5. Est-ce que les « product owners » de tous vos systèmes sont d’accord au niveau des modalités d’échange de données et les processus liés à la modification de données ? « Non » peut éliminer la plupart des approches, sauf le MDM Registre.

6. Est-ce que les systèmes-producteurs de données doivent aussi profiter du projet MDM ? « Oui » élimine le MDM de Consolidation.

7. Vous possédez déjà un MDM et vous souhaitez améliorer la situation ? Identifiez la source du problème – dans l’outil ou dans les processus – souvent il est possible de faire un « patch » pour l’existant.

Le numéro 10, 11, 12 … car il existe encore des dizaines de questions. Pour y répondre, nous pouvons échanger ensemble : contact@cilintir.tech

PS : Nous avons vraiment essayé de ne pas parler de microservices ici …