Arquitetura de TI é importante. Deixe-me dizer por que

Adoramos desenhar !!

(Miguel Angel Coll) (2 de julho de 2020)

Eu investi os últimos 5 anos em minha carreira trabalhando na função de Arquitetura de TI. Todos esses anos, tive que justificar a mera existência da função Arquitetura até para mim. Às vezes também nos sentimos intrusos cercados pelas pessoas que realmente fazem o trabalho (desenvolvedores e sys-ops).

Depois de 5 anos, ainda estou convencido de que a arquitetura é importante, deixe-me apresentar alguns argumentos para prove.

Melhor valor pelo dinheiro

Se eu tiver que escolher apenas uma missão para a arquitetura de TI, vou escolher esta. Os departamentos e plataformas de TI estão crescendo. Alguns porque a empresa está crescendo, outros porque a empresa está em uma transformação digital. Em qualquer caso, o resultado é o mesmo, ano após ano você tem mais sistemas, mais equipes, mais complexidade.

Eu gosto de simplificar excessivamente uma plataforma de TI da seguinte maneira:

A função principal da Arquitetura é manter o relacionamento com o O custo da plataforma de TI e o valor que ela oferece em boa forma.

Há algum tempo, trabalhei em uma empresa de viagens com um modelo de negócios baseado na distribuição de produtos online por meio de APIs. Essas APIs foram fortemente acopladas a um enorme sistema monolítico baseado no Oracle Exadata. Isso significa que sempre que aumentamos o tráfego de API (e o tráfego estava crescendo mais do que a taxa de conversão), precisamos dimensionar nosso banco de dados verticalmente.

A arquitetura impulsiona a eficiência da plataforma de TI

A proposta da arquitetura na época era separar os serviços de API, criando uma nova camada de micro serviços a nuvem para lidar com todo o tráfego com custos menores, mantendo a infraestrutura de Banco de Dados apenas para reservas e operações (que infelizmente não crescem exponencialmente). O resultado foi o fim da nova infraestrutura necessária para o banco de dados nos anos seguintes e uma melhor relação entre tráfego e custos de TI.

Use a mesma linguagem

Não se preocupe, estou não falando sobre linguagens de programação (java, python, etc). Como arquiteto, estou mais do que aberto para a diversidade com algum controle (não caos). Aqui estou me referindo a Integridade conceitual, termo que li pela primeira vez em Mythical Man Month e outros ensaios sobre engenharia de software de Frederick P . Brooks Jr.

No livro, Fred Brooks explica como as equipes de TI crescem e como esse impacto crescente em sua produtividade. Para Fred, um dos maiores problemas a resolver ao tentar dimensionar uma equipe de TI é a comunicação entre as equipes. Para paralelizar as tarefas, você precisa que as equipes sejam o mais independentes possível. Mas, assim que todas as equipes trabalham em uma plataforma interconectada, precisamos de alguma comunicação entre as equipes. É nesses cenários que ter uma linguagem comum é a chave para o sucesso.

Ainda me lembro de conversas intermináveis ​​com meus ex-companheiros de equipe discutindo sobre o que é um sistema, um componente de tecnologia, uma interface ou um bloco de construção. Se você trabalha em um grande departamento de TI, provavelmente sabe como é frustrante que as coisas sejam nomeadas de maneiras diferentes pelas equipes. Às vezes é ainda pior quando eles usam o mesmo nome para coisas diferentes.

Um exemplo comum desse último é nomear um aplicativo monolith com apenas um nome. Mesmo que faça sentido (já que é um monólito), quando você quiser quebrar esse monólito, você precisará de mais detalhes. A introdução de nomes diferentes para o banco de dados, o front-end, o modelo de dados etc. ajudará no processo.

Mesmo que você esteja em um departamento de TI pequeno ou maior, é sempre um bom momento para começar com uma convenção de nomenclatura, um catálogo de serviço / sistema / solução, etc. Você nunca sabe quão grande você será no futuro.

Sobre integridade conceitual, simples comigo, quanto mais cedo melhor.

Forçar conversas de design

Em minha mente, toda solução para um problema sempre começa com um análise da situação e do desenho da solução antes da implementação. A realidade para uma equipe de desenvolvimento é que a cada semana temos novos problemas para resolver. Após alguns meses de rotinas Business as Usual, as equipes começam a funcionar no piloto automático e apenas encontram soluções para os problemas sem pensar muito nas implicações de médio e longo prazo.

Ter a função de arquitetura integrada nas equipes de desenvolvimento sempre ajuda em aumentar as conversas sobre design para encontrar as melhores soluções para os problemas que enfrentamos.

Além disso, gosto de desafiar o processo de desenvolvimento à moda antiga, em que o design é visto como algo a ser feito logo no início de um projeto.No artigo The Architect Elevator – Visitando os andares superiores , Gregor Hohpe descreve minha compreensão da função da Arquitetura perfeitamente:

“… Então, em vez de confiar todas as decisões cruciais a uma pessoa, o risco do projeto pode ser reduzido em minimizando o número de decisões que são irreversíveis .”

A arquitetura deve estar presente em todo o processo de desenvolvimento . Na verdade, se você estiver trabalhando com Agile, você tomará decisões em cada iteração.

Discussões de estratégia

Como um cara de TI, adorarei estar no conselho da empresa, tendo e discussões técnicas detalhadas. A realidade para médias e grandes empresas é que os membros do Conselho não podem se dar ao luxo de se aprofundar nos detalhes. Mas, a diretoria da empresa deve tomar decisões sobre estratégia sem entender a situação da TI?

No mundo atual, existem poucas empresas que podem dizer que a TI não está no centro de sua estratégia. Então, quem é o responsável por traduzir a estratégia para TI e vice-versa? – você já sabe a resposta.

Uma das nossas maiores contribuições na equipe de arquitetura da TUI Destination Experiences foi desenhar um modelo de arquitetura de destino. O TAM permite que pessoas que não são de TI entendam nossas principais soluções e sistemas e como eles estão conectados aos fluxos de valor de nossa empresa. Depois de distribuir o TAM, a maioria de nossas conversas sobre estratégia começou observando como nossa arquitetura se parece e como devemos nos adaptar a uma nova situação.

Mas tenha cuidado, um modelo de arquitetura de destino não deve ser estático imagem da arquitetura “tal como está” e “futura”. Tentar fazer esse tipo de exercício vai acabar com algo efêmero que se encaixa perfeitamente em um projeto específico. Na minha opinião, é melhor se concentrar em desenhar os componentes principais de sua arquitetura e selecionar as coisas que você deseja preservar (porque são o núcleo do seu negócio) e apontar as coisas que você precisará mudar ou evoluir.

Primeiro slide da apresentação TAM

Lembre-se sempre do que Dee Hock, fundadora da Visa, disse:

Propósitos e princípios simples e claros dão origem a um comportamento inteligente complexo. Regras e regulamentos complexos dão origem a comportamentos simples e estúpidos.

Até o infinito e além

A obsessão por ser ágil às vezes é transformar as equipes de TI em tomadores de decisão de curto prazo . Como já discutimos, precisamos ter certeza de que as decisões que estamos tomando hoje são à prova de futuro. Às vezes, significa ter uma visão clara da estratégia de longo prazo. Às vezes significa ter cuidado para não ficar preso a uma solução que não se encaixa no seu futuro. Na maioria das vezes significa garantir um nível padrão de qualidade e ser capaz de se adaptar a tudo o que vier.

Como já comentamos, a Arquitetura tem que atuar também no nível estratégico. Isso significa que provavelmente terá novas informações sobre possibilidades futuras que podem afetar a plataforma de TI. Às vezes, essas mudanças estratégicas são até confidenciais. Ser capaz de influenciar em algumas decisões para evitar movimentos de arrependimento às vezes é uma tarefa difícil, porque pessoas não informadas nunca entenderão o verdadeiro motivo por trás.

Em algum momento, estávamos no meio do discussão sobre como melhorar a arquitetura da plataforma B2C. Realmente faz sentido melhorar muito a arquitetura. Mas, alguns de nós sabíamos que estávamos em conversas para adquirir uma empresa que substituirá nossa plataforma B2C.

Acredite em mim, nem sempre é fácil ser um arquiteto, mas você tem que sempre pensar no que é melhor para a empresa.

E também…

… Também amamos desenhar e vamos deixar o escritório muito mais legal.

Equipe de desenvolvimento discutindo usando um diagrama de arquitetura

Espero que esta postagem modesta contribuir no futuro para entender um trabalho tão bonito.

Migue Coll, chefe de domínio de tecnologia da Tui Destination Experiences.