L'urbanisme et la gouvernance du Système d'Information
Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?
Le niveau d'investissement en urbanisme peut se mesure par un indicateur simple.
L'urbanisme se développe par cycles.
L'investissement dans une nouvelle infrastructure d'urbanisme est obligatoire lorsqu'il y a des dysfonctionnements, des surcoûts, des blocages ou des constats de déphasage par rapport à la stratégie.
La mise en place de cette infrastructure est progressive, car l'urbanisme ne crée pas de rupture.
Des investissements pour la création ou le développement d'un service d'urbanistes et les réalisations techniques sont nécessaires.
L'étape suivante est la mise en œuvre de l'urbanisme dans les projets IT, véritable consolidation de la nouvelle politique d'urbanisme.
Cette infrastructure est conçue pour une durée de vie longue, plus longue que celle des systèmes d'information qui la prennent pour base.
Un jour, il faudra la remettre en cause, pour faire face aux enjeux futurs.
Une nouvelle période d'investissement sera engagée, modifiant tout ou partie des bases précédentes.
Ces cycles, générations successives de politiques d'urbanisme, sont des avancées dans la maîtrise des SI.
L'urbanisme gagne en maturité :
-
1ère étape, on se limite à cartographier le patrimoine d'un SI mal connu. Ceci permet d'éviter l'empilement systématique des composants applicatifs issus de projets opportunistes. L'urbanisme est préventif, limite la complexité, les redondances et incohérences.
-
2ème étape, l'urbanisme, ayant gagné en crédibilité auprès des maîtres d'œuvre, peut engager la promotion des référentiels.
-
3ème étape de maturité, l'urbanisme espère à la mise en ordre des processus, et à un meilleur alignement stratégique.
Les efforts budgétaires dans l'urbanisme suivent des fluctuations périodiques :
-
Instabilité incitant à privilégier le simple et jetable
-
Nécessité d'aller au plus vite pour gagner des parts de marché en phase de croissance extensive
-
Période de consolidation
-
Année de restrictions financières
La difficulté analytique existe car la fonction urbanisme n'a pas un périmètre immuable :
-
D'une entreprise à l'autre, il existe des variantes dans les définitions (urbaniste, architecte fonctionnel, architecte d'entreprise), dans l'organisation, dans les rôles des processus de l'urbanisme.
-
Au sein des grands groupes, des variantes existent aussi entre les diverses entités, leur organisation, et la subsidiarité ajoute un niveau de complexité pour une comptabilité analytique.
-
Les entreprises ne mettent pas en œuvre tous les processus de l'urbanisme, cela dépend du contexte et du schéma de gouvernance.
Un indice de maturité basé sur une échelle unique serait réducteur, car l'objectif n'est pas d'appliquer tous les processus.
Au cas par cas, l'entreprise arbitre et choisit le panier de processus pertinents.
L'indice d'urbanisation restitue mieux cette approche multiple, et ne livre aucune préconisation.
Le niveau d'investissement en urbanisme peut se mesurer par un indicateur simple : le rapport entre cet investissement et celui constaté dans les projets de Systèmes d'Information.
L'urbanisme ayant une nature d'infrastructure pour les Systèmes d'Information, le dénominateur est constitué uniquement du coût d'étude, de développement, de test, à l'exclusion des coûts de maintenance, et de ceux de maîtrise d'ouvrage. Il s'agit de comparer des coûts d'investissement de même nature.
L'effet de levier de l'urbanisme porte sur la création de valeur.
Par son action vertueuse sur la flexibilité, la réactivité, il contribue alors directement à la stratégie.
L'urbanisme révèle et positionne certains composants du SI et objective les scénarios répondant aux aléas et stratégies du métier.
Si tel est le cas, un ratio d'urbanisme durablement faible, une fonction sous-configurée et incapable de répondre, en qualité, aux enjeux, pourra mettre en péril l'entreprise, bien au-delà de la performance des processus.
Rhona Maxwel
@rhona_helena
« Le courage est la première des qualités humaines car elle garantit toutes les autres. »
Aristote
Articles conseillés :
En Urbanisation SI, les constructions/destructions et l’entretien du POS sont réglementés
Urbanisme SI : les objectifs en moins de 20 lignes !
Urbanisation du Système d'Information : Ne vous perdez pas dans les typologies de référentiel !
Urbanisation du Système d'Information : créez l'évènement !
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
Urbanisation du Système d'Information : créez l'évènement !
Comment faire pour signifier aux autres briques logicielles, que l'état d'une entité métier a changé ?
Classiquement, une adhésion à un contrat peut être fermée de manière rétroactive. Comment le communiquer au bloc applicatif prestation pour que celui-ci puisse clore le sinistre correspondant ?
La démarche d'urbanisation est une démarche fractale, on réapplique les concepts d'un niveau au niveau supérieur.
Par exemple, au niveau microscopique, les concepts objet fondamendaux comme l'encapsulation et la communication par messages se retrouvent au niveau macroscopique c'est à dire au niveau blocs fonctionnels ou applicatifs des cartographies correspondantes.
Appliquons ce principe au modèle de conception bien connu des concepteurs objet sous le nom de Design Pattern du GoF (Gang of Four, la bande des 4 génies, experts en concepts objet).
Un de ces modèles s'appelle l'Observateur. Avec un AGL comme Enterprise Architect on peut facilemet récupérer le squelette du diagramme de classe du pattern en faisant un glisser déposer à partir de la bibliothèque de patten du GoF, c'est ce qu'on a fait pour obtenir le diagramme de classe ci-dessus.
Encore un truc technique issu de "teckausses autistes" me direz-vous ?
Surtout pas de préjugés, les experts métiers auraient beaucoup à y gagner en s'inspirant de modéles de conception qu'ils pourraient adapter et appliquer à leurs problématiques métiers.
Mais alors en mots simples, de quoi s'agit-il ?
Les entités (ConcreteObserver sur le diagramme de classe) devant être informées d'éventuels changements d'une autre doivent avoir un comportement d'"Observateur" (Observer ou encore Listener). Elles s'abonnent aux entités à observer (ConcreteSubject) qui doivent avoir elles, un comportement de "Sujet" (Subject).
Le comportement "Sujet" (le terme technique est interface ou classe abstraite) doit pouvoir ajouter et supprimer des entités de type "Observateur" de sa liste d'abonnés (nommée "observers" sur la relation "Subject" vers "Observer"). De plus, il doit pouvoir notifier (notify) tous ses abonnés en leur transmettant un évènement comprenant le sujet et ce qui a changé dans son état. Pour se faire, le sujet envoie un message (update) à tous ses abonnés, dans lequel se trouve l'émetteur du message (le ConcreteSubject) et son nouvel état.
Un abonné (ConcreteObserver) reçoit l'évènement (le message), il sait quelle est l'entité émettrice, ce qui a changé dans son état et peut donc modifier son état en conséquence.
Cette gestion évènementielle peut se faire en temps réel ou bien en différé en rendant persistant l'évènement (par exemple en le stockant dans une base de données).
Revenons à notre problème de départ ou une adhésion est fermée de manière rétroactive ce qui doit modifier les prestations postérieures à cette date de fermeture.
Avec cette solution, le gestionnaire sera averti dans son écran que l'adhésion a été fermée rétroactivement et que cela à impacter un certain nombre de prestations (qui ont été par exemple annulées et se retrouvent en régularisation si elles ont été payées).
De même, un batch de régularisation des prestations pourra récupérer tous les évèvement émis par l'adhésion pour ses abonnés de type Prestation et aura toutes les informations nécessaires à la régularisation.
Notre vie serait peut être transformée, s'il existait des patterns de solutions à des problèmes types de notre existence ? Y-a-t'il seulement une personne qui y a réfléchi ?
"J'ai toujours rêvé d'un ordinateur qui soit aussi facile à utiliser qu'un téléphone. Mon rêve s'est réalisé : je ne sais plus comment utiliser mon téléphone."
Bjarne Stroustrup
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 : Ne vous perdez pas dans les typologies de référentiel !
Car vous n'obtiendez jamais un consensus sur ce genre de chose. Personne n'est d'accord et tout le monde a de bons arguments pour discuter telle ou telle classe de référentiel : "Pourquoi les contrats sont dans le référentiel de données élémentaires et pas dans le référentiel des données sensibles ?".
Faut-il créer un référentiel avec des données de type nomenclature (tables de référence), un référentiel basé sur le cycle de vie et la fréquence de mise à jour, un référentiel des données confidentielles et un référentiel des données élémentaires (clients, fournisseurs, produits, ...) ?
Mieux vaut se consacrer sur le coeur du sujet c'est à dire :
- la description de la structure des entités métiers. Pour cela on utilise une modélisation UML avec un diagramme de classe qui permet de préciser les objets, leurs attributs et les relations entre les objets.
- la solution retenue pour l'architecture technique d'implémentation du référentiel (base SQL, base objet, XML, les canaux d'accès, la sécurité, ...)
- les données métiers, avec l'analyse de la valeur des données, leur origine, le processus d'acquisition et de mise à jour, l'évaluation de la fiabilité, le propriétaire de la donnée et n'oublions pas le coût d'acquisition et de maintenance.
- les interfaces avec les applications futures ou existantes nécessitant la mise en place d'un langage pivot commun et les adapteurs entre ce langage et le format des applications.
"La science est avant tout une classification, une façon de rapprocher des faits que les apparences séparaient bien qu'ils fussent liés par quelque parenté naturelle et cachée. La science en d'autres termes, est un système de relations."
Henri Poincaré
La valeur de la science
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/
Urbanisme SI : les objectifs en moins de 20 lignes !
L’objectif majeur de l’urbanisme SI est de permettre au Système d’Information d’évoluer de manière fractale et itérative, sans effet de BIG BANG, en gérant l'intégration d'applications vieillissantes et hétérogènes.
Cela nécessite de définir des règles de conception des systèmes d’information qui soient pérennes pour de longues années et donc agnostiques sur le plan des technologies.
L’urbanisation SI présuppose que la cartographie applicative de l'existant ait été réalisée, mais il n’est cependant pas nécessaire d’avoir documenté l’architecture applicative en détail ; seule la nomenclature des applications et services est indispensable.
Un deuxième objectif de l’urbanisme SI est d’identifier les redondances fonctionnelles pour :
- Éviter d’en créer de nouvelles grâce à la réutilisation des ressources logicielles existantes lors du développement de nouvelles applications.
- Réduire les coûts de maintenance en effectuant une rénovation bloc par bloc, qui consiste à définir une nouvelle ressource qui se substitue aux anciennes et réponde aux divers cas d’utilisation.
- Consolider deux Systèmes d’Information comme dans le cas d’une fusion/acquisition.
- Préparer le déploiement d'une plate forme ESB (Enterprise Service Bus) à grande échelle.
"La pire erreur à faire est de constamment avoir peur de faire une erreur."
Elbert Hubbard
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 SI : Les indicateurs d’urbanisme SI sont avant tout une aide à la définition de plan d’actions.
Les indicateurs d’urbanisation SI sont avant tout une aide à la définition de plan d’actions sur les travaux d’urbanisme SI pour une entreprise, en fonction de sa stratégie.
En dehors de l’atteinte d’un premier niveau de maturité global, l’importance d’un indice ne réside pas dans sa valeur absolue, mais bien dans les travaux planifiés pour faire évoluer sa valeur en fonction de la stratégie engagée, et donc dans son évolution dans le temps. Ces indicateurs doivent inciter à plus de transparence dans le pilotage, la communication et la maîtrise des transformations du SI de l’entreprise.
En plus de la vision globale , il sera nécessaire à terme d’avoir une vision de ces indicateurs par zones ciblées du POS.
Les indicateurs d'urbanisation SI permettant d’évaluer le niveau de maturité de la démarche d’urbanisation, implicitement ils permettent également de mesurer le niveau d’urbanisation du SI.
Il est très clair que pour pouvoir piloter la transformation du SI de l'entreprise avec efficience, et donc pour pouvoir disposer d’indicateurs pertinents et utilisables, il est déjà nécessaire d’avoir démarré cette démarche d’urbanisation SI. Il est nécessaire d’atteindre « un premier niveau » d'urbanisme SI, de gouvernance et en particulier d’outillage, qui deviendra un élément déterminant pour la construction d’indicateurs et donc de tableau de bord efficace.
Les indicateurs sont organisés par activité de la démarche d’urbanisation.
Pour plus de précisions voir le site du Club Urba-EA.
"Même pour le simple envol d'un papillon tout le ciel est nécessaire."
Paul Claudel
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/
Ubanisation SI : circulation à accés réglementée
En Ubanisation SI, les constructions/destructions et l’entretien du POS sont réglementés :
- Chaque zone doit être rattaché à un et un seul des 5 domaines : Opération (1), Support (2), Pilotage & Contrôle (3), Échange (4), Référentiel (5) ;
- Chaque secteur fonctionnel (zone, quartier, ou bloc) doit avoir un libellé unique, et n’est rattaché qu’à un et un seul secteur fonctionnel de niveau supérieur (domaine, zone ou quartier) ;
- Chaque secteur fonctionnel est identifié par code unique (un entier, non signifiant, qui s’incrémente en fonction des ajouts)
- Chaque secteur fonctionnel doit être accompagné d’une définition (description succincte, non ambiguë, et auto porteuse).
- Le POS est un découpage fonctionnel ; il constitue une partition. C'est-à-dire qu’un objet métier, ou une fonctionnalité n’appartient qu’à un et un seul secteur fonctionnel, idéalement un bloc voire un quartier le cas échéant) du POS.
- Le POS n’est disponible que dans une seule version à un instant t. L’historique des modifications est conservé, mais il n’y a pas de version cible et de version existante. Il s’agit de décrire à un instant la meilleure vision fonctionnelle du moment. Par ailleurs, il peut être utile d’identifier (de marquer) les zones ou quartiers qui doivent faire l’objet d’une étude plus poussée (redécoupage, fusion, révision en profondeur, etc.).
Règles de gouvernance des secteurs fonctionnels du POS :
- À chaque zone du POS doit être associée un responsable de zone fonctionnelle (RZF), c'est-à-dire un référent métier chargé de définir la transformation stratégique de la zone en fonction de la stratégie métier
- À chaque zone du POS doit être associé un correspondant urbanisation.
- Consolidation au fil de l’eau des évolutions et demandes d’évolutions, dans des versions mineures, validées par les correspondants urbanisation.
- Production d’une version majeure annuelle du POS reprenant l’ensemble des modifications validées par les responsables de zones fonctionnelles.
- Les principes d’urbanisation conduisent de fait à un certain nombre de règles dans l’utilisation de ce POS pour construire l’architecture applicative d’une solution, par exemple : une application ne devrait couvrir qu’au plus un seul bloc.
Faire aisément ce qui est difficile aux autres, voilà le talent ; faire ce qui est impossible au talent, voilà le génie.
Henri-Frédéric Amiel
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/