AILES : Architecture, AT - AF, exemple d'un contexte d'architecture

De l'AF vers l'AT...
Si l'on considère un processus métier (ici, par exemple, l'obtention d'un crédit, point de vue de la banque), on se rend vite compte que :
- des données internes ou externes à la banques sont concernées ;
- plusieurs processus (calculs de ratios, détection d'encours trop important, etc...) sont à mettre en oeuvre ;
A l'issue de votre architecture fonctionnelle, vous aurez, au minimum :
- dressé un glossaire complet des données métier à manipuler
- détaillée les différentes sources de données
- inventorié tous les processus métiers
- identifié le contexte à conserver par requête et par session...
Par exemple, vous pouvez avoir opté pour une approche à base de composant, comme celle illustré de façon "générique" ci dessous :

architecture "technico-fonctionnelle" à base de composant
(mixte de l'architecture en couche et celle à base de composant)
Pour bien comprendre en quoi ce n'est pas une "architecture fonctionnelle", se reporter à l'article du même nom : Architecture Fonctionnelle

Et là, mon consultant de 30 ans arrive, rigole un coup, vous met sous le nez le schéma suivant :

procédé métier : obtention d'un crédit

    Ce schéma n'est pas là pour détailler tous les mécanismes mis en oeuvre pour l'obtention d'un crédit (je suis loin d'être un expert dans la finance et le schéma est certainement très simplifié).
    En revanche, il permet d'illustrer le douloureux passage de l'AF (archi fonctionnelle) à l'AT (archi technique), via les problèmes potentiels que pose un tel processus.
    En particulier, il y a fort à parier que l'informatique et les données de la DGI (Direction Générale des Impôts) ne soient pas compatibles avec celle de votre banque. L'obtention d'un crédit, du point de vue de la banque, c'est accéder à de nombreuses sources d'informations hétérogènes, mettre en jeu de nombreux process.
    Ce consultant de 30 ans (toujours lui!) vous demandera alors si vous avez :
- identifié les solutions concrètes d'accès aux données des systèmes extérieurs ;
- réglé les problèmes de traduction de formats de ces mêmes données ;
- repéré les goulots d'étranglement d'accès à ces données ;
- mesuré les performances de chaque traitement...

De l'AT vers l'AF
    Pour mieux illustrer les problèmes que met en lumière une architecture technique (et qu'il faudra prendre en compte et/ou intégrer dans l'architecture fonctionnelle), on peut prendre l'exemple d'une autre application bancaire : la consultation de ses actions.
    Techniquement, vis-à-vis d'un système aussi transverse, on parlera en architecture à niveau.
En particulier, on distinguera tout ce qui est "front" (en liaison direct avec le/les clients), du "back" (interne à la banque).

architecture technique d'un système de consultation de titres

    Cette architecture technique (même si elle est encore bien incomplète) permet de visualiser deux Sphères architecturales bien précises : le "front" et le "back".
    Elle doit aussi faire le point sur les systèmes existants au sein de la banque et qui permette de remplir le service. Ici, au niveau front, il y en a deux : un système de web broker (système dédié interne à la banque) et un système d'accès aux données distribuées (serveur de page + serveur d'application).
    Il conviendra alors de faire une synthèses des caractéristiques fonctionnelles de ces systèmes existants.
Ici, par exemple, on détaillera :
- le mode d'accès (unique ou multiple) ;
- la gestion des risques (délocalisée ou centralisée) ;
- la mise à jour du portefeuille du client (temps réel ou différé) ;
- délai de réponse d'exécution des ordres boursiers ;
- etc...
En fonction de l'architecture technique, donc en fonction de :
- la "cartographie" des systèmes existants (ici présentée sous forme de niveau, avec "front" et "back") ;
- la liste des mode d'accès à ce service ;
- la visualisation "technique" des flux existants de données (avec format, temps de réponse, ...) ;
on pourra plus facilement développer une architecture fonctionnelle adaptée.
    Par exemple, dans le cas d'une architecture à base de composant, on pourra se poser les bonnes questions lorsqu'il s'agira de définir le composant :
* gestion de compte.
Faut-il prévoir un composant de gestion de compte par client ?
ou plutôt, toujours par client, 2 composants liés (un pour les opérations bancaires - virements, etc. - et un dédié aux opérations titre ?
* accès aux bourses étrangères.
Est-ce seulement possible, envisageable techniquement au vue de l'infrastructure actuelle ? Quelles évolutions sont à mettre en oeuvre techniquement pour que le composant fonctionnel correspondant ait un sens ?
* interface client
Considérant l'architecture technique, n'est-il pas judicieux de définir un composant fonctionnel d'interface (entre les clients - web, minitel, agence, ... - et la banque) ?

Conclusion
    Cet article ne prétend pas montrer tout ce que recouvre l'architecture technique et fonctionnelle. Ces 2 points de vue majeurs ont par ailleurs été détaillés dans l'article "Architectures, les points de vue".
    En revanche, il illustre la nécessaire collaboration qui doit exister entre AF et AT.