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.