Avec, comme à l’habitude, sur des sujets aussi stratégiques, une tendance malheureuse à polariser les discussions. Cette polarisation n’a pas lieu d’être : chacune de ces approches a sa part de valeur ajoutée pour le projet.

Je vais m’attacher ici à les expliquer. Rapidement bien entendu – Nous sommes dans le cadre d’un blog.

Mais commençons par rappeler les définitions de broker et portal.

Broker vs. Portal

La définition d’un broker est un peu difficile à établir. Pour s’en convaincre il suffit de regarder les discussions sur différents forums qui s’intéressent à ce qui distingue un broker d’un enterprise service bus (ESB).
Faisons simple et considérons le broker comme un moyen de transférer des données via des messages dans le backend (la partie non visible par les utilisateurs).

Dans le cadre qui nous occupe, un portal peut être vu comme un site web destiné à agréger les accès à divers autres sites web sous-jacents. Un point d’accès central en quelque sorte.

Le projet

Sans le citer nommément, voici maintenant les fondamentaux du projet.

– des acteurs privés, fournisseurs de données, et des acteurs publics, consommateurs de données, avec chacun des besoins propres ;
– les fournisseurs de données sont plusieurs dizaines voire plusieurs centaines ;
– les consommateurs de données sont au nombre de 5 ;
– pour fournir les données, les fournisseurs de données doivent utiliser l’application de tiers (au nombre de 4) – ces tiers sont eux-mêmes fournisseurs d’une partie des données ;
– les consommateurs de données exploitent celles-ci à des fins de contrôle ;
– une obligation de résultats rapide.

La voie initialement choisie a consisté à mettre en place plusieurs bus de données en cascade pour transférer les données des fournisseurs vers les consommateurs.

La première difficulté rencontrée avec cette seule approche est d’arriver à mettre tous les acteurs d’accord sur les différents types de messages à prévoir et sur leur contenu, d’autant plus que les fournisseurs de données vivent le projet comme une obligation (ils doivent se soumettre aux obligations imposées).

Autre difficulté d’importance : les propriétaires des applications doivent chacun compléter leur application avec des écrans de capture pour collecter l’ensemble des données requises par tous les consommateurs. Il faut donc coordonner les efforts de 4 équipes de développement sur des fonctionnalités qui en fait ne constituent pas une valeur ajoutée pour leurs propriétaires (des acteurs du projet finalement gênés dans l’exercice de leur métier par ces obligations).

La difficulté est d’autant plus grande que les 5 consommateurs de données ont des besoins spécifiques. Il s’agit donc de gérer 5 x 4 relations entre partenaires.

Dans un tel contexte, il est évident que les maintenances corrective et évolutive posent de sérieux problèmes, en termes d’obtention des consensus sur les évolutions nécessaires des différentes applications et sur la gestion des plannings de réalisation et de tests. Les disponibilités sont en effet variables selon les acteurs, avec pour corollaire que de manière quasi permanente, au moins un des acteurs est attendu par tout ou partie des autres.

L’addition de toutes ces difficultés a conduit à un allongement considérable du projet.

Approche combinée Broker plus Portal

Après de longs mois de tergiversations multiples, la réflexion suivante s’est imposée : pourquoi ne pas faire en sorte que chacun des partenaires soit responsable de collecter les données dont il a seul l’usage.
Et d’ensuite les partager, via le broker, s’il s’avère que dans le cours du projet, en contradiction avec les analyses de départ, elles peuvent en intéresser d’autres.

Permettre à chacun de développer sa propre application web lui permettant d’obtenir les données qui lui sont propres (comprenez qui n’intéresse aucun des autres consommateurs de données), en complément au broker, a donc finalement été considéré comme une option intéressante.
Sous trois conditions :
– ne pas vouloir obtenir par ce canal une information déjà disponible par un autre canal, ce qui obligerait le fournisseur de la dite information à de l’encodage multiple (respect strict du principe “only once”) – donc, si l’information est déjà disponible via le broker, elle doit être récupérée par ce biais;
– mettre à disposition un seul point d’accès aux différentes applications web via la notion de portal ;
– ne pas obliger les fournisseurs de données à des login multiples (principe du “single-sign-on”).

Cette approche combinée broker plus portal concilie l’ indépendance des acteurs, gage de leur efficacité individuelle, et partage des données. L’approche permet en effet de réduire considérablement les besoins de concertation sur les développements à réaliser et simplifie également la gestion des plannings.

Comme annoncé en début de ce blog, sur base de ces quelques considérations, il est donc facile de conclure que broker et portal sont bien des approches complémentaires.

Un conseil à ce stade : dès le début du projet, établissez un diagramme de contexte complet, dans lequel vous faites apparaître les flux de données entre partenaires. En complément, établissez des fiches qui donnent le détail de ces flux. Vous prendrez ainsi immédiatement conscience de qui est vraiment intéressé par quelles données.

Aspects particuliers

Voyons maintenant quelques aspects particuliers.

Lors de l’échange de données entre partenaires, une problématique de première importance est incontournable : la gestion des anomalies. Sur ce point, le portal apporte son lot d’avantages, en évitant d’impliquer tous les intermédiaires dans cette gestion souvent complexe. En effet, grâce au portal les retours d’anomalies peuvent être gérés sans dépendances vis-à-vis des tiers qui gèrent le broker. La gestion des anomalies est un vaste sujet qui mériterait à lui seul un blog séparé (et bien plus encore).

L’utilisation du format XML, et la définition d’un format canonique pour les échanges, est aujourd’hui un must pour le succès du broker.

En nous appuyant sur les schémas XSD nous avons pu développer un outil de génération de cas de test qui nous a permis de tester rapidement nos développements, sans attendre que nos partenaires soient déjà à même de nous envoyer des messages. Cette initiative a permis de gagner énormément de temps en s’affranchissant de nombreuses dépendances temporelles dans le projet.

A titre d’information cet outil a été développé en s’inspirant de la philosophie des moteurs de règles (externalisation poussée des logiques d’alimentation des templates de messages sous la forme de règles). Il possède de ce fait un caractère générique non négligeable.

A l’issue de ce projet nous pouvons émettre la recommandation suivante : dans un projet d’intégration impliquant des partenaires multiples, obligés de collaborer mais avec des centres d’intérêts plutôt éloignés, il faut veiller à limiter au maximum les dépendances en matière de développement. C’est la meilleure garantie de rester maîtres des délais de réalisation, de maîtriser dans le temps l’évolution du système global et de garder les coûts de maintenance sous contrôle.

La combinaison broker plus portal aide grandement à satisfaire à cette stratégie.

S’agissant de l’approche portal, pour être complet et ne rien cacher des difficultés rencontrées, il nous faut encore ajouter que la mise en place d’un mécanisme de single-sign-on reste un exercice souvent difficile. La diversité des technologies utilisées par les différents partenaires et les différences de niveau de compétences sur le sujet expliquent cela.

La raison d’être d’un data dictionary réside dans la nécessité de construire un vocabulaire commun entre tous les acteurs d’un projet sur l’aspect particulier des données.

Le partage d’un vocabulaire commun facilite la communication entre tous les acteurs du projet. Il constitue un facteur clé de succès pour éviter les ambiguïtés dues à des interprétations différentes des concepts manipulés au sein d’un projet de développement d’application.

La mise en place d’un data dictionary est indissociable de la mise en place d’un glossaire propre au projet. Le data dictionary n’est en fait qu’un subset du glossaire projet.

Plus d’explications dans mon blogpost précédent : “Pourquoi et qu’est-ce qu’un data dictionary ?”

Comment construire un data dictionary ?

La construction d’un data dictionary peut s’appuyer sur quelques notions simples et normalement bien connues.

Le diagramme de contexte

Les premières opportunités pour commencer à alimenter le data dictionary résident dans les flux identifiés via le diagramme de contexte. En effet, les données entrantes et sortantes du système à construire constituent autant d’éléments permettant l’établissement d’un modèle de données métier (business data model). Voir aussi que ces données alimentent indirectement la définition des besoins fonctionnels. En effet, les données doivent être alimentées, consultées et mises à jour. Elles sont aussi l’objet de calculs. Autant de fonctionnalités à prévoir qui ne peuvent être exécutées sans disposer des données (la matière première du métier).

Si le projet couvre plusieurs domaines métiers un diagramme de contexte sera établi par domaine métier.

Le modèle de données conceptuel ou la définition des entités métiers

Pour chaque domaine métier, l’étape suivante est d’établir le modèle conceptuel de données (conceptual data model) en précisant pour chaque classe l’ensemble des entités ainsi que les relations entre classes. Idéalement sous la forme d’un diagramme entités-relations en UML. Comme dit précédemment, l’ensemble de ces données permettra d’identifier l’essentiel des fonctionnalités à prévoir (alimentation, consultation, mises à jour, traitements).

La définition des attributs au sein des entités métiers (modèle de données logique)

La troisième étape consiste à définir la signification de chaque classe, attribut et association du data model. Les définitions données dans le data dictionary devront (idéalement) avoir une valeur universelle dans tout le projet. Si tel n’est pas le cas, et ce n’est pas rare (les significations peuvent varier d’un domaine métier à l’autre), il convient de relever les différentes définitions existantes dans le scope du projet et de les mettre en évidence. Il s’agira alors, dans la mesure du possible, de procéder à une unification. Mais des divergences peuvent devoir rester. Il faut alors impérativement en être conscient et bien entendu les documenter.

La localisation des données (modèle de données physique)

La quatrième étape consiste à préciser la localisation physique des données : dans quelle base de données et quelle table se trouvent les classes et attributs.

Cette étape doit aussi s’intéresser à l’existence de dupliquas éventuels et donc faire la différence entre source authentique (la source dans laquelle se trouve la vérité sur la donnée) et les doublons éventuels.

Les règles métiers

La cinquième étape s’intéressera à l’identification des contraintes et règles métiers (business rules) sur les entités de données.

Quelles informations faire figurer dans le data dictionary ?

Le contenu du data dictionary découle des explications données au point précédent :

Pour chaque domaine métier, le context diagram et le modèle conceptuel de données.

Pour chaque classe du modèle entités- relations (qui formalise le modèle conceptuel de données), l’ensemble des attributs.

Pour chaque classe et chaque attribut, un nom et une définition claire (donc non ambigüe et éventuellement multilingue).

L’ensemble des relations entre les classes.

Pour chaque relation un nom et une définition claire (non ambigüe et éventuellement multilingue).

Pour chaque classe la liste des moyens d’alimentation, de mise à jour et de consultation.

Ceci suppose de recenser :

• l’ensemble des data flows (qui devraient avoir été recensés lors de l’établissement du diagramme de contexte) – de type batch (flat files ?) ou remote  (web services ?);
• l’ensemble des écrans (inventaire élaboré au fur et à mesure des itérations sur le projet) – on parlera de services de présentation dans le cadre d’une architecture SOA.

Autres informations possibles :

• les limitations de droit d’accès sur les données sensibles. Mais ceci demande d’avoir identifié les rôles métier dans l’organisation. Remarque : ceci montre encore une fois que l’approche par les données permet la découverte organisée de toute une série d’informations de première importance pour l’analyse fonctionnelle.
• les tags XML utilisés dans les échanges au format XML si d’application.

Quels moyens pour la mise en place du data dictionary ?

L’établissement des diagrammes de contexte et des diagrammes de classes sera réalisé avec un outil de dessin de type Visio ou, plus élaboré, Enterprise Architect, Visual Paradigm ou autre.

Les définitions sur les classes / attributs et le recensement des moyens d’accès sera réalisé dans un document Word par domaine métier ou dans un fichier Excel, les deux pouvant être complémentaires.

Les documents seront publiés dans un repository de type CMS. SharePoint par exemple.

Une mindmap comme point d’entrée peut être utile pour faciliter la navigation entre les domaines métiers et les entités.

– un facteur clé de succès (pour éviter les incompréhensions et les ambiguïtés) ;

– un gage de productivité (pour éviter que chacun ne doive se livrer aux mêmes recherches sur le sens des différents concepts intervenant dans le projet) ;

– un gage de qualité en uniformisant toute une série de conventions et contraintes à respecter par tous, ceci en vue d’éviter les interprétations divergentes.

Cette problématique est adressée en construisant un glossaire projet.

Un data dictionary n’est rien d’autre qu’un subset de ce glossaire, dont le scope est centré sur les données, matière première des applications à construire.

Un data dictionary est un repository qui contient des données sur les données (soit des méta données).

Les données traditionnellement stockées dans un data dictionary sont, sans être exhaustif :

• les noms des entités de données et les tables correspondantes de la ou des bases de données ;
• les attributs des entités et les colonnes correspondantes dans les tables ;
• les relations entre entités ;
• les dupliquas éventuels (auquel cas il convient de préciser la source maître) ;
• la signification métier des données, éventuellement dans plusieurs langues ;
• les domaines de valeurs si des contraintes existent de ce point de vue ;
• les autres contraintes (telles que les contrôles croisés entre données);
• les libellés à utiliser dans les écrans ;
• les dispositifs d’alimentation et de consultation ;
• les schémas XSD éventuels;
• …

Il est facile de comprendre que la présence d’un data dictionary aura un effet significatif immédiat sur les équipes de développement. Ainsi, par exemple, les développeurs sauront où aller chercher les données et quels intitulés leur donner dans les écrans. De même, quels contrôles appliquer dans les écrans d’encodage. Le data dictionary peut aller jusqu’à inclure les traductions des libellés dans les différentes langues utilisées par l’organisation.

Faut-il insister sur les heures perdues par tout un chacun lorsqu’une information vitale pour l’exercice de son activité est absente ou difficile à localiser ? Faut-il mettre en évidence les heures perdues à chercher et rechercher une information sortie de sa mémoire en interpellant / distrayant régulièrement des collègues (avec les effets collatéraux sur la productivité de ceux-ci) ou en « fouinant » dans une documentation de qualité médiocre ?

Faut-il aussi insister sur les effets absolument pervers de documentations personnelles construites par les uns et les autres sur de l’information en fait utile à tous ? Elles sont le plus souvent parcellaires, dispersées et soumises à interprétation personnelle, avec bien entendu des risques de désynchronisation par rapport à la dernière vérité et toutes les conséquences qui peuvent en découler en termes de divergence dans les implémentations des différentes parties d’un même projet.

Beaucoup d’efforts dans le cadre du master data management pourraient sans doute être épargnés si une attention plus grande était portée à l’effort transversal de documentation sur les données.

Les approches Agile, qui mettent exagérément l’accent sur la réduction du « time to market » au détriment de la qualité et de la documentation ne contribuent malheureusement pas à aller dans ce sens. Avec inévitablement des conséquences sur ce que j’appellerai “la dette fonctionnelle sur les données” et les efforts qui devront être fournis pour la corriger. Mieux vaut prévenir que guérir.

Dans le cadre des dispositifs B2B destinés à supporter les échanges entre partenaires, la présence d’un data dictionary est un facteur de succès déterminant. Comment en effet faire adhérer l’ensemble des partenaires à un format canonique sur le bus d’échange si celui-ci n’est pas clairement défini dans un data dictionary. Le glossaire de données (c’est le nom que nous lui avons donné) mis en place pour la Sécurité Sociale belge est là pour en témoigner. Vu le nombre d’intervenants impliqués, ce dispositif s’est avéré indispensable pendant la phase de développement et tout autant aujourd’hui dans les opérations de maintenance trimestrielle.

Bien entendu les efforts liés au data dictionary se doivent d’être « raisonnables », pour garantir le retour sur investissement d’un strict point de vue budgétaire. Comme pour toute initiative transversale, tout ce qui est fait doit être directement utile aux projets. Cela suppose une attention permanente à la maîtrise de sa complexité pour en garantir la facilité d’utilisation et de maintenance, sans quoi il sera vite abandonné par ceux que l’on veut servir.

J’espère vous avoir convaincu que le data dictionary, et au delà le glossaire d’enterprise, sont des initiatives transversales amplement justifiées. Elles ont un coût, certes, mais leur retour sur investissement est prouvé.

Dans un prochain blog nous nous intéresserons à la manière de construire un data dictionary.

Nous avons insister sur le fait que ces deux fonctions doivent être vues comme étant des rôles, une même personne pouvant, selon la phase du ou des projets en cours, occuper tantôt un de ces deux rôles et tantôt l’autre. La taille de l’organisation est le déteminant principal quant à la distribution ou non de ces deux fonctions sur des personnes distinctes .

Par rapport au processus RUP, nous avons situé les interventions du business analyst dans les phases d’inception et d’elaboration.

Une fois arrivé le temps de la construction phase, il est temps de changer de casquette (ou de faire intervenir les functional analysts, qui agissent alors dans la continuité des business analysts): place à l’analyse fonctionnelle, dont le but est d’entrer dans le détail de ce qui a été fait dans les phases précédentes. Vous l’aurez compris, la phase précédente correspond à une préoccupation de cadrage / définition soignée du projet pour garantir l’alignement business case / projet, au juste niveau de détail.

On entre ici, et selon moi seulement ici, dans le vrai pré carré de l’approche agile, avec la souplesse et la réactivité aux adaptations sur les requirements qui la caractérise.

Il s’agit maintenant de détailler les use cases, de définir les layouts et contenus d’écrans, les règles métiers relatives aux calculs (via langage naturel ou tables de décision), les modèles de données logiques, d’établir les scénarios de test détaillés. Le détail des use cases pourra être élaboré en s’appuyant sur la notion de user stories (voir Visual Paradigm par exemple), concept propre aux méthodes agile, et qui serviront à alimenter le product backlog selon la méthode Scrum.

C’est aussi maintenant que sont spécifiés dans le détail tous les éléments réutilisables (services [called] et librairies [embedded]).

A ce stade la collaboration entre le business analyst et l’enterprise architect est maximale : il s’agit pour ces deux rôles de définir précisément l’architecture SOA à mettre en place , en faisant intervenir les notions de taxonomie et de typologie de services (nous n’entrerons pas dans l’explication de ces notions ici – un autre blog peut-être). J’insiste sur ce point : la réussite de la mise en oeuvre d’une architecture orientée service est d’abord le résultat d’une collaboration réussie entre business analyst(s) et enterprise architect(s).

Au delà de l’architecture de services, business analyst(s) et entreprise architect(s) doivent aussi veiller à établir et à maintenir la cartographie applicative et des données (relevé des applications et des services, alimentation du data dictionnary, …).

Point d’attention : des découvertes effectuées pendant la construction phase peuvent devoir être remontées au niveau des documents produits par la business analysis.

Je voudrais aussi insister dans ce blog sur le parallèle suivant : de la même manière que l’on attribue aujourd’hui, de plus en plus, toute l’importance qu’elle mérite à la gestion du code (naming and coding conventions, structuration des projets, gestion de version, visualisation des différences entre versions, quality metrics, peer review, …) il convient d’en faire autant avec les délivrables de l’analyse (la recommandation n ‘est pas nouvelle !). De ce point de vue, je suis amené à constater que les approches agile tentent à un certain laxisme, pour ne pas dire plus, sur la gestion de la qualité de la documentation.

Les mêmes concepts doivent être d’application pour l’analyse : la documentation doit être standardisée, maintenable, pérenne, comprise par ses destinataires, aujourd’hui et demain aussi. La documentation du niveau business en particulier est LE pilier du transfert et donc du maintien de la connaissance métier dans l’organisation. Le passage de témoin entre les générations de collaborateurs l’exige.

Ceci est d’autant plus important lors de la présence d’intervenants extérieurs : trop nombreux sont ceux qui pratiquent le “freestyle” (à chacun sa(ses) manière(s) de faire), attitude entretenue par la mode agile, quand cela ne correspond pas à un objectif caché de verrouillage sur les connaissances nécessaires pour être à même de piloter les développements IT et se rendre indispensables sur le long terme dans l’organisation.

Au sujet du repository pour les documents d’analyse, les offres cloud permettent de ne pas s’encombrer avec la gestion technique de ceux-ci. Mais il convient alors de prendre les précautions nécessaires en matière de sécurité des données, tous aspects confondus. Et sans oublier que placer dans le cloud des savoir-faire métiers qui offrent des avantages concurrentiels n’est jamais une bonne idée.

Une comparaison pour aider à la compréhension sur la distinction entre les deux rôles de business analyst et de functional analyst : le binôme business analyst / functional analyst est comparable au binôme enterprise architect / application architect. La différence entre ces deux niveaux de fonction relève de l’importance du scope à balayer et consécutivement du niveau de détail moins élevé attendu des deux premières. Business analyst et enterprise architect sont les garants de la prise en compte globale et donc, par extension, de l’optimisation globale et de la réutilisation, sur les données et sur le code.

En conclusion : la prise en considération des distinctions entre ces deux rôles de business analyst et functional analyst est une assurance pour un équilibre judicieux entre l’approche plutôt Waterfall (cadrage et préparation) et l’approche résolument  Agile (réactivité aux changements en cours de développement).

Et dernière réflexion : lors de l’élaboration d’un plan directeur informatique, qui se doit d’avoir pour tout premier objectif l’alignement de l’IT sur le business, les business analysts sont à l’évidence des fournisseurs d’information de tout premier plan. Au même titre que les enterprise architects.

Si la nécessité de la fonction d’analyste fonctionnel (functional analyst) est universellement reconnue dans la sphère IT, la fonction de business analyst est plus méconnue et la distinction entre les deux fonctions souvent mal comprise.

Je vais tenter ici de la clarifier. Bien entendu, dans le cadre d’un blog, je ne peux que survoler le sujet.

La vision dégagée ici est celle mise en place dans le cadre d’une institution de Sécurité Sociale occupée à refondre son système IT et qui a mis en place une équipe de 6 business analysts. Elle est donc propre à cette organisation.  Je suis actuellement responsable du coaching de cette équipe.

Tout d’abord, il convient d’insister sur le fait que ces deux fonctions doivent être vues comme étant des rôles, une même personne pouvant, selon la phase du ou des projets en cours, occuper tantôt un de ces deux rôles et tantôt l’autre. La taille de l’organisation et donc souvent, par voie de conséquences, l’étendue des domaines fonctionnels,  est évidemment déterminante quant à la distribution ou non de ces deux fonctions sur des personnes distinctes .

Mais en tous les cas, elles doivent veiller, selon moi, à ne porter qu’une seule de ces deux casquettes à un moment donné. La raison principale est que les deux rôles ont des publics cibles prioritaires  différents.

Dans le cadre d’un premier blog sur le sujet, intéressons-nous d’abord aux responsabilités et aux outils nécessaires au business analyst. Un second blog , à paraître plus tard, explicitera davantage la distinction entre les deux rôles.

Le business analyst est responsable:

• De travailler sur les business case avec le(s) chef(s) de projet
• Une fois un projet identifié, d’établir le scope document correspondant en collaboration avec le chef de projet désigné
• Sur ce point l’établissement d’un diagramme de contexte (context diagram) est un must.
• D’identifier et formaliser  les processus métiers à haut niveau de manière transverse, internes et externes (B2B), en ce compris les traitements des exceptions (!)
• L’un de ses outils privilégié sera donc un process modeler, idéalement basé sur le langage de formalisation BPMN (dont l’utilisation sera limitée aux fonctionnalités de base). Il devra être attentif à bien identifier/distinguer les sous-processus d’un processus principal, ce afin  de préserver une vue holistique permettant la maîtrise du tout par une approche drill-down (du général vers le détail).
• Au sein des processus et sous-processus il identifiera les tâches à accomplir (un processus n’est jamais qu’une succession de tâches), soit les high level use cases. L’identification de ces tâches lui permettra de découvrir la “matière première” des traitements  à effectuer, à savoir les données.
• Sur les tâches et les données, en tant que business analyst, son rôle se limite à établir une définition high level (comprenez sans excès de détails). Ainsi, il se doit :
  • D’établir le modèle de données conceptuel
  • D’établir un glossaire des termes métiers en vue de normaliser le vocabulaire employé lors des communications entre les différents acteurs (je reviens un peu plus loin sur ce point)
  • D’identifier les acteurs, rôles et responsabilités (indispensable pour la définition de la sécurité applicative)
  • D’identifier les évènements déclencheurs des processus, les données en entrée et en sortie, les règles métiers de transition entre les tâches
• De challenger les solutions actuelles et en particulier de relever toutes les possibilités de simplification – the business analyst must be a no added value killer (lean approach) !
• De relever les opportunités de réutilisation sur base de la connaissance métier (à l’inverse des architectes qui le font plutôt sur base de la connaissance des assets techniques).
• D’établir le glossaire métier en vue de mettre en place un vocabulaire partagé entre tous les acteurs – cette activité a toute son importance : à elle seule la non standardisation du vocabulaire employé dans les discussions peut être la cause  d’opportunités de réutilisation manquées. Et, faut-il le dire, de réunions inefficaces, suite à des incompréhensions dont le plus regrettable est qu’elles ne sont que rarement avouées (sur ce point, faut-il le dire, les responsables hiérarchiques ont un rôle d’exemple à jouer).
• D’alimenter le data dictionnary (cette activité est indissociable de la précédente) – le maintien d’un data dictionnary est à mes yeux une tâche essentielle des business analysts.
• De détecter les mesures à même d’augmenter la qualité et la cohérence des données (unicité).

Le business analyst joue un rôle clé en matière d’élaboration des scénarios de test : il est responsable de vérifier que les UATs (User Acceptance Tests) garantissent le bon alignement de la solution développée sur les besoins exprimés dans la  business analysis.

La formalisation des business process, des use cases et du modèle de données conceptuel requière idéalement un outil de design BPMN/UML accompagné d’un repository permettant la gestion de version et la centralisation de tous les artefacts produits. L’outil devra permettre la génération de documents Word sur base de templates customizables. Point d’attention : la facilité de mise en oeuvre de ces templates est fort variable d’un outil à l’autre – il  s’agit là d’un différentiateur important en termes de  productivité et d’efficacité dans la communication avec les autres parties.

Le business analyst doit être capable d’élaborer tout à la fois:

• D’une part, les documents nécessaires à la validation par les expert métiers : mind maps (très utiles à la capture et la première organisation des idées), documents Word agrémentés de schémas, présentations PowerPoint,  tableaux Excels, … bref une démarche que je qualifierai de “low tech”;
• D’autre part, les documents servant à préparer le travail du functional analyst – ceux-ci font un usage plus important du formalisme UML – la démarche sera ici de type “mid tech”.

Il convient d’insister sur la nécessité des échanges fréquents entre les business analysts travaillant sur des domaines fonctionnels différents. Les optimisations doivent en effet être globales et non pas locales aux domaines fonctionnels. Un rôle de coordinateur est à prévoir (espérer ne suffit pas – il faut provoquer ce que l’on veut obtenir).

Le business analyst se doit encore d’être :

• L’aiguillon du business pour entretenir une démarche de progrès permanent dans la maintenance des processus métier et des modèles de données ;
• L’avocat du business vi-à-vis de l’IT, par l’intermédiaire de l’enterprise architect et du(des) chef(s) de projet(s).

Enfin, le business analyst doit être le bibliothécaire de la connaissance métier : il est responsable de la qualité de la documentation métier et de sa bonne gestion. Il veillera donc à la fois à la standardisation et à la qualité des documents d’analyse, de même qu’à la standardisation et à la qualité de son organisation au sein d’un (ou de plusieurs) repository. La règle en or : un artefact quel qu’il soit doit être facilement localisable et interprétable par quiconque dans l’organisation.

Dans le cadre du processus RUP (que je me refuse personnellement à oublier malgré une forme de déferlante au tout à Scrum – les deux sont en fait complémentaires), le business analyst intervient donc en amont, sur les phases d’inception et d’elaboration.

La qualité constatée du monitoring opéré par le fournisseur et le projet impliquant par ailleurs de nombreux intervenants, et nécessitant des intégrations avec d’autres systèmes, la dilution des responsabilités résultante nous a obligé à reprendre en mains, en tant que maître d’œuvre, la construction de la solution de monitoring ainsi que son exploitation.

Nous avions initialement mis en place une solution commerciale indépendante, elle-même en mode SAAS, pour monitorer les urls de base, mais l’expérience nous a montré (si besoin était) que ceci est largement insuffisant. Ainsi, pour donner deux exemples parmi d’autres, un problème sur la base de données et un autre relatif à un tiers n’ont pu être mis en évidence … autrement que par les utilisateurs.

Une solution de monitoring a donc finalement dû être développée et opérée en interne pour être à même de détecter (tous ?) les problèmes potentiels vus du point de vue de l’utilisateur final.

Bref, en synthèse, il s’est agi d’éviter un manque de couverture en termes de monitoring par le fournisseur SAAS, qui aura naturellement tendance à limiter son intervention en la matière au seul bon fonctionnement de sa plate-forme vu du point de vue trop exclusif de l’infrastructure sous-jacente (saturation du processeur, capacité disque, opérations de lecture /écriture…), sans se préoccuper suffisamment de tout l’ensemble des problèmes pouvant affecter l’utilisateur final et du bon fonctionnement avec les applications partenaires.

Notre conclusion: en mode SAAS, il faut redoubler de vigilance non seulement sur la sécurité, mais aussi sur le monitoring, point d’attention sans doute trop peu abordé dans le discours ambiant.

C’est en particulier vrai en cas d’intégration avec d’autres systèmes, sujet particulièrement brûlant en cas de changement de version (la bonne gestion des dépendances est alors un enjeu majeur).

Ce sujet du cloud monitoring nous amène aussi sur tout ce qui touche, dans une vue plus large, à l’importance des activités dites de cloud brokering (ou cloud brokerage).

Le cloud brokering couvre les activités qui vont permettre de faire interagir entre eux différents clouds et d’aider à la gestion de l’ensemble.

Il s’agit, sur un ensemble de solutions IaaS, PaaS et SaaS, distribuées dans des clouds privés ou publics, de mettre en place une solution unifiée permettant, par exemple, des fonctionnalités de :

• Service catalog
• Integration (entre solutions cloud et/ou avec le backend)
• Provisioning
• Security
• Single sign on
• Administration
• Monitoring
• Reporting
• Support
• Billing
• …

Ces activités sont  souvent prises en charge par un fournisseur externe qui s’est spécialisé dans le cloud brokerage – un Cloud Service Broker (CSB).

Vous l’aurez compris, il s’agit ici de porter dans le cloud des activités autrefois confinées intramuros.

Toute organisation ayant compris que :

• les TICs constituent aujourd’hui un levier indispensable à leur développement, sinon même à leur survie ;
• que le cloud peut leur permettre de réduire leurs coûts, se doivent : 
  • soit de développer des compétences dans le domaine du cloud brokering ;
  • soit de s’assurer les services d’un prestataire extérieur soigneusement choisi (pour rappel, un Cloud Service Broker – CSB), eu égard aux enjeux dont il est question ici (seulement mentionner la sécurité devrait suffire à vous convaincre).

Ceci m’amène également à la prévision suivante : il est à craindre que les silos intramuros finissent sur le long terme par trouver leurs équivalents dans le cloud.

Cela me semble d’autant plus vraisemblable que, légitimement, les activités métier voudront exploiter, si la décision est prise d’externaliser, les meilleurs solutions en mode SaaS, la solution 1  étant dans le cloud A et la solution 2 dans le cloud B. Le cloud A pouvant être privé parce que la solution 1 aura peut-être fait l’objet d’une acquisition par voie de licence alors que la solution B reste louée.

Un conseil à partir de cette dernière remarque : prévoyer dans vos futurs cahiers des charges, chaque fois que possible, les deux modes d’acquisition location (SaaS) et acquisition (licence) . C’est en particulier vrai lorsque le nombre d’utilisateurs croît dans le temps. Au-delà d’un certain seuil il peut devenir plus intéressant de basculer vers le mode acquisition. A ce moment vous pourrez déplacer l’application vers votre cloud privé.

Ce risque sur les silos dans le cloud est une raison supplémentaire de s’intéresser aux solutions de cloud brokering, en vue d’éviter les îlots fonctionnels du passé, les sous optimisations globales résultantes au niveau du métier , et les coûts de maintenance et d’exploitation extravagants au niveau de l’IT.

Indiscutablement, les enterprise architects doivent investir sur ce sujet.

Source de promesses, car les moyens disponibles aujourd’hui permettent d’améliorer notre réactivite et notre efficacité : Internet est un catalyseur phénoménal de l’intelligence collective et permet de trouver rapidement de nouveaux partenaires, les TIC sous toutes leurs formes  permettent en permanence l’accès à l’information de toutes natures, facilite le travail collaboratif et aident à  réduire les temps de réaction en cas de crise ou d’accidents, etc.

Source de menaces, car les idées et les recettes  s’échangent de plus en plus vite. La concurrence peut en effet surgir très vite de n’importe où, à n’importe quel moment, et de plus en plus souvent sans signes annonciateurs facilement détectables.

Il ne fait plus de doutes que les entreprises triomphantes de demain seront celles qui sauront trouver et exploiter rapidement les meilleures idées. “Pas nouveau” me direz-vous. Certes, mais l’important est de percevoir que c’est de plus en plus vrai.

Cet impératif exige pour les entreprises d’améliorer sans cesse la collaboration entre tous les acteurs de son domaine, qu’ils soient internes ou externes, et souvent aussi complètement inconnus à un moment donné.

La conviction suivante émerge et se renforce rapidement : la première des priorités n’est plus la course à la productivité ou à l’innovation. La première des priorités est aujourd’hui à la collaboration, les deux autres, évidemment aussi importantes, en étant des retombées naturelles. Il s’agit en fait de changer de point de vue.

Augmenter la collaboration demande une révision sérieuse de plusieurs dimensions dans l’entreprise.

Style de management, culture, organisation/processus, incitants et outils doivent être revisités.

Quelques réflexions suivent sur les différentes dimensions.

Sur le plan du management il faut accepter plus de décentralisation. Mais chaque opportunité de décentralisation fera l’objet d’une décision au cas par cas.
Le management doit communiquer clairement :
– les objectifs et critères de décision – il s’agit d’un facteur essentiel à une décentralisation réussie (l’autonomie accordée doit absolument être cadrée – la confiance ne peut évidemment exclure un certain niveau de contrôle);
– les raisonnements ayant conduit aux décisions – il s’agit d’un facteur essentiel à l’acceptation par les équipes et à leur résilience (frustrations mieux gérées).

Sur le plan de la culture il faut accentuer :
– l’importance accordée aux objectifs collectifs et donc accentuer le fonctionnement transversal;
– les signes de reconnaissance individuels et collectifs.

Sur le plan de l’organisation et des processus, il faut mieux partager les ressources et donc lutter contre le travers possessif de nombreux cadres intermédiaires.
Le partage réussi des ressources demande des moyens uniformisés, en particulier un vocabulaire commun, indispensable pour éviter le “dialogue de sourds” lors de la mise sur pied d’équipes ad hoc, construites à partir de ressources n’ayant peut-être jamais travaillé ensemble.
Encourager la vraie collaboration c’est aussi indirectement encourager la créativité, donc injecter de l’entropie supplémentaire dans le système, donc du chaos et à fortiori des risques supplémentaires.
Ceci doit être contrebalancé par des processus décisionnels exhaustifs, une attribution claire des responsabilités et une gestion des risques résolument proactive. Le dernier point est absolument fondamental et sera utile à la motivation des refus.

Les incitants doivent être tels qu’ils incitent à la collaboration plutôt qu’à la compétition. Une révision des méthodes d’évaluation, souvent trop orientées vers les objectifs individuels, est nécessaire.

Du côté des outils, il faudra introduire de nouveaux moyens comme, à titre d’exemples, une plate-forme d’idea management, un média social, une plate-forme de gestion de processus, le cloud computing pour une mise à disposition rapide des outils IT et pour renforcer les possibilités de collaboration dans les équipes géographiquement fortement distribuées et/ou à caractère (très) temporaire.

Toujours dans la dimension outils, une démarche architecture d’entreprise (métier et technique), permettra de garantir un cadre global cohérent et sera, comme la gestion des risques, utiles à motiver les refus. Elle contribuera aussi au vocabulaire commun et constituera un vecteur de communication devenu indispensable entre le métier et l’IT.

La nature humaine étant ce qu’elle est, tous les collaborateurs n’adhèreront évidemment pas à ce changement de culture. Ce n’est pas nouveau. Qu’importe.  L’enjeu est bien trop important.

Ces idées sont-elles applicables dans le secteur public? Ce serait faire injure à vos collaborateurs que de vouloir ne pas le croire. Si les enjeux d’innovation sont moindres , les enjeux d’amélioration sont quant à eux tout aussi importants. Ainsi, imaginez par exemple ce que peuvent vous apporter vos collaborateurs, dans le cadre d’une politique volontariste de simplification administrative au bénéfice des usagers.

Ce blog pour introduire une lecture fort intéressante : http://thecollaborationimperative.com/the-book/

Merci à ses auteurs … et bonne lecture.

En effet, la complexité, tout autant que la variété et la vitesse d’évolution des solutions mises en oeuvre demandent régulièrement la mise en place d’équipes spécialisées. Parce que leur maîtrise, j’entends par là la capacité à une mise en oeuvre réellement efficiente, est devenue quasiment impossible au sein de chaque équipe qui doit pouvoir en faire usage.

Résultat immédiat : une multiplication des équipes de support (dites quelquefois transversales).

Conséquences : une dépendance accrue des équipes de projet vis-à-vis de ces équipes de support, en profondeur (elles sont les seules à savoir, ou à pouvoir [questions d’autorisations] intervenir sur les technologies dont elles sont dépositaires), et en largeur (elles se multiplient comme déjà dit).

Inutile de dire que la multiplication des dépendances a pour corrolaire immédiat que :
– l’équipe de projet est de plus en plus souvent dans l’attente d’un délivrable (un serveur, une base de données, un jeu de données de test, un service au niveau d’un application server, un pipe sur  l’ESB, un processus sur le  BPM, le déploiement d’un outil, une configuration quelconque, …) ;
– l’intégration devient un cauchemar en termes organisationnels (il manque toujours quelque chose ou quelqu’un);
avec les conséquences qui s’ensuivent en termes de délai et de coûts, en développement proprement dit et souvent tout autant en maintenance.

Je vois encore deux autres facteurs d’inquiétude :
– les équipes de support sont naturellement moins impliquées que les équipes de projet sur la question de l’orientation sur le résulat pour le client (une forme d’application du principe “[plus] loin des yeux [plus] loin du coeur”) – osons le dire en des termes appropriés, la vie dans les équipes de support est souvent moins stressante que dans les équipes de projet;
– la lassitude guette les équipes de projet, avec son risque apparenté, le désengagement.

Et donc je n’hésite plus à poser la question suivante : ne faudrait-il pas en revenir, pour partie en tous les cas, à des feature teams, soit des équipes dotées de tous les moyens nécessaires à l’accomplissement de leurs missions au bénéfice de leurs clients directs?

La définition suivante (voir www.featureteamprimer.org) va dans ce sens, avec les réserves voulues sur les défauts cachés du développement agile poussé à l’extrême.

Le but de ce blog n’est évidemment pas de traiter le sujet en profondeur. Je me contenterai donc de quelques premières et rapides réflexions sur le sujet, à travers l’exercice des “dix principes”.

1. La standardisation garde du sens sur les outils stratégiques.
2. La standardisation doit être plus qu’intramuros. Elle doit aussi s’appliquer entre partenaires “privilégiés”.
3. A contrario, la standardisation ne doit pas être  dogmatique sur les outils non stratégiques pour tous les feature teams, sauf à réduire les coûts de licences (crise oblige). Sur le plan tactique, des zones de liberté riment avec agilité /efficacité (l’histoire militaire, par exemple, l’a amplement démontré).
4. La standardisation est un must au sein d’un feature team.
5. Sur les outils stratégiques chaque équipe doit posséder les compétences voulues. Une stricte dépendance vis-à-vis des équipes de support est à proscrire.
Dit autrement, les équipes de support doivent être et rester des équipes de support. Elles ne doivent pas nourrir les dépendances.
6. Les équipes de support n’ont pas nécessairement vocation à devenir “éternelles”. Un outil stratégique devenu banal ne mérite peut-être plus une équipe de support. Il faut savoir “nettoyer”.
Une équipe de support dans la durée n’a peut-être de sens que sur les technologies rarement utilisées par les équipes de projet, et pour lesquelles le maintien de la maîtrise dans la durée s’avère impossible par manque de pratique.
7. L’introduction d’un nouvel outil stratégique se fait via une équipe dédiée. Dans un premier temps, l’équipe de support reste seul maître de la nouvelle technologie, avec la volonté de diffuser  rapidement les compétences vers les équipes de projet utilisatrices en vue de les rendre indépendantes.
8. Les “principes” évoqués ici sont valables tant pour l’infrastructure que pour le développement.
9. Le management doit s’intéresser aux approches “converged infrastructure”, en vue de réduire le besoin en spécialistes pointus induits par les architectures (trop) distribuées et faciliter la mise à disposition et la redistribution des ressources.
10. La mutualisation des moyens entre partenaires doit être encouragée. Elle contribuera à réduire les dépendances de nature technique.

En espérant que ces quelques lignes contribueront à alimenter votre réflexion sur les problématiques de la standardisation et de l’agilité.

Une lecture conseillée sur le sujet (concise et claire) : https://s3-eu-west-1.amazonaws.com/geantsduweb.com/uploads/download/downloadable/33/octo-gdw-feature

SQLite est une base de données relationnelle livrée sous la forme d’une librairie. A la différence des bases de données traditionnelles, SQLite ne s’exécute pas en tant que processus standalone, appelé par les applications clientes, mais est liée à et donc partie intégrale (embedded) d’une application cliente. L’application cliente interagit avec SQLite par le biais de simples appels de fonctions, ce qui contribue à réduire la latence lors des accès aux données – Nous sommes ici en single et non en inter-process communication.

SQlite est ACID compliant et supporte les ordres SQL-92 standards fondamentaux, en oubliant volontairement les ordres « ésotériques » peu utilisés par les développeurs. Ceci va dans le sens de la philosophie générale  du produit dont les maîtres mots sont, dans l’ordre : robustesse, administration simple, faible occupation-mémoire, vitesse et  fonctionnalités. Dans ses premières versions elle supportait les accès concurrents en lecture mais pas en écriture. Depuis la version 3.7 cette restriction peut être levée en activant le WAL (Write-Ahead Logging –  mécanisme de gestion des modifications qui écrit d’abord dans un fichier de log avant de les appliquer sur la base de données).

Etant donné sa compacité (+/- 350 KB – dépendant de la plate-forme et du mode de compilation [32 ou 64 bits]) et sa philosophie « zero administration », SQLite est très largement utilisée dans les mobile devices et les systèmes embarqués, limités par la mémoire et la puissance du processeur.

SQLite est bien appropriée pour les phases de développement et de test, ou pour des démonstrations, là où installer une vraie base client/serveur peut s’avérer finalement trop lourd et compliqué par rapport aux objectifs poursuivis.

SQLite est bien appropriée pour les phases de développement et de test, ou pour des démonstrations, là où installer une vraie base client/serveur peut s’avérer finalement trop lourd et compliqué par rapport aux objectifs poursuivis.

Des outils gratuits sont disponibles pour visualiser et gérer la base de données. Citons en particulier le plugin Mozilla SQLite Manager et SQLite Personal Manager.

Un soin très poussé est apporté au testing du produit : environ 60% du code écrit pour SQLite existe seulement pour raison de test. Le plus gros de ce code de test est écrit en Tcl. SQLite est réputé « 100 % branch test coverage ».

De même, malgré son caractère open source, SQLite est très contrôlé en matière de contribution. Il faut savoir que beaucoup d’acteurs utilise SQLite sans publiquement le dire. Les avocats de ces éditeurs veulent évidemment éviter que ne surviennent des problèmes de non-appartenance du code.

SQLite fait maintenant partie de PHP5, ainsi que de Mac OS X.

SQLite offre des APIs pour de nombreux langages : Basic, C, C++, Tcl, Java, Lua, PHP, Python, Javascript, R, REBOL, …

Une caractéristique importante du produit est le variable length record. Alors que la plupart des RDBMs alloue de l’espace disque en fonction de la longueur déclarée des données stockées, SQLite utilise l’espace strictement nécessaire. Ceci offre des avantages immédiats en termes de compacité  et de performance, étant donné que moins de données sont déplacées du et vers le disque. Autre avantage : le manifest typing plutôt que le static typing (en particulier intéressant si vous utiliser un langage qui supporte le type Variant – mais cette liberté présente ses dangers).

La principale limitation de SQLite porte sur la commande ALTER. Elle permet  juste d’ajouter une colonne à la fin d’une table ou d’en changer le nom. Des opérations plus complexes sur la structure d’une table nécessite de la récréer (voir par exemple le code SQL ci-après).

BEGIN TRANSACTION;
CREATE TEMPORARY TABLE t1_backup(a,b);
INSERT INTO t1_backup SELECT a,b FROM t1;
DROP TABLE t1;
CREATE TABLE t1(a,b);
INSERT INTO t1 SELECT a,b FROM t1_backup;
DROP TABLE t1_backup;
COMMIT;

Signalons enfin l’existence de l’exécutable SQLite3.exe qui permet l’interaction avec la db en ligne de commande.

Ci-dessous une copie écran du plugin Mozilla

Nous avons utilisé SQLite dans le cadre d’un système stand-alone de monitoring de sites web et d’exploitation des logs associés, développé avec le langage de scripting AutoIT (voir un autre quick review),  pour le stockage moyen terme et pour bénéficier des possibilités de filtrage et de tri inhérents à une base de données. Egalement pour pouvoir profiter de certaines fonctions SQL au sein de nos développements.

Nous avons donc pu amplement vérifier la compacité, la fiabilité, la performance et la simplicité de gestion de SQLite, dans ses deux versions 32 et 64 bits. Nos développements sont restés limités à la plate-forme Windows.

Nos tests très approfondis ont démontré la facilité de prise en mains de SQLite, son orientation zero administration, sa fiabilité et sa performance.

La version originale de l’outil existe depuis 2001. Sa déjà longue histoire et un usage répandu (mais le plus souvent discret) lui confère des gages de pérennité.

Conclusion :
SQlite est un choix judicieux comme alternative ou en complément d’un système de gestion de fichiers, par exemple pour gérer les paramètres d’une application, voire pour mettre en place un système de cache en local.
Sa réputation n’est plus à faire comme solution de choix pour les mobile devices et les systèmes embarqués.
Couplée au plugin Mozilla SQLite Manager ou à SQLite Expert Personal, elle permet de disposer d’une alternative complète et gratuite aux RDBMS client-serveur dans les cas de figure où ceux-ci ne s’imposent pas. A retenir pour les systèmes stand-alone et/ou mettant l’accent sur de faibles coûts de support.

Autre cas d’application : mettre rapidement en place des bases de données  de test dans l’environnement de développement, en éliminant les temps d’attente relatifs aux équipes admin dbs (ou plus selon l’organisation).

SQLite est une solution entièrement gratuite.