Archives des Architecture, Data & Transformation - Page 34 sur 34

9 mars 2018

– Lecture de 2 mn

David Couillard

Directeur Transformation Office Management

Une architecture d’entreprise bien conçue est le fruit d’une intelligence collective. Le déploiement des pratiques d’architecture doit aussi être considéré du point de vue humain. Tentative de démonstration en ré-exploitant quelques enseignements de la mobilisation en entreprise.

Pour concevoir et faire évoluer l’architecture du système d’information d’une entreprise, il faut tenir compte de nombreuses préoccupations hétéroclites : métiers, techniques, managériales, financières, réglementaires, etc.

Par leurs efforts, les différents métiers en charge de l’architecture parviennent à définir des architectures cohérentes, alignées avec les différents besoins, à la fois pérennes et évolutives. Une architecture bien conçue est finalement le fruit d’une mobilisation, par laquelle l’intelligence collective opère correctement. Pour aider les architectes d’entreprise, il existe un ensemble de bonnes pratiques permettant de concevoir une architecture adaptée à chaque entreprise, développé depuis plusieurs années. Ces bonnes pratiques sont une extension des pratiques architecturales à l’ensemble de l’entreprise : représenter (modéliser) pour concevoir et partager ; comprendre l’existant pour savoir d’où l’on part ; établir une cible ; établir des bibliothèques d’architectures-types ré-exploitables ; etc.

L’effort d’appropriation de ces bonnes pratiques est souvent focalisé sur la définition des outils de l’architecte (modélisation, patterns, concepts, livrables, etc.). L’appropriation et l’adoption des outils est longue et on la qualifie volontiers « d’évangélisation ». Aussi pertinents ces outils soient-ils, ils ne peuvent pas provoquer la mobilisation de l’intelligence collective à eux seuls. On doit compléter leur déploiement par une série d’initiatives visant à mobiliser les acteurs de l’architecture. Il faut rappeler ce qu’est la mobilisation.

Les différentes formes de la mobilisation

La mobilisation est l’acte intentionnel d’un collaborateur le conduisant à faire des efforts dans le sens d’un travail collectif. D’après Arnaud Bichon, sociologue, on trouve trois formes de comportement de mobilisation, classés par ordre de complexité croissante :

Les conduites relationnelles : ce sont les efforts favorisant la connaissance mutuelle des acteurs et divers types de partage entre eux. C’est le fameux « esprit de corps » des gens du (même) métier qui s’apprécient. Le collaborateur mobilisé est celui qui fait l’effort de tisser des liens, de vivre des expériences avec l’autre. L’inverse, c’est l’individu isolé qui n’engage aucune relation particulière.
Les conduites coopératives : ce sont les efforts spontanés de collaboration, avec des prises d’initiatives dépassant le cadre stricte des obligations. Le collaborateur mobilisé est celui qui travaille délibérément en interaction avec ses collègues et s’implique dans les décisions, qui « partage ». L’inverse c’est la non-collaboration.
Les conduites d’intercompréhension : ce sont les efforts pour construire des représentations communes, comme référence des actions collectives et individuelles.
Le collaborateur mobilisé est celui qui développe une vision globale de l’activité contribuant à « construire avec autrui ». L’inverse, c’est celui qui veut rester dans son cadre de référence.

La mobilisation est provoquée selon deux modalités de natures très différentes, qui se complètent :

Un processus managérial de mobilisation (pratiques RH, prescriptives et descendantes, sous forme d’injonctions) visant à déclencher la mobilisation.
Un ensemble de comportements individuels, « autogènes », à l’initiative du collaborateur.

Plus les formes de mobilisation sont complexes (de 1 à 3 dans la liste plus haut), plus elles sont délicates à provoquer, car elles sont discrétionnaires. L’intelligence collective fait partie de celle-ci. Elle fait parfois dire à des patrons d’entreprises que « la collaboration se constate, mais qu’elle ne se mesure pas », comme une déclaration d’impuissance.

Application à l’architecture

Lorsque l’on déploie les outils de l’architecte (modélisation, patterns, concepts, livrables, etc.) on travaille sur une série d’injonctions visant à provoquer l’utilisation de nouveaux outils. A l’opposé d’une démarche par injonctions, pour que l’intelligence opère, il faut agir sur les comportements, afin de créer des réflexes de collaboration. Il s’agit de créer un contexte favorable.

Dans cette perspective, des actions prioritaires sont à mener en parallèle :

Faire reconnaître la pratique de l’architecture dans le cadre de référence RH de l’entreprise. Il paraît difficile de demander au équipes de réaliser des effort sur une discipline qui ne serait pas reconnue comme telle. Cela nécessité une réflexion, car il n’existe pas de cadre de référence publiée sur le sujet. On trouve n variantes sur le sujet « Architecte » dans le domaine SI. C’est dans le cadre de référence RH que l’on pourra définir les fonctions des « Architectes d’Entreprise » et des points de repère pour formuler des objectifs annuels individuels.
Créer une communauté des architectes, pour provoquer les rencontres et les « conduites relationnelles » qui ensuite seront poursuivies dans le cadre des activités courantes.
Cette communauté peut prendre différentes formes : petits déjeuners débats réguliers, conférences animées par des intervenants internes ou des prestataires, groupes de travail à thème, outils de partage d’information (le « wiki » des architectes), etc.
Développer l’envie de faire de l’architecture, en recherchant et en agissant systématiquement sur les appétences et les freins des acteurs de l’architecture.
On doit pouvoir établir un plan d’action de changement très pragmatique, impliquant les acteurs et leurs hiérarchies, en complément des habituelles réunions d’information. sur l’architecture.
Développer un réseau favorable à l’architecture en identifiant les alliés sur lesquels on peut compter et en leur confiant des initiatives concourant au déploiement de l’architecture.

Je n’ose pas rappeler qu’un soutien, dans les paroles et les actes, de la Direction des Systèmes d’Information, est indispensable pour que l’opération réussisse.

18 décembre 2017

– 2 min de lecture

Architecture

Bruno Tardy

Senior Manager Architecture

Bien que tentante par sa concision et sa fluidité, cette formulation est une chausse-trape tant elle semble précise alors qu’elle est absolument vide de sens. Elle donne l’impression aux parties prenantes de s’être exprimées alors qu’elle masque complètement la réflexion qu’ils doivent mener.

« Faire du temps réel » n’est en effet pas un besoin. On voit tout juste pointer le bout du nez d’une information sur la vitesse de propagation mais c’est une exigence non fonctionnelle qu’il sera nécessaire d’arriver à quantifier, l’ubiquité de la donnée n’étant pas encore accessible. Et ce sera d’ailleurs l’occasion de parler volumétrie, supervision, sécurité.

Et rappelons que le synchronisme n’a rien à voir là-dedans… De nos jours des API complexes vont mettre beaucoup plus de temps à répondre qu’une transmission asynchrone utilisant un outil correctement dimensionné.

Pour être sûr de ne plus faire l’erreur, reprenons les bases

L’important dans la conception d’un échange de données est de comprendre la relation entre le consommateur et le producteur. Et ça, c’est bien les sachants fonctionnels qui sont les mieux placés pour l’exprimer (un accompagnement par une personne exercée peut être utile) :

Qui déclenche le flux ? Est-ce le besoin d’accéder à la donnée -et donc le consommateur- ou le fait d’avoir capté un événement (création, modification d’information) -et donc le créateur ?
Est-on dans le cadre d’une communication bidirectionnelle -question-réponse-, ou unilatérale ?
S’il y a réponse, doit-elle être liée à la question et à son contexte ou garde-t-elle tout son sens et sa pertinence quel que soit le timing de retour ?

Un petit exemple, car je sens que cette phrase absconse peut laisser pantois : Quand je lance un calcul d’itinéraire avec G**gle, la réponse est entièrement liée au contexte d’appel, i.e. ma position. L’information n’a plus de sens si elle arrive trop tard ou si j’ai depuis déclenché une nouvelle demande (si j’ai raté une intersection par exemple). En revanche si je demande le score de Lyon/Paris-Saint Germain d’hier, le contexte de ma demande n’influe pas, je veux la réponse dès que possible, et si cela arrive dans 2 minutes cela m’intéresse toujours !

Il est maintenant clair que ces trois questions dépassent largement la notion de « temps réel ». Délaissez donc cette formulation passe partout et cantonnez-la aux discussions dont le fond n’est pas réellement l’architecture des échanges (et heureusement elles sont nombreuses !).