Get best of the week

Liste de contrôle pour un architecte

À partir de cet article, vous apprendrez comment organiser le processus de construction d'un développement efficace dans une entreprise numérique distribuée, comment le faire grâce à une communication experte et comment cela se produit avec l'exemple de MTS.

MTS, comme beaucoup d'autres entreprises modernes, a subi la soi-disant transformation numérique. En termes simples, le lancement de processus et de produits numériques est devenu notre priorité.

Pour moi, en tant que technicien, cela signifie que la direction de l'entreprise dans l'entreprise dépend entièrement de la qualité des systèmes informatiques et de leur capacité à évoluer rapidement.

Bien sûr, c'est une mauvaise définition, et les spécialistes du marketing peuvent discuter avec moi - et même argumenter! Mais pour tout ce que vous lisez ci-dessous, c'est assez.



Moins de bureaucratie - développement plus facile


Ce qui a changé: tout d'abord, le modèle de gestion d'entreprise. Si auparavant les gars de l'architecture d'entreprise centralisée (architecture d'entreprise) ont vérifié chaque projet, ils publient maintenant une politique technique (un document volumineux et intelligent) et forment des architectes. Et comment l'appliquer est déjà une affaire personnelle de chaque architecte produit de plus d'une centaine d'équipes.
 
D'une part, c'est bien - moins de bureaucratie, ce qui simplifie considérablement le développement. D'un autre côté, tous les produits interagissent d'une manière ou d'une autre, et une erreur dans l'un d'eux peut affecter l'autre.

Par exemple, dans Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Eoin Woods et Nick Rozanski écrivent sur le principe de base de la sécurité - sécuriser le maillon le plus faible. Cela signifie que si votre paysage informatique comporte au moins un système informatique faiblement protégé, l'ensemble du paysage informatique est menacé. Tout simplement parce qu'un attaquant hypothétique peut travailler en toute impunité au nom de ce système.

Il existe de nombreux autres exemples où il est utile de garantir la qualité et la cohérence de la conception et du développement des systèmes informatiques.

Experts introvertis


Ce que nous avons trouvé: créer une communauté pour partager les connaissances et diffuser les meilleures pratiques. L'idée n'est pas nouvelle et peu révolutionnaire, mais répond aux exigences et spécificités du développement de produits numériques.

  • — DevOps- support-;
  • , . , , ;
  • - , — . . -, ; -, ; -, ;
  • , ;
  • Organisation de la rotation dans une équipe d '«auditeurs» afin que le plus grand nombre possible de représentants d'équipe aient la possibilité de partager leurs connaissances et leur expérience.

Pour démarrer le processus, nous avons réuni une équipe de passionnés, élaboré une liste de sujets de discussion pour chacun des rôles et formé l'équipe de nos auditeurs impromptus. Soit dit en passant, la formation a été l'étape la plus difficile, car souvent de très bons spécialistes dans notre domaine sont aussi de très bons introvertis :-)

Quel est le résultat?




  • Le processus de recherche des équipes de produits a été plutôt tranquille. En moyenne, cela prend environ 31 jours pour une équipe. Pendant ce temps, nous parvenons à communiquer avec les représentants de tous les domaines des activités de l'équipe, à rédiger un rapport de mémo et à l'expliquer au chef de produit afin qu'il puisse le planifier pour l'action;
  • Le résultat du travail dépend beaucoup de l'expert. Par conséquent, il est important qu'il y en ait plusieurs pour chaque rôle: deux analystes, deux architectes, etc.; où l'un a déjà mené une série d'entretiens, et l'autre n'est impliqué que dans la communication;
  • Il est également nécessaire d'adapter constamment la méthodologie de l'entretien, car certains sujets perdent leur pertinence et à leur place, il y a des questions auxquelles personne n'avait pensé auparavant.

Par exemple, regardons les résultats d'une étude dans le sens de "Architecture".
 
Qu'avons-nous fait:

  • Communiqué avec 20 équipes;
  • Chacun a passé en moyenne 31 jours. Étant donné que nous avons simultanément interagi avec plusieurs équipes, l'ensemble du processus a pris six mois;
  • Révélé 180 risques associés à l'architecture.

 Au sein de nos équipes, les risques ont été répartis comme suit:


Risque 1: conception

Il est important de comprendre que tous les systèmes logiciels que nous examinons passent par une sorte de contrôle qualité strict (par exemple, pour les systèmes télécoms la période de surveillance est plus longue que la période de développement), mais il n'y a pas de limites à la perfection et à l'efficacité .

Pour comprendre ce que nous considérons comme des risques, regardons le TOP-3 par des exemples.

Pour les jeunes équipes produits, la situation est tout à fait normale lorsque l'architecture logicielle est développée sur une base résiduelle. Au début, il semble que tout soit simple, et le timing des projets donne rarement l'occasion de réfléchir sérieusement à l'organisation de l'architecture. Et puis la méthode de conception ascendante entre en jeu - lorsque nous développons les composants individuels de la solution, après quoi nous les assemblons en un seul ensemble.

Par exemple, nous avons décidé de créer un produit numérique pour la télémédecine. Que faut-il pour cela?

  • Nous avons probablement besoin d'un composant pour les appels vidéo entre le patient et le médecin - nous faisons un composant pour les appels;
  • Parfois, vous avez besoin d'un chat régulier - cela signifie que nous créons un composant pour le chat;
  • Nous devons prendre les antécédents médicaux des systèmes médicaux automatisés - nous créons le composant approprié;
  • Nous devons garder un horaire de médecins en service - nous en faisons également un élément.

Etc.

Tout semble simple jusqu'à ce que nous commencions à tout assembler. Et ici, il y a des problèmes de duplication des fonctions - par exemple, le chat et les appels vidéo sont des applications très proches en eux-mêmes (au moins du point de vue du contexte de l'interaction médecin-patient). Ceux. le risque est que nous devions refaire notre application de manière assez importante en raison de la grande quantité de code en double.

Ou des problèmes avec le modèle de données. Par défaut, chaque composant fournit des interfaces dans ce modèle, ce qui est pratique pour stocker et traiter ce composant particulier, et non l'application dans son ensemble.
 
Par conséquent, il convient de rappeler un certain nombre de règles simples:

  • La méthode de conception ascendante convient aux petits projets à faible complexité technique, aux petites équipes et aux exigences volatiles;
  • Pour les grands projets et les équipes, la méthode de conception est descendante, c'est-à-dire lorsque nous concevons d'abord l'image dans son ensemble, puis procédons au codage.

Par conséquent, avant de plonger tête baissée dans un nouveau projet, posez-vous la question: à quel type appartient-il?
 

Risque 2: Sécurité

Il semble que la sécurité soit considérée très sérieusement ces jours-ci. Tout le monde se souvient des banalités comme de la nécessité:

  • Authentifier les utilisateurs
  • les autoriser à effectuer des actions;
  • respecter le principe des moindres privilèges;
  • maintenir la confidentialité des données;
  • tenir un journal de l'audit des actions des utilisateurs.

Mais voici une surprise! Pour les équipes qui font des services d'automatisation interne, ce n'est pas aussi évident que pour tout le monde. Il semble que si l'application fonctionne déjà sur le réseau interne de l'entreprise, alors pourquoi la protéger encore? En fait, c'est nécessaire, surtout si les données avec lesquelles l'application fonctionne sont classées comme personnelles. Oui, la probabilité qu'un intrus pénètre dans le réseau interne est très faible, mais il n'y a pas beaucoup de protection.
 
Et avec des applications externes, des nuances peuvent également apparaître. Prenons un exemple d'application Web simple et purement hypothétique qui authentifie un utilisateur avec un mot de passe. Quels problèmes peut-il y avoir:

  • L'application peut vous permettre de saisir des mots de passe trop simples et faciles à saisir;
  • L'application peut ne pas être protégée contre les mots de passe de force brute eux-mêmes (il n'y a pas de captcha ou quelque chose comme ça);
  • . , - ;
  • URL- HTTP- ;
  • -, . , MD5 ;
  • - ;
  • - , . , , -;
  • - : , ..;
  • - HTTP-:

  1. - session tokens , ;
  2. - session fixation- (. . session token );
  3. - HttpOnly Secure browser cookies, session tokens;
  4. - .


Ainsi, le risque ici est que quelqu'un accède à des données qui ne lui sont pas destinées. Et cela peut entraîner des problèmes dans l'application. 
Ce ne sont que des exemples de ce dont vous pouvez parler dans le domaine de la sécurité. Bien sûr, l'option idéale serait de mettre en œuvre le processus de cycle de vie de développement sécurisé, par exemple, tel que recommandé par Microsoft .


Risque 3: performance
 
L'un des défis de la création rapide d'équipes de produits est un mot de trois lettres. Il s'agit d'un MVP ou d'un produit de valeur minimale. Ces équipes s'efforcent de créer dès que possible une application qui commencera à générer des revenus pour l'entreprise, et comme il y aura très peu d'utilisateurs au début de l'application, ils pensent généralement au dernier moment aux paramètres de performance. Mais si l'application créée devient soudainement populaire, alors vous devez penser à quoi faire ensuite.

Les recommandations ici sont simples: les performances des applications sont inversement proportionnelles au nombre de demandes de ressources lentes. En conséquence, toutes les tactiques visent soit à réduire le nombre de demandes, soit à accélérer les ressources elles-mêmes. Dans ce cas, les ressources sont comprises comme un processeur, une mémoire, un réseau, des disques; Il est également parfois utile de considérer une base de données ou un serveur d'applications comme une ressource.
 
  • Tout d'abord, nous examinons s'il est possible de créer un cache client dans une application distribuée afin que chaque fois que nous ne demandions / calculions pas les données dont nous avons besoin. Si cela est possible, nous économisons sur les requêtes réseau, le chargement des ressources du serveur et tout ce qu'il fait là-bas.
  • Mais c'est une chance très rare, donc nous cherchons à voir si nous pouvons créer un cache de serveur. Avec lui, le principe est le même qu'avec le client, mais le gain de performance est légèrement inférieur, car les requêtes réseau iront toujours;
  • , . , , , , (load balancer);
  • , . — My SQL Cluster Grid Edition Apache Ignite (Gridgain).

Eh bien, bien sûr, nous devons nous rappeler que le cache lui-même résout le problème d'accès aux données, mais crée un nouveau problème avec l'algorithme pour son invalidation et sa précharge. Et dans certains systèmes, la mise en cache peut être complètement inutile. Par exemple, dans les systèmes CRM (Customer Relationship Management), il est très rarement possible de mettre efficacement en cache les données client. Un spécialiste qui travaille au bureau passe très rapidement d'un client à l'autre et le cache n'est tout simplement pas utilisé.

Ainsi, le risque ici est que sans penser d'abord à la stratégie de la façon dont nous «overclockerons» notre application, nous pourrions nous retrouver à des coûts très élevés pour réécrire l'application à l'avenir.

Résumer


Dans cet article, j'ai essayé de parler de la façon dont vous pouvez organiser le processus de construction d'un développement efficace dans une entreprise numérique distribuée grâce à une communication experte. À notre époque de développement à distance, ces processus deviennent particulièrement pertinents. Ils vous permettent de détruire la loi de Conway , ou du moins de la minimiser.
 
Si vous décidez de créer vos propres listes de contrôle, je vous recommande de ne pas tout faire à partir de zéro, mais de prendre quelque chose de la littérature existante. Par exemple, sur l'architecture, le document de revue Software Architect's Handbook de Joseph Ingeno ISBN est très utile: 9781788624060

Mon rapport se trouve ici

Auteur de l'article: Dmitry Dzyuba, chef du centre R&D
 

More articles:


All Articles