Urbanisation SI
La méthode top-down dans l'urbanisme du Sytème d'Information
La méthode top-down part de la stratégie d'entreprise, pour en déduire les objectifs métiers, les processus métiers, le système d'information et enfin le système informatique.
En haut, juste en dessous de la stratégie d'entreprise qui ne fait pas partie de l'urbanisation du SI, on trouve la cartographie métier avec les processus métiers et leurs événements déclencheurs, puis en dessous, la cartographie fonctionnelle structurant le système d'information avec des blocs fonctionnels, un niveau encore en dessous, on trouve la cartographie applicative constituée de composants applicatifs du système informatique et enfin tout en bas la cartographie technique représentant l'infrastructure technique du système informatique.
La méthode top-down part de la stratégie d'entreprise, pour en déduire les objectifs métiers, les processus métiers, le système d'information et enfin le système informatique.
Le postulat étant que la couche supérieure à celle qui est modifiée, est invariante, sinon on s'expose à un risque de divergence.
Toute intervention dans l'urbanisation du SI est opérée sur la couche n immédiatement en dessous de celle n+1 qui doit rester invariante. La couche n-1 doit subir toutes les modifications pour remplir les besoins de la couche n et ainsi de suite. Il est possible qu'une couche remplisse déjà les besoins de la couche supérieure, auquel cas elle ne subira aucune modification.
Prenons l'exemple de la direction générale d'une mutuelle qui adopte une stratégie de lutte renforcée contre la fraude. Le schéma directeur défini sur 3 ans, bien qu'il puisse être révisé tous les ans, est considéré comme invariant. La première couche non invariante est la couche métier. En effet, le processus métier de remboursement d'actes de santé est modifié.
En fonction de certaines règles, comme plus de 3 consultations chez un généraliste dans la même journée, un rejet sera généré pour un traitement manuel. On voit que non seulement le processus métier est modifié mais aussi l'organisation avec un changement important pour le travail du gestionnaire. Il faudra modifié la couche fonctionnelle avec des classes et des services métiers spécifiques.
La couche applicatives devra implémenter ces classes et ces services et assurer la communication avec les autres blocs applicatifs comme le paiement, le juridique, ...
La couche technique ne sera peut être pas impactée, car elle possède déjà un ESB (Enterprise Serial Bus) permettant la communication entre les blocs.
La méthode bottom-up, consiste à intervenir sur une couche pour en améliorer le fonctionnement.
Cette opération peut faire émerger des opportunités de modification à la couche supérieure. Elle part du principe que dans tout système défini, il peut y avoir des évènements qui remettent en cause les principes établis.
Généralement ces évènements sont extérieurs à l’entreprise, d’ordre technologique mais aussi économique (fusions ou acquisitions) ou réglementaire (obligation de mise en place d’une norme européenne).
Et comme bien souvent ce n'est pas l'une ou l'autre qui est privilégiée mais bien un mixte des 2 méthodes.
Rhona Maxwel
@rhona_helena
"Le paradoxe du travail, c'est que l'on ne travaille, en fin de compte, que pour le supprimer."
Boris Vian
Objectifs des indicateurs du processus d'urbanisation du Système d'Information
Les 6 commandements de la démarche d'urbanisation du Système d'Information.
Connaître le SI existant. Cette connaissance, qui est indispensable pour faire évoluer le système d'information, porte à la fois sur les processus métiers et les applications du SI. Elle fait l'objet de référentiels cartographiques, dont la mise à jour doit accompagner les changements apportés au SI.
Gérer les référentiels majeurs pour l'entreprise. L'existence au sein d'un SI, de multiples bases de données ou fichiers contenant des données semblable, mais loin d'être identiques, est toujours un facteur de complexité ou de surcout.
Cet objectif permet d'évalue si les données métier de référence sont défini de façon unique et connue de tous, si la responsabilité de chaque référentiel est attribué à une maîtrise d'ouvrage identifiée. Enfin, il permet de vérifier si les dispositifs de gestion des données de référence permettent d'en assurer la qualité, la cohérence et la disponibilité.
Disposer de cibles pour l'évolution du SI. L'élaboration de ces cibles fonctionnelles, applicatives et techniques permet d'une par de s'assurer que la réalisation des nouveaux projets s'inscrit bien dans le cadre de ces cibles.
Permet de s'assurer en permanence que ces cibles sont en harmonie avec la stratégie de l'entreprise.
Maîtriser une construction du SI pour l'ensemble de l'entreprise. Pour atteindre ces cibles, il faut définir et mettre en œuvre un plan de migration ou road map, élaborer et diffuser des règles d'urbanisme applicables par les équipes de projets (maîtrises d'ouvrage et maîtrise d'œuvre).
Grâce à un accompagnement permanent des projets par les urbanistes, il faut en outre s'assurer que ces règles sont effectivement appliquées dès la première étude amont.
Maîtriser la complexité des flux d'échanges d'informations. L'indicateur portera sur la description des flux inter-applicatif, la standardisation de ces échanges, au moins pour les données majeures de l'entreprise.
Il faut vérifier la mise en place, l'administration et la maintenance de dispositifs d'échanges mutualisés.
Piloter et supporter l'urbanisation du SI. Pour mettre en œuvre le processus d'urbanisation, il faut des moyens adaptés.
L'indicateur analysera la modélisation de ressources pour l'urbanisme (définition de la fonction d'urbaniste, insertion des urbanistes dans les structures de gouvernance). Permet de vérifier la mise œuvre de dispositif de communication et de formation pour l'ensemble des acteurs projets.
Pour chaque objectif est associé un certain nombre de critère (3 à 5) et à chaque critère est associé une mesure, noté de de 0 à 4, selon une grille prédéfini associé à chaque critère.
L'indicateur de cette mesure est :
soit quantitatif : par exemple, pour les référentiels de cartographie, les notes sont attribuées selon le taux de couverture de la cartographie ;
soit qualitatif : l'indicateur caractérise des notions telles que le champ, la fréquence, la profondeur des actions associées au critère.
« Faiblesse et courage, étourderie et raison, caprice et dévouement ! la femme est un composé de tout cela. »
Goswin Joseph Augustin, baron de Stassart
Rhona Maxwel
@rhona_helena
Articles conseillés :
Quelle est l'étape la plus importante dans l'urbanisation des SI ?
Pas de nouvelles, mauvaises nouvelles
Quels sont les axes de recherche et développement de l'urbanisation ?
La démarche de l'urbanisation des systèmes d'informations : comment mesurer les progrès ?
Un processus n'est bien défini que s'il est mesurable.
La démarche d'urbanisation est une tâche qui prend du temps, la communication doit être sans faille, les progrès doivent être visibles et l'on doit s'efforcer de renouveler la motivation et l'énergie nécessaire.
Fini le simple inventaire d'avantages qualitatifs, il faut objectiver grâce à des indicateurs servant de véritable outil de mesure.
L'indice est donc un outil de mesure et de management : il permet d'apprécier si l'urbanisation du SI est en "bonne voie", c'est à dire si les actions menées s'inscrivent dans une démarche de meilleures maîtrise de l'urbanisation du SI. En ce sens, il différencie l'urbanisme d'une démarche comme CMMI : cette dernière se concentre sur le pilotage du processus, alors que l'indice d'urbanisation mesure le résultat sur la base de faits démontrables correspondants aux résultats du processus mis en œuvre.
Il faut mettre en œuvre la cotation de l'indice d'urbanisation et l'utiliser comme outil de pilotage de l'urbanisation de leur système d'information.
Rhona Maxwel
@rhona_helena
"C'est toute la beauté des larmes ; elles peuvent avoir deux significations opposées.
On pleure de douleur, on pleure de bonheur.
Peu de manifestations physiques ont cette identité à deux têtes, comme pour matérialiser la confusion."
David Foenkinos
Articles conseillés :
Avec un peu de métier, métamodéliser la vue métier pour assurer la traçabilité avec la stratégie
Visiter la "salle machine" de l'urbanisation des SI
Dans le futur, il faudra réaliser la symbiose des méthodes et veiller à la cohérence des gouvernances SI et processus
L'avenir de l'urbanisme de SI sera lié à 3 facteurs :
- La généralisation des relations en entreprise étendue, au delà des périmètres figés de la firme traditionnelle.
- La montée inéluctable des organisations autour des processus, du management par les processus, qui remettra en cause les fonctionnements internes, et sera reliée aux SI urbanisés.
- L'extension progressive des solutions techniques et conceptuelles basées sur des architectures de services pour les fonctions métiers souvent développées par les informaticiens de l'entreprise, comme pour les fonctions de support traditionnellement confiées à des ERP.
Le 1ère évolution, les relations entre les acteurs économiques, de plus en plus basées sur la technologie, gommeront les espaces traditionnels.
Les entreprises interagiront plus fortement, dans des processus plus directs et plus tendus avec leurs clients et leurs partenaires.
Ce fonctionnement en entreprise étendue qui existe déjà chez de nombreux grands comptes, deviendra la règle.
Dés lors, le champ des préoccupations d'urbanisme débordant le monde clos de l'entreprise, il faudra raisonner sur l'entreprise et son écosystème.
Les flux, la gestion des grands référentiels, l'activation de services automatisés, de bases de connaissances, seront à situer dans un contexte élargi, où les mouvements stratégiques, partenariats, fusions, filialisations, acquisitions, externalisations, pourront redistribuer les cartes autour des composants urbanisés.
Les urbanistes devenant architecte de la chaîne de valeur, auront à étendre leurs investigations jusqu'aux limites de ces champs d'action.
La 2ème évolution, elle aussi déjà engagée, concerne la vision processus. en effet la recherche de l'efficience, de la flexibilité et la proposition pour le client de la plus grande efficacité, continueront à bousculer les organisations.
La déformation des entreprises organisées en silos, en des modèles orientés processus deviendra une généralité.
Il faudra se préoccuper de diffuser la culture du management par les processus, de faire passer le BPM dans la réalité : instituer des propriétaires de processus, gouverner l'amélioration et piloter les performances pour que les processus répondent aux services qu'attendent les multiples parties prenantes, clients, usagers, partenaires, employés, actionnaires, sociétaires, ...
L'urbanisme des SI incite à décrire les processus métiers.
C'est un début, mais les processus sont considérés comme une entrée, et l'urbaniste n'a pas de légitimité pour les optimiser, voire les remettre en cause.
Pourtant dans le futur, il faudra fédérer les approches par les SI et celles par les processus, connecter les différentes visions transversales, réaliser la symbiose des méthodes, veiller à la cohérence des gouvernances SI et processus : les urbanistes seront les catalyseurs de cohérence, de transversalité, et de flexibilité.
La 3ème évolution majeure se réfère à la sphère technique.
Urbaniser le métier ou architecturer l'entreprise, tire les urbanistes vers le haut, que leur référence s'appelle urbanisme des SI, EA (Enterprise Architecture ou Architecture d'Entreprise) ou BPM (Business Process Management ou Gestion des Processus Métiers).
Ils ne doivent pas ignorer les évolutions techniques.
Un miracle technologique se produira-t-il (attention aux effets de buzz) ? Une révolution technique donnera-t-elle l'agilité instantanée tant espérée ?
Comme le montre notre X-Men John Zachman dans son modèle, pour l'instant aucune bonne fée n'est apparue avec sa baguette magique, il sera toujours nécessaire d'architecturer l'entreprise.
Les grandes entreprises dotées de SI de plus en plus complexes, seront confrontées à un environnement réglementaire multiple, protéiforme, à des contraintes de marché archi-mondialisées.
Il leur faudra lutter férocement contre l'entropie et rechercher toujours plus d'agilité.
Dans le futur, tel un funambule, l'urbaniste devra maintenir l'équilibre sur une corde qui sera disposée malheureusement de plus en plus haut.
Rhona Maxwel
@rhona_helena
"Le malheur déteint sur nous et nous ravit notre force. Mais il faut trouver le courage d'agir."
Laurent Seksik
L'urbanisme des SI et architecture d'entreprise : retour vers le futur
L'avenir de l'urbanisme de SI sera lié à 3 facteurs :
- La généralisation des relations en entreprise étendue, au delà des périmètres figés de la firme traditionnelle.
- La montée inéluctable des organisations autour des processus, du management par les processus, qui remettra en cause les fonctionnements internes, et sera reliée aux SI urbanisés.
- L'extension progressive des solutions techniques et conceptuelles basées sur des architectures de services pour les fonctions métiers souvent développées par les informaticiens de l'entreprise, comme pour les fonctions de support traditionnellement confiées à des ERP.
Le 1ère évolution, les relations entre les acteurs économiques, de plus en plus basées sur la technologie, gommeront les espaces traditionnels.
Les entreprises interagiront plus fortement, dans des processus plus directs et plus tendus avec leurs clients et leurs partenaires.
Ce fonctionnement en entreprise étendue qui existe déjà chez de nombreux grands comptes, deviendra la règle.
Dés lors, le champ des préoccupations d'urbanisme débordant le monde clos de l'entreprise, il faudra raisonner sur l'entreprise et son écosystème.
Les flux, la gestion des grands référentiels, l'activation de services automatisés, de bases de connaissances, seront à situer dans un contexte élargi, où les mouvements stratégiques, partenariats, fusions, filialisations, acquisitions, externalisations, pourront redistribuer les cartes autour des composants urbanisés.
Les urbanistes devenant architecte de la chaîne de valeur, auront à étendre leurs investigations jusqu'aux limites de ces champs d'action.
La 2ème évolution, elle aussi déjà engagée, concerne la vision processus. en effet la recherche de l'efficience, de la flexibilité et la proposition pour le client de la plus grande efficacité, continueront à bousculer les organisations.
La déformation des entreprises organisées en silos, en des modèles orientés processus deviendra une généralité.
Il faudra se préoccuper de diffuser la culture du management par les processus, de faire passer le BPM dans la réalité : instituer des propriétaires de processus, gouverner l'amélioration et piloter les performances pour que les processus répondent aux services qu'attendent les multiples parties prenantes, clients, usagers, partenaires, employés, actionnaires, sociétaires, ...
L'urbanisme des SI incite à décrire les processus métiers.
C'est un début, mais les processus sont considérés comme une entrée, et l'urbaniste n'a pas de légitimité pour les optimiser, voire les remettre en cause.
Pourtant dans le futur, il faudra fédérer les approches par les SI et celles par les processus, connecter les différentes visions transversales, réaliser la symbiose des méthodes, veiller à la cohérence des gouvernances SI et processus : les urbanistes seront les catalyseurs de cohérence, de transversalité, et de flexibilité.
La 3ème évolution majeure se réfère à la sphère technique.
Urbaniser le métier ou architecturer l'entreprise, tire les urbanistes vers le haut, que leur référence s'appelle urbanisme des SI, EA (Enterprise Architecture ou Architecture d'Entreprise) ou BPM (Business Process Management ou Gestion des Processus Métiers).
Ils ne doivent pas ignorer les évolutions techniques.
Un miracle technologique se produira-t-il (attention aux effets de buzz) ? Une révolution technique donnera-t-elle l'agilité instantanée tant espérée ?
Comme le montre notre X-Men John Zachman dans son modèle, pour l'instant aucune bonne fée n'est apparue avec sa baguette magique, il sera toujours nécessaire d'architecturer l'entreprise.
Les grandes entreprises dotées de SI de plus en plus complexes, seront confrontées à un environnement réglementaire multiple, protéiforme, à des contraintes de marché archi-mondialisées.
Il leur faudra lutter férocement contre l'entropie et rechercher toujours plus d'agilité.
Dans le futur, tel un funambule, l'urbaniste devra maintenir l'équilibre sur une corde qui sera disposée malheureusement de plus en plus haut.
Rhona Maxwel
@rhona_helena
"Il n'y a rien de plus parfait que de trouver du bonheur à communiquer le sien."
Henri Lacordaire
Architecture d'entreprise : le framework de Zachman pour les nuls
La métaphore de la cité : le POS (Plan d’Occupation des Sols) d’un SI a pour but :
• De définir les services et les responsabilités attachées à chaque sous-ensemble
• D’organiser le SI
• L’objet et la mission des applicatifs le composant
• Les regroupements d’applicatifs en ensemble cohérents
• Les périmètres réservés pour de futurs applicatifs à construire, notamment pour les applicatifs transversaux
Le POS d’un SI doit être compatible et s’aligné sur la stratégie de l’entreprise. Le dossier doit comporter :
• Synthèse sur les orientations et options retenues
• Un ensemble de cartographies (graphiques et commentaires associés) montrant avec précision les différentes subdivisions du SI et permettant de savoir à quels sous-ensembles du SI s’applique ou non une règle d’urbanisme donnée
• Les règles d’urbanisme ainsi que la définition de la mission et des services de chaque zone, quartier et îlot
• Annexes, CR d’entretiens, liste des personnes concernées, …
Le découpage en zones suit la typologie suivante :
• zone échange est responsable de l’acquisition/restitution du SI vis à vis de son environnement extérieur
• zone gisement de données : ensemble de toutes les informations dynamiques et pérennes ainsi que les services d’accès à ces données et assure la conservation et la valorisation du patrimoine d’informations, garantit sa cohérence et permet son enrichissement dans le temps
• zone référentielle des données de l’entreprise : regroupe l’ensemble de toutes les informations communes aux différents éléments du SI dont le cycle de vie est relativement stable
• zones opérations : on en trouve par métier principal
• zone ressource : regroupe les systèmes dédiés à la gestion des ressources internes (RH, comptabilité, …)
• zone pilotage
Les quartiers dans le SI sont des composants homogènes quant à la nature de l’information traitée. Ils correspondent à un sous-système. On a un couplage faible et une forte cohérence entre les quartiers. Ils regroupent les îlots qui sont les plus petits niveaux de décomposition du SI.
Un îlot :
• représente des entités (développées ou achetées) remplaçables du SI
• correspond à un but fonctionnel et avoir des accès à des bases de données
• reçoit ou émet des données vers d’autres îlots
• équivalent à une application ou une grande fonction applicative
• progiciel ou module d’un progiciel.
Mais à quoi peuvent bien ressembler les règles d’urbanisme ? Exemple :
• Interdictions comme d’accéder à un bloc sans passer par son port (prise)
• Limitations, par ex. une donnée doit être sous la responsabilité d’un et d’un seul bloc
• Prescription, par ex. tout bloc doit avoir un port (prise)
Parmi retours d’expérience les plus fréquemment cités :
• Les cartographies des applications existantes sont exhaustives et constituent un référentiel partagé, complet et administré de façon centralisé
• Les cartographies d’états futurs du SI sont moins fréquentes et leur niveau de détail est d’autant moins fin que l’on se projette dans un futur lointain
• La mise à jour des cartographies est réalisée dans la plupart des cas par des cellules dédiées mais la tendance est d’inscrire la mise à jour de la cartographie dans la méthodologie de conduite de projet
• La restitution des cartographies se fait par l’intermédiaire d’un intranet en général largement ouvert aux utilisateurs concernés
Néanmoins malgré sa très large généralisation, la cartographie applicative rencontre des difficultés :
• La coexistence de la cartographie de l’existant, de cartographie futures à différents horizons et d’une cartographie cible est difficile à obtenir
• La maîtrise de la cohérence du référentiel de cartographie, notamment en ce qui concerne les flux inter-applicatifs, nécessite un processus formalisé de mise à jour, qui n’est pas toujours en place ce qui nécessite d’effectuer des contrôles à posteriori
• La production de sous-ensembles cartographiques spécifiques n’est pas automatisée
• Le maintien à jour de la cartographie est difficile et nécessite organisation, suivi et support du management
Mais, la question qui intéresse tout le monde, c’est en quoi un environnement urbanisé peut-il réduire les coûts projet. Les réponses sont multiples :
• Mise à disposition d’informations sur le contexte fonctionnel et les applications
• Anticipation des impacts des autres projets
• Réduction des études amont et des études préalables
• Réduction du risque de fausse route
• Maîtrise du périmètre des projets
• Réduction des risques liés à la taille des projets
• Réduction des études, des développements et de la recette
• Existence de briques directement utilisables (composants, référentiels, EAI, ESB, données…)
• Existence de règles de construction qui permettent aux projets de se centrer sur les problèmes métier.
Pour les spécifications, on a un surcoût de l’ordre de 20% au départ pour passer à une orientation processus et une économie par la suite de 30% du à la simplification des études d’impact d’où un gain net de 10%.
Sur le développement on a un gain net de 20% car les objets métiers sont mutualisés et externalisés des processus.
L’intégration gagne en net un facteur de 40%. Il faut en effet au départ un surcoût de 30% pour acquérir le technique des bus logiciel et des adaptateurs mais une économie par la suite de l’ordre de 70% grâce à la réutilisation et au fait qu’il faille un seul adaptateur à réaliser pour se connecter au bus.
Ce que gagne l’exploitation, environ de l’ordre de 20% du aux découplages des systèmes et la flexibilité des hébergements, est perdu à cause des logiciels à mettre en œuvre (bus, logiciel d’administration, de surveillance, …).
Bien souvent, des applications obsolètes continuent de tourner par peur de couper le « mauvais fil » tellement les liens qui la relie au SI constitue un véritable plat de spaghetti. Si le SI est bien urbanisé, un seul lien à désactiver suffit d’où un gain net estimé à 80%.
Bien sur ces contributions continuent leurs effets dans les phases d’évolution ou de maintenance.
La gouvernance du SI optimise l’ensemble « fonctionnalités, coûts, délais » en misant sur l’urbanisation du SI. Chaque projet, lui aussi, optimise le même ensemble, mais à son échelle.
Pourquoi les projets sont-ils réticents à appliquer les règles d’urbanisme, parce qu’ils y voient une source de coûts additionnels.
La raison est que chaque projet voit les efforts de maintien ou d’amélioration de l’urbanisation comme générateurs de coûts. La raison d’être même des projets explique ce point de vue. En effet, un projet est constitué pour fournir, partant d’une situation donnée, une situation cible dans des coûts et délais déterminés. Les facilités que lui offrent son environnement, fruit des projets précédents, et les surcoûts éventuels qu’il génère aux projets suivants ne sont pas prises en compte par le projet. Un projet ne tient pas compte des efforts passés : il ne valorise pas dans son budget ce qui lui apporte un contexte urbanisé. Le projet n’a aucune nécessité de simuler quel aurait été son coût si la cartographie n’était pas à jour, s’il n’y avait pas de référentiels, si aucun mécanisme d’échange inter-applications n’était disponible, ... ce contexte à haute valeur ajoutée est considéré comme gratuit, alors qu’en fait, il s’agit d’une réduction de coût financée par les projets antérieurs. Un projet ne tient pas compte de la situation qu’il laisse: le projet ne valorise pas non plus le surcroît de travail qui sera demandé aux projets suivants et à la maintenance du produit si le projet dégrade l’urbanisation. Par contre, chaque jour de travail à maintenir ou améliorer l’urbanisation apparaît dans ses charges: tout naturellement, le projet va privilégier les ressources vers des tâches qui participent à l’atteinte de ses objectifs. Les tâches « pour la suite » apparaissent inévitablement comme des surcoûts.
Il faut se lancer dans l’urbanisation dès le départ du projet, les méthodes, les retours d’expérience et les outils existent et font qu’aujourd’hui urbaniser son SI n’est plus une aventure mais de la vulgaire routine.
"Rien ne vous emprisonne excepté vos pensées. Rien ne vous limite excepté vos peurs. Et rien ne vous contrôle excepté vos croyances."
Marianne Williamson
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Urbanisation du Système d'Information : les points d'attention concernant les performances
Toute conception ne doit jamais occultée la problématique des performances, mais au contraire elle doit orienter vers des choix conceptuels afin d'anticiper les futurs problèmes qui sans aucun doute ne manqueront pas d'arriver lors de son implémentation.
Lors de l'exécution d'un processus métier, des échanges inter-zones peuvent avoir lieu plus fréquemment que des échanges intra-zones.
Le cas classique est bien évidemment les quartiers de la zone référentiels qui ne communiquent pas entre eux, mais par principe, sont extrèmement sollicités par les autres zones.
On voit donc que le couplage par échanges de messages (flux) et l'application des règles d'urbanisme cohérence forte / couplage faible des blocs peut faire surgir des problèmes de performances.
On ne répètera jamais assez toute l'importance du dimensionnement de l'infrastructure comme par exemple l'ESB (Enterprise Service Bus), véritable colonne vertébrale supportant tout le système d'information.
Un autre problème toujours lié au fondement de l'urbanisme des SI, est celui concernant l'interface (prise) unique d'un bloc comme point de passage obligatoire pour l'accés des données aux autres blocs, peut laisser craindre des problèmes de contention et dégrader les temps de réponse.
Il n'y a pas de problèmes, il n'y a que des solutions, malgré tout, les cas présentés précédemment peuvent constituer des limites pour l'urbanisation des systèmes d'information.
"C'est une erreur de croire nécessairement faux ce qu'on ne comprend pas."
Gandhi
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Urbanisation du Système d'Information : les dangers des nouvelles technologies
Les règles d'urbanisme imposent pour les aspects fonctionnels et applicatifs une décomposition en blocs (3 niveaux de hiérarchie : zone, quartier, îlot / bloc) autonomes et communicants par messages (ou flux). Les entrées/sorties d'un bloc sont obligatoirement gérées par une interface unique (ou prise ou point de services d'accès unique), ce qui renforce le principe de forte cohérence forte/couplage faible du processus d'urbanisation du Système d'Information.
Ces concepts connus depuis longtemps font partie de l'Orienté Objet (A/C/OO, Analyse/Conception, POO Programmation, LOO Langage, ...). Les notions de classe (bloc), encapsulation (interface/prise) et communication par messages sont en effet des piliers de l'Orienté Objet et permettent d'avoir une forte cohérence (classe, encapsulation) et un faible couplage, secrets de l'agilité, évolutivité, réutilisabilité et maintenabilité.
Comme le processus d'urbanisation est fractal, on retrouve ces concepts aux niveaux supérieurs: les composants, les blocs/îlots, les quartiers, les zones et même aux sous-systèmes d'information !
Mais attention aux transferts de compétences !
Bien souvent les organisations qui entreprennent une démarche d'urbanisation de leur système d'information, viennent de cultures mainframe (COBOL, procédurale, ...). Passer à L'Orienté Objet est toujours un choc des cultures qui doit être évité par un accompagnement aux changements bien conçu.
L'implémentation de l'interopérabilité entre les blocs par échange de message est réalisée par un bus logiciel de type ESB (Enterprise Service Bus), digne successeur de l'EAI (enterprise Application Integration).
Pour ces concepts radicalement nouveaux, la DSI doit être formée et accompagnée par des experts amenant leurs retours d'expérience réussis dans d'autres projets similaires. La MOE doit alors s'approprier ces concepts et s'impliquer complètement dans ces révolutions technologiques.
Attention donc à ne pas mettre la charrue avant les boeufs et de ne pas démarrer la transformation vers les objets/composants/ SOA (Service Oriented Architecture) sans accompagnement au changement et aussi de bien surveiller la stabilité et la maturité des technologies utilisées.
Ne vous faites pas avoir par les supers vendeurs des éditeurs !
"Pas trop d'isolement ; pas trop de relations ; le juste milieu, voilà la sagesse."
Confucius
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
L'imprécision des méthodes d'urbanisme des systèmes d'information dans le cas de la multiplicité des systèmes
Un système d'information est un système fractal. On peut donc appliquer la même méthode à l'ensemble des sous systèmes.
Mais là ou le bas blesse, c'est qu'il n'est nulle part précisé comment on decide de créer tel ou tel sous système d'information.
Et dans le cas où ils correspondent à un existant, il n'y a pas de cadrage formel pour spécifier les artères de communication entre ces sous systèmes.
N'oublions pas qu'un système d'information est un systéme c'est à dire un ensemble d'éléments en interaction dynamique, organisé en fonction d'un but.
L'environnement influe en permanence sur le système d'information. Des événements externes imprévisibles et non analysables obligent à une adaptation permanente pour retrouver un etat stable.
Le partage des bonnes pratiques d'urbanisme de SI devrait permettre aux méthodes de s'étoffer sur ces sujets et pourquoi de voir pas la naissance d'une méthode open source spécialisée dans la démarche d'urbanisation des systèmes d'information.
"Toute méchanceté vient de faiblesse ; l'enfant est méchant que parce qu'il est faible ; rendez-le fort, il sera bon."
Jean-Jacques Rousseau
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
Y-a t'il des trous dans la raquette de la méthode d'urbanisation du système d'information ?
Depuis que les méthodes existent et continueront d'exister (peut-on se passer de méthodes ?), il y aura toujours des "trous dans la raquette."
En effet, chaque méthode a ses forces et ses faiblesses.
L'une met l'accent sur telles ou telles préoccupations et fourni un formalisme tandis qu'une constitue un ensemble de bonnes pratiques sans fournir de langage.
Concernant la vue métier de l'urbanisme des systèmes d'information, l'exhaustivité des méthodologies sur l'identification des processus métier à partir de la vue stratégie, leur définition et leur modélisation, se vérifie de projets en projets chaque jour.
A partir des modèles de la vue stratégique, les urbanistes avec leur expertise fonctionnel et technique appliquent des méthodes top-down, bottom-up ou mixte, associées aux bonnes pratiques de modélisation des processus métier en BPMN (Business Preocess Model Notation).
Il existe donc de nombreux retours d'expérience, des méthodes et des langages de modélisation (BPMN, profils UML) consacrés à la vue métier et assurant la traçabilité avec la stratégie.
Qu'en est -il pour la vue fonctionnelle ?
Comment passe t'on de la vue métier à la vue fonctionnelle ?
Et la, force est de constater que les méthodes fournissent peu d'éléments pour le cadrage de cette transformation.
De même la formalisation du passage au niveau technique reste peu développer.
On s'arrêterait au milieu du chemin avec une belle stratégie, supportée par de magnifiques processus métier joliment modélisés en BPMN sans savoir ensuite comment ils sont implémentés techniquement !
Quelle frustration !
"Rire souvent et beaucoup ; gagner le respect des gens intelligents et l'affection des enfants ; savoir qu'un être a respiré plus aisément parce que vous avez vécu. C'est cela réussir sa vie."
Ralph Waldo Emerson
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/