Reconnaissons-le sans honte, lire un pavé de 780 pages n’est pas facile et surtout consommateur de temps. A part les ceintures noires du TOGAF, le business analyst moyen ne lira peut-être jamais plus de choses sur TOGAF que les 3 lignes de présentation. Ceci est évidemment également valable pour le consultant moyen dont l’entreprise n’acceptera aucune formation avant qu’une demande client pressante ne soit présente (et signée) sur le bureau du directeur. Heureusement est arrivé ce petit document pour vous mettre le pied à l’étrier !

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).

Popularity: 15% [?]

J’ai découvert il y a quelques mois le PeaF qui signifie Pragmatic Enterprise Architecture Framework. (Enterprise Architecture = Urbanisation du SI)

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 !

Popularity: 12% [?]

Le défaut de l’ingénieur et en particulier du développeur est plus répandu qu’on le souhaiterait. Mais en fait, lorsque je dis LE défaut, il conviendrait de dire LES défauts.

Parmi les écueils les plus courants, on trouve le fait de vouloir réaliser une fonction pour le défi technologique qu’elle représente et non pas pour répondre au besoin ou encore le fait de penser à son CV avant de répondre à la problématique.

Tout ceci est classique. Si vous êtes architecte logiciel, vous le savez déjà et si vous êtes chef d’équipe ou client vous le savez encore mieux

Je suis tombé sur un livre qui recense tous ces défauts. Plus qu’une collection, c’est un inventaire que je trouve exhaustif (pensez bien qu’il y a tout de même 97 défauts!) qui permettra de mieux comprendre les architectes logiciels.

Le livre est disponible sur Amazon mais il est possible de consulter gratuitement le Wiki sur lequel se trouvent une partie du contenu dont voici un extrait :

We often design over-engineered applications as a result of blindly pleasing customers to the greatest extent. We are so distracted by the details of the solutions that we offer, that we sometimes fail to see that we end up solving the wrong problems in the first place.

So here is a little suggestion: don’t just translate customer requirements into code, but strive to be a wise interpreter. In other words: design for needs, not wants.

You should challenge requirement definitions as, almost invariably, customers poorly define and understand their own actual needs.

All too often, they say they want a longer antenna when, in fact, they need a better reception. You should ask simple questions such as « why do you want this feature? » and « what is its benefit? » and you should keep inquiring until you obtain an adequate answer.

Once you have identified the underlying needs, you have the opportunity to look for alternative solutions. Don’t stop at the first good idea and don’t blindly trust your first instincts. As the French philosopher Alain (Émile Chartier) once said: « Nothing is more dangerous than an idea when it’s the only one you have. » Deliberately ask questions such as « this is a way of doing what? » and « how else can this be achieved? »

Incidentally, this is your best chance to reduce complexity in your applications: right at the source, where it matters most. Simple and elegant solutions are often incredibly hard to find and may not be there at all. But do not to give up too quickly, as you may miss tremendous opportunities.

by Claudio Perrone

Vous trouverez aussi des citations de nombreux professionnels :

• Don’t Put Your Resume Ahead of the Requirements (Nitin Borwankar)
• Chances Are, Your Biggest Problem Isn’t Technical (Mark Ramm)
• Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
• Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
• For the End User, the Interface Is the System (Vinayak Hegde)
• It’s Never Too Early to Think About Performance (Rebecca Parsons)

Si vous connaissez un architecte logiciel ou un développeur ce livre doit être en bonne place dans votre prochaine commande !

Si je parle de ceci sur un blog à priori dédié à la modélisation des processus métier et à l’urbanisation du SI, c’est que je pense que les business analyst et les urbanistes du SI ont de nombreux défauts en commun avec les développeurs… et je sais de quoi je parle !

Pour le commander :

Popularity: 5% [?]

Voici un document présentant le framework Togaf qui est assez bien rédigé. Il présente notamment les nouveautés de la version 9, plus facile à prendre en main.

togaf_9_intergration_consortium_february_2009

Popularity: 28% [?]

Dans les projets de modélisation de processus ou d’urbanisation du système d’information, l’une des questions qui sera inévitablement abordées est celle des objets métiers.

De notion informatique…

Le terme d’objet métier est connoté « informatique » puisqu’on le retrouve dans plusieurs langages de développement dont notamment Java.

L’objet métier est très proche de ce qu’est une classe java (en théorie). Il s’agit simplement de regrouper des idées similaires et de définir ce qui se trouve à l’intérieur.

Typiquement, l’objet client contient tous les éléments qui permettent de décrire un client : nom, prénom, date de naissance…

L’objet métier est un concept et il est toujours un peu difficile à définir précisément (à l’agacement de certains clients!).

Cependant ce n’est pas non plus n’importe quoi ; il s’agit de suive une logique identique pour l’ensemble du découpage sans quoi la modélisation n’aura plus de sens.

…à concept métier

L’objet métier désigne un concept ayant une réalité pour le métier de l’entreprise. Pour les connaisseurs, cela est très similaire des entités de Merise mais avec une souplesse plus importante puisque leur finalité directe n’est pas d’être transformé en tables de base de données.

Un élément clé de tout référentiel métier

L’objet métier est la notion pivot par excellence entre les processus métier et le système d’information. Certain voit le processus métier comme une machine à état venant changer l’état de quelques objets métiers et le système d’information comme un ensemble de fonctions manipulant des objets métiers.

Ainsi, le processus de traitement d’une commande client viendra lire l’objet métier Client et Facture pour mettre à jour l’objet métier Commande à la fin du traitement et le système d’information associé viendra lui offrir toutes les fonctions nécessaires.

L’objet métier comme pivot est une vision pratique pour créer un modèle pertinent.

Une méthode simple

Pour modéliser des objets métiers il « suffit » de discuter avec les personnes du métier.

Selon les projets et les organisations cela peut faire intervenir tout un ensemble d’acteurs différents : de MOE à MOA en passant par les urbanistes. Cela va dépendre du projet mais les qualités requises sont :

- comprendre le métier

- savoir faire abstraction des choses

- compétences de modélisation

Il s’agit de confier cette tâche à une personne étant à mi-chemin entre la tribu des « informaticiens » et celle des « gens du métier » : un interprète qui fera en sorte que ces 2 mondes se comprennent.

Le début de tout projet ?

Selon la méthode de modélisation, les objets métiers vont apparaitre à plus ou moins long terme.

Dans les projets plutôt orienté urbanisation, ils auront tendance à apparaitre plus tôt alors que dans les projets processus, ils ne sont parfois même pas abordés.

Par exemple la méthode Praxeme met plutôt en avant l’approche « objet métier d’abord ».

Personnellement, c’est une approche que j’aime bien car elle clarifie le périmètre. A partir d’une carte d’objet métier de haut niveau, on pourra en déduire des processus mais aussi les principaux systèmes d’information de l’entreprise (un SI pour la relation client, un pour la gestion des commandes….)

Les cartes d’objet métier m’ont souvent aidé à discuter avec les personnes du métier des cas d’utilisation. Il est très facile de montrer un modèle et de poser une question sur la relation entre 2 objets : possible ou non, dans quelles conditions…

Merci à Pascal pour la suggestion du sujet !

Popularity: 100% [?]

Lorsqu’il s’agit de modéliser des processus, la plupart des clients vont chercher un outil avec cette question en tête : « quel est le meilleur outil pour faire ce que je dois faire ? ».

Cette question dérive bien souvent vers : « quel est le meilleur outil ? » qui veut bien entendu dire « quel est le plus cher ? ».

Outil ?

Cette tendance très humaine ne doit jamais faire oublier que modéliser n’est pas une question d’outil. Autant la question était primordiale il y a 3 ou 5 ans lorsque le marché était « sous-outillé » et qu’une décision sur ce point pouvait conditionner le succès ou non d’un projet mais désormais de nombreux outils sont très qualifiés.

J’ai pu tester et travailler avec de nombreux outils BPM ou outils de modélisation de processus métier.

Ce que je sais, c’est que les différences sont minimes entre les plus gros outils à tel point que les critéres d’évalutions doivent être très affinés.

L’outil n’est donc plus déterminant (sauf projet technologique particulier, une minorité). Ce constat est aussi valable pour la modélisation de systèmes d’information et l’urbanisation du SI.

L’outil sera quand même la garantie de la pérennité d’un référentiel d’entreprise. On ne compte plus les projets de modélisation basés sur Excel qui n’ont presque jamais servi…

Un outil est donc nécessaire mais pas déterminant.

Conceptualisation

L’une des qualités importantes que doit posséder un modélisateur, c’est donc de conceptualiser. C’est à dire, intégrer de nombreuses informations et arriver à organiser, reconnaître des patterns , et prioriser des idées.

Cette capacité, directement liée à l’hémisphère droit du cerveau, n’est pas à mon sens quelque chose qui se travaille. C’est quelque chose que l’on possède ou non.

C’est ce qui va faire la différence entre quelqu’un qui nécessite 20 minutes d’exposés et de prise de notes et quelqu’un qui reconnait les éléments clés et leurs relations en 5 minutes.

Bien sûr, je caricature un peu la chose, mais vous voyez ce que je veux dire.

Méthodologie

Un modélisateur doit être méthodique. La méthode définie les choses autorisées et interdites dans une modélisation. Elle définie ce que pourront faire les modélisateurs. Son objectif est de garantir une homogénéité dans les modèles et d’assurer un niveau de qualité minimum (en terme de détails de description).

C’est un point bien souvent négligé.

Le modélisateur doit :

- savoir suivre une méthode qu’il n’a pas créé,

- savoir mettre au point une méthode,

- trouver les points faibles et faire évoluer une méthode existante,

- savoir expliquer le point précédent à un client !

Restitution

Si conceptualiser est la première étape, restituer est l’étape finale. Restituer de manière cohérente avec ce qu’il a précédemment fait est une qualité qui ne se trouve pas chez tout le monde.

C’est là où la méthode intervient.

Malgré la méthode, il arrive très souvent qu’une marge de manoeuvre existe. Si le modélisateur est bon, cette marge sera utilisée pour faire du modèle quelque chose de mieux que prévu, sinon ce sera un résultat décevant.

C’est aussi simple que ça. Vous constaterez tout de suite si un modèle « parle » ou s’il nécessite 5 minutes d’explication. Vous verrez la différence entre un modèle « auto-descriptif » et un modèle qui nécessite la présence de son réalisateur pour être compris…

Conclusion

Voici donc un petit aperçu rapide des qualités « techniques » d’un bon modélisateur de processus d’entreprise ou de systèmes d’information. Au-delà de ça, il ne faut pas oublier qu’un modèlisateur sera amené à discuter et échanger avec de nombreuses personnes et que ses qualités humaines sont très importantes.

Il me semble que les modélisateurs sont plutôt des gens qui fonctionne de manière visuelle. Ils privilégient ce canal au lieu du son qui naturellement est moins utile dans ce type de travaux.

Popularity: 3% [?]