Blog Posts

Accueil /
Blog Posts

Manifeste de la Continuous Architecture - Edition 1.0 (2019)

Ce document est la première édition (1.0) du Manifeste Continuous Architecture, publiée initialement en 2019. Il présente l’ensemble des convictions et principes fondateurs qui ont servi de base à l’approche Continuous Architecture.

France Travail - Kata architecture Hexagonale

Nous proposons un Kata sur l’architecture hexagonale que nous avons joué à l’occasion d’une conférence interne pour les développeurs de la DSI France travail.

France Travail - Pratique d'ADR

France Travail partage sa pratique ADR avec la procédure suivante et le fichier template ci-dessous :

Étude de cas Architecture for flow

Une étude de cas industrielle pour comprendre comment utiliser le Domain Driven Design et les Team Topologies pour concevoir une architecture orientée flux rapide.

Utiliser nos templates Miro

Téléchargez la dernière version du tableau Miro que vous souhaitez utiliser. À ce jour, nous proposons : Modèle Miro des Team Topologies Event storming Ouvrez Miro et cliquez sur Télécharger depuis une sauvegarde (Upload from backup). Cela créera un nouveau tableau intitulé Restored SOMETHING Il vous suffit ensuite de renommer le tableau et de commencer à l’utiliser en copiant-collant les différentes formes selon vos besoins. Modifier les modèles Miro et les partager Vous êtes entièrement libre de modifier nos tableaux pour les adapter à votre contexte. Si vous souhaitez partager ces modèles, plusieurs options s’offrent à vous :

Découverte du problème

Contexte et problématique Dans son livre « Kaizen et l’art de la pensée créative », Shigeo Shingo1 identifie trois étapes essentielles dans la résolution de problèmes :

Pourquoi changer notre façon d’architecturer nos solutions ?

Depuis une dizaine d’années, de nombreuses nouvelles pratiques d’ingénierie logicielle ont vu le jour, principalement dans le but de livrer plus rapidement nos produits à nos utilisateurs finaux. Parmi celles-ci : le lean management, l’agilité, la transformation DevOps, l’intégration continue et la livraison continue… Pourquoi une telle tendance ? Parce que la valeur n’est produite que lorsque le produit est déployé et utilisé. Tout ce qui n’est pas encore déployé n’est que de l’inventaire dans votre base de code source. Mais un domaine clé manquait encore dans cette transformation massive de nos pratiques d’ingénierie. Et si vous vous trouvez actuellement sur notre site web consacré à la Continuous Architecture, vous avez probablement déjà deviné de quoi il s’agit. Comme le dit l’adage : “Rome ne s’est pas faite en un jour.” On comprend donc qu’il est impossible de transformer toutes les disciplines en même temps. Mais pour achever cette transformation, il faut désormais s’attaquer à l’Architecture. Notre conviction : les méthodes et processus d’architecture d’hier ne permettront pas de livrer les solutions de demain. Si l’on prend un peu de recul, on peut dire qu’aujourd’hui, nous construisons le logiciel de manière continue. Il est donc temps d’adapter notre modèle opérationnel d’architecture à cette réalité !

Commencer le parcours

Commencez votre parcours Le déploiement des nouvelles méthodes de travail (pratiques, rituels, cadre) décrites dans le Cadre et la Boîte à Outils de Continuous Architecture constitue un véritable parcours de transformation. Il n’existe pas de trajectoire unique pour faire évoluer votre entreprise (ou une partie de celle-ci) depuis son état actuel vers l’état cible (ou étoile du nord) que nous recommandons et qui est incarné dans les principes du Manifeste de la Continuous Architecture - édition 1.

Étude de cas bancaire

Introduction Cette étude de cas bancaire est en cours de développement. Son objectif est d’illustrer les pratiques de la Continuous Architecture. Elle servira principalement à tester le méta-modèle et à fournir un exemple concret à utiliser lors des sessions de formation.

Le domaine Order to cash

Contexte et historique Il y a plusieurs années, nous avons repensé notre système d’information supportant les processus « order to cash » (de la commande à l’encaissement). À l’époque, nous utilisions un monolithe legacy (hébergé sur un mainframe) couvrant la majorité de ces processus. Nous avons choisi une approche best of breed : plusieurs solutions spécialisées ont été mises en œuvre pour couvrir les différentes étapes du processus, de la prise de commande à l’optimisation du transport jusqu’à la livraison logistique…

Ré-architecture de notre solution de séchage

Introduction Domain Driven Design (DDD) est un ensemble de concepts et de pratiques visant à aligner la structure et le langage du code logiciel avec le domaine métier qu’il soutient. Popularisé par Eric Evans, il a connu un fort regain d’intérêt ces dernières années. Une des principales difficultés lorsqu’on souhaite adopter le DDD pour modéliser et concevoir une solution est la suivante : « Par où diable commencer ? »

Blog Posts

Catégories