Quelles considérations devraient être données pour et contre les «super» sites?

Mon entreprise envisage de consolider toutes ses applications et sites de niveau 1 (c'est-à-dire de production haut de gamme) en une base de code globale.

La théorie est que leurs autorisations, leur conception et leurs fonctionnalités globales peuvent être homogénéisées et gérées de manière centralisée.

Je n'ai aucune inquiétude à propos de cette approche car les structures de données qui sous-tendent chaque application sont très différentes, les règles métier sont complexes et uniques à chaque application et les bases de code globales pour les applications existantes sont extrêmement disparates et très négligées.

MODIFIER :

L'environnement actuel se compose de trois sites ASP.Net 1.1 qui ont à peine vu un véritable amour depuis leur première écriture (en raison principalement de l'absence de développeurs expérimentés dans l'entreprise) et d'une application MVC2 qui était également un site ASP.Net 1.1 avant d'être mis à niveau l'année dernière. Nous écrivons exclusivement en C #.

L'entreprise est assez petite, avec environ 50 employés; dont trois sont de vrais développeurs. La direction (même la gestion informatique) n'a pas d'expérience ou d'expérience informatique autre que la gestion de projet de projets informatiques (et donc une connaissance passagère de la terminologie et des impacts commerciaux).

Les applications sont principalement des services en ligne pour soutenir les produits vendus par la société. La société ne vend aucun logiciel directement.

Donc, pour exprimer toute cette situation dans une question raisonnablement spécifique et répondable: quelles sont les raisons convaincantes pour et contre d'essayer de rassembler tous vos systèmes dans une seule solution globale étant donné les conditions actuelles (c'est-à-dire l'ancienne base de code, les systèmes commerciaux complexes et les règles )?

Mauvaise idée

Cette réaction est basée sur les hypothèses suivantes:

1. Il y a beaucoup d'applications assez disparates qui sont homogénéisées
2. De nombreuses équipes travaillent sur les différentes applications
3. Aucun architecte logiciel respecté et faisant autorité ne gère activement les applications

Que se passera-t-il si vous continuez

Il y aura très probablement un effort initial consolidé pour tout rassembler sous une approche de conception unique. Cela montrera l'énorme effort requis pour que tout fonctionne de la même manière et peut se révéler impossible à mettre en conserve.

Si cela persiste, une sorte de référentiel centralisé contenant des données de configuration (par exemple, accès de sécurité, niveaux de journalisation, etc.) sera requis, à quel point quelqu'un indiquera l'évidence et dira

"Hé, pourquoi ne pas simplement adapter cette approche de configuration externalisée aux anciennes applications, ce sera beaucoup plus rapide?"

et un instant plus tard quelqu'un

"Et, comme nous refactorisons de toute façon, pourquoi n'appliquons-nous pas simplement une norme de conception pour chacun des domaines d'application?

jusqu'à ce que finalement

"Oh, et il y a beaucoup de code commun ici, pourquoi ne pas assembler des bibliothèques facilement partagées. Nous aurons probablement besoin d'une sorte de build d'intégration exécuté à intervalles réguliers, disons, tous les soirs."

À quel point tout le monde pousse un soupir de soulagement qu'un énorme monolithe n'ait pas été construit.

Nous y travaillons dans mon entreprise. Je pense que c'est possible et qu'il y a des avantages évidents (vous les avez mentionnés), cependant, ce sera probablement un projet de 5 à 7 ans au minimum absolu, et nécessite essentiellement tout ce qui doit être réécrit. Si vous pouvez vous déconnecter de quelque chose comme ça, alors je dirais allez-y. Sinon, préparez-vous pour une marche de la mort cauchemardesque.

Google le fait, donc c'est certainement possible .

Ce lien BTW est une présentation intéressante d'un googleur sur la façon dont ils gèrent leur base de code, l'intégration continue, les tests, etc.

Sans un engagement aussi fort envers l'outillage, cependant, comme Google l'a fait, vous risquez de souffrir.

La question clé ici est pourquoi ? Pourquoi la haute direction veut-elle faire cela? Quelles économies, quel effet de levier ou quel autre avantage espèrent-ils gagner?

Si vous pouvez résoudre suffisamment de ces problèmes de manière à atteindre leurs objectifs, vous pouvez très bien éviter la base de code unique qui vous concerne, tout en leur donnant le même résultat efficace.

Nous avons suivi un processus similaire. Nous avions un produit qui existait depuis un certain temps. L'année dernière, nous avons introduit un autre produit qui est 95% le même que le premier, avec 5% de différences parfois subtiles mais significatives, ces différences devant être développées et maintenues par une équipe distincte.

Lorsque nous avons commencé à travailler sur le nouveau produit, l'ancienne équipe a continué à apporter des modifications qui nous ont pénalisés dans ces 5%, car ils ne comprenaient pas le nouveau produit. Nous avons donc complètement forké ces 5% de code, ce qui nous a permis de terminer la première version à temps.

Ensuite, plus de travaux de maintenance ont commencé et nous avons constaté que nous apportions fréquemment des modifications presque identiques dans un code presque identique. L'ancienne équipe a également une bien meilleure compréhension du nouveau produit maintenant, donc nous réintégrons progressivement ce que nous avons bifurqué et trouvons des moyens architecturaux plus efficaces pour exprimer les différences.

Donc, lorsque vous dites que les structures de données sont différentes et que les bases de code globales sont disparates, la question que je poserais est de savoir si elles doivent être ainsi ou si c'est exactement comme cela qu'elles ont évolué en raison de l'opportunité du moment. De toute évidence, vous devez tenir compte des différentes règles et exigences commerciales, mais la clé est d'isoler ces différences dans un module aussi petit que possible. Si vous vous retrouvez souvent à implémenter la même fonctionnalité exacte pour plusieurs clients de manière légèrement différente pour différentes bases de code, la consolidation peut vraiment aider, et je pense que c'est le cas ou que la direction ne proposerait probablement pas cela.

Vous ne pourrez probablement pas consolider de nombreuses applications dans la même base de code car cela demandera un certain effort et pour les anciens programmes négligés, cela pourrait être beaucoup plus de travail que prévu initialement.

Cela dit, il n'y a rien de mal à avoir toutes vos applications dans le même référentiel de code , où chaque application a sa zone distincte. Cela vous permet, par exemple, de générer toute la documentation en ligne pour l'ensemble de la base de code dans une seule vue cohérente, ce qui est généralement une bonne chose car vous voulez autant de visibilité que possible.

Ceux qui décident de cela devraient considérer sérieusement POURQUOI ils veulent le faire et considérer combien de travail ils veulent dépenser pour y arriver.

S'il y a une seule chose qui rend le développement d'entreprise si inefficace et si cher, c'est l'illusion qu'il est possible de créer un système unique qui fait tout. Si vous aviez un seul propriétaire de produit qui comprend tous les détails du système et peut prendre toutes les décisions sans avoir besoin d'une semaine de réunions, cela pourrait fonctionner, mais je n'ai jamais vu cela se produire.

En général, vous serez mieux si vous le traitez plus comme un développement pour Internet - créez simplement votre propre application, admettant qu'en pratique, vous n'avez aucun contrôle sur tout ce qui se trouve en dehors de votre propre code. Vous pouvez obtenir à peu près toute la cohérence que vous êtes susceptible de vouloir avec OAuth et une API simple pour les paramètres utilisateur et un peu de CSS partagé.

Ceci est assez similaire à l'intention originale de SOA, mais si vous l'appelez, vous vous retrouverez avec un type différent de grand système à peine fonctionnel qui essaie de tout faire.

Ma première pensée est que ce serait un PITA total pour les sorties.

Il est beaucoup plus judicieux de se diviser en blocs de fonctionnalités gérables, ne serait-ce que pour éviter toutes les couches de gestion et d'approbation.

Décomposer des éléments communs en composants / services et normaliser de cette façon serait beaucoup plus facile à mon humble avis.

Vous pouvez aborder cela différemment, en utilisant une technologie d'intégration telle que Deliverance pour thématiser toutes vos applications Web de manière similaire. Fondamentalement, chaque application est toujours distincte; Deliverance utilise des règles XSLT pour chausse-pied leur sortie dans un modèle HTML statique que vous concevez. Cela permet d'appliquer un thème HTML / CSS statique relativement simple à une suite complète d'applications avec un minimum de problèmes.