Nessa publicação, apresentamos uma consolidação do nosso entendimento sobre arquitetura de software.

Essa publicação é um “documento vivo” que continuará recebendo atualizações ao longo do tempo.

O que é arquitetura de software?

A boa arquitetura orienta e propicia formas produtivas para desenvolver, manter, atualizar, entregar (deploy) e operacionalizar software.

Todo software tem uma arquitetura. Entretanto, essa “arquitetura” nem sempre tem evolução planejada. Entendemos, de qualquer forma, que sua concepção, descrição e manutenção deveria ocorrer de forma sistemática e organizada.

Ela pode ser definida sob duas perspectivas: descritiva e ativa.

Perspectiva descritiva

A perspectiva descritiva contempla os componentes, suas responsabilidades, a forma como se relacionam (seus relacionamentos) e, finalmente, a estratégia evolutiva de um sistema.

NOTA: Para fins práticos, definimos estratégia como “um padrão coerente para tomada de decisões”. É a estratégia que ajuda os tomadores de decisão a optar entre duas ou mais abordagens para resolver um problema.

 

A estratégia quase sempre é resultante dos desejos e restrições funcionais, não-funcionais e inversas que o software precisa atender.

Perspectiva ativa

Na perspectiva ativa, entendemos que a arquitetura de software sempre deve ser analisada em, pelo menos, três versões: a arquitetura como ela está (AS-IS), como a vislumbramos no futuro (TO-BE), além dos estágios em que a arquitetura irá passar para sair do momento atual e chegar ao estágio desejado (roadmap).

As demandas de negócio evoluem com o tempo. Assim, também evolui o software e sua arquitetura. Modelos rígidos (dífíceis de mudar) não são ideais e, por isso, a arquitetura deve ser evolutiva (de maneira responsável)

Relação com DDD

Domain-driven design não tem relação obrigatória com arquitetura de Software. Entretanto, é extremamente útil, sobretudo para identificar as demandas do negócio e para delinear componentes mais alinhados com as características do domínio (por exemplo, respeitando Bounded Contexts)

Curadoria tecnológica

Parte das atribuições da arquitetura de software é indicar o conjunto de tecnologias indicadas para implementação de  uma solução.

Há diversos critérios a serem considerados na hora de, por exemplo, optar pelo novo e que está hype ou pelo consolidado (porém próximo da obsolescência). Cabe a arquitetura garantir que as ferramentas sejam selecionadas considerando aspectos de adequação e capacidade do time e aos termos e restrições da organização e dos stakeholders.

Papel e atribuições do arquiteto de software

O arquiteto de software não é, necessariamente, um “Desenvolvedor Sênior-Sênior”. Embora não conheçamos nenhum bom arquiteto de software que, em algum momento da carreira, não tenha sido uma excelente desenvolvedor, entendemos que são posições com skills distintas.

O arquiteto geralmente tem “cicatrizes” adquiridas com a experiência.

O Arquiteto de Software é, acima de tudo, um excelente orquestrador. Afinal, ele “orquestra” as relações dos diversos interessados, incluindo times de negócios e de tecnologia, afim de garantir que as decisões mais adequadas sejam tomadas e seguidas.

Entendemos que a demanda e a rigidez associadas as atividades de arquitetura de software variam conforme o risco do projeto. Quanto maior o risco associado, maior a necessidade de método e disciplina nas práticas do Arquiteto.

Sempre que possível, o arquiteto de software, deve considerar e respeitar critérios mais objetivos de decisão, apoiando-se em indicadores e métricas.

Finalmente, consideramos importante que o arquiteto faça parte ativa do time, acompanhando a implementação e a manutenção da solução que está propondo.

Documentação

Parte das responsabilidades do arquiteto de software é garantir que documentação abrangente e atualizada esteja disponível.

De forma alguma entendemos que o código é suficiente para descrever um sistema. Principalmente, se levarmos em consideração aspectos não-funcionais.

Na EximiaCo, adotamos e recomendamos a adoção de linguagens específicas para documentação da arquitetura, incluindo UML, C4 e ArchiMate

Entendemos que o papel do arquiteto é mais relevante em projetos com maior complexidade.

Relação com arquitetura corporativa

Com frequência, detectamos confusão entre Arquitetura Corporativa e Arquitetura de Software. Inclusive entre os papéis dos arquitetos em cada tipo de arquitetura.

É fundamental que deixemos claro que a arquitetura corporativa, embora tenha origens no departamento de TI é, há tempos, uma disciplina de negócio.

A arquitetura corporativa irá tratar de conectar a estratégia com a operação, atuando em quatro dimensões: negócios, dados, aplicações e infraestrutura.

O futuro da arquitetura de software

Modernamente, estilos arquiteturais novos tem aumentado ainda mais a necessidade da prática da arquitetura e, em nossa opinião, a formalização do papel do arquiteto de software.

Além disso, constata-se a relação entre estrutura de comunicação da empresa e estrutura do software. Daí, se infere que modificações em uma impactam na outra, o que aumenta ainda mais a relevância da prática da arquitetura.

Finalmente, espera-se cada vez mais de TI. Logo, os desafios tendem a crescer em complexidade mesmo com o surgimento, todos os dias, de componentes prontos e formas mais produtivas de trabalho.

Histórico

• 16/09/2019 – Versão inicial
• 02/10/2019 – Preocupações da arquitetura (desenvolver, manter, entregar e operar), “Seleção de Tecnologias” como parte da arquitetura; Arquiteto como membro do time;
• 08/11/2019 – Revisão do texto; Separação dos tópicos DDD e futuro da arquitetura; Menção a arquitetura evolutiva.