mar 21

L’interopérabilité est la motivation première qui vise à améliorer la cohérence des systèmes d’information. La gestion des points de vue fonctionnels ne trouve cependant pas de résolution immédiate et évidente. Au contraire, la mise en œuvre de solutions d’échange de données par entité, risquent souvent d’alourdir les structures d’échange et de finalement introduire plus d’immobilisme que d’agilité dans l’évolution du système.

L’interopérabilité se définit par la facilité avec laquelle les systèmes peuvent échanger. On peut projeter cette propriété sur 3 couches distinctes :

  1. l’interopérabilité technique qui consiste à s’assurer que les encodages des contenus sont exploitables de la part des clients et des fournisseurs de services
  2. l’interopérabilité des protocoles qui permet de garantir l’usage et le fonctionnement cohérent de mécanismes transverses tels que la sécurité ou les transactions
  3. l’interopérabilité fonctionnelle qui s’occupe de l’interprétation cohérente, de l’exhaustivité et de l’utilisabilité de l’information transmise par les services.

Lire la suite »

Mots-clés :
nov 23

Le développement du BPM au sein des entreprises poursuit son cours. S’il a contribué dans la majeure partie des cas à améliorer la connaissance des processus métier par la cartographie, son extension vers l’architecture du SI est de plus en plus envisagée à titre d’alignement formel entre logiciel et métier. Cette évolution est également favorisée par la proposition de passage de BPMN à BPEL, également supportée par les grands éditeurs de suites SOA.

Cela revient cependant à positionner BPMN comme un équivalent graphique de BPEL; bien que cela arrange les éditeurs dans leur discours simplificateur, l’application sur des cas concrets d’entreprise révèle le manque d’exactitude de cette approche.

Lire la suite »

Mots-clés :
juil 06

Le livre de Laurent Morisseau « Kanban pour l’IT » est désormais disponible ici ou .

Couverture du livre "Kanban pour l'IT"

D’une part, les premiers retours de la part des « early readers » sont très flatteurs. (Voir le post de Claudre Aubry  sur son blog).

D’autre part, nous avons la chance de bénéficier du coaching de Laurent depuis peu sur un de nos projets. A ce sujet, l’approche Kanban à ce stade m’a séduit pour deux points primordiaux concernant l’approche Kanban :

  • elle joue son rôle parfaitement pour révéler les obstacles ;
  • sa mise en oeuvre peut être très progressive. C’est un vecteur particulièrement intéressant en terme de conduite du changement. En effet, de mon point de vue, le passage à des méthodes « agiles » ou « lean » nécessite de conduire le changement auprès des équipes, du client… Je pense approfondir d’ailleurs ce point comparativement à d’autres solutions comme Scrum par exemple !

En attendant de pouvoir lire le livre et de partager ma lecture avec vous prochainement… .

PS: Si seulement je pouvais le lire sur la plage que l’on aperçoit sur la couverture du livre … ;-)

A suivre…

Yann BARRAULT

Consultant Architecture & Nouvelles Technologies

Mots-clés :
avr 23

Ce troisième billet sur la modélisation du besoin va s’attacher à préciser les différences existantes entre l’activité d’expression du besoin destinée à la MOA et celle d’analyse du besoin prise en charge par la MOE ; du moins quand celle-ci ne passe pas directement à l’implémentation logicielle.

On l’a vu précédemment, bien souvent, la MOA bâtit une expression du besoin sous la forme d’un cahier des charges et la MOE établit une expression du besoin en utilisant un cadre de pensée plus précis tel que les cas d’utilisation et la modélisation objet. Toutefois, dans les deux cas, on s’intéresse à la description du besoin du système d’un point de vue externe.  Le cahier des charges n’étant pas assez précis, complet et cohérent, il est devenu une habitude que la MOE le complète d’une spécification du besoin plus formelle.

En dehors de l’avantage de permettre à la MOE de prendre connaissance du besoin, les inconvénients de cette approche sont les suivants :

  • On se retrouve avec plusieurs documents d’expression du besoin ! Lequel fait foi et reste à jour ?
  • On effectue parfois deux fois le travail d’expression du besoin ;
  • la MOE s’accapare la maîtrise du besoin qui pourtant devrait rester dans le giron de la MOA ;
  • Plus technique, il n’est pas rare que la spécification vue par la MOE noie le besoin avec des considérations de l’ordre de la solution technique. Lire la suite »
Mots-clés :
mar 05

Le premier billet sur la modélisation a voulu démythifier cette activité mal perçue dans le monde informatique. Ce deuxième billet se focalise sur l’activité essentielle du développement logicielle qu’est l’expression du besoin et met en perspective comment la mauvaise compréhension de l’acte de modélisation lui est fortement préjudiciable.

On sépare communément la maîtrise d’ouvrage (MOA) responsable de l’expression du besoin d’un système et la maîtrise d’œuvre (MOE) responsable de la réalisation de ce système. Bien que les rôles semblent bien définis, il n’en va pas vraiment de même dans la réalité. Un lieu commun est de trouver un cahier des charges produit par la MOA suivi d’une spécification du besoin réalisée par la MOE ; chaque document traitant à sa manière du besoin. Lire la suite »

Mots-clés :
jan 30

Au cours de mes expériences en tant  qu’architecte, qu’AMOA ou au sein de département méthode, j’ai été frappé par la mauvaise perception que l’on a de la notion de modélisation dans les équipes informatiques.

Pour beaucoup la modélisation est une activité à part qui fait peur (on pense que c’est une activité difficile réservée à des experts) et qui apporte un surcroît de travail pour obtenir un hypothétique gain en qualité dans le développement des systèmes informatiques.

Pourtant, modéliser est avant tout un acte intellectuel naturel que nous effectuons quotidiennement et ceci depuis notre plus jeune âge. Notre cerveau est bâti pour produire des modèles mentaux de la réalité que nous percevons.
Lire la suite »

Mots-clés :
jan 02

SOA component UML schema

Cet article expose mes réflexions sur la relation entre les deux concepts logiciels clés qui sont la  SOA et l’orienté objet, et qui concernent à la fois les méthodes et l’architecture des systèmes. Il fait suite à une de ces phrases assassines entendues au cours d’une réunion de travail : « le SOA c’est la mort de l’objet« . Afin de faire la part des choses, il convient de replacer les mots dans leur contexte et de préciser les différents points de vue selon lesquels cette opinion peut être considérée…

Lire la suite »

Mots-clés :
oct 13

Suite à nos premiers articles sur la productivité (les facteurs néfactes à la productivité, l’évolution des outils et des IDE de développement, le concept de « Task Focus Interface »), nous vous proposons de détailler ici l’outil Mylyn, première implémentation du concept de « Task Focus Interface », imaginé et mis en œuvre par Mik Kersten pour répondre à la problématique de focalisation/concentration (en témoigne cet article dans l’actualité).

Comme vous pouvez le constater, Mylyn est un projet qui fait partie aujourd’hui de l’IDE Eclipse.

Mylyn, le premier outil « Task Focus Interface »

Mylyn, le premier outil « Task Focus Interface »

Lire la suite »

Mots-clés :
oct 07

 

Le concept d’urbanisation de SI est très porteur depuis quelques années. Grands groupes comme PME sont concernés pour avoir souvent construit leur SI de manière empirique suivant les aléas de la stratégie d’entreprise (rachat, fusion, repositionnement métier…).

Une étude d’urbanisation vise à identifier des axes d’amélioration du SI pour le réconcilier avec l’activité humaine de l’entreprise, pour qu’il retrouve son rôle de facilitateur du métier, et surtout pour qu’il retrouve sa capacité à évoluer.

L’urbanisation ne se résume pas à un empilement de bonnes idées apportées par un auditeur externe, car il ne faut pas perdre de vue que derrière les aspects techniques, la réussite d’un tel chantier repose avant tout sur la méthode ! Lire la suite »

Mots-clés :
sept 08

La réutilisation est une vieille promesse des architectures logicielles qui a connu une progression lente mais continue… En récapitulant mes expériences en la matière, je constate qu’à chaque nouvelle vague de middleware, de nouvelles tentatives sont menées dans l’optique d’obtenir la réutilisation logicielle.

Lire la suite »

Mots-clés :
preload preload preload