Vous êtes sur la page 1sur 11

URBANISATION SI

CHAPITRE 4 : Urbanisme et architecture fonctionnelle

Transition de l’architecture métier cible vers


L’architecture fonctionnelle
L’architecture fonctionnelle est la structuration du système d’information en blocs
fonctionnels communicants. Elle répond à la question QUOI ? Sans tenir compte des acteurs
et de l’organisation.

Ce passage nécessite le respect de certaines règles et le déroulement de 7 étapes :


Les sept étapes :
Etape 1 : Le zonage
Etape 2 : Exploitation des processus métier
Etape 3 : Se servir des objectifs stratégiques

Etape 4 : Identifier les services des différents blocs


Etape 5 : Partir des événements de gestion
Etape 6 : Rebouclage par rapport aux objectifs stratégiques
Etape 7 : Rebouclage sur les règles d’urbanisme.
Le déroulement habituel de ces étapes est séquentiel, néanmoins et dans certaines
circonstances, certaines de ces étapes nécessitent un déroulement itératif.

Première étape : application des règles de bonnes pratiques qui permettent de


définir a priori les zones suivantes pour l’architecture fonctionnelle cible :
Règle n° 1 : Toute architecture fonctionnelle comporte une zone échange
(acquisition/restitution) qui est en quelque sorte la prise du SI.
L’acquisition transforme des flux événements organisationnels externes en flux fonctionnels
enrichis de toute information nécessaire à leur traitement en aval par la fonction prise en
compte. Elle garantit aussi la conformité du flux fonctionnel enrichi aux engagements
conclus avec le partenaire émetteur et aux conditions d’exécution déterminées par
l‘entreprise.
La restitution adapte les résultats issus de la fonction constitution aux supports
d’information et aux canaux de communication, et personnalise l’émission du flux en
fonction du partenaire et du canal.
Règle n° 2 : Toute architecture fonctionnelle comporte une zone gisement de données.
Cette zone reprend l’ensemble de toutes les informations dynamiques et pérennes de
l’entreprise ainsi que les services d’accès à ces données.
Elle assure la conservation et la valorisation du patrimoine d’informations de l’entreprise,
garantit sa cohérence et permet son enrichissement dans le temps.

Règle n° 3 : Toute architecture fonctionnelle comporte une zone référentiel de données et


de règles.

Z_Référentiel de données et de règles


Cette zone regroupe l’ensemble de toutes les informations communes aux différents
éléments du SI dont le cycle de vie est relativement stable.
Un référentiel contient les données de référence concernant les produits et services, les
règles de gestion administrative et comptable de la compagnie, ses métiers, son organisation
indépendamment d’un client particulier ainsi que les services d’accès à ces données.

Règle n° 4 : Toute architecture fonctionnelle comporte une zone décisionnel unique


Zone décisionnel :
Cette zone regroupe les blocs dédiés aux processus de gouvernance et d’analyse et utilisant
les informations globalisées historisées.

Règle n° 5 : Toute architecture fonctionnelle comporte une zone (ou un SI) opération par
métier principal de l’entreprise.

Zone opération :
Toute architecture fonctionnelle comporte une zone opération par métier principal de
l’entreprise ou de l’organisme. Le système d’information d’une entreprise ou d’un organisme
n’ayant qu’un seul métier ne comporte qu’une seule zone opération. Par contre, si
l’entreprise ou l’organisme a plusieurs métiers, le système d’information doit comporter une
zone opération pour chacun.

Règle n° 6 : Toute architecture fonctionnelle comporte une zone (ou un SI) ressource unique.
Zone (ou un SI) Ressource unique :

Cette zone regroupe les systèmes dédiés à la gestion des ressources internes à l’entreprise
(ressources humaines, comptabilité, etc.).

Deuxième étape : explorer les processus métier. Les processus métier


permettent d’identifier les classes concepts.
La description des processus permet naturellement d’identifier les concepts métier
manipulés, et donc les classes permettant de décrire un concept métier indépendant de
l’organisation, c’est-à-dire les classes de substance. Il convient ensuite de distinguer parmi
les classes de substance celles qui sont essentielles (classes concepts) des autres (classes
secondaires).
Chaque classe concept donne a priori lieu à :

❑ un quartier dans la zone gisement de données qui gère toutes les données
relatives à l’unique classe concept du quartier et aux classes secondaires
rattachées à cette classe concept

❑ un quartier dans la zone opération.

Exemple :

 Les classes concepts du T.O. sont les suivantes :

Personne, réservation, paiement, paiement échelonné, facture, voyage, tarif,


calendrier, structure compagnie, nomenclature comptable.

 Les classes secondaires sont :


Catalogue, agence, acompte, hébergement, type d’hébergement, lieu, moyen de
paiement, vendeur.
Architecture fonctionnelle cible contenant ces classes est la suivante :

Les classes concepts ont donné lieu soit à des quartiers soit à des îlots pour celles qui sont
venues peupler le quartier référentiel de données de la zone référentiel.

Paiement et paiement échelonné ont été regroupés.


Les classes secondaires n’ont pas donné lieu à des quartiers ou à des îlots.
Il s’agit des classes :
catalogue, liée à la classe substance voyage
agence, liée à la classe de substance structure compagnie

acompte, liée à la classe de substance paiement


hébergement, liée à la classe de substance voyage
type d’hébergement, liée à la classe de substance voyage
vendeur, liée à la classe de substance structure compagnie
lieu, liée à la classe de substance voyage
moyen de paiement, liée à la classe de substance paiement. .
Troisième étape : elle consiste à compléter l’ébauche d’architecture
fonctionnelle en fonction des objectifs stratégiques du SI.
Les objectifs stratégiques du SI (du T.O) ayant un impact sur l’architecture fonctionnelle
sont :
 Optimiser la valeur des clients

 Ouvrir à la vente 24 h / 24
 Permettre la vente directe via Internet et le centre d’appels
 Accepter ou refuser en temps réel les demandes de paiements échelonnés

L’objectif « Optimiser la valeur des clients » nous conduit à ajouter (ou à confirmer l’intérêt)
des quartiers suivants :

Q_Gestion de la qualité de service


Q_Traitement des demandes
Q_Traitement des problèmes
Q_Marketing opérationnel
Q_personne

Q_statistiques agences
Q_statistiques voyages
Q_marketing stratégique
Q_gestion des personnes.

L’objectif « Ouverture à la vente 24h/24 et 7j/7 » permet donc l’accès aux référentiels
produit (voyage) et client 24 h / 24, nous conduit à ajouter (ou à confirmer l’intérêt de) les
quartiers ou îlots suivants :
Q_Multimédia ; Q_Personne ;

I_Voyage ; I_Tarif ; I_Calendrier ;


Q_Gestion des réservations ;
Q_Gestion des personnes ;
Q_Réservation ;
Q_Traitement des demandes.
Bien entendu, l’existence de ces quartiers est une condition nécessaire pour offrir une
ouverture à la vente 24 h / 24 et 7j/7, et donc l’accès aux référentiels produit et client, mais
non suffisante. Le besoin de 24 h/24 et 7j/7 entraînera d’autres conséquences sur
l’architecture technique.

L’objectif « Permettre la vente directe » nous conduit à ajouter (ou à confirmer l’intérêt de)
les quartiers ou îlots suivants :
Q_Multimédia ; Q_Gestion de la qualité de service ;
Q_Traitement des demandes ; Q_Traitement des problèmes ;

Q_Gestion des réservations ; Q_Réservation ;


Q_Gestion des personnes ;
Q_Personne ;
I_Voyage ;
I_Tarif ;

I_Calendrier.

L’objectif « accepter ou refuser en TR les demandes de paiements échelonnés » nous


conduit à ajouter (ou à confirmer l’intérêt de) les quartiers suivants :
I_Acceptation des paiements échelonnés ;

I_Gestion de l’acceptation des paiements échelonnés.

La quatrième étape : consiste à identifier les services des différents blocs


composant l’architecture fonctionnelle.
 Pour cela on se base sur :
❑ · La connaissance du système d’information existant,
❑ · La connaissance de l’urbanisme,

❑ Les modèles existants sur le marché (par exemple TOM dans


les télécoms ou IAA pour l’assurance)….
La cinquième étape : poursuit l’exploitation des processus métier.
Il s’agit de partir des événements de gestion et d’exécuter les processus permettant de
traiter ces événements en vérifiant pour chaque activité du processus à quels blocs
fonctionnels elle peut faire appel pour être menée à bien et si les blocs fonctionnels en
question contiennent les services nécessaires.

La sixième étape : consiste à faire un rebouclage par rapport aux objectifs


stratégiques du SI.
Il s’agit de reprendre un à un chaque objectif d’évolution du système d’information et de se
demander en quoi l’architecture fonctionnelle y répond et en quoi elle apporte une
amélioration significative par rapport à l’existant.

La septième étape est un rebouclage sur les règles d’urbanisme pour


l’architecture fonctionnelle.
On fait une représentation finale de l’architecture fonctionnelle. Normalement, ces règles
doivent avoir été respectées, mais il convient de s’en assurer.

Enfin l’architecture fonctionnelle complète du cas « TO » est la suivante :


Les règles d’urbanisme pour l’architecture
fonctionnelle
Règle n° 1 : Règle d’unicité en blocs.
Un îlot appartient à un et un seul quartier, un quartier appartient à une et une seule zone,
donc un îlot appartient à une et une seule zone.
Au niveau de l’architecture fonctionnelle, un bloc ne doit pas être dupliqué.

Règle n° 2 : Règle d’asynchronisme des îlots.


Après avoir traité un événement, un îlot peut en traiter immédiatement un autre sans avoir
à se préoccuper de ce qu’il advient du compte rendu de traitement de l’événement
précédent.

Règle n° 3 : Un bloc comporte obligatoirement une prise (interface externe).


Il est capable d’activer les services du bloc et de gérer les communications entrantes et
sortantes du bloc...

Règle n° 4 : Toute communication entrante ou sortante d’un bloc passe par sa prise.

Ces prises présentent les avantages suivants :


Centraliser les appels de services et limiter le nombre d’interfaces ;
Ajouter un niveau d’encapsulation supplémentaire : l’intra-muros d’un bloc est à considérer
comme une boîte noire par l’extérieur ; en développement objet, une classe traduit déjà un
premier niveau d’encapsulation, le principe est à reconduire aux niveaux supérieurs îlots,
quartier et zone ;
Mutualiser les services
Accroître la modularité
Faciliter la mise en œuvre de maintenances évolutives.

Règle n° 5 : Seules les prises communiquent avec le gestionnaire des flux.

Règle n° 6 : Une donnée est sous la responsabilité (quel que soit le type d’accès : création,
modification, suppression, visualisation) d’un îlot et d’un seul.

Vous aimerez peut-être aussi