Management des SI

Urbanisation des SI

1/20

Management des SI

Urbanisation des SI

Urbanisation des Systmes d'information

Dfinitions
L urbanisme du systme dinformation dsigne la dmarche qui consiste dfinir un systme dinformation cible qui puisse sadapter et anticiper les diffrents changements (stratgiques, organisationnels, juridiques) touchant lentreprise. Le plan durbanisme du systme dinformation dsigne lagrgation de la dfinition du systme dinformation cible et des rgles durbanisme avec la trajectoire suivre pour atteindre ce systme dinformation cible. L' urbanisation est la dmarche qui consiste rendre un systme dinformation plus apte servir la stratgie de lentreprise et anticiper les changements dans lenvironnement de lentreprise. L urbanisation du systme dinformation dsigne plus prcisment la mise en uvre du plan durbanisme du systme dinformation. Le processus d'urbanisation correspond l'ensemble des activits lies l'urbanisme du SI. C'est un processus permanent dont la gomtrie 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 dmarche d'urbanisme considre quatre niveaux de proccupation : mtier, fonctionnel, applicatif et technique. Le facteur-cl de succs est de considrer que, si ces quatre univers sont parallles , ils n'en sont pas moins lis : aligner le SI sur la stratgie et les besoins consiste travailler sur les passages entre ces univers. En particulier, le niveau fonctionnel supporte l'abstraction ncessaire entre les besoins et les solutions : ce dcouplage permet de garantir la souplesse d'volution des applications et la rutilisation de leurs composants. C'est l que rside la cl de l'agilit.

Le processus est organis en cinq sous-ensembles : Pilotage : mettre en oeuvre le processus et le piloter ; porter les proccupations de l'urbanisme du SI au niveau de l'arbitrage des projets de l'entreprise. Cadre d'urbanisme : poser les principes et rgles fondamentaux d'urbanisme : dfinir les cibles fonctionnelles et/ou applicatives, le plan de migration vers la cible.

2/20

Management des SI

Urbanisation des SI

Infrastructure fonctionnelle : structurer le SI sur la base d'un vritable socle de l'volutivit matrise et de la rutilisation : mettre sous contrle et normaliser les rfrentiels de donnes et de services, les changes inter-applicatifs ...

Relations avec les projets : s'assurer que les rgles d'urbanisme du SI sont prises en compte ds les tudes amont, et dans la mise en oeuvre des solutions applicatives. Support et communication : convaincre de l'intrt de la dmarche et en dvelopper la pratique ; partager la connaissance du SI au travers des cartographies.

Facteurs de l'urbanisation
Lenvironnement concurrentiel des entreprises
La stratgie de lentreprise est de moins en moins stable dans le temps. Lentreprise doit pouvoir profiter des opportunits et doit prioriser les projets qui se multiplient. Il n'est plus raisonnable denvisager la construction dun nouveau systme dinformation. le changement est devenu la rgle . Les entreprises doivent pouvoir ragir rapidement aux mouvements des marchs, la versatilit des besoins des clients, aux volutions des mtiers des utilisateurs, lvolution des technologies la prvisibilit des changements extrieurs se rduit , dans un monde concurrentiel soumis notamment aux effets des modes, les stratgies de communication des diffrents acteurs rapprochent de plus en plus lhorizon des changements envisageables ; lhorizon temporel des volutions de lentreprise est lui aussi raccourci : il est dornavant difficile de faire une prvision et de la maintenir telle quelle sur du long terme. le systme dinformation est devenu lui-mme un lment concurrentiel dans la stratgie de la plupart des entreprises.

3/20

Management des SI

Urbanisation des SI

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

Ainsi, la notion d'architecture d'entreprise s'est-elle impose, comme devant dcrire la structure pense en tant que telle - du systme d'information global d'une organisation, devant rpondre des objectifs globaux d'efficacit et d'alignement sur les processus et des objectifs mtiers , plutt que de laisser le systme d'information global s'auto-organiser de manire parfois accidentelle. Il s'agit donc d'assembler les diverses applications de l'entreprise en un ensemble structur et efficace, en imposant des rgles fonctionnelles (responsabilits) et techniques et en s'intressant prioritairement aux interfaces. Ainsi les EAI et autres bus applicatifs sont-ils devenus les outils privilgis de l'architecture d'entreprise. Nous comprenons alors que les deux approches d'urbanisation des systmes d'information et d'architecture d'entreprise convergent, car elles ont fondamentalement le mme sujet : apporter une vison globale du systme d'information de l'entreprise, s'appuyant sur les processus mtiers et visant l'alignement entre les applications et les besoins mtiers, tout en imposant des rgles globales visant au bon fonctionnement du systme dans son ensemble. L'architecture d'entreprise met en vidence le rle d'architecte global et propose une structure des applicatifs base sur les processus mtiers et les objectifs gnraux de l'entreprise sans proposer de contraintes a priori. L'urbanisme propose un ensemble de rgles s'imposant tout ou partie du systme d'information, rgles respecter par les applications, dans le but d'obtenir un systme d'information volutif.

Les concepts de l'urbanisme des SI

Rappel de l'historique de l'urbanisme
L'origine des approches d'urbanisation du SI, bien que relativement imprcise nous apparat comme tant essentiellement issue du monde industriel. Cependant, l'ide initiale consistant traiter l'volution du SI par analogie avec la faon dont est organis l'amnagement du territoire en gnral et celui du milieu urbain en particulier, est trop marque par l'absence d'crits pour que l'attribution un auteur prcis ne soit une opration assez hasardeuse ; le plus probable tant nanmoins Jacques Sassoon.

Origine dans le secteur bancaire

L'origine la plus probable est que la notion d'urbanisme des systmes d'information soit ne en France dans le milieu des les annes 1980 dans le secteur bancaire. Les responsables d'exploitation constataient la difficult d'optimiser - ou mme d'utiliser au mieux - les machines de traitement de l'information, pour faire tourner les travaux batch - en gnral de gros volumes et des contraintes fonctionnelles fortes - conues 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'intgrit imposant des rgles de successions entre les diverses applications/travaux ; il faisait raliser des programmes spcifiques d'extractions de fichiers des applications connexes pour ses besoins propres. L'exploitant tait alors coinc dans un jeu de contrainte, imposes 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 (mmoire, CPU) car il ne pouvait pas suffisamment parallliser les travaux. En effet, les concepteurs prenaient en compte les contraintes fonctionnelles provenant des utilisateurs et du mtier, mais ne prenaient que trs 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 trouve fut d'imposer au concepteur des rgles globales, l'obligeant tenir compte des contraintes techniques et d'exploitation. Ces rgles sont maintenant bien connues : asynchronisme des traitements (rendre les traitements indpendants permet de les traiter, si ncessaire, en parallle), unicit des interfaces - on ralise un seul programme d'extraction pour ne pas multiplier les interfaces, chaque programme utilisateur ne prenant en compte que les informations qui l'intressent. Il s'agit donc d'imposer chaque projet des rgles globales relatives principalement aux interfaces et aux flux, de la mme manire que dans une cit l'urbaniste impose des rgles globales aux diffrents 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 mmes besoins qu'une zone d'habitation). De cette analogie est ne la notion d'urbanisme des systmes d'information.

4/20

Management des SI

Urbanisation des SI

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

L'urbanisme des SI repose pour sa partie la plus visible sur un nombre volontairement rduit de concepts visant limiter sa complexit. En premier lieu, il s'agit de procder un dcoupage du SI en conglomrats hirarchiss (blocs) que sont : les zones, quartiers, blocs ou lots. L'ide matresse de ce dcoupage est qu'il doit obir un POS (plan d'occupation des sols) se posant comme le garant des enjeux lis l'urbanisation. Les activits entre diffrents quartiers sont mis en correspondance, conformment au POS et aux rgles d'urbanisme par un gestionnaire de flux. Dans les approches existantes et formalises 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 peru comme est un modle logique en se sens qu'il ne tient pas compte de l'organisation spatiale de l'entreprise. Les concepts fondateurs qu'il concerne sont prsents ciaprs : zone : l'urbanisme dfinit une zone d'amnagement comme tant une zone d'affectation du sol selon l'usage qui y sera autoris et la nature des activits dominantes . Sassoon s'est appuy sur cette analogie pour dfinir la notion de zone du SI comme tant reprsentative des diffrents niveaux de celui-ci, lesquels correspondent aux proccupations de temps et de mtiers 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 diffrents types d'oprations ou processus homognes l'intrieur d'un mtier ou d'une activit. Ces traitements portent par consquent sur une nature d'information. Pour assurer l'enchanement de traitements de nature homogne, 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 rgle gnrale d'urbanisme, une proprit de fait du quartier et un critre pour rpartir les lots sur les quartiers ; lot : la terminologie de l'urbanisme parle d'lots pour dsigner les blocs finaux et par essence indcomposables que dfinit le pas. Pour Sassoon un bloc est un ensemble de donnes et de traitements homognes dans une activit. Il est compos de traitements qui portent sur un seul niveau d'agrgation de l'information. Dans les approches fortement connotes objet comme ITEOR-Urbanisation, un lot est un composant mtier (de manire marginale, il peut tre technique) et possde de ce fait une mission de service. Il offre un ensemble de services (qui peuvent du point de vue objet tre considrs comme des mthodes) autour d'un thme dont il est responsable pour tout le SI. Les services sont mis disposition des autres composants (mtier ou techniques) du systme d'information via le gestionnaire de flux ; le ou les gestionnaire(s) de flux. Une fois le dcoupage du SI ralis, il s'agit de permettre la communication entre les diffrents blocs. Dans le milieu urbain il s'agit de mettre en place les axes de communication, la voirie, les rseaux d'gout, etc. Dans le SI c'est le rle du gestionnaire de flux qui assure ces changes, sur la base d'un format standardis. La responsabilit des changes est transparente pour les applications ; rgles d'urbanisme : les concepts noncs prcdemment sont issus de rgles gnrales d'urbanisme qui prsident notamment le dcoupage en zones, quartiers, blocs ou lots. Ces rgles renvoient la dfinition d'un ensemble de proprits confrant leur structure ces blocs et permettant d'aborder leur identification, auxquelles peuvent s'en ajouter d'autres, qui sont gnrales au systme d'information ou plus spcifiques certaines zones. Ce sont des rgles relatives l'tat de l'art et aux meilleures pratiques - par exemple, il est interdit d'accder directement aux donnes d'un quartier sans passer par un service d'accs - ou des rgles plus propres l'entreprise et relatives aux normes appliquer ou aux techniques et logiciels mettre en uvre. Parfois, on observe que les rgles d'urbanisme s'appliquent l'organisation et au processus de dveloppement.

5/20

Management des SI

Urbanisation des SI

Rvision et extension des concepts

En partie en rponse aux limites existantes des concepts manipuls par l'urbanisation, il est utile d'actualiser les concepts traditionnellement manipuls par l'urbanisme...et de prciser la terminologie utilise en explicitant et affinant le sens attach des notions rencontres dans de nombreuses approches existantes.

Des plans stratgiques et des plans oprationnels

L'organisation de l'urbanisme doit tre dcrite plusieurs niveaux. Ces diffrents niveaux sont ceux ncessaires imprimer des directions d'volution et dcliner leur mise en uvre de faon pratique des niveaux de dtail diffrents. Pour cela, il s'agit de signifier les orientations stratgiques et leur pendant oprationnel, dans des plans adapts 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 (mme 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 refltent celles de la stratgie de l'entreprise. Le POSI s'articule en plusieurs volets, qui doivent faire apparatre : sur les aspects structurels (urbanisme), les principes de dcoupage qui seront les fondamentaux du SI. Il s'agit en particulier des terrains de reprsentation du SI et de l'identification des grands blocs ou grandes division du SI. Sur ce dernier point, il n'est gure souhaitable de descendre en dessous du niveau de la zone, sauf pour souligner l'intrt de mise en place d'un quartier ou lot ayant un rle trs particulier. sur les aspects dynamiques (urbanisation), les rgles d'organisation qui doivent tre considres comme des axiomes organisationnels. Ces rgles statuent sur les degrs de libert qui seront associs aux futures constructions.

Plan d'urbanisme et d'urbanisation

Les plans d'urbanisme et d'urbanisation sont une dclinaison oprationnelle du POSI. Ils traduisent l'aspect pratique des possibilits d'amnagement du SI et affinent son dcoupage en appliquant un style qui se veut en adquation avec le POSI. Ces plans dclinent donc les orientations du POSI de manire pratique qu'ils restituent dans une cartographie faisant apparatre le SI cibl par le plan d'urbanisme. Son contenu vise donc notamment les aspects suivants : approfondir les dcoupages du POSI au niveau des blocs... ; prciser l'assignation du style en mettant en vidence toutes les proprits qui le dfinissent ;

6/20

Management des SI

Urbanisation des SI

dcrire la cible finale et les ventuelles cibles intermdiaires formalises dans une cartographie qui situent les diffrents blocs et leur relations.

Les cartographies cibles qui apparaissent dans le plan d'urbanisme sont labores en se basant sur le plan d'urbanisation (aspect dynamique) qui fait apparatre deux volets principaux. Avec la combinaison du POSI et du plan d'urbanisme, le SI dispose donc de cibles organisationnelles diffrents niveaux de maille et diffrentes priodes de temps qui dterminent son cadre gnral d'volution. Cependant ces cibles, si elles sont fixes dans leurs grandes lignes, ne sont pas totalement statiques. Elles sont mises jour au gr des vnements dans le cadre de structures qui permettent prcisment de corrler leur volution aux variations de l'environnement en procdant aux ajustements ncessaires. Ce mcanisme est trait au niveau de la mthodologie calque sur la thorie de l'urbanisation et s'appuie notamment sur les lments fournis par la fonction de veille et de suivi de l'urbanisation.

Les blocs
Le principe de dcoupage du SI en blocs est intimement li la notion mme d'urbanisation. Ce dcoupage entend aboutir une modularit des composantes du SI telle que les blocs puissent tre suffisamment indpendants pour permettre une volution disjointe. La hirarchisation de ces blocs et leur encapsulation successive permet d'associer des proprits diffrentes chaque niveau hirarchique. Elle permet de masquer chaque niveau les volutions internes un niveau infrieur et galement de circonscrire le primtre des volutions un primtre donn du systme, quel que soit son niveau.

Niveaux de dcomposition des blocs, notion de hirarchie

La hirarchie des blocs est ncessaire pour dissquer la complexit du SI. Nous entendons que la possibilit qu'elle offre de rajouter des proprits chaque niveau de dcomposition soit tendue sans se limiter forcment une hirarchisation trois niveaux (lot, quartier, zones) comme le proposent les approches les plus gnreuses. Le dcoupage doit permettre de hirarchiser 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 gnral, nous fixerons toutefois les conventions suivantes, de faon prciser davantage le sens et le niveau de granularit associs aux appellations juges les plus rcurrentes : l'lot fixe la modularit minimale de l'urbanisme en modlisant l'espace de ralisation des oprations atomiques de l'urbanisme ; le quartier assemble les lots selon des rgles de cohrence destines prendre en compte les problmatiques internes de l'entreprise lui permettant de produire les rsultats qu'impliquent sa mission ; la zone rpond des objectifs similaires ceux des quartiers, mais un niveau de gnralisation plus important, susceptible de transparatre l'extrieur de l'entreprise et par consquent 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 rglementaire, la dimension gographique, etc.) ; l'ensemble de ces constructions est tourne vers l'optimisation des rsultats produire mais galement (et surtout) sur les proccupations d'adaptation l'volution qui sont le propos de l'urbanisation.

Les niveaux suprieurs, lorsqu'ils sont dfinis (bassins, dpartements, etc.) gnralisent davantage la notion de zone. Ceci de faon pouvoir prendre en compte des aspects qui, bien que n'ayant pas un caractre strictement exceptionnel (dimension internationale, entreprises gantes multi-activit/mtier,

Notion de fondations du bloc

Un bloc est gnralement fond sur : les donnes (fondements smantique) ; les flux (il favorise dans ce cas le regroupement de composants/sous-blocs partir des relations qu'ils entretiennent).

Granularit et primtre du bloc

Dterminer la limite du bloc est l'exercice le plus ardu. L'assignation de ses proprits ncessite pourtant de lui attribuer son primtre d'autonomie et ce faisant de se prononcer sur les donnes et

7/20

Management des SI

Urbanisation des SI

services qui seront dupliques pour ce bloc et celles qui seront mutualises (sollicites par l'intermdiaire d'autres blocs). Dans le milieu urbain cette organisation se fait au gr gr par une rgulation assez naturelle de la redondance. Un magasin s'tablit dans un quartier bien achaland et disparat ou persiste en fonction de son essor. En revanche, l'implantation de certaines composantes des chelons plus ou moins locaux est dcide au niveau de structures centrales (crches, centres commerciaux, parkings, centrales lectriques, etc.). Ce principe, transpos au SI montre bien l'intrt autant que la ncessit d'un arbitrage global qui statue sur le degr d'autonomie et la granularit des blocs autant que sur la promotion de services mutualiss. L'essentiel est de ne pas mettre en pril la cohrence et le fonctionnement global du SI. Le recours la mutualisation, s'il prsente des intrts indniables (cots, administration, standardisation, etc.) introduit une dpendance. Nous voyons bien quel point cet arbitrage est dlicat et doit tre contextuel. C'est donc aux urbanistes et aux rgles de l'art qu'ils peuvent dployer qu'il appartient de se prononcer en dtail sur ces sujets. Exemple inspir du contexte hospitalier Dans le contexte de l'hpital, sur le plan fonctionnel, les blocs s'articulent assez naturellement autour de mtiers bien segments (administration, soins, services techniques, etc.) qui peuvent tre vus comme autant de zones du SIH (systme d'information hospitalier), ou en tout cas de blocs de haut niveau.

S'agissant de l'activit en rapport avec les soins, les fonctions exerces font appel des comptences bien prcises, d'ailleurs cloisonnes par des rgles renvoyant des habilitations ou des diplmes. L'ensemble de ces fonctions peut tre vu comme autant d'activits dcomposables en oprations ou directement comme des oprations de niveau de granularit minimal. En dtaillant par exemple, l'activit d'examen, il est envisageable de la dcomposer encore en sous activits ou oprations telles que : mission de la demande d'examen, la ralisation de l'examen, la transmission du rsultat d'examen. Ces fonctions sont articules autour d'activits ou d'informations particulires : patient, ralisation des examens via un SGL (systme de gestion de laboratoire), dispensation des soins infirmiers, prise de rendez-vous, etc. Elles identifient autant de blocs potentiels, dont chaque opration exerce par un mme type d'acteur peut tre assimile un lot, regroups ou non dans des quartiers. Au passage, il faut noter que, activits et oprations ne sont pas ncessairement informatises. Ainsi par exemple, le diagnostic ou la prescription de mdicaments n'est pas ncessairement effectue par des logiciels mais repose sur la consultation de documents papiers.

Prendre en compte la nature du sol : notion de terrain

Au mme 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 prmunir des tremblements de terre, tenir les riverains l'cart des aroports, etc.), l'urbanisme des SI doit prendre en compte la

8/20

Management des SI

Urbanisation des SI

spcificit des fondations du SI. La gestion de l'volution du SI met en jeu de multiples contraintes qui refltent diffrents niveaux de proccupations. Ces niveaux de proccupation sont de plusieurs ordres : fonctionnel, technique, organisationnel, etc. et peuvent leur tour tre dclins en plusieurs strates reprsentatives de niveaux de contraintes intermdiaires. Ils correspondent d'une certaine manire aux diffrents angles ou points de vue selon lesquels peut tre examine la problmatique d'volution du SI. Par exemple, la vision fonctionnelle s'appuie un moment donn sur une vision applicative (les applications ncessaires 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 reprsenter chacune de ces visions. Les terrains sont mutuellement structurants. Ils rpondent des niveaux de proccupations diffrents et aspirent voluer de faon indpendante tout en maintenant la cohrence d'ensemble. Au regard des enjeux lis la reprsentation du patrimoine informationnel, ils sont en outre autant de cartes du SI, montrant tour tour, les infrastructures techniques, les fondements du mtier, 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, mtier, etc. Il ne semble pas utile de s'interdire qu'ils puissent, si cela est souhaitable, tre rduits un seul. Un terrain gnraliste, peut par exemple contenir des blocs de haut niveau relatifs aux applications et d'autres relatifs aux services techniques. Ce terrain serait alors une reprsentation, sur le mme plan, du terrain applicatif et du terrain technique. Inversement, les terrains rcurrents d'une entreprise l'autre n'ont pas vocation tre limitatifs. Dans certains cas, il peut tre bienvenu d'y ajouter, un terrain organisationnel, stratgique, etc. de dcomposer un terrain particulier ou d'adjoindre tout autre type de terrain susceptible de reprsenter un intrt quelconque. Vus comme autant de cartes du SI, ils sont ncessaires pour orienter et guider les choix et les travaux d'volution. Exemple inspir du contexte hospitalier

Base sur un chantillon de l'exemple prcdent, ce schma montre un type de dcomposition envisageable pour le quartier examen sur chacun des terrains majeurs du SIH. Les fonctions de demande et de rsultat d'examens sont runies dans une application commune baptise Sandra. En revanche, divers systmes de gestion de laboratoire (SGL) coexistent, en fonction de la nature des examens raliser ou tout simplement du fait de l'historique du SIH. Enfin sur le terrain technique, une approche qui semble intressante, consisterait calquer les diffrents quartiers sur une typologie des services techniques offerts par le SI, l'un d'eux tant celui dvolu au stockage des informations.

Relations entre blocs

Les diffrents blocs entretiennent, du fait de leur collaboration l'chelle du SI, des liens, liaisons, plus ou moins troits. Ces liaisons sont assez diversifies : changes d'informations de types varis, invocations de services, etc. ou plus simplement liens d'ordre organisationnel. La recherche d'une structure et de composantes adaptes la gestion de ces liaisons fait clairement partie des vocations de l'urbanisme. Dans la plupart des cas, il est en effet intressant de chercher les normaliser, ne serait ce que pour mieux matriser leurs volutions et mutualiser les infrastructures qui les supportent. Pour dsigner les liens entre les blocs dans toute leur varit 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 diffremment ce qui est usuellement assimil une notion de flux. Il faut reconnatre que la notion de flux est fortement connote communication . La notion de flux dans le contexte trait nous a donc parut tre empreinte d'une perception trop rductrice. Le propos dlibr est bien d'assigner au concept relation un primtre plus large, couvrant la diversit des liens entre blocs. Ces
9/20

Management des SI

Urbanisation des SI

relations sont distingues selon une typologie base sur leurs proprits fondamentales. Compte tenu de l'ambition qui leur est assign, les principaux types de relations qu'il semble utile de distinguer sont donns par le tableau suivant : Type Support Description Matrialise la dpendance structurelle entre blocs. L'exemple le plus reprsentatif 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 diffrents Echange d'informations entre blocs pour la production de l'activit. Les sous-types de cette catgorie sont ceux ncessaires qualifier le type ou la nature des changes (synchrone/asynchrone, donnes/service, etc.) Invocation de services ou donnes normalises dans le SI (annuaires de personnes ou de ressources, dictionnaires de donnes, nomenclatures, etc.) Relation ncessaire la gestion du bloc en question (maintenance, exploitation, etc.) Plutt caractre descriptif et destine montrer les autres dpendances

Communication

Rfrentiel Administration Organisation

Des oprateurs de mesure de l'urbanisme

Disposer de moyens de mesure de l'aptitude du SI traiter la problmatique d'volution est essentiel. Pour cela, il est ncessaire de dgager les facteurs qui influent sur l'aptitude du SI voluer et d'identifier les proprits du SI partir desquelles ils peuvent tre dgags. Ces facteurs sont autant de critres de mesure de l'urbanisme qui permettent de jauger la rponse aux enjeux de l'urbanisme et de disposer d'indicateurs susceptibles d'aider la prise de dcision, 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. Critre Niveau de prcision atteint par l'urbanisme Concentration et organisation des blocs Capacit d'volution interne d'un bloc Impact des changements sur le reste du SI Degr de mutualisation standard Degr de couverture de l'urbanisation Description et possibilits de mesure Rend compte du degr d'analyse des principes d'urbanisation Met en vidence les surfaces sensibles du SI et illustre les ventuelles disparits dans le d :gr d'urbanisation Examen des dpendances d'un bloc envers les autres blocs, au travers de ses relations et des proprits qui l'attachent son bloc ou terrain d'insertion Traduit la porte d'un bloc, ensemble des autres blocs pouvant tre atteints par ce bloc Montre le niveau de mutualisation du SI. Examen de l'utilisation des structures collectives Identification des surfaces du SI auxquelles sont appliqus les principes d'urbanisation. Permet notamment de relativiser le niveau de prcision

La mise disposition d'oprateurs d'valuation de l'urbanisme peut laisser entendre que des moyens sont disponibles pour progresser vers des cibles suprieures en qualit et pour mettre en perspective la qualit de diffrents SI entre eux. Il est en effet tentant de chercher identifier les valeurs idales que doit retourner chacun des oprateurs pour assigner au SI une configuration optimale. En ralit, il est difficile de dgager une valeur absolue reprsentative 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 dmarche d'urbanisation de tout le systme d'information de l'entreprise ou d'une partie, de renforcer les quatre piliers de la gouvernance du SI : anticiper, dcider, communiquer et suivre.

10/20

Management des SI

Urbanisation des SI

L'indice est constitu de mesures qualitatives et quantitatives ralises sur sept axes d'analyse: connatre le SI existant et cible, grer les rfrentiels de l'entreprise (donnes et services), fournir un cadre pour les volutions du SI, accompagner les projets, matriser la complexit des flux d'changes d'informations, piloter l'urbanisation du SI, communiquer sur l'urbanisme et dvelopper les comptences.

Reprsent 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 rsultats, on peut alors construire le plan de progrs ncessaire au dveloppement et l'appropriation de la dmarche d'urbanisme dans l'organisation.

Axes

1 - Connaitre le SI existant et cible 2 - Grer les rfrentiels de l'entreprise (donnes et services) 3 - Fournir uncadre pour l'volution des SI 4 - Accompagner les projets 5 - Maitriser la complexit des flux d'change d'informations 6 - Piloter l'urbanisation du SI 7 - Communiquer sur l'urbanisme et dvelopper les comptences

11/20

Management des SI

Urbanisation des SI

12/20

Management des SI

Urbanisation des SI

Correspondance processus - indice d'urbanisation

13/20

Management des SI

Urbanisation des SI

exemples
Renault

Socit Gnrale

14/20

Management des SI

Urbanisation des SI

LES RGLES D'URBANISME (C.Longp -Le projet d'urbanisation du SI- Dunod 2009)
Les rgles 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 rfrence. Elles sont pour chacune dclines en : rgles d'urbanisme ; rgles de bonnes pratiques.

Il est noter que les rgles de niveau architecture fonctionnelle sont les plus universelles. Les rgles de niveau architecture applicative et surtout les rgles de niveau architecture technique sont beaucoup plus sujettes adaptation au sein de chaque entreprise ou organisme. Enfin, les rgles d'urbanisme de niveau architecture applicative et/ou de niveau architecture technique sont des rgles d'urbanisme valable pour l'ensemble du systme d'information. Elles ne sauraient donc prtendre 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 appliqus pour la construction de chaque difice.

Les rgles d'urbanisme pour la modlisation de la stratgie (diagramme d'Ishikawa)

Rgle n 1 : Un mme objectif ne figure qu'une seule fois dans le diagramme. Rgle n 2 : Lorsqu'un objectif est dclin en sous-objectifs, la liste des sous-objectifs doit tre exhaustive pour atteindre l'objectif. Rgle 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 Raliste et positionn dans le Temps).

Les rgles de bonnes pratiques pour la modlisation de la stratgie Rgles de bonnes pratiques pour le diagramme d'Ishikawa
Rgle n 1 : Un objectif commence par un verbe. Rgle n 2 : Le libell d'un objectif ne comprend pas de et qui pourrait masquer deux objectifs.

Rgles de bonnes pratiques pour le diagramme d'entreprise

Rgle n 1 : Privilgier la clart et la lisibilit l'exhaustivit. Rgle n 2 : Indiquer dans le commentaire associ au diagramme ceux des flux entre processus de premier niveau qui n'ont pas t indiqus sur le diagramme pour des raisons de lisibilit.

Les rgles d'urbanisme pour l'architecture mtier

Rgle 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. Rgle n 2 : Toute transformation des proprits d'un objet rsulte d'une activit, mme si c'est simplement l'ge de l'objet qui change, comme dans le cas o l'on garderait un objet entre deux transactions lies cet objet. Mais dans un diagramme normalis, une activit ne peut concerner qu'un seul objet, mme s'il peut s'agir d'un objet compos. Rgle n 3 : Une activit lmentaire ne peut tre interrompue, ce qui signifie qu'une fois qu'un acteur est affect une activit, il ne peut tre raffect avant la fin d'excution ou l'interruption de celle-ci pour fin anormale. Rgle n 4 : La fin d'excution d'une activit force la fin d'excution simultane de toutes les activits appartenant au primtre d'impact de cet vnement, qu'il s'agisse d'impacts indirects ou induits. Rgle n 5 : Toutes les activits peuvent avoir une fin anormale, mais galement des vnements temporels ou d'abandon. Chacun de ces vnements constitue un vnement particulier.

Les rgles de bonnes pratiques pour l'architecture mtier

Rgles de bonnes pratiques pour la cartographie des processus
Rgle n 1 : Les processus oprationnels, les processus de pilotage et les processus de support sont distingus.

15/20

Management des SI

Urbanisation des SI

Rgles de bonnes pratiques pour les processus

Rgle n 1 : La dcomposition des processus est limite trois niveaux. Par dfinition un sousprocessus est un processus et doit donc satisfaire la dfinition d'un processus. Rgle n 2 : Une tape du processus correspond un type de transformation d'un objet exprim comme son tat. Rgle n 3 : Toute fin d'activit gnre un vnement qui correspond au fait que la transformation est finie ou interrompue. Rgle n 4 : L'occurrence d'un vnement porte en elle la fin des transformations d'autres objets qui sont lis l'objet principal. Cela est vrai, soit parce qu'il y a de multiples reprsentations d'un mme fait rel (impacts indirects), soit parce que les rgles de gestion impliquent la rvaluation d'autres activits (impacts induits). Une activit, un objet ou un vnement peut toutefois dclencher l'tape. Tous les autres impacts sont indirects ou induits par cet vnement principal, puisque l'activit concerne de nombreux objets. Rgle n 5 : Un vnement peut activer de nombreux vnements dclenchs, au moins un pour chaque objet concern. Rgle n 6 : Chaque dclenchement est associ une dcision qui peut commander une activit ou une autre encore. Rgle n 7 : Une activit peut ncessiter un ou plusieurs dclenchements si des activits doivent tre synchronises.

Les rgles d'urbanisme pour l'architecture fonctionnelle

Rgle n 1 : Rgle 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. Rgle n 2 : Rgle d'asynchronisme des lots. Aprs avoir trait un vnement, un lot peut en traiter immdiatement un autre sans avoir se proccuper de ce qu'il advient du compte rendu de traitement de l'vnement prcdent. Rgle n 3 : Un bloc comporte obligatoirement une prise (interface externe). Elle est capable d'activer les services du bloc et de grer les communications entrantes et sortantes du bloc. Rgle n 4 : Toute communication entrante ou sortante d'un bloc passe par sa prise. Ces prises prsentent les avantages suivants : centraliser les appels de services et limiter le nombre d'interfaces ; ajouter un niveau d'encapsulation supplmentaire : l' intra-muros d'un bloc est considrer comme une bote noire par l'extrieur ; en dveloppement objet, une classe traduit dj un premier niveau d'encapsulation, le principe est reconduire aux niveaux suprieurs lot, quartier et zone ; mutualiser les services : un service public et un seul pour rpondre des besoins identiques formuls par des demandeurs diffrents appartenant le cas chant des blocs, quartiers ou zones distincts ; ceci traduit galement le principe de rutilisation ; accrotre la modularit ; rduire au strict minimum les impacts suite l'volution d'un lot dont les services publics sont sollicits par une diversit de demandeurs et rendre plus aise la dtermination de la chane d'impacts ; faciliter la mise en oeuvre de maintenances volutives.

Rgle n 5 : Seules les prises communiquent avec le gestionnaire de flux. Les prises sont seules habilites communiquer avec le gestionnaire de flux.

16/20

Management des SI

Urbanisation des SI

Rgle n 6 : Une donne est sous la responsabilit (quel que soit le type d'accs modification, suppression, visualisation) d'un lot et d'un seul.

: cration,

Un des objectifs de l'urbanisme est la portabilit des lots en respectant les rgles d'autonomie et d'asynchronisme. Pour atteindre cet objectif, il est ncessaire d'avoir des structures de donnes alignes 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 rgles de bonnes pratiques pour l'architecture fonctionnelle

Rgle 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 vnement organisationnels externes en flux fonctionnels enrichis de toute information ncessaire 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'excution dtermines par l'entreprise. La restitution adapte les rsultats 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. Rgle n 2 : Toute architecture fonctionnelle comporte une zone gisement de donnes. Cette zone reprend l'ensemble de toutes les informations dynamiques et prennes de l'entreprise ainsi que les services d'accs ces donnes. Elle assure la conservation et la valorisation du patrimoine d'informations de l'entreprise, garantit sa cohrence et permet son enrichissement dans le temps. Il faut noter qu'il ne s'agit que d'une rgle de bonne pratique, c'est--dire une recommandation. Les avis sur l'option qui consiste isoler de tels gisements de donnes dans une zone ddie et celle qui consiste les loger dans les quartiers d'autres zones (donc non spcifiques) sont en effet partags. Il y a deux raisons principales qui poussent vers la solution recommande dans cet ouvrage : cela facilite la progressivit de la migration des applications clientes d'un gisement de donnes mettre en oeuvre et surtout renforce l'volutivit et les possibilits de synergies entre systmes d'information dans un contexte multi-SI. Rgle n 3 : Toute architecture fonctionnelle comporte une zone rfrentiel de donnes et de rgles. Cette zone regroupe l'ensemble de toutes les informations communes aux diffrents lments du SI dont le cycle de vie est relativement stable. Un rfrentiel contient les donnes de rfrence concernant les produits et services, les rgles de gestion administrative et comptable de la compagnie, ses mtiers, son organisation indpendamment d'un client particulier ainsi que les services d'accs ces donnes. La notion de rfrentiel de rgles tant moins courante que celle de rfrentiel de donnes, il convient de la prciser. L'intrt d'un rfrentiel de rgles est d'extraire des rgles mtier du code des applications et de les stocker dans un rfrentiel. C'est particulirement utile pour les rgles qui ncessitent la fois un fort besoin de partage entre applications, de qualit et de cohrence. Les rgles stockes dans un rfrentiel de rgles peuvent tre modifies sans changer le code des diffrentes applications qui doivent les utiliser, voire mme sans arrter ces applications. Il ne s'agit pas d'isoler systmatiquement toutes les rgles mtier dans un rfrentiel de rgles mais c'est particulirement pertinent lorsque : ces rgles sont trs importantes pour l'entreprise (fort besoin de qualit) j ces rgles doivent tre appliques l'identique par diffrentes applications (fort besoin de partage et de cohrence) j ces rgles sont susceptibles d'tre modifies frquemment et l'entreprise a besoin d'agilit.

Exemples de rgles mtier : L'acompte la rservation doit tre> 10 % du prix total du voyage ou encore le solde du voyage doit tre pay un mois avant le dpart.

17/20

Management des SI

Urbanisation des SI

Si le tour-oprateur stocke ces rgles dans un rfrentiel de rgles, il peut alors dcider soudainement que l'acompte la rservation doit tre> 20 % du prix total du voyage et que le solde doit tre pay deux semaines avant le dpart et cela sans changer aucune ligne de code. Cet exemple illustre bien l'agilit que confre l'entreprise un rfrentiel de rgles. Rgle n 4 : Toute architecture fonctionnelle comporte une zone pilotage unique. Cette zone regroupe les blocs ddis aux processus de gouvernance et d'analyse et utilisant des informations globalises et historises. Rgle n 5 : Toute architecture fonctionnelle comporte une zone (ou un SI> opration par mtier principal de l'entreprise. Toute architecture fonctionnelle comporte une zone opration par mtier principal de l'entreprise ou de l'organisme. Le systme d'information d'une entreprise ou d'un organisme n'ayant qu'un seul mtier ne comporte donc qu'une seule zone opration. Par contre, si l'entreprise ou l'organisme a plusieurs mtiers, le systme d'information doit comporter une zone opration pour chacun. Par exemple, le systme d'information d'une compagnie exerant dans le domaine de l'assurance lARD (incendie, accident, risques divers), de l'assurance-vie et de la banque comportera une zone opration lARD, une zone opration Vie et une zone opration Banque. Rgle n 6 : Toute architecture fonctionnelle comporte une zone (ou un SI) ressources unique. Cette zone regroupe les systmes ddis la gestion des ressources internes l'entreprise (ressources humaines, comptabilit, etc.).

Les rgles d'urbanisme pour l'architecture applicative

Rgle n 1 : Les donnes des gisements de donnes doivent tre historises. Les donnes partages doivent tre historises afin de permettre de rejouer si ncessaire un processus et de garantir la cohrence du contenu et la bonne fin. Rgle n 2 : Les donnes des gisements de donnes doivent tre accompagnes d'une date de publication de mise jour. Les donnes des gisements de donnes doivent tre accompagnes 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 trs anciennes valeurs peuvent tre dportes dans des modules de gestion de donnes archives. Rgle n 3 : Les donnes des rfrentiels de donnes doivent tre accompagnes d'une date de publication de mise jour (comme les donnes des gisements de donnes) mais aussi d'une date d'ffet. Afin de permettre le versionnement temporel, les donnes des rfrentiels de gisements de donnes doivent tre accompagnes : 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 trs anciennes valeurs peuvent tre dportes dans des modules de gestion de donnes archives j d'une date d'effet.

Rgle n 4 : Duplication des donnes. Au sein d'un bloc, les donnes peuvent tre dupliques entre les donnes de contexte et les donnes des gisements de donnes car cela correspond deux niveaux de partage et de cycle de vie bien diffrents. En effet, les donnes sont isoles et temporaires pour le contexte alors qu'elles sont partages et permanentes pour les gisements de donnes. Le niveau gisement de donnes doit rester matre. La synchronisation au sein d'un bloc se fait par publication du contexte en respectant la rgle d'intgrit des gisements de donnes (rgle d'urbanisme pour l'architecture technique). Rgle 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

Management des SI

Urbanisation des SI

Les rgles de bonnes pratiques pour l'architecture applicative

Rgle n 1 : Toute architecture applicative comporte une zone ordonnancement qui assure l'interface entre front office, bock office et middle office. Plus prcisment 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 appels dans un certain ordre au niveau des MO et BO ; le pilotage des processus internes au SI ; la gestion des priorits.

Les rgles d'urbanisme pour l'architecture technique

Rgle n 1 : Dcomposition 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 dcomposition d'un bloc applicatif en couches d'architecture (les n couches ne sont pas utiles pour tous les blocs applicatifs) ne sont pas regroups diffremment. Rgle n 2 : Intgrit transactionnelle des flux sensibles. Afin d'assurer l'intgrit transactionnelle des flux sensibles (c'est--dire engageant financirement et/ou lgalement la socit), la communication entre tous les systmes concerns doit tre synchrone durant la phase de stockage mise jour des gisements de donnes. C'est d'ailleurs le seul cas o la communication synchrone est obligatoire. Rgle n 3 : . Intgrit des gisements de donnes Toute mise jour des gisements de donnes et toute mission vers l'extrieur 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 donnes des gisements de donnes et dans l'mission des flux ; cohrence tout moment des gisements de donnes ; caractre durable (non rversible automatiquement) de la publication si elle russit.

Rgle n 4 : Concurrence batch / TP. Les batchs doivent tre construits pour s'excuter de manire concurrente aux processus TP sous le contrle des transactions avec respect de la rgle d'intgrit des gisements de donnes. Rgle n 5 : Source unique. Les composants logiciels qui ne ncessitent pas de variante pour des raisons lies leur catgorie ne doivent tre crits qu'une seule fois. La possibilit ou l'obligation de les implmenter sur des platesformes technologiques diffrentes ne justifie nullement une multiplicit des sources.

Les rgles de bonnes pratiques pour l'architecture technique

Rgle n 1 : Centralisation des gisements de donnes. Les gisements de donnes doivent tre centraliss, c'est--dire se trouver sur une plate-forme centrale, scurise, accessible depuis toute autre plate-forme. Rgle n 2 : Recommandation de non-duplication. On ne recourt la duplication que lorsqu'il y a des contraintes impratives (performance, scurit, charge rseau, exploitabilit, etc.). On appelle dans la mesure du possible le composant original.

19/20

Management des SI

Urbanisation des SI

Mtamodle de cartographie applicative

Ce mtamodle considre les points suivants : une application ou un rfrentiel sont des composants informatiques ; un composant informatique appartient un domaine fonctionnel (une zone si celle-ci ne se dcompose pas en blocs, un bloc si celui-ci ne se dcompose 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 dcomposer en un ensemble de sous- composants ; une application outille ou non une ou plusieurs oprations (une opration peut tre outille ou non par une ou plusieurs applications) ; un composant informatique a des flux entrant et sortant qui sont l'implmentation de messages (donc dcrits par des formats d'change).

20/20