Vous êtes sur la page 1sur 34

Méthodologie de référence pour une entreprise numérique

agile
Version été-2021

reference-methodology/reference-methodology.md au master · wso2/méthodologie-référence · GitHub

Auteur actuel

 Asanka Abeysinghe | Évangéliste de la technologie en chef - WSO2, Inc | @asankama

Auteurs originaux

 Asanka Abeysinghe | Évangéliste de la technologie en chef - WSO2, Inc | @asankama (été-2018 - été-2021)


 Paul Fremantle | ancien directeur technique et cofondateur - WSO2, Inc | @pzfreo (été-2018 - printemps-2020)

Ce document décrit une méthodologie de référence pour les entreprises numériques agiles modernes. Notre objectif est de faire
passer les organisations de l’étape actuelle de maturité à l’étape agile d’intégration. Le résultat d’un passage plus haut dans le
modèle de maturité est d’augmenter la productivité des employés, d’économiser des coûts en réaffectant les ressources d’un
« centre d’excellence » à des équipes auto-organisées et de fournir une meilleure expérience client en étant aligné numériquement.
La méthodologie pour passer à travers ces étapes de maturité implique des personnes, des processus et de la technologie.

Introduction
À mesure que les API, les microservices, les logiciels en tant que service (SaaS) et les architectures sans serveur évoluent,
l’intégration ne s’estompe pas ; au lieu de cela, presque chaque nouvelle application implique l’intégration sur un ensemble de
points de terminaison éclatés. Le mantra microservices des points de terminaison intelligents et des canaux muets résout
fondamentalement un problème plus profond. L’intégration doit apprendre du code pour devenir immuable, de type sécurisé,
testable, construit et déployé en continu afin qu’ils soient plus robustes, résilients et surtout agiles.

Une méthodologie
Une méthodologie officialise une approche pour atteindre un objectif particulier ou un ensemble d’objectifs. Notre objectif final est
de rendre une intégration oraque agile. La méthodologie proposée est un processus itératif caractérisé par cinq étapes. En outre, la
méthodologie définie dans ce document examine les améliorations organisationnelles en trois dimensions.

La méthodologie ne s’attend pas à ce qu’une organisation parte de zéro, mais plutôt à ce qu’elle effectue d’abord
une évaluation pour comprendre l’état actuel et définir un chemin pour passer au niveau souhaité suivant. Ce document décrit un
méta-processus permettant aux organisations de se référer et de devenir agiles en matière d’intégration.

Modèle de maturité
Un modèle de maturité définit comment une organisation peut mesurer l’étape actuelle de l’agilité d’intégration et définit une
direction d’amélioration dans trois dimensions : les personnes, les processus et la technologie. Il y a deux éléments fondamentaux
pour permettre l’amélioration continue d’une organisation et passer à droite dans le modèle de maturité :

 Pour les gens et les processus, la fondation est la culture d’une organisation.

 Pour la technologie, la base est l’architecture conçue et mise en œuvre par l’organisation.

Vue récapitulative
monolithiqu Cascade
Piloté par API Agilité précoce Intégration Agile
e rapide

Équipes auto-
gens Centralisé Coe Équipes API décentralisé
organisées

Cascade
processus cascade API Itérative Semi-continu continu
rapide

Technologie silo EAI/ESB Piloté par API Agilité précoce Agilité continue

Alignement Débuts Le numérique


séparer Ad hoc adaptatif
numérique stratégiques d’abord

Le modèle de maturité défini ici contient cinq étapes, et chaque étape est définie en trois dimensions. Examinons chaque dimension
en détail.

gens
Les gens et leur capacité à définir des solutions en comprenant la situation actuelle est la chose la plus importante pour une
organisation. La culture et la structure organisationnelle contrôlent la façon dont les gens fonctionnent, et c’est la plate-forme pour
permettre la productivité des gens. La culture joue un rôle important dans l’adaptation au changement. Les habitudes et les
meilleures pratiques héritées de la culture d’une organisation sont plus puissantes que celles simplement appliquées par les
stratégies.
La structure organisationnelle et décisionnelle influe sur la façon dont les idées novatrices de chaque partie de l’organisation sont
mises en œuvre et transmises aux utilisateurs finaux. Les structures traditionnelles divisées en pyramides, en étoile et en étoile
créent une mentalité de centre d’excellence (COE) et peuvent rapidement bloquer le flux d’innovation. Comme alternative, nous
proposons une structure organisationnelle podulaire, qui permet aux organisations de devenir adaptatives, innovantes et agiles. Les
personnes (organisation et culture) doivent passer d’approches séquentielles en cascade et en cascade agiles qui incluent des
équipes « centre d’excellence » cloisonnés à un ensemble fondamentalement décentralisé d’équipes agiles. Dans une structure
podulaire, chacune de ces équipes est alors responsable de la construction, de l’exécution et de la gestion de leurs applications
d’intégration. L’une des principales caractéristiques d’une structure d’organisation podulaire est que chaque pod agit comme une
unité commerciale individuelle [2] ce qui permet d’opérer et de prendre des décisions de manière indépendante ainsi que d’ajouter
les personnes ayant les compétences requises à l’équipe.

processus
Le processus définit les étapes qu’une organisation doit suivre pour atteindre ses objectifs. Un processus est connecté avec les
personnes impliquées dans son exécution, ainsi qu’avec la technologie mise en œuvre pour optimiser leur productivité. Ce
document se concentre principalement sur la définition d’un méta-processus.
Bien que de nombreux processus de développement de logiciels aient été introduits, nous pouvons tous les placer dans deux
compartiments: en cascade et agile. À ce jour, il y a eu de nombreuses tentatives pour devenir vraiment agile, mais cela n’a pas été
une tâche facile en raison de plusieurs contraintes techniques et culturelles. En conséquence, de nombreuses entreprises ont dû se
rabattre sur des processus agiles en cascade ou rapides. Cependant, nous vivons maintenant à une époque avec des améliorations
DevOps et des infrastructures de déploiement extrêmement flexibles, qui créent des processus continus qui permettent aux équipes
de fonctionner de manière vraiment agile.

Technologie
Bien que la méthodologie de référence concerne fondamentalement les personnes et les processus, elle comporte des exigences
technologiques qui doivent être satisfaites pour permettre les bons processus et la bonne approche. Par exemple, l’intégration
continue décentralisée/le développement continu (CI/CD) avec le déploiement canary nécessite un modèle d’orchestration cloud, tel
que Kubernetes.For example, decentralized continuous integration/continuous development (CI/CD) with canary deployment
requires a cloud orchestration model, such as Kubernetes. Le développement agile d’applications d’intégration nécessite des outils
d’intégration qui prennent en charge la construction, le test et le déploiement continus. Cela pousse un glissement des approches
de configuration sur code telles qu’un bus de service d’entreprise (ESB) vers des approches code sur configuration qui apportent la
validation de type et l’intégration de l’environnement de développement intégré (IDE) et fonctionnent plus efficacement avec le
contrôle de version et les outils CI/CD. Les applications d’intégration doivent fonctionner dans des environnements cloud natifs, y
compris des conteneurs et sans serveur. Les applications d’intégration doivent être observables à l’aide d’outils de suivi et de
surveillance distribués.

Comme nous l’avons décrit précédemment, l’architecture est le fondement de la technologie. L’architecture fait référence à la
maturité de l’architecture globale d’entreprise et d’intégration de l’organisation ainsi qu’à l’adoption de la technologie. Dans l’article
WSO2 Reference Architecture (RM) for Agility [1], nous avons discuté de trois modèles architecturaux émergents; en couches,
segmentées et basées sur des cellules, qui peuvent représenter l’architecture d’entreprise et d’intégration mise en œuvre ou
planifiée dans n’importe quelle organisation. Le modèle d’architecture souhaité a un impact direct sur l’utilisation technique et sur la
façon dont une organisation peut appliquer une approche agile (architecture itérative) dans la pratique.
La dimension de l’architecture représente la maturité de l’intégration interne et externe de l’entreprise, le niveau d’intégration ainsi
que la fluidité.

Alignement numérique
L’alignement numérique est un résultat de l’amélioration des personnes, des processus et de la technologie. L’alignement
numérique se concentre principalement sur la maturité de la transformation numérique, tant en interne qu’en externe, avec les
employés et les clients. En interne, elle affecte la façon dont les employés bénéficient des produits et des points de terminaison
numériques, tels que les API, les événements et les flux, pour augmenter leur productivité et améliorer leur processus de prise de
décision. En externe, cela affecte les expériences que les clients et les partenaires ont avec les produits et les points de terminaison
numériques axés sur la possibilité d’une transformation externe. À l’ère numérique actuelle, les consommateurs recherchent une
expérience en temps réel, personnalisée, géosensible et prédictive des produits et services qu’ils utilisent.

Plate-forme pour la maturité organisationnelle


Ensemble, la culture et l’architecture créent une plate-forme permettant aux personnes, aux processus et à la technologie de
fonctionner et de s’améliorer. La culture joue le rôle principal dans le soutien des gens tandis que l’architecture a le rôle principal
dans le soutien de la technologie. Cependant, ces deux fondations ont des rôles qui se chevauchent et qui sont complémentaires
pour soutenir les trois piliers de l’alignement numérique : les personnes, les processus et la technologie.

Modèle de maturité : perspectives actuelles


Modèle de maturité agile : Matrice
monolithique Cascade rapide Piloté par API Agilité précoce Intégration Agile

Équipes auto-
COE: Des équipes
Équipes API: les organisées: A
de
équipes sont décentralisé les
développement Décentralisé:A
distribuées ; des équipes et la prise
uniques ou distribué des
projets parallèles de décision. Les
importantes sont équipes avec des
Centralisé: L’équipe sont en cours projets et les
contrôlées et plates-formes
gens est structurée autour d’exécution, mais systèmes se
régies par technologiques
d’un seul projet. les dépendances connectent à l’aide
plusieurs centres centralisées et des
et le modèle du pipeline DevOps.
d’excellence pratiques EA qui
d’exécution les Les équipes peuvent
(COE). La créent un COE.
ramènent en livrer des projets
gouvernance est
cascade. rapidement et
complexe.
indépendamment.

processus Cascade:ollows un Cascade API Itérative: Les Semi-continu: Continuous: a une


processus de rapide:Suit une applications de Les processus approche pipeline-
cascade. Exécute un méthode en l’utilisateur final continus sont liés first pour chaque
projet à la fois. cascade ou en et le à la plate-forme projet et des
spirale. A de développement centrale. A un pipelines de mise en
longs cycles de d’API suivent un pipeline de build, production
publication de processus agile ce qui crée un individuels pour
projet. Est très en se divisant en autre COE chaque
monolithique Cascade rapide Piloté par API Agilité précoce Intégration Agile

équipe/projet. Les
processus sont
non agile. petites équipes.
entièrement
automatisés.

Agilité précoce:
utilise des ESB
légers avec
Agilité continue:
Piloté par API: la intégration et test
Intégration
gestion des API continus, mais
Silo: Legacy et COTS* décentralisée
EAI/ESB: est utilisée au toujours
fonctionnent comme automatisée avec les
S’appuie sur les sein des centralisés, avec
des silos. Il y a peu API, les flux et les
technologies EAI organisations découverte
Technologie ou pas de pratique événements publiés
et/ou ESB pour rationaliser manuelle,
d’EE. Les données et découverts dans
héritées. Est très la gouvernance gouvernance et
sont agrégées les registres fédérés
non agile et fournir une autres processus.
manuellement. et ci/cd. Utilise une
découverte L’adoption
architecture basée
décentralisée. précoce de
sur les cellules.
l’architecture de
microservices se
produit.

Alignement Séparer:L’entreprise Ad-hoc: Early Strategic:P Digital-First: Est Adaptive: Offre une
numérique s’exécute L’entreprise se aide une connecté à expérience
monolithique Cascade rapide Piloté par API Agilité précoce Intégration Agile

l’écosystème.
connecte avec numérique
Fournit une
des partenaires et multicanal complète
expérience
a initié la expérience pour les
individuellement. La numérique
transformation numérique de consommateurs.
périphérie de multicanal aux
numérique. base pour le S’adapte en fonction
l’entreprise est clients en temps
Cependant, seuls client de manière des commentaires et
déconnectée de la réel ou presque.
les par lots ou en de la demande des
gestion. Chaque
consommateurs temps quasi réel. consommateurs à
consommateur a
internes en l’aide de l’analyse et
une identité
bénéficient. de l’IA.
numérique.

(*Logiciel commercial standard. **Centre d’excellence. )

Modèle de maturité : vue pragmatique


Le modèle de maturité a une séparation verticale définie de chaque étape, mais la plupart des organisations peuvent avoir du mal à
s’intégrer dans un pilier vertical. Par conséquent, une organisation peut s’aligner sur trois étapes horizontales différentes, comme le
montre le diagramme.

Cette approche aide une organisation à planifier la transformation et à savoir où mettre plus d’efforts et de concentration.

Par exemple, une organisation peut passer à une infrastructure cloud native complète avec un pipeline CI/CD mature, mais la
structure d’équipe peut ne pas être suffisamment podulaire pour avoir une entreprise véritablement agile.

Comment passer au RIght dans le modèle de maturité : méthodologie


«  La transformation est un voyage sans destination  »  - Marilyn Ferguson

Approche : Transformation itérative des activités


L’approche globale consistant à passer d’une étape à une autre est itérative. Planifiez, mettez en œuvre, examinez, améliorez et
revenez au plan. En outre, commencez petit en commençant par un petit groupe, un seul projet et un secteur d’activité au lieu
d’adopter une approche à l’échelle de l’entreprise. Sauter des étapes est dangereux parce que tout changement prend du temps
pour que les gens adoptent et deviennent productifs. Par conséquent, la réduction au minimum du changement à chaque étape est
un facteur important pour pouvoir continuer comme d’habitude pendant que la transition se déroule en parallèle.

Monolithique à Fast-Waterfall
Personnes: Organisez les équipes de développement en introduisant les méthodologies de développement de logiciels de base
décrites ci-dessus. Intégrez la gouvernance en introduisant un système de contrôle de code source et des infrastructures de test. La
qualité du code et les révisions de conception peuvent être manuelles.

Processus: Introduisez un processus de développement logiciel principal, tel que la cascade ou la spirale au lieu d’utiliser un
processus de développement ad hoc.

Technologie: Définissez une architecture d’entreprise à l’aide d’un modèle d’architecture en couches. Catégoriser chaque couche en
fonction de la fonctionnalité, la plupart des organisations suivent une vue « système de système » (SoS) [4] lors de la définition de
chaque couche d’architecture. Commencez à connecter des systèmes internes et externes à l’aide de l’intergiciel (middleware)
d’intégration et de messagerie.

Alignement numérique: Créez des applications et des tableaux de bord internes en utilisant les données consolidées recueillies en
intégrant les systèmes internes et les partenaires.

Cascade rapide vers pilotée par API


Personnes: Construisez plusieurs plans et groupes de projets en planifiant l’exécution de projets en parallèle.

Processus: Introduisez de l’agilité en convertissant les équipes de développement d’API et d’applications utilisateur final en petites
équipes. Utilisez les API comme connecteurs pour ces petites équipes.

Technologie: Démarrez un programme d’API et exposez les fonctionnalités métier de base créées par l’intégration de systèmes
internes et externes en tant qu’API. Suivez les instructions de conception des API [5] et normalisez les API dans le secteur.
Encouragez les développeurs d’applications internes et externes à utiliser les API lors du développement d’applications pour
consommer des fonctions et des données métier. Utilisez la fédération et passez à une architecture segmentée à partir de
l’architecture de la cour.

Alignement numérique: Encouragez les développeurs d’applications internes et externes à fournir des idées créatives et
compétitives en tant qu’expérience numérique pour les consommateurs en utilisant les API. Permettre aux partenaires de se
connecter de manière transparente à l’aide des API.

Api-Driven à l’agilité précoce


Personnes: Distribuer la prise de décision et la gestion à chaque équipe de projet. Fournir des fonctionnalités techniques en tant
que service partagé via une plate-forme. Appliquer la gouvernance et les politiques via la plateforme.

Processus: Améliorez le processus agile introduit dans l’étape précédente en apportant l’intégration continue et la livraison
continue (CI/CD) en s’associant à l’équipe DevOps qui gère l’infrastructure centralisée et les plateformes technologiques.
Technologie: Passez à une architecture segmentée basée sur l’étendue des services. Autorisez le déploiement décentralisé dans la
mesure du possible. Encouragez l’utilisation de pratiques DevOps automatisées et lancez une intégration et une livraison continues.
Commencez à utiliser des environnements de déploiement légers, tels que des machines virtuelles et des conteneurs basés sur un
hyperviseur.

Alignement numérique: Fournir une identité numérique unique à chaque consommateur interne et externe. Créez un échange
d’informations en temps réel et quasi réel avec les consommateurs via des applications numériques. Étendez la portée numérique
du consommateur à plusieurs canaux en plus du Web et du mobile en étendant les capacités de l’Internet des objets (IoT).

Agilité précoce à l’agilité d’intégration Agile


L’objectif principal de ce document est de rendre votre organisation plus agile en matière d’intégration. Par conséquent, nous
mettons l’accent sur cette section par rapport au reste des étapes de transition déjà décrites. La plupart des organisations ont un
effort actif pour passer à droite dans le modèle de maturité et répondre à la demande des consommateurs et rester au top de la
concurrence. Les pratiques exemplaires et les lignes directrices fournies dans cette section aident les organisations à passer
directement au modèle de maturité, quel que soit le niveau de maturité actuel.
gens

Noyau agile

Étant donné qu’être itératif est fondamental pour une organisation agile en matière d’intégration, la transformation de la culture
doit également être gérée de manière itérative. Former un petit groupe que nous appelons le noyau Agile est la première étape de
ce processus. L’équipe agile-core est un facteur de réussite essentiel dans l’ensemble du parcours de transformation d’une
organisation. Par conséquent, soyez attentif lorsque vous choisissez des personnes pour cette équipe. Il y a trois règles à suivre. Tout
d’abord, choisissez la poignée de personnes qui acceptent le changement et s’adaptent rapidement. Deuxièmement, choisissez les
personnes qui ont les compétences requises ou qui peuvent facilement être formées. La troisième consiste à choisir un ensemble
diversifié de personnes qui représentent différents niveaux et rôles. L’idée ici de suivre la formation du formateur et de laisser le
noyau agile former les autres et transformer l’ensemble de l’organisation en une main-d’œuvre agile et numérique. De nombreuses
approches peuvent être adoptées dans cette activité de transformation, telles que la formation structurée, les camps d’entraînement,
les hackathons, les déjeuners-causements et les laboratoires d’innovation.

Équipes auto-organisées

Nous avons remarqué des équipes réparties avec des projets parallèles en cours d’exécution dans les premières étapes de maturité.
Cependant, les équipes distribuées dépendent de divers centres d’excellence lorsqu’il s’agit de la livraison de bout en bout d’un
projet. La motivation derrière les équipes auto-organisées est d’avoir une structure décentralisée appropriée. Une structure
organisationnelle podulaire fournit la plate-forme pour créer des équipes auto-organisées et fonctionner avec succès. Les équipes
auto-organisées planifient, construisent, exécutent et gèrent leurs applications de manière indépendante. Dans le même temps, les
fonctionnalités métier détenues sont exposées à l’aide de points de terminaison qui exposent des données sous forme d’API,
d’événements et de flux.

Tout le monde est un maître Agile


La plupart des méthodologies agiles encouragent à avoir un maître agile pour chaque équipe agile. Cependant, les équipes auto-
organisées fonctionnent différemment. Les membres de l’équipe sont engagés, habilités et chargés de mettre en œuvre des idées
innovantes et de fournir des produits numériques aux utilisateurs finaux. Par conséquent, chaque membre de l’équipe agit en tant
que maître agile dans différentes étapes et domaines du projet, quels que soient les niveaux hiérarchiques attribués par
l’organisation.

processus

itératif

Une organisation agile d’intégration utilise un modèle d’exécution itératif dans les processus métier et techniques. Il est facile de
définir des processus itératifs mais difficile à exécuter sans une culture et une architecture conventionnelles. Les sous-sujets dont
nous discutons sous Organisation et culture sont essentiels à la création d’une culture de soutien. Les principes fondamentaux de
l’approche itérative sont de commencer petit tout en ayant une vision plus large et en itérant continuellement vers la cible. La
planification d’itérations comprises entre un mois et trois mois est efficace.

Continu (Agile + DevOps)

Le processus continu que nous décrivons dans ce document est une combinaison d’agilité et de DevOps amélioré, qui fait partie du
développement et utilise une infrastructure cloud native. La combinaison de DevOps et du développement permet un processus
continu automatisé de bout en bout. Cette approche rationalise le processus de publication et augmente la productivité des équipes
de développement.

La programmabilité est un facteur essentiel pour une véritable agilité. Cette approche va au-delà de l’automatisation de
l’infrastructure, qui est une pratique courante en permettant l’accès par programme pour automatiser les actions, les procédures, les
processus et les runtimes utilisés dans l’ensemble du cycle de vie d’une application. Grâce à la programmabilité et à l’automatisation
de bout en bout, les équipes peuvent augmenter la productivité et la flexibilité et mettre rapidement hors service les tâches
reproductibles; ils peuvent également consacrer plus de temps à la mise en œuvre d’idées novatrices.
Code sur la configuration

Une approche basée sur la configuration, associée à l’utilisation de couches d’intergiciel (middleware) lourdes, est le principal
bloqueur qui empêche les équipes de développement de fonctionner en mode agile réel. Il est difficile de lier des modèles de
développement basés sur la configuration à un pipeline de mise en production continu et à un cycle de vie d’application
entièrement automatisé avec plusieurs étapes du cycle de vie (environnements). En outre, la plupart des runtimes d’intergiciel
(middleware) ne sont pas des microservices et des cloud-natives. En tant que solution, une approche basée sur le codage qui utilise
un langage de programmation optimisé pour l’intégration permettra aux équipes de répondre à l’agilité et à la conformité
attendues avec un pipeline continu.

L’intégration d’abord

Le modèle de programmation a évolué au cours de la dernière décennie pour adopter une approche axée sur l’intégration d’abord.
Cela est principalement dû aux points de terminaison programmables et réutilisables que les entreprises ont créés à l’aide de divers
modèles d’architecture distribuée, tels que l’architecture orientée services (SOA), l’architecture pilotée par les événements (EDA) et
l’architecture de microservices (MSA). Par conséquent, chaque programmeur est aujourd’hui un ingénieur d’intégration. De plus,
l’architecture d’entreprise moderne est axée sur l’intégration, avec des applications et des services qui ont chacun des dizaines à des
centaines de points de terminaison composables.

Technologie

Pipeline réglé

Les développeurs passent beaucoup de temps à créer leurs environnements sandbox et à les lier au système de contrôle de code
source et au pipeline de génération. Parfois, ils ne suivent pas les normes en raison de la configuration manuelle et de la liaison. Le
concept de pipeline prêt est une solution pour ce qui fournit l’environnement sandbox et des liens vers les outils de développement
en une fraction de temps à l’aide d’un processus automatisé. La préparation des pipelines augmente la productivité des
développeurs et applique les normes de gouvernance et de développement. En outre, il permet aux développeurs de s’approprier la
plupart des responsabilités DevOps du jour 1 et de gérer les pipelines CI/CD spécifiques au projet.

Cycle de vie des applications multi-environnements

Le cycle de vie de développement et de déploiement traditionnel d’une build d’application est basé sur un minimum de trois
environnements : développement, test et production. Certaines organisations ont ajouté un environnement intermédiaire en tant
que site sécurisé pour déboguer les problèmes de production. Toutefois, la nature itérative et de publication rapide de l’équipe
auto-organisée nécessite l’ajout de plus d’environnements pour être productifs, ainsi que d’une infrastructure, d’un pipeline CI/CD
et d’une prise en charge de la pratique DevOps. Nous envisageons d’ajouter des environnements de test bleu-vert, canary et A/B
automatisés au cycle de vie de l’application.

Développement piloté par les tests

Traditionnellement, le test d’une application est une action secondaire exécutée par un groupe distinct en créant un autre silo ou un
CoE. Dans un environnement agile d’intégration, l’équipe de projet elle-même est responsable de la livraison d’une application de
haute qualité. (N’oubliez pas que les équipes de projet planifient, créent, exécutent et gèrent l’application.) Par conséquent, le test
fait partie de l’équipe de projet, qui est exécutée par les développeurs. Les tests automatisés (unité, performances et intégration)
avec les données de test et les systèmes de test (par exemple, les services fictifs) doivent être créés avant que le développement et
les tests automatisés ne s’exécutent sur le code dès le premier jour. Les développeurs doivent enrichir l’infrastructure de test en
introduisant de nombreux scénarios de test basés sur divers cas d’utilisation métier et techniques (fonctionnels et non fonctionnels).
Certaines organisations l’appellent la grille de test, ce qui renforce la qualité de l’application.

Cloud natif

La nature fortement décentralisée d’une équipe auto-organisée et les responsabilités DevOps distribuées nécessitent une
infrastructure appropriée pour prendre en charge les organisations agiles d’intégration. Une architecture cloud native basée sur des
conteneurs et des systèmes d’orchestration de conteneurs aide les équipes de développement à utiliser une infrastructure
standardisée à l’échelle de l’entreprise pour déployer et exécuter des applications et toutes les dépendances. L’utilisation de
conteneurs pour mettre à l’échelle automatiquement, empaqueter des applications, régler le pipeline et prendre en charge CI/CD
par provisionnement rapide de l’environnement sont quelques fonctionnalités cloud natives de base qui peuvent être utilisées par
des équipes auto-organisées. En outre, les fonctionnalités avancées telles que les architectures pilotées par les événements et
basées sur les fonctions peuvent utiliser une infrastructure cloud native pour améliorer l’agilité globale de l’intégration.

Architecture basée sur les cellules

Les modèles architecturaux émergents, tels que les architectures en couches et segmentées, sont centralisés ou dépendent des ce
centralisés. En revanche, les microservices définis dans une architecture de microservices (MSA) sont trop granulaires pour être
traités comme une unité d’architecture. Par conséquent, les équipes auto-contrôlées ont besoin d’une architecture de référence
pour définir les limites de l’architecture logique et physique dans l’entreprise dans son ensemble.

Nous avons introduit l’architecture basée surles cellules [1] comme solution à ce problème pour disposer d’une architecture
d’entreprise de pointe en matière de microservices et d’architecture cloud native à utiliser dans un environnement agile en matière
d’intégration. L’architecture basée sur les cellules permet la conversion de systèmes, de services et de données hérités en cellules, et
elle réutilise les fonctionnalités en combinaison avec les cellules natives du cloud. En un mot, l’architecture basée sur les cellules
permet de s’appuyer sur le développement des friches industrielles.

libre

Dans un environnement agile d’intégration, vous prévoyez de faire de nombreuses innovations dans les laboratoires (notez que la
recherche et le développement font partie des équipes auto-organisées), ainsi que le développement rapide d’applications en
suivant un modèle d’exécution itératif. Dans un tel environnement, vous ne pouvez pas vous permettre d’attendre des processus
d’approvisionnement longs (et lents) pour adopter les technologies qui vous permettront de concrétiser vos idées novatrices. L’open
source joue un rôle important ici en vous donnant accès à des technologies robustes et stables qui sont utilisées et apportées par
une communauté plus large. Vous pouvez choisir des technologies fournies sous des licences open source conviviales pour les
entreprises, telles qu’Apache 2.0, pour éviter toute ligne rouge d’entreprise à l’avenir.
Le paragraphe ci-dessus n’expliquait qu’un seul aspect de l’effet de l’open source pour une organisation, qui est l’utilisation de
l’open source et l’augmentation de la productivité. Contribuer à l’open source et créer une culture ouverte avec des pratiques open
source sont deux autres aspects.

Contribuer au mandat du projet open source par certaines des licences open source, mais plus que cette contribution est une
éthique d’utilisation de l’open source. Les organisations peuvent créer des équipes d’écosystème et contribuer à des projets open
source en fonction de la pertinence. Cette approche présente de nombreux avantages. Apprendre d’un public plus large en dehors
de l’organisation et augmenter l’utilisation du code que les équipes de l’écosystème écrivent sont quelques avantages qui peuvent
être mis en évidence.

Le travail d’équipe isolé au sein d’une entreprise ou d’une unité fonctionnelle peut se transformer en travail de développement
collaboratif à l’aide de pratiques open source. La plupart des organisations commencent par l’innersourcing (un mot inventé par Tim
O’Reilly en 2000) - le développement collaboratif entre les équipes, mais au sein de l’organisation est la principale caractéristique de
l’innersourcing. En outre, le code n’est pas disponible dans un référentiel public pour que des personnes extérieures y accèdent ou y
contribuent. La deuxième étape est open source que le développement et l’accès au code sont disponibles pour les étrangers, mais
la plupart des contributions provenant de la communauté interne. La troisième étape est une communauté ouverte que le projet a
donnée à une fondation indépendante telle que Apache Foundation(ASF)ou Cloud Native Computer Foundation(CNCF). La
gouvernance du projet géré par la fondation et la contribution peuvent provenir de toute personne utilisant ou désireuse de
s’engager dans le projet.

Alignement numérique

Exigences axées sur les consommateurs

L’une des caractéristiques essentielles d’une architecture podulaire est d’amener des équipes de développement auto-organisées à
la périphérie de l’entreprise et de fournir un accès aux consommateurs. Minimiser l’écart entre le consommateur et le producteur
aide à mettre en œuvre des solutions qui sont réellement requises par les consommateurs sans travailler sur des exigences
hypothétiques qui se répercutent sur de nombreux CE. Les équipes de développement peuvent avoir un dialogue direct avec les
consommateurs à l’aide de différents canaux, analyser le comportement des consommateurs et examiner les perspectives du
marché lors de l’identification et de la hiérarchisation des besoins de l’entreprise. Les petites itérations et le développement rapide
d’applications aident les équipes auto-organisées à fournir rapidement une fonctionnalité et à la tester avec les consommateurs
réels (y compris la restauration d’une fonctionnalité). Les équipes techniques ont tendance à compliquer les exigences en les
examinant d’un point de vue technique. Dans un environnement agile d’intégration, les exigences que les équipes examinent sont
du point de vue du consommateur (ou de l’entreprise) et simplement basées sur l’expérience du consommateur et l’avantage
concurrentiel.

Commencez avec un MVP

La nature axée sur le consommateur et la culture d’entreprise d’abord entraînent des changements rapides des exigences et de
l’expérience utilisateur. Les consommateurs sont impatients de consommer de nouvelles expériences numériques et de se rendre
productifs lors des activités quotidiennes. Une fois qu’ils n’obtiennent pas l’expérience qu’ils recherchent, ils changent de fournisseur
de services. En outre, il y a un avantage concurrentiel à introduire une nouvelle idée sur le marché avant que les concurrents ne
fournissent la même chose. La planification, la mise en œuvre et le lancement d’un produit viable minimal (MVP) sur le marché est le
meilleur moyen de s’en tenir au modèle d’exécution itératif, plutôt que d’avoir de longs cycles de livraison de produits qui suivent
des méthodologies en cascade ou en cascade rapide. Les équipes auto-organisées obtiennent la base et la plate-forme en restant à
la périphérie, près des consommateurs pour les comprendre correctement et définir le MVP.

Fournir des applications natives numériques

Comme nous l’avons expliqué précédemment dans ce document, les consommateurs de l’ère numérique moderne viennent avec
certaines attentes prédéfinies. Pour mettre à nouveau l’accent sur les attentes numériques actuelles, celles-ci incluent des
expériences en temps réel, personnalisées, géosensibles et prévisibles à partir d’applications numériques. Les applications
perturbatrices libérées par les équipes auto-organisées doivent être natives du numérique pour gagner le marché et fournir des
services à long terme aux consommateurs.

Appliquer les boucles de rétroaction


Un modèle d’exécution itératif utile nécessite des commentaires provenant de l’utilisation et du comportement d’exécution. Une
architecture basée sur des cellules applique les passerelles de cellule pour acheminer les communications et fournir suffisamment de
hooks pour capturer les données requises pour identifier les commentaires sur l’utilisation et le comportement des runtimes. Les
commentaires constructifs doivent être pris en compte lors de la planification de l’itération suivante afin d’améliorer l’expérience
utilisateur et le comportement d’exécution.

Objectif transformateur

La définition de la stratégie de transformation en fonction d’un objectif aide à gérer un programme de transformation réussi et à
fournir des résultats alignés sur l’entreprise. Différents cadres peuvent utiliser pour y parvenir, les cadres les plus populaires sont
OKR (Objectifs et résultats clés) et MTP (Objectif massivement transformateur). La définition de l’objectif et des résultats mesurables
est un exercice que le stratège numérique ou le comité de pilotage doit mener avant d’exécuter les activités de la stratégie de
transformation. Une analyse approfondie des priorités internes, de la demande des clients, de la concurrence et des perspectives du
marché aide à définir l’objectif transformateur. Le modèle de maturité peut être utilisé pour démarrer le processus en effectuant
une évaluation ainsi qu’un guide pendant le parcours de transformation.

Conclusions
La transformation numérique est le facteur de réussite essentiel des entreprises modernes, et les leaders de l’industrie ont identifié
la transformation numérique comme la quatrième révolution industrielle. Par conséquent, les organisations doivent planifier et
exécuter la transformation sans perdre leurs personnes, systèmes, données et clients existants. Cependant, l’intégration est devenue
un facteur essentiel dans le développement d’applications avec l’explosion des points de terminaison consommables que nous
avons créés au cours des deux dernières décennies en construisant des systèmes hautement distribués. Les organisations essaient
de suivre des modèles d’exécution agiles pour leur intégration, mais reviennent aux modèles traditionnels en cascade ou en spirale
en raison du non-alignement de la structure organisationnelle, de la culture, de l’architecture, de l’utilisation de la technologie et de
la stratégie numérique de leurs équipes d’intégration. Ce document décrit un modèle de maturité permettant aux organisations
d’identifier leur position en ce qui concerne leur agilité d’intégration et d’aider à planifier un chemin de transformation pour devenir
véritablement agiles en matière d’intégration. Le contenu recueilli et proposé est basé sur notre expérience de travail avec de
nombreuses entreprises sur leurs initiatives d’intégration et de transformation numérique.

Faits saillants de la prochaine version

Entreprise cellulaire
En utilisant la biologie comme métaphore pour définir la structure organisationnelle moderne construite avec une architecture
podulaire se composent de nombreuses équipes auto-organisées. L’entreprise cellulaire définit les unités associées à une
application, de l’humain qui conçoit et construit à un composite qui se déploie à la fin. Reportez-vous à l’article de Forbes pour plus
de détails.
Type de
description unité cartographie
cellule

Cellule C Cellule composite composite Déploiement décentralisé

Cellule de Bac à sable de


Cellule D Développement autonome
développement développement

Cellule A Cellule Architecture Bloc d’architecture Architecture basée sur les cellules

Cellule B Cellule d’affaires Fonction commerciale Modèle d’affaires cellulaire

Cellule H Cellule humaine Équipes auto-orgénisées Organisation podulaire (équipe d’équipes)

références
[1] Document sur l’architecture de référence WSO2 pour l’agilité : https://github.com/wso2/reference-
architecture/blob/master/reference-architecture-cell-based.md

[2] Dave Gray - The Connected Company - http://www.xplaner.com/connectedco/

[3] Architecture itérative et segmentée - https://www.slideshare.net/asankama/iterative-architecture-your-path-to-ontime-delivery

[4] Système de systèmes (SoS) : https://en.wikipedia.org/wiki/System_of_systems

[5] Directives de conception d’API : https://wso2.com/whitepapers/wso2-rest-apis-design-guidelines/


[6] Évaluation de la maturité agile WSO2 : https://wso2.com/agile-maturity-assessment

[7] WSO2 Impulse (Conseil stratégique) : https://wso2.com/strategic-consulting/

[8] L’entreprise celleulaire (article de Forbes) : https://www.forbes.com/sites/forbestechcouncil/2020/06/29/the-cellular-


enterprise/#786824316832

Vous aimerez peut-être aussi