Comment centraliser les fonctionnalités au sein d'une entreprise?

Question

Au travail, nous utilisons/développons BEAUCOUP d'applications MS Access.

Chaque fois qu'un problème important doit être résolu dans l'entreprise, un nouveau projet MS Access est démarré. En conséquence, bien que ces projets résolvent des problèmes assez différents, ils peuvent en fait utiliser un code très similaire dans certaines parties de chaque projet. Il y a tellement de façons que vous pouvez extraire des clients de la même base de données, n'est-ce pas? Ou peut-être, de nombreux projets différents doivent travailler sur une liste de clients dont nous avons retourné le courrier. Donc, chaque fois que nous commençons un nouveau projet, nous avons écrit le code pour faire à peu près la même chose que ce qui a été fait précédemment.

De toute évidence, un moyen de «centraliser» cette fonctionnalité serait très utile. Supposons que le schéma de la base de données soit légèrement modifié, nous ne souhaitons pas devoir mettre à jour chaque application MS Access. Quel serait un bon moyen de le faire? Peut-être que beaucoup de gens diront "Tout d'abord, supprimez toutes les applications MS Access!" Bien sûr, il ne serait pas si simple de remplacer toutes nos applications MS Access existantes, donc ce serait bien que la fonctionnalité centralisée puisse être également consommée par MS Access. Sinon, j'apprécierais toujours les réponses qui ne fonctionneraient pas avec MS Access.

De plus, la solution devrait être dans .NET car nous sommes un magasin .NET.

EDIT

Nous utilisons .NET 3.5.

Les références à .NET 4.0 ne seraient pas utiles à ce stade.

Answer 1

Ce genre de choses n'est jamais simple du point de vue technique et organisationnel. Si je devais m'y attaquer, je verrais d'abord si nous pourrions être convaincus qu'une seule base de données ou peut-être une collection plus intégrée de bases de données centralisées répondraient aux besoins fonctionnels de l'organisation. Une fois satisfait de cela je verrais si je pourrais projeter de construire cette base de données et migrer des applications pour l'employer avec la révision du front-end totalement ou les modifier pour employer des données d'ailleurs (je crois que c'est possible avec MS Accès). Sinon, il pourrait être préférable de trouver une application d'entreprise qui fait tout ce que vous voulez et migrer vers cela. Je ferais écho à ce que Stephan dit, que vous aurez besoin de comprendre la fonctionnalité afin que vous puissiez la hiérarchiser et l'accommoder. Ce sera important pour déterminer si vous vous retrouvez avec quelque chose de beaucoup plus agréable ou juste une grosse boule de désordre par rapport à beaucoup de boules de désordre séparés.Ce sera également un changement culturel pour votre organisation puisque vous allez mettre le pouvoir hors des mains des gens et vous devrez les garder impliqués et leur vendre le concept sinon ils ne le feront pas. utiliser le système centralisé et reviendra à la construction de leurs propres bases de données Access. :(

Answer 2

La première étape consiste à créer une carte de la fonctionnalité utilisée dans quelle application. La centralisation signifie que vous devez développer un moyen de suivre les modifications apportées aux applications (dépendances). Votre situation est maintenant simple: tout est indépendant, donc un changement à l'un ne va pas casser une autre application. C'est beaucoup de travail, car le même changement doit être apporté à toutes les applications pertinentes. Avec un système plus centralisé, vous aurez besoin de quelques changements organisationnels: quelqu'un doit être responsable des changements dans chaque domaine fonctionnel. Les développeurs ne peuvent plus apporter de changement qu'ils aiment.

Answer 3

Arrêtez le saignement. Commencez à penser à cette prochaine application avec un état d'esprit d'utiliser les fonctionnalités existantes.

Jetez un oeil à une application existante qui a dans l'attente des demandes d'ajouter plus de fonctionnalités. Vous pouvez trouver le code existant utiliser.

Commencer à créer un moyen de mettre à jour le code plus automatisé dans vos applications. Il peut être difficile, mais je l'ai vu recomendations sur ce site pour divers outils pour aider avec le code vba.

Démarrer une stratégie que les applications Access arrivent à maturité et gagnent en adoption, elles migrent vers l'application centralisée (.NET). De cette façon, vous ne gaspillez pas de temps de développement sur les fonctionnalités de votre application principale qui ne sont jamais utilisées (en théorie, vous devriez pouvoir développer plus rapidement dans Access). J'ai vu des applications entières ne voient pas la lumière du jour pour diverses raisons. À ce stade, vous êtes reconnaissant qu'ils ont été construits dans Access.

Answer 4

+1 pour l'idée "prototype en accès". L'accès est un excellent outil pour le développement rapide d'une idée et réagit bien au fluage de la portée et le «hey pouvez-vous aussi le faire faire cela?" Les problèmes auxquels nous sommes tous confrontés. Une fois que la fonctionnalité est arrivée à maturité et verrouillée, vous pouvez migrer vers une nouvelle application et en effet l'application d'accès devient votre spec/benchmark. Une façon de faciliter cela est d'avoir un serveur SQL semi-ouvert, donc l'ajout de nouvelles tables, etc n'est pas un mélange complet de la bureaucratie. Si l'application devient candidate à la «migration», il suffit de déplacer la base de données du serveur SQL semi-ouvert vers son propre serveur ou vers le serveur principal pris en charge.

Answer 5

J'ai travaillé dans une situation comme celle-là auparavant. MSAccess peut être une solution tellement rapide et flexible que tout le monde peut facilement répondre à ses besoins spécifiques sans avoir à attendre une équipe de développement. Pour le résoudre correctement et centraliser tout le développement sera coûteux (en temps, argent et personnel). Une structure centralisée comme celle-ci exigera également beaucoup de rigidité, ce qui peut inciter les gens à utiliser leurs propres petits projets d'accès pour obtenir ce dont ils ont besoin, quand et comment ils en ont besoin.

Je suggère un référentiel de code. Vous pouvez même le faire dans Access et le mettre sur un lecteur partagé. :) Maintenant, quand quelqu'un a besoin d'une fonction spécifique, il peut voir si elle existe avant de créer la sienne. Si vos données proviennent d'un référentiel sql ou oracle, disposez de quelques procédures ou vues stockées qui sont des compilations d'ensembles de données généralement utilisés par les utilisateurs. Ceux-ci peuvent être consultés à partir des bases de données d'accès sans coûter le temps de "recréer la roue".

Bonne chance.