Beaucoup de théoriciens, abondamment relayés par la littérature de référence sur les sujets d'urbanisation, démontrent par A+B que la réussite des projets d'urbanisaiton repose essentiellement sur l'adhésion du métier; et plus précisément sur un respect plus ou moins strict d'une démarche top down: en partant de la stratégie de l'entreprise on dessine une architecture business qui donne lieu à une architecture fonctionnelle et applicative (information system architecture des anglo saxon) puis à une architecture technique.

Cette belle théorie fonctionne bien sur le papier et effectivement elle présente une bonne démarche théorique, que tout architecte se doit de conserver en arrière pensée. Reste que la pratique vient perturber la belle mécanique.

Premiérement l'architecture technique est de fait assez peu décrite dans les ouvrages consacrés aux sujets de l'urbanisation et de l'architecture d'entreprise. Or cette architecture technique joue un rôle crucial: une infrastructure (j'entends par infrastructure l'ensemble machines, réseaux et équipements et OS / voire hébergement et SGBD) mal définie conduit en général à la catastrophe. Soit le projet d'urbanisation est impacté dans sa trajectoire (difficultés sur les plateformes de qualification, temps d'assemblage trop longs,...), soit et c'est encore pire, le service rendu ne respecte pas en production le contrat de service défini: qualité de service, scalabilité, etc.

D'autre part, et dans un tout autre ordre d'idée, la démarche d'urbanisation se heurte parfois à des difficultés de passage d'une couche à une autre. Si la stratégie de l'entreprise est en général (et c'est heureux !) clairement définie, la définition des axes stratégiques en projets métiers concrets prend parfois plus de temps... ce qui grippe notre belle mécanique d'urbanisation ! Le temps nécessaire à la formalisation des besoins métiers (la liste de nos exigences) puis leur traduction en architectures applicatives et référentiels de données (ou en architecture fonctionnelle) peut se révéler long. Et pendant ce temps, le SI existant continue de vivre, avec ses coûts et ses faiblesses.

Pour répondre à ces constatations, une démarche plus itérative peut se mettre en place. L'urbanisation peut se traiter dans un premier temps par un prisme technique, par des projets qui permettront de donner du souffle au SI dans l'attente de projets métiers formalisés. Ces projets techniques permettront aussi de continuer à développer de nouvelles fonctionnalités sur le SI actuel (pendant les travaux, le business continue...).

Quelques exemples d'axes d'amélioration purement technos qui peuvent donner de l'air à une DSI:

  • renouveler une partie de son matériel
  • changer de socle applicatif (OS, frameworks, serveurs d'application...)
  • préparer son infra à de nouvelles évolutions (réseaux, machines, hébergeur)
  • mettre en place des méthodologies nouvelles: agilité (XP, Scrum), intégration continue, TDD/TDR

Surtout n'ayons pas peur de faire des choix qui seront remis en question lorsque le programme d'urbanisaiton sera plus avancé, il coute parfois plus cher de faire du "jetable" que de ne rien faire. Surtout n'ayons pas peur de faire des projets IT, ils ont aussi des bénéfices à apporter à l'entreprise Surtout n'oublions pas de travailler en paralléle avec les métiers pour clarifier les besoins