Les cartes de la catégorie "RÈGLES DU JEU"

RÈGLES DU JEU

RÈGLES DU JEU

RÈGLES DU JEU

[ CHOIX TECHNIQUES ]

Les choix techniques sont effectués et assumés par la Feature Team.

RÈGLES DU JEU

[ CHOIX TECHNIQUES ]

La Feature Team doit agir de manière responsable afin d'identifier les choix qui l'impactent exclusivement et les choix qui impactent l'organisation.

Les choix qui dépassent le périmètre de la Feature Team (exemple : licence, langage de programmation peu répandu) doivent être soumis à validation par l'organisation ou par le processus de convergence des pairs.

RÈGLES DU JEU

[ BON USAGE ]

Le bon outil pour le bon usage est une source d'économies.

RÈGLES DU JEU

[ BON USAGE ]

Un mauvais outil imposé à tous est un risque. Le mauvais usage d'un bon outil peut avoir des conséquences très néfastes. Par exemple, les méthodes Agiles mal utilisées sont dangereuses.

Les outils doivent être remis en question.

Excel est souvent un choix rationnel mais ça n'est pas un outil à tout faire (CRM, ERP, Datamart, …)

RÈGLES DU JEU

[ BUILD VS. BUY ]

Privilégiez le Build pour le coeur de métier.

Envisagez le Buy pour le reste, au cas par cas.

RÈGLES DU JEU

[ BUILD VS. BUY ]

Plus un outil porte une fonctionnalité apportant un caractère différenciant pour l'organisation, plus il a vocation à être construit. Le coeur de métier doit permettre la spécificité et s'adapter souvent et rapidement. Certains progiciels sont parfois adaptés à ce besoin.

Pour le reste : SaaS, Open Source, Build ou Propriétaire sont à étudier au cas par cas.

RÈGLES DU JEU

[ OPEN SOURCE ]

Privilégiez l’Open Source.

Les choix alternatifs doivent être étayés.

RÈGLES DU JEU

[ OPEN SOURCE ]

Les solutions propriétaires sont un risque pour l'organisation qui doit être capable de reprendre la maintenance si besoin.

Rares sont les outils propriétaires qui n'ont pas d'alternatives Open Source.

L'organisation bénéficie de la Communauté Open Source et peut lui reverser ses contributions.

RÈGLES DU JEU

[ MICRO-SERVICES ]

Développez des services autonomes et faiblement couplés.

RÈGLES DU JEU

[ MICRO-SERVICES ]

Le couplage faible doit être la norme.

Chaque micro-service dispose d'une interface clairement définie.

Cette interface détermine le couplage entre les micro-services.

Le Domain Driven Design permet, notamment avec les Bounded Contexts, d'anticiper au mieux cette problématique.

RÈGLES DU JEU

[ DONNÉES ]

Chaque service possède son propre système de stockage de données.

RÈGLES DU JEU

[ DONNÉES ]

Un Data Store n'a vocation à être couplé qu'avec un seul micro-service.

L'accès aux données d'un micro-service à un autre est effectué exclusivement via son interface.

Ce design implique la cohérence à terme à l'échelle de la plateforme. Elle doit être appréhendée à tous les niveaux, y compris UX.

RÈGLES DU JEU

[ PÉRIMÈTRE ]

Chaque micro-service doit avoir un périmètre fonctionnel raisonnable, qui "loge dans la tête".

RÈGLES DU JEU

[ PÉRIMÈTRE ]

Un micro-service propose un nombre raisonnable de fonctionnalités.

N'hésitez pas à découper un micro-service lorsque celui-ci commence à grossir.

Un service de taille raisonnable permet d'envisager sereinement la réécriture, si le besoin se présente.

RÈGLES DU JEU

[ RÉACTIF ]

Le Reactive Manifesto ouvre la voie vers la conception d'architectures réactives.

RÈGLES DU JEU

[ RÉACTIF ]

La programmation réactive se concentre sur le flux de données et la propagation du changement. Elle s'appuie sur le pattern "Observer" contrairement à l'approche "Iterator", plus classique.

Le Reactive Manifesto fixe des axes fondamentaux : disponibilité et rapidité, résilience aux pannes, souplesse, élasticité et orientation messages.

RÈGLES DU JEU

[ ASYNC-FIRST ]

Les processus asynchrones favorisent le découplage et la scalabilité au profit des performances.

RÈGLES DU JEU

[ ASYNC-FIRST ]

Les échanges entre applications doivent être en premier lieu asynchrones.

Les échanges asynchrones permettent naturellement le couplage faible, l' isolation et le contrôle des flux (back-pressure).

La communication synchrone ne doit être envisagée que lorsque l'action l'impose.

RÈGLES DU JEU

[ ÉVÉNEMENTS ]

Le système d'informations doit être orienté événements.

RÈGLES DU JEU

[ ÉVÉNEMENTS ]

Les processus fonctionnels orientés "événements" sont naturellement implémentés de manière asynchrone.

L' orientation événements permet de favoriser la mise en place d'approches telles que Command Query Responsibility Segregation (CQRS) et Event Sourcing.

RÈGLES DU JEU

[ MESSAGE BROKER ]

Privilégiez un message-broker simple , robuste et performant à un "tuyau intelligent".

RÈGLES DU JEU

[ MESSAGE BROKER ]

Les ESB ont montré leurs limites : la maintenance évolutive est critique, aussi bien d'un point de vue technique qu'organisationnel.

Les messages brokers comme Kafka offrent une solution simple, durable et résiliente.

Des endpoints intelligents et des tuyaux simples est une architecture qui fonctionne à l'échelle : c'est Internet.

RÈGLES DU JEU

[ SYNCHRONISATION ]

La synchronisation totale du système doit être pensée dès sa conception.

RÈGLES DU JEU

[ SYNCHRONISATION ]

Si la synchronisation entre deux systèmes est assurée par un flux d'événements, la resynchronisation totale de ces systèmes doit être prévue dès la conception.

Un audit automatique de la synchronisation (exemple : par échantillons) permet de mesurer et détecter les éventuelles erreurs de synchronisation.

RÈGLES DU JEU

[ CENTRALISATION ]

La configuration des services est centralisée, leur découverte est assurée par un annuaire.

RÈGLES DU JEU

[ CENTRALISATION ]

La configuration des micro-services est centralisée pour l'ensemble des environnements.

Un annuaire centralisé permet d'assurer la découverte dynamique des micro-services.

La scalabilité globale du SI dépend de cet annuaire.

RÈGLES DU JEU

[ BAC À SABLE ]

Les Feature Teams fournissent un environnement "bac à sable".

RÈGLES DU JEU

[ BAC À SABLE ]

Les Feature Teams maintiennent un environnement "bac à sable" (version actuelle et version à venir) afin de permettre aux autres équipes de développer à l'échelle.

Dans certains cas non nominaux, des features peuvent être désactivées dans l'environnement de développement.

RÈGLES DU JEU

[ DESIGN FOR FAILURE ]

Votre système tombera en panne !

Concevez-le afin qu’il y soit tolérant.

RÈGLES DU JEU

[ DESIGN FOR FAILURE ]

Votre système tombera en panne, c'est inévitable. Il doit être conçu pour cela (Design For Failure).

Prévoir la redondance à tous les niveaux : matériel (réseau, disque, etc.), applicatifs (plusieurs instances des applications), zones géographiques, providers (exemple : AWS + OVH).

RÈGLES DU JEU

[ TOOLKITS ]

Fournissez des toolkits, n’imposez pas de cadres stricts.

RÈGLES DU JEU

[ TOOLKITS ]

Attention aux composants techniques maisons et transverses ! Ils sont contraignants, coûteux et difficiles à maintenir.

Des accélérateurs, toolkits, stacks techniques peuvent être mis en commun, au libre choix des Feature Teams, en évitant une approche dogmatique.

RÈGLES DU JEU

[ CLOUD ]

Public, privé ou hybride, le cloud (IaaS ou PaaS) est la norme pour la production.

RÈGLES DU JEU

[ CLOUD ]

Les services de type PaaS sont à privilégier, ils sont simples et passent rapidement à l'échelle.

Les services IaaS permettent d'adresser les cas demandant une plus grande souplesse , mais ils demandent plus de travail opérationnel.

Un cloud privé n'est pas un environnement de virtualisation traditionnel, il s'appuie sur du commodity hardware.

RÈGLES DU JEU

[ INFRASTRUCTURE ]

Les Feature Teams ne gèrent pas l'infrastructure, elle est fournie et maintenue par l'organisation.

RÈGLES DU JEU

[ INFRASTRUCTURE ]

Les problèmes d'infrastructure ne sont pas du ressort des Feature Teams. L'infrastructure doit leur être fournie et maintenue par un service transverse.

RÈGLES DU JEU

[ CONTENEURS ]

Les conteneurs offrent la souplesse nécessaire à un outillage hétérogène.

RÈGLES DU JEU

[ CONTENEURS ]

Les conteneurs offrent la souplesse nécessaire aux Feature Teams pour leur permettre un outillage hétérogène dans un contexte homogène.

RÈGLES DU JEU

[ ENVIRONNEMENTS ]

L'utilisation de conteneurs permet de s'affranchir des problèmes d'environnements techniques.

RÈGLES DU JEU

[ ENVIRONNEMENTS ]

Les conteneurs (exemple : Docker) permettent de s'affranchir des différences d'environnement.

Le processus de déploiement doit être agnostique à l'environnement.

Certains composants comme les bases de données ne doivent pas être déployés dans des conteneurs. Leur déploiement est malgré tout automatisé.

RÈGLES DU JEU

[ MÉTRIQUES ]

Les mesures doivent être centralisées et accessibles à tous.

RÈGLES DU JEU

[ MÉTRIQUES ]

Les métriques sont accessibles à tous avec différents niveaux de granularité : vue détaillée pour la Feature Team concernée, agrégations pour les autres membres de l'organisation.

L'accès aux métriques n'implique pas l'accès aux données unitaires, celui-ci doit être contrôlé pour préserver la confidentialité.

Tous les environnements sont concernés.

RÈGLES DU JEU

[ QUALITÉ ]

La qualité logicielle est un facteur clé.

RÈGLES DU JEU

[ QUALITÉ ]

Les revues de code sont systématiques. Elles sont effectuées par des membres de la Feature Team ou d'autres membres de l'organisation, dans le cadre de l'amélioration continue.

Ça n'est pas vous qu'on audite mais votre code : "You are not your code !".

La qualimétrie peut être en partie automatisée, mais rien ne vaut l'"oeil neuf".

RÈGLES DU JEU

[ TEST AUTOMATISÉS ]

Le testing automatisé est un prérequis non négociable au déploiement continu.

RÈGLES DU JEU

[ TEST AUTOMATISÉS ]

Le testing automatisé permet d'assurer la qualité du produit dans le temps.

Il est un prérequis au déploiement continu, il permet changements et déploiements fréquents.

Le déploiement en production devient un événement anecdotique !

RÈGLES DU JEU

[ NIVEAUX DE TESTS ]

Des tests à tous les niveaux : unitaires, intégration, fonctionnels, résilience, performance.

RÈGLES DU JEU

[ NIVEAUX DE TESTS ]

Les tests d'intégration et fonctionnels sont les plus importants, ce sont eux qui garantissent le bon fonctionnement du produit.

Les tests unitaires sont adaptés au développement.

Les tests de performance permettent de mesurer la performance dans le temps.

Les tests de résilience permettent d'anticiper les pannes.

RÈGLES DU JEU

[ COUVERTURE ]

La couverture est le principal indicateur objectif de qualité des tests.

RÈGLES DU JEU

[ COUVERTURE ]

La couverture de code par les tests est une bonne métrique de la qualité du code.

C'est une condition nécessaire mais pas suffisante, la couverture d'une mauvaise stratégie de tests peut être élevée sans être garante de la bonne qualité du code.

RÈGLES DU JEU

[ SÉCURITÉ ]

La sécurité est un processus, elle ne doit pas être traitée en réaction aux problèmes.

RÈGLES DU JEU

[ SÉCURITÉ ]

Des experts sécurité peuvent être intégrés directement aux Feature Teams si nécessaire.

Des experts sécurité sont disponibles dans l'organisation pour auditer, sensibiliser et transmettre.