Comment faire évoluer le SI par bloc de la manière la plus indépendante possible ?

La réponse à cette question fait partie des enjeux de l'urbanisation des SI et correspond aux critères d'évolutivité et de modularité que doit avoir tous SI urbanisés dans les règles de l'art.
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"

urbanisation des SI, processus métier, règles métier, bonnes pratiques SI, MDA, génération d'applica

Urbanisation des SI, processus métier, moteur de processus, règles métier, moteur de règles, BPM, BRMS, SOA, génération d'application, MDA, méthode agile, Scrum, Kanban, bonnes pratiques SI

http://urbanisation-si.blog4ever.net/

urbanisation-si.over-blog.com

L'urbanisation des SI est une méthode de la maîtrise de la complexité. Changer l'entreprise pour rendre ses processus métiers plus agiles et augmenter sa capacité à évoluer sont les principa...

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

Urbanisation des SI

Le but de ce blog est d'expliquer de manière pédagogique les enjeux, concepts et innovations dans le domaine de l'urbanisation des SI.

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

Urbanisation des SI - L'urbanisation des SI est une méthode de la maîtrise de la complexité. Changer l'entreprise pour rendre ses processus métiers plus agiles et augmenter sa capacité à évoluer sont les principaux objectifs de l'urbanisation des SI.

Le super ordinateur Watson d'IBM champion du monde de Jeopardy! en 2011 capable de s"approprier des milliers de milliards de données afin de répondre à des questions en langage naturel. En 1997 ...

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

Abandonnez le classicisme, relookez votre SI - L'urbanisation des SI est une méthode de la maîtrise de la complexité. Changer l'entreprise pour rendre ses processus métiers plus agiles et augmenter sa capacité à évoluer sont les principaux objectifs de l'urbanisation des SI.

Par Rhona Maxwel dans Les moteurs de règles le 21 Septembre 2014 à 22:53 Pour concevoir directement une règle, l'expert métier peut utiliser différents outils, suivant le type de règles :1 ...

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