Mesa redonda "Arquitecto del proyecto de TI", septiembre de 2018

El 5 de septiembre, Moscú organizó la Mesa Redonda "Arquitecto de Proyectos de TI" en el HSE. El organizador de la mesa redonda, Maxim Smirnov, es un blog sobre arquitectura y el canal de Facebook .

Estoy muy contento de que se lleven a cabo tales eventos. Convertirse en un arquitecto genial fue y sigue siendo mi sueño. Durante mucho tiempo no entendí cómo se desarrollan los arquitectos en general, cómo desarrollar y qué direcciones elegir para que conduzcan a la arquitectura, y creo que tales preguntas surgen no solo para mí. Es genial que haya una comunidad donde puedas venir y hacer preguntas a los arquitectos.

En la mesa redonda, se presentaron 4 informes de 15-20 minutos, después de lo cual hubo preguntas de la audiencia y discusión.

Los informes fueron breves y al grano, y la discusión fue muy animada y extensa.



Además, mis notas durante los informes.

Informe 1
Habilidades clave de un arquitecto de decisiones en proyectos desde cero

Gennady Kruglov
Arquitecto SOA certificado, ctn

Como parte de la presentación, se tocaron las principales etapas del proceso arquitectónico:

1. Participación empresarial.
2. Involucrando a los ingenieros.
3. Prototipos
4. La elección del estilo arquitectónico y la pila tecnológica (microservicios, monolitos, SOA).
5. Desarrollo de proyectos de arquitectura.
6. Demostración al cliente.
7. Diseño de soluciones.
8. Documentación de soluciones de arco.
9. Supervisión arquitectónica.

Aspectos destacados de la actuación:

Es recomendable hacer un prototipo para mostrarlo a la empresa. Siempre que sea posible, es necesario involucrar a diferentes partes al elegir un estilo arquitectónico: desarrolladores, seguridad, operación. Al diseñar un boceto, debe crear diferentes secciones de la arquitectura: negocios, tecnología, seguridad.

Si es posible, es necesario atraer a personas que luego trabajarán directamente con esta parte del sistema.

Después de la discusión con las partes interesadas, se demuestra un prototipo. Si el proyecto comienza, se realiza un estudio más detallado de cada nivel de arquitectura.
Durante el desarrollo, la sincronización con el arquitecto es necesaria para verificar que el proceso sigue la ruta elegida.

Las habilidades que, según el orador, son necesarias para el arquitecto:

• Habilidades de comunicación (persuasión, negociación).
• Presentaciones
• Lluvia de ideas y talleres
• Conocimiento de estilos arquitectónicos.
• Amplios horizontes de la tecnología moderna (es importante comprender las fortalezas y debilidades)
• Habilidades de diseño y aplicación
• Habilidades de desarrollo utilizando diferentes marcos, productos y lenguajes de programación.
• Conocimiento de los marcos de documentación de decisiones.
• Comprender los diferentes tipos de SDLC (ciclo de vida de desarrollo de sistemas)
• Amplia red de conexiones profesionales.
• Habilidades en la gestión de equipos de desarrollo.

Informe 2
Soporte arquitectónico para proyectos de TI.

Dmitry Romanov, ITSK

Diseño de soluciones de TI, soporte arquitectónico de proyectos, alrededor de 80 proyectos al año, alrededor de 50 arquitectos están involucrados en el proceso.

El servicio del arquitecto jefe de TI determina la política técnica en el campo de TI, que fue implementada por los arquitectos de proyectos de TI. Respondiendo a la pregunta donde el arquitecto generalmente reúne la experiencia necesaria, Dmitry indicó las siguientes fuentes:

1. Experiencia: crear sistemas similares
2. Colegas: alguien dentro de la compañía o en otras compañías
3. Proveedor - consultas con desarrolladores
4. Foros temáticos
5. Technopark - aprobaciones o sandbox sobre la base de Technopark

Teniendo en cuenta la necesidad del papel de arquitecto en ITSK, Dmitry señaló que se necesita el arquitecto de un proyecto de TI para que, por ejemplo, no haya una situación en la que un proyecto se haya completado durante 1 año, luego hayan trabajado durante seis meses y se hayan dado cuenta de que no hay escala, y luego se rehicieron durante 2 años. Una comprensión clara es importante para poder implementar la arquitectura propuesta. Dependiendo de la metodología de gestión del proyecto, en ITSK el arquitecto ingresa al equipo (si es ágil) o ingresa al grupo de expertos del proyecto.

Informe 3
Arquitectura en los proyectos de TI de la organización: enfoque principal

Ivan Lukyanov, Departamento de Tecnologías de la Información de Moscú, producto "Servicios estatales y MFC"

Biografía profesional del orador: desarrollador de Diasoft, jefe del equipo de desarrollo (BSC Praha), consultor líder (Neoflex), jefe del departamento de arquitectura y estrategia en Alfa Bank, jefe del departamento de desarrollo de arquitectura (DIT).
Ivan recomienda comenzar con una descripción de la arquitectura existente (tal como está), crear una arquitectura objetivo (para ser) y analizar la diferencia entre los puntos "dónde está la organización ahora" y "dónde quiere ir la organización" describen los pasos para llevar el sistema al estado objetivo.
El enfoque principal de los proyectos de TI en arquitectura:

• Declaración del problema comercial a resolver: el arquitecto debe asegurarse de que la tarea comercial esté bien planteada, descrita en una forma adecuada para el diseño, acordada por las personas responsables de la empresa
• Visión del camino: por los esfuerzos de los arquitectos en la organización, la arquitectura objetivo de la organización debe desarrollarse para las necesidades específicas del negocio. La arquitectura de destino debe desglosarse en pasos concretos (proyectos) para lograrlo.
• Diseño: todas las soluciones están diseñadas teniendo en cuenta la arquitectura objetivo desarrollada. La arquitectura de destino se implementa de forma incremental de un proyecto a otro. El arquitecto aprueba la decisión con respecto a la arquitectura.
• El proceso de implementación del proyecto: la organización debe tener un proceso que incluya el análisis y la descripción de las tareas del negocio, el desarrollo de la arquitectura objetivo y el proceso de diseño (el desarrollo y la operación no fueron cubiertos en el informe). El proceso debe ser acordado por todas las partes involucradas y respaldado por la gerencia.
• Apoyo metodológico para el proceso de implementación del proyecto: muy a menudo es el arquitecto quien se convierte en la figura sobre cuyos hombros se encuentra el desarrollo de una metodología para implementar proyectos de TI en una organización, teniendo en cuenta la formulación de una tarea y diseño de negocios. Como parte de este trabajo, se pueden hacer ajustes al proceso existente de implementación de proyectos de TI en la organización (si hubo uno antes) o la creación de un nuevo proceso desde cero (si no existiera). El resultado del trabajo metodológico es el proceso descrito y los documentos de respaldo, formalizados en forma de plantillas.

La compañía ahora ha desarrollado su propia metodología, que incluye plantillas utilizadas en el trabajo de documentos. Se utilizaron los principios de TOGAF y Gartner.

Se aprobaron los principios arquitectónicos, se desarrolló el documento "Solución arquitectónica y tecnológica", que describe los requisitos comerciales para las soluciones y el proyecto para su implementación.

Características del arquitecto:

• Sociabilidad La comunicación con la gerencia, con los artistas intérpretes o ejecutantes, con el apoyo, con los gerentes y evaluadores es importante. El arquitecto debe desempeñar el papel de un traductor: traducir del lenguaje de los negocios al técnico y viceversa.
• Un requisito previo es la experiencia del desarrollador (bueno, si también análisis).
• Respeto a los colegas.
• Desarrollo continuo

La arquitectura no es un monumento inmóvil moldeado en granito, sino una visión viva y en evolución de lo que queremos lograr en términos de apoyo comercial.

Informe 4
Arquitecto de proyectos de TI: uno de los posibles puntos de vista

Evgeny Aslamov Aslamov, Arquitecto principal, Lanit Group of Companies.

El camino de Eugene hacia el rol de arquitecto: desarrollador, analista, gerente de proyectos. Durante el cuento, el autor planteó varias cuestiones relacionadas con el papel del arquitecto en el desarrollo personalizado: qué lo rodea, qué hace y cómo lo hace.

En opinión de Eugene, al hablar sobre el arquitecto en el desarrollo personalizado, dependemos de varios factores: el tiempo, el presupuesto, el equipo, la complejidad y el volumen de las tareas. Como regla general, en proyectos complejos (varios miles de escenarios de usuario, integración con un par de docenas de sistemas, grandes volúmenes de datos, requisitos severos para alta disponibilidad y recuperación ante desastres), un equipo de arquitectos cierra las tareas arquitectónicas. En proyectos más modestos, una persona puede hacer frente a estas tareas y el arquitecto no siempre se dedica a las tareas: su función se puede combinar con otras funciones: el desarrollador principal o el analista.

Un arquitecto, como cualquier miembro del equipo, trabaja en un determinado contexto. Un resumen de dicho contexto:

Cliente

• la gestión más alta (en cualquier caso, lo suficientemente alta para decisiones clave) del cliente a cargo del proyecto;
• comités de clientes (arquitectura, diseño, operación, etc., sucede mucho);
• servicio o departamento de especialistas en seguridad de la información;
• empleados del cliente que necesitan un sistema que "queme" el proyecto;
• realidades: una rutina bastante banal, factor humano, problemas de procedimiento, desacuerdos menores, etc.

El equipo

• Gerentes
• Analistas
• desarrollo;
• DevOps
• servicio de calidad;

El contrato

• plazos de entrega;
• presupuesto
• cotizaciones legales;
• nuevas tecnologías, enfoques, chips que realmente quiero aplicar;
• tradiciones: funciona y es bueno, todo está bien con nosotros: qué cambiar y cosas por el estilo.

Como parte del contexto, un arquitecto o grupo de arquitectos hace lo siguiente:

• Forma los límites para el equipo en el que el proyecto se desarrollará y vivirá. En primer lugar, estamos hablando de límites derivados de requisitos no funcionales.
• Forma, respalda y actualiza soluciones arquitectónicas teniendo en cuenta las opiniones de los principales interesados.
• Trabaja como intérprete: se traduce del técnico al ruso y viceversa. Actual tanto para el cliente como para el equipo. El arquitecto debe comprender todos los aspectos del proyecto (junto con los principales analistas y el gerente del proyecto) y poder explicar su relación con las partes técnicas.
• Hace muchas preguntas desagradables. Sucede que algunas decisiones se tomaron sin la participación de uno u otro miembro del equipo. Esto es normal Si se ha hecho algo y está afectando o puede afectar la arquitectura del sistema, entonces necesita averiguar las razones, determinar si necesita cambiar algo ahora, prever algunas medidas para el futuro, o simplemente puede grabarlo y dejarlo hasta tiempos mejores.

Respondiendo a la pregunta "¿Cómo hace esto?", Eugene primero se refirió al tema del desarrollo de soluciones arquitectónicas. Se identificaron varios componentes que ayudan en esta tarea:

• Experiencia y analogías. Este es uno de los activos más importantes del arquitecto. Y debe incrementarse constantemente, no para estancarse en un proyecto, tecnología, etc.
• Horizontes No puede usar su propia experiencia: la experiencia de colegas, la experiencia de las comunidades, los estándares.
• Prototipos. En el caso de utilizar un nuevo, no probado o con riesgos visibles, la creación de prototipos es necesaria. Al mismo tiempo, es importante formular de manera correcta y precisa las preguntas que el prototipo debe responder, de lo contrario, solo puede empeorar la situación.
• Protegiendo tus decisiones. Ante el equipo del proyecto, ante el comité de arquitectura (el suyo o el del cliente), frente a usted. Como una de las soluciones puede ser la introducción (elementos completos o individuales) de ATAM - Método de análisis de compensación de arquitectura . En varios de nuestros proyectos, por ejemplo, la protección de decisiones se implementa como la presentación de decisiones clave a colegas fuera del proyecto para obtener opiniones y comentarios alternativos.

En lugar de una conclusión: una de las tareas informales de un arquitecto, y de cualquier especialista que ama su trabajo, es popularizar el conocimiento, las tecnologías, los enfoques y las habilidades que permitirán al equipo resolver problemas en un proyecto de manera más eficiente y con mayor comodidad.

El artículo de Eugene sobre habr “ Estamos preparando un proyecto en Sparx Enterprise Architect. Nuestra receta ".

Preguntas y respuestas

Lo siguiente fue una sección de preguntas y respuestas, las más recordadas se pueden leer a continuación.

¿De dónde vienen los arquitectos?

Gennady:
Arquitectos de software: ex líderes de equipo o esos líderes o desarrolladores líderes.
Dmitry:
Los arquitectos son tomados de desarrolladores de consultores, con amplia experiencia.
El desarrollador puede hablar y dibujar presentaciones: arquitecto de soluciones.
Eugene
En general, desde cualquier parte: desde el desarrollo, las pruebas, la gestión de proyectos, etc. Pero, en cualquier caso, algunas especializaciones técnicas ayudan: no tienen que desarrollarse desde cero.
Un ejemplo de experiencia personal: un estudiante del departamento de mecánica de la Universidad Estatal de Moscú, una persona inteligente y sociable sin enfermedad de las estrellas, fue llevado a la compañía Lanit. Trabajó un poco en análisis, desarrollo, comunicación con el cliente. Como resultado, se convirtió en un arquitecto aplicado en nuestra empresa.
Ivan:
De los desarrolladores. Si hay un buen desarrollador, entonces puede continuar profundizando en los lenguajes de programación, desarrollar más profundamente. Pero si, en algún momento, sintió curiosidad por cómo nació la tarea técnica, quién analiza, quién toma la decisión de si se debe hacer o no, entonces esto es una señal de que el especialista se ha embarcado en el camino de un arquitecto novato. El siguiente nivel de curiosidad es cómo nace una solución en su conjunto, a nivel empresarial. ¿Cómo puede mostrarle al jefe de la organización que lo necesita y qué no? Al describir el papel del arquitecto, Gregor Hohpe utiliza la metáfora del ascensor . Cada piso donde se detiene el elevador es un cierto nivel en la organización: el primer piso - la sala de máquinas - estos son desarrolladores, producción; piso superior - gestión de la organización. Dando vida a la arquitectura, el arquitecto se comunica en cada piso (del primero al último) y en cada piso tiene que hacer frente a diversas dificultades: tecnológicas, políticas, de comunicación.

El arquitecto puede recopilar la información necesaria y transmitirla a cada nivel. De hecho, actúa como mediador entre las partes involucradas.

¿Cómo se debe compartir la autoridad entre el gerente del proyecto y el arquitecto?

Debe haber un equilibrio entre la autoridad. La autoridad del arquitecto radica en la parte técnica, y el gerente del proyecto en la parte organizativa.

En el caso de que el equilibrio se desplace hacia el RP, puede obtener el proyecto a tiempo, pero no funciona o no es escalable. Y, si está dirigido al arquitecto, puede obtener un proyecto maravilloso cuando nadie lo necesita. Así es como se responden las preguntas "¿A quién amas más: mamá o papá?"

¿Cómo ser arquitectos corporativos que tienen un gran flujo de proyectos diferentes?

Ivan:
En organizaciones grandes, más de 2,000 personas hacen una arquitectura corporativa y es casi imposible seguirla. En DIT, una división se hace en productos (servicios), cada producto tiene su propia pila de tecnología, su propia arquitectura. En cuanto a la arquitectura corporativa, los accionistas la necesitan más para que comprendan hacia dónde se dirige la organización en términos de desarrollo de arquitectura. Para este propósito, el papel del arquitecto jefe de TI a menudo se destaca en las organizaciones, cuya tarea principal es determinar el panorama general de la arquitectura corporativa.

¿Cómo se construye la interacción entre el arquitecto del proyecto y el arquitecto corporativo?

La comunicación es importante Necesita construir comunicación y simplemente comunicarse. Un arquitecto de proyecto puede no necesitar conocimientos de arquitectura corporativa, pero es importante saber con quién estará la integración y cuál será el impacto. Es importante hacer comités de arquitectura, es posible conocer no solo arquitectos corporativos, sino también diseñadores.

Puedes verlo en términos de valor: quién aporta más valor. Si las soluciones funcionan, entonces hay valor. La arquitectura empresarial en sí misma no aporta valor, pero aporta valor a través de una solución de arquitectos que ya implementan tareas específicas.

Nadie necesita generalistas: cada vez menos son personas que no saben nada de todo. Es mejor poder responder preguntas específicas, por ejemplo, si RabbitMQ es suficiente aquí o si se necesita Kafka.

¿Cómo se organizan los repositorios arquitectónicos empresariales?

¿Hay modelos complejos que puedan calcularse, verificarse, etc.?

Eugene: tenemos un repositorio arquitectónico, pero no hay automatización para calcular ninguna métrica. Las relaciones entre los modelos y los modelos mismos nos permiten considerar la arquitectura como algo integral, en lugar de un conjunto de imágenes. Una de las tareas del repositorio es proporcionar análisis de impacto. Sobre esta base, puede hacer una estimación del valor de los cambios.

Epílogo

Es genial que puedas venir y escuchar a los arquitectos, conocer a la comunidad. Tales reuniones son siempre una oportunidad para que yo comprenda dónde cavar para encontrar el conocimiento necesario. Además, puede discutir casos de trabajo y obtener una recomendación.

¡Gracias a Maxim Smirnov y HSE por organizar una mesa redonda de arquitectos!
También muchas gracias a los autores de los informes (Eugene Aslamov, Gennady Kruglov, Ivan Lukyanov) por la preparación de este texto , ya que las notas originales fueron escritas durante los informes y contenían errores e inexactitudes que fueron corregidas.

En la foto, el castillo de Chambord en Francia , dicen, cada propietario construyó en su torre. A veces, la arquitectura de un proyecto se ve de esa manera. En mi opinión, se necesita un arquitecto para que todo sea hermoso y lo más simple posible, de modo que incluso con un montón de torres en diferentes estilos, aún así se obtenga un hermoso castillo.