La mienne est une histoire de "réussite". Mon projet impliquait un site principal avec 4 sites satellites gérés et écrits indépendamment (sous-domaines avec différentes applications). Nous avions 4 bases d'utilisateurs principaux (toutes dans des répertoires actifs séparés) et aucune n'avait un système d'authentification commun. 3 étaient des applications bien établies et en silo et le 4ème satellite était tout neuf et avait copié une grande partie de sa base de code à partir de notre site le plus connu.
Objectif: Mettre en œuvre un système large identité de l' entreprise qui pourrait authentifier les comptes dans 4 domaines et complète gérer (avec self-service) représente dans 1 des domaines. Comme .Net était déjà implémenté sur les satellites, il fallait réécrire le site asp classique utilisé comme "introduction", ajouter une gestion des identités et tous les sites nécessiteraient des tests de régression pour s'assurer qu'aucun service n'était impacté.
Ressources: 3 architectes principaux - programmeur, gestion des identités, chef de projet. Environ 20 développeurs, 10 analystes, 10 testeurs.
Délai d'achèvement (du début à la fin): 1,5 ans
Lancement réussi: presque échec
Succès de longévité: Terrific
J'étais l'architecte de la gestion des identités. J'ai donc conçu les bases de données, les sous-systèmes et les interfaces logiques permettant à tous les satellites d'interagir. L’architecte «programmeur» était un développeur principal possédant une connaissance approfondie de tous les satellites et une expérience des applications et de leur développement jusqu’à maintenant.
Après plusieurs mois de collecte des exigences avec une cinquantaine de personnes différentes appartenant à différents départements de notre société, nous avons réussi à affiner l'architecture logique et à commencer à faire sauter du code. En raison de la nature du changement, nous avons dû réécrire notre propre site Web et toutes les fonctionnalités qu’il contenait dans .Net. Dans certains cas, il ne s'agissait que d'une refactorisation. Dans de nombreux cas, cela impliquait une réécriture complète des processus qui l’entouraient. Dans 2 cas, nous avons simplement abandonné la fonctionnalité d'origine car ce n'était pas important. Nous avons manqué deux délais dans le processus (mais nous avons fini par respecter le délai initial que j'avais proposé - à peine). Le jour du lancement, rien n'a fonctionné. Notre lancement ayant eu lieu un samedi, l'impact a été relativement minime, mais j'ai passé toute la journée à parcourir les journaux, à réécrire les morceaux et à évaluer la charge des serveurs. Plus de tests auraient pu aider.
À la fin du premier jour, tous les sites étaient opérationnels et tout fonctionnait (je dirais un succès nominal). Au cours des 2,5 dernières années, tout a été un succès retentissant. Le fait d'avoir tous nos sites sur une architecture commune avec une base de cadre commune a grandement facilité le développement et le travail entre développeurs. Les caractéristiques que j'ai écrites sur notre site il y a deux ans et demi (lors de notre réécriture) ont depuis été vues / adoptées par deux ou trois silos satellites.
Nous avons augmenté la journalisation, le suivi des utilisateurs, le temps d’utilisation, une application unique responsable de l’authentification / autorisation / identification. Les silos satellites peuvent se concentrer entièrement sur leurs applications et peuvent faire confiance à tout problème d'authentification / autorisation avec l'application de gestion des identités.
Notre projet comportait beaucoup de frustration, de chagrin d'amour et de catastrophes. En fin de compte, cela a porté ses fruits et plus encore. Je suis à 100% en accord avec l'évaluation de Joel Spolsky sur les réécritures en règle générale, mais il y a toujours des exceptions. Si vous envisagez une réécriture, vous devez simplement vous assurer que c'est exactement ce dont vous avez besoin. Si c'est le cas, préparez-vous à toutes les douleurs qui l'accompagnent.