SlideShare une entreprise Scribd logo
1  sur  58
Télécharger pour lire hors ligne
Chp 1 - Introduction à l’Urbanisation des SI
Urbanisation des Systèmes d’Information
GL5
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1
INSAT - Institut National des Sciences Appliquées et de Technologie
‫واﻟﺗﻛﻧوﻟوﺟﯾﺎ‬ ‫اﻟﺗطﺑﯾﻘﯾﺔ‬ ‫ﻟﻠﻌﻠوم‬ ‫اﻟوطﻧﻲ‬ ‫اﻟﻣﻌﮭد‬
❏ Architectures d’Entreprise
❏ Frameworks d’architectures d’entreprise
❏ TOGAF
❏ Urbanisation des Systèmes d’Information
2
PLAN
Chp 1 - Introduction à l’Urbanisation des SI
3
Architectures d’Entreprise
Définition (1)
● Architecture enables you to accommodate complexity and change.
If you don't have Enterprise Architecture, your enterprise is not
going to be viable in an increasingly complex and changing
external environment.
John Zachman
● EA provides the strategic context to enable organizations to move
from innovation to assembly line production information products,
and still meet the constantly changing needs of the business
environment.
IBM Certified Infrastructure Systems Architect
4
Architectures d’Entreprise
Définition (2)
● Plan conceptuel, définit la structure et le fonctionnement des
organisations.
● Permet de déterminer comment une organisation peut atteindre
efficacement ses objectifs actuels et futurs.
● Implique la pratique de l'analyse, de la planification, de la conception
et de la mise en œuvre éventuelle de l'analyse sur une entreprise.
● Aide à la transformation numérique:
○ Regroupement des applications et des processus existants dans le
but de créer un environnement homogène.
○ Permet de répondre à la croissance rapide des technologies
5
Architectures d’Entreprise
Définition (3)
● Les concepts d'architecture d'entreprise sont variables:
○ Différents d’une organisation à l’autre
○ Différents d’un profil à l’autre dans une même organisation
■ Professionnels IT: Infrastructures, d'applications et de composants de
gestion sous leur contrôle.
■ Architectes d'entreprise: Architectures logicielles, processus et
orchestration
■ Intégrateurs: Assemblage de matériels et logiciels
6
Architectures d’Entreprise
Importance
● Aider les différents départements d'une entreprise à mieux
comprendre le modèle d'entreprise et à articuler les défis et les
risques commerciaux.
○ Alignement stratégique
● Unification et la coordination des processus départementaux au
sein d'une organisation
● Identification des lacunes de l’entreprise par tous ses acteurs
○ Prise de décision plus éclairée.
7
Architectures d’Entreprise
Objectifs
● Fournir des systèmes d'information (SI) appropriés en fonction des
demandes de l'entreprise
● Optimiser l’utilisation des processus, souvent fragmentés, d’une entreprise,
dans un environnement intégré, ouvert aux changements et cohérent avec
la stratégie métier.
● Créer une carte ou un plan (blueprint) de la structure et des opérations
d'une organisation.
○ Doit comprendre des informations telles qu'une carte des actifs informatiques
et des processus opérationnels.
● Promouvoir l'alignement et la normalisation des équipes.
○ Unification des environnements au sein des équipes et des organisations,
et/ou établissement de communications automatisées entre eux
8
Architectures d’Entreprise
Architectures d’Entreprise vs. Architectures Logicielles
9
Architectures d’Entreprise
Architecture d’Entreprise Architecture Logicielle
Quoi? Système d’Information Application
Pourquoi?
Définir les principes directeurs
d’une organisation, respect de
normes et règles techniques
Définir des directives techniques pour
la phase de réalisation
Qui?
Dirigeant, DSI, Architecte, Cabinet
de conseil
Ingénieur d’études, Responsable
informatique, Analyste, Développeur,
Intégrateur
Comment? Vendor-neutral
Liée à des solutions technologiques,
fournisseurs et compétences
Quand?
Ponctuellement, sur décision des
dirigeants
Dans la phase de conception de
chaque projet
Architecte SI : Profil
● Chef d’orchestre
● Coordonne les différents spécialistes intervenant dans les SI
● Au delà de l’expertise technique, il doit faire du SI un outil de développement
et de stratégie
○ Doit être calé dans les métiers de l’entreprise
● Travaille au sein des grandes entreprises utilisatrices (banques,
télécommunications, grande distribution, etc.) mais aussi dans les cabinet
de conseil
10
Architectures d’Entreprise
(*)
(*) https://www.lesjeudis.com/metiers/systeme/architecte-systeme-d'information/fiche
Architecte SI : Missions
● Analyser le système existant
● Construire la cartographie du SI
● Choisir les technologies selon les contraintes (coût, délai, intégration et
sécurité)
● Élaborer un plan de développement ou d’intégration
● Piloter le déploiement
● Informer et conseiller la direction sur les conséquences technologiques et
organisationnelles du nouveau SI
11
Architectures d’Entreprise
Couches d’une Architecture d’Entreprise
● Les différentes couches d’une AE (Layers) sont des domaines de pratique
pour décrire correctement une entreprise selon une spécification bien
déterminée.
● Le nombre de couches change d’un framework à un autre (voir les
frameworks dans la section suivante), mais les plus populaires sont les
suivantes:
○ Couche métier
○ Couche de données
○ Couche applicative
○ Couche de technologie
Slide 12
Architectures d’Entreprise
Couches d’une Architecture d’Entreprise
Slide 13
Architectures d’Entreprise
Couche métier - Business Layer
Couche de données - Data Layer
Couche applicative - Application Layer
Couche technologique - Technology Layer
Couches d’une Architecture d’Entreprise
Slide 14
Architectures d’Entreprise
Business
Couche métier - Business Layer
Décrit:
● Les objectifs stratégiques, politiques d’entreprise, et
modèles opérationnels
● Décompositions fonctionnelles et modèles
organisationnels
● Processus métier, workflows et règles qui articulent les
autorités, responsabilités et politiques affectées
● Organisation des cycles, périodes et calendriers
● Fournisseurs d’équipements, logiciels et services
Couches d’une Architecture d’Entreprise
Slide 15
Architectures d’Entreprise
Business
Couche de données - Data Layer
Concerne les informations et données collectées, organisées,
sauvegardées et distribuées. A les caractéristiques suivants:
● Architecture d’Information: Une vue globale du flux d’information de
l’entreprise
● Architecture de données: Décrit le flux des données et comment elles
sont sauvegardées et traitées.
● MDM: Master Data Management & BI: Business Intelligence
● Data quality: identifier, analyser, améliorer et mesurer la qualité des
données, les problèmes d’intégrité et les efforts d’amélioration
● Abstraction des modèles de bases de données
● Gestion du cycle de vie des données
Data
Couches d’une Architecture d’Entreprise
Slide 16
Architectures d’Entreprise
Business
Couche applicative - Application Layer
Offre une description rigoureuse des applications logicielles, par exemple:
● Un inventaire des applications et des diagrammes logiciels
● Les interfaces entre les applications qui sont: les événements,
messages, etc.
● Modélisation des entités structurelles: composants logiciels
réutilisables, applications et systèmes d’informations
● Définition des collaborations entre les applications ou services
● Définition du comportement des applications et services
Data
Application
Couches d’une Architecture d’Entreprise
Slide 17
Architectures d’Entreprise
Business
Couche technologique - Technology Layer
La couche ou architecture technologique comprend:
● Les middlewares
● Les environnement d’exécution des applications et frameworks
● Les serveurs et systèmes d’exploitation, d’authentification et
d’autorisation.
● Les systèmes de sécurité et de monitoring.
● Les plateformes matérielles et serveurs hôtes
● Les datacenters, réseaux LAN et WAN disponibles, diagrammes de
connectivité internet.
● Les bases de données et langages de programmation utilisés
Data
Application
Technology
Chp 1 - Introduction à l’Urbanisation des SI
18
Frameworks d’Architectures d’Entreprise
Objectif d’un EAF (Enterprise Architecture Framework)
● EAF : décrit des méthodes structurées afin de mettre en œuvre les projets
d’architecture d’entreprise, accompagnés d’outils et bonnes pratiques.
● Plusieurs EAF de référence:
○ ZF : Zachman’s Framework
○ EAP : Enterprise Architecture Planning
○ FEAF: Federal Enterprise Architecture Framework
○ TOGAF : The Open Group Architecture Framework
19
Frameworks d’Architectures d’Entreprise
ZF : Zachman’s Framework
● Défini par John Zachman, le pionnier des architectures d’entreprises, initialement
publié en 1987.
● Un schéma de classification bidimensionnel pour les représentations descriptives
d'une entreprise.
● Représente les artefacts de conception de divers produits selon le public cible
(perspective) ainsi que le contenu ou sujet de l’artefact (abstraction)
20
Frameworks d’Architectures d’Entreprise
A1 A2 A3
P1 AC11 AC12 AC13
P2 AC21 AC22 AC23
P3 AC31 AC32 AC33
Artefact de
conception
Abstractions
Perspectives
ZF : Zachman’s Framework
21
(*)
(*) https://www.dragon1.com/downloads/ZachmanBookRFIextract.pdf
EAP : Enterprise Architecture Planning
● Framework qui détermine le processus de planification pour définir les
architectures d’entreprise et les implémenter.
● EAP permet de définir la façon d’approcher la création des deux premières lignes
dans le framework de Zachman, le planner et le owner.
○ La conception du système en tant que tel est en dehors du scope de EAP.
● EAP définit ce que les données, applications et technologies permettent de
faire pour le bénéfice de l’entreprise.
● Définit 4 niveaux (Levels) et 7 composants
22
Frameworks d’Architectures d’Entreprise
EAP : Enterprise Architecture Planning
● Level1 : Par où commencer?
Production d’un plan, couvrant les
décisions à prendre pour la méthodologie
à utiliser, les parties impliquées et les
outils nécessaires.
● Level2 : Où en sommes-nous aujourd’hui?
Définition des processus métiers et des
systèmes et technologies actuellement utilisés.
● Level3 : Où voulons-nous aller?
(1) définition des données nécessaires pour le métier, (2) définition des applications majeures
nécessaires pour la gestion des données et des fonctions métier, et (3) définition des
plateformes nécessaires pour supporter ces applications.
● Level4 : Comment y arriver?
Définition des plans d’implémentation des applications, une analyse coût/bénéfice, et un chemin
clair pour la migration.
Slide 23
Frameworks d’Architectures d’Entreprise
FEAF : Federal Enterprise Architecture Framework
● Architecture d’entreprise de référence réalisée par le gouvernement fédéral aux États Unis.
● Permet de guider l'intégration des processus d'architecture de gestion stratégique, commerciale et
technologique.
● C’est un framework spécifiquement réservé aux agences fédérales, contrairement aux autres
frameworks plus génériques tels que Zachman ou TOGAF.
● Ce framework est basé sur l’approche Zachman, comme c’est le cas pour EAP, par contre il inclut les trois
premières colonnes.
● Définit quatre niveaux d’architecture:
○ Architecture métier: Ce qui est fait, par qui, comment et pourquoi
○ Architecture de données: Informations utilisées par l’agence pour réaliser le métier
○ Architecture d’application: Applications et logiciels qui traitent les données selon les règles métiers définies.
○ Architecture de technologie: Technologies de communication et matériel utilisé pour supporter les trois couches
ci-dessus.
24
Frameworks d’Architectures d’Entreprise
FEAF : Federal Enterprise Architecture Framework
● FEAF Définit un assortiment de modèles de référence appelé CRM (Consolidated Reference
Model) qui développe une taxonomie commune pour décrire les ressources IT
Slide 25
Frameworks d’Architectures d’Entreprise
TOGAF : The Open Group Architecture Framework
● Le standard EAF le plus utilisé et le plus célèbre dans le monde
● Développé et maintenu par les membres de The Open Group, travaillant sous le Architecture
Forum (voir www.opengroup.org/architecture )
● Le développement initial de la version 1 de TOGAF en 1995 était basé sur le EAF TAFIM
(Technical Architecture Framework for Information Management), développé par le
département de la défense américain (DoD).
● Se base sur les 4 domaines d’architecture précédemment cités (métier, données, application
et technologie), mais définit également d’autres domaines en combinant ces quatre couches:
○ L’architecture d’information
○ Les architecture de risque et de sécurité
○ L’architecture digitale
Nous présentons le framework TOGAF plus en détails dans la section suivante.
26
Frameworks d’Architectures d’Entreprise
Chp 1 - Introduction à l’Urbanisation des SI
27
TOGAF
Principes TOGAF : Principes métier
Slide 28
TOGAF
Principe Définition
Primauté des principes
Ces principes de gestion de l'information s'appliquent à toutes les organisations au sein de
l'entreprise.
Maximiser le bénéfice pour
l'entreprise
Les décisions relatives à la gestion de l'information sont prises de manière à procurer un avantage
maximal à l'entreprise dans son ensemble.
La gestion de l'information
est l'affaire de tous
Toutes les organisations de l'entreprise participent aux décisions de gestion de l'information
nécessaires pour atteindre les objectifs de l'entreprise.
Continuité des activités Les opérations de l'entreprise sont maintenues malgré les interruptions du système.
Applications d'usage
courant
Le développement d'applications utilisées dans l'ensemble de l'entreprise est préféré au
développement d'applications similaires ou dupliquées qui ne sont fournies qu'à une organisation
particulière.
Orientation vers les services
L'architecture est basée sur une conception de services qui reflètent les activités commerciales
réelles comprenant les processus commerciaux de l'entreprise (ou inter-entreprises).
Respect de la loi
Les processus de gestion des informations de l'entreprise sont conformes à toutes les lois,
politiques et réglementations pertinentes.
Responsabilité
informatique
L'organisation informatique est responsable de la propriété et de la mise en œuvre des processus
et de l'infrastructure informatiques qui permettent aux solutions de répondre aux exigences
définies par l'utilisateur en matière de fonctionnalité, de niveaux de service, de coûts et de délais de
livraison.
Protection de la propriété
intellectuelle
La propriété intellectuelle (PI) de l'entreprise doit être protégée. Cette protection doit être reflétée
dans l'architecture informatique, la mise en œuvre et les processus de gouvernance.
Principes TOGAF : Principes de données
Slide 29
TOGAF
Principe Définition
Les données sont un
atout
Les données sont un actif qui a une valeur pour l'entreprise et qui est géré en
conséquence.
Les données sont
partagées
Les utilisateurs ont accès aux données nécessaires à l'exercice de leurs fonctions ;
les données sont donc partagées entre les fonctions et les organisations de
l'entreprise.
Les données sont
accessibles
Les données sont accessibles aux utilisateurs pour qu'ils puissent remplir leurs
fonctions.
Administrateur des
données
Chaque élément de données a un administrateur responsable de la qualité des
données.
Vocabulaire et
définitions des
données communs
Les données sont définies de manière cohérente dans toute l'entreprise, et les
définitions sont compréhensibles et disponibles pour tous les utilisateurs.
Sécurité des données
Les données sont protégées contre toute utilisation ou divulgation non autorisée.
En plus des aspects traditionnels de la classification de la sécurité nationale, cela
inclut, mais sans s'y limiter, la protection des informations pré-décisionnelles,
sensibles, sensibles à la sélection des sources et propriétaires.
Principes TOGAF : Principes d’application & de technologie
Slide 30
TOGAF
Principe Définition
Indépendance
technologique
Les applications sont indépendantes des choix technologiques spécifiques et
peuvent donc fonctionner sur une variété de plateformes technologiques.
Facilité d'utilisation
Les applications sont faciles à utiliser. La technologie sous-jacente est
transparente pour les utilisateurs, qui peuvent ainsi se concentrer sur les tâches à
accomplir.
Changement basé sur
les exigences
Ce n'est qu'en réponse aux besoins de l'entreprise que des changements sont
apportés aux applications et à la technologie.
Gestion réactive du
changement
Les modifications apportées à l'environnement d'information de l'entreprise sont
mises en œuvre en temps utile.
Contrôle de la diversité
technique
La diversité technologique est contrôlée pour minimiser le coût non trivial du
maintien de l'expertise et de la connectivité entre plusieurs environnements de
traitement.
Interopérabilité
Les logiciels et le matériel doivent être conformes à des normes définies qui
favorisent l'interopérabilité des données, des applications et des technologies.
ADM : The Architecture Development Method
● TOGAF ADM fournit un processus testé pour le développement des architectures.
● ADM permet d’établir un EAF, de développer le contenu d’une architecture, et faire la
transition et de gouverner la réalisation d’architectures.
● Cycle itératif de définition et réalisation continues d’architectures
○ Permet une transformation contrôlée des entreprises, en réponse de leurs
besoins et opportunités métiers
31
TOGAF
ADM : The
Architecture
Development
Method
TOGAF
32
Une description détaillée des phases de l’ADM est fournie ici:
https://pubs.opengroup.org/togaf-standard/adm/index.html
ADM : Phases (1)
33
TOGAF
● Phase0 : Phase préliminaire
Activités de préparation et d’initiation pour
créer l’architecture, inclut la personnalisation du
framework TOGAF et la définition des principes
d’architecture.
● PhaseA : Architecture Vision
Phase initiale du cycle de définition de
l’architecture. Informations sur la définition de
sa portée (scope), identification des parties
prenantes, et l’obtention de l’accord nécessaire
pour sa mise en place.
● PhaseB : Business Architecture
Développement de l’architecture métier.
● PhaseC : Information Systems Architecture
Développement de l’architecture du SI.
● PhaseD : Technology Architecture
Développement de l’architecture technologique.
ADM : Phases (2)
34
TOGAF
● PhaseE : Opportunities & Solutions
Planning initial d’implémentation et
identification des livrables de l’architecture
prédéfinie.
● PhaseF : Migration Planning
Comment passer de l’architecture initiale vers
l’architecture cible en finalisant un plan détaillé
d’implémentation et de migration.
● PhaseG : Implementation Governance
Définition d’un contrat d’architecture pour gérer
le processus d’implémentation et déploiement,
et attribution des rôle pour les intervenants.
● PhaseH : Architecture Change Management
Établissement de procédures pour gérer les
modifications de la nouvelle architecture.
● PhaseCentrale : Requirements Management
Définition du processus de gestion des besoins
tout au long de l’ADM
Contenu de l’architecture dans TOGAF
● Le TOGAF Content Framework définit un cadre de catégorisation à utiliser pour structurer :
○ La description de l'architecture
○ Les produits de travail utilisés pour exprimer une architecture
○ La collection de modèles qui décrivent l'architecture.
● Il permet de:
○ Fournir un modèle détaillé des produits du travail architectural
○ Favoriser la cohérence des résultats créés en suivant l’ADM.
○ Fournir une liste de contrôle complète des produits d'architecture qui pourraient
être créés.
○ Réduire le risque de lacunes dans l'ensemble des livrables d'architecture finaux.
○ Aider l'entreprise à définir des concepts, des termes et des livrables d'architecture
standard.
35
TOGAF
36
Contenu de
l’architecture
dans TOGAF
TOGAF
Artefacts d’Architecture selon les phases de l’ADM (1)
● TOGAF définit plusieurs concepts pour satisfaire les besoins des différentes parties
prenantes, tels que les blocs de construction, les catalogues, les matrices et les
diagrammes.
● Blocs de construction (Building blocks)
○ Entités d'un type particulier dans le métamodèle
■ par exemple, un service commercial appelé "Bon de commande"
○ Peuvent également inclure des entités dépendantes ou contenues selon le
contexte de l'architecture
■ par exemple, un service commercial appelé "Bon de commande" peut inclure
implicitement un certain nombre de processus, d'entités de données, de
composants d'application, etc.
37
TOGAF
Artefacts d’Architecture selon les phases de l’ADM (2)
● Catalogues
○ Listes de blocs de construction d'un type spécifique, ou de types apparentés, qui sont utilisés à des
fins de gouvernance ou de référence
■ par exemple, un organigramme, indiquant les lieux et les acteurs
● Matrices
○ Grilles qui montrent les relations entre deux ou plusieurs entités du modèle
○ Utilisées pour représenter les relations qui sont basées sur des listes plutôt que sur des graphiques
■ par exemple, une matrice CRUD montrant quelles applications créent, lisent, mettent à jour et
suppriment un type particulier de données.
● Diagrammes
○ Rendus du contenu architectural dans un format graphique pour permettre aux parties prenantes de
récupérer les informations requises
■ par exemple, un diagramme de flux ou BPM
38
TOGAF
Artefacts TOGAF
39
TOGAF
Exemples d’Artefacts : APPLICATION PORTFOLIO CATALOG
40
Exemples d’Artefacts : Application / Data Matrix
41
Exemples d’Artefacts : BUSINESS SERVICES AND INFORMATION DIAGRAM
42
Artefacts d’Architecture selon les phases de l’ADM
Vous trouverez une liste complète des templates des
différents artefacts TOGAF sur ce lien:
○ https://github.com/leonux/architecture-work/tree/master/Tog
af-material/TOGAF_9_Templates
Slide 43
TOGAF
Chp 1 - Introduction à l’Urbanisation des SI
44
Urbanisation des Systèmes d’Information
Définition
● Architectures d’entreprises
○ Met en évidence le rôle d’architecte
○ Propose une structure des applicatifs basée sur les processus métiers et objectifs de
l’entreprise, sans proposer de contraintes a priori
● Urbanisation / Urbanisme
○ Ensemble de règles s’imposant à tout ou partie du SI
○ Définition de règles à respecter par les applications, pour obtenir un SI évolutif
○ Les concepts manipulés s'apparentent à ceux de l'urbanisation de l'habitat humain
(organisation des villes, du territoire)
=> Le processus d'urbanisation répond aux couches "Scope (contexte)" , "Business
Model (conceptuel)" et "System Model (logique)" des Architectures d’Entreprise.
Slide 45
Urbanisation des SI
Origine
● Les chefs de projet concevaient des travaux par lot (batch) utilisant des
informations provenant d’applications connexes.
○ Programmes spécifiques d’extraction de fichiers des applications
● Plusieures difficultés:
○ Obligation de respecter les contraintes des concepteurs: horaire d’exploitation par
exemple
○ Incapacité d’optimiser l’utilisation des machines: difficulté de faire tourner les travaux en
parallèle
○ Les concepteurs des applications sources prennent en compte les contraintes
fonctionnelles, mais pas (ou peu) celles de l’exploitant
● Solution proposée:
○ Imposer des règles globales aux concepteurs de façon à tenir compte des contraintes
techniques et d’exploitation
○ Respecter l’asynchronisme et indépendance des traitements
○ Unifier les interfaces
=> de même que, dans une cité, l’urbaniste impose des règles aux architectes
(alimentation électrique, égouts, alimentation des eaux, etc.)
Slide 46
Urbanisation des SI
Urbanisation des territoires vs. Urbanisation des SI.
Slide 47
Urbanisation des SI
Méta-modèle des Concepts
Slide 48
Urbanisation des SI
Concepts fondamentaux: Conglomérats
● Découpage du SI en conglomérats hiérarchisés de façon à obéir à un plan
d’organisation du SI (POSI), garant des enjeux liés à l’urbanisation
● Les conglomérats peuvent être:
○ zone: zone d’affectation du sol selon l’usage qui y sera autorisé et la nature des
activités dominantes
■ Permet de classifier les quartiers selon la nature de la mission
○ quartier: entité assurant une production contribuant à la mission de l’entreprise
■ rassemble les différents types d’opérations ou processus homogènes d’un métier ou
activité
■ Le quartier s’appuie sur les blocs ou îlots qui le composent
■ Un quartier invoque principalement les services de ses îlots
○ îlot: blocs finaux indécomposables
■ Ensemble de données et de traitements homogènes dans une activité, portant sur un seul
niveau d’agrégation de l’information
■ Composant métier possédant une mission de service autours d’un thème dont il est
responsable pour tout le SI
Slide 49
Urbanisation des SI
Exemples de conglomérats
Slide 50
Urbanisation des SI
Concepts fondamentaux: Périmètres
● L’exercice le plus difficile est de déterminer la limite d’un bloc
● Il faut pour chaque bloc:
○ Attribuer son périmètre d’autonomie
○ Choisir les données et services qui seront dupliquées pour ce bloc, et celles qui seront
mutualisées.
Slide 51
Urbanisation des SI
Dans le milieu urbain cette organisation se fait au gré à gré par une régulation assez
naturelle de la redondance. Un magasin s'établit dans un quartier bien achalandé et
disparaît ou persiste en fonction de son essor. En revanche, l'implantation de
certaines composantes à des échelons plus ou moins locaux est décidée au niveau
de structures centrales (crèches, centres commerciaux, parkings, centrales
électriques, etc.).
Plan stratégique et plan d’urbanisme
● POSI: Plan d’organisation du SI
○ Équivalent du POS (Plan d’occupation du sol) dans le milieu urbain
○ Définit les grandes orientations du SI et les directions majeures de son
évolution
○ Doit porter :
■ Sur les aspects structurels (urbanisme): principes de découpage et identification
des blocs, sans descendre en dessous du niveau de la zone
■ Sur les aspects dynamiques (urbanisation): règles d’organisation statuant sur les
degrés de liberté associés aux futures constructions
● Plan d’urbanisme et d’urbanisation
○ Déclinaison opérationnelle du POSI
○ Traduisent l’aspect pratique des possibilités d’aménagement du SI
○ Déclinent les orientations du POSI de manière pratique restituée dans une
cartographie
Slide 52
Urbanisation des SI
Cartographie d’un Système d’Information
● Représentation du système d’information (SI) d’une organisation
ainsi que ses connexions avec l’extérieur
● Peut être plus ou moins détaillée et inclure, par exemple, les biens
matériels, logiciels, les réseaux de connexion, mais aussi les
informations, activités et processus qui reposent sur ces biens
● Doit permettre de:
○ réaliser l’inventaire patrimonial du système d’information, à savoir la
liste des composants du SI et leur description détaillée;
○ présenter le système d’information sous forme de vues
(représentations partielles du SI), de ses liens et de son fonctionnement.
Elles visent à rendre lisibles et compréhensibles différents aspects du
système d’information.
Slide 53
Urbanisation des SI
Cartographie d’un SI : Composition
● Vision métier
○ Vue de l’écosystème: entités ou systèmes avec lesquels le SI
interagit
○ Vue métier: processus et informations principales, valeurs métiers
● Vision applicative
○ Vue des applications: composants logiciels du SI, services offerts et
flux de données entre eux
○ Vue de l’administration: périmètres et niveaux de privilèges des
utilisateurs et administrateurs.
● Vision infrastructure
○ Vue des infrastructures logiques: cloisonnement logique des
réseaux, notamment par la définition des plages d’adresses IP, des
VLAN et des fonctions de filtrage et routage
○ Vue des infrastructures physiques: équipements physiques qui
composent le système d’information ou utilisés par celui-ci.
Slide 54
Urbanisation des SI
Notion de terrain
Slide 55
Urbanisation des SI
● Prise en compte de la nature du sol avant la construction
● Considérer les préoccupations fonctionnelles, techniques, organisationnelles..
● Terrain d’urbanisation: décomposition possible répondant à des niveaux de
préoccupations différents
Exemple de
Cartographie
Cartographie
Fonctionnelle de
l’INSAT
Réalisée par Amira Ben Achour, GL5,
promotion 2018
56
Exemple de
Cartographie
Cartographie
Applicative de
l’INSAT
Réalisée par Amira Ben Achour, GL5,
promotion 2018
57
- IBM Systems Group, IBM Certified Infrastructure Systems Architect, Mai 2004
- Alexander S. Gillis, Enterprise architecture (EA), Techtarget, 2020
- Badreddine Ladjemi, Cours d’urbanisation des SI, INSAT, 2017
- John A. Zachman, The Zachman Framework For Enterprise Architecture, 2003
- Steven Spewak and S. C. Hill (1992) Enterprise Architecture Planning: Developing a Blueprint for Data,
Applications, and Technology. Boston, QED Pub. Group. p. 1
- Lean IX, FEAF: le guide Ultime, consulté en Août 2022,
https://www.leanix.net/fr/wiki/ea/feaf-federal-enterprise-architecture-framework
- Wikipedia, Federal Enterprise Architecture, consultée en Août 2022,
https://en.wikipedia.org/wiki/Federal_enterprise_architecture
- Maache Salah, An experiment applying the enterprise architecture, case study: Algerian government agency.
International Journal of Research in Management, Science and Technology, April 2016.
- The Open Group, The TOGAF Standard, https://pubs.opengroup.org/togaf-standard/ , consulté Aout 2022
- DSCG: UE5 - Management des Systèmes d’Information, Architecture d’entreprise et Urbanisation des SI (Cours),
inspiré de IN Management et gouvernance des SI - Carvalho-Lavoisier 2009, et de Le projet d’urbanisation du SI -
C.Longépé 2009.
- ANSSI, Cartographie du SI,
https://www.mauricenavarro.com/ressources/cartographie-du-systeme-d-information/ Nov. 2018
-
58
Références

Contenu connexe

Tendances

introduction à la modélisation objet
introduction à la modélisation objetintroduction à la modélisation objet
introduction à la modélisation objet
Amir Souissi
 
Chap1 systéme d'information
Chap1 systéme d'informationChap1 systéme d'information
Chap1 systéme d'information
Ghita Benabdellah
 
PFE BI - INPT
PFE BI - INPTPFE BI - INPT
PFE BI - INPT
riyadadva
 

Tendances (20)

Dojo 02 : Introduction au noSQL
Dojo 02 : Introduction au noSQLDojo 02 : Introduction au noSQL
Dojo 02 : Introduction au noSQL
 
Introduction au BIG DATA
Introduction au BIG DATAIntroduction au BIG DATA
Introduction au BIG DATA
 
INTRODUCTION A BPM
INTRODUCTION A BPMINTRODUCTION A BPM
INTRODUCTION A BPM
 
exercices business intelligence
exercices business intelligence exercices business intelligence
exercices business intelligence
 
Chp2 - Vers les Architectures Orientées Services
Chp2 - Vers les Architectures Orientées ServicesChp2 - Vers les Architectures Orientées Services
Chp2 - Vers les Architectures Orientées Services
 
introduction à la modélisation objet
introduction à la modélisation objetintroduction à la modélisation objet
introduction à la modélisation objet
 
Business intelligence
Business intelligenceBusiness intelligence
Business intelligence
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
 
Architectures orientés services (SOA)
Architectures orientés services (SOA)Architectures orientés services (SOA)
Architectures orientés services (SOA)
 
Bases de données réparties par la pratique
Bases de données réparties par la pratiqueBases de données réparties par la pratique
Bases de données réparties par la pratique
 
Resume de BI
Resume de BIResume de BI
Resume de BI
 
Etat de l’art approche et outils BI
Etat de l’art approche et outils BIEtat de l’art approche et outils BI
Etat de l’art approche et outils BI
 
Chap1 systéme d'information
Chap1 systéme d'informationChap1 systéme d'information
Chap1 systéme d'information
 
cahier des charges
cahier des chargescahier des charges
cahier des charges
 
PFE BI - INPT
PFE BI - INPTPFE BI - INPT
PFE BI - INPT
 
Diapo - SI.ppt
Diapo - SI.pptDiapo - SI.ppt
Diapo - SI.ppt
 
Urbanisation
UrbanisationUrbanisation
Urbanisation
 
Système d'Information (S.I.) dans l’entreprise
Système d'Information (S.I.) dans l’entrepriseSystème d'Information (S.I.) dans l’entreprise
Système d'Information (S.I.) dans l’entreprise
 
Le système d’information de l’entreprise
Le système d’information de l’entrepriseLe système d’information de l’entreprise
Le système d’information de l’entreprise
 
Cours Base de données relationnelles
Cours Base de données relationnellesCours Base de données relationnelles
Cours Base de données relationnelles
 

Similaire à chp1-Intro à l'urbanisation des SI.pdf

Déjeuner-débat EIM360 | Casser les silos pour améliorer l’efficacité métiers ...
Déjeuner-débat EIM360 | Casser les silos pour améliorer l’efficacité métiers ...Déjeuner-débat EIM360 | Casser les silos pour améliorer l’efficacité métiers ...
Déjeuner-débat EIM360 | Casser les silos pour améliorer l’efficacité métiers ...
Sollan France
 
Rs303 g formation-utilisation-avancee-de-ibm-rational-clearcase-pour-unix
Rs303 g formation-utilisation-avancee-de-ibm-rational-clearcase-pour-unixRs303 g formation-utilisation-avancee-de-ibm-rational-clearcase-pour-unix
Rs303 g formation-utilisation-avancee-de-ibm-rational-clearcase-pour-unix
CERTyou Formation
 
Le système d'information unifié
Le système d'information unifiéLe système d'information unifié
Le système d'information unifié
itSMF France
 
Le système d'information unifié
Le système d'information unifiéLe système d'information unifié
Le système d'information unifié
itSMF France
 

Similaire à chp1-Intro à l'urbanisation des SI.pdf (20)

TOGAF.pptx
TOGAF.pptxTOGAF.pptx
TOGAF.pptx
 
Togaf
TogafTogaf
Togaf
 
Joseph Glorieux & Mathieu Brun Maintenant que mon delivery pipeline est en pl...
Joseph Glorieux & Mathieu Brun Maintenant que mon delivery pipeline est en pl...Joseph Glorieux & Mathieu Brun Maintenant que mon delivery pipeline est en pl...
Joseph Glorieux & Mathieu Brun Maintenant que mon delivery pipeline est en pl...
 
Déjeuner-débat EIM360 | Casser les silos pour améliorer l’efficacité métiers ...
Déjeuner-débat EIM360 | Casser les silos pour améliorer l’efficacité métiers ...Déjeuner-débat EIM360 | Casser les silos pour améliorer l’efficacité métiers ...
Déjeuner-débat EIM360 | Casser les silos pour améliorer l’efficacité métiers ...
 
Présentation en ligne | Casser les silos pour améliorer l’efficacité métiers ...
Présentation en ligne | Casser les silos pour améliorer l’efficacité métiers ...Présentation en ligne | Casser les silos pour améliorer l’efficacité métiers ...
Présentation en ligne | Casser les silos pour améliorer l’efficacité métiers ...
 
Temoignages clients
Temoignages clientsTemoignages clients
Temoignages clients
 
Vendre l'ae club-urba-ea-v1-7-2016
Vendre l'ae club-urba-ea-v1-7-2016Vendre l'ae club-urba-ea-v1-7-2016
Vendre l'ae club-urba-ea-v1-7-2016
 
Discovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data VirtualizationDiscovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data Virtualization
 
Business Card
Business CardBusiness Card
Business Card
 
Rs303 g formation-utilisation-avancee-de-ibm-rational-clearcase-pour-unix
Rs303 g formation-utilisation-avancee-de-ibm-rational-clearcase-pour-unixRs303 g formation-utilisation-avancee-de-ibm-rational-clearcase-pour-unix
Rs303 g formation-utilisation-avancee-de-ibm-rational-clearcase-pour-unix
 
LES SYSTEMES INTERACTIFS D'AIDE A' LA DECISION.
LES SYSTEMES INTERACTIFS D'AIDE A' LA DECISION.LES SYSTEMES INTERACTIFS D'AIDE A' LA DECISION.
LES SYSTEMES INTERACTIFS D'AIDE A' LA DECISION.
 
Le système d'information unifié
Le système d'information unifiéLe système d'information unifié
Le système d'information unifié
 
Le système d'information unifié
Le système d'information unifiéLe système d'information unifié
Le système d'information unifié
 
Cours de Management des Systèmes d'information
Cours de Management des Systèmes d'informationCours de Management des Systèmes d'information
Cours de Management des Systèmes d'information
 
Sap presentation
Sap presentationSap presentation
Sap presentation
 
Le Pensum du DSI
Le Pensum du DSILe Pensum du DSI
Le Pensum du DSI
 
Xi3 1 whats-new_fr
Xi3 1 whats-new_frXi3 1 whats-new_fr
Xi3 1 whats-new_fr
 
Présentation en ligne | Casser les silos pour améliorer l’efficacité métiers ...
Présentation en ligne | Casser les silos pour améliorer l’efficacité métiers ...Présentation en ligne | Casser les silos pour améliorer l’efficacité métiers ...
Présentation en ligne | Casser les silos pour améliorer l’efficacité métiers ...
 
X-Analysis - for IBM partners - FR
X-Analysis - for IBM partners - FRX-Analysis - for IBM partners - FR
X-Analysis - for IBM partners - FR
 
Work placement bachelor's degree computer science_2009
Work placement bachelor's degree computer science_2009Work placement bachelor's degree computer science_2009
Work placement bachelor's degree computer science_2009
 

Plus de Lilia Sfaxi

Plus de Lilia Sfaxi (20)

Plan d'études_INSAT_2022_2023.pdf
Plan d'études_INSAT_2022_2023.pdfPlan d'études_INSAT_2022_2023.pdf
Plan d'études_INSAT_2022_2023.pdf
 
Lab3-DB_Neo4j
Lab3-DB_Neo4jLab3-DB_Neo4j
Lab3-DB_Neo4j
 
Lab2-DB-Mongodb
Lab2-DB-MongodbLab2-DB-Mongodb
Lab2-DB-Mongodb
 
Lab1-DB-Cassandra
Lab1-DB-CassandraLab1-DB-Cassandra
Lab1-DB-Cassandra
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-Correction
 
TP1-UML-Correction
TP1-UML-CorrectionTP1-UML-Correction
TP1-UML-Correction
 
TP0-UML-Correction
TP0-UML-CorrectionTP0-UML-Correction
TP0-UML-Correction
 
TD4-UML
TD4-UMLTD4-UML
TD4-UML
 
TD4-UML-Correction
TD4-UML-CorrectionTD4-UML-Correction
TD4-UML-Correction
 
TD3-UML-Séquences
TD3-UML-SéquencesTD3-UML-Séquences
TD3-UML-Séquences
 
TD3-UML-Correction
TD3-UML-CorrectionTD3-UML-Correction
TD3-UML-Correction
 
TD2 - UML - Correction
TD2 - UML - CorrectionTD2 - UML - Correction
TD2 - UML - Correction
 
TD1 - UML - DCU
TD1 - UML - DCUTD1 - UML - DCU
TD1 - UML - DCU
 
TD1-UML-correction
TD1-UML-correctionTD1-UML-correction
TD1-UML-correction
 
Android - Tp1 - installation et démarrage
Android - Tp1 -   installation et démarrageAndroid - Tp1 -   installation et démarrage
Android - Tp1 - installation et démarrage
 
Android - Tp2 - Elements graphiques
Android - Tp2 - Elements graphiques Android - Tp2 - Elements graphiques
Android - Tp2 - Elements graphiques
 
Android - Tp3 - intents
Android - Tp3 -  intentsAndroid - Tp3 -  intents
Android - Tp3 - intents
 
Android - TPBonus - web services
Android - TPBonus - web servicesAndroid - TPBonus - web services
Android - TPBonus - web services
 
Android - Tp4 - graphiques avancés
Android - Tp4 - graphiques avancésAndroid - Tp4 - graphiques avancés
Android - Tp4 - graphiques avancés
 
Android - Tp 5 - stockage de données
Android - Tp 5 -  stockage de donnéesAndroid - Tp 5 -  stockage de données
Android - Tp 5 - stockage de données
 

chp1-Intro à l'urbanisation des SI.pdf

  • 1. Chp 1 - Introduction à l’Urbanisation des SI Urbanisation des Systèmes d’Information GL5 Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 1 INSAT - Institut National des Sciences Appliquées et de Technologie ‫واﻟﺗﻛﻧوﻟوﺟﯾﺎ‬ ‫اﻟﺗطﺑﯾﻘﯾﺔ‬ ‫ﻟﻠﻌﻠوم‬ ‫اﻟوطﻧﻲ‬ ‫اﻟﻣﻌﮭد‬
  • 2. ❏ Architectures d’Entreprise ❏ Frameworks d’architectures d’entreprise ❏ TOGAF ❏ Urbanisation des Systèmes d’Information 2 PLAN
  • 3. Chp 1 - Introduction à l’Urbanisation des SI 3 Architectures d’Entreprise
  • 4. Définition (1) ● Architecture enables you to accommodate complexity and change. If you don't have Enterprise Architecture, your enterprise is not going to be viable in an increasingly complex and changing external environment. John Zachman ● EA provides the strategic context to enable organizations to move from innovation to assembly line production information products, and still meet the constantly changing needs of the business environment. IBM Certified Infrastructure Systems Architect 4 Architectures d’Entreprise
  • 5. Définition (2) ● Plan conceptuel, définit la structure et le fonctionnement des organisations. ● Permet de déterminer comment une organisation peut atteindre efficacement ses objectifs actuels et futurs. ● Implique la pratique de l'analyse, de la planification, de la conception et de la mise en œuvre éventuelle de l'analyse sur une entreprise. ● Aide à la transformation numérique: ○ Regroupement des applications et des processus existants dans le but de créer un environnement homogène. ○ Permet de répondre à la croissance rapide des technologies 5 Architectures d’Entreprise
  • 6. Définition (3) ● Les concepts d'architecture d'entreprise sont variables: ○ Différents d’une organisation à l’autre ○ Différents d’un profil à l’autre dans une même organisation ■ Professionnels IT: Infrastructures, d'applications et de composants de gestion sous leur contrôle. ■ Architectes d'entreprise: Architectures logicielles, processus et orchestration ■ Intégrateurs: Assemblage de matériels et logiciels 6 Architectures d’Entreprise
  • 7. Importance ● Aider les différents départements d'une entreprise à mieux comprendre le modèle d'entreprise et à articuler les défis et les risques commerciaux. ○ Alignement stratégique ● Unification et la coordination des processus départementaux au sein d'une organisation ● Identification des lacunes de l’entreprise par tous ses acteurs ○ Prise de décision plus éclairée. 7 Architectures d’Entreprise
  • 8. Objectifs ● Fournir des systèmes d'information (SI) appropriés en fonction des demandes de l'entreprise ● Optimiser l’utilisation des processus, souvent fragmentés, d’une entreprise, dans un environnement intégré, ouvert aux changements et cohérent avec la stratégie métier. ● Créer une carte ou un plan (blueprint) de la structure et des opérations d'une organisation. ○ Doit comprendre des informations telles qu'une carte des actifs informatiques et des processus opérationnels. ● Promouvoir l'alignement et la normalisation des équipes. ○ Unification des environnements au sein des équipes et des organisations, et/ou établissement de communications automatisées entre eux 8 Architectures d’Entreprise
  • 9. Architectures d’Entreprise vs. Architectures Logicielles 9 Architectures d’Entreprise Architecture d’Entreprise Architecture Logicielle Quoi? Système d’Information Application Pourquoi? Définir les principes directeurs d’une organisation, respect de normes et règles techniques Définir des directives techniques pour la phase de réalisation Qui? Dirigeant, DSI, Architecte, Cabinet de conseil Ingénieur d’études, Responsable informatique, Analyste, Développeur, Intégrateur Comment? Vendor-neutral Liée à des solutions technologiques, fournisseurs et compétences Quand? Ponctuellement, sur décision des dirigeants Dans la phase de conception de chaque projet
  • 10. Architecte SI : Profil ● Chef d’orchestre ● Coordonne les différents spécialistes intervenant dans les SI ● Au delà de l’expertise technique, il doit faire du SI un outil de développement et de stratégie ○ Doit être calé dans les métiers de l’entreprise ● Travaille au sein des grandes entreprises utilisatrices (banques, télécommunications, grande distribution, etc.) mais aussi dans les cabinet de conseil 10 Architectures d’Entreprise (*) (*) https://www.lesjeudis.com/metiers/systeme/architecte-systeme-d'information/fiche
  • 11. Architecte SI : Missions ● Analyser le système existant ● Construire la cartographie du SI ● Choisir les technologies selon les contraintes (coût, délai, intégration et sécurité) ● Élaborer un plan de développement ou d’intégration ● Piloter le déploiement ● Informer et conseiller la direction sur les conséquences technologiques et organisationnelles du nouveau SI 11 Architectures d’Entreprise
  • 12. Couches d’une Architecture d’Entreprise ● Les différentes couches d’une AE (Layers) sont des domaines de pratique pour décrire correctement une entreprise selon une spécification bien déterminée. ● Le nombre de couches change d’un framework à un autre (voir les frameworks dans la section suivante), mais les plus populaires sont les suivantes: ○ Couche métier ○ Couche de données ○ Couche applicative ○ Couche de technologie Slide 12 Architectures d’Entreprise
  • 13. Couches d’une Architecture d’Entreprise Slide 13 Architectures d’Entreprise Couche métier - Business Layer Couche de données - Data Layer Couche applicative - Application Layer Couche technologique - Technology Layer
  • 14. Couches d’une Architecture d’Entreprise Slide 14 Architectures d’Entreprise Business Couche métier - Business Layer Décrit: ● Les objectifs stratégiques, politiques d’entreprise, et modèles opérationnels ● Décompositions fonctionnelles et modèles organisationnels ● Processus métier, workflows et règles qui articulent les autorités, responsabilités et politiques affectées ● Organisation des cycles, périodes et calendriers ● Fournisseurs d’équipements, logiciels et services
  • 15. Couches d’une Architecture d’Entreprise Slide 15 Architectures d’Entreprise Business Couche de données - Data Layer Concerne les informations et données collectées, organisées, sauvegardées et distribuées. A les caractéristiques suivants: ● Architecture d’Information: Une vue globale du flux d’information de l’entreprise ● Architecture de données: Décrit le flux des données et comment elles sont sauvegardées et traitées. ● MDM: Master Data Management & BI: Business Intelligence ● Data quality: identifier, analyser, améliorer et mesurer la qualité des données, les problèmes d’intégrité et les efforts d’amélioration ● Abstraction des modèles de bases de données ● Gestion du cycle de vie des données Data
  • 16. Couches d’une Architecture d’Entreprise Slide 16 Architectures d’Entreprise Business Couche applicative - Application Layer Offre une description rigoureuse des applications logicielles, par exemple: ● Un inventaire des applications et des diagrammes logiciels ● Les interfaces entre les applications qui sont: les événements, messages, etc. ● Modélisation des entités structurelles: composants logiciels réutilisables, applications et systèmes d’informations ● Définition des collaborations entre les applications ou services ● Définition du comportement des applications et services Data Application
  • 17. Couches d’une Architecture d’Entreprise Slide 17 Architectures d’Entreprise Business Couche technologique - Technology Layer La couche ou architecture technologique comprend: ● Les middlewares ● Les environnement d’exécution des applications et frameworks ● Les serveurs et systèmes d’exploitation, d’authentification et d’autorisation. ● Les systèmes de sécurité et de monitoring. ● Les plateformes matérielles et serveurs hôtes ● Les datacenters, réseaux LAN et WAN disponibles, diagrammes de connectivité internet. ● Les bases de données et langages de programmation utilisés Data Application Technology
  • 18. Chp 1 - Introduction à l’Urbanisation des SI 18 Frameworks d’Architectures d’Entreprise
  • 19. Objectif d’un EAF (Enterprise Architecture Framework) ● EAF : décrit des méthodes structurées afin de mettre en œuvre les projets d’architecture d’entreprise, accompagnés d’outils et bonnes pratiques. ● Plusieurs EAF de référence: ○ ZF : Zachman’s Framework ○ EAP : Enterprise Architecture Planning ○ FEAF: Federal Enterprise Architecture Framework ○ TOGAF : The Open Group Architecture Framework 19 Frameworks d’Architectures d’Entreprise
  • 20. ZF : Zachman’s Framework ● Défini par John Zachman, le pionnier des architectures d’entreprises, initialement publié en 1987. ● Un schéma de classification bidimensionnel pour les représentations descriptives d'une entreprise. ● Représente les artefacts de conception de divers produits selon le public cible (perspective) ainsi que le contenu ou sujet de l’artefact (abstraction) 20 Frameworks d’Architectures d’Entreprise A1 A2 A3 P1 AC11 AC12 AC13 P2 AC21 AC22 AC23 P3 AC31 AC32 AC33 Artefact de conception Abstractions Perspectives
  • 21. ZF : Zachman’s Framework 21 (*) (*) https://www.dragon1.com/downloads/ZachmanBookRFIextract.pdf
  • 22. EAP : Enterprise Architecture Planning ● Framework qui détermine le processus de planification pour définir les architectures d’entreprise et les implémenter. ● EAP permet de définir la façon d’approcher la création des deux premières lignes dans le framework de Zachman, le planner et le owner. ○ La conception du système en tant que tel est en dehors du scope de EAP. ● EAP définit ce que les données, applications et technologies permettent de faire pour le bénéfice de l’entreprise. ● Définit 4 niveaux (Levels) et 7 composants 22 Frameworks d’Architectures d’Entreprise
  • 23. EAP : Enterprise Architecture Planning ● Level1 : Par où commencer? Production d’un plan, couvrant les décisions à prendre pour la méthodologie à utiliser, les parties impliquées et les outils nécessaires. ● Level2 : Où en sommes-nous aujourd’hui? Définition des processus métiers et des systèmes et technologies actuellement utilisés. ● Level3 : Où voulons-nous aller? (1) définition des données nécessaires pour le métier, (2) définition des applications majeures nécessaires pour la gestion des données et des fonctions métier, et (3) définition des plateformes nécessaires pour supporter ces applications. ● Level4 : Comment y arriver? Définition des plans d’implémentation des applications, une analyse coût/bénéfice, et un chemin clair pour la migration. Slide 23 Frameworks d’Architectures d’Entreprise
  • 24. FEAF : Federal Enterprise Architecture Framework ● Architecture d’entreprise de référence réalisée par le gouvernement fédéral aux États Unis. ● Permet de guider l'intégration des processus d'architecture de gestion stratégique, commerciale et technologique. ● C’est un framework spécifiquement réservé aux agences fédérales, contrairement aux autres frameworks plus génériques tels que Zachman ou TOGAF. ● Ce framework est basé sur l’approche Zachman, comme c’est le cas pour EAP, par contre il inclut les trois premières colonnes. ● Définit quatre niveaux d’architecture: ○ Architecture métier: Ce qui est fait, par qui, comment et pourquoi ○ Architecture de données: Informations utilisées par l’agence pour réaliser le métier ○ Architecture d’application: Applications et logiciels qui traitent les données selon les règles métiers définies. ○ Architecture de technologie: Technologies de communication et matériel utilisé pour supporter les trois couches ci-dessus. 24 Frameworks d’Architectures d’Entreprise
  • 25. FEAF : Federal Enterprise Architecture Framework ● FEAF Définit un assortiment de modèles de référence appelé CRM (Consolidated Reference Model) qui développe une taxonomie commune pour décrire les ressources IT Slide 25 Frameworks d’Architectures d’Entreprise
  • 26. TOGAF : The Open Group Architecture Framework ● Le standard EAF le plus utilisé et le plus célèbre dans le monde ● Développé et maintenu par les membres de The Open Group, travaillant sous le Architecture Forum (voir www.opengroup.org/architecture ) ● Le développement initial de la version 1 de TOGAF en 1995 était basé sur le EAF TAFIM (Technical Architecture Framework for Information Management), développé par le département de la défense américain (DoD). ● Se base sur les 4 domaines d’architecture précédemment cités (métier, données, application et technologie), mais définit également d’autres domaines en combinant ces quatre couches: ○ L’architecture d’information ○ Les architecture de risque et de sécurité ○ L’architecture digitale Nous présentons le framework TOGAF plus en détails dans la section suivante. 26 Frameworks d’Architectures d’Entreprise
  • 27. Chp 1 - Introduction à l’Urbanisation des SI 27 TOGAF
  • 28. Principes TOGAF : Principes métier Slide 28 TOGAF Principe Définition Primauté des principes Ces principes de gestion de l'information s'appliquent à toutes les organisations au sein de l'entreprise. Maximiser le bénéfice pour l'entreprise Les décisions relatives à la gestion de l'information sont prises de manière à procurer un avantage maximal à l'entreprise dans son ensemble. La gestion de l'information est l'affaire de tous Toutes les organisations de l'entreprise participent aux décisions de gestion de l'information nécessaires pour atteindre les objectifs de l'entreprise. Continuité des activités Les opérations de l'entreprise sont maintenues malgré les interruptions du système. Applications d'usage courant Le développement d'applications utilisées dans l'ensemble de l'entreprise est préféré au développement d'applications similaires ou dupliquées qui ne sont fournies qu'à une organisation particulière. Orientation vers les services L'architecture est basée sur une conception de services qui reflètent les activités commerciales réelles comprenant les processus commerciaux de l'entreprise (ou inter-entreprises). Respect de la loi Les processus de gestion des informations de l'entreprise sont conformes à toutes les lois, politiques et réglementations pertinentes. Responsabilité informatique L'organisation informatique est responsable de la propriété et de la mise en œuvre des processus et de l'infrastructure informatiques qui permettent aux solutions de répondre aux exigences définies par l'utilisateur en matière de fonctionnalité, de niveaux de service, de coûts et de délais de livraison. Protection de la propriété intellectuelle La propriété intellectuelle (PI) de l'entreprise doit être protégée. Cette protection doit être reflétée dans l'architecture informatique, la mise en œuvre et les processus de gouvernance.
  • 29. Principes TOGAF : Principes de données Slide 29 TOGAF Principe Définition Les données sont un atout Les données sont un actif qui a une valeur pour l'entreprise et qui est géré en conséquence. Les données sont partagées Les utilisateurs ont accès aux données nécessaires à l'exercice de leurs fonctions ; les données sont donc partagées entre les fonctions et les organisations de l'entreprise. Les données sont accessibles Les données sont accessibles aux utilisateurs pour qu'ils puissent remplir leurs fonctions. Administrateur des données Chaque élément de données a un administrateur responsable de la qualité des données. Vocabulaire et définitions des données communs Les données sont définies de manière cohérente dans toute l'entreprise, et les définitions sont compréhensibles et disponibles pour tous les utilisateurs. Sécurité des données Les données sont protégées contre toute utilisation ou divulgation non autorisée. En plus des aspects traditionnels de la classification de la sécurité nationale, cela inclut, mais sans s'y limiter, la protection des informations pré-décisionnelles, sensibles, sensibles à la sélection des sources et propriétaires.
  • 30. Principes TOGAF : Principes d’application & de technologie Slide 30 TOGAF Principe Définition Indépendance technologique Les applications sont indépendantes des choix technologiques spécifiques et peuvent donc fonctionner sur une variété de plateformes technologiques. Facilité d'utilisation Les applications sont faciles à utiliser. La technologie sous-jacente est transparente pour les utilisateurs, qui peuvent ainsi se concentrer sur les tâches à accomplir. Changement basé sur les exigences Ce n'est qu'en réponse aux besoins de l'entreprise que des changements sont apportés aux applications et à la technologie. Gestion réactive du changement Les modifications apportées à l'environnement d'information de l'entreprise sont mises en œuvre en temps utile. Contrôle de la diversité technique La diversité technologique est contrôlée pour minimiser le coût non trivial du maintien de l'expertise et de la connectivité entre plusieurs environnements de traitement. Interopérabilité Les logiciels et le matériel doivent être conformes à des normes définies qui favorisent l'interopérabilité des données, des applications et des technologies.
  • 31. ADM : The Architecture Development Method ● TOGAF ADM fournit un processus testé pour le développement des architectures. ● ADM permet d’établir un EAF, de développer le contenu d’une architecture, et faire la transition et de gouverner la réalisation d’architectures. ● Cycle itératif de définition et réalisation continues d’architectures ○ Permet une transformation contrôlée des entreprises, en réponse de leurs besoins et opportunités métiers 31 TOGAF
  • 32. ADM : The Architecture Development Method TOGAF 32 Une description détaillée des phases de l’ADM est fournie ici: https://pubs.opengroup.org/togaf-standard/adm/index.html
  • 33. ADM : Phases (1) 33 TOGAF ● Phase0 : Phase préliminaire Activités de préparation et d’initiation pour créer l’architecture, inclut la personnalisation du framework TOGAF et la définition des principes d’architecture. ● PhaseA : Architecture Vision Phase initiale du cycle de définition de l’architecture. Informations sur la définition de sa portée (scope), identification des parties prenantes, et l’obtention de l’accord nécessaire pour sa mise en place. ● PhaseB : Business Architecture Développement de l’architecture métier. ● PhaseC : Information Systems Architecture Développement de l’architecture du SI. ● PhaseD : Technology Architecture Développement de l’architecture technologique.
  • 34. ADM : Phases (2) 34 TOGAF ● PhaseE : Opportunities & Solutions Planning initial d’implémentation et identification des livrables de l’architecture prédéfinie. ● PhaseF : Migration Planning Comment passer de l’architecture initiale vers l’architecture cible en finalisant un plan détaillé d’implémentation et de migration. ● PhaseG : Implementation Governance Définition d’un contrat d’architecture pour gérer le processus d’implémentation et déploiement, et attribution des rôle pour les intervenants. ● PhaseH : Architecture Change Management Établissement de procédures pour gérer les modifications de la nouvelle architecture. ● PhaseCentrale : Requirements Management Définition du processus de gestion des besoins tout au long de l’ADM
  • 35. Contenu de l’architecture dans TOGAF ● Le TOGAF Content Framework définit un cadre de catégorisation à utiliser pour structurer : ○ La description de l'architecture ○ Les produits de travail utilisés pour exprimer une architecture ○ La collection de modèles qui décrivent l'architecture. ● Il permet de: ○ Fournir un modèle détaillé des produits du travail architectural ○ Favoriser la cohérence des résultats créés en suivant l’ADM. ○ Fournir une liste de contrôle complète des produits d'architecture qui pourraient être créés. ○ Réduire le risque de lacunes dans l'ensemble des livrables d'architecture finaux. ○ Aider l'entreprise à définir des concepts, des termes et des livrables d'architecture standard. 35 TOGAF
  • 37. Artefacts d’Architecture selon les phases de l’ADM (1) ● TOGAF définit plusieurs concepts pour satisfaire les besoins des différentes parties prenantes, tels que les blocs de construction, les catalogues, les matrices et les diagrammes. ● Blocs de construction (Building blocks) ○ Entités d'un type particulier dans le métamodèle ■ par exemple, un service commercial appelé "Bon de commande" ○ Peuvent également inclure des entités dépendantes ou contenues selon le contexte de l'architecture ■ par exemple, un service commercial appelé "Bon de commande" peut inclure implicitement un certain nombre de processus, d'entités de données, de composants d'application, etc. 37 TOGAF
  • 38. Artefacts d’Architecture selon les phases de l’ADM (2) ● Catalogues ○ Listes de blocs de construction d'un type spécifique, ou de types apparentés, qui sont utilisés à des fins de gouvernance ou de référence ■ par exemple, un organigramme, indiquant les lieux et les acteurs ● Matrices ○ Grilles qui montrent les relations entre deux ou plusieurs entités du modèle ○ Utilisées pour représenter les relations qui sont basées sur des listes plutôt que sur des graphiques ■ par exemple, une matrice CRUD montrant quelles applications créent, lisent, mettent à jour et suppriment un type particulier de données. ● Diagrammes ○ Rendus du contenu architectural dans un format graphique pour permettre aux parties prenantes de récupérer les informations requises ■ par exemple, un diagramme de flux ou BPM 38 TOGAF
  • 40. Exemples d’Artefacts : APPLICATION PORTFOLIO CATALOG 40
  • 41. Exemples d’Artefacts : Application / Data Matrix 41
  • 42. Exemples d’Artefacts : BUSINESS SERVICES AND INFORMATION DIAGRAM 42
  • 43. Artefacts d’Architecture selon les phases de l’ADM Vous trouverez une liste complète des templates des différents artefacts TOGAF sur ce lien: ○ https://github.com/leonux/architecture-work/tree/master/Tog af-material/TOGAF_9_Templates Slide 43 TOGAF
  • 44. Chp 1 - Introduction à l’Urbanisation des SI 44 Urbanisation des Systèmes d’Information
  • 45. Définition ● Architectures d’entreprises ○ Met en évidence le rôle d’architecte ○ Propose une structure des applicatifs basée sur les processus métiers et objectifs de l’entreprise, sans proposer de contraintes a priori ● Urbanisation / Urbanisme ○ Ensemble de règles s’imposant à tout ou partie du SI ○ Définition de règles à respecter par les applications, pour obtenir un SI évolutif ○ Les concepts manipulés s'apparentent à ceux de l'urbanisation de l'habitat humain (organisation des villes, du territoire) => Le processus d'urbanisation répond aux couches "Scope (contexte)" , "Business Model (conceptuel)" et "System Model (logique)" des Architectures d’Entreprise. Slide 45 Urbanisation des SI
  • 46. Origine ● Les chefs de projet concevaient des travaux par lot (batch) utilisant des informations provenant d’applications connexes. ○ Programmes spécifiques d’extraction de fichiers des applications ● Plusieures difficultés: ○ Obligation de respecter les contraintes des concepteurs: horaire d’exploitation par exemple ○ Incapacité d’optimiser l’utilisation des machines: difficulté de faire tourner les travaux en parallèle ○ Les concepteurs des applications sources prennent en compte les contraintes fonctionnelles, mais pas (ou peu) celles de l’exploitant ● Solution proposée: ○ Imposer des règles globales aux concepteurs de façon à tenir compte des contraintes techniques et d’exploitation ○ Respecter l’asynchronisme et indépendance des traitements ○ Unifier les interfaces => de même que, dans une cité, l’urbaniste impose des règles aux architectes (alimentation électrique, égouts, alimentation des eaux, etc.) Slide 46 Urbanisation des SI
  • 47. Urbanisation des territoires vs. Urbanisation des SI. Slide 47 Urbanisation des SI
  • 48. Méta-modèle des Concepts Slide 48 Urbanisation des SI
  • 49. Concepts fondamentaux: Conglomérats ● Découpage du SI en conglomérats hiérarchisés de façon à obéir à un plan d’organisation du SI (POSI), garant des enjeux liés à l’urbanisation ● Les conglomérats peuvent être: ○ zone: zone d’affectation du sol selon l’usage qui y sera autorisé et la nature des activités dominantes ■ Permet de classifier les quartiers selon la nature de la mission ○ quartier: entité assurant une production contribuant à la mission de l’entreprise ■ rassemble les différents types d’opérations ou processus homogènes d’un métier ou activité ■ Le quartier s’appuie sur les blocs ou îlots qui le composent ■ Un quartier invoque principalement les services de ses îlots ○ îlot: blocs finaux indécomposables ■ Ensemble de données et de traitements homogènes dans une activité, portant sur un seul niveau d’agrégation de l’information ■ Composant métier possédant une mission de service autours d’un thème dont il est responsable pour tout le SI Slide 49 Urbanisation des SI
  • 50. Exemples de conglomérats Slide 50 Urbanisation des SI
  • 51. Concepts fondamentaux: Périmètres ● L’exercice le plus difficile est de déterminer la limite d’un bloc ● Il faut pour chaque bloc: ○ Attribuer son périmètre d’autonomie ○ Choisir les données et services qui seront dupliquées pour ce bloc, et celles qui seront mutualisées. Slide 51 Urbanisation des SI Dans le milieu urbain cette organisation se fait au gré à gré par une régulation assez naturelle de la redondance. Un magasin s'établit dans un quartier bien achalandé et disparaît ou persiste en fonction de son essor. En revanche, l'implantation de certaines composantes à des échelons plus ou moins locaux est décidée au niveau de structures centrales (crèches, centres commerciaux, parkings, centrales électriques, etc.).
  • 52. Plan stratégique et plan d’urbanisme ● POSI: Plan d’organisation du SI ○ Équivalent du POS (Plan d’occupation du sol) dans le milieu urbain ○ Définit les grandes orientations du SI et les directions majeures de son évolution ○ Doit porter : ■ Sur les aspects structurels (urbanisme): principes de découpage et identification des blocs, sans descendre en dessous du niveau de la zone ■ Sur les aspects dynamiques (urbanisation): règles d’organisation statuant sur les degrés de liberté associés aux futures constructions ● Plan d’urbanisme et d’urbanisation ○ Déclinaison opérationnelle du POSI ○ Traduisent l’aspect pratique des possibilités d’aménagement du SI ○ Déclinent les orientations du POSI de manière pratique restituée dans une cartographie Slide 52 Urbanisation des SI
  • 53. Cartographie d’un Système d’Information ● Représentation du système d’information (SI) d’une organisation ainsi que ses connexions avec l’extérieur ● Peut être plus ou moins détaillée et inclure, par exemple, les biens matériels, logiciels, les réseaux de connexion, mais aussi les informations, activités et processus qui reposent sur ces biens ● Doit permettre de: ○ réaliser l’inventaire patrimonial du système d’information, à savoir la liste des composants du SI et leur description détaillée; ○ présenter le système d’information sous forme de vues (représentations partielles du SI), de ses liens et de son fonctionnement. Elles visent à rendre lisibles et compréhensibles différents aspects du système d’information. Slide 53 Urbanisation des SI
  • 54. Cartographie d’un SI : Composition ● Vision métier ○ Vue de l’écosystème: entités ou systèmes avec lesquels le SI interagit ○ Vue métier: processus et informations principales, valeurs métiers ● Vision applicative ○ Vue des applications: composants logiciels du SI, services offerts et flux de données entre eux ○ Vue de l’administration: périmètres et niveaux de privilèges des utilisateurs et administrateurs. ● Vision infrastructure ○ Vue des infrastructures logiques: cloisonnement logique des réseaux, notamment par la définition des plages d’adresses IP, des VLAN et des fonctions de filtrage et routage ○ Vue des infrastructures physiques: équipements physiques qui composent le système d’information ou utilisés par celui-ci. Slide 54 Urbanisation des SI
  • 55. Notion de terrain Slide 55 Urbanisation des SI ● Prise en compte de la nature du sol avant la construction ● Considérer les préoccupations fonctionnelles, techniques, organisationnelles.. ● Terrain d’urbanisation: décomposition possible répondant à des niveaux de préoccupations différents
  • 57. Exemple de Cartographie Cartographie Applicative de l’INSAT Réalisée par Amira Ben Achour, GL5, promotion 2018 57
  • 58. - IBM Systems Group, IBM Certified Infrastructure Systems Architect, Mai 2004 - Alexander S. Gillis, Enterprise architecture (EA), Techtarget, 2020 - Badreddine Ladjemi, Cours d’urbanisation des SI, INSAT, 2017 - John A. Zachman, The Zachman Framework For Enterprise Architecture, 2003 - Steven Spewak and S. C. Hill (1992) Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology. Boston, QED Pub. Group. p. 1 - Lean IX, FEAF: le guide Ultime, consulté en Août 2022, https://www.leanix.net/fr/wiki/ea/feaf-federal-enterprise-architecture-framework - Wikipedia, Federal Enterprise Architecture, consultée en Août 2022, https://en.wikipedia.org/wiki/Federal_enterprise_architecture - Maache Salah, An experiment applying the enterprise architecture, case study: Algerian government agency. International Journal of Research in Management, Science and Technology, April 2016. - The Open Group, The TOGAF Standard, https://pubs.opengroup.org/togaf-standard/ , consulté Aout 2022 - DSCG: UE5 - Management des Systèmes d’Information, Architecture d’entreprise et Urbanisation des SI (Cours), inspiré de IN Management et gouvernance des SI - Carvalho-Lavoisier 2009, et de Le projet d’urbanisation du SI - C.Longépé 2009. - ANSSI, Cartographie du SI, https://www.mauricenavarro.com/ressources/cartographie-du-systeme-d-information/ Nov. 2018 - 58 Références