Sourcing Driven Architecture

Qui n'a jamais subi de solution technique guidée par le fait que la seule équipe de développement disponible ou imposée par le métier impose la technologie qu'elle maîtrise et ceci en dehors de tout schéma directeur ? C'est le Sourcing Driven Architecture.
Des exemples réels
Là des développeurs travaillent sur un framework reconnu sur le marché mais non expertisé par les équipes de support, d'exploitation. D'autres testent sur Firefox alors que le browser d'entreprise est IE. et si vous ajoutez les deux, on se retrouve avec des performances déplorables et une réécriture à la clef. Ce n'est rien, le projet coûte juste le double à l'entreprise.
Ici, il est décidé pas des managers de haut vol d'utiliser une solution de datawarehouse contre toutes les études réalisés et on se retrouve sans expertises ou compétences internes capables d'accompagner le projet. . Et ailleurs, d'autres exemples, la liste est quasi infinie, vous pouvez partager vos cas en commentaire.
Les conséquences
Le non respect des schémas directeurs amène des dérives globales sur les cout-qualité-délais. La solution est inconnue collectivement, les écueils sont donc nombreux, non identifiables en amont ou au mieux non qualifiés et non quantifiés.
En l'absence d'expertise, chaque nouvelle difficulté amène une nouvelle dérive.

Andy Warhol - Shadows

Le coup est parti
Si l'on ne peut rien changer à l’architecture, il faut alors sécuriser l'approche par une gestion des risques, en établissant et déroulant les plans d'action associés :
- incompatibilités avec tel ou tel composant standard : la création d'une première application "coquille", vide fonctionnellement mais qui peut permettre de tester les composants techniques sur toute la chaine et sur toutes les plateformes
- absence de support : s'abonner aux communautés, devenir acteur des échanges en partageant vos expériences, et bien sur former les équipes
- préparer un plan de migration vers des technologies standard en sécurisant en premier les accès aux données et la logique métier
- en dernier recours ou si la technologie imposée s'avère pertinente, mener les travaux pour une inscription de la technologie au schéma directeur
- à chaque risque technologique identifié, traduire les impacts technologiques en impacts métier pour permettre les bons arbitrages
Comment éviter que cela ne se produise trop souvent ?
La gouvernance projet peut vous sauver : anticiper les projets, gérer un vrai capacity planning, former les équipes en continu (et oui, la formation peut faire partie de la gouvernance !)
L'architecte d'entreprise a aussi tout son rôle à jouer en :
- identifiant en amont les technologies pertinentes pour les métiers non encore mis en place, les faire inscrire au schéma directeur, évangéliser les managers, les équipes.
- rapprochant les équipes projet et transverse
- développant l'innovation interne qui rapproche les métiers et les acteurs SI
Enfin, d'autres leviers sont activables comme développer une stratégie de sourcing maitrisée et non subie en identifiant en amont des partenaires internes ou externes