Pendant évaluations d’structurenous identifions généralement dette-technique problèmes au sein d’un système ou d’un projet distinctive. Cependant, l’influence de la dette approach va souvent au-delà de la portée d’un seul système ou projet. Dans notre travail, nous appelons cette forme de dette approach dette approach de l’entreprise. Comme toute dette approach, la dette approach des entreprises consiste en des choix opportuns à court docket terme, mais souvent problématiques à lengthy terme. Ignorer la dette approach de l’entreprise peut avoir des conséquences importantes. Les architectes doivent donc y être attentifs et ne doivent pas la laisser être négligée ou ignorée lorsqu’ils la rencontrent. Dans cet article, je donne des exemples de dette approach d’entreprise (et du risque qu’elle représente) tirés de projets réels.
En tant qu’évaluateurs d’structure, nous avons l’opportunité distinctive de voir les risques architecturaux du level de vue de l’entreprise (par opposition au niveau du projet), en particulier si nous participons à des évaluations pour un portefeuille de projets. Au cours des dernières années, le SEI a tiré parti Recherche approach sur la dette SEI pour institutionnaliser les pratiques de dette approach dans une organisation disposant d’un vaste portefeuille de systèmes évalué à plus de 100 hundreds of thousands de {dollars}. Cette organisation possède un portefeuille de plus de deux douzaines d’purposes métier et go well with un modèle de gouvernance informatique décentralisé. Les exemples de cet article proviennent de notre travail en tant qu’évaluateurs d’structure sur ces projets.
Pour rendre la dette approach d’entreprise plus concrète pour les lecteurs, je donne trois exemples d’éléments et de conséquences de la dette approach d’entreprise. Dans un prochain article, j’aborderai plus en détail la documentation et la résolution de la dette approach de l’entreprise.
Exemple 1 : Une answer fragile d’intégration système
Dans cet exemple (Determine 1), les exigences du projet nécessitaient l’échange de données entre les purposes A et B. Les équipes du projet ont pris la décision architecturale d’utiliser un schéma de base de données partagé comme mécanisme d’échange de données. Cette approche séduisait les équipes à l’époque automotive elle était facile à mettre en œuvre, mais plus tard, il est devenu évident que cette answer était fragile. En particulier, lorsque l’équipe A a apporté une modification indépendante au schéma partagé sans se coordonner avec l’équipe B, l’software B a également dû apporter des modifications pour s’adapter et vice versa.
Determine 1 : Une answer fragile d’intégration système
Les équipes ont trouvé une answer de contournement qui a aggravé les choses. Les développeurs ont copié les données dans leurs environnements locaux pour éviter de modifier le schéma. Les équipes créées extraire, transformer, charger (ETL) travaux pour maintenir la synchronisation des données qui n’étaient pas fiables. Lorsqu’une tâche ETL échouait, les données restaient dans un état incohérent. Par exemple, après des échecs, les utilisateurs obtenaient des réponses de requête historiques différentes de l’software A et de l’software B. La livraison des fonctionnalités du projet était également ralentie automotive les modifications de schéma nécessitaient une analyse fastidieuse.
Les deux équipes étaient satisfaites du schéma partagé, du moins à court docket terme. Cependant, à partir de notre évaluation de l’structure, qui nous donne une perspective externe et au niveau de l’entreprise, nous avons pu voir que les conséquences négatives de cette answer étaient susceptibles d’augmenter avec le temps à mesure que les fonctionnalités se développaient. Pour cette raison, nous avons recommandé de remplacer la answer fragile de schéma partagé par une Interface de programmation d’purposes (API) pour l’échange de données d’software.
Les équipes ont facilement accepté la answer approach proposée, mais l’organisation n’a pas agi pour résoudre le problème initialement pour plusieurs raisons. Premièrement, dans cet environnement de gouvernance décentralisée, aucune des équipes ne se sentait responsable du travail de refactorisation. Deuxièmement, réparer une answer d’intégration fragile n’était pas considéré comme une priorité pour l’entreprise. Par conséquent, les propriétaires de produits n’alloueraient pas de fonds de projet à l’effort de refonte. Bien qu’aucune mesure ne soit prise à court docket terme, nous avons créé un poste de la dette approach—une description écrite du problème et des conséquences. Documenter le problème comme un élément de dette approach a permis à l’organisation de le rendre seen et de travailler sur une stratégie à plus lengthy terme pour retravailler la answer. Je fournirai des exemples de ces éléments de dette approach que nous avons créés dans un futur article de weblog.
Exemple 2 : Options hétérogènes d’accès et de contrôle d’authentification
En tant qu’évaluateurs d’structure pour cette organisation, nous avons examiné plusieurs architectures de projet dans lesquelles les équipes mettaient en œuvre une capacité d’authentification et de contrôle d’accès dupliquée. Capacités de duplication incluses
- possibilité de stocker des informations sur les rôles et les autorisations
- capacité administrative pour ajouter, modifier et supprimer les autorisations des utilisateurs
- génération de jeton sécurisé
- possibilité de définir et d’appliquer des politiques de contrôle d’accès pour les companies logiciels (appels API)
Une capacité commune d’accès et d’authentification n’a pas été fournie, de sorte que les équipes individuelles ont mis en œuvre cette capacité de manière hétérogène. La determine 2 illustre trois kinds de mise en œuvre différents que nous avons observés.
Determine 2 : Options hétérogènes d’accès et de contrôle d’authentification
- L’software A est une software héritée développée comme un monolithe, qui est obsolète et présente plusieurs inconvénients. Par exemple, les équipes ont écrit un code d’authentification personnalisé au lieu d’utiliser des composants de fournisseur sécurisés et vérifiés. Nous avons également constaté que les informations sur les rôles et les autorisations étaient codées en dur et que des identifiants de mot de passe moins sécurisés étaient utilisés à la place des jetons pour la certification. Enfin, il n’y avait pas de contrôle de sécurité au niveau de l’software au niveau de la couche d’accès aux données.
- L’software B était une implémentation plus moderne avec un fashion architectural basé sur les composants. Dans cette implémentation, il y avait une séparation de la capacité d’authentification et de contrôle d’accès en composants (par exemple, l’administration des rôles et des autorisations, l’authentification, la génération de jetons, le contrôle d’accès). Ces composants étaient partageables par plusieurs consommateurs.
- L’software C avait une structure orientée companies. Les companies utilisés étaient l’administration des rôles et des autorisations, l’authentification, la génération de jetons et le contrôle d’accès.
Ces options hétérogènes d’authentification et de contrôle d’accès ont finalement entraîné une augmentation des risques de sécurité et de upkeep. Par exemple, sans module d’administration commun, les comptes d’utilisateurs ont été désactivés (plutôt que supprimés), exposant l’organisation aux attaques par usurpation d’identité. De plus, la modification des autorisations des utilisateurs impliquait l’exécution de scripts de base de données manuels sujets aux erreurs pour mettre à jour plusieurs bases de données. Au lieu de stocker les données d’identification de l’utilisateur dans une seule supply de données sécurisée et faisant autorité, ces données ont été stockées au hasard dans diverses bases de données de projets opérationnels.
Encore une fois, les équipes du projet n’ont vu aucun problème avec cette state of affairs. Du level de vue de l’entreprise, cependant, les risques de sécurité et de upkeep étaient clairs. Pour rendre cette dette seen, nous avons créé un élément de dette approach et travaillé avec l’organisation pour qu’elle soit priorisée. Je partagerai l’élément de dette approach que nous avons créé pour cet exemple dans le prochain article.
Exemple 3 : problème d’actualisation de l’entrepôt de données
Il y a des années, l’organisation a investi dans la development d’un vaste entrepôt de données. Lors des évaluations d’structure, nous avons constaté que plusieurs équipes n’utilisaient pas le reporting de l’entrepôt de données. Au lieu de cela, ils exécutaient de nombreuses tâches de base de données complexes la nuit pour copier les données historiques dans leurs bases de données locales. Nous avons constaté que la trigger principale de cette approche était un décalage de 48 heures dans la mise à jour des données vers l’entrepôt de données. Les utilisateurs n’étaient pas satisfaits de l’affichage des données obsolètes, ce qui laissait l’entrepôt de données sous-utilisé et ajoutait une complexité inutile à l’écosystème.
Encore une fois, cette state of affairs plaisait aux équipes du projet. Une fois analysés du level de vue de l’entreprise, cependant, les risques commerciaux et de upkeep/coûts sont devenus clairs. Par exemple, la copie de données a provoqué une explosion de l’utilisation du stockage de données. Se conformer aux exigences de gestion des enregistrements est devenu un cauchemar après que la copie intensive a rendu les sources de données faisant autorité peu claires. Le personnel d’exploitation et de upkeep se plaignait de passer du temps à surveiller et à mettre à jour le réseau complexe de tâches de synchronisation ETL. En conséquence, nous avons créé un élément de dette approach documentant le problème et recommandé une refonte pour réduire le temps de latence de l’entrepôt de données.
Regarder vers l’avant
Dans cet article, j’ai décrit trois exemples de dette approach d’entreprise. Nous avons illustré, par des exemples, la nature insaisissable de la dette approach d’entreprise et l’influence potentiel que la dette approach d’entreprise incontrôlée peut avoir sur une organisation. Dans nos exemples, l’influence des éléments ETD n’a pas été ressenti au niveau approach. Cependant, l’ignorer entraînait des risques multi-projets ou à l’échelle de l’organisation. Ceux-ci ont à leur tour augmenté les coûts, l’efficacité ou les risques de sécurité pour l’organisation. J’ai également discuté du rôle de l’architecte dans l’software des pratiques de dette approach pour suivre et remédier à la dette approach. Dans mon prochain article, je décrirai remark nous avons corrigé ces exemples et remark nous avons guidé les équipes pour appliquer la dette approach et les pratiques de gouvernance pour motiver l’motion.
