Mesa redonda “Arquiteto do projeto de TI”, setembro de 2018

Em 5 de setembro, Moscou sediou a Mesa Redonda “Arquiteto de Projetos de TI” no HSE. O organizador da mesa redonda, Maxim Smirnov, é um blog sobre arquitetura e o canal do Facebook .

Estou muito feliz que tais eventos estejam sendo realizados. Tornar-se um arquiteto legal foi e continua sendo meu sonho. Durante muito tempo, não entendi como os arquitetos geralmente se desenvolvem, como se desenvolvem e quais direções escolher para que levem à arquitetura e, penso, essas questões surgem não apenas para mim. É ótimo que exista uma comunidade onde você possa entrar e fazer perguntas aos arquitetos.

Na mesa redonda, foram apresentados 4 relatórios de 15 a 20 minutos, após o que houve perguntas da platéia e discussão.

Os relatórios foram breves e diretos, e a discussão foi muito animada e extensa.



Além disso, minhas anotações durante os relatórios.

Relatório 1
Principais habilidades de um arquiteto de decisão em projetos do zero

Gennady Kruglov
Arquiteto SOA certificado, ctn

Como parte da apresentação, as principais etapas do processo arquitetônico foram abordadas:

1. Envolvimento de negócios.
2. Engenheiros envolventes.
3. Prototipagem.
4. A escolha do estilo arquitetônico e da pilha tecnológica (microsserviços, monólito, SOA).
5. Desenvolvimento de projeto de arquitetura.
6. Demonstração para o cliente.
7. Design da solução.
8. Documentando soluções em arco.
9. Supervisão arquitetônica.

Destaques do desempenho:

É aconselhável fazer um protótipo para mostrá-lo aos negócios. Sempre que possível, é necessário envolver diferentes partes na escolha de um estilo arquitetônico - desenvolvedores, segurança, operação. Ao projetar um esboço, você precisa criar diferentes seções da arquitetura - negócios, tecnologia e segurança.

Se possível, é necessário atrair pessoas que trabalharão diretamente com essa parte do sistema.

Após discussão com as partes interessadas, um protótipo é demonstrado. Se o projeto iniciar, é realizado um estudo mais detalhado de cada nível de arquitetura.
Durante o desenvolvimento, a sincronização com o arquiteto é necessária para verificar se o processo está seguindo o caminho escolhido.

As habilidades que, segundo o orador, são necessárias ao arquiteto:

• Habilidades de comunicação (persuasão, negociação)
• Apresentações
• Brainstorming e workshops
• Conhecimento de estilos arquitetônicos
• Grandes horizontes da tecnologia moderna (é importante entender os pontos fortes e fracos)
• Habilidades de design e aplicação
• Habilidades de desenvolvimento usando diferentes estruturas, produtos e linguagens de programação
• Conhecimento de estruturas de documentação de decisão
• Compreendendo os diferentes tipos de SDLC (ciclo de vida de desenvolvimento de sistemas)
• Ampla rede de conexões profissionais
• Habilidades em gerenciar equipes de desenvolvimento

Relatório 2
Suporte de arquitetura para projetos de TI

Dmitry Romanov, ITSK

Projetando soluções de TI, suporte arquitetônico de projetos, cerca de 80 projetos por ano, cerca de 50 arquitetos estão envolvidos no processo.

O serviço do arquiteto chefe de TI determina a política técnica no campo da TI, que foi implementada pelos arquitetos do projeto de TI. Respondendo à pergunta em que o arquiteto geralmente reúne os conhecimentos necessários, Dmitry indicou as seguintes fontes:

1. Experiência - criando sistemas similares
2. Colegas - alguém dentro da empresa ou em outras empresas
3. Fornecedor - consultas com desenvolvedores
4. Fóruns Temáticos
5. Technopark - aprovações ou sandbox com base no Technopark

Considerando a necessidade do papel de arquiteto no ITSK, Dmitry apontou que o arquiteto de um projeto de TI é necessário para que, por exemplo, não exista uma situação em que um projeto tenha sido concluído por 1 ano, eles trabalhem por seis meses e percebam que não há dimensionamento e refeitos por 2 anos. Um entendimento claro é importante para que a arquitetura proposta possa ser implementada. Dependendo da metodologia de gerenciamento de projetos, no ITSK, o arquiteto entra na equipe (se for ágil) ou no grupo de especialistas do projeto.

Relatório 3
Arquitetura nos projetos de TI da organização: foco principal

Ivan Lukyanov, Departamento de Tecnologias de Informação de Moscou, produto “Serviços estatais e MFC”

Biografia profissional do palestrante: desenvolvedor da Diasoft, chefe da equipe de desenvolvimento (BSC Praha), consultor líder (Neoflex), chefe do departamento de arquitetura e estratégia do Alfa Bank, chefe do departamento de desenvolvimento de arquitetura (DIT).
Ivan recomenda começar com uma descrição da arquitetura existente (como está), criando uma arquitetura de destino (a ser) e analisando a diferença entre os pontos "onde a organização está agora" e "para onde a organização deseja ir" descrevendo as etapas para levar o sistema ao estado de destino.
O foco principal dos projetos de TI em arquitetura:

• Declaração do problema de negócios a ser resolvido: o arquiteto deve garantir que a tarefa do negócio seja bem colocada, descrita em uma forma adequada para o design, acordada pelas pessoas responsáveis ​​pelo negócio
• Visão do caminho: pelos esforços dos arquitetos da organização, a arquitetura de destino da organização deve ser desenvolvida para as necessidades específicas do negócio. A arquitetura de destino deve ser dividida em etapas concretas (projetos) para alcançá-la.
• Design: todas as soluções são projetadas levando em consideração a arquitetura de destino desenvolvida. A arquitetura de destino é implementada incrementalmente de projeto para projeto. O arquiteto aprova a decisão sobre arquitetura.
• O processo de implementação do projeto: a organização deve ter um processo que inclua análise e descrição de tarefas de negócios, desenvolvimento da arquitetura de destino e processo de design (o desenvolvimento e a operação não foram abordados no relatório). O processo deve ser acordado por todas as partes envolvidas e apoiado pela gerência.
• Suporte metodológico ao processo de implementação do projeto: muitas vezes é o arquiteto que se torna a figura em cujos ombros reside o desenvolvimento de uma metodologia para a implementação de projetos de TI em uma organização, levando em consideração a formulação de uma tarefa e design de negócios. Como parte deste trabalho, podem ser feitos ajustes no processo existente de implementação de projetos de TI na organização (se houver um antes) ou na criação de um novo processo a partir do zero (se não existir). O resultado do trabalho metodológico é o processo descrito e os documentos de suporte, formalizados na forma de modelos.

A empresa agora desenvolveu sua própria metodologia, incluindo modelos usados ​​no trabalho de documentos. Os princípios do TOGAF e do Gartner foram utilizados.

Os princípios arquitetônicos foram aprovados, o documento “Solução arquitetônica e tecnológica” foi desenvolvido, descrevendo os requisitos de negócios para soluções e o projeto para sua implementação.

Recursos do arquiteto:

• Sociabilidade. A comunicação com a gerência, com artistas, com suporte, com gerentes e testadores é importante. O arquiteto deve desempenhar o papel de tradutor - traduzir do idioma dos negócios para o técnico e vice-versa.
• Um pré-requisito é a experiência do desenvolvedor (bem, se também analítica).
• Respeito pelos colegas.
• Desenvolvimento contínuo.

A arquitetura não é um monumento imóvel em granito, mas uma visão viva e em evolução do que queremos alcançar em termos de apoio aos negócios.

Relatório 4
Arquiteto de projetos de TI: um dos pontos de vista possíveis

Evgeny Aslamov Aslamov, arquiteto líder, Lanit Group of Companies.

O caminho de Eugene para o papel de arquiteto: desenvolvedor, analista, gerente de projetos. Durante o conto, o autor levantou várias questões relacionadas ao papel do arquiteto no desenvolvimento personalizado: o que o rodeia, o que faz e como faz.

Na opinião de Eugene, falando sobre o arquiteto no desenvolvimento personalizado, dependemos de vários fatores - tempo, orçamento, equipe, complexidade e volume de tarefas. Como regra, em projetos complexos (vários milhares de cenários de usuários, integração com algumas dezenas de sistemas, grandes volumes de dados, requisitos severos de alta disponibilidade e recuperação de desastres), as tarefas de arquitetura são fechadas por uma equipe de arquitetos. Em projetos mais modestos, uma pessoa pode lidar com essas tarefas e o arquiteto nem sempre é dedicado às tarefas - sua função pode ser combinada com outras funções - o desenvolvedor ou analista principal.

Um arquiteto, como qualquer membro da equipe, trabalha em um determinado contexto. Um esboço desse contexto:

Cliente

• a mais alta (em qualquer caso, alta o suficiente para decisões importantes) do cliente responsável pelo projeto;
• comitês de clientes (arquitetura, design, operação, etc. - isso acontece muito);
• serviço ou departamento de especialistas em segurança da informação;
• funcionários do cliente que precisam de um sistema que "grave" o projeto;
• realidades - rotina banal, fator humano, questões processuais, pequenas divergências, etc;

A equipe

• Gerentes
• Analistas
• desenvolvimento;
• DevOps
• serviço de qualidade;

O contrato

• prazos;
• orçamento
• citações legais;
• novas tecnologias, abordagens, chips que realmente quero aplicar;
• tradições: funciona e é bom, está tudo bem conosco - o que mudar e coisas do gênero.

Como parte do contexto, um arquiteto ou grupo de arquitetos faz o seguinte:

• Ele forma os limites para a equipe na qual o projeto se desenvolverá e viverá. Primeiro, estamos falando de limites decorrentes de requisitos não funcionais.
• Formula, suporta e atualiza soluções arquiteturais, levando em consideração os pontos de vista dos principais interessados.
• Funciona como intérprete - traduz do técnico para o russo e vice-versa. Real para o cliente e a equipe. O arquiteto deve entender todos os aspectos do projeto (juntamente com os principais analistas e o gerente do projeto) e ser capaz de explicar seu relacionamento com as partes técnicas.
• Faz muitas perguntas desagradáveis. Acontece que algumas decisões foram tomadas sem a participação de um ou outro membro da equipe. Isso é normal. Se algo foi feito e está afetando ou pode afetar a arquitetura do sistema, você precisa descobrir os motivos, para descobrir se precisa alterar algo agora, prever algumas medidas para o futuro ou pode simplesmente gravar e deixá-lo até melhores tempos.

Respondendo à pergunta “Como ele faz isso?”, Eugene primeiro falou sobre a questão do desenvolvimento de soluções arquitetônicas. Foram identificados vários componentes que ajudam nessa tarefa:

• Experiência e analogias. Este é um dos ativos mais importantes do arquiteto. E ele precisa ser constantemente aumentado - para não estagnar em um projeto, tecnologia etc.
• Horizontes. Você não pode usar sua própria experiência - a experiência dos colegas, a experiência das comunidades, os padrões.
• Protótipos. No caso de usar um novo, não testado ou com riscos visíveis, a prototipagem é necessária. Ao mesmo tempo, é importante formular corretamente e com precisão as perguntas que o protótipo deve responder, caso contrário, ele só pode piorar a situação.
• Protegendo suas decisões. Antes da equipe do projeto, antes do comitê de arquitetura (seu ou do cliente), na sua frente. Como uma das soluções, pode ser a introdução (elementos completos ou individuais) do ATAM - Architecture Tradeoff Analysis Method . Em vários de nossos projetos, por exemplo, a proteção de decisão é implementada como a apresentação de decisões importantes para colegas de fora do projeto para opiniões e comentários alternativos.

Em vez de uma conclusão: uma das tarefas informais de um arquiteto e de qualquer especialista que ama seu trabalho é popularizar conhecimentos, tecnologias, abordagens e habilidades que permitirão à equipe resolver problemas de um projeto com mais eficiência e maior comodidade.

Artigo de Eugene sobre habr “ Estamos preparando um projeto no Sparx Enterprise Architect. Nossa receita . "

Perguntas e Respostas

A seguir, havia uma seção de perguntas e respostas, as mais lembradas podem ser lidas abaixo.

De onde vêm os arquitetos?

Gennady:
Arquitetos de software - ex-líderes de equipe ou líderes ou desenvolvedores líderes.
Dmitry:
Arquitetos são retirados de desenvolvedores de consultores, com ampla experiência.
O desenvolvedor pode falar e desenhar apresentações - arquiteto de soluções.
Eugene:
Em geral, de qualquer parte - desde desenvolvimento, testes, gerenciamento de projetos, etc. Mas, de qualquer forma, algumas especializações técnicas ajudam - elas não precisam ser desenvolvidas do zero.
Um exemplo da experiência pessoal: um aluno do departamento de mecânica da Universidade Estadual de Moscou, uma pessoa inteligente e sociável sem doença estelar, foi levado para a empresa Lanit. Ele trabalhou um pouco em análise, desenvolvimento, comunicação com o cliente. Como resultado, ele se tornou um arquiteto aplicado em nossa empresa.
Ivan:
Dos desenvolvedores. Se houver um bom desenvolvedor, ele poderá continuar a se aprofundar nas linguagens de programação, desenvolver-se mais profundamente. Mas se, ao mesmo tempo, ele ficou curioso sobre como nasceu a tarefa técnica, quem analisa, quem toma a decisão se isso deve ou não ser feito, isso é um sinal de que o especialista embarcou no caminho de um arquiteto iniciante. O próximo nível de curiosidade é como uma solução nasce como um todo, no nível dos negócios. Como você pode mostrar ao chefe da organização que ele precisa e o que não precisa. Ao descrever o papel do arquiteto, Gregor Hohpe usa a metáfora do elevador . Cada andar em que o elevador para é um certo nível na organização: o primeiro andar - a sala de máquinas - são desenvolvedores, produção; último andar - gestão da organização. Trazendo vida à arquitetura, o arquiteto se comunica em cada andar (do primeiro ao último) e em cada andar ele tem que lidar com várias dificuldades - comunicação tecnológica, política e política.

O arquiteto é capaz de coletar as informações necessárias e transmitir a cada nível. De fato, ele atua como mediador entre as partes envolvidas.

Como a autoridade deve ser compartilhada entre o gerente do projeto e o arquiteto?

Deve haver um equilíbrio entre autoridade. A autoridade do arquiteto está na parte técnica e o gerente do projeto na parte organizacional.

No caso de o saldo ser desviado para o RP - você pode obter o projeto no prazo, mas não está funcionando ou não é escalável. E, se for para o arquiteto, você poderá obter um projeto maravilhoso quando ninguém precisar. É assim que se responde às perguntas "Quem você ama mais - pai ou mãe?"

Como ser arquitetos corporativos que têm um grande fluxo de projetos diferentes?

Ivan:
Nas grandes organizações, mais de 2.000 pessoas fazem uma arquitetura corporativa e é quase impossível segui-la. No DIT, uma divisão é feita em produtos (serviços), cada produto possui sua própria pilha de tecnologia, sua própria arquitetura. Quanto à arquitetura corporativa, os acionistas precisam mais dela para entender para onde a organização está indo em termos de desenvolvimento da arquitetura. Para esse fim, o papel do arquiteto chefe de TI é frequentemente destacado nas organizações, cuja principal tarefa é determinar o cenário geral da arquitetura corporativa.

Como é construída a interação entre o arquiteto do projeto e o arquiteto corporativo?

A comunicação é importante. Você precisa criar comunicação e apenas se comunicar. Um arquiteto de projeto pode não precisar de conhecimento da arquitetura corporativa, mas é importante saber com quem será a integração e qual será o impacto. É importante formar comitês de arquitetura, é possível conhecer não apenas os arquitetos corporativos, mas também os de design.

Você pode ver isso em termos de valor - quem traz mais valor. Se as soluções funcionarem, haverá valor. A arquitetura corporativa, por si só, não agrega valor, mas agrega valor através de uma solução de arquitetos que já implementam tarefas específicas.

Ninguém precisa de generalistas - cada vez menos são pessoas que não sabem nada sobre tudo. É melhor poder responder a perguntas específicas, por exemplo, o RabbitMQ é suficiente aqui ou o Kafka é necessário.

Como são organizados os repositórios de arquitetura corporativa?

Existem modelos complexos que podem ser calculados, verificados etc.?

Eugene: temos um repositório de arquitetura, mas não há automação para calcular nenhuma métrica. As relações entre os modelos e os próprios modelos nos permitem considerar a arquitetura como algo integral, e não como um conjunto de imagens. Uma das tarefas do repositório é fornecer análise de impacto. Nesta base, você pode fazer uma estimativa do valor das alterações.

Posfácio

É ótimo que você possa vir e ouvir os arquitetos, conhecer a comunidade. Tais reuniões são sempre uma oportunidade para eu entender onde cavar para encontrar o conhecimento necessário. Além disso, você pode discutir casos de trabalho e obter uma recomendação.

Agradecimentos a Maxim Smirnov e HSE por organizar uma mesa redonda de arquitetos!
Também muito obrigado aos autores dos relatórios (Eugene Aslamov, Gennady Kruglov, Ivan Lukyanov) pela preparação deste texto , pois as notas originais foram escritas durante os relatórios e continham erros e imprecisões que foram corrigidos.

Na foto, o castelo de Chambord , na França , dizem eles, cada proprietário construiu sua torre. Às vezes, a arquitetura de um projeto é assim. Na minha opinião, é necessário um arquiteto para que tudo seja bonito e o mais simples possível, para que, mesmo com várias torres em estilos diferentes, você ainda tenha um belo castelo.