Le principe du CTO d'amorçage / Team as a Service est d'intervenir, à minima en binôme, dans une structure sans compétence disponible en développement logiciel (développement, gestion de projet, etc ...) afin de démarrer un projet, d'accompagner le client sur le développement et la conception de son produit ou MVP, de poser les bases d'une architecture saine et éventuellement de l'aider dans son recrutement de développeurs.

Nous avons abordé notre action de CTO d'amorçage / Team as a Service suivant trois axes : tout d'abord d'un point de vue apprentissage fonctionnel, puis d'un point de vue méthodologique et enfin d'un point de vue technique.

Apprentissage fonctionnel

Le métier de ce client était quelque chose de nouveaux pour nous, nous avons donc fait plusieurs ateliers d'Event Storming avec l'expert métier.

Le but de ces ateliers est multiple :

• Découvrir le langage métier de l'expert (et donc partager le même langage entre le code et la réalité métier)
• Découvrir le fonctionnement de l'outil, le process métier, les besoins
• Avoir une première idée / ébauche de la conception du logiciel

Ceci s'inscrit dans une approche Domain-Driven Design (DDD) ou Conception pilotée par le domaine (métier).

Ces ateliers sont refaits régulièrement, par exemple pour présenter un nouveau use case afin d'en explorer le fonctionnement.

Méthodologie

Chez Avalon Lab, nous sommes convaincus par les principes de développement agile.

Nous avons un fonctionnement assez proche de la méthode eXtrem Programming :

• Contact étroit avec l'expert métier
• Livraison fréquente
• Feedback régulier
• Binômage
• Développement piloté par les tests (TDD)
• Intégration et déploiement continue
• Rythme soutenable
• Conception simple

Intervenant dans un contexte "remote" dès le départ, l'expert métier n'étant pas localisé avec l'équipe de développement, nous avons mis en place plusieurs outils afin de collaborer efficacement en fonction des contraintes client :

• Gitlab (gitlab.com), pour la gestion de projets (user stories, bug tracker, milestone)
• Miro (miro.com), un tableau blanc collaboratif (schémas, atelier post-it)
• Skype ou autre, notamment pour faire des démos, via le partage d'écran.

Technique

L'approche DDD, notamment au travers d'ateliers type Event Storming, nous permet de mieux concevoir l'application.

L'application est découpée en domaine, unités logiques correspondant à un regroupement logique de sens métier.

Pour implémenter ces domaines, nous avons suivi les principes de l'architecture hexagonale où tout le code, correspondant aux règles métier, est correctement isolé de l'extérieur (base de données, web services, interface utilisateur) et n'est pas "pollué" par du code provenant d'un quelconque framework ce qui rend les choix de solutions type framework moins définitive et impactant.

Aujourd'hui, on sait que les fonctions principales d'un logiciel concernent principalement de la présentation de données (certains parlent de 80 % lecture de données et 20 % écriture de données).

Partant de ce constant, nous avons adopté le pattern CQRS (Command Query Responsibility Segregation) qui sépare les tâches d'écriture (command), des tâches de lecture (query) et ayant des modèles de donnés séparés.
[Ce pattern peut être étendu avec le principe d'Event Sourcing lorsque le métier requiert un traçage / audit des différentes actions.]

Toutes les décisions d'architectures / de choix techniques sont tracés dans des documents de décision d'architecture (Architecture decision record - ADR).

Architecture SI

L'architecture physique du SI évolue en fonction des besoins métier, tout en se basant sur les principes généraux des 12 factors

Nous avons d'un côté un frontal web (SPA) et de l'autre un backend métier.

Pour le backend métier, notre principe de base est de démarrer avec un monolithe, comme nous adoptons une démarche DDD, ce monolithe embarque nos domaines qui eux sont indépendants et correctement séparés.

L'avantage est de simplifier la phase de construction de l'application ainsi que sont déploiement et son monitoring tout en gardant la flexibilité de pouvoir sortir un domaine afin de répondre à un nouveau besoin ou à des contraintes de charges spécifiques.

De plus, cette architecture est déclinée en deux versions :

• Test/intégration => construite directement depuis les sources, à chaque modification (Continuous Deployement), permet aux développeurs et à l'expert métier de tester sur un environnement déployé.
• Production => construite et déployée à la demande, ouverte aux clients.

Technologie

Dans l'optique d'aider le client à recruter des développeurs et un CTO, nous sommes partis sur des technologies fiables, connues et pour lesquelles il est facile de recruter tout en respectant nos critères de qualités.

• VueJS / Web Component (lit-element)
• Java 11
• Gitlab : gestion de code et ci/cd
• Datadog : collecte et analyse des logs applicatives / monitoring [peut être remplacé par Elastic Stack]
• Clever Cloud : gestion de l'infrastructure
• Izanami : Configuration partagée, features flipping
• Warp10 : Base de données de séries temporelles
• Cellar / AWS S3 : stockage de fichiers
• SonarCloud : Analyse qualité du code

Cet article vous a intéressé, vous avez envie d'en savoir plus ou par rapport à vos besoins ?

N'hésitez pas à nous envoyer un mail à contact@avalon-lab.coop