Êtes-vous concerné par l’Architecture Applicative?
Si vous êtes développeur vous aimeriez comprendre comment les éléments applicatifs interagissent entre eux; comment doit fonctionner un traitement applicatif particulier, avec quels résultats attendus; de quelle manière un utilisateur doit utiliser un écran de saisie ou de consultation.
Si vous êtes spécialiste infrastructure, vous avez besoin de connaître la nature et la volumétrie des données stockées et échangées; la fréquence et la charge requise par chaque traitement applicatif; l’agencement des différentes solutions applicatives entre elles au sein du système d’information (SI).
Si vous êtes spécialiste en sécurité, vous souhaitez connaître où se trouvent les données sensibles, par qui sont-elles consultées et modifiées; quelles sont les interactions avec le monde extérieur.
Si vous êtes décideur ou architecte ou gestionnaire/chargé de projet, vous voulez avoir une vue d’ensemble du fonctionnement du SI.
Mais voilà, parfois la notion d’architecture n’est pas mise en œuvre et les éléments de documentation pour décrire l’existant et la cible n’existent pas. Certains documents décrivent parfois une partie précise du SI orientée pour les besoins d’un certain groupe de lecteurs.
Pourtant la solution existe, elle consiste à suivre les grands principes de l’Architecture IT en décrivant l’Architecture Applicative de tout ou partie du système d’information.
Vue d’ensemble de l’Architecture IT
Pour bien comprendre ce qu’est l’Architecture Applicative, il faut commencer par les différentes manières de représenter l’Architecture IT.
Il faut bien comprendre que selon la portée de l’architecture, la taille et l’organisation du SI, ainsi que la culture et les méthodes de l’entreprise, le découpage de même que les noms des étapes peuvent varier.
Tout part d’un besoin au sein d’un processus métier.
L’objectif est alors de représenter les fonctions et utilisateurs impliqués au travers de cas d’usages, c’est l’Architecture Métier ou Architecture d’Affaires.
Si les changements concernent l’organisation des applications (blocs fonctionnels, flux intra et inter-applicatifs, interface utilisateur), on parle alors de l’Architecture Applicative.
Pour documenter le détail des besoins, les fonctions impactées sont spécifiées: on parle d’Architecture Fonctionnelle.
Tout ce qui a trait aux données utilisées (nomenclature, normes, méthodes, outils) est documenté dans l’Architecture de Données.
Enfin, la conception des modifications à apporter aux composants logiciels en utilisant des modèles logiques (module, composant, classes) est nommée l’Architecture Applicative Logique ou Architecture Logicielle.
Et pour finir, l’implémentation avec les technologies sélectionnées (SGBD, serveurs, middleware…) va se faire en utilisant l’Architecture Technique.
Définition de l’Architecture Applicative
Comme nous l’avons vu précédemment, l’Architecture Applicative n’est pas une notion figée et invariable appliquée uniformément par tous.
Non, il s’agit de principes directeurs appliqués au sein d’une méthode ou d’un cadre d’architecture (architecture framework) souvent défini dans l’Architecture d’Entreprise.
Les grandes idées de l’Architecture Applicative sont de décrire à haut niveau une hiérarchie d’applications, de blocs ou composants, de fonctionnalités, d’entités. Chaque élément peut interagir avec d’autres au sein ou en dehors de son contenant.
Il faut bien voir que le principe d’Architecture Applicative peut s’appliquer à des cas de figure très variés. C’est pourquoi le principe est souple et que plusieurs cadres existent.
En effet, les projets suivants ont tous besoin d’une Architecture Applicative, pourtant ils sont très différents les uns des autres:
- mise en oeuvre d’un progiciel sur site sur étagère, à configurer
- mise en oeuvre d’un progiciel sur site associé à du développement sur mesure
- mise en oeuvre d’une solution SaaS à intégrer aux autres briques applicatives
- sous-traitance d’un processus applicatif complet à un prestataire
- développement d’une application sur grand système (mainframe)
- développement d’une application web 3-tiers
- développement d’une application à base de micro-services
- développement d’une application orientée service
- développement d’une application répartie basée sur des événements d’affaires circulant sur un bus applicatif
- développement d’une application entièrement dans le Cloud en connectant des services en ligne
- développement d’une application pour mobile
- développement d’une application pour ordinateur personnel
- développement d’une application pour objet connecté
- développement d’une application pour machine industrielle
- développement d’une application pour calculateur scientifique
Les déclinaisons de l’Architecture Applicative
L’Architecture Applicative peut aussi regrouper un ensemble de sous-domaines architecturaux qui peuvent parfois éclipser le nom même d’Architecture Applicative:
- Architecture Logicielle
- Architecture d’Intégration
- Architecture de Données
- Architecture Fonctionnelle
L’Architecture Logicielle va plus être orientée développement et cela se retrouve par les termes utilisés. On va ici parler de composants, de modules, de librairies, de framework, de modèle de données, d’expérience utilisateur, de l’interface utilisateur, de langages…
L’Architecture d’Intégration est en charge de décrire comment les applications vont s’intégrer les unes avec les autres:
- la nature, la description et le format des données échangées
- la nature et le format des flux de communication synchrones et asynchrones
- la description des éléments propre à l’intégration
L’Architecture de Données veille à conserver une cohérence et une traçabilité des données du SI. Elle décrit les modèles logiques de données, les modèles de description de données et les modèles physiques de données. Elle participe aussi en établissant des règles sur le choix des outils de stockage et d’échange de données, les bonnes pratiques, l’anonymisation et l’optimisation du traitement des données.
L’Architecture Fonctionnelle est souvent la partie la plus mise en œuvre car elle décrit les besoins métier ou d’affaires en spécifications fonctionnelles utilisables par les concepteurs ou développeurs.
De manière générale, l’Architecture Applicative apporte les éléments suivants:
- une vue globale des éléments applicatifs
- une description précise du comportement attendu de chaque élément
- une description des interactions possibles entre les éléments
- une description des données utilisées et échangées par les éléments
- une feuille de route des grandes étapes de mise en oeuvre
- un guide de description et d’implémentation
- des modèles réutilisables de solutions (voir Architecture de Solution/LIEN)
Les facettes de l’Architecture Applicative
Une application peut s’opérer de manière plus ou moins visible vis à vis des utilisateurs internes ou clients.
La partie en visibilité des utilisateurs (internes ou clients) se nomme le frontend. Un des aspects essentiels à surveiller est ici l’expérience utilisateur, c’est à dire le ressenti à l’usage.
Même si de nos jours, il est essentiellement question d’application web ou mobile, il ne faut pas oublier tout le pan des applications des postes de travail et l’existant grand système.
Ainsi, la description du frontend comprend l’interface utilisateur, les interactions entre les éléments de l’interface et l’utilisation des services applicatifs du backend.
La partie en arrière-plan qui va traiter les données en exécutant des traitements sans interactions avec les utilisateurs principaux s’appelle le backend. Ici, la sécurité, la résilience, la performance, la scalabilité (faculté de monter facilement en charge) sont les maîtres-mots.
La documentation du backend concerne donc principalement les schémas de données, les échanges de données, l’intégration entre applications, les traitements batchs et les services applicatifs.
Les méthodes de l’Architecture Applicative
Comme nous l’avons vu, l’Architecture Applicative regroupe une grande variété de contextes et cas d’utilisation totalement différents.
Cela concerne des applications nouvelles, web ou mobile, aussi bien que applications existant depuis plusieurs décennies, époque où l’internet le PC n’existaient pas.
Ensuite, selon la culture et l’activité des entreprises, les besoins en termes de sécurité, d’agilité, de conformité… sont très différents.
Entre une institution financière internationale et une startup dans les jeux gratuits sur mobile, les différences de besoins d’Architecture Applicative sont énormes.
Et même au sein d’une Architecture d’Entreprise, la nature d’une application particulière peut amener à utiliser une méthode différente.
En termes de méthodes, plusieurs grands courants architecturaux sont disponibles depuis longtemps tels que:
- l’approche Donnes/Traitements (framework Zachman, Merise), démarche top-down en séquence, lourde et verbeuse
- l’approche Composant plus adaptée aux systèmes distribués et orientés objets (framework Zachman), méthode assez rigide et manquant parfois de pragmatisme
- l’approche orienté service (SOA) met en oeuvre des services permettant d’avoir un faible couplage avec l’extérieur de l’application
- l’approche des processus métier est basée sur une méthodologie de modélisation et un formalisme de description (UML). UML s’est en effet imposé en tant que standard de formalisation de la modélisation. Toutefois il n’y a pas de norme unique pour la modélisation. Chaque fournisseur peut avoir sa propre méthode utilisant UML. Les outils utilisés sont le BPM (Business Process Modeling) ou le BPR (Business Process Re-engineering) tels que Mega, Erwin/Casewise.
Les livrables de l’Architecture Applicative
La liste des livrables fournis par l’Architecture Applicative varie en fonction de l’organisation, des normes et méthodes de l’architecture dans son ensemble.
Toutefois, voici les principaux livrables possibles:
- environnement de conception et développement
- la liste des briques techniques requises pour la conception et l’implémentation tels que les librairies, progiciels, solutions SaaS, design patterns (motifs de conception) à utiliser…
- les outils de modélisation et de conception
- les outils de développement (IDE)
- les standards et méthodes de développement à utiliser
- la description fonctionnelle
- les diagrammes des structures de données, des traitements, des enchaînements, des interfaces
- les maquettes de l’interface utilisateur
- les spécifications fonctionnelles (requis, attendus, contraintes)
- les spécifications de l’intégration
- les spécifications de conception logicielle
Le rôle de l’Architecte Applicatif
L’Architecte Applicatif a souvent un rôle central car il est un des seuls à avoir une vision globale du fonctionnement applicatif avec les aspects fonctionnels, techniques et architecturaux.
En outre, il procède par étapes en élaborant d’abord une ébauche de la vue d’ensemble puis en affinant successivement les composants à implémenter. L’Architecte Applicatif a alors pour principaux rôles:
- de recenser les besoins fonctionnels, les contraintes et règles métier ou d’affaires
- d’élaborer et communiquer les principes directeurs de l’architecture applicative
- de définir les besoins techniques
- de participer aux choix technologiques
- de créer l’Architecture Applicative
- de participer ou de créer la conception logicielle
- de supporter les concepteurs et développeurs
- de participer aux phases de tests, d’intégration, d’acceptation et de performance
L’Architecture Applicative au service de l’urbanisation du SI
L’urbanisation du système d’information (SI) décrit les constituants du SI et les interactions entre ces éléments, sans entrer dans le détail de la conception et de l’implémentation.
Son but est de s’assurer d’une cohérence globale au niveau du SI.
Ainsi, l’Architecture Applicative participe à maintenir l’évolutivité et l’uniformité du SI en respectant les règles et contraintes édictées et en veillant à décliner ces pratiques dans toute la granularité qu’elle va définir.
L’objectif de l’Architecture Applicative est donc de servir à la fois les concepteurs et développeurs. Ceci afin d’implémenter la solution mais aussi afin de veiller à la cohérence globale, à la sécurité, à la résilience et à l’évolutivité du système d’information.
Merci pour votre lecture, n’hésitez pas à partager cet article.
Je peux être amené à citer des marques (produits, solutions, entreprises) par choix rédactionnel. Mais sans indication explicite de ma part, cela ne préjuge en rien d’un quelconque partenariat ou placement de produit.
N’hésitez pas à faire part de vos connaissances et expériences pour compléter cette fiche. Utilisez les commentaires mais toujours avec bienveillance et courtoisie 😃. Au plaisir de vous lire.
Sommaire du dossier Architecture, état des lieux et enjeux:
- Architecture IT : quelle définition et quels métiers ?
- Architecture d’Entreprise ou la gouvernance de la conception du SI
- Architecture Métier ou d’Affaires, la bonne compréhension des besoins au cœur de la réussite du SI(à venir)
- Architecture de Solution conception d’une architecture autour d’une problématique précise
- Architecture Applicative, Fonctionnelle ou Logicielle pour décrire les fonctionnalités des applications
- Architecture de Données ou la gouvernance de l’information d’entreprise
- Architecture Technologique ou Architecture Technique vs Expertise Technique
