Le bloc constitue l’élément de base interchangeable et autonome du SI, présentant une forte cohérence.

Les blocs correspondent à 3 types de finalités :

1. Le bloc métier qui est propriétaire des données et des traitements qui les mettent à jour,
   
2. Le bloc d’assemblage qui n’est pas propriétaire des données mais seulement des règles de gestion de l’assemblage
   
3. Le bloc d’interfaces (échanges)
   

La taille du bloc doit tenir compte à la fois :

• du besoin de cohérence du bloc
  
• du besoin d’autonomie conduisant à un nombre limité d’échanges avec les autres blocs (couplage faible)
  

Le bloc est propriétaire :

• des entités définissant les objets racine et l’objet souche qui le constituent ainsi que leurs règles de gestion
  
• des services d’accès, de consultation, de modification, de création, de suppression et de contrôle des données et des relations dont il est propriétaire.
  

Les travaux de modélisation reposent sur deux notions principales inspirées des concepts de l’objet:

1. Le concept de macro - objet




• Un bloc (unité atomique et autonome) est un macro - objet dans la mesure où il regroupe à la fois les données et les traitements permettant de les manipuler.


• Un bloc est propriétaire de ses données et de ses traitements.


• Un bloc ne peut accéder aux données encapsulées dans un autre bloc qu’en faisant appel aux services que propose celui-ci.




2. La logique de cohérence forte et de couplage faible:
   
   
   Cette logique permet de découvrir les blocs.
   
   • Ils sont définis par rapport aux données et traitements présentant une forte cohérence, c’est-à-dire des relations fortes (ex : contraintes d’intégrité)
   
   
   • Ils sont définis également par rapport à un couplage faible, c’est-à-dire une frontière bien délimitée avec les blocs connexes
   
   
   
   

Les éléments de la modélisation

Les éléments de la modélisation fonctionnelle

• Systèmes
  
• Domaine
  
• Zones
  
• Quartiers
  
• Bloc fonctionnelle
  

Les éléments de modélisation applicative

• Portail
  
• Systèmes
  
• Application
  
• Modules
  
• Blocs applicatifs
  
• Procédure fonctionnelle
  
• Blocs applicatifs
  

La démarche d'urbanisation confronte les besoins de la M.O.E (Maîtrise d'Oeuvre) et de la M.O.A (Maîtrise d'Ouvrage). Cette confrontation apporte des solutions en termes d'architecture du nouveau système informatique aux besoins de l'entreprise.
Les objectifs de l'entreprise se concrétisent en activités ou en processus métiers, quant à l'architecture, elle concerne l'architecture fonctionnelle et l'architecture logique du système informatique.
La démarche d'urbanisation peut être vu selon trois axes qui convergent :

• Axe stratégique qui consiste à définir les indicateurs liés aux processus et à suivre et motiver la démarche de l’urbanisation.



• Axe Fonctions qui consiste à identifier les grandes fonctions de l'entreprise. Ces fonctions représentent le modèle d’activité de l’entreprise.
  
  Les grandes fonctions définissent des fonctions métier.
  
  Ci-dessous un exemple de découpage des grandes fonctions :
  
  
  
  
  
  
  
  
  
  



• Axe processus qui consiste à découper les macro processus en processus métiers. Cet axe permet d’élaborer une cartographie ou une matrice des processus métiers selon leurs types. Cette matrice offre une visibilité sur les relations entre processus et les données susceptibles d’être échangées.

Lorsqu’elle atteint une certaine taille, une grande ville est confrontée, tout comme un système d’information, à des problèmes de maîtrise de la complexité.

Pour y répondre, la ville est divisée en arrondissements et quartiers avec des règles et objectifs communs à la ville et spécifiques aux arrondissements ou quartiers.

Urbaniser le système d’information de l’entreprise consiste donc à le structurer de façon cohérente et modulaire, à l’instar de la ville et de ses quartiers, en définissant les différents niveaux d’agrégation, en répartissant les éléments système d’information et les responsabilités qui y sont liées par niveaux, et en édictant les règles communes ou spécifiques.

Pour construire un nouvel immeuble, aligner une rue, rénover ou construire un quartier, l’urbaniste établit des plans et des normes.
La construction peut alors s’opérer de manière autonome sous réserve du respect des règles décidées au niveau de la rue, du quartier ou de la ville.
Le plan d’urbanisme permet d’assurer la cohérence entre la rénovation des quartiers anciens et la création de nouveaux quartiers.

De la même façon, le projet informatique (l’immeuble) s’insère dans un système d’information (le quartier ou l’arrondissement) qui s’insère, lui même, dans le système d’information global de l’entreprise (la cité) dont il faut avoir préalablement dessiné les plans (le plan d’occupation des sols) et précisé les normes.
Le plan d’urbanisme du système d’information de l’entreprise permet alors refontes ou aménagements progressifs.

• Le processus opérationnel est un enchaînement des activités à valeur ajoutée qui aboutit à délivrer un produit ou service au client.
  Identifier les processus opérationnels pour une entreprise consiste à identifier les couples produits clients.


• Le processus de pilotage vise à optimiser la prise de décision des acteurs le long de la chaîne opérationnelle


• Le processus de support soutient le processus opérationnel en optimisant ses ressources.

Système informatique

Ensemble structuré des applications et des données et des infrastructures automatisant, pour tout ou partie, les fonctions et informations. Partie automatisée du système d’information.

Système d’information

Ensemble structuré des fonctions et des informations utilisées par les processus et mis en œuvre par des hommes ou des automates

Stratégie Métier

Orientation des activités à long terme classées par business unit et processus métier.

Processus

Ensemble des enchaînements d’activités réalisées avec des moyens et selon des règles en vue de générer un produit de sortie (objectifs des processus) destiné à satisfaire les clients (finalité des processus)

Le plan de l’urbanisme se définit via trois concepts :

• Zone,
  
• quartier,
  
• îlot.
  

Ces trois concepts permettent de cartographier le système d'Information.

Les zones

Le concept des zones décrit le plus haut niveau de distribution des processus et des données.

Il correspond au découplage des grandes fonctions de la chaîne de valeur de l'entreprise.

On peut identifier les zones suivantes pour un plan d'urbanisation :

• Échange
  
• Ressource
  
• Pilotage
  
• Gisement
  
• Référentiel
  
• Opération
  

Les Quartiers

Le concept des quartiers décrit un niveau intermédiaire de distribution des fonctions et des données à l’intérieur de chaque zone.

Il correspond à une focalisation autour des grands concepts mis en jeu par l’activité de l’entreprise.

Les Ilots

Le Modèle des îlots décrit le plus bas niveau de répartition des fonctions à l’intérieur de chaque quartier.

Il correspond à un regroupement des fonctions automatisables (tirées de l’analyse des processus).

L’Architecture Orientée Services vient avec des promesses dont l’Agilité, l’Ouverture et l’interopérabilité.
L’Architecture Orientée Services n’a de sens que si un alignement métier a été planifié et aboutit à un résultat définitif.

Cet alignement métier ou en d’autres termes l’urbanisation du Système d’Information assure un cadrage et un pilotage aux architectures de ce Système d’Information. Le but «étant de segmenter l’architecture de l’entreprise en se basant sur les spécificités métier en premier lieu.

Je pourrais comparer l’urbanisation du Système d’Information en question, au plan d’urbanisme des villes. Cet urbanisme est organisé en quartiers, rues, …, afin de préparer les moyens de communication entre ces éléments (égouts, routes, réseau téléphonique, etc). Le plan d’urbanisme divise les villes en zones, au niveau de chaque zone, un quartier. Les zones et les quartiers communiquent et échangent des flux (transport, électricité)

Il est de même du Système d’Information, il faut identifier ses zones fonctionnelles, ces dernières doivent être autonomes du point de vue Métier.

L’urbanisme promeut la gouvernance du S.I et l’alignement métier.

Si je résume, l’Architecture Orientée Services offre le caractère indispensable d’Agilité, l’urbanisation quant à elle fournit le mode d’emploi pour mettre cette agilité en place.

L’urbanisation guide et oriente l’Architecture Orientée Services, c’est donc une phase très critique, qu’on soit en phase de mise en place du système d’Information ou en phase de migration de ce dernier.

Un des buts et idéaux d’une démarche d’urbanisation consiste à rationaliser les éléments fonctionnels dont le périmètre est identique, et à éviter leur multiplication, afin de supprimer toute redondance aux quatre coins du système d’information, et disposer ainsi d’un SI homogénéisé, pilotable, plus simple et moins coûteux. C’est également l’une des volontés qui doit présider à la construction d’une SOA. La possibilité de définir des services d’entreprise et des services transversaux semble aller dans cette direction, impression renforcée par la mise à disposition, autour des Services Web, d’un annuaire central d’entreprise au format UDDI.

Pour parvenir à cette objectif, il convient de cartographier efficacement les différents services fournis dans l’entreprise. L’organisation d’une plate-forme de services et la recherche de réutilisabilité demandent de prendre de la distance par rapport au système, donc à modéliser la cible avant de la mettre en œuvre. Cette modélisation ne doit pas être perçue comme un travail détaché des réalités de la mise en œuvre : on privilégiera un outillage capable de s’interfacer avec le terrain (les serveurs opérationnels d’exécution) et de se synchroniser avec eux sur la base des standards adéquats, notamment ceux évoqués plus haut dans ce document (BPEL, XML-Schemas, SOAP, WSDL, UDDI…).

Cette cartographie vise à recenser l’ensemble des services constitutifs du socle SOA. Dans le cadre de l’établissement d’une architecture multi-dimensionnelle et multi-niveaux, la cartographie vise également à catégoriser les services pour mieux en qualifier le périmètre, la portée et l’utilisation :

certains services sont fonctionnels et liés à des applications et d’autres sont techniques.
certains services n’ont qu’une portée locale, applicable à un bloc fonctionnel identifié.
d’autres sont transversaux et applicables à l’ensemble de la plate-forme.

Il existe autant d’axes d’analyse qu’il existe de méta-données pour qualifier un service dans
l’annuaire qui les référence :

• Le type ou la classe du service : service de présentation, d’accès aux données…


• Le sujet adressé : applications, données, flux, réseau, systèmes, postes de travail…


• Le bénéficiaire du service : ressource machine et/ou personne physique, avec les droits d’accès correspondants,


• Le type d’usage,


• Les technologies utilisées couvrant le service, notamment dans le cadre de la constitution d’un référentiel d’entreprise.

Cette liste n’est pas exhaustive, et selon les différentes vues souhaitées, l’outil de cartographie établira les différentes matrices de liaisons croisées et d’analyse d’impact.

On sait qu’un travail de recensement et de cartographie des services en amont est un pré-requis indispensable au maintien de l’évolutivité de la plate-forme et aux décisions d’alignement métier, ainsi qu’aux rationalisations et réutilisations nécessaires à l’obtention du retour sur investissement. Cependant, une fois ce travail effectué, il ne doit pas devenir obsolète : les modifications de modélisation doivent être rapidement intégrées, et les changements au niveau du terrain doivent être reportés, après validation, au niveau de la cartographie.

Cet outil sera donc équipé d’un véritable référentiel avec des passerelles de synchronisation au niveau du terrain pour assurer une mise à jour bidirectionnelle, sur la base des standards de l’industrie, établis ou en passe de l’être (XML-Schemas, BPMN (Business Process Modelling Notation), BPEL (Business Process Execution Language)…). La présence d’un référentiel dynamique et interrogeable doit être recherchée. Ainsi les outils de modélisation plats, sans référentiel (Powerpoint, Visio…) devraient ainsi être évités, au profit de produits tels que Aris d’IDS Scheer, Isiman de Keyword, Corporate Modeler de Mega, System Architect de Popkin Software, et bien d’autres encore. Ces produits ne sont pas tous à l’heure actuelle fournis avec la capacité de modéliser et stocker une bibliothèque de services ; mais tous ont un méta-modèle personnalisable qui peut s’adapter à celui défini par une entreprise pour la représentation et la catégorisation de ses services.

On comprend mieux dans quelle mesure une démarche de construction de SOA s’inscrit en plein dans le volonté généralisée de rationalisation et de gouvernance que recherchent les entreprises.

La réutilisabilité des services est plus concrète que n’a jamais pu l’être celle des composants. La construction d’une SOA à un niveau d’entreprise demande de l’organisation et de la méthode, relayés par des outils adaptés, pour :

• cartographier l’utilisation des services, les liens existants entre les services invoqués, les versions des services et des processus utilisés, dresser des analyses d’impact…


• orchestrer l’exécution des processus et des chorégraphies, tracer le résultat de cette exécution, notifier des erreurs et anomalies rencontrées, délivrer un reporting régulier en mesurant la qualité de service…

Sans ce travail parallèle, il est évident que la multiplication des services et des niveaux de services entraînera une absence de visibilité tant au niveau de la conception, de l’exécution que de l’exploitation, qui serait préjudiciable au système d’information tout entier et serait vécu comme un véritable retour en arrière.

Or, signe des temps, la demande est actuellement très forte en ce qui concerne l’outillage pragmatique d’une démarche d’urbanisation vers un champ d’application à mi-chemin entre organisation de SOA et intégration d’applications. Qu’en déduire ? Que le lien entre modélisation/cartographie et orchestration est plus fort que jamais, relayé par l’émergence de standard et le besoin d’organiser réellement et concrètement les systèmes d’information dans le sens d’une plus grande rationalisation et d’une meilleure réutilisation des services existants.

Le découplage entre Système d’Information et Système Informatique, qu’introduit la SOA, et le besoin constant envers les outils de modélisation, tend bien à prouver que la mise en œuvre de SOA constitue un facteur facilitant de l’alignement métier.