cours msi urbanisation-si

Management des SI Urbanisation des SI

1/20


Urbanisation des Systèmes d'information

DéfinitionsL’« urbanisme du système d’information » désigne la démarche qui consiste à définir un système d’information cible qui puisse s’adapter et anticiper les différents changements (stratégiques, organisationnels, juridiques…) touchant l’entreprise.

Le « plan d’urbanisme du système d’information » désigne l’agrégation de la définition du système d’information cible et des règles d’urbanisme avec la trajectoire à suivre pour atteindre ce système d’information cible.

L' « urbanisation » est la démarche qui consiste à rendre un système d’information plus apte à servir la stratégie de l’entreprise et à anticiper les changements dans l’environnement de l’entreprise.

L’« urbanisation du système d’information » désigne plus précisément la mise en œuvre du plan d’urbanisme du système d’information.

Le « processus d'urbanisation » correspond à l'ensemble des activités liées à l'urbanisme du SI. C'est un processus permanent dont la géométrie est variable : il doit s'adapter aux entreprises qui se l'approprient et il évolue dans le temps au fil de la maturité acquise.

La démarche d'urbanisme considère quatre niveaux de préoccupation : métier, fonctionnel, applicatif et technique. Le facteur-clé de succès est de considérer que, si ces quatre «univers» sont « parallèles », ils n'en sont pas moins liés : aligner le SI sur la stratégie et les besoins consiste à travailler sur les « passages» entre ces univers. En particulier, le niveau fonctionnel supporte l'abstraction nécessaire entre les besoins et les solutions : ce découplage permet de garantir la souplesse d'évolution des applications et la réutilisation de leurs composants. C'est là que réside la clé de l'agilité.

Le processus est organisé en cinq sous-ensembles :

• Pilotage : mettre en oeuvre le processus et le piloter ; porter les préoccupations de l'urbanisme du SI au niveau de l'arbitrage des projets de l'entreprise.

• Cadre d'urbanisme : poser les principes et règles fondamentaux d'urbanisme : définir les cibles fonctionnelles et/ou applicatives, le plan de migration vers la cible.

2/20


• Infrastructure fonctionnelle : structurer le SI sur la base d'un véritable socle de l'évolutivité maîtrisée et de la réutilisation : mettre sous contrôle et normaliser les référentiels de données et de services, les échanges inter-applicatifs ...

• Relations avec les projets : s'assurer que les règles d'urbanisme du SI sont prises en compte dès les études amont, et dans la mise en oeuvre des solutions applicatives.

• Support et communication : convaincre de l'intérêt de la démarche et en développer la pratique ; partager la connaissance du SI au travers des cartographies.

Facteurs de l'urbanisation

L’environnement concurrentiel des entreprisesL’environnement concurrentiel des entreprises

La stratégie de l’entreprise est de moins en moins stable dans le temps. L’entreprise doit pouvoir profiter des opportunités et doit « prioriser » les projets qui se multiplient.

Il n'est plus raisonnable d’envisager la construction d’un nouveau système d’information.

le changement est devenu la règle. Les entreprises doivent pouvoir réagir rapidement aux mouvements des marchés, à la versatilité des besoins des clients, aux évolutions des métiers des utilisateurs, à l’évolution des technologies…

la prévisibilité des changements extérieurs se réduit, dans un monde concurrentiel soumis notamment aux effets des modes, les stratégies de communication des différents acteurs rapprochent de plus en plus l’horizon des changements envisageables ;

l’horizon temporel des évolutions de l’entreprise est lui aussi raccourci : il est dorénavant difficile de faire une prévision et de la maintenir telle quelle sur du long terme.

le système d’information est devenu lui-même un élément concurrentiel dans la stratégie de la plupart des entreprises.

3/20


Urbanisme (in Management et Gouvernance des SI – Carvalho - Lavoisier 2009)

Ainsi, la notion d'architecture d'entreprise s'est-elle imposée, comme devant décrire la structure - pensée en tant que telle - du système d'information global d'une organisation, devant répondre à des objectifs globaux d'efficacité et d'alignement sur les processus et des objectifs «métiers », plutôt que de laisser le système d'information global s'auto-organiser de manière parfois accidentelle. Il s'agit donc d'assembler les diverses applications de l'entreprise en un ensemble structuré et efficace, en imposant des règles fonctionnelles (responsabilités) et techniques et en s'intéressant prioritairement aux interfaces. Ainsi les EAI et autres bus applicatifs sont-ils devenus les outils privilégiés de l'architecture d'entreprise.

Nous comprenons alors que les deux approches d'urbanisation des systèmes d'information et d'architecture d'entreprise convergent, car elles ont fondamentalement le même sujet : apporter une vison globale du système d'information de l'entreprise, s'appuyant sur les processus métiers et visant l'alignement entre les applications et les besoins métiers, tout en imposant des règles globales visant au bon fonctionnement du système dans son ensemble.

L'architecture d'entreprise met en évidence le rôle d'architecte global et propose une structure des applicatifs basée sur les processus métiers et les objectifs généraux de l'entreprise sans proposer de contraintes a priori.

L'urbanisme propose un ensemble de règles s'imposant à tout ou partie du système d'information, règles à respecter par les applications, dans le but d'obtenir un système d'information évolutif.

Les concepts de l'urbanisme des SI

Rappel de l'historique de l'urbanisme Rappel de l'historique de l'urbanisme

L'origine des approches d'urbanisation du SI, bien que relativement imprécise nous apparaît comme étant essentiellement issue du monde industriel. Cependant, l'idée initiale consistant à traiter l'évolution du SI par analogie avec la façon dont est organisé l'aménagement du territoire en général et celui du milieu urbain en particulier, est trop marquée par l'absence d'écrits pour que l'attribution à un auteur précis ne soit une opération assez hasardeuse ; le plus probable étant néanmoins Jacques Sassoon.

Origine dans le secteur bancaire Origine dans le secteur bancaire L'origine la plus probable est que la notion d'urbanisme des systèmes d'information soit née en France dans le milieu des les années 1980 dans le secteur bancaire. Les responsables d'exploitation constataient la difficulté d'optimiser - ou même d'utiliser au mieux - les machines de traitement de l'information, pour faire tourner les travaux batch - en général de gros volumes et des contraintes fonctionnelles fortes - conçues par les chefs de projet - le terme architecte n'était pas encore utilisé.

En effet, le chef de projet concevait ses travaux batch en fonction des fichiers et des informations dont il avait besoin - provenant d'applications connexes, tout en appliquant des contraintes d'intégrité imposant des règles de successions entre les diverses applications/travaux ; il faisait réaliser des programmes spécifiques d'extractions de fichiers des applications connexes pour ses besoins propres.

L'exploitant était alors coincé dans un jeu de contrainte, imposées par les concepteurs, et était dans l'incapacité, par exemple, de faire tenir les traitements dans la nuit -le TP devait s'ouvrir le lendemain à 8h30 - ni d'optimiser l'utilisation de la machine (mémoire, CPU) car il ne pouvait pas suffisamment paralléliser les travaux. En effet, les concepteurs prenaient en compte les contraintes fonctionnelles - provenant des utilisateurs et du métier, mais ne prenaient que très peu en compte les contraintes de l'exploitant, ne serait-ce que par absence d'une vision globale des travaux concurrents.

La solution qui a été trouvée fut d'imposer au concepteur des règles globales, l'obligeant à tenir compte des contraintes techniques et d'exploitation. Ces règles sont maintenant bien connues : asynchronisme des traitements (rendre les traitements indépendants permet de les traiter, si nécessaire, en parallèle), unicité des interfaces - on réalise un seul programme d'extraction pour ne pas multiplier les interfaces, chaque programme utilisateur ne prenant en compte que les informations qui l'intéressent. Il s'agit donc d'imposer à chaque projet des règles globales relatives principalement aux interfaces et aux flux, de la même manière que dans une cité l'urbaniste impose des règles globales aux différents architectes au travers d'un plan d'occupation des sols ; en termes de flux (alimentation électrique, égouts, alimentation en eaux, une zone industrielle n'a pas les mêmes besoins qu'une zone d'habitation). De cette analogie est née la notion d'urbanisme des systèmes d'information.

4/20


Les concepts fondateurs : une analogie avec le monde deLes concepts fondateurs : une analogie avec le monde de l'environnement l'environnement

L'urbanisme des SI repose pour sa partie la plus visible sur un nombre volontairement réduit de concepts visant à limiter sa complexité. En premier lieu, il s'agit de procéder à un découpage du SI en conglomérats hiérarchisés (blocs) que sont : les zones, quartiers, blocs ou îlots. L'idée maîtresse de ce découpage est qu'il doit obéir à un POS (plan d'occupation des sols) se posant comme le garant des enjeux liés à l'urbanisation. Les activités entre différents quartiers sont mis en correspondance, conformément au POS et aux règles d'urbanisme par un gestionnaire de flux. Dans les approches existantes et formalisées le POS est donc essentiellement une formalisation graphique de l'organisation des blocs/îlots en quartiers, des quartiers en zones et de l'agencement des quartiers entre eux (flux). Le POS est perçu comme est un modèle logique en se sens qu'il ne tient pas compte de l'organisation spatiale de l'entreprise. Les concepts fondateurs qu'il concerne sont présentés ci-après :

• zone : l'urbanisme définit une zone d'aménagement comme étant « une zone d'affectation du sol selon l'usage qui y sera autorisé et la nature des activités dominantes ». Sassoon s'est appuyé sur cette analogie pour définir la notion de zone du SI comme étant représentative des différents niveaux de celui-ci, lesquels correspondent aux préoccupations de temps et de métiers de l'entreprise. La notion de zone permet la classification des quartiers selon la nature de leur mission.

• quartier : vu comme une entité assurant une production qui contribue à la mission de l'entreprise, le quartier rassemble les différents types d'opérations ou processus homogènes à l'intérieur d'un métier ou d'une activité. Ces traitements portent par conséquent sur une nature d'information. Pour assurer l'enchaînement de traitements de nature homogène, le quartier s'appuie sur les blocs ou îlots qui le composent. Pour ce faire il invoque principalement les services de ses îlots ; ce qui peut être vu à la fois comme une règle générale d'urbanisme, une propriété de fait du quartier et un critère pour répartir les îlots sur les quartiers ;

• îlot : la terminologie de l'urbanisme parle d'îlots pour désigner les blocs finaux et par essence indécomposables que définit le pas. Pour Sassoon un bloc est un ensemble de données et de traitements homogènes dans une activité. Il est composé de traitements qui portent sur un seul niveau d'agrégation de l'information. Dans les approches fortement connotées objet comme ITEOR-Urbanisation, un îlot est un composant métier (de manière marginale, il peut être technique) et possède de ce fait une mission de service. Il offre un ensemble de services (qui peuvent du point de vue objet être considérés comme des méthodes) autour d'un thème dont il est responsable pour tout le SI. Les services sont mis à disposition des autres composants (métier ou techniques) du système d'information via le gestionnaire de flux ;

• le ou les gestionnaire(s) de flux. Une fois le découpage du SI réalisé, il s'agit de permettre la communication entre les différents blocs. Dans le milieu urbain il s'agit de mettre en place les axes de communication, la voirie, les réseaux d'égout, etc. Dans le SI c'est le rôle du gestionnaire de flux qui assure ces échanges, sur la base d'un format standardisé. La responsabilité des échanges est transparente pour les applications ;

• règles d'urbanisme : les concepts énoncés précédemment sont issus de règles générales d'urbanisme qui président notamment le découpage en zones, quartiers, blocs ou îlots. Ces règles renvoient à la définition d'un ensemble de propriétés conférant leur structure à ces blocs et permettant d'aborder leur identification, auxquelles peuvent s'en ajouter d'autres, qui sont générales au système d'information ou plus spécifiques à certaines zones. Ce sont des règles relatives à l'état de l'art et aux meilleures pratiques - par exemple, il est interdit d'accéder directement aux données d'un quartier sans passer par un service d'accès - ou des règles plus propres à l'entreprise et relatives aux normes à appliquer ou aux techniques et logiciels à mettre en œuvre. Parfois, on observe que les règles d'urbanisme s'appliquent à l'organisation et au processus de développement.

5/20


Révision et extension des concepts Révision et extension des concepts

En partie en réponse aux limites existantes des concepts manipulés par l'urbanisation, il est utile d'actualiser les concepts traditionnellement manipulés par l'urbanisme...et de préciser la terminologie utilisée en explicitant et affinant le sens attaché à des notions rencontrées dans de nombreuses approches existantes.

Des plans stratégiques et des plans opérationnels

L'organisation de l'urbanisme doit être décrite à plusieurs niveaux. Ces différents niveaux sont ceux nécessaires à imprimer des directions d'évolution et décliner leur mise en œuvre de façon pratique à des niveaux de détail différents. Pour cela, il s'agit de signifier les orientations stratégiques et leur pendant opérationnel, dans des plans adaptés que sont le POSI et le plan d'urbanisme.

Le plan d'organisation du SI (POSI) : les grandes orientations du SI

Le POSI est l'équivalent du POS dans le milieu urbain. Elaboré sur un principe de long terme (même si cet aspect est relatif dans le contexte informatique), il situe les grandes orientations pour l'organisation du SI et les directions majeures de son évolution. Ces orientations reflètent celles de la stratégie de l'entreprise. Le POSI s'articule en plusieurs volets, qui doivent faire apparaître :

• sur les aspects structurels (urbanisme), les principes de découpage qui seront les fondamentaux du SI. Il s'agit en particulier des terrains de représentation du SI et de l'identification des grands blocs ou grandes division du SI. Sur ce dernier point, il n'est guère souhaitable de descendre en dessous du niveau de la zone, sauf pour souligner l'intérêt de mise en place d'un quartier ou îlot ayant un rôle très particulier.

• sur les aspects dynamiques (urbanisation), les règles d'organisation qui doivent être considérées comme des axiomes organisationnels. Ces règles statuent sur les degrés de liberté qui seront associés aux futures constructions.

Plan d'urbanisme et d'urbanisation

Les plans d'urbanisme et d'urbanisation sont une déclinaison opérationnelle du POSI. Ils traduisent l'aspect pratique des possibilités d'aménagement du SI et affinent son découpage en appliquant un style qui se veut en adéquation avec le POSI. Ces plans déclinent donc les orientations du POSI de manière pratique qu'ils restituent dans une cartographie faisant apparaître le SI ciblé par le plan d'urbanisme. Son contenu vise donc notamment les aspects suivants :

• approfondir les découpages du POSI au niveau des blocs... ;

• préciser l'assignation du style en mettant en évidence toutes les propriétés qui le définissent ;

6/20


• décrire la cible finale et les éventuelles cibles intermédiaires formalisées dans une cartographie qui situent les différents blocs et leur relations.

Les cartographies cibles qui apparaissent dans le plan d'urbanisme sont élaborées en se basant sur le plan d'urbanisation (aspect dynamique) qui fait apparaître deux volets principaux.

Avec la combinaison du POSI et du plan d'urbanisme, le SI dispose donc de cibles organisationnelles à différents niveaux de maille et différentes périodes de temps qui déterminent son cadre général d'évolution. Cependant ces cibles, si elles sont fixées dans leurs grandes lignes, ne sont pas totalement statiques. Elles sont mises à jour au gré des événements dans le cadre de structures qui permettent précisément de corréler leur évolution aux variations de l'environnement en procédant aux ajustements nécessaires. Ce mécanisme est traité au niveau de la méthodologie calquée sur la théorie de l'urbanisation et s'appuie notamment sur les éléments fournis par la fonction de veille et de suivi de l'urbanisation.

Les blocs

Le principe de découpage du SI en blocs est intimement lié à la notion même d'urbanisation. Ce découpage entend aboutir à une modularité des composantes du SI telle que les blocs puissent être suffisamment indépendants pour permettre une évolution disjointe. La hiérarchisation de ces blocs et leur encapsulation successive permet d'associer des propriétés différentes à chaque niveau hiérarchique. Elle permet de masquer à chaque niveau les évolutions internes à un niveau inférieur et également de circonscrire le périmètre des évolutions à un périmètre donné du système, quel que soit son niveau.

Niveaux de décomposition des blocs, notion de hiérarchie

La hiérarchie des blocs est nécessaire pour disséquer la complexité du SI. Nous entendons que la possibilité qu'elle offre de rajouter des propriétés à chaque niveau de décomposition soit étendue sans se limiter forcément à une hiérarchisation à trois niveaux (îlot, quartier, zones) comme le proposent les approches les plus généreuses. Le découpage doit permettre de hiérarchiser ou encore de fixer le niveau de granularité ou d'encapsulation souhaitable en fonction de la taille/complexité du SI ou du niveau de finesse visé.

Pour affiner ce cadre général, nous fixerons toutefois les conventions suivantes, de façon à préciser davantage le sens et le niveau de granularité associés aux appellations jugées les plus récurrentes :

• l'îlot fixe la modularité minimale de l'urbanisme en modélisant l'espace de réalisation des opérations atomiques de l'urbanisme ;

• le quartier assemble les îlots selon des règles de cohérence destinées à prendre en compte les problématiques internes de l'entreprise lui permettant de produire les résultats qu'impliquent sa mission ;

• la zone répond à des objectifs similaires à ceux des quartiers, mais à un niveau de généralisation plus important, susceptible de transparaître à l'extérieur de l'entreprise et par conséquent davantage calqué sur l'organisation de l'environnement externe à l'entreprise (l'organisation de son secteur d'activité, la typologie des acteurs du marché, l'espace administratif et réglementaire, la dimension géographique, etc.) ;

• l'ensemble de ces constructions est tournée vers l'optimisation des résultats à produire mais également (et surtout) sur les préoccupations d'adaptation à l'évolution qui sont le propos de l'urbanisation.

Les niveaux supérieurs, lorsqu'ils sont définis (bassins, départements, etc.) généralisent davantage la notion de zone. Ceci de façon à pouvoir prendre en compte des aspects qui, bien que n'ayant pas un caractère strictement exceptionnel (dimension internationale, entreprises géantes multi-activité/métier,

Notion de fondations du bloc

Un bloc est généralement fondé sur :

• les données (fondements sémantique) ;

• les flux (il favorise dans ce cas le regroupement de composants/sous-blocs à partir des relations qu'ils entretiennent).

Granularité et périmètre du bloc Granularité et périmètre du bloc

Déterminer la limite du bloc est l'exercice le plus ardu. L'assignation de ses propriétés nécessite pourtant de lui attribuer son périmètre d'autonomie et ce faisant de se prononcer sur les données et

7/20


services qui seront dupliquées pour ce bloc et celles qui seront mutualisées (sollicitées par l'intermédiaire d'autres blocs). 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.).

Ce principe, transposé au SI montre bien l'intérêt autant que la nécessité d'un arbitrage global qui statue sur le degré d'autonomie et la granularité des blocs autant que sur la promotion de services mutualisés. L'essentiel est de ne pas mettre en péril la cohérence et le fonctionnement global du SI. Le recours à la mutualisation, s'il présente des intérêts indéniables (coûts, administration, standardisation, etc.) introduit une dépendance.

Nous voyons bien à quel point cet arbitrage est délicat et doit être contextuel.

C'est donc aux urbanistes et aux règles de l'art qu'ils peuvent déployer qu'il appartient de se prononcer en détail sur ces sujets.

Exemple inspiré du contexte hospitalier Exemple inspiré du contexte hospitalier

Dans le contexte de l'hôpital, sur le plan fonctionnel, les blocs s'articulent assez naturellement autour de métiers bien segmentés (administration, soins, services techniques, etc.) qui peuvent être vus comme autant de zones du SIH (système d'information hospitalier), ou en tout cas de blocs de haut niveau.

S'agissant de l'activité en rapport avec les soins, les fonctions exercées font appel à des compétences bien précises, d'ailleurs cloisonnées par des règles renvoyant à des habilitations ou des diplômes.

L'ensemble de ces fonctions peut être vu comme autant d'activités décomposables en opérations ou directement comme des opérations de niveau de granularité minimal.

En détaillant par exemple, l'activité d'examen, il est envisageable de la décomposer encore en sous activités ou opérations telles que : émission de la demande d'examen, la réalisation de l'examen, la transmission du résultat d'examen.

Ces fonctions sont articulées autour d'activités ou d'informations particulières : patient, réalisation des examens via un SGL (système de gestion de laboratoire), dispensation des soins infirmiers, prise de rendez-vous, etc. Elles identifient autant de blocs potentiels, dont chaque opération exercée par un même type d'acteur peut être assimilée à un îlot, regroupés ou non dans des quartiers. Au passage, il faut noter que, activités et opérations ne sont pas nécessairement informatisées. Ainsi par exemple, le diagnostic ou la prescription de médicaments n'est pas nécessairement effectuée par des logiciels mais repose sur la consultation de documents papiers.

Prendre en compte la nature du sol : notion de terrain

Au même titre que l'urbanisme du monde de l'environnement compose avec la nature du sol (par exemple pour éviter les constructions dans des secteurs inondables, se prémunir des tremblements de terre, tenir les riverains à l'écart des aéroports, etc.), l'urbanisme des SI doit prendre en compte la

8/20


spécificité des fondations du SI. La gestion de l'évolution du SI met en jeu de multiples contraintes qui reflètent différents niveaux de préoccupations.

Ces niveaux de préoccupation sont de plusieurs ordres : fonctionnel, technique, organisationnel, etc. et peuvent à leur tour être déclinés en plusieurs strates représentatives de niveaux de contraintes intermédiaires. Ils correspondent d'une certaine manière aux différents angles ou points de vue selon lesquels peut être examinée la problématique d'évolution du SI. Par exemple, la vision fonctionnelle s'appuie à un moment donné sur une vision applicative (les applications nécessaires à supporter les fonctions attendues), laquelle s'appuie sur une vision logicielle (les logiciels qui composent les applications), etc.

Le concept de terrain d'urbanisation sert à représenter chacune de ces visions.

Les terrains sont mutuellement structurants. Ils répondent à des niveaux de préoccupations différents et aspirent à évoluer de façon indépendante tout en maintenant la cohérence d'ensemble. Au regard des enjeux liés à la représentation du patrimoine informationnel, ils sont en outre autant de cartes du SI, montrant tour à tour, les infrastructures techniques, les fondements du métier, l'organisation de l'entreprise, etc.

Ajoutons que s'il semble clair que des terrains particuliers ont vocation à revenir d'un SI à l'autre : terrain technique, fonctionnel, métier, etc. Il ne semble pas utile de s'interdire qu'ils puissent, si cela est souhaitable, être réduits à un seul. Un terrain généraliste, peut par exemple contenir des blocs de haut niveau relatifs aux applications et d'autres relatifs aux services techniques. Ce terrain serait alors une représentation, sur le même plan, du terrain applicatif et du terrain technique. Inversement, les terrains récurrents d'une entreprise à l'autre n'ont pas vocation à être limitatifs. Dans certains cas, il peut être bienvenu d'y ajouter, un terrain organisationnel, stratégique, etc. de décomposer un terrain particulier ou d'adjoindre tout autre type de terrain susceptible de représenter un intérêt quelconque. Vus comme autant de cartes du SI, ils sont nécessaires pour orienter et guider les choix et les travaux d'évolution.

Exemple inspiré du contexte hospitalier Exemple inspiré du contexte hospitalier

Basée sur un échantillon de l'exemple précédent, ce schéma montre un type de décomposition envisageable pour le « quartier examen» sur chacun des terrains majeurs du SIH. Les fonctions de demande et de résultat d'examens sont réunies dans une application commune baptisée Sandra.

En revanche, divers systèmes de gestion de laboratoire (SGL) coexistent, en fonction de la nature des examens à réaliser ou tout simplement du fait de l'historique du SIH. Enfin sur le terrain technique, une approche qui semble intéressante, consisterait à calquer les différents quartiers sur une typologie des services techniques offerts par le SI, l'un d'eux étant celui dévolu au stockage des informations.

Relations entre blocs

Les différents blocs entretiennent, du fait de leur collaboration à l'échelle du SI, des liens, liaisons, plus ou moins étroits. Ces liaisons sont assez diversifiées : échanges d'informations de types variés, invocations de services, etc. ou plus simplement liens d'ordre organisationnel. La recherche d'une structure et de composantes adaptées à la gestion de ces liaisons fait clairement partie des vocations de l'urbanisme. Dans la plupart des cas, il est en effet intéressant de chercher à les normaliser, ne serait ce que pour mieux maîtriser leurs évolutions et mutualiser les infrastructures qui les supportent.

Pour désigner les liens entre les blocs dans toute leur variété nous avons choisi de parler de relations. Tout d'abord, notons qu'à travers la notion de relation, le propos n'est pas de chercher à tout prix à nommer différemment ce qui est usuellement assimilé à une notion de flux. Il faut reconnaître que la notion de flux est fortement connotée « communication ». La notion de flux dans le contexte traité nous a donc parut être empreinte d'une perception trop réductrice. Le propos délibéré est bien d'assigner au concept relation un périmètre plus large, couvrant la diversité des liens entre blocs. Ces

9/20


relations sont distinguées selon une typologie basée sur leurs propriétés fondamentales. Compte tenu de l'ambition qui leur est assigné, les principaux types de relations qu'il semble utile de distinguer sont donnés par le tableau suivant :

Type Description

SupportMatérialise la dépendance structurelle entre blocs. L'exemple le plus représentatif est celui d'un bloc applicatif ayant une relation avec un SGBD du SI. Ce type de relation est surtout constaté entre blocs de terrains différents

CommunicationEchange d'informations entre blocs pour la production de l'activité. Les sous-types de cette catégorie sont ceux nécessaires à qualifier le type ou la nature des échanges (synchrone/asynchrone, données/service, etc.)

RéférentielInvocation de services ou données normalisées dans le SI (annuaires de personnes ou de ressources, dictionnaires de données, nomenclatures, etc.)

AdministrationRelation nécessaire à la gestion du bloc en question (maintenance, exploitation, etc.)

Organisation Plutôt à caractère descriptif et destinée à montrer les autres dépendances

Des opérateurs de mesure de l'urbanisme Des opérateurs de mesure de l'urbanisme Disposer de moyens de mesure de l'aptitude du SI à traiter la problématique d'évolution est essentiel. Pour cela, il est nécessaire de dégager les facteurs qui influent sur l'aptitude du SI à évoluer et d'identifier les propriétés du SI à partir desquelles ils peuvent être dégagés. Ces facteurs sont autant de critères de mesure de l'urbanisme qui permettent de jauger la réponse aux enjeux de l'urbanisme et de disposer d'indicateurs susceptibles d'aider la prise de décision, comme de suivre la progression de l'organisation. Ils doivent traduire les aptitudes à un niveau local (par exemple d'un bloc) mais doivent également permettre de relativiser ces aptitudes locales à l'échelle de tout le SI.

Critère Description et possibilités de mesure

Niveau de précision atteint par l'urbanisme

Rend compte du degré d'analyse des principes d'urbanisation

Concentration et organisation des blocs

Met en évidence les surfaces sensibles du SI et illustre les éventuelles disparités dans le d :gré d'urbanisation

Capacité d'évolution interne d'un bloc

Examen des dépendances d'un bloc envers les autres blocs, au travers de ses relations et des propriétés qui l'attachent à son bloc ou terrain d'insertion

Impact des changements sur le reste du SI

Traduit la portée d'un bloc, ensemble des autres blocs pouvant être atteints par ce bloc

Degré de mutualisation standardMontre le niveau de mutualisation du SI. Examen de l'utilisation des structures collectives

Degré de couverture de l'urbanisation

Identification des «surfaces» du SI auxquelles sont appliqués les principes d'urbanisation. Permet notamment de relativiser le niveau de précision

La mise à disposition d'opérateurs d'évaluation de l'urbanisme peut laisser entendre que des moyens sont disponibles pour progresser vers des cibles supérieures en qualité et pour mettre en perspective la qualité de différents SI entre eux. Il est en effet tentant de chercher à identifier les valeurs idéales que doit retourner chacun des opérateurs pour assigner au SI une configuration optimale. En réalité, il est difficile de dégager une valeur absolue représentative de la qualité globale de l'urbanisme et de l'urbanisation.

Indice d'urbanisation (Urbanisation des SI et Gouvernance – Club Urba-EA – Dunod 2010)

L'indice d'urbanisation constitue un outil de gouvernance et de management du SI, qui permet, à partir d'une évaluation de la démarche d'urbanisation de tout le système d'information de l'entreprise ou d'une partie, de renforcer les quatre piliers de la gouvernance du SI : anticiper, décider, communiquer et suivre.

10/20


L'indice est constitué de mesures qualitatives et quantitatives réalisées sur sept axes d'analyse:

• connaître le SI existant et cible,

• gérer les référentiels de l'entreprise (données et services),

• fournir un cadre pour les évolutions du SI,

• accompagner les projets,

• maîtriser la complexité des flux d'échanges d'informations,

• piloter l'urbanisation du SI,

• communiquer sur l'urbanisme et développer les compétences.

Représenté sous forme graphique (de type radar), il peut combiner à la fois un état existant, des évolutions successives ou un état cible. Dans le cas d'organisations complexes (groupes, implantations internationales, SI multiples par branches ... ) il peut également être éclaté en domaines d'étude, et reconsolidé au niveau de l'entreprise.

Partant de l'analyse des résultats, on peut alors construire le plan de progrès nécessaire au développement et à l'appropriation de la démarche d'urbanisme dans l'organisation.

Axes

1 - Connaitre le SI existant et cible2 - Gérer les référentiels de l'entreprise (données et services)3 - Fournir uncadre pour l'évolution des SI4 - Accompagner les projets5 - Maitriser la complexité des flux d'échange d'informations6 - Piloter l'urbanisation du SI7 - Communiquer sur l'urbanisme et développer les compétences

11/20


12/20


Correspondance processus - indice d'urbanisation

13/20


exemplesexemples

Renault

Société Générale

14/20


LES RÈGLES D'URBANISME (C.Longépé -Le projet d'urbanisation du SI- Dunod 2009)

Les règles d'urbanisme peuvent être établies pour chacune des quatre visions de l'architecture d'entreprise. Nous en proposons pour les quatre visions du cadre de référence. Elles sont pour chacune déclinées en :

• règles d'urbanisme ;

• règles de bonnes pratiques.

Il est à noter que les règles de niveau architecture fonctionnelle sont les plus universelles. Les règles de niveau architecture applicative et surtout les règles de niveau architecture technique sont beaucoup plus sujettes à adaptation au sein de chaque entreprise ou organisme. Enfin, les règles d'urbanisme de niveau architecture applicative et/ou de niveau architecture technique sont des règles d'urbanisme valable pour l'ensemble du système d'information. Elles ne sauraient donc prétendre se subbstituer, notamment en termes d'exhaustivité, aux normes et standards d'architectures applicative et technique qui doivent exister dans chaque direction informatique et être appliqués pour la construction de chaque édifice.

Les règles d'urbanisme pour la modélisation de la stratégie (diagrammeLes règles d'urbanisme pour la modélisation de la stratégie (diagramme d'Ishikawa) d'Ishikawa)

Règle n° 1 : Un même objectif ne figure qu'une seule fois dans le diagramme.

Règle n° 2 : Lorsqu'un objectif est décliné en sous-objectifs, la liste des sous-objectifs doit être exhaustive pour atteindre l'objectif.

Règle n° 3 : Un objectif de niveau le plus fin doit pouvoir être associé à un ou plusieurs KPI (Key Performance Indicator, indicateur clé de performance) SMART (Simple, Mesurable, Ambitieux mais Réaliste et positionné dans le Temps).

Les règles de bonnes pratiques pour la modélisation de la stratégieLes règles de bonnes pratiques pour la modélisation de la stratégie Règles de bonnes pratiques pour le diagramme d'Ishikawa Règles de bonnes pratiques pour le diagramme d'Ishikawa

Règle n° 1 : Un objectif commence par un verbe.

Règle n° 2 : Le libellé d'un objectif ne comprend pas de « et » qui pourrait masquer deux objectifs.

Règles de bonnes pratiques pour le diagramme d'entreprise Règles de bonnes pratiques pour le diagramme d'entreprise

Règle n° 1 : Privilégier la clarté et la lisibilité à l'exhaustivité.

Règle n° 2 : Indiquer dans le commentaire associé au diagramme ceux des flux entre processus de premier niveau qui n'ont pas été indiqués sur le diagramme pour des raisons de lisibilité.

Les règles d'urbanisme pour l'architecture métier Les règles d'urbanisme pour l'architecture métier Règle n° 1 : Une activité d'un processus appartient à un et un seul SI. Une activité d'un processus ne peut donc faire appel aux services que d'un seul SI.

Règle n° 2 : Toute transformation des propriétés d'un objet résulte d'une activité, même si c'est simplement l'âge de l'objet qui change, comme dans le cas où l'on garderait un objet entre deux transactions liées à cet objet. Mais dans un diagramme normalisé, une activité ne peut concerner qu'un seul objet, même s'il peut s'agir d'un objet composé.

Règle n° 3 : Une activité élémentaire ne peut être interrompue, ce qui signifie qu'une fois qu'un acteur est affecté à une activité, il ne peut être réaffecté avant la fin d'exécution ou l'interruption de celle-ci pour fin anormale.

Règle n° 4 : La fin d'exécution d'une activité force la fin d'exécution simultanée de toutes les activités appartenant au périmètre d'impact de cet événement, qu'il s'agisse d'impacts indirects ou induits.

Règle n° 5 : Toutes les activités peuvent avoir une fin anormale, mais également des événements temporels ou d'abandon. Chacun de ces événements constitue un événement particulier.

Les règles de bonnes pratiques pour l'architecture métier Les règles de bonnes pratiques pour l'architecture métier

Règles de bonnes pratiques pour la cartographie des processus

Règle n° 1 : Les processus opérationnels, les processus de pilotage et les processus de support sont distingués.

15/20


Règles de bonnes pratiques pour les processus

Règle n° 1 : La décomposition des processus est limitée à trois niveaux. Par définition un sous-processus est un processus et doit donc satisfaire la définition d'un processus.

Règle n° 2 : Une étape du processus correspond à un type de transformation d'un objet exprimé comme son état.

Règle n° 3 : Toute fin d'activité génère un événement qui correspond au fait que la transformation est finie ou interrompue.

Règle n° 4 : L'occurrence d'un événement porte en elle la fin des transformations d'autres objets qui sont liés à l'objet principal.

Cela est vrai, soit parce qu'il y a de multiples représentations d'un même fait réel (impacts indirects), soit parce que les règles de gestion impliquent la réévaluation d'autres activités (impacts induits). Une activité, un objet ou un événement peut toutefois déclencher l'étape. Tous les autres impacts sont indirects ou induits par cet événement principal, puisque l'activité concerne de nombreux objets.

Règle n° 5 : Un événement peut activer de nombreux événements déclenchés, au moins un pour chaque objet concerné.

Règle n° 6 : Chaque déclenchement est associé à une décision qui peut commander une activité ou une autre encore.

Règle n° 7 : Une activité peut nécessiter un ou plusieurs déclenchements si des activités doivent ètre synchronisées.

Les règles d'urbanisme pour l'architecture fonctionnelle Les règles d'urbanisme pour l'architecture fonctionnelle

Règle n° 1 : Règle d'unicité des 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 donc 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).

Elle 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 îlot, quartier et zone ;

• mutualiser les services : un service public et un seul pour répondre à des besoins identiques formulés par des demandeurs différents appartenant le cas échéant à des blocs, quartiers ou zones distincts ; ceci traduit également le principe de réutilisation ;

• accroître la modularité ;

• réduire au strict minimum les impacts suite à l'évolution d'un îlot dont les services publics sont sollicités par une diversité de demandeurs et rendre plus aisée la détermination de la chaîne d'impacts ;

• faciliter la mise en oeuvre de maintenances évolutives.

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

Les prises sont seules habilitées à communiquer avec le gestionnaire de flux.

16/20


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.

Un des objectifs de l'urbanisme est la portabilité des îlots en respectant les règles d'autonomie et d'asynchronisme. Pour atteindre cet objectif, il est nécessaire d'avoir des structures de données alignées sur les îlots pour que l'ajout, le remplacement ou la suppression d'un îlot puisse se faire avec un minimum d'impacts sur le SI.

Les règles de bonnes pratiques pour l'architecture fonctionnelle Les règles de bonnes pratiques pour l'architecture fonctionnelle

Règle n° 1 : Toute architecture fonctionnelle comporte une zone échange (acquisiition/restitution) qui est en quelque sorte la prise du SI.

L'acquisition transforme des flux événement 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 de 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.

Il faut noter qu'il ne s'agit que d'une règle de bonne pratique, c'est-à-dire une recommandation. Les avis sur l'option qui consiste à isoler de tels gisements de données dans une zone dédiée et celle qui consiste à les loger dans les quartiers d'autres zones (donc non spécifiques) sont en effet partagés.

Il y a deux raisons principales qui poussent vers la solution recommandée dans cet ouvrage : cela facilite la progressivité de la migration des applications clientes d'un gisement de données à mettre en oeuvre et surtout renforce l'évolutivité et les possibilités de synergies entre systèmes d'information dans un contexte multi-SI.

Règle n° 3 : Toute architecture fonctionnelle comporte une zone 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.

La notion de référentiel de règles étant moins courante que celle de référentiel de données, il convient de la préciser. L'intérêt d'un référentiel de règles est d'extraire des règles métier du code des applications et de les stocker dans un référentiel.

C'est particulièrement utile pour les règles qui nécessitent à la fois un fort besoin de partage entre applications, de qualité et de cohérence.

Les règles stockées dans un référentiel de règles peuvent être modifiées sans changer le code des différentes applications qui doivent les utiliser, voire même sans arrêter ces applications.

Il ne s'agit pas d'isoler systématiquement toutes les règles métier dans un référentiel de règles mais c'est particulièrement pertinent lorsque :

• ces règles sont très importantes pour l'entreprise (fort besoin de qualité) j

• ces règles doivent être appliquées à l'identique par différentes applications (fort besoin de partage et de cohérence) j

• ces règles sont susceptibles d'être modifiées fréquemment et l'entreprise a besoin d'agilité.

Exemples de règles métier :

L'acompte à la réservation doit être> 10 % du prix total du voyage ou encore le solde du voyage doit être payé un mois avant le départ.

17/20


Si le tour-opérateur stocke ces règles dans un référentiel de règles, il peut alors décider soudainement que l'acompte à la réservation doit être> 20 % du prix total du voyage et que le solde doit être payé deux semaines avant le départ et cela sans changer aucune ligne de code.

Cet exemple illustre bien l'agilité que confère à l'entreprise un référentiel de règles.

Règle n° 4 : Toute architecture fonctionnelle comporte une zone pilotage unique.

Cette zone regroupe les blocs dédiés aux processus de gouvernance et d'analyse et utilisant des informations globalisées et historisées.

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

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 donc 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. Par exemple, le système d'information d'une compagnie exerçant dans le domaine de l'assurance lARD (incendie, accident, risques divers), de l'assurance-vie et de la banque comportera une zone opération lARD, une zone opération Vie et une zone opération Banque.

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

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

Les règles d'urbanisme pour l'architecture applicative Les règles d'urbanisme pour l'architecture applicative

Règle n° 1 : Les données des gisements de données doivent étre historisées.

Les données partagées doivent être historisées afin de permettre de « rejouer » si nécessaire un processus et de garantir la cohérence du contenu et la bonne fin.

Règle n° 2 : Les données des gisements de données doivent être accompagnées d'une date de publication de mise à jour.

Les données des gisements de données doivent être accompagnées d'une date de publication de mise à jour de sorte que les anciennes valeurs ne soient pas perdues et que l'on puisse retrouver leur valeur à un instant passé. Les très anciennes valeurs peuvent être déportées dans des modules de gestion de données archivées.

Règle n° 3 : Les données des référentiels de données doivent être accompagnées d'une date de publication de mise à jour (comme les données des gisements de données) mais aussi d'une date d'èffet.

Afin de permettre le versionnement temporel, les données des référentiels de gisements de données doivent être accompagnées :

• d'une date de publication de mise à jour de sorte que les anciennes valeurs ne soient pas perdues et que l'on puisse retrouver leur valeur à un instant passé. Les très anciennes valeurs peuvent être déportées dans des modules de gestion de données archivées j

• d'une date d'effet.

Règle n° 4 : Duplication des données.

Au sein d'un bloc, les données peuvent être dupliquées entre les données de contexte et les données des gisements de données car cela correspond à deux niveaux de partage et de cycle de vie bien différents. En effet, les données sont isolées et temporaires pour le contexte alors qu'elles sont partagées et permanentes pour les gisements de données. Le niveau gisement de données doit rester maître. La synchronisation au sein d'un bloc se fait par publication du contexte en respectant la règle d'intégrité des gisements de données (règle d'urbanisme pour l'architecture technique).

Règle n° 5 : Le bloc offrant un service est le responsable de la qualité du service.

C'est le bloc qui offre un service qui doit s'assurer qu'il offre la meilleure qualité de service y compris la continuité de service.

18/20


Les règles de bonnes pratiques pour l'architecture applicative Les règles de bonnes pratiques pour l'architecture applicative

Règle n° 1 : Toute architecture applicative comporte une zone ordonnancement qui assure l'interface entre front office, bock office et middle office.

Plus précisément cette zone assure :

• la traduction, l'ordonnancement et le pilotage des demandes du FO. Une demande de service émanant du FO est traduite en un ensemble de services appelés dans un certain ordre au niveau des MO et BO ;

• le pilotage des processus internes au SI ;

• la gestion des priorités.

Les règles d'urbanisme pour l'architecture technique Les règles d'urbanisme pour l'architecture technique Règle n° 1 : Décomposition des blocs applicatifs en couches. Tout bloc applicatif donne lieu à n paquetages, n étant le nombre de couches de l'architecture technique logique le concernant. Les n paquetages utiles à la décomposition d'un bloc applicatif en couches d'architecture (les n couches ne sont pas utiles pour tous les blocs applicatifs) ne sont pas regroupés différemment.

Règle n° 2 : Intégrité transactionnelle des flux sensibles.

Afin d'assurer l'intégrité transactionnelle des flux sensibles (c'est-à-dire engageant financièrement et/ou légalement la société), la communication entre tous les systèmes concernés doit être synchrone durant la phase de stockage mise à jour des gisements de données. C'est d'ailleurs le seul cas où la communication synchrone est obligatoire.

Règle n° 3 : . Intégrité des gisements de données

Toute mise à jour des gisements de données et toute émission vers l'extérieur de flux critiques doivent respecter les principes suivants :

• isolation dans un contexte pendant la transaction ;

• atomicité (tout ou rien) de la mise à jour du contexte dans les données des gisements de données et dans l'émission des flux ;

• cohérence à tout moment des gisements de données ;

• caractère durable (non réversible automatiquement) de la publication si elle réussit.

Règle n° 4 : Concurrence batch / TP.

Les batchs doivent être construits pour s'exécuter de manière concurrente aux processus TP sous le contrôle des transactions avec respect de la règle d'intégrité des gisements de données.

Règle n° 5 : Source unique.

Les composants logiciels qui ne nécessitent pas de variante pour des raisons liées à leur catégorie ne doivent être écrits qu'une seule fois. La possibilité ou l'obligation de les implémenter sur des plates-formes technologiques différentes ne justifie nullement une multiplicité des sources.

Les règles de bonnes pratiques pour l'architecture technique Les règles de bonnes pratiques pour l'architecture technique

Règle n° 1 : Centralisation des gisements de données.

Les gisements de données doivent être centralisés, c'est-à-dire se trouver sur une plate-forme centrale, sécurisée, accessible depuis toute autre plate-forme.

Règle n° 2 : Recommandation de non-duplication. On ne recourt à la duplication que lorsqu'il y a des contraintes impératives (performance, sécurité, charge réseau, exploitabilité, etc.). On appelle dans la mesure du possible le composant original.

19/20


Métamodèle de cartographie applicative

Ce métamodèle considère les points suivants :

• une application ou un référentiel sont des composants informatiques ;

• un composant informatique appartient à un domaine fonctionnel (une zone si celle-ci ne se décompose pas en blocs, un bloc si celui-ci ne se décompose pas en quartier, sinon un quartier) ;

• une zone, un bloc ou un quartier sont des domaines fonctionnels, une zone se compose éventuellement de blocs, un bloc éventuellement de quartiers ;

• un composant informatique peut se décomposer en un ensemble de sous- composants ;

• une application outille ou non une ou plusieurs opérations (une opération peut être outillée ou non par une ou plusieurs applications) ;

• un composant informatique a des flux entrant et sortant qui sont l'implémentation de messages (donc décrits par des formats d'échange).

20/20

cours msi urbanisation-si

Documents