0036 3 11.6architecture Centralisée

C2 – Usage restreint Sopra Banking Amplitude
Architecture centralisée
Guide utilisateur
Sopra Banking Software
Sopra Banking Amplitude
1/24
Sommaire
1. Terminologie 4
2. Architecture Amplitude 5
3. Centralisation Amplitude 7
3.1. Principes de base 7
3.1.1. Principe 1 stratégie de migration progressive 8
3.1.2. Principe 2 : accompagnement au changement 8
3.2. Pourquoi des étapes intermédiaires ? 9
3.3. Quels sont les gains attendus ? 9
3.4. Quelles sont les contraintes ? 9
3.5. Quel est le coût d’un projet de centralisation ? 11
4. Stratégie de centralisation progressive 12

4.1. Phase 0 : Existant 12
4.2. Phase 1 : Construction d’un GSR 12
4.3. Phase 1bis : Ouverture des nouvelles agences 13
4.4. Phase 2 : Basculement des premières agences 13
4.5. Phase 3 : Basculement des dernières agences 14
4.6. Phase 4 : Suppression du SC 14
4.7. Analyse 14
5. L’approche organisationnelle du projet 15

5.1. Principes 15
5.2. Les étapes 16
6. Approche technique de la migration progressive 17

6.1. Phase 1 : Initialisation 17
6.2. Phase 2 : Transitoire 17
6.3. Phase 3 : Finalisation 17
6.4. Mixité des sources de données en phase 2 18
6.5. Cas de la renumérotation des comptes 18
6.6. Aspects batchs 18
6.7. Autre approche 19
7. Architecture applicative 20
7.1. Type d’architecture technique 20
7.2. Schéma d’architecture des flux 20
8. Architecture matérielle 21
8.1. Vers une solution en cluster ? 21
2/24
8.2. Préconisations hardware 22

8.3. Solution de backup 23
8.4. Backup dormant ou backup actif ? 24
3/24
1. Terminologie
Dans toute la suite du document, les termes suivants seront utilisés :
 AGE = Base mono Agence.
 AR = Agence Rattachée.
 BMA = Base toutes (multi) agences : architecture centralisée.
 STA = Site Toutes Agences (synonyme de BMA).
 SC = Site Central classique, il s’agit du site pivot des transferts inter sites.
 SR = Site de Regroupement.
 GSR = Gros Site de Regroupement : terminologie utilisée dans le cadre d’une migration progressive.
 AM = Agence mère ou régionale.
 FV = Fonctions Vitales agence.
 TFJ = Traitement de Fin de Journée.
 SDA = Solution Dégradée Agence.
4/24
2. Architecture Amplitude
Type Répartition des bases Commentaire
1 niveau
Architecture
SC
centralisée Production 1 base de données
 toutes les entités comptables gérées
1 niveau
2 bases de données
Architecture  toutes les entités comptables gérées sur les 2
SC SC
centralisée Trt Production bases.
Un serveur de production (transactionnel) et un

serveur annexe de traitement de masse
2 niveaux
SC
Architecture 1 Site central

décentralisée
n bases
Agence Agence Agence
A B C  mono agence
Architecture
2 niveaux
décentralisée SC
1 Site central
Semi n bases
Agence Groupe
A 1
 mono agence ou multi agences
centralisée
SC 3 niveaux
Architecture
décentralisée 1 Site central
n bases régionales
Groupe Groupe Groupe
1 2 3  mono agence ou multi agences
Centra
p bases Agences
régionale  mono agence
Ag Ag Ag
A B C
5/24
 Architecture centralisée mono-base
Nécessite une puissante machine capable d’assumer la charge transactionnelle et batch. La disponibilité
de l’infrastructure technique centrale doit être importante. La mise en place d’une solution dégradée
agence (SDA) est un renfort à ce type d’architecture.
Les créneaux horaires permettant d’assurer les traitements de masse sont limités, c'est pourquoi ces
derniers doivent être réalisés de manière concurrentielle.
 Architecture centralisée bi-bases
La charge transactionnelle est assurée totalement par le site toutes agences. Le site central quant à lui
n’est utilisé que pour déporter les traitements de masse.
 Architecture décentralisée : ensemble de mono-agences
Les charges transactionnelles et batch sont assurées par les agences.
Les opérations inter agences se dénouent au moins à J+1.
Elle convient parfaitement aux structures avec un réseau de qualité incertaine et ne nécessite pas une
disponibilité réseau 24h/24.
 Architecture décentralisée : mixte
Centralisation partielle des BO au sein d’une même ville.
Elle nécessite de fait des connections réseaux performantes au sein de la ville.
 Architecture décentralisée : 3 niveaux
Centralisation régionale des BO. Forme d’architecture hybride permettant de combiner une répartition
de charge et une infrastructure réseau hétérogène. La synchronisation inter sites devient la clef de voûte
de cette architecture.
6/24
3. Centralisation Amplitude
Ce chapitre explique comment passer d’une architecture décentralisée (2 ou 3 niveaux) vers une
architecture centralisée.
Quels sont les gains attendus ?
 Un SI unique.
Quelles sont les contraintes ?
 Criticité.
 Disponibilité.
Quel est le coût d’une centralisation ?
 Aspect matériel.
 Aspect réseau.
 Aspect accompagnement au changement.
 Des utilisateurs finaux.
 Des équipes de production & système.
3.1. Principes de base
Puisqu'il s'agit de passer de Amplitude à Amplitude, d’une application vivante et opérationnelle à la

même application en vendant aux utilisateurs des gains substantiels, il ne faut pas les décevoir, ne pas
les perturber : il faut faire de cette migration une migration fluide.
7/24
3.1.1. Principe 1 stratégie de migration progressive
A
Site central
B
Agence A Agence B Agence C
Site central Site de regroupement
C
Site central Site de regroupement
D
Site central Site toutes agence
E Agence A Agence B Agence C
Site toutes agences
3.1.2. Principe 2 : accompagnement au changement

Expliciter les changements.
8/24
3.2. Pourquoi des étapes intermédiaires ?
Pour valider progressivement en réel :
 Evaluer la capacité du réseau retenu à supporter la charge transactionnelle.
 Evaluer la capacité de la machine cible à supporter la charge transactionnelle et batch :

 A disposer d’une montée en charge progressive de la cible.
 A valider (corriger) le paramétrage (nouveau) mis en jeu sur une activité tout d’abord light
avant de bloquer toute la banque.
 A régler la stratégie d’habilitation des utilisateurs.
 A régler les problématiques d’édition.
3.3. Quels sont les gains attendus ?
Sur le plan technique
 Un seul TFJ.
 Une seule base de données.
 Aucun transfert inter sites.
Sur le plan bancaire
 Une vision globale client (image).
 Le risque bancaire maîtrisé.
 Dénouement possible à J de la plupart des opérations.
 Gestion des suspens simplifiée (au sens rapprochement bancaire du terme).
3.4. Quelles sont les contraintes ?
Mots clés : disponibilité.
Sur le plan réseau
 Disponibilité (sur la journée transactionnelle).
 Temps de latence (< 320 ms).
 Pas de double rebond satellitaire.
 Bande passante (> 64 Kbs).
 Backup conseillé (solution RNIS par exemple).
Sur le plan système
 Haute disponibilité (24 h / 24).
 Puissance machine (compter environ 8 MHz par user sur une architecture technique en cluster sur
processeur RISC).
 Espace de stockage (éditique centralisée).
9/24
Sur le plan base de données
 Sécurité d’accès.
 Disponibilité.
 Sauvegarde.
Sur le plan bancaire
 Mise en œuvre d’une solution de Plan de Continuité d’Activité (PCA).
Sur le plan éditique
Les flux éditiques sont fortement consommateurs de bande passante, aussi est-il indispensable de
mettre rapidement en place des mécanismes de rationalisation des éditions à la demande en agence.
Il peut être ainsi envisagé :
 La génération de fichiers PDF pour les états à la demande dépassant telle taille de manière à mettre
à disposition en temps réel ou en différé (pendant le creux de l’activité réseau) les fichiers ainsi
générés.
 La mise à disposition sur un serveur d’édition agence des fichiers générés pendant le batch nocturne
afin d’éviter leur rapatriement pendant la journée transactionnelle pour soulager le réseau. Cette
action est dénommée la descente éditique journalière (DEJ) : elle permettra un nivellement de la
charge réseau et conduira inéluctablement à une diminution des frais d’édition puisque seuls les
flots réellement désirés seront imprimés.
 Un accroissement des moyens éditique centralisés pour assumer l’édition de l’ensemble des états
de gestion mais également des états à destination de la clientèle (avis, extraits…)
Sur le plan applicatif Amplitude / Four JS
Version Amplitude :
 Minimum v 10.0.6 dite version fonctionnalisée si réseau VSAT (temps de latence important).
 Minimum v 7.3 si réseau à faible temps de latence.
Version 4JS :
 Minimum v 3.53 (client & serveur).
10/24
3.5. Quel est le coût d’un projet de centralisation ?
Ce coût est la résultante de la rigueur induite dans la méthodologie (démarche) de centralisation ainsi
que de la prise en compte des contraintes évoquées ci-dessus.
Mots clés : réactivité et compétences des hommes.
 Poste 1 : Réseau / matériel + Compétences réseau.
 Poste 2 : Système / matériel + Compétences système.
 Poste 3 : Homologation fonctionnelle.
 Poste 4 : Production + Accompagnement au changement + Astreintes haut niveau.
 Poste 5 : Accompagnement au changement des utilisateurs, disponibilité des organisateurs
11/24
4. Stratégie de centralisation progressive
4.1. Phase 0 : Existant
Etranger
SC Monetique
Virement salaire
Intégration prélèvements automatiques
99000
...
AGE AGE AGE

... AGE AGE AGE
00112 00xxx 00xxx 00xxx 00xxx 00xxx
BO/FO
Il s’agit d’une architecture classique décentralisée Amplitude à 2 niveaux.
4.2. Phase 1 : Construction d’un GSR
SC
99000
GSR
99100
AGE AGE AGE ... AGE AGE AGE
00xxx 00xxx 00xxx 00xxx 00xxx 00xxx
Le site de regroupement est vierge de toutes données bancaires, il ne contient que le paramétrage de
la couverture fonctionnelle agence. Il est prêt à recevoir les dossiers des premières agences.
12/24
4.3. Phase 1bis : Ouverture des nouvelles agences
SC
99000
GSR
99100
AGE AGE AGE ... AGE AGE AGE
00xxx 00xxx 00xxx 00xxx 00xxx 00xxx
L'utilisateur doit profiter de ce début de centralisation pour démarrer les nouvelles agences dont
l’ouverture avait été différée. C’est une façon de rôder le paramétrage du nouveau GSR sur des
volumétries light.
4.4. Phase 2 : Basculement des premières agences
Il y a une double exploitation en SC

central
99000
GSR
AGE AGE AGE
99100
00xxx 00xxx 00xxx
Le site de regroupement regroupe à ce stade les premières agences basculées, son comportement est
celui des n agences sur le plan fonctionnel (avec le gain d’automatisation des opérations intra-agences
même base) mais également sur le plan technique (communication et échange avec le SC pivot).
13/24
4.5. Phase 3 : Basculement des dernières agences
SC
99000
GSR
99100
Il s’agit de la cohabitation d’un site de regroupement et d’un site central n’assurant que les traitements
de masse.
4.6. Phase 4 : Suppression du SC
BMA
99100
Cette transition consiste à récupérer l’ensemble des fonctions du SC c'est-à-dire du paramétrage relatif
aux traitements de masse (arrêtés de compte, reporting légal…) mais également l’étranger et à l’intégrer
dans la base ex-SR qui devient alors une base site toutes agences.
4.7. Analyse
Cette approche en 4 phases permet de conduire progressivement d’une architecture décentralisée à 2

niveaux à une architecture centralisée type BMA.
Cette méthodologie conduit à une montée en charge progressive de l’activité transactionnelle et batch
du futur site toutes agences. Le mécanisme de déversement en vases communicantes n’impose pas de
contraintes temporelles de déploiement. Il sollicite en revanche une forme de double exploitation en
centrale.
14/24
5. L’approche organisationnelle du projet
Mots clés : parallélisation des tâches.
5.1. Principes
Dans le contexte d’une mise en place progressive de l’architecture, il est indispensable d’homologuer la
cible mais également l’architecture hybride en phase transitoire.
La phase transitoire revêt un intérêt tout particulier par la présence d’un site de regroupement. Ce type
d’architecture contraint à la mise en place de transferts inter sites (les mêmes que ceux en architecture
décentralisée classique) avec des volumes plus importants.
Il faut distinguer dans ce contexte les opérations :
 Inter agences intra-groupes :

Fonctionnement semblable à la cible centralisée.
 Inter agences inter-groupes :

Fonctionnement semblable à l’architecture décentralisée.
La cible est constituée d’un site toutes agences :
 Le dénouement des opérations est immédiat.
 Pas de transfert inter sites.
 Politique de pointage des valeurs à préciser par la banque.
15/24
5.2. Les étapes
Homologation fonctionnelle Homologation fonctionnelle Homologation technique
Phase transitoire Situation cible Environnement cible
NRF Habilitation Aspects réseau
Aspects système
Pointage des valeurs Pointage des valeurs
Gestion de la mémoire
../.. ../..
Chaîne de TFJ Politique de sauvegarde
Editique centrale
et
Editique agence
Validation fonctionnelle
Assemblage
Initialisation de la migration
Bascule progressive des agence
Bascule finale des fonctions du SC
16/24
6. Approche technique de la migration progressive
6.1. Phase 1 : Initialisation
La construction d’une base vide de dossiers, ne comportant que du paramétrage se fait

automatiquement à partir d’un outillage squelette fourni par Amplitude.
Il est nécessaire d'avoir enrichi au préalable le squelette par les spécificités de la banque, les spécificités
de certaines agences (exemple : agence Western Union).
6.2. Phase 2 : Transitoire
Le transfert des dossiers, valeurs d’une agence ou d’un groupe d’agences vers le GSR se fait
automatiquement à partir d’un outillage squelette fourni par Amplitude.
Il est nécessaire d'avoir enrichi au préalable le squelette par les spécificités de la banque.
Attention aux tables spécifiques.
FAQ sur la phase 2 :
 A quel moment et comment reprend on les utilisateurs ?
 A quel moment et comment reprend on les gestionnaires ?
La segmentation est souvent l’occasion de re-segmenter les PTF des gestionnaires.
6.3. Phase 3 : Finalisation
Le transfert des fonctions du SC se fait automatiquement à partir d’un outillage modulaire squelette
fourni par Amplitude.
17/24
6.4. Mixité des sources de données en phase 2
Comme il y a redondance des données en architecture centralisée, il est possible de mixer les reprises.
Exemple :
 Dossiers de crédits en agence.
 Compte et historique au SC (prise en considération de la profondeur d’historique conservé).
 La banque doit déterminer où sont les données les plus fiables.
6.5. Cas de la renumérotation des comptes
Il est fort souhaitable d’attendre la fin de la centralisation pour opérer ce genre d’action. La structure
mono-base se prête bien aux actions de masse.
6.6. Aspects batchs
Criticité des batch
Le traitement batch (TFJ) devient unique dans une architecture centralisée, aussi sa bonne fin
conditionne-t-elle l’ouverture du transactionnel le lendemain.
Externalisation
Il est ainsi possible de prévoir l’externalisation de certains traitements lourds et non critiques en
dehors du TFJ, en appliquant des mécanismes de mirroring de tables volatiles (ex : bkeve, bkmvtg…)
Il s’agit alors de sortir du TFJ et d’exécuter à la demande certains traitements.
Parallélisme
Le parallélisme des traitements de masse de Amplitude permet de réduire et d’assumer de fortes

volumétries.
Dans le cas des traitements parallèles dont la granularité est l’agence (cas des cautions, des crédits,
des prélèvements), il est impératif d’assurer l’étanchéité des processus.
Les traitements parallélisés de générations d’événements (cautions & crédits entre autres) nécessitent
d’incrémenter, par l’ensemble des sous-processus lancés, la zone bkope.num (no d’événement). Ainsi,
en cas de paramétrage des opérations au niveau Banque (age = 99000), l’opération unique devient une
ressource partagée et critique : elle est en permanence sollicitée en lecture, écriture conduisant à des
niveaux d’attente rédhibitoires des n sous-processus au regard du temps de traitement global.
18/24
C’est pourquoi, la solution, une fois le paramétrage stabilisé, est de dupliquer par agence ces opérations
fortement sollicitées permettant ainsi d’assurer une parfaite étanchéité entre les n sous-processus se
traduisant par des temps de traitement fortement améliorés.
Il est nécessaire de s'occuper tout particulièrement des opérations rattachées aux natures APPECH
(psmaj030) ainsi que COMCAU (cahc010).
6.7. Autre approche
Une autre approche permet de tester la capacité de la machine cible et du réseau : il s’agit de déplacer
progressivement les base agences sur le serveur central.
Est multiplié ainsi le nombre de bases permettant de simuler la charge transactionnelle sur le réseau et
sur la machine cible.
Seul le traitement de journée ne peut être testé dans cette approche : l'utilisateur reste sur un TFJ pour
chaque base.
Les accès concurrentiels aux ressources partagées de la base ne sont pas non plus validés dans ce
contexte.
19/24
7. Architecture applicative
7.1. Type d’architecture technique
Il est question ici d'architectures centralisées sur systèmes UNIX.
Il ne s’agit pas d’une architecture de type client / serveur mais d’une architecture dite de présentation
sur le serveur central. L’ensemble des processus (connexion à la base de données et traitements métier)
s’exécute sur la machine centrale et seul un flot propriétaire 4JS est échangé entre le Serveur
d’Application et le poste client assurant ainsi la présentation graphique et gérant les interactions
événementielles sur le poste.
Architecture 3 tiers.
7.2. Schéma d’architecture des flux
Cas du SGBD Oracle
Oracle Common Interface
4JS Open Database Interface
ODI TCP/IP OCI
DVM
Dynamic User Interface Dynamic Virtual Machine
( 1 ) Démarrer l'application via rlogin

DUI Business Logic
( 4, 6, 8 ) Statut des champs et des événements Oracle Database
Server
P-Code
P-Code
Oracle
( 2 ) Code TCL
Windows Compilateur Database
( 3, 5,7 ) Commandes TCL
Front End pour dessiner l'interface client BDL
Business Development Language
Source
Source
4GL
4GL
Client Serveur d'application Serveur de données
Figure 1 : Architecture Amplitude / 4JS.
20/24
8. Architecture matérielle
8.1. Vers une solution en cluster ?
Mots clés : Haute disponibilité et puissance
L’architecture centralisée induit une modification structurelle importante du rôle et de la charge

supportée par le serveur central.
La puissance du serveur central doit être largement augmentée.
De plus, la mise en œuvre d’une solution de haute disponibilité permettant de répondre aux exigences
de l’architecture centralisée doit être prise en compte.
La scission des activités de Serveur d’Application et de Serveur de Données sur 2 serveurs physiquement
séparés peut être envisagée : celle-ci répondant au besoin de charge mais également de sécurité.
21/24
Serveur
d’application
Serveur de
données
La configuration des serveurs en Mutual Take Over permet de répondre parfaitement aux aspects haute
disponibilité. Le serveur d’applications pouvant faire office de serveur d’application et serveur de
données si une panne survient sur le serveur de données (et inversement).
Cette solution assure une étanchéité entre les fonctions permettant la mise en œuvre d’une sécurité
plus grande du SI de la banque.
8.2. Préconisations hardware
Prévoir ainsi un (plusieurs) serveur(s) upgradable en terme de processeurs et mémoire.
Une attention particulière sur la situation du (des) serveur(s) au sein de la gamme concernée doit être
prise en compte en terme d’évolutivité.
Aussi, les drawers installés doivent permettre l’adjonction de cartes, de disques sans investissement
supplémentaire hors prix du (des) disque(s) ou de la carte.
22/24
8.3. Solution de backup
Vers la mise à disposition d’un backup sinistre, dit backup hors site ?
Les questions devant être posées concerne la stratégie de mise à jour de ce backup :
 Quel outil ?
 Quelle fréquence de vacation ?
 Backup synchrone / asynchrone ?
Ces réponses sont structurantes quant au choix de la technologie des baies de disques.
Client DELTA
Baie de
Serveur Serveur de
disques
d'Application Données
primaire
Site central
Mécanisme de réplication ou de
synchronisation
Baie de
Backup
disques
HS
secondaire
Site de secours
Figure 2 : Architecture en cluster avec backup HS
23/24
8.4. Backup dormant ou backup actif ?
Il est indispensable de préserver, de prioriser l’activité transactionnelle sur le site toutes agences ainsi
construit.
Aussi, le backup peut servir comme base d’info-centre dans la journée, les traitements éditiques de
masse ou exceptionnels peuvent ainsi être délocalisés sur le serveur de backup.
24/24

0036 3 11.6architecture Centralisée

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

0036 3 11.6architecture Centralisée

Transféré par

Droits d'auteur :

Formats disponibles

C2 – Usage restreint Sopra Banking Amplitude

Sopra Banking Software

Sopra Banking Amplitude

4. Stratégie de centralisation progressive 12

5. L’approche organisationnelle du projet 15

6. Approche technique de la migration progressive 17

8.2. Préconisations hardware 22

Dans toute la suite du document, les termes suivants seront utilisés :

 AGE = Base mono Agence.

 BMA = Base toutes (multi) agences : architecture centralisée.

 STA = Site Toutes Agences (synonyme de BMA).

 AM = Agence mère ou régionale.

 FV = Fonctions Vitales agence.

 TFJ = Traitement de Fin de Journée.

 SDA = Solution Dégradée Agence.

Type Répartition des bases Commentaire

Un serveur de production (transactionnel) et un

Architecture 1 Site central

 Architecture centralisée mono-base

 Architecture centralisée bi-bases

 Architecture décentralisée : ensemble de mono-agences

Les charges transactionnelles et batch sont assurées par les agences.

Les opérations inter agences se dénouent au moins à J+1.

 Architecture décentralisée : mixte

Centralisation partielle des BO au sein d’une même ville.

Elle nécessite de fait des connections réseaux performantes au sein de la ville.

 Architecture décentralisée : 3 niveaux

Quels sont les gains attendus ?

Quelles sont les contraintes ?

Quel est le coût d’une centralisation ?

 Aspect accompagnement au changement.

 Des utilisateurs finaux.

 Des équipes de production & système.

3.1. Principes de base

Puisqu'il s'agit de passer de Amplitude à Amplitude, d’une application vivante et opérationnelle à la

3.1.1. Principe 1 stratégie de migration progressive

Site central Site de regroupement

Site central Site de regroupement

Site central Site toutes agence

E Agence A Agence B Agence C

Site toutes agences

Agence A Agence B Agence C

3.1.2. Principe 2 : accompagnement au changement

3.2. Pourquoi des étapes intermédiaires ?

Pour valider progressivement en réel :

 Evaluer la capacité du réseau retenu à supporter la charge transactionnelle.

 Evaluer la capacité de la machine cible à supporter la charge transactionnelle et batch :

3.3. Quels sont les gains attendus ?

Sur le plan technique

 Une seule base de données.

 Aucun transfert inter sites.

Sur le plan bancaire

 Une vision globale client (image).

 Le risque bancaire maîtrisé.

 Dénouement possible à J de la plupart des opérations.

 Gestion des suspens simplifiée (au sens rapprochement bancaire du terme).

3.4. Quelles sont les contraintes ?

Mots clés : disponibilité.

Sur le plan réseau

 Disponibilité (sur la journée transactionnelle).

 Temps de latence (< 320 ms).

 Pas de double rebond satellitaire.

 Bande passante (> 64 Kbs).