Nous avons vu dans un précédent billet que le rôle de l’architecture pouvait être remis en perspective à travers la poursuite de trois objectifs : Etre Connecté aux objectifs métier de l’entreprise ; Assurer la Cohésion des solutions ; Accueillir favorablement le Changement. Voici un nouveau principe à appliquer afin d’atteindre ces objectifs. Ce principe a été introduit par James O. Coplien et s’intitule « Tous sur le pont dès le début ».
L’essence de ce principe est que l’ensemble des parties prenantes d’un projet doit être impliqué dès le démarrage de ce dernier.
Lire la suite de cet article »
Nous avons vu dans un précédent billet que le rôle de l’architecture pouvait être remis en perspective au travers de la poursuite de trois objectifs : Etre Connecté aux objectifs métier de l’entreprise ; Assurer la Cohésion des solutions ; Accueillir favorablement le Changement. Voici un nouveau principe à appliquer afin d’atteindre ces objectifs. Il constitue un aspect primordial de la fonction d’architecture et s’intitule « Penser grand, agir petit ».
Lire la suite de cet article »
Nous avons vu dans un précédent billet que le rôle de l’architecture pouvait être remis en perspective au travers de la poursuite de trois objectifs : Etre Connecté aux objectifs métier de l’entreprise ; Assurer la Cohésion des solutions ; Accueillir favorablement le Changement. Voici un deuxième principe à appliquer afin d’atteindre ces objectifs. Alors que le premier, « Etre toujours impliqué », concernait l’architecte et son rôle, celui-ci à trait aux livrables d’architecture. Il s’intitule « Voyager léger ».
L’expression « Voyager léger » doit ici être prise au pied de la lettre. La question qui se pose est : Que doit avoir sur lui un architecte lorsqu’il fait le tour des parties prenantes d’un projet pour échanger avec chacune d’entre elles ? De quel support a-t-il besoin pour expliquer les besoins métier à l’équipe de réalisation, pour transmettre la vision du produit au métier, pour impliquer les opérations suffisamment tôt, etc. ?
Comme nous l’avons déjà vu, les dossiers d’architecture à rallonge sont un mal courant dans nos Direction Informatique. C’est le piège du « Big Design Up Front » (BDUF) ou du « Big Modeling Up Front » (BMUF). Les dossiers d’architecture épais comme des bottins ne sont d’aucune utilité parce qu’au final, quels que soient les efforts déployés pour les produire et quelle que soit la pertinence de leur contenu, ils ne sont pas lus. De tels documents ne sont pas lisibles facilement et demandent trop d’efforts et de temps pour appréhender et comprendre leur contenu. Résultat, tout le monde s’en détourne et toute la valeur qu’ils contiennent est perdue.
Lire la suite de cet article »
Nous avons vu dans un précédent billet que le rôle de l’architecture pouvait être remis en perspective au travers de la poursuite de trois objectifs : Etre Connecté aux objectifs métier de l’entreprise ; Assurer la Cohésion des solutions ; Accueillir favorablement le Changement. Voici un premier principe à appliquer afin d’atteindre ces objectifs. Il concerne l’architecte et son rôle et s’intitule « Etre toujours impliqué ».
Le rôle d’un architecte ne se limite pas à un projet ou à une phase d’un projet. Pour être efficace, un architecte doit avoir des perspectives bien plus larges. Un architecte Lean communique en permanence avec toutes les parties prenantes de la DSI (du métier aux opérations). Il joue un rôle actif dans la réalisation des projets. Il s’assure que les leçons apprises sur les projets passés ou en cours sont sues et qu’elles sont appliquées dans tous les projets qui le nécessitent.
Lire la suite de cet article »
Le rôle de l’architecture et la place des architectes au sein d’une organisation font souvent débat et sont souvent mal compris. Cette incompréhension est principalement due au fait que la contribution de l’architecture à la réalisation des objectifs métier de l’entreprise n’est pas (ou peu) visible.
Le rôle de l’architecture peut être remis en perspective si on le considère au travers du prisme de trois objectifs clés (les 3 C de l’architecture) :
- Etre Connecté aux objectifs métier de l’entreprise.
- Assurer la Cohésion des solutions.
- Accueillir favorablement le Changement.
Utiliser ces objectifs comme principes fondamentaux d’une « architecture lean » met l’emphase sur ce qui doit être fait sans perdre de vue le pourquoi. Cela permet ainsi de mieux positionner l’architecture au sein d’une organisation.
Lire la suite de cet article »
Le modèle de maturité de Richardson (Richardson Maturity Model) est un modèle qui décompose l’approche REST en trois étapes qui introduisent progressivement les principaux éléments de REST (Ressources ; Verbes et Codes retours HTTP ; Contrôles hypermédia) pour passer d’un modèle RPC sur HTTP à un modèle RESTFul.
Ce modèle a été développé par Léonard Richardson. Léonard Richardson est, entre autres, co-auteur du livre « Restful Web Service » publié chez O’Reilly.
Martin Fowler a récemment publié un papier à propos du Modèle de Maturité de Richardson intitulé « Richardson Maturity Model: steps toward the glory of REST ». Dans ce papier, Martin Fowler déroule et commente le Richardson Maturity Model au travers d’un cas d’utilisation simple (réserver un rendez-vous chez le médecin).
Ce billet présente le Richardson Maturity Model en s’appuyant en grande partie sur le papier de Martin Fowler. Au programme :
Lire la suite de cet article »
Dans une architecture orientée service, le référentiel ou catalogue de services appartient à une famille de composants destinés à ce que l’on appelle généralement la gouvernance. La gouvernance est une notion évanescente, dont la définition fait l’objet d’âpres débats, mais qui, quelle que soit celle que l’on retient, renvoie au besoin de se doter d’outils et de procédures susceptibles d’assurer le contrôle de la complexité de l’architecture et d’en mesurer la consistance.
Le référentiel de service est un incontournable pour maîtriser les services.
Lire la suite de cet article »
Comme son nom le suggère, l’élément clé de SOA (Service Oriented Architecture) est le Service. Il est pourtant difficile de faire le consensus autour de la notion de service et il est souvent difficile de répondre à cette simple question « Qu’est-ce qu’un service ? ». Ce sujet débouche invariablement sur, au choix : Un blanc ; Une réponse alambiquée et incertaine ; Une discussion enflammée (ou un débat stérile).
On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.
Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :
- Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
- Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
- Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
- Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
- Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
- Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
- Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
- Composabilité : Un service doit être conçu de façon à participer à des compositions de services.
Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.
Dans ce billet, nous nous attarderons sur la notion de composabilité.
Lire la suite de cet article »
Comme son nom le suggère, l’élément clé de SOA (Service Oriented Architecture) est le Service. Il est pourtant difficile de faire le consensus autour de la notion de service et il est souvent difficile de répondre à cette simple question « Qu’est-ce qu’un service ? ». Ce sujet débouche invariablement sur, au choix : Un blanc ; Une réponse alambiquée et incertaine ; Une discussion enflammée (ou un débat stérile).
On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.
Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :
- Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
- Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
- Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
- Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
- Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
- Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
- Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
- Composabilité : Un service doit être conçu de façon à participer à des compositions de services.
Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.
Dans ce billet, nous nous attarderons sur la notion de « découvrabilité« .
Lire la suite de cet article »
Comme son nom le suggère, l’élément clé de SOA (Service Oriented Architecture) est le Service. Il est pourtant difficile de faire le consensus autour de la notion de service et il est souvent difficile de répondre à cette simple question « Qu’est-ce qu’un service ? ». Ce sujet débouche invariablement sur, au choix : Un blanc ; Une réponse alambiquée et incertaine ; Une discussion enflammée (ou un débat stérile).
On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.
Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :
- Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
- Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
- Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
- Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
- Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
- Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
- Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
- Composabilité : Un service doit être conçu de façon à participer à des compositions de services.
Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.
Dans ce billet, nous nous attarderons sur la notion de « statelessness« .
Lire la suite de cet article »
Complet
Twitter
