Une entreprise ne modifie que rarement, voire jamais, l’architecture d’une application pour la beauté du geste. Il existe en général une raison sous-jacente, et cette raison, c’est une opportunité business.
Dans ce chapitre, nous allons amorcer le processus de modification de l’architecture. Pour ce faire, nous observerons tout d’abord la nouvelle opportunité business présentée et les besoins architecturaux correspondants. Puis, nous examinerons d’autres opportunités qui peuvent capitaliser sur notre nouvelle architecture. Enfin, nous exprimerons ces opportunités sous forme de user stories.
Attendez une seconde, pourquoi ai-je besoin de comprendre les opportunités business ?
Ne devrais-je pas m’occuper uniquement du code ?
C’est le fait de savoir évaluer les opportunités business qui fait la différence entre un programmeur et un ingénieur logiciel. L’ingénierie tient compte des aspects business du développement d’applications, au-delà du fait de faire fonctionner le code. C’est pourquoi l’architecture est un composant clé du processus.
Étudiez les opportunités business
Air Business veut étendre ses services. Nous avons l’opportunité de répondre à la requête du tour opérateur qui souhaite réserver des vacances régulièrement. Comment allons-nous mettre à jour l’application pour répondre à ces besoins ?
Nous allons commencer par regarder la nouvelle fonctionnalité. Chaque nouvelle fonctionnalité sera traduite en une user story. Nous écrirons autant de stories que de fonctionnalités. Plus tard, nous revisiterons les stories en détail pour déterminer ce qui doit être architecturé et codé.
Voici notre première user story :
En tant qu’opérateur d’agence de voyage, je veux réserver un vol pouvant transporter jusqu’à 12 personnes pour qu’elles puissent découvrir un lieu unique.
Comme nous l’avons indiqué dans le chapitre précédent, le système n’assure pas cette fonctionnalité aujourd’hui. L’opérateur devrait donner les détails du voyage qu’il souhaite organiser à la personne au comptoir à l’aéroport.
Pourquoi ne peut-on pas simplement coder cela et en avoir fini ?
Nous pourrions nous lancer et essayer de glisser “de force” cette fonctionnalité dans l’architecture existante. Mais nous savons que c’est une mauvaise stratégie. La solution ? s'orienter vers une application web découplée pour permettre à l’entreprise de réaliser un retour sur investissement significatif. Et ce, pas uniquement pour cette nouvelle user story là, mais pour une prochaine nouvelle fonctionnalité. Étant donné que nous allons nous intéresser à la modification de l’architecture pour qu’elle puisse mieux gérer de plus grosses opérations pour la compagnie aérienne, regardons d’autres idées de fonctionnalités supplémentaires qu’a eues la compagnie.
Comment puis-je trouver une opportunité business ?
Demandez-vous : « Où l'entreprise peut-elle gagner ou économiser plus d’argent ? ». Regardons comment celle-ci peut être mieux servie grâce à un changement dans l’architecture. Nous pouvons commencer par poser quelques questions (j’ai fourni les réponses spécifiques à notre scénario) :
Quels sont les problèmes orientés utilisateur qui existent actuellement ?
Actuellement, seul un utilisateur unique à un seul emplacement peut utiliser l’application. La compagnie aérienne veut que l’application soit accessible depuis de nombreux emplacements, par de nombreuses personnes, le tout simultanément. La transformation en application web résoudra ces problèmes.
Quels sont les problèmes orientés données qui existent actuellement ?
La base de données stocke juste assez d’informations pour que l’application réserve des vols. Le mécanisme de requêtes est dirigé exclusivement vers cette fonctionnalité. Il y a très peu de capacités d’analyse. L'entreprise est donc incapable de proposer des offres aux voyageurs fréquents, ou de suivre les départs et arrivées en retard ou en avance. Par exemple, le système actuel affiche une liste de tous les clients d’Air Business, avec des informations qui les concernent, y compris les sommes qu’ils doivent actuellement. Nous voudrions voir une liste regroupant uniquement les clients qui doivent de l’argent.
Quid de ce qui n'est pas informatisé : ce qui est communiqué sur papier, à l'oral ?
Les pilotes soumettent actuellement les commentaires sur le vol et les demandes de maintenance par des formulaires imprimés. Avec une architecture découplée, ces données pourraient être saisies via une application mobile, pendant que le pilote fait sa tournée d’inspection avant ou après le vol.
Les mécaniciens apportent des modifications à l’appareil et, de façon similaire aux pilotes, saisissent ces changements par le biais de rapports papier. Il serait très utile qu’ils puissent signaler leurs changements en temps réel.
Quelles analyses peuvent être réalisées pour prévenir ces problèmes avant leur apparition ?
Les achats de pièces et les dates d’installation peuvent être saisis. Un système analytique intelligent peut déterminer quelles pièces approchent de leur date de remplacement, et lesquelles peuvent être commandées « juste à temps », avant qu'un dysfonctionnement arrive.
Comme vous pouvez le constater, il existe de nombreuses opportunités de tirer profit de la nouvelle architecture. Voici quelques solutions possibles :
Convertir le système existant en application web nous donnera beaucoup plus de flexibilité que l’application sur un seul ordinateur.
Les analyses peuvent être introduites pour proposer des offres spéciales, et suivre les arrivées et les départs en avance et en retard. La base de données actuelle n’a aucun moyen de stocker ou de demander ces informations.
Permettre aux pilotes de saisir des commentaires sur le vol et des demandes de maintenance (un processus qui se fait actuellement sur papier), possiblement via une application mobile, qu’ils pourront utiliser en effectuant l’inspection de l’avion avant ou après le vol.
Conserver des archives de maintenance plus avancées (un autre processus sur papier), qui pourront être utilisées pour acheter des pièces lorsqu’elles approchent de leur date de remplacement, plutôt qu’une fois qu’elles sont cassées, ce qui oblige à garder l’avion inactif pendant que l’on attend l’arrivée de la pièce.
Toutes ces opportunités n’ont pas besoin d’être mises en place immédiatement. Néanmoins, le fait de les connaître nous donne de meilleures justifications pour passer à l’architecture découplée.
Si cela représente autant de travail, pourquoi ne pas simplement recommencer à zéro ?
Nous pourrions jeter au feu l’application originale et recommencer à zéro. 🔥
Le problème, c'est qu'Air Business est toujours en activité…
Et puis, le code fonctionne tout de même : il fait ce qu’on attend de lui. Nous allons donc intégrer ces changements petit à petit. Cela permet à la compagnie aérienne de poursuivre ses opérations pendant que nous travaillons. De plus, nous pouvons récolter du feedback de la part des salariés de la compagnie aérienne sur la façon dont les fonctionnalités devraient marcher. Ainsi, ils n’auront pas besoin de se former sur un système totalement nouveau, d’un seul coup.
Définissons nos user stories
Jusqu’ici, nous avons créé une user story pour la première situation de notre liste :
Situation | User story |
Actuellement, seul un utilisateur unique à un seul emplacement peut utiliser l’application. Air Business veut que l’application soit accessible depuis de nombreux emplacements, par de nombreuses personnes, le tout simultanément. La conversion en application web résoudra ces problèmes. | En tant qu’opérateur d’agence de voyage, je veux réserver un vol pouvant transporter jusqu’à 12 personnes pour qu’elles puissent découvrir un lieu unique. |
Nous nous concentrerons sur deux user stories supplémentaires pour inclure les situations où des choses se font pour l'instant à l'écrit ou à l'oral, et qui donc, ne sont pas informatisées.
Essayez de les élaborer vous-même avant de regarder ma réponse ci-dessous :
Situation | User Story |
Les pilotes soumettent actuellement les commentaires sur le vol et les demandes de maintenance par des formulaires imprimés. Avec une architecture découplée, ces données pourraient être saisies dans une application mobile, pendant que le pilote fait sa tournée d’inspection avant ou après le vol. | En tant que pilote, je veux saisir tout problème de maintenance mineur dès l’atterrissage, pour qu’il puisse être réparé rapidement. |
Les mécaniciens apportent des modifications à l’appareil et saisissent ces changements par le biais de rapports papier. Il serait très utile qu’ils puissent signaler leurs changements en temps réel. | En tant que mécanicien en charge de la maintenance de l’avion, je veux mettre à jour tout problème dès qu’il a été traité, pour que l’avion puisse être considéré comme apte à voler. |
Ces deux questions, ainsi que la user story de l’opérateur, impliquent les questions que nous posions plus haut sur les processus orientés utilisateur, orientés données, et sur papier.
Il existe une autre user story que nous allons regarder pour illustrer la facilité d’implémentation APRÈS la mise en place de l’architecture (dans la section orientée données) :
Situation | User story |
Le système actuel affiche une liste de tous les clients d’Air Business, avec des informations qui les concernent, y compris le montant qu’ils doivent. Nous voudrions voir une liste montrant uniquement les clients qui doivent de l’argent. | En tant que responsable financier, je veux voir une liste de tous les clients qui nous doivent de l’argent, afin de pouvoir leur faire un rappel téléphonique. |
En résumé
Résistez à la tentation de coder une fonctionnalité dans une application monolithique et cherchez comment une architecture découplée pourrait plutôt être utilisée.
Posez vous les bonnes questions pour savoir quels problèmes pourraient être évités.
Ecrivez une user story pour chaque fonctionnalité de l'application.
Lorsque vous ajoutez une nouvelle fonctionnalité (user story), pensez aux opportunités business qu'elles représentent. C'est plus facile à justifier auprès du client quand vous lui expliquerez qu'il faut passer à une architecture découplée.
Maintenant que nous avons nos user stories, décomposons-les et définissons les nouvelles entités dont nous avons besoin dans notre application !
