On me demande régulièrement des outils de ce type et la plupart des éditeurs ont une offre limitée dans le temps ce qui ne correspond pas aux besoins des utilisateurs qui cherchent des outils gratuits. Il ne s’agit pas d’évaluer mais bien d’utiliser sans limite de temps. Ici, ne se trouve que des outils dont l’utilisation n’est pas bornée dans le temps. Je n’ai pas eu l’occasion de tester chaque outil de manière précise mais je sais que les outils open source demandent plus de compétences techniques pour être mis en oeuvre. Aris express et Bizagi sont très simples à utiliser et à installer.

La plupart de ces outils sont en anglais malheureusement. Bizagi possède une interface en Français.

• Aris Express
• Bonita (open source)
• BizAgi Process Modeler
• Questetra BPM Suite
• Tibco Business Studio
• Open ModelSphere
• Process Maker (open source)
  

C’est une question qui est souvent posée par mes clients. Cela commence souvent ainsi : « J’ai choisi la suite … et j’ai commencé à modéliser mais au bout d’un mois tous mes modèles sont enchevêtres et je ne m’y retrouve plus, l’outil n’est pas censé apporter la méthode ? ».

Pour bien répondre à la question (de manière plus complète que ce qui peut-être fait au téléphone) voici le fond du problème.

Il nous faut tout d’abord commencer par le commencement : qu’est-ce qu’un outil de modélisation ?

Un outil de modélisation de processus est un logiciel qui permet de représenter et d’organiser les processus métier d’une entreprise. Il comporte une partie graphique pour représenter le diagramme et une partie textuelle pour décrire le graphique et les données associées. Un outil digne de ce nom est épaulé par une base de donnée relationnelle qui assure, entre autre, que chaque élément dans l’ensemble du référentiel soit unique (non, Visio n’est pas une suite de modélisation). L’objectif est d’assurer qu’une tâche générale soit décrite d’une seule manière et qu’elle soit réutilisée à de multiples endroits afin de faciliter les mises à jour : il suffira de modifier une occurrence de l’objet pour que toutes les autres soit mises à jour. D’autres bénéfices sont retirés d’une base de données relationnelle.

L’outil possède généralement de nombreuses fonctionnalités qui vont du « designer » qui sert à modéliser au « générateur d’état » qui sert à restituer le processus pour qu’il soit communiqué (PDF, Doc, HTML…).

Ce qui se cache derrière l’outil de modélisation est bien plus complet qu’une simple base de donnée relationnelle. L’outil contient toujours un ensemble d’objets prédéfinis pour décrire les processus ou le système d’information : un objet représente une tâche, un autre une zone du SI et ainsi de suite. Chaque objet est configuré selon 2 angles : les relations qu’il peut avoir avec les autres objets et ses attributs.

Par exemple, un objet tâche pourra avoir une relation avec un évènement mais non avec un objet tâche et il contiendra au minimum une description et un type précisant si c’est une tâche manuelle ou automatique.

Toute cette configuration est contenu dans le méta-modèle. Il va contenir l’ensemble des objets, leur représentation graphique, leurs liens possibles, leurs attributs ainsi que d’autres éléments conditionnant le fonctionnement de l’outil de modélisation.

Ceci étant dit, l’outil de modélisation contient donc des choix de méthode. Un outil permettra de relier une tâche à une autre alors qu’un second outil ne l’autorisera pas. Selon l’éditeur et le méta-modèle différents choix méthodologiques seront fait. En dépit de ces choix, il reste souvent beaucoup d’autres décisions que l’outil ne contient pas car il est livré indépendamment du contexte du projet du client.

Cela va plus loin que ça. Même avec un méta-modèle parfaitement personnalisé pour un client, l’outil ne dira toujours pas comment doivent être modèlisés les processus. Certains outils sont plus contraignants que d’autres sur le sujet et la finesse des contrôles peut être important mais dans l’ensemble, l’outil n’est pas la méthode.

Imaginez que vous achetez un logiciel pour faire de la musique. Vous pouvez cherchez si le LA doit être à 440 Hz ou pas et si vous souhaitez positionner une note de guitare acoustique ou de piano mais cela ne fait toujours pas de vous un musicien ou un compositeur. L’illusion est facile sur ce sujet et l’on peut rapidement être amené à croire que l’on va s’en sortir tout seul avec un outil et en lisant l’aide fournie (souvent la documentation du méta-modèle n’est pas fournie).

Une partie de la méthode est donc nécessairement comprise dans le méta-modèle de l’outil. Selon sa flexibilité, c’est soit on adapte le méta-modèle au besoin du client, soit… le client s’adapte au méta-modèle de l’outil (cela arrive plus souvent qu’on le souhaiterais!). Mais en dépit de l’aide apportée par le méta-modèle, il n’est reste pas moins que de nombreux éléments contextuels ne sont pas compris ici : manière de nommer les modèles et les objets, la manière d’organiser les modèles (hiérarchique ou non), la manière de décrire les objets…

Pire, l’outil ne sait pas si votre modèle est conforme à d’autres choix méthodologiques comme le nombre maximum d’objets par modèle, le nombre de niveaux ou de couches ou d’autres choix non présent dans l’outil.

Les outils évoluent naturellement vers l’intégration de plus en plus complète de la méthode de modélisation mais prenez garde car le diable se niche dans les détails !

La récupération d’un projet ayant été démarré sans méthode précise est toujours une tâche haletante car on ne souhaite pas perdre le travail fourni par les équipes ni vraiment faire passer le message comme quoi la méthode n’est pas viable tout en devant respecter une certaine rapidité d’exécution. Mieux vaut éviter d’en arriver là.

L’urbanisation, par le niveau de compréhension qui en ressort, est une formidable source d’information permettant de prendre des décisions éclairées et de voir le véritable lien entre le métier de l’entreprise et son système d’information.

La direction de l’entreprise s’en trouve simplifiée et les décisions métiers et IT gagnent en synergie.

La complexité des systèmes d’information est à un niveau jamais atteint, cela rend plus simple la prise de décision.

Cependant dans les projets, sur le terrain et loin des conférences et autres symposiums, les résultats obtenus sont souvent décevants.

Je vais m’attacher au lien entre le projet d’urbanisation et le projet IT de refonte ou de développement dans le système d’information de l’entreprise.

Les difficultés rencontrées :

Tout d’abord chaque projet IT doit affronter les chefs de silo (CDS). Les chefs de silo interviennent pour garantir que leur secteur (ou leur territoire) ne sera pas réduit par le projet. Que l’organisation soit notablement sous forme de silo ou non ne change pas grand chose car dans le fond, les chefs de silo trouvent toujours un moyen de recréer une organisation par silo.

Il faudra donc composer avec eux et surtout arriver à faire collaborer ces chefs entre eux. C’est d’ailleurs en bonne partie pour cela que la recommandation dans tout projet d’urbanisation est que le haut management soit acteur : pour « forcer » les chefs de silo à travailler entre eux.

Ensuite, le projet devra affronter la résistance de nombreux intervenants dont la liste n’est pas très réjouissante.

Le projet d’urbanisation peinera à atteindre des résultats satisfaisants à cause des entraves précédemment listées : les intervenants terrain ne croient pas au projet et n’en attendent rien. La conséquence logique est que l’investissement consenti pour le projet ne donnera pas de bons résultats.

Inévitablement, le projet IT qui en découle sera comme la majorité des projets IT non encadrés : il comportera trop de fonctionnalités qui ne seront basées sur aucun besoin métier et coûtera donc trop cher.

Bien sûr, le projet sera trop gros avec un planning intenable. Cerise sur le gâteau, les indicateurs permettant de mesurer la qualité du projet et sa contribution aux résultats de l’entreprise ne seront pas définis et donc non mesurés ce qui poussera l’équipe projet à livrer à tout prix sans s’attacher aux détails de la livraison (le lien vers la nouvelle application dans l’intranet suffi pour apporter satisfaction non ?).

Comment faire ?

Si l’urbanisation n’est pas la méthode miracle pour faire des projets IT une absolue réussite, sa rigueur permettra surtout de s’attacher aux résultats qu’attends l’entreprise : un changement positif qui apporte une amélioration métier.

La réalité des projets d’urbanisation n’est en fait pas très différente de celle des projets IT. Si le projet d’urbanisation doit apporter un éclairage pratique et fixer les limites des projets IT, il souffre des mêmes contraintes pour une seule raison : il évolue dans le même milieu.

Le milieu est grandement influencé par la manière dont les équipes collaborent et je pense que le type de collaboration entre projets et urbanistes est déterminant.

Il existe différentes manières d’intégrer l’urbanisation aux projets IT.

Les urbanistes sont souvent une entité isolée qui intervient sur les projets à la demande. La plupart du temps ils sont dans leur tour d’ivoire bureau et travaillent en parallèle des projets IT en essayant de produire le plus gros modèle du monde. Selon le niveau d’autorité qui leur ai accordé, ils peuvent opposer un véto au projet si jamais celui-ci ne respectait pas les pré-requis nécessaires pour garder un SI urbanisé.

On les trouve parfois dans l’équipe des business analyst qui décrit les processus métier à mettre en place. Ils bénéficient d’une place de choix puisqu’ils peuvent faire remonter les parties du SI susceptibles de couvrir les besoins métiers étudiés et ainsi concrétiser un mot sacré la réutilisation. Souvent, il s’agit d’une personne détachée de l’équipe d’urbanistes.

Parfois, ils ne sont pas tout à fait identifié et leur intervention sur les projets est mal vue. Ils restent en marge et se contentent de documenter ce qui se passe et d’emettre des « notes de recommandation »…

Je suis intimement convaincu que la position de l’urbaniste doit être dans les projets. C’est là où l’urbaniste prend sa casquette d’archiecte applicatif (si ce rôle n’existe pas) pour aider les projets à s’intégrer au SI. C’est là où le travail de cartographie apporte de la valeur et délivre son potentiel. Il n’en reste pas moins que la nature des projets IT est très diverse et cela rend toujours un peu difficile de coller à une organisation type. Cependant, posez-vous la question : est-ce que mes urbanistes contribuent aux projets IT ? Est-ce que le référentiel des applications (CMDB ou pas) est mis à contribution ? Est-ce que tous les outils à notre disposition sont utilisés pour encadrer le projet ?

Dans mes recherches sur le net, j’ai trouvé un document qui résume l’esprit du framework TOGAF 9.

Ecrit par Wolfgang W. Keller, ce résumé est un excellent moyen de :

• savoir plus en détail de quoi TOGAF parle
• pouvoir le positionner par rapport aux autres framework
• pouvoir décider de l’utiliser ou non

De plus, le document contient une dizaine de pages de définitions sur l’enterprise architecture et le rôle de l’architecte dans l’entreprise.

• Comment décrire la stratégie en termes SI ?
• Comment gérer le portefeuille d’applications ?
• Comment utiliser TOGAF pour mettre au point son approche urbanisée ?
• Quel lien existe-t-il entre TOAGF et la gouvernance du SI ?

Sans plus attendre, voici le lien pour télécharger ce document PDF en anglais (j’ai du insister pour arriver à télécharger le document).

Voici également un autre lien si jamais le premier ne fonctionne pas (faire bouton droit – Enregistrer la cible su lien).

C’est une initiative intéressante de Kevin Lee Smith, un « professionnel de la profession » avec 28 années d’expériences dans le domaine. Après avoir élaboré ce framework pendant des années, il a décidé de le publier en Novembre 2008.

Ce framework se veut résolument pragmatique (approche que l’on retrouve d’ailleurs dans l’approche Praxeme) et sans artifices.

PeaF vient se rajouter à la longue liste des frameworks déjà existants :

• TOGAF,
• Zachnman,
• TEAF
• E2AF,
• MoDAF / DoDAF
• IAF.

S’il y a un document à consulter pour avoir un aperçu de cette méthode, c’est celui-ci et aussi celui-ci.

Vous verrez que l’auteur a pris le soin de modéliser sa propre méthode, ce qui pour un architecte est la moindre des choses

Je souscris à l’approche générale et qu’une méthode comme celle-ci gagne à être diffusée, c’est pourquoi j’ai une licence qui m’a été délivré.

Les domaines

Model : l’ensemble des modèles, du méta-modèle et des outils qui constituent le cœur d’une démarche d’urbanisation du SI.

Governance : processus et principes qui permettent de garantir la qualité des travaux d’urbanisation (notamment le respect de la convention de modélisation qui est si difficile et la gestion du cycle de vie).

Foundation : la vision, l’analyse des risques et le niveau de maturité de l’organisation.

Management : définition d’indicateurs pour mesurer l’état et la contribution de l’urbanisation à l’entreprise et processus de planification des évolutions et des tâches d’urbanisation.

Communication : processus d’évangélisation autour de l’urbanisation et du framework. La communication est souvent le point noir des projets d’urbanisation ou de modélisation de processus métier.

Si une entreprise entame une démarche, ces documents sont une véritable mine d’or à condition d’en comprendre la finalité.

Ce qui est intéressant, ce que PeaF se défini également par rapport aux autres framework. Ainsi, il se veut plus concret que Zachmann qui est plutôt un méta-modèle et plus compréhensible que TOGAF dont la courbe d’apprentissage est énorme (700 pages).

Guide pour analyser un outil de modélisation qui contient une liste des caractéristiques à regarder ainsi qu’un classement de la plupart des éditeurs de solutions BPA/BPM.

Une initiative à suivre !