Il y a 15 ans -
Temps de lecture 7 minutes
Urbanisation pour les nuls
Le XKE (Xebia Knowledge Exchange) de mars a été l’occasion de présenter la démarche d’urbanisation. L’exemple présenté ne suivait pas le déroulement type : une démarche d’urbanisation est adaptée suivant les projets et organisations auxquels elle est appliquée.
Le but de ce billet est de dérouler cette démarche de manière simplifiée. Cela nous donnera l’occasion de définir le vocabulaire employé, et de faire un constat sur cette démarche.
Nous déroulerons l’exemple avec une approche TOP-DOWN, c’est-à-dire que l’analyse commence par la définition de la stratégie pour descendre ensuite au travers des différentes strates du SI. Pour l’exemple, nous prendrons le cas d’une agence de voyages qui achète et vend des voyages.
- Pourquoi une démarche d’urbanisation ?
- A quels niveaux se situe la démarche d’urbanisation ?
- L’analyse de la stratégie
- Identification des zones, quartiers et îlots (= bloc fonctionnel)
- Les cartographies
- Les livrables
- Conclusion
- Référence
Pourquoi une démarche d’urbanisation ?
La démarche d’urbanisation est née de la volonté d’avoir un système d’information évolutif et peu coûteux. En effet, la plupart des évolutions au sein d’un SI se révèlent être coûteuses et impactent souvent les autres composants du système, entraînant ainsi des problèmes de cohérence et des freins à l’amélioration du système d’information. Par ailleurs, l’évolution constante du SI engendre des redondances de fonctionnalités et des chevauchements des flux de communication. Au final, on se retrouve avec un système d’information non conforme avec les processus métiers de l’organisation.
La démarche d’urbanisation permet de « ranger » son système d’information. Il s’agit d’établir ou de ré-établir une relation entre les systèmes informatiques et la stratégie de l’entreprise. Le but étant de pouvoir intégrer progressivement les demandes d’évolutions du système d’information par une approche rationnelle.
A quels niveaux se situe la démarche d’urbanisation ?
La démarche d’urbanisation touche tous les niveaux de l’organisation :
Précisons les fonctions des différentes couches :
- Vue métier : cartographie des processus métiers de l’organisation.
- Vue fonctionnelle : description des fonctionnalités (services) offertes par le système d’information pour supporter les processus métiers.
- Vue applicative : description de l’ensemble des éléments du système informatique implémentant les services urbanisés sous forme d’éléments logiciels.
- Vue technique : description de l’infrastructure de fonctionnement des éléments logiciels du système informatique.
Sur ce schéma, nous voyons que la démarche d’urbanisation s’applique essentiellement au niveau des vues métier et fonctionnelle. En résumé, la démarche s’applique principalement aux stratégies de l’organisation ainsi qu’à la manière dont elles seront implémentées.
Les deux dernières vues correspondent plus à des problématiques projets.
L’analyse de la stratégie
Dans cette première étape, l’objectif est de définir la stratégie principale que l’organisation veut atteindre, ainsi que les moyens d’y parvenir. Cela se fait souvent au moyen d’un ou de plusieurs diagramme(s). Nous prenons ici l’exemple d’un diagramme d’Ishikawa:
Ce diagramme permet de représenter les causes et leurs effets. La flèche centrale sert à représenter le but principal, et les causes permettant d’atteindre cet objectif sont représentées par des flèches dirigées vers l’axe central, et ainsi de suite pour les autres flèches. Ici, le but principal sera d’améliorer le fonctionnement et la rentabilité de l’agence de voyages. Par exemple, cela passera par l’amélioration de la productivité des vendeurs.
Cette ou ces stratégies s’accompagnent des analyses des fonctionnalités existantes de l’organisation en décomposant les processus métier. Prenons l’exemple avec le processus d’achat d’un voyage par une agence :
Cette analyse s’accompagne aussi de diagrammes d’activités.
Ensuite, après analyse, la démarche prévoit de définir les processus cibles :
Dans cet exemple, le processus existant a été décomposé en deux processus afin de mieux répondre aux problématiques de l’organisation.
Identification des zones, quartiers et îlots (= bloc fonctionnel)
Définitions :
- Une zone représente le domaine fonctionnel.
- Un quartier est une opération à l’intérieur d’un métier.
- Un îlot représente une application.
Voyons sur un exemple une des façons d’identifier ceux-ci :
Ici, nous avons un ensemble de services qui communiquent les uns avec les autres, et nous constatons tout de suite les problèmes d’échanges de flux et de redondances…
La démarche prévoit de séparer ces services et de les regrouper suivant des domaines fonctionnels. Ainsi, nous obtenons :
A ce stade, les domaines fonctionnels sont identifiés et nous voyons que les communications entre services passent par une zone de médiation (on parle alors de découplage fonctionnel). Cette zone permet de centraliser les flux de communication. La couche médiation peut, par exemple, être implémentée par des ESB. En résumé, celle-ci vise à assurer l’interconnexion en gérant la médiation, la communication et les interactions entre les services et applications d’un système d’information. Pour plus de précision, je vous invite à consulter notre livre blanc sur les ESB.
A noter, l’apparition d’un réservoir d’informations, regroupant toutes les données de l’organisation.
Les cartographies
Les cartographies permettent d’avoir une vue d’ensemble des zones, quartiers et îlots. La démarche préconise d’établir les cartographies des processus métiers, fonctionnels et applicatives existantes et cibles. La cartographie des processus métiers a déjà été évoquée précédemment. La cartographie applicative est la suite logique de la cartographie fonctionnelle et regroupe donc les éléments de cette dernière. Nous nous attarderons sur la cartographie applicative. Cette étape représente la structuration du système d’information en blocs applicatifs.
En reprenant notre exemple, nous obtenons ainsi deux cartographies :
Cartographie applicative existante :
En pointillé, nous avons les zones dans lesquelles nous avons des quartiers (en violet) et à l’intérieur de ceux-ci des îlots (en jaune). Les noms des îlots sont présents à titre indicatif.
A travers cette cartographie, nous retrouvons les problèmes vus précédemment (redondances…)
Cartographie applicative cible :
D’une part, nous avons un meilleur découpage, car un îlot appartient à un seul quartier et d’autre part nous voyons que de nouvelles zones apparaissent.
Cette cartographie est issue de la cartographie fonctionnelle cible sur laquelle des zones ont été ajoutées. Bien entendu, afin de mettre en place une telle cartographie, des bonnes pratiques existent parmi lesquelles (Le projet d’urbanisation du SI, C.Longépé):
- Toute architecture fonctionnelle comporte une zone échange qui est en quelque sorte la prise du SI
- Toute architecture fonctionnelle comporte une zone gisement de données : elle regroupe les informations dynamiques ainsi que les services d’accès à ces données
- Toute architecture fonctionnelle comporte une zone référentiel de données : elle regroupe les informations communes aux différents éléments du système d’information étant relativement stables.
- Toute architecture fonctionnelle comporte une zone de pilotage unique
- Toute architecture applicative comporte une zone ordonnancement qui assure l’interface entre le front office, le back office et le middle office.
Les livrables
Au terme de cette démarche, un Plan d’occupation des sols (POS) est défini. C’est un rapport constitué :
- De synthèses sur les orientations choisies ainsi que les justifications sur les options retenues.
- D’une définition des zones, quartiers et îlots.
- De cartographies existantes et cibles (cartographie des processus, fonctionnelle, applicative, et éventuellement technique).
- De documents annexes (comptes rendus d’entretiens, liste des personnes et des entités organisationnelles…)
Le but est d’identifier les écarts entre l’existant et les principes d’urbanisation, mais aussi d’établir le planning des évolutions en décrivant les actions et leur coût correspondant.
Conclusion
En pratique, la démarche d’urbanisation est très lourde à mettre en place. D’une part, elle requiert la participation de beaucoup d’acteurs de l’organisation (DSI, comité stratégique, MOA décisionnaire, MOE, …), et d’autre part, l’analyse est très longue. En découle le principal problème : les besoins ont souvent évolué et le POS n’est plus forcément adapté…
En théorie, les principaux bénéfices de cette démarche sont d’optimiser le fonctionnement des processus, d’avoir un système d’information modulaire, évolutif et cohérent et de faciliter la réutilisation de composants. Bien entendu, comme vous vous en doutez, au vu des critiques précédentes, ces bénéfices sont souvent utopiques. Néanmoins, il est possible d’y parvenir en appliquant la démarche sur des périmètres réduits (un seul processus par exemple) et en itérant.
Référence
Publié par Nicolas Jozwiak
Nicolas est delivery manager disposant de 12 ans d’expérience en conception et développement. Son parcours chez un éditeur avant son entrée chez Xebia lui a notamment permis de développer de solides compétences dans le domaine de la qualité et de l’industrialisation (tests, intégration continue, gestion de configuration, contrôle qualité). Bénéficiant d’une expérience très solide de mise en place des méthodes agiles et d’accompagnement d’équipes sur le terrain, il s’attache à mettre à profit quotidiennement son expérience qui est reconnue pour son approche pragmatique, proactive et pédagogique.
Commentaire
37 réponses pour " Urbanisation pour les nuls "
Published by David @ Infhotep , Il y a 15 ans
Enfin ! Comprendre Longépé en un post : bravo ! Mais si cet article présente « l’urbanisme pour les nuls », alors 90% des DSI de ce monde ne peuvent pas l’appliquer.
On peut faire de l’urbanisme *simplement* sans sacrifier des processus métiers. Je réalise des schémas directeurs avec « plan d’urbanisme » en 10 jours pour les entreprises de 100 personnes (avec une DSI (presque) inexistante).
L’approche de Longépé est très belle, mais inapplicable sans avoir une cellule d’urbanistes chevronnés (donc être un groupe de 10 000 collaborateurs.)
Comment faire court et simple ?
Oublier les processus métiers, segmenter son SI en sous-systèmes métiers liés à l’organisation, responsabiliser les DGA et associer aux sous-systèmes des projets métiers et transversaux. Une petite moulinette et hop, des scenarii d’évolutions réalistes et compréhensibles pour un DG. (le « hop » est un peu chaud quand même:-)
Certes, pour l’urbanisation du ministère de l’éducation nationale, j’applique Longépé à la lettre. Mais pour nos DSI progicialisées qui veulent sortir d’un ERP, pour les DG qui transforment les services informatiques en direction des systèmes d’information, alors il y a une place pour le « Longépé light ».
David
Published by Nicolas Jozwiak , Il y a 15 ans
Tout d’abord merci pour ce commentaire !
Ensuite concernant un « Longépé light » je suis tout à fait d’accord avec cette idée, et elle rejoint la conclusion (application sur des périmètres réduits). Je suis persuadé que la démarche d’urbanisation a une place, mais après tout dépend de la façon dont celle-ci est mise en œuvre. La segmentation du SI en sous systèmes métiers est sans aucun doute une voie à suivre.
Published by CThiry , Il y a 15 ans
Merci pour ce billet.
Je souhaiterais répondre à plusieurs points.
– « démarche d’urbanisation est très lourde à mettre en place » « l’analyse est très longue » … lourd ? long ? c’est un jugement de valeur. On compte de 4 à 6 mois pour un premier niveau d’étude selon la complexité des situations. Alors, compte tenu de l’apport, à vous de voir si ca vaut le coup …
– « périmètres réduits » : il faut qu’il y ait au moins plusieurs processus d’un même domaine métier pour que ca fonctionne. un seul processus : pas possible.
– « L’approche de Longépé est très belle, mais inapplicable sans avoir une cellule d’urbanistes chevronnés (donc être un groupe de 10 000 collaborateurs.) »
En fait, la démarche d’urbanisation ne donne pas de résultats très intéressants dans une PME. Plus le SI et grand, mieux elle fonctionne.
Si vous travaillez sur une petite structure, je ne sais même pas si on pourraît appeler cela de l’urbanisme (vous imaginez, le plan d’urbanisme de la ville de Dordives ? ca ne va pas chercher bien loin)
De plus, les urbanistes doivent dans tous les cas être chevronnés, ils sont situés ‘à cheval’ entre métier et technique. Ce sont des moutons à 5 pattes (quelquefois 10 !).
Christophe
http://urba-si.blogspot.com/
Published by Michael , Il y a 14 ans
Je ne comprends pas la difference entre la zone Referentiel & Gisement de données (et j’ai pas mal étudié le livre de Longépé!). Dans cet exemple, on peut s’imaginer que Voyage et Tariff peuvent être modifiés souvent (place disponibles, prix qui augmente chaque semaine quand la date s’approche, etc.). Je ne comprends pas le critere de decider si un bloc est referentiel ou gisement. Cela fait plusieurs années que je me pose cette question.
Merci!
Published by THIRY , Il y a 14 ans
Bonjour,
Je viens de rédiger une réponse à Michaël sur mon blog
http://urba-si.blogspot.com/2009/03/referentiel-vs-gisement.html
Merci
Christophe
Published by Guilhem DELEBECQUE , Il y a 14 ans
Bonjour
Je trouve la démarche intéressante mais le résultat discutable (intérêt du blog).
J’ajouterai quelques commentaires concernant la réponse aux zones gisement et Référentielle sur le blog http://urba-si.blogspot.com/.
Je ne suis pas persuadé de l’intérêt de créer une zone gisement.
Soit la donnée est transverse à l’ensemble du SI, auquel cas elle doit faire partie de la zone référentielle, soit elle est propriété d’un quartier, auquel cas, ce sont les principes de Sas In/Out qui prévalent. (peut-être suis-je trop puriste). J’ai peur que la zone de Gisement ne soit qu’une justification à la mise en place d’un artéfact technique permettant la distribution de la donnée.
Au même titre, la Présence de la zone « Référentiel Règles » m’étonne énormément. Quelles sont les règles qui justifieraient de la création d’un quartier ne portant aucune donnée, et tout au plus l’exécution de règles. La mise en place d’un moteur de règle ne doit pas, à mon sens être justifié par le plan d’urbanisme mais par une réelle stratégie de développement informatique.
Le plan d’urbanisme doit à mon sens (encore une fois) être abstrait des implémentations techniques. J’ai trop souvent été le témoin de placages purs et durs des plans d’urba sur les applications provoquant l’inverse de ce qui était la cible. Des couplages forts, de la rigidité et des projets de refonte en pagaille.
Je prend la démarche d’urbanisation des systèmes comme une méthode de conception à la réalisation du système informatique. Tout ne doit pas y être cablé comme dans le physique. Certains concepts doivent rester flou (pas trop quand même) pour laisser une part de souplesse aux aspects de réalisation.
Ainsi le même plan d’urbanisme pourrait être appliqué à deux entreprises l’une portant tout sur le progiciel, l’ERP et les transporteurs de données et l’autre au tout SOA avec les orchestrateurs de services. La traduction de la stratégie métier est la même, la stratégie découpage de leur système est la même, seule l’implémentation diffère.
Je serais ravi de discuter de mes remarques.
Published by CThiry , Il y a 14 ans
Bonjour,
Voici quelques réponses
– « la zone « Référentiel Règles » m’étonne énormément »
Oui, je suis d’accord. Moi non plus je n’ai jamais compris pourquoi M. Longépé avait placé ce quartier
– « Le plan d’urbanisme doit (…) être abstrait des implémentations techniques »
Oui, je suis tout à fait d’accord. D’autant que mes amis et collègues architectes techniques voient d’un assez mauvais oeil la « main mise » sur leur prérogatives. Exemple : On reste indépendant de la technique en parlant de « service » et non de « web service »
– « J’ai peur que la zone de Gisement ne soit qu’une justification à la mise en place d’un artéfact technique permettant la distribution de la donnée »
En fait, l’arrière pensée est technique : on peut imaginer qu’un bloc applicatif référentiel soit majoritairement accédé en consultation e qu’un bloc applicatif gisement soit majoritairement accédé en création/modification …
Si vous ne voulez pas faire la distinction Référentiel/Gisement, libre à vous…
Merci. Christophe.
Published by Michael , Il y a 14 ans
Merci Thiry pour ta reponse dans ton blog sur la difference entre les zones de referentiel et gisement. Je suis un peu d’accord avec Guilhem, si la seul difference est la frequence de changement / mise à jour, je ne suis pas sur s’il faut les separer.
J’ai une autre question: J’ai des bloc fonctionnels dans ma zone referentiel, mais les données vient d’un partenaire à l’exterieur. Pour exemple j’ai une liste des sites internet qui est fournit par un partenaire et mise à jour tous les jours. Est-ce que ce bloc « sites internet » est situé dans la zone d’echange ou dans la zone de referentiel, ou les deux? Je les receptionne dans la zone d’echange mais ils sont disponible dans la zone referentiel.
Published by THIRY , Il y a 14 ans
Ma réponse:
– les fonctions d’acquisition / validation (dont en cible le système qui le fait) sont en Zone Échange
– les fonctions de mise à disposition vis-à-vis du reste du SI (dont en cible le système qui le fait) sont en Zone Référentiel
Pourquoi séparer en deux système ?
Avantage : On peut distinguer la qualité de service des systèmes de la zone échange (ex : 24/24 si le monte extérieur peuvent les invoquer) avec la qualité de service des systèmes référentiels (ex : 18/24 pour l’usage du SI de l’entreprise) et donc renforcer la contrainte technique du système d’échange uniquement là ou c’est nécessaire
Christophe
http://urba-si.blogspot.com/
Published by Richard , Il y a 13 ans
Bonjour,
Je ne sais pas si je dois poser la question mais je me lance. Depuis quelques temps je m’interesse à l’urbanisation. Dans les ouvrages que je suis en train de lire, il est fait référence à la notion de POS et à la notion de plan d’urbanisme. Aujourd’hui, je ne comprends pas bien la différence….si quelqu’un pouvait m’éclairer, ce serait fort urbain……
Merci à tous.
Published by Nicolas Jozwiak , Il y a 13 ans
Bonjour,
Le POS (Plan d’occupation des sols) regroupe l’ensemble des règles d’urbanisme. Le plan d’urbanisme est donc un sous ensemble du POS.
Pour rappel, le POS contient (partie Livrable de l’article) :
– un rapport contenant les orientations ainsi que les options retenues.
– les règles d’urbanisme (définitions zones, quartiers et îlots).
– les cartographies.
Néanmoins certaines littérature font un abus de langage : nous trouvons la définition du plan d’urbanisme au même niveau que le POS, ce qui est incomplet par rapport à la définition du POS.
Nicolas (Xebia)
Published by Richard , Il y a 13 ans
Merci Nicolas pour votre réponse et votre promptitude.
Amicalement.
Published by François , Il y a 13 ans
Bonjour,
Au sujet de la différence entre les zones référentiel et gisement de données, voici mon point de vue:
Le référentiel contient les informations (relativement) stables pour l’activité de l’entreprise. Ces données sont des données « référentielles/sources » qui doivent (ou peuvent) être partagées dans le SI.
Pour une activité commerciale, on y retrouvera donc les produits, les fournisseurs, les réseaux de distribution, les tarifs, etc.
On y trouve aussi toutes les données de « paramétrage » normalisées ou d’usage dans le SI: données légales, nomenclature, listes de pays, de code taxes, type de produit, etc.
On peut aussi y trouver des tables de transcodifications (codification externe inter-applicatif).
Le référentiel présente la donnée dans sa dernière valeur de référence. Il ne gère pas forcément différentes versions d’une même donnée.
Par contre, ce que je mets dans le gisement de données concernent toutes les données opérationnelles.
Les données variables au cours du temps: les ventes, les stocks, les commandes, etc. Elles y sont historisées.
Cette zone, je la considère comme un entrepôt de données mis à disposition du service pilotage. Le pilotage s’alimente en données provenant à la fois de la zone référentielle et de la zone gisement de données, croise ses données et fournit ses indicateurs.
Voilà, j’espère avoir fait avancer le débat.
Cordialement,
François.
Published by Abdoulaye , Il y a 13 ans
Bonsoir tout le monde,
Je voudrai savoir la différence entre le Plan d’actions et le POS. Et ce qu’on trouve dans le Plan d’action.
Merci d’avance.
Published by Nicolas , Il y a 13 ans
Bonjour,
Le plan d’action sera la conséquence du POS. Comme nous l’avons dit ci-dessus, le POS permet de d’établir un rapport qui est une synthèse des étapes d’urbanisation, et définit les stratégies à mettre en place pour y parvenir. Ce sont ces étapes qui vont alimenter le plan d’action. Par exemple si vous décidez de mettre en place une zone de référentiel de données : comment allez-vous vous y prendre ? Quelles technologies allez-vous utiliser ? Quel sera son coût ? Etc. Les réponses à ces questions alimenteront votre plan d’action.
Nicolas (Xebia)
Published by Abdoulaye , Il y a 13 ans
Merci Nicolas, c’est beaucoup plus clair pour moi maintenant.
Et je voudrai savoir s’il y a des outils open source pour l’urbanisation des si?
Published by Nicolas , Il y a 13 ans
Bonjour,
Hélas, à ma connaissance, dans ce domaine les outils Open Source sont rares…
Mis à part un bon vieux Open Office avec des diagrammes.
Concernant les outils ‘payants’, il y a (entre autre) suivant vos besoins Talend, Power AMC et Mega.
Nicolas (Xebia)
Published by Guilhem DELEBECQUE , Il y a 13 ans
Bonjour
Talend comme outil d’urbanisation des SI ?
C’est un outils d’implémentation de l’urbanisation comme n’importe quel transporteur de données ou de services permettant le découplage des applications. Ce n’est pas un outil d’aide à l’urbanisation (au sens conceptuel du terme).
Power AMC et MEGA, OK, mais il ne faut pas oublier ARIS (IDS Scheer), Corporate Modeler (Casewise), Entreprise Architect (Sparx System), Ado IT (BOC), ainsi que les plus petit et moins cher : Win’Design ou Valdys.
Quelques initiatives Open Source ont débuté sans produire de résultat. L’urbanisation des SI reste un sujet très « Conseil » peu compatible avec le temps à passer pour le développement de la solution et de la méthode.
Cdt
Guilhem
Published by CThiry , Il y a 13 ans
Bonjour,
J’ai eu l’occasion de regarder deux outils « open source ».
– ESSENTIAL PROJET, que l’on trouve sur http://www.enterprise-architecture.org/
Le métamodèle est très (trop) riche, mais sans vue fonctionnelle, il n’y a quasiment pas de modélisation (petit modélisateur de « processus » très limité), il est basé sur un « moteur d’ontologies » ce qui rends certes le métamodèle personnalisable mais produit des écrans très confus et très abstrait car exprimé dans le langage des ontologies – on ne crée pas une donnée mais on « instancie un concept » :-))
– ITERAPLAN 2.5 qui est encore plus limité : il manque un modélisateur, les vues stratégiques et fonctionnelless et la personnalisation du métamodèle. Mais il sait générer des graphiques à partir des données.
Cordialement
Christophe
Published by Abdoulaye , Il y a 13 ans
Merci à tous pour votre réactivité et vos réponses instructives.
Cordialement,
Abdoulaye.
Published by Mustapha , Il y a 13 ans
Tout d’abord merci à tous
je souhaite savoir la relation en un schema Directeur Systemes d’information et une démarché d’urbanisation ? est ce qu’ ils sont complémentairs ?
Cordialement,
Mustapha
Published by David , Il y a 12 ans
Bonjour,
J’ai la même question que Mustapha.
Comment associer urbanisme et schéma directeur informatique ?
La démarche d’urbanisation propose de passer d’un système d’information existant à un système d’information cible, par versions successives. Ces versions sont
gérés par des plans de convergence. Le schéma Directeur correspond-il au plan de convergence ?
Merci pour vos réponses,
Cordialement,
Published by CThiry , Il y a 12 ans
Mon avis:
L’expression « schéma directeur » n’est pas normalisée, elle a longtemps été employé bien avant l’urbanisme et l’architecture d’entreprise.
Dans un « schéma directeur » de ces époques, on trouvait le plus souvent un plan d’évolution strictement technologique.
De nos jours, on considère qu’il est également important de réaliser des plans stratégiques du système d’information, c’est à dire IT + Applications métier. Dans ce cas, le « schéma directeur » contiendra également un plan d’urbanisme
A vous de définir le sens (technique ou métier) que vous voulez donner « schéma directeur ».
à bientôt
Christophe
Published by Vivien , Il y a 12 ans
Bonjour tout le monde,
J’ai une petite question à laquelle je n’arrive pas réellement à repondre.
Quelles sont les principales différences entre les démarches de Longépé et de Sasoon? Y’en a-t-il une qui contredit l’autre?
Published by Nicolas , Il y a 12 ans
Bonjour Vivien,
Mes connaissances concernant la démarche de Sasoon sont moindres comparées à la démarche de Longépé, mais d’après ce que je sais les démarches sont similaires: nous retrouvons les mêmes étapes.
C’est dans la mise en oeuvre de ces étapes que la différence se situe:
– Sasoon propose une approche « académique » : étape 1, étape 2, etc.
– Longépé propose une approche dans la continuité de Sasoon mais dans un cadre « projet ».
Nicolas (Xebia)
Published by Jérôme BENOIS , Il y a 12 ans
Bonjour,
Dans la liste des outils, vous oubliez Obeo Designer (édité par une boite française) qui permet d’adresser les problématiques d’urbanisation mais aussi d’Architecture d’entreprise. Il a l’avantage d’être basé sur Eclipse, et offre la possibilité de définir son propre méta-modèle, mais aussi de personnaliser les diagrammes et les matrices permettant d’éditer les différents cartographies.
Jérôme.
Published by L Martinez , Il y a 11 ans
Bonjour,
Désolé d’intervenir si tardivement, mais je viens juste de découvrir le blog.
Je pratique l’EA depuis le milieu des années 90, même si à cette époque cette discipline n’était pas reconnue ni dénommée comme telle. J’ai également été formé par le CEISAR.
Il me paraît essentiel de mettre en avant deux notions:
– Peu importe l’outil utilisé pour la modélisation (MEGA, ARIS, …) et la méthode ou le modèle. L’essentiel est la finalité.
– Une entreprise n’investit que si cet investissement correspond à un gain.
Ainsi, j’en arrive à un questionnement fondamental:
Comment démontrer les gains opérationnels, et donc financiers, de l’EA (Urbanisme SI à la française)?
Quelles sont donc les métriques permettant de démontrer le bien-fondé de notre approche?
Nous sommes en effet perçus généralement par les métiers comme des « empêcheurs de tourner en rond », et donc, contrairement à notre vocation, des vecteurs de non réactivité.
Comment démontrer que cette approche organisationnelle est bénéfique pour l’entreprise, sans rester dans le conceptuel?
Vous pouvez consulter mon blog à http://fusacq.over-blog.com
Cordialement,
Luc
Published by Tan khoy , Il y a 11 ans
Bonjour,
Tout d’abord je vous remercie pour votre blog. Sinon j’ai une question : Que représente une application par rapport à un domaine fonctionnel.
Merci de votre retour.
Cordialement
kht
Published by Nicolas , Il y a 11 ans
Bonjour,
Le domaine fonctionnel représente une partie de l’application. C’est la partie qui va représenter ce que vous souhaitez modéliser.
Une application est bien plus large : elle englobe le domaine et/ou des règles de configuration par exemple.
Nicolas (Xebia)
Published by Jean Serge NZE , Il y a 10 ans
Bonjour,
je pense plutôt le contraire,l’application est bel et bien une partie c’est à dire une brique du domaine fonctionnel.En effet dans celui-ci (domaine fonctionnel), l’on peut trouver plusieurs blocs applicatifs.
Jean Serge
Published by jpl , Il y a 10 ans
Bonjour,
comme quoi, après des années de débats d’experts, de conférences, de clubs spécialisés, de projets et démarches, ce n’est toujours pas clair.
Bon :
Ce ne sont pas les mêmes couches, la couche applicatives répond à la couche fonctionnelle, ce sont des vues différentes. En conséquence une application selon sa conception peut répondre à un sous-ensemble fonctionnel ou bien au contraire répondre à plusieurs ensembles fonctionnels. Par ailleurs, il ne faut pas confondre la fonction et le domaine fonctionnel, ex la fonction comptabilité du domaine fonctionnel finance. Ou la fonction paye du domaine fonctionnel RH.
Et voilà
Published by Arsen kabey , Il y a 10 ans
Bonjour,si on devait representé le macro processus d’un gouvernement(pays) qu’elles sont les ministères qui devront être présent dans les processus opérationnels, merci
Published by jpl , Il y a 10 ans
Bonjour,
tous les ministères ont des processus opérationnels, en effet la déclinaison des décisions politiques se fait à travers la mise en œuvre des politiques menées par les ministères au sein des administrations, il ne faut pas confondre ministre (gouvernement) et ministère (administration centrale et territoriale) chargé d’appliquer sur le terrain les décisions politiques et de mener les missions régaliennes.
Un ministère et son administration sont opérationnelles.
Le processus gouvernementaux eux relève des processus stratégiques.
jpl
Published by Statuds , Il y a 9 ans
Bonjour,
Quelqu’un peut me dire ou je peux trouver des infos uniquement sur l’architecture fonctionnelle…en assurance par exemple?
CDT
Published by stephanie , Il y a 9 ans
Bonjour
on m’a propose de faire mon memoire de fin d’etudes (ENSET)sur l’urbanisation du SI d’un lycee. cela doit se faire en un mois et demi. pensez-vous que cela soit realisable? si oui, pouvez vous m’orientez SVP (plan de travail, outils.. )?
Published by Laabi , Il y a 7 ans
Bonjour
Serait il possible de me
Communiquer des outils / logiciels pour dresser la cartographie fonctionnelle (POS) et applicative
Merci
Published by paul arnaud , Il y a 5 ans
Combien de niveaux comporte une démarche d’urbanisation des SI ?