Archive

Author Archive

Voulez-vous accroître les compétences de votre organisation sur l’Architecture d’Entreprise ?

October 6th, 2010 No comments

La plupart des DSI, comme les managers en général, tiennent comme fondamental d’avoir accru les compétences de leur organisation. Ils ont davantage de chances d’atteindre, voire de dépasser, leurs objectifs et sont plus forts pour résister aux périodes difficiles. De plus, les collaborateurs qui ont progressé, font preuve d’une plus grande loyauté à leur égard et à celui de l’entreprise. Ces managers voient leur taux d’attrition baisser.

Pourtant,  l’architecture et l’architecture d’entreprise pourraient vous surprendre. Bien que vous ayez formé tous vos architectes, vous ne parvenez pas à accélérer le rythme des changements de l’architecture de votre système d’information. Cela parce que les architectes ne réalisent qu’une partie de l’architecture, les choix de conception et les décisions sont faits par les chefs de projet. Certaines entreprises ont même inventé le nom “Les chefs de projet technique” afin de promouvoir leurs architectes à la position de manager. Cela signifie que si vous avez investi pour le déploiement d’un framework comme TOGAF parmi vos architectes, vous pouvez sans doute, manquez votre retour sur investissement.

Read more…

Accéler, Accéler, Accéler encore grâce à l’Architecture d’Entreprise

August 21st, 2010 No comments

Ne voulons-nous tous pas mettre en œuvre des réponses simples et rapides à nos questions stratégiques ? Pas seulement à cause de la contrainte de délai de commercialisation des produits, mais aussi, parce que cela accroît la  visibilité sur la valeur que nous apportons à nos entreprises. Nous avons passé beaucoup de temps à lire, à parcourir les tweets, à observer les médias sociaux, à discuter avec les fournisseurs, à assister à des conférences pour trouver les bonnes idées adaptées à notre cas. Lorsque nous en avons identifiée une, nous essayons de la mettre à côté d’une ancienne idée pour voir comment elles s’intègrent, à la manière d’un jeu de lego. Souvent, elle ne convient pas. Alors, nous stockons l’idée pour un usage ultérieur, lorsque nous trouverons une nouvelle qui va permettre de réaliser l’ensemble du montage.

Si elle convient, nous faisons une analyse de rentabilisation et nous nous mettons en quête d’un sponsor pour ce qu’il promet d’être un projet révolutionnaire pour notre entreprise. A partir de maintenant, il ne fait aucun doute que notre expérience est adaptée pour mener le projet à une réalisation réussie, sinon ce serait une autre histoire.

Le stade où un ensemble d’idées constitue une solution d’entreprise innovante, est très difficile à atteindre pour de nombreuses raisons étudiées et connues par les chercheurs en gestion. Selon les promesse du projet, certains utilisateurs peuvent accepter des inconvénients en regards des avantages, ce qui les obligent à changer leur mode de travail.
Read more…

Quelles sont les nouvelles de la ligne de front des exigences ?

July 15th, 2010 2 comments

Lorsque l’IEEE s’est intéressée à l’ingénierie des exigences, elle a publié la définition suivante dans son standard IEEE Std 610.12.-1990: «Une exigence est : (1) Une condition ou une aptitude nécessaire à un utilisateur pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées.(3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).

RUP et les autres approches de développement de logiciels utilisent cette définition.

l’IIBA dans le BABOK 2,0 prend un court-circuit et élargit le périmètre de la définition de l’IEEE grâce au mot partie-prenante : “une exigence est (1) Une condition ou une aptitude nécessaire à une partie prenante pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées. (3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).

(1) concerne les exigences organisationnelles et métier tandis que (2) concerne les exigences de solution.

Pour le BABOK 2.0 (1) est découpé entre exigences d’entreprises classifient les objectifs globaux d’une organisation et les exigences des parties prenantes qui classifient les besoins des intervenants en particulier. (2) concerne les exigences fonctionnelles et non fonctionnelles.

Il est étonnant de voir comment l’IIBA a ignoré les initiatives d’Architecture d’Entreprise qui visent à renouveler la gestion des exigences au sein du cycle de vie de la transformation de l’entreprise.

Malgré tout, les exigences continuent à être collectées au travers des modèles que nous connaissons depuis les temps immémoriaux: IDEF0 , SADT , UML , BPMN , … avec quelques améliorations sur les exigences non fonctionnelles.

Alors qu’il y -t-il à la table de jeu?

Read more…

Les systèmes d’information peuvent-ils vraiments être comparés à une ville ?

En classant ma documentation sur l’urbanisme des systèmes d’information, pourquoi tombé-je sans arrêt sur des articles ou des billets qui expliquent la pertinence de l’analogie entre le modèle urbain et les systèmes d’information ? En voilà quelques exemples : “Urbanisme des villes et urbanisme des systèmes d’information”, “L’apport historique de l’urbanisme des villes pour l’urbanisme des systèmes d’information” de Véronique Levasseur, ou bien l’Article de Wikipédia sur le même sujet.
Read more…

Facteurs clés de succès de la transformation

January 11th, 2010 No comments

La revue de l’AFAI a publié un article sur la gouvernance des SI et l’Architecture d’entreprise co-signé par votre serviteur. Dans sa conclusion, l’article propose les facteurs de succès de la transformation de l’entreprise :

Une cible et une trajectoire partagées en cohérence avec la vision stratégique de l’Entreprise. C’est un objectif habituellement difficile, notamment avec la multiplication des parties-prenantes. L’architecture d’entreprise permet grâce à la gestion des exigences et aux vues d’architecture, d’organiser des cascades depuis le management stratégique jusqu’au management opérationnel, de tenir et créer  la cohérence.


Des business case de projets, réalistes, et soutenus par le management. Les business case de projets ne doivent pas être que financier, mais prendre en compte tous les éléments techniques, organisationnels et stratégiques du projet. L’architecture d’entreprise permet de constituer l’ensemble de ces éléments de manière partagée.


Une processus de prise de décision pour le lancement et le suivi de projets qui mobilise les bonnes personnes au bon moment. L’Architecture d’Entreprise vise à formuler les bonnes questions à la bonne personne au bon moment.

Une implication des responsables fonctionnels et opérationnels tout au long de la vie du projet, et notamment pour la matérialisation de la valeur métier prévue. En considérant dans un même plan, les aspects organisationnels, opérationnels, stratégiques et techniques, l’Architecture d’Entreprise ramène l’intérêt des responsables opérationnels et fonctionnels vers les projets.

Une vision partagée des processus métier permettant la déclinaison des objectifs opérationnels et la mise en cohérence des projets avce ces objectifs opérationnels. En mettant au centre de ses apports les vues d’architecture et le partage, l’Architecture d’Entreprise donne au métier des outils de management opérationnels.

Une gestion de portefeuille de projets adaptées aux enjeux de l’entreprise L’Architecture d’Entreprise appuie la gestion de portefeuilles de projets, notamment en sécurisant les dépendances et les trajectoires.

Un Référentiel d’Architecture d’Entreprise permettant de capitaliser et de partager les pratiques et les services d’entreprise. A condition que le référentiel d‘Architecture soit adapté et déployé en synergie des processus de management existants, dans un esprit lean, c’est à dire juste ce qu’il faut au moment où il faut.

Un leadership permettant de donner un sens à l’ensemble des projets par rapport à des objectifs stratégiques et responsabiliser le management. Dans toute thématique de management, pour réussir,  le leadership est essentiel. L’architecture d’entreprise ne doit pas être un bureau d’étude de plus, mais un levier de leadership.

Voici le lien pour télécharger l’article complet.ArticleGouvSIAE.pdf

Open World Forum Paris le 1-2 octobre

October 8th, 2009 2 comments

J’ai assisté à la matinée du 1er octobre de l’Open World Forum à Paris. Je recherchais au milieu d’un public de convaincus, des clés complémentaires pour comprendre les fondamentaux économiques du logiciel libre. Des conférenciers de renoms pour ouvrir un Forum qui s’annonçait réellement international : Jacques Attali, Andrew Aitken, Matthew Aslett, Michael Tiemann.
Une Table Ronde avec des acteurs locaux : Jean-Pierre Barbéris, Président, Bull France, Michel Cosnard, Président, INRIA, Henri Verdier, Président, Cap Digital, Dominique Vernay, Président, System@TIC.

En 2 mots Matthew Aslett nous dit que la guerre est gagnée, il s’appuie pour cela sur l’article “Unlocking the cloud” du journal The Economist. Le logiciel libre a aujourd’hui sa place, et il sert de base à la construction du Cloud Computing. Néanmoins il reste beaucoup de travail pour franchir l’obstacle du verrouillage des données : il faut que les données puissent être déménagées d’un fournisseur de “cloud services” à l’autre.
Read more…

PARIS 2.0. Une richesse de points de vue

October 1st, 2009 No comments


J’ai assisté à l’événement PARIS 2.0, la matinée du 25 septembre. Les sujets abordés étaient la génération digitale, les marques en réseau, le management 2.0 sous forme de tables rondes où les participants donnaient leur point de vue et leurs retours d’expérience. Ce fut un événement enrichissant notamment grâce à la diversité des points de vue, due à la diversité de secteurs d’activité, mais aussi à la diversité des métiers de chaque intervenant : manager, offreur de service, communicant, technicien,…


Read more…

La fondation Cigref : “Dynamique des usages des Systèmes d’Information”

September 25th, 2009 1 comment

J’ai participé à la matinée du colloque sur la “Dynamique des usages des Systèmes d’Information”. Bravo à Bruno Ménard et à l’équipe du Cigref pour un événement réussi, qui a réuni des intervenants de très grande qualité avec une diversité de points de vue tout à fait intéressante. L’affluence était finalement le meilleur indicateur de réussite.
Concis et Brillant, Gérard Berry met en perspective l’arrivée de l’ordinateur comme une révolution du calcul qui ouvre la voie de la simulation du réel en temps réel. Cela étend nos capacités de prédictions et d’adaptation à condition que l’on change nos schémas mentaux : la tâche la plus ardue.
Read more…

Considérer la promesse du consultant à sa juste valeur

September 17th, 2009 No comments

Vous êtes consultant. Votre objectif est d’amener votre client à mettre en pratique une nouvelle idée qui doit, en partie, changer sa façon de travailler. Plusieurs cas peuvent se présenter : soit cette idée est une promesse réaliste de résoudre un problème ou bien d’améliorer les résultats habituellement atteints, soit elle garde le client d’une situation où l’inertie sera à terme dommageable. En soi, cette position est ambitieuse, car la promesse soit être suffisamment attirante.

Qu’est-ce qui devrait rendre cette promesse attirante ?

D’abord, c’est la relation directe entre la réalisation de la promesse et la réalisation du résultat attendu par le client. Plus le client perçoit cette relation, plus il perçoit la promesse comme une proposition de valeur.
C’est, ensuite, la démonstration de la capacité du conseil à tenir la promesse. Ce sont les références du conseil ou bien de l’entreprise qui, sur la base des savoir-faire déjà mis en œuvre, étayent cette capacité.
C’est enfin l’empathie que le conseil fait surgir et qui complète l’atmosphère de confiance qui s’est installée.
Read more…

Septembre, la période des budgets débute, c’est aussi celle des erreurs

September 7th, 2009 2 comments

Septembre est habituellement la période où débute le processus budgétaire. Le processus, généralement piloté par le contrôle de gestion, commence par le rappel des orientations stratégiques et des éléments de cadrage budgétaire pour leur mise en œuvre. L’exigence de gains par rapport aux lignes de l’année précédente est présente partout, et un contexte de stagnation ou de faible croissance offre moins de marges de manœuvre.

Les managers IT doivent passer en revue le portefeuille de projets pour réestimer les ordres de priorité. Ceci ne peut être fait sans la collaboration des métiers qui en sont les commanditaires. Généralement, on distingue les grands projets à visibilité d’entreprise et les demandes de maintenance évolutive qui concernent chacune un petit groupe d’utilisateurs.

Dans ce dernier cas, il y a deux critères pour cadrer  les demandes : le ROI qui permet d’exprimer les gains de productivité et le caractère obligatoire du point de vue de la conformité. Malgré tout, le nombre de lignes rend parfois fastidieuse la tâche d’estimation ou de réestimation et donc mène à des approximations parfois larges.
Read more…

Switch to our mobile site