Definição

A arquitetura de um software contempla um conjunto de decisões de design relacionadas com:

• os componentes (elementos) de uma aplicação;
• as propriedades externas e responsabilidades de cada um desses componentes
• os relacionamentos estabelecidos, tanto internos quanto externos
• a estratégia ou princípios que norteiam a evolução do software

Todo software tem uma arquitetura. Entretanto, essa “arquitetura” nem sempre foi planejada. Entendemos, de qualquer forma, que sua concepção, descrição e manutenção deveria ocorrer de forma sistemática e organizada. Para isso, entendemos que a arquitetura de software sempre deve ser analisada em, pelo menos, três versões:

1. AS-IS – a arquitetura como ela está;
2. TO-BE – como a vislumbramos no futuro;
3. Roadmap evolutivo – os estágios intermediários necessários entre o AS-IS e o TO-BE.

A arquitetura, como disciplina, contempla o conjunto de práticas sistematizadas para tratar das decisões de arquiteturais de design, bem como planejamento para evolução do software.

Objetivos

O objetivo principal da disciplina de arquitetura de software é garantir que os atributos de qualidade, restrições de alto nível e os objetivos de negócio sejam atendidos.

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

Relação com design de software

De forma categórica: Atividades relacionadas a arquitetura de software são sempre de design. Entretanto, nem todas atividades de design são sobre arquitetura. Há muitas decisões de design, menos relevantes, que são postergadas e delegadas para que sejam tomadas, potencialmente, com menos rigor.

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.

Domain-driven Design

As práticas e padrões de Domain-driven design não tem relação obrigatória com a disciplina de arquitetura de Software. Entretanto, DDD é 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.

Documentação arquitetural

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

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 a documentação arquitetural é mais relevante em projetos com maior complexidade.

Implicações da nuvem

O surgimento da nuvem impactou de forma definitiva a forma como as arquiteturas de software são planejadas e mantidas. Cabe a prática da disciplina de arquitetura de software demonstrar e aproveitar os ganhos potenciais da nuvem em custo, elasticidade e recursos para o negócio.

Também é responsabilidade da prática da arquitetura de software garantir que a migração aconteça com impacto negativo mínimo, maximizando resultados.

Influência do legado

A disciplina da arquitetura deve mitigar os riscos de um software se converter em legado.

Um software se torna legado quando a capacidade do time técnico de pagar dívidas técnicas é menor do que a necessidade de contrair novas. (Fernando Neiva Paiva)

Para cumprir este objetivo, é fundamental gestão efetiva das dívidas técnicas.

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

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 de atualizações deste documento

• 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 – Separação dos tópicos DDD e futuro da arquitetura; Menção a arquitetura evolutiva.
• 08/02/2020 – Organização do conteúdo; Relação com design; Documentação; Nuvem; Legado
• 17/07/2020 – adição para vídeos explicando conceitos