Six péchés capitaux de l’architecture d’entreprise

Faire fonctionner une entreprise n’est pas une tâche facile. L’essor des outils logiciels a rendu de nombreuses parties du flux de travail plus rapides, plus fluides et plus cohérentes pour tout le monde, mais pas pour les personnes qui doivent faire fonctionner le logiciel. C’est comme la phrase bien connue sur un canard glissant sur un étang. Tout semble calme au-dessus de l’eau, mais sous la surface, ils bougent constamment les pieds.

Pour les utilisateurs finaux occasionnels, les gestionnaires et les dirigeants, le travail d’un architecte d’entreprise est comme par magie. L’ordinateur effectue tout le travail sans fin de synchronisation, d’intégration et de stabilisation, vous laissant libre de vous concentrer sur ce que vous faites le mieux. Mais le bon fonctionnement des portails Web, des piles de collaboration et des omnitools de référentiel cache des défis sans fin. Pour toute évolutionl’architecture d’entrepriseC’est encore un nouveau monde plein de tâches et de responsabilités que personne ne peut pleinement appréhender.

architecte d’entrepriseest encore au stade de l’apprentissage et de l’expérimentation de diverses choses. Nous en apprenons davantage sur ce qu’il faut faire et, surtout, sur ce qu’il ne faut pas faire.Nous sommes en train de trouver des moyens de maintenir notre pile logicielle en fonctionnement et de rendre la vie professionnelle de chaque employé de l’entreprise aussi simple que possible.beaucoupfaire une erreurje me suis engagé, vous pouvez continuer à faire des erreurs encore et encore. Cela est dû en partie au fait que le travail est très technique et complexe, mais également aux erreurs suivantes commises par les architectes d’entreprise :

Stocker trop (ou pas assez) de données

Les développeurs de logiciels ont tendance à tout surcharger. Si vous le pouviez, vous mettriez en cache toutes vos données, enregistreriez tout et conserveriez des copies de sauvegarde de l’évolution sans fin de votre entreprise, mais ces gigaoctets et métaoctets s’additionnent. Même le stockage froid à faible coût proposé par certains fournisseurs de cloud devient coûteux lorsque de grandes quantités de données deviennent disponibles.

Pire encore, à mesure que le lac de données se remplit, il devient de plus en plus difficile de trouver les bons éléments.« Raiders/L’arche perdue »C’est la même chose que l’Arche qui apparaît à la fin du film. Techniquement, toutes les informations sont là, mais pouvez-vous les trouver ?

Le problème est que conserver trop peu d’informations s’accompagne de son propre ensemble de problèmes et de problèmes. Certaines entreprises ont tenté de définir des politiques de conservation des données aussi perturbatrices que le permettent les réglementations. Mais ensuite, même si vous essayez de trouver des réponses à toutes vos questions, vous vous retrouvez dans un état d’amnésie où le dossier n’existe pas. Personne ne comprendra rien.

Trouver l’équilibre exact peut s’avérer impossible. Tout ce que nous pouvons faire, c’est trouver une bonne architecture de stockage de données, stockant les bonnes informations dans une structure facilement accessible pour éviter de fouiller dans le noir à la recherche d’un interrupteur.

Trop s’appuyer sur une seule plateforme (ou en adopter trop)

Le moyen le plus simple de créer des logiciels d’entreprise consiste à exploiter la puissance des outils, des portails et des plates-formes créés par des sociétés externes. Plus de 90 % du travail se fait en signant un bon de commande et en écrivant un petit code de colle.

Cependant, compter sur des sociétés extérieures pour construire des éléments clés de votre entreprise comporte de nombreux risques. Certaines sociétés de capital-investissement peuvent acheter des sociétés extérieures, licencier tous les meilleurs employés et augmenter les prix parce qu’elles savent que l’autre partie ne s’en sortira pas. Tout instancier sur une seule plate-forme commence soudainement à tourner terriblement mal. Personne ne se souvient plus de la simplicité et de la cohérence qui accompagnent une seule plateforme, une seule interface.

Adopter plusieurs plateformes peut être tout aussi pénible. Les équipes commerciales peuvent promettre que leurs outils sont interopérables et suivent les protocoles standards de l’industrie, mais c’est loin d’être suffisant. Même si chaque plateforme stocke les données en version bêta de données SQL, certaines utilisent MySQL, d’autres PostgreSQL ou Oracle.

La bonne réponse ne vient pas facilement. Trop de plates-formes peuvent conduire à un projet impossible, comme la Tour de Babel. Trop peu peut entraîner un risque de blocage du fournisseur et la difficulté d’ouvrir les e-mails de renouvellement de contrat. Le coût de tout développement en interne est une autre affaire.

Externalisation trop (ou pas assez) vers le cloud

Le cloud a grandement facilité la vie des architectes d’entreprise. Si vous avez besoin d’une machine de taille spécifique, nous la aurons disponible en quelques minutes. Pas besoin de rédiger des bons de commande ou de trouver de l’espace de stockage. Tout ce que vous avez à faire est de donner votre numéro de carte de crédit à la société cloud et vous n’avez rien d’autre à faire.

Si les avantages d’être disponible en quelques minutes ou secondes sur n’importe quelle machine sont certainement évidents, le plus gros inconvénient est son coût. Le cloud computing est étonnamment coûteux par rapport à la gestion en interne. Les coûts sont souvent plus élevés que prévu, c’est pourquoi de nombreux directeurs financiers examinent chaque mois leurs factures cloud avec appréhension.

Cependant, si vous le gérez vous-même, vous devrez gérer le personnel, les centres de données, etc., et en payer les coûts. La liste des problèmes associés et des réglementations à respecter s’allonge encore et encore, et les faibles coûts deviennent une joie de courte durée.

Certains architectes d’entreprise connaissent un grand succès dans le cloud. Si vous constatez une légère hausse de la demande chaque semaine, mois ou année, il suffit de faire tourner un serveur pendant quelques minutes ou quelques heures pour gérer la charge, ce qui revient beaucoup moins cher que de faire quelque chose en interne. Toutes les autres entreprises se demanderont si elles ont investi trop ou pas assez dans le cloud.

Adopter (ou ignorer) les frameworks avec fanatisme

Face à la complexité des piles d’entreprise d’aujourd’hui, certains grands architectes ont construit des cadres pour aider à les organiser.Par exempleFormat d’architecture de groupe ouvert (TOGAF). Il s’agit d’un cadre stratégique qui construit presque tout ce dont une entreprise a besoin. TOGAF fournit un certain nombre de lignes directrices et de bonnes pratiques, notamment la méthodologie de développement d’architecture (ADM) et l’architecture Compliance Framework (ACF). autres,ZachmanCadreDes approches telles que l’architecture d’entreprise fédérale ont leurs propres règles et réglementations pour la construction de piles.

Le plus grand avantage est peut-être la cohérence. Si tous les membres du personnel connaissent les techniques et la théorie, il sera plus facile de maîtriser le logiciel. Les données et le code sont (généralement) organisés et se situent tous dans des endroits prévisibles.

Mais certaines personnes vont peut-être un peu trop loin. Ils ne se contentent pas d’adopter les règles, ils en deviennent fanatiques. Vous devrez lire attentivement le cahier des charges et prendre des décisions selon les règles. Malheur à ceux qui s’écartent du chemin.

Même si tout le monde est fanatique du framework et que les réunions de planification de bureau sont remplies de personnes prêtes à suivre les règles, d’autres problèmes peuvent survenir. Même si l’équipe rejette le code open source parfait simplement parce qu’il ne rentre pas dans le cadre architectural souhaité, ou si le fournisseur propose une meilleure option, elle ne peut pas le développer dans la bonne direction. pas ce qu’on leur a donné.

Adhérer avant tout à la méthodologie

Les frameworks fournissent une structure, mais ils peuvent également servir de couverture à un comportement bâclé, paresseux et même malveillant. Vous attendez peut-être qu’un membre de votre équipe remplisse le formulaire TOGAF approprié, ce qui peut prolonger la décision. La frontière est mince entre les règles qui soutiennent l’amélioration et les procédures lourdes qui sont lourdes.

Un gars avec qui je travaillais croyait en la méthodologie Agile et il l’a tellement gâché que l’équipe est devenue moins qu’Agile. Il connaissait tous les rituels des réunions et était doué pour regrouper de nombreux points d’histoire dans des « sprints » afin de refactoriser le code qui venait d’être écrit la semaine dernière. L’équipe ne semblait pas avancer très vite dans la reconstruction de la méthode de paiement par carte de crédit qu’elle était censée proposer, mais en regardant le graphique des points Agile gagnés à chaque sprint, le travail de bureau semblait progresser le plus rapidement du pays.

Vous avez besoin d’un moyen d’organiser votre flux de travail de développement. Les programmeurs peuvent débattre Agile vs Waterfall pendant des jours. Si votre projet est trop vaste pour être réalisé par une seule personne en un week-end, vous aurez besoin d’une certaine stratégie.

Des problèmes surviennent lorsque nous commençons à croire à la méthodologie plus qu’à ce que l’on voit. Dans ce cas, les codeurs intelligents peuvent manipuler le système pour obtenir d’excellents résultats même si leur code ne fait pas grand-chose.

Suivez (ou ignorez) les tendances

Les développeurs adorent s’appuyer sur les dernières idées et modèles d’architecture d’entreprise. Parfois, ils ont de la chance et les nouvelles tendances répondent à leurs besoins. L’application d’un développeur est un excellent exemple de la façon dont un pionnier a eu l’idée.

Cependant, dans la plupart des cas, ce n’est pas le cas. Le cas d’utilisation est peut-être similaire à l’application qui a inspiré la tendance, mais après un peu de triche. Pendant ce temps, les équipes de développement s’efforcent de maintenir leur code en phase avec les tendances. Parfois, d’énormes blocs de code parfaitement compatibles sont supprimés simplement parce qu’ils ont été écrits pour répondre à un objectif auparavant populaire.

Le problème ici est qu’ignorer complètement les tendances peut aussi être mortel. En effet, heureusement, le code est resté fidèle à sa version originale, en utilisant des bases de données, des formats, des normes de codage et des protocoles qui fonctionnent bien. Mais si le monde entier a suivi une tendance, tous les fournisseurs, fabricants d’outils et futures recrues ont suivi la même tendance. À un moment donné, une tendance ou un mode devient une norme, ou pire encore, une exigence légale de s’y conformer.

Les architectes d’entreprise n’ont aucune chance. Si vous suivez les tendances, vous deviendrez l’esclave des tendances créées par les masses, et si vous les ignorez, vous serez laissé pour compte. Tout ce que EA peut faire, c’est veiller à faire le bon choix pour la pile technologique de l’organisation et le personnel informatique qui doit rester au courant des tendances.