Get best of the week

Lista de verificación para un arquitecto

A partir de este artículo, aprenderá cómo organizar el proceso de construcción de un desarrollo efectivo en una empresa digital distribuida, cómo hacerlo a través de la comunicación experta y cómo sucede esto con el ejemplo de MTS.

MTS, como muchas otras compañías modernas, ha sufrido la llamada transformación digital. En términos simples, el lanzamiento de procesos y productos digitales se ha convertido en nuestra prioridad.

Para mí, como técnico, esto significa que la dirección del negocio en la empresa depende completamente de la calidad de los sistemas de TI y su capacidad para evolucionar rápidamente.

Por supuesto, esta es una definición incorrecta, y los especialistas en marketing pueden discutir conmigo, ¡e incluso discutir! Pero para todo lo que lees a continuación, es suficiente.



Menos burocracia: desarrollo más fácil


Lo que ha cambiado: en primer lugar, el modelo de gestión de la empresa. Si antes los chicos de la arquitectura empresarial centralizada (arquitectura empresarial) verificaban cada proyecto, ahora publican una política técnica (un documento grande e inteligente) y capacitan a los arquitectos en él. Y cómo aplicarlo ya es un asunto personal de cada arquitecto de producto de más de cien equipos.
 
Por un lado, esto es bueno, menos burocracia, lo que simplifica enormemente el desarrollo. Por otro lado, todos los productos interactúan entre sí de una forma u otra, y un error en uno de ellos puede afectar al otro.

Por ejemplo, en Arquitectura de sistemas de software: trabajando con partes interesadas utilizando puntos de vista y perspectivas, Eoin Woods y Nick Rozanski escriben sobre el principio básico de seguridad, asegurar el eslabón más débil. Significa que si su panorama de TI tiene al menos un sistema de TI débilmente protegido, entonces todo el panorama de TI está en riesgo. Solo porque un atacante hipotético puede trabajar con impunidad en nombre de este sistema.

Hay muchos más ejemplos en los que es útil garantizar la calidad y la coherencia en el diseño y desarrollo de sistemas de TI.

Expertos introvertidos


Lo que se nos ocurrió: crear una comunidad para compartir conocimientos y difundir las mejores prácticas. La idea no es nueva ni revolucionaria, pero cumple con los requisitos y las características específicas del desarrollo de productos digitales.

  • — DevOps- support-;
  • , . , , ;
  • - , — . . -, ; -, ; -, ;
  • , ;
  • Organización de la rotación en un equipo de "auditores" para que tantos representantes del equipo como sea posible tengan la oportunidad de compartir conocimientos y experiencias.

Para comenzar el proceso, reunimos un equipo de entusiastas, desarrollamos una lista de temas de discusión para cada uno de los roles y capacitamos al equipo de nuestros auditores improvisados. Por cierto, el entrenamiento fue la etapa más difícil, porque a menudo muy buenos especialistas en nuestro campo también son muy introvertidos :-)

Cual es el resultado?




  • El proceso de investigación de equipos de productos ha sido bastante lento. En promedio, toma alrededor de 31 días para un equipo. Durante este tiempo, logramos comunicarnos con representantes de todas las áreas de las actividades del equipo, redactamos un informe memo y se lo explicamos al propietario del producto para que pueda planificarlo para la acción;
  • El resultado del trabajo depende mucho del experto. Por lo tanto, es importante que haya varios para cada rol: dos analistas, dos arquitectos, etc. donde uno ya ha realizado una serie de entrevistas y el otro solo está involucrado en la comunicación;
  • También es necesario adaptar constantemente la metodología de las entrevistas, ya que algunos temas pierden relevancia y, en su lugar, hay preguntas que nadie había pensado antes.

Por ejemplo, veamos los resultados de un estudio en la dirección de "Arquitectura".
 
Qué hemos hecho:

  • Comunicado con 20 equipos;
  • Cada uno pasó un promedio de 31 días. Dado que interactuamos simultáneamente con varios equipos, todo el proceso tomó seis meses;
  • Revelado 180 riesgos asociados con la arquitectura.

 Dentro de nuestros equipos, los riesgos se dividieron de la siguiente manera:


Riesgo 1: diseño

Es importante comprender que todos los sistemas de software que estamos examinando pasan por algún tipo de estricto control de calidad (por ejemplo, para sistemas de telecomunicaciones, el período de monitoreo es más largo que el período de desarrollo), pero no hay límites para la perfección y la eficiencia. .

Para comprender lo que consideramos riesgos, veamos el TOP-3 con ejemplos.

Para los equipos de productos jóvenes, la situación es bastante normal cuando la arquitectura del software se desarrolla de forma residual. Al principio parece que todo es simple, y el momento de los proyectos rara vez brinda la oportunidad de pensar seriamente en la organización de la arquitectura. Y luego entra en juego el método de diseño ascendente: cuando desarrollamos los componentes individuales de la solución, después de lo cual los reunimos en un solo conjunto.

Por ejemplo, decidimos hacer un producto digital para telemedicina. ¿Qué se necesita para esto?

  • Probablemente necesitemos un componente para las videollamadas entre el paciente y el médico; hacemos un componente para las llamadas;
  • A veces necesitas un chat regular, eso significa que hacemos un componente para el chat;
  • Necesitamos tomar el historial médico de los sistemas médicos automatizados: creamos el componente apropiado;
  • Necesitamos mantener un horario de médicos de guardia, también hacemos un componente para esto.

Etc.

Todo parece simple hasta que empezamos a armarlo todo. Y aquí hay problemas con la duplicación de funciones: por ejemplo, el chat y las videollamadas son aplicaciones muy cercanas en sí mismas (al menos desde el punto de vista del contexto de la interacción médico-paciente). Aquellos. El riesgo es que tenemos que rehacer nuestra aplicación de manera bastante significativa debido a la gran cantidad de código duplicado.

O problemas con el modelo de datos. Cada componente por defecto proporciona interfaces en ese modelo, lo cual es conveniente para almacenar y procesar este componente en particular, y no la aplicación en su conjunto.
 
Por lo tanto, vale la pena recordar una serie de reglas simples:

  • El método de diseño ascendente es bueno para proyectos pequeños con baja complejidad técnica, equipos pequeños y requisitos volátiles;
  • Para grandes proyectos y equipos, el método de diseño es de arriba hacia abajo, es decir, cuando primero diseñamos la imagen como un todo, y luego procedemos a la codificación.

Por lo tanto, antes de lanzarse de cabeza a un nuevo proyecto, hágase la pregunta: ¿a qué tipo pertenece?
 

Riesgo 2: Seguridad

Parecía que la seguridad se está pensando muy seriamente en estos días. Todos recuerdan banalidades como la necesidad:

  • Autenticar usuarios
  • autorizarlos a realizar acciones;
  • cumplir con el principio de privilegios mínimos;
  • mantener la confidencialidad de los datos;
  • mantener un registro de la auditoría de las acciones del usuario.

¡Pero aquí hay una sorpresa! Para los equipos que prestan servicios de automatización interna, esto no es tan obvio como para todos los demás. Parece que si la aplicación ya se está ejecutando en la red corporativa interna, ¿por qué protegerla todavía? De hecho, es necesario, especialmente si los datos con los que trabaja la aplicación se clasifican como personales. Sí, la probabilidad de que un intruso haya penetrado en la red interna es muy pequeña, pero no hay mucha protección.
 
Y con aplicaciones externas, también pueden surgir matices. Considere una aplicación web simple, puramente hipotética, de ejemplo, que autentica a un usuario con una contraseña. ¿Qué problemas puede haber?

  • La aplicación puede permitirle ingresar contraseñas que son demasiado simples, que luego son fáciles de aprender;
  • Es posible que la aplicación no esté protegida de las contraseñas de fuerza bruta (no hay captcha ni nada de eso);
  • . , - ;
  • URL- HTTP- ;
  • -, . , MD5 ;
  • - ;
  • - , . , , -;
  • - : , ..;
  • - HTTP-:

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


Por lo tanto, el riesgo aquí es que alguien obtenga acceso a datos que no están destinados a él. Y esto puede conducir a problemas en la aplicación. 
Estos son solo ejemplos de lo que puede hablar en el campo de la seguridad. Por supuesto, la opción ideal sería implementar el proceso de Ciclo de vida de desarrollo seguro, por ejemplo, como lo recomienda Microsoft .


Riesgo 3: rendimiento
 
Uno de los desafíos de crear rápidamente equipos de productos es una palabra de tres letras. Este es un MVP o producto valioso mínimo. Dichos equipos se esfuerzan por crear una aplicación lo antes posible, lo que comenzará a generar ingresos para la empresa, y dado que habrá muy pocos usuarios al comienzo de la aplicación, generalmente piensan en los parámetros de rendimiento en el último momento. Pero si la aplicación creada de repente se vuelve popular, entonces debe pensar qué hacer a continuación.

Las recomendaciones aquí son simples: el rendimiento de la aplicación es inversamente proporcional al número de solicitudes de recursos lentos. En consecuencia, todas las tácticas tienen como objetivo reducir el número de solicitudes o acelerar los recursos mismos. En este caso, los recursos se entienden como un procesador, memoria, red, discos; A veces también es conveniente considerar una base de datos o un servidor de aplicaciones como un recurso.
 
  • Primero, observamos si es posible hacer un caché de cliente en una aplicación distribuida para que cada vez que no solicitemos / calculemos los datos que necesitamos. Si esto es posible, ahorramos en solicitudes de red, cargando recursos del servidor y todo lo que hace allí.
  • Pero es una suerte muy rara, por lo que estamos buscando ver si podemos hacer un caché del servidor. Con él, el principio es el mismo que para el cliente, pero la ganancia de rendimiento es ligeramente menor, ya que las solicitudes de red continuarán;
  • , . , , , , (load balancer);
  • , . — My SQL Cluster Grid Edition Apache Ignite (Gridgain).

Bueno, por supuesto, debemos recordar que el caché en sí resuelve el problema del acceso a los datos, pero crea un nuevo problema con el algoritmo para su invalidación y precarga. Y en algunos sistemas, el almacenamiento en caché puede ser completamente inútil. Por ejemplo, en los sistemas CRM (Customer Relationship Management), es muy raro que pueda almacenar en caché los datos de los clientes. Un especialista que trabaja en la oficina se mueve muy rápidamente de un cliente a otro y el caché simplemente no se usa.

Por lo tanto, el riesgo aquí es que sin pensar primero en la estrategia de cómo "overclockearemos" nuestra aplicación, podemos terminar con costos muy altos por reescribir la aplicación en el futuro.

Resumiendo


En este artículo intenté hablar sobre cómo puede organizar el proceso de construcción de un desarrollo efectivo en una empresa digital distribuida a través de la comunicación experta. En nuestro tiempo de desarrollo remoto, tales procesos se vuelven especialmente relevantes. Le permiten destruir la ley de Conway , o al menos minimizarla.
 
Si decide crear sus propias listas de verificación, le recomendaría no hacer todo desde cero, sino tomar algo de la literatura existente. Por ejemplo, en arquitectura, el material de revisión Software Architect's Handbook por Joseph Ingeno ISBN es muy útil: 9781788624060

Mi informe se puede encontrar aquí

Autor del artículo: Dmitry Dzyuba, Jefe del Centro de I + D
 

More articles:


All Articles