38 ações e insights para se tornar um arquiteto de software melhor

Vários anos atrás, me perguntaram: “Como você se tornou um arquiteto de software?”. Conversamos sobre as habilidades necessárias, a experiência e a quantidade de tempo e dedicação necessários para construir conhecimento. Além disso, passei pelas etapas que tomei, com as tecnologias com as quais trabalhei ativamente ou com o que aprendi durante minha carreira profissional e não profissional.

Essa conversa me desencadeou e comecei a estruturar o tópico para o meu crescimento pessoal. “O que faz um bom arquiteto de software?”, Perguntei, e “Como posso melhorar para me tornar um arquiteto de software melhor?”. Eu li artigos e livros e, claro, conversei com colegas. Hoje, quero compartilhar uma visão geral de minhas ideias com você, quais habilidades são mais importantes e como melhorá-las para me tornar um (melhor) arquiteto de software.

O que é um arquiteto de software?

Antes de nos aprofundarmos nos detalhes, vamos dar uma olhada em duas definições primeiro.

Um arquiteto de software é um especialista em software que faz escolhas de design de alto nível e dita padrões técnicos, incluindo padrões, ferramentas e plataformas de codificação de software. O principal especialista é conhecido como arquiteto-chefe.
(Fonte: Wikipedia: arquiteto de software )

A arquitetura de software é a organização fundamental de um sistema, representada por seus componentes, seus relacionamentos entre si e com o meio ambiente, e os princípios que determinam o design e a evolução do sistema.
(Fonte: Manual de Arquitetura de Software )

Níveis de Arquitetura

A arquitetura pode ser feita em vários “níveis” de abstração. O nível influencia a importância das habilidades necessárias. Como existem muitas categorizações possíveis, minha segmentação favorita inclui esses três níveis:

  • Nível de Aplicação : O nível mais baixo de arquitetura. Concentre-se em um único aplicativo. Design muito detalhado e de baixo nível. Comunicação geralmente dentro de uma equipe de desenvolvimento.
  • Nível da solução : o nível médio da arquitetura. Concentre-se em um ou mais aplicativos que atendam a uma necessidade comercial (solução comercial). Algum design alto, mas principalmente de baixo nível. Comunicação entre várias equipes de desenvolvimento.
  • Nível Corporativo : O nível mais alto de arquitetura. Concentre-se em várias soluções. Design abstrato de alto nível, que precisa ser detalhado por arquitetos de soluções ou aplicativos. Comunicação em toda a organização.

Às vezes, os arquitetos também são vistos como “cola” entre diferentes partes interessadas. Três exemplos:

  • Horizontal : conecte a comunicação entre empresas e desenvolvedores ou diferentes equipes de desenvolvimento.
  • Vertical : ponte de comunicação entre desenvolvedores e gerentes.
  • Tecnologia : integre diferentes tecnologias ou aplicativos entre si.

Atividades típicas de arquitetos de software

Para entender as habilidades necessárias que um arquiteto precisa, primeiro precisamos entender as atividades típicas. A lista seguinte (não final) contém da minha perspectiva as atividades mais importantes:

  • Definir e decidir a tecnologia e plataforma de desenvolvimento
  • Definir padrões de desenvolvimento, por exemplo, padrões de codificação, ferramentas, processos de revisão, abordagem de teste, etc.
  • Suporte para identificar e entender os requisitos de negócios
  • Projete sistemas e tome decisões com base em requisitos
  • Documente e comunique definições arquitetônicas, design e decisões
  • Verifique e analise a arquitetura e o código, por exemplo, verifique se os padrões definidos e os padrões de codificação estão implementados adequadamente
  • Colabore com outros arquitetos e interessados
  • Coach e consultores de desenvolvimento
  • Detalhe e refine o design de nível superior no design de nível inferior

Nota: A arquitetura é uma atividade contínua, especialmente quando é aplicada em desenvolvimento de software ágil. Portanto, essas atividades são feitas repetidas vezes.

Habilidades Importantes de Arquitetos de Software

Para apoiar as atividades definidas, são necessárias habilidades específicas. Pela minha experiência, leia livros e discussões que podemos resumir a essas 10 habilidades que todo arquiteto de software deve ter:

Projeto, Decida, Simplifique, Código, Documento, Comunique-se, Estimativa, Equilíbrio, Consultar, Mercado

Vamos passar um por um. Para cada habilidade, descrevi algumas ações ou percepções a serem seguidas para melhorar nessa área.

(1) projeto

O que faz um bom design? Esta é provavelmente a questão mais importante e desafiadora. Eu farei uma distinção entre teoria e prática. Para minha experiência, ter uma mistura de ambos é mais valioso. Vamos começar com a teoria :

  • Conheça os padrões básicos de design : Os padrões são uma das ferramentas mais importantes que um arquiteto precisa para desenvolver sistemas de manutenção. Com padrões, você pode reutilizar o design para resolver problemas comuns com soluções comprovadas. O livro “Padrões de Design: Elementos do Software Orientado a Objetos Reutilizáveis” escrito pelo “Gang of Four” (GoF) é uma leitura obrigatória para todos que estão no desenvolvimento de software. Embora o padrão publicado há mais de 20 anos, eles ainda são a base da moderna arquitetura de software. Por exemplo, o padrão Model-View-Controller (MVC) foi descrito neste livro, que é aplicado em muitas áreas ou é a base para um padrão mais novo, por exemplo, MVVC .
  • Aprofunde-se em padrões e antipadrão : se você já conhece todos os padrões básicos do GoF, estenda seu conhecimento com mais padrões de design de software . Ou aprofunde-se em sua área de interesse. Um dos meus favoritos para integração de aplicativos é o livro Enterprise Integration Patterns escrito por Gregor Hohpe . Este livro é aplicável em várias áreas sempre que dois aplicativos precisam trocar dados, seja uma troca de arquivos antiga de alguns sistemas legados ou arquiteturas modernas de Microservice.
  • Conheça as medidas de qualidade : Definir arquitetura não é um fim. Tem razões pelas quais diretrizes e padrões de codificação são definidos, aplicados e controlados. Você faz isso por causa de requisitos de qualidade e não funcionais. Você quer ter um sistema que seja sustentável, confiável, adaptável, seguro, testável, vendável, utilizável, etc. E uma peça para alcançar todos esses atributos de qualidade é aplicar um bom trabalho de arquitetura. Você poderia começar a aprender mais sobre medidas de qualidade na wikipedia .

Teoria é importante. A prática é igualmente ou mais importante se você não quiser se tornar um arquiteto da Ivory Tower .

  • Experimente e compreenda diferentes pilhas de tecnologia : acho que essa é a atividade mais importante se você quiser se tornar um arquiteto melhor. Experimente novas pilhas de tecnologia e aprenda seus altos e baixos. Tecnologia diferente ou nova vem com diferentes aspectos e padrões de design. Você provavelmente não aprende nada apenas de folhear slides abstratos, mas experimentá-lo sozinho e sentir a dor ou o alívio. Um arquiteto não deve apenas ter um conhecimento profundo amplo, mas também em algumas áreas. Não é importante dominar todas as pilhas de tecnologia, mas ter uma sólida compreensão das mais importantes em sua área. Experimente também a tecnologia que não está na sua área, por exemplo, se você estiver interessado no SAP R / 3, tente também o JavaScript e vice-versa. Ainda assim, ambas as partes se surpreenderão com os últimos avanços no SAP S / 4 Hana. Por exemplo, você pode tentar sozinho e fazer um curso no openSAP gratuitamente. Seja curioso e experimente coisas novas. Experimente também coisas que você não gostou há alguns anos.
  • Analise e entenda os padrões aplicados : dê uma olhada em qualquer estrutura atual, por exemplo, Angular . Você pode estudar muitos padrões na prática, por exemplo, Observables . Tente entender como é aplicado no framework, porque foi feito. E se você for realmente dedicado, dê uma olhada mais profunda no código e entenda como ele foi implementado.
  • Seja curioso e participe de Grupos de Usuários : Na Alemanha, por exemplo, temos o Java User Group (JUG) em todas as cidades maiores, onde uma variedade de tópicos é discutida, desde codificação de baixo nível até tópicos de arquitetura mais altos. Eu realmente amo esses eventos, pois eles fortalecem seu pensamento fora da caixa e da sua rede pessoal.

(2) decidir

Um arquiteto precisa ser capaz de tomar decisões e orientar projetos ou toda a organização na direção certa.

  • Saiba o que é importante: não perca tempo com decisões ou atividades sem importância. Aprenda o que é importante. Até onde sei, não há um livro que tenha essas informações (se você conhece uma, por favor me avise). Meus favoritos pessoais são essas duas características que eu costumo considerar ao julgar se algo é importante ou não:
    (1) Integridade Conceitual : Se você decidir fazê-lo de uma maneira, cumpra-o, mesmo que às vezes seja melhor fazê-lo de forma diferente. Geralmente, isso leva a um conceito geral mais direto, facilita a compreensão e facilita a manutenção.
    (2) Uniformidade : Se você, por exemplo, define e aplica convenções de nomenclatura, não é sobre maiúsculas ou minúsculas (de verdade!), Mas para que seja aplicado em todos os lugares da mesma maneira.
  • Priorize : Algumas decisões são altamente críticas. Se elas não forem tomadas cedo o suficiente, serão construídas soluções alternativas que provavelmente não serão removidas mais tarde e serão um pesadelo para a manutenção, ou pior, os desenvolvedores simplesmente deixarão de trabalhar até que uma decisão seja tomada. Em tais situações, às vezes, é melhor ir com uma decisão “ruim” em vez de não ter nenhuma decisão. Mas antes de chegar a essa situação, considere priorizar as decisões futuras. Existem diferentes maneiras de fazer isso. Eu sugiro dar uma olhada no modelo WSJF (Weighted Shortest Job First) , que é amplamente usado no desenvolvimento ágil de software. Especialmente as medidas de tempo crítico e redução de risco são fundamentais para estimar a prioridade das decisões de arquitetura.
  • Conheça sua competência: Não decida coisas que não são de sua competência. Isso é crítico, pois pode arruinar sua posição como arquiteto, se não for considerado. Para evitar isso, esclareça com seus colegas quais responsabilidades você tem e o que faz parte de sua função. Se houver mais de um arquiteto, você deve respeitar o nível de arquitetura no qual está atualmente implantado. Como arquiteto de nível inferior, é melhor você sugerir uma arquitetura de nível superior em vez de decisões. Além disso, recomendo verificar decisões críticas sempre com um par.
  • Avalie várias opções: Sempre defina mais de uma opção, se se trata de decisões. Na maioria dos casos em que estive envolvido, havia mais de uma opção (boa) possível. Ir com apenas uma opção é ruim em dois aspectos: (1) parece que você não fez o seu trabalho corretamente e (2) impede a tomada de decisões adequadas. Ao definir medidas, as opções podem ser comparadas com base em fatos, em vez de sentimentos viscerais, por exemplo, custos de licença ou maturidade. Isso geralmente leva a decisões melhores e mais sustentáveis. Além disso, facilita a venda da decisão para diferentes partes interessadas. Além disso, se você não tiver avaliado as opções corretamente, você pode perder argumentos quando se trata de discussões.

(3) Simplifique

Tenha em mente o princípio de resolução de problemas Navalha de Occam, que afirma preferir a simplicidade. Eu interpreto o princípio da seguinte forma: Se você tem muitas suposições sobre o problema para resolver sua solução, provavelmente está errado ou leva a uma solução complexa desnecessária. Suposições precisam ser reduzidas (simplificadas) para chegar a uma boa solução.

  • Agite a solução : para obter soluções simplificadas, geralmente ajuda a “sacudir” a solução e examiná-las de diferentes posições. Tente moldar a solução pensando de cima para baixo e novamente de baixo para cima. Se você tiver um fluxo ou processo de dados, pense primeiro da esquerda para a direita e novamente da direita para a esquerda. Faça perguntas como: “O que acontece com sua solução em um mundo perfeito?” Ou: “O que a empresa / pessoa X faria?” (Onde X provavelmente não é seu concorrente, mas uma das empresas GAFA ). para reduzir as suposições sugeridas pela Navalha de Occam.
  • Dê um passo atrás : depois de discussões intensas e longas, os rabiscos altamente complexos são muitas vezes os resultados. Você nunca deve ver estes como os resultados finais. Dê um passo para trás: dê uma olhada no quadro geral novamente (nível abstrato). Ainda faz sentido? Então, passe pelo nível abstrato novamente e refatore. Às vezes, ajuda a interromper uma discussão e continuar no dia seguinte. Pelo menos meu cérebro precisa de algum tempo para processar e chegar a soluções melhores, mais elegantes e mais simples.
  • Divide and Conquer : Simplifique o problema dividindo-o em partes menores. Em seguida, resolva-os de forma independente. Depois, valide se os pequenos pedaços combinam juntos. Dê um passo atrás para dar uma olhada na imagem geral para isso.
  • Refatorar não é mal : é totalmente aceitável começar com uma solução mais complexa, se nenhuma idéia melhor puder ser encontrada. Se a solução estiver causando problemas, você poderá repensar a solução posteriormente e aplicar seu aprendizado. Refatorar não é mal. Mas antes de iniciar a refatoração, lembre-se de ter (1) testes automatizados suficientes para garantir a funcionalidade adequada do sistema e (2) a adesão de seus stakeholders. Para saber mais sobre refatoração, sugiro ler Refatoração. Melhorando o design do código existente ”, de Martin Fowler .

(4) código

Mesmo como um Enterprise Architect, o nível mais abstrato de arquitetura, você ainda deve saber o que os desenvolvedores estão fazendo diariamente. E se você não entender como isso é feito, poderá enfrentar dois grandes problemas:
(1) Desenvolvedores não aceitarão seus ditos e
(2) Você não entende os desafios e as necessidades dos desenvolvedores.

  • Tenha um projeto paralelo : O objetivo é testar novas tecnologias e ferramentas para descobrir como o desenvolvimento é feito hoje e no futuro. A experiência é a combinação de observações, emoções e hipóteses ( “Experiência e Gestão do Conhecimento em Engenharia de Software”, de Kurt Schneider ). Ler um tutorial ou alguns prós e contras é bom. Mas isso é apenas "conhecimento do livro". Somente se você experimentar as coisas sozinho, poderá sentir emoções e construir hipóteses sobre por que algo é bom ou ruim. E quanto mais você trabalhar com uma tecnologia, melhor será sua hipótese. Isso ajudará você a tomar melhores decisões no seu dia a dia de trabalho. Quando comecei a programar, não tinha conclusão de código e apenas algumas bibliotecas de utilitários para acelerar o desenvolvimento. Obviamente, com este pano de fundo, eu tomaria decisões erradas hoje. Hoje, temos toneladas de linguagens de programação, estruturas, ferramentas, processos e práticas. Somente se você tiver alguma experiência e uma visão geral das principais tendências, você poderá participar da conversa e direcionar o desenvolvimento para a direção certa.
  • Encontre as coisas certas para experimentar : você não pode experimentar tudo. Isso é simplesmente impossível. Você precisa de uma abordagem mais estruturada. Uma fonte que descobri recentemente é o Radar de Tecnologia da ThoughtWorks. Eles categorizam tecnologias, ferramentas, plataformas, linguagens e estruturas em quatro categorias: Adote, teste, avalie e mantenha. Adotar significa “forte sentimento de estar pronto para o uso corporativo”, Trial significa “empresa deve testá-lo em um projeto que possa lidar com o risco”, Avaliar significa “explorar como isso afeta sua empresa” e Hold significa “processar com cautela”. Com essa categorização, é mais fácil obter uma visão geral das novidades e sua prontidão para avaliar melhor qual tendência explorar em seguida.

(5) Documento

A documentação arquitetônica é às vezes mais e, às vezes, menos importante. Documentos importantes são, por exemplo, decisões de arquitetura ou diretrizes de código. A documentação inicial é frequentemente necessária antes do início da codificação e precisa ser refinada continuamente. Outra documentação pode ser gerada automaticamente, pois o código também pode ser uma documentação, por exemplo, diagramas de classes UML.

  • Código limpo : o código é a melhor documentação, se bem feito. Um bom arquiteto deve ser capaz de julgar um bom código de um código ruim. Um ótimo recurso para aprender mais sobre códigos bons e ruins é o livro Código Limpo ”, de Robert C. Martin.
  • Gere documentação sempre que possível : os sistemas estão mudando rapidamente e é difícil atualizar a documentação. Seja sobre APIs ou cenários de sistema na forma de CMDBs: As informações subjacentes geralmente mudam muito rápido para manter a documentação correspondente atualizada à mão. Exemplo: Para APIs, você pode gerar automaticamente a documentação com base no arquivo de definição, caso seja orientado por modelo ou diretamente a partir do código-fonte. Existem muitas ferramentas para isso, eu acho que Swagger e RAML são um bom ponto de partida para aprender mais.
  • Tanto quanto necessário, o mínimo possível : Tudo o que você precisa documentar, por exemplo, documentos de decisão, tente se concentrar em apenas uma coisa de cada vez e inclua apenas as informações necessárias para essa única coisa. Documentação extensa é difícil de ler e entender. Informações adicionais devem ser armazenadas no apêndice. Especialmente para os documentos de decisão, é mais importante contar uma história convincente em vez de apenas jogar toneladas de argumentos. Além disso, isso poupa você e seus colegas de trabalho, que precisam lê-lo, muito tempo. Dê uma olhada em algumas documentações que você fez no passado (código-fonte, modelos, documentos de decisão, etc.) e faça as seguintes perguntas: “Todas as informações necessárias estão incluídas para compreendê-lo?”, “Quais informações são realmente necessárias e que poderia ser omitido? ”e“ A documentação tem uma linha vermelha? ”.
  • Saiba mais sobre estruturas de arquitetura : esse ponto também pode ser aplicado a todos os outros pontos “técnicos”. Eu coloquei aqui, pois frameworks como TOGAF ou Zachmann estão fornecendo “ferramentas” que parecem pesadas no site de documentação, embora seu valor agregado não esteja limitado à documentação. Ser certificado em tal estrutura ensina você a lidar com a arquitetura de forma mais sistemática.

(6) Comunicar

Ser pró-ativo é provavelmente o melhor que você pode fazer quando se trata de consultoria e coaching. Se você for perguntado, muitas vezes é tarde demais. E limpar o site de arquitetura é algo que você deseja evitar. Você precisa, de alguma forma, prever as próximas semanas, meses ou mesmo anos e preparar a si mesmo e a organização para os próximos passos.

  • Tenha uma visão : se você está implantado em um projeto, seja uma abordagem tradicional em cascata ou ágil, você sempre precisa ter uma visão de suas metas de médio e longo prazo que deseja alcançar. Este não é um conceito detalhado, mas mais um roteiro para todos pode funcionar. Como você não pode conseguir tudo de uma vez (é uma jornada) eu prefiro usar modelos de maturidade. Eles dão uma estrutura clara que pode ser facilmente consumida e dar o status atual de progresso a cada momento. Para diferentes aspectos, uso modelos diferentes, por exemplo, práticas de desenvolvimento ou entrega contínua. Cada nível no modelo de maturidade tem requisitos claros que seguem os critérios SMART para julgar se você o alcançou ou não. Um bom exemplo que encontrei é para continuar a entrega .
  • Construa uma comunidade de prática (CoP) : trocar experiência e conhecimento entre um grupo de interesse comum ajuda a distribuir idéias e padronizar abordagens. Por exemplo, você pode reunir todos os desenvolvedores e arquitetos de JavaScript em uma sala, a cada três meses ou mais, e discutir os desafios passados ??e atuais e como eles foram abordados ou novas metodologias e abordagens. Arquitetos podem compartilhar, discutir e alinhar suas visões, desenvolvedores podem compartilhar experiências e aprender com seus colegas. Essa rodada pode ser altamente benéfica para a empresa, mas também para o próprio indivíduo, pois ajuda a construir uma rede mais forte e a distribuir ideias. Também confira o artigo Comunidades de Prática do Framework SAFe, que explica o conceito de CoP em um ambiente ágil.
  • Realizar sessões de portas abertas : uma fonte de equívocos ou ambiguidades é a falta de comunicação. Bloqueie um horário fixo, por exemplo, 30 minutos por semana, para trocar tópicos importantes com seus colegas. Esta sessão não tem agenda, tudo pode ser discutido. Tente resolver pequenas coisas no local. Agende follow-ups sobre os tópicos mais complexos.

(10) mercado

Suas idéias são ótimas e você as comunicou bem, mas ainda ninguém quer seguir? Então você provavelmente não tem habilidades de marketing.

  • Motivar e convencer : como as empresas o convencem de comprar um produto? Eles demonstram seu valor e benefícios. Mas não apenas com 5 pontos. Eles envolvem-no bem e facilitam a digestão.
    (1) Protótipos : Mostre um protótipo da sua ideia. Existem muitas ferramentas para criar protótipos. No contexto de empresas que amam o SAP, confira o build.me, no qual você pode criar aplicativos UI5 com boa aparência e clicáveis, de maneira rápida e fácil.
    (2) Mostrar um vídeo : em vez de “slides chatos”, você também pode mostrar um vídeo que demonstra sua ideia ou pelo menos a direção.
    Mas, por favor, não exagere no marketing: a longo prazo, o conteúdo é rei. Se as suas palavras não se concretizarem, isso prejudicará sua reputação a longo prazo.
  • Lute por suas idéias e seja persistente : as pessoas às vezes não gostam de suas ideias ou ficam com preguiça de segui-las. Se você está realmente convencido por suas idéias, você deve continuamente ir atrás delas e "lutar". Às vezes isso é necessário. As decisões de arquitetura com metas de longo prazo geralmente não são as mais fáceis: os desenvolvedores não gostam delas, pois são mais complexas para se desenvolver. Os gerentes não gostam deles, pois são mais caros a curto prazo. Este é o seu trabalho para ser persistente e negociar.
  • Encontrar aliados : Estabelecer ou impor suas idéias por conta própria pode ser difícil ou mesmo impossível. Tente encontrar aliados que possam apoiar e ajudar a convencer os outros. Use sua rede. Se você ainda não tiver um, comece a criá-lo agora. Você pode começar conversando com seus colegas (de mente aberta) sobre suas ideias. Se eles gostam disso, ou pelo menos partes dele, é provável que eles apóiem ??a sua ideia se for perguntado por outros (“A ideia de X foi interessante”). Se eles não gostarem, pergunte o porquê: Talvez você tenha perdido alguma coisa? Ou a sua história não é convincente o suficiente? O próximo passo é encontrar aliados com poder de decisão. Peça uma discussão de mente aberta. Se você tem medo da discussão, lembre-se de que às vezes você precisa sair da sua zona de conforto.
  • Repita, acredite : “[…] estudos mostram que a exposição repetida a uma opinião faz as pessoas acreditarem que a opinião é mais prevalente, mesmo que a fonte dessa opinião seja apenas uma pessoa”. (Fonte: The Financial Brand ) publicar poucas mensagens com freqüência suficiente, pode ajudar a convencer as pessoas com mais facilidade. Mas fique atento: na minha perspectiva, essa estratégia deve ser usada com sabedoria, pois pode sair pela culatra como um truque de marketing ruim.