urbanisation-si.com

Ce besoin d'évolutivité et de modularité peut être une exigence du métier. Le SI urbanisé doit être découplé de l'architecture technique, on doit pouvoir choisir des technologies différentes suivant les blocs (îlots applicatifs pouvant représentés des applications, progiciels, …) et cerise sur le gâteau on doit pouvoir choisir de manière indépendante les dates de déploiements. 

Le problème vient du fait qu'il existe des processus transverses à plusieurs domaines fonctionnels donc à plusieurs blocs applicatifs. Un des concepts de l'urbanisation est qu'il doit exister un référentiel unique et commun à toute l'entreprise des processus transverses et du modèle métier. 

Les différentes infrastructures d'intégration doivent être reliées par des passerelles assurant la continuité de transport et les transformations de format de données.  

Pour parvenir à un SI évolutif, agile et flexible, on applique de manière macroscopiques les concepts et les patterns de l'orienté objet. Les blocs (îlot, quartier, zone ou région) sont à un SI urbanisé ce que sont les objets (classes, composant, …) dans le monde de la conception objet. On retrouve la notion d'encapsulation des données et des traitements, la communication par messages, la généricité et les patterns de conception objet comme les fameux patterns du GoF ( paru dans le fameux ouvrage Design Patterns: Elements of Reusable Object-Oriented Software de Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides surnommé « Gang of Four », abrégé GoF  et publié en 1994 ). Parmi ceux-ci on trouve le pattern "proxy" permettant de rendre visible qu'une partie d'un objet et d'adapter un comportement en fonction du besoin du monde extérieur. Grace à ce pattern, les blocs peuvent évoluer de manière indépendante si on modifie des composants techniques ou le format de données à l'intérieur d'un bloc, la vision qu'en a les autres blocs restera inchangée car c'est la passerelle qui leur renverra toujours le même comportement adapté. 

Les blocs urbanisés collaborent entre eux comme le font des objets au sein d'un programme conçu en orienté objet. Un modèle externe d'une autre application du SI, ne doit pas parasiter notre domaine. Par exemple, pour récupérer un contrat, on peut accéder au référentiel contrat, mais pour répondre à la demande, le référentiel aura peut être besoin d'accéder à un objet externe en provenance d'une autre application (le référentiel produits d'assurance)  via un Web Service. Le référentiel et la couche d'infrastructure permettent de ne pas introduire de dépendance forte vers un modèle externe dont nous ne maîtrisons pas les évolutions et qui n'est probablement pas adapté à nos besoins. La bonne pratique est donc que tout élément introduisant une complexité non essentielle (non liée à notre problématique métier) doit être « emprisonné » dans une couche d’infrastructure. On doit toujours avoir un couplage faible comme la structuration d'une application en 2 sous-système, l'un dédié aux interactions avec l'extérieur et les standards de l'entreprise, l'autre  indépendante et responsable du cœur de métier. 

On verra que le mécanisme de l'urbanisation est fractale, on  vient de le voir ici, on peut appliquer les patterns de conception de l'orienté objet  au niveau macroscopique des blocs d'un système urbanisé afin de diminuer le couplage et d'augmenter la cohésion ce qui va dans le sens de l'évolutivité, la réutilisabilité et la maintenabilité. 

"Quand on porte un chagrin, il faut le porter loin pour le laisser un peu s'égrener sur la route"

Voir aussi :  http://urbanisation-si.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://urbanisation-si.eklablog.com/

http://bonnes-pratiques-si.eklablog.com/

http://rhonamaxwel.over-blog.com/