Publié par

Il y a 5 années -

Temps de lecture 12 minutes

Vers des applications évolutives et pérennes

Depuis quelques années, nous sommes dans l’ère du tout connecté. L’information est accessible facilement et rapidement sur de multiples supports tels que les smartphones, tablettes, etc. Ce phénomène implique de changer nos habitudes de conceptions des applications sous-jacentes. En effet, nous devons être capables de les faire évoluer vite, continuellement et de manière transparente.

Le principal problème est que lorsqu’une application vieillit, la moindre évolution prend du temps et entraîne des coûts importants. Les deux principales raisons à cela sont :

  • Une dette technique importante.
  • Des choix technologiques et matériels remis en question.

Dans cet article, nous n’évoquerons pas la problématique de la dette technique. Celle-ci a déjà été abordée dans un livre blanc.

C’est le second point qui va nous intéresser. En effet certaines évolutions impliquent des changements de matériels, de frameworks, d’intégration avec d’autres langages, etc. Et pour ceux-ci, les choix sont nombreux et ils ne cessent d’évoluer de manière exponentielle au fil des années.

Une des difficultés consiste à choisir la bonne technologie et/ou le bon matériel pour répondre au besoin. L’enjeu est de taille car ces décisions peuvent entraîner des modifications profondes allant même jusqu’à une refonte globale d’une application.

L’idéal serait de pouvoir réaliser des applications s’adaptant facilement aux besoins et qui durent dans le temps. Mais en pratique, il est difficile d’élaborer des applications évolutives et pérennes. Il est cependant possible de pérenniser certaines briques d’applications dont le modèle métier.

Le constat

Des choix techniques souvent remis en question

Un pari permanent

Lorsque vient le choix d’une technologie, un ensemble de critères sont pris en compte. En voici une liste non exhaustive:

  • Adéquation aux besoins de l’application.
  • Courbe d’apprentissage par l’équipe en place ou présumée.
  • Rapidité de mise en œuvre et de développement.
  • Intégration avec les autres technologies déjà présentes dans le SI.
  • Importance de la communauté (taille, activité).

En règle générale pour valider tout ou partie de ces critères, des POC (Proof Of Concept) sont effectués. Ils vont notamment permettre d’étudier, sur une période courte, les technologies répondant au mieux aux besoins et de les sélectionner.

Mais cette étude ne porte que sur les besoins identifiés au moment où elle est réalisée. Nous sommes incapables d’anticiper les besoins futurs et donc de savoir si celle-ci les couvrira. Nous faisons alors un pari en espérant que les technologies restent en adéquation le plus longtemps possible.

Un cycle technologique raccourci

Avec le temps et l’apparition de nouveaux besoins ou de nouvelles contraintes, des limites liées aux technologies choisies finissent inévitablement par apparaitre. L’intégration de certaines fonctionnalités devient difficile. Nous contournons généralement ces problèmes en effectuant des développements spécifiques. Mais au bout d’un moment ils deviennent systématiques et engendrent de la dette technique.

Au travers de notre veille quotidienne, nous réalisons que de nouveaux outils peuvent nous aider à réduire, voire supprimer, les développements spécifiques. Et dans certains cas, nous voyons que les technologies que nous utilisons deviennent obsolètes : les maintenances et évolutions ne sont même plus effectuées. Certains de nos choix technologiques sont alors sérieusement remis en cause.

A travers ce scénario, un cycle se dessine : nous faisons des choix technologiques qui seront tôt ou tard remis en question. Ce phénomène est normal et inhérent à notre métier mais le problème est que ce cycle se raccourcit de plus en plus et que l’éventail des technologies possibles est de plus en plus large.

Une évolution rapide et permanente

Du matériel

Depuis les débuts de l’informatique, la capacité mémoire des machines (processeurs, RAM) n’a cessé d’augmenter permettant d’avoir des processeurs multi-cœurs, peu coûteux et capables d’effectuer des traitements parallèles volumineux. Mais ce type d’architecture matérielle n’évolue plus trop. En effet nous atteignons des limites physiques, remettant en cause la Loi de Moore.

De ce fait, une grande partie des technologies évolue de manière à tirer le maximum de profit de ces architectures. De cela se sont développées, entre autres, les technologies NIO ou bien encore plus récemment le retour en force des langages à paradigme fonctionnel (Scala notamment). Ces derniers favorisent l’immutabilité, représentant un grand atout pour limiter les effets de bords dans l’univers du parallélisme.

Il est ainsi possible de mettre en place facilement et à faible coût des applications scalables. Mais ces changements nécessitent de modéliser nos applications différemment, entraînant des modifications plus ou moins impactantes sur l’existant.

Des technologies

Nous venons de voir que le matériel a induit l’évolution des technologies. En parallèle, ces dernières se multiplient de manière exponentielle ces dernières années. Parmi celles-ci, nous retrouvons :

  • Langages de programmations sur la JVM : Clojure, Scala, Groovy, etc.
  • Serveur NIO : Netty, etc.
  • Bases de données NoSql: Cassandra, MongoDB, etc.
  • Big Data : Hadoop, etc.
  • Plateformes, infrastructures Cloud : Amazon EC2, Heroku, etc.
  • Librairies / frameworks web : Flex, GWT, angular, backbone, HTML 5, Play, etc.
  • Réseau : généralisation de la fibre optique, réseaux mobiles (3G/4G).

Et cette énumération est loin d’être exhaustive. Nous retrouvons des technologies adressant de nouveaux besoins (Big Data, NoSql, Cloud) et d’autres proposant différentes approches de conceptions (Scala, Heroku).

Il devient alors difficile de faire ses choix dans cet univers technologique, d’autant plus que de nouveaux outils nous sont proposés de plus en plus rapidement. Il ne serait pas étonnant qu’entre la rédaction de cet article et le moment de sa publication, de nouvelles plates-formes ou librairies soient disponibles.

A travers notre étude, nous constatons que les modules de l’application seront tôt ou tard confrontés à ces problématiques, et les rendre pérennes reste difficile.

Néanmoins, parmi ces modules nous pouvons pérenniser l’un d’entre eux : le modèle métier.

Vers une application évolutive et pérenne

Un socle solide : le modèle métier

Définition

Voici la définition du modèle métier sur Wikipédia :

« Un modèle de métier ou business pattern en anglais est une description générique des règles de travail utilisée en informatique pour réaliser des solutions propres à un métier. »

En d’autres termes ce modèle regroupe les entités, leurs interactions et les services permettant de les adresser. C’est le cœur de l’application.

Modélisation

La première difficulté de modélisation consiste à n’avoir que les règles métiers dans le modèle. En effet dans beaucoup d’applications, il contient des informations de persistance, d’exposition en Web Service, d’interactions avec d’autres applications, etc. En extrapolant le Single Responsibility Principle au modèle, nous constatons que ce dernier est pollué par d’autres notions et viole donc ce principe.

La seconde difficulté consiste à ne pas éparpiller les règles métiers dans toute l’application. Par exemple, nous en retrouvons certaines dans la couche de persistance, d’autres dans l’interface utilisateur, etc. Cela rend les maintenances et évolutions difficiles traduisant une dette technique importante.

L’idéal serait une modélisation alliant centralisation des règles métiers et décorrélation des technologies et infrastructures.

Ce type de modélisation est possible grâce à la combinaison d’architectures centrées sur le modèle et de techniques de conceptions adaptées.

Parmi les architectures, nous trouvons le Ports and Adapters définit en 2005 par Alistair Cockburn dont voici le principe :

L’architecture consiste à centraliser le modèle métier au cœur de l’application. Il interagit avec des « ports » (bases de données, appel Web Services, etc) par le biais « d’adapters » qui sont des interfaces.

Cette architecture possède les avantages suivants :

  • Le modèle et les règles métier sont indépendants des librairies,
  • Les règles métiers sont testables plus facilement,
  • Le modèle et les règles métier sont indépendants de l’interface utilisateur,
  • Le modèle et les règles métier sont indépendants de la persistance du modèle,
  • Le modèle et les règles métier sont indépendants des systèmes tiers.

Les évolutions apportées à notre modèle sont mieux ciblées, et les changements technologiques n’ont pas ou induisent peu d’impacts sur ce dernier.

Dans le même registre, l’Onion Architecture de Jeffrey Palermo présente les avantages identiques à l’architecture Ports and Adapters.

Cependant ces architectures ne nous fournissent pas de technique de modélisation. Un second outil est nécessaire. L’un des plus efficaces est le Domain Driven Design (DDD). Défini par Eric Evans, il permet d’appréhender la modélisation du métier avec, entre autres, des composantes telles que l’Ubiquitious Language, le Bounded Context, les Entities et Value Object. Ces dernières permettent de :

  • Définir les échanges et relations entre les objets du métier
  • Délimiter le modèle et de le découper en sous-modèles

Un autre outil de modélisation peut aussi être utilisé : Command Query Responsibility Seggregation (CQRS). Le but de cette approche est de séparer notre modèle en deux parties :

  • La lecture permettant la restitution d’informations.
  • L’écriture pour la partie persistance.

L’utilisation des ces deux outils séparément ou en combinaison présente les avantages suivants :

  • Définition d’un vocabulaire commun : l’Ubiquitious Language dans l’univers DDD.
  • Règles fonctionnelles isolées facilitant les tests, les maintenances et les évolutions.
  • Exposition du modèle sous forme de services par le biais de façades.

Bien entendu l’utilisation du DDD et du CQRS n’est pas obligatoire. Il est tout à fait possible de mettre en place un modèle métier sans avoir recours à ces derniers. Tout dépend de la taille et des besoins du métier. En général lorsqu’il est complexe, ces outils permettent de mieux structurer les règles.

Malgré tout, rendre pérenne un modèle métier doit aussi s’accompagner de bonnes pratiques.

Faire vivre son modèle

Afin de mettre en place un modèle reflétant au mieux le métier, il est nécessaire de se l’approprier. En pratique, nous constatons que peu de temps est accordé à l’apprentissage et au partage de connaissances.

Or la mise en place et l’évolution d’un modèle métier nécessitent de bonnes connaissances. Il est donc indispensable d’avoir une implication et une collaboration étroite entre les développeurs et les personnes du métier. Cela permet de mieux appréhender les concepts pour les modéliser et de fournir les services adéquats.

Et tout comme un jardin, si nous n’entretenons pas notre modèle régulièrement, les interventions seront de plus en plus difficiles et délicates, preuves d’une dette technique croissante. Il est donc nécessaire d’être rigoureux et d’effectuer des entretiens réguliers. Cela implique de reconsidérer certaines parties du modèle et de « refactorer » afin de toujours être plus réactif face aux évolutions du métier.

Conclusion

Les applications doivent évoluer de plus en plus vite. Cela s’avère d’autant plus vrai aujourd’hui car elles doivent s’adapter à de multiples supports (Web, mobiles, etc).

Afin de permettre des intégrations rapides et à moindre coût, rendre les applications adaptatives et durables est primordial mais difficile en pratique car :

  • Certains besoins impliquent l’utilisation de nouvelles technologies et matériels entraînant des modifications plus ou moins profondes,
  • Beaucoup de technologies sont périssables : impossible de savoir si celle choisie va être maintenue dans le temps. Si ce n’est pas le cas, il faudra peut être en intégrer une autre,
  • Intégrer des évolutions dans des applications existantes peut être difficile et coûteux si la dette technique est importante.

De ce fait rendre une application évolutive et pérenne est ardue et reste assez marginal. Il est néanmoins possible de pérenniser certaines parties dont la principale est le modèle métier. Ce dernier est la brique la plus importante : il est le reflet du fonctionnel. Toutes les règles de gestion sont présentes : c’est le cœur et l’intelligence de l’application.

Rendre un modèle métier durable est possible et s’accompagne de bonnes pratiques :

  • Isoler le fonctionnel de la technique : ne pas éparpiller les règles de gestion à tous les niveaux de l’application,
  • Utiliser des outils de conception tels que le Domain Driven Design et CQRS,
  • Faire vivre le modèle : refactorer, refactorer, refactorer et toujours coller au fonctionnel,
  • Maîtriser la dette technique.

L’expérience montre que le modèle métier survivra plus longtemps que les technologies sur lesquelles il est implémenté. De plus, des besoins se présentent en permanence et avoir un modèle métier reflétant le fonctionnel permet d’intégrer les évolutions plus aisément.

Investir dans le modèle métier tant sur le plan fonctionnel que celui de la modélisation technique doit prendre une part importante dans la mise en place d’applications, permettant de mieux le maîtriser et surtout de le pérenniser.

Malgré tout, l’évolution permanente de l’informatique est et restera encore pendant de nombreuses années un perpétuel débat. Mettre en place des applications s’accompagne de choix fonctionnels et techniques qui ne sont pas triviaux, mais font que l’informatique est un métier passionnant.

Publié par

Publié par Nicolas Jozwiak

Nicolas est delivery manager disposant de 12 ans d’expérience en conception et développement. Son parcours chez un éditeur avant son entrée chez Xebia lui a notamment permis de développer de solides compétences dans le domaine de la qualité et de l’industrialisation (tests, intégration continue, gestion de configuration, contrôle qualité). Bénéficiant d’une expérience très solide de mise en place des méthodes agiles et d’accompagnement d’équipes sur le terrain, il s’attache à mettre à profit quotidiennement son expérience qui est reconnue pour son approche pragmatique, proactive et pédagogique.

Commentaire

4 réponses pour " Vers des applications évolutives et pérennes "

  1. Publié par , Il y a 5 années

    Super article qui néglige néanmoins à mon sens un problème de taille : la maintenance des adapters.

    Par exemple, si j’ai un adapter JPA et que je veux le modifier pour XXX. Ayant 400 adapters actuellement cela reste difficile.

    Autre exemple, si j’ai un adapter MVC réalisé avec Spring MVC et que je veux le modifier pour XXX. Migrer 10000 méthodes vers une autre technologie est très lourd (et migrer la moitié c’est bien sûr pas terrible terrible).

    Dernière exemple, le GUI : je veux passer de XXX à HTML5. Ayant 50 écrans avec plein d’interactions est très difficile (pour ne pas dire impossible)

    Par conséquent, une bonne pratique de modélisation à ajouter serait à mon avis : rester petit.

    En ayant PLUSIEURS modèles métier, chacun ayant ses adapters et son GUI (ce qui est encouragé par DDD avec un modèle par use case ou groupe de use cases mais qu’on peut faire aussi « naturellement »).
    Quand je veux migrer, je peux le faire modèle par modèle, petit à petit.

    En faisant ca, on peut également adapter les technologies aux mieux (par exemple, websocket pour un modèle, REST pour un autre, SOAP pour un autre, NoSQL par ci et fichiers par là, etc…)

    Néanmoins, les possibilités restent limitées : si je veux changer de langage, changer de base de données alors que l’actuelle fait 1To, etc…, ca RESTE COMPLIQUE si l’application est suffisamment veille, grosse, utilisée par beaucoup de personnes, …

    Encore merci pour l’article

  2. Publié par , Il y a 5 années

    Il ne s’agit ni plus ni moins que de séparer la description de « la logique métier » de la technologie de l’automate permettant de l’exploiter. Pour que cette approche fonctionne, il faut qu’il y ai un formalisme standard et universel de description de « la logique métier ». Ce formalisme doit être partagé par tout un monde de monde: les métiers qui l’expriment, les fabricants de technologies d’automates (éditeurs de produit et framework payant ou open) et les intégrateurs qui le construisent.

    …. vaste programme.

    Pour l’instant, seuls deux standards se sont à peu près imposés, et seulement dans le monde des fabricants et intégrateurs, et de surcroit ne concernent que le volet données de « la logique métier », il s’agit du XSD et du modèle de classes UML. Le premier n’a pas du tout percé coté acteurs métier qui le considèrent comme une ressource « technique » (… jargon évitant de dire « trop formel pour moi et pas envie de formaliser »). Quand au second, ça dépend du contexte, dès foi on a affaire à des métiers qui comprennent les diagrammes de classes UML et d’autres pas.

    Concernant le volet traitement de « la logique métier », il n’y a pas vraiment de formalisme partagé universellement, à part WSDL (partie portType) que les acteurs métiers considèrent comme « technique » et le BPMN qui reste encore difficile de leur faire accepter.

  3. Publié par , Il y a 5 années

    @cris,
    Effectivement cette approche, bien qu’elle soit utopique et naïve à l’échelle d’un gros SI, peut s’avérer pertinente dans un contexte « petit » (un processus métier cloisonné) à condition que la politique des DSI soit capable de l’imposer au métier ou d’imposer au métier un formalisme traduisible dans le langage de l’approche.

  4. Publié par , Il y a 5 années

    @Chris
    Je suis tout à fait d’accord sur le fait que cette approche est plus adaptée sur des SI de taille petite ou moyenne.
    C’est d’ailleurs une approche plus que recommandée (avec ou sans DDD) : faire un ensemble de petits / moyens SI plutôt qu’un énorme. Cela le rendrait difficilement maintenable, pouvant potentiellement affecter d’autres SI connexes…

    Reste que sur de gros SI, mettre en oeuvre cette approche est faisable mais requiert de la discipline, une bonne organisation et du temps.

    Nicolas (Xebia)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.