Arquitetura de Software
Sumário

Esse documento apresenta a consolidação da visão dos profissionais de nossa empresa sobre Arquitetura de Software.
O conteúdo deste documento é considerado estruturante e é atualizado periodicamente. A última atualização ocorreu em 17/07/2020
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:
- AS-IS – a arquitetura como ela está;
- TO-BE – como a vislumbramos no futuro;
- 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.
- As grandes etapas, recomendadas pela Microsoft, na migração de aplicações para a nuvem
- Receio de migrar aplicações para a Nuvem? Comece “pequeno”!
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.
- Nem tudo que parece dívida técnica, efetivamente, é
- O verdadeiro motivo para evitar dívidas técnicas
- Como determinar que dívidas técnicas pagar primeiro
- As etapas na jornada dos legados para “Cloud-native Applications”
- Compartilhar o banco de dados – O equívoco arquitetural mais difundido nas organizações
- Software projetado sem considerar performance e escalabilidade já nasce legado
- Ferramentas de análise estática ajudam os times a produzir “código limpo”
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