Concevoir une architecture d'application, c'est penser plus loin que le temps T, envisager les impacts de ses choix au-delà de la seule problématique du coût.
Pour nous, c'est un état d'esprit qui nous fait privilégier, lorsque cela est possible, la démarche agile de la conception orientée service : la SOA.
SOA
La SOA ou l’urbanisation des systèmes agiles
La séparation entre couches de présentations (écrans), logiques applicatives et données, rendue possible par l’évolution des langages ou environnements de programmation, a marqué les prémices de la structuration et l’industrialisation des méthodes de programmation, facilitant la maintenabilité des systèmes.
La conception orientée service (SOA) en est la seconde étape. Elle correspond à une démarche plus structurée vis-à-vis de l’architecture globale, une volonté d’urbanisation des systèmes d’informations. S’il ne s’agit pas d’une révolution technologique puisque les concepts existaient, il faut bien admettre que les environnements / normes / outils que nous nommons, de manière élargie, serveurs d’application permettent de la réaliser plus facilement : c’est une avancée.
Penser à court...
Les projets d’expérimentation, à l’origine de la création d’applications dans l’entreprise, sont souvent pilotés par le court terme et ses corollaires, des contraintes de délai et de fonctionnalités. Si bien qu’il reste parfois peu de place pour les problématiques de montée en charge et de maintenabilité future inter-applicative.
Il s’en suit souvent une forte disparité dans les applications en place et une redondance des fonctionnalités. Une même fonction d’authentification peut ainsi être développée dans deux systèmes différents au lieu d’en faire un service commun.
Ou long terme ?
Au contraire, choisir une architecture et une approche orientées service va déterminer la manière dont les applications vont être conçues, et influer positivement tant sur la manière de concevoir les composants et les services, que sur leur interaction dans le cadre global du SI. Cela va aussi permettre des changements dans l’organisation de l’entreprise, en découplant la partie technique de la partie métier, donnant aux utilisateurs MOA plus d’autonomie, de réactivité, via le BPM et le BAM.
Impossible de « tout casser » et de recommencer à zéro ; impossible de ne pas préserver l’existant de nos clients ! C’est pourquoi, chez Axones, nous privilégions une approche incrémentale ; c’est pourquoi nous recherchons, lors de l’implémentation d’une nouvelle fonctionnalité, les solutions autorisant son découplage des autres processus métiers.
La SOA, un état d’esprit
Les consultants Axones ont cette ‘culture agile SOA’, mais dans tous les cas nous respectons votre arbitrage final entre rapidité de développement, faible coût et structuration, face à un investissement de structuration plus lourd ; car une démarche orientée service a toujours un impact en termes de temps, donc de coût d’implémentation