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 :
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.
