Definindo arquitetura de software e o papel do arquiteto

Arquitetura de software são as coisas importantes de um software. O que quer que isso seja.
Ralph Johnson (não Martin Fowler)


Saiba mais

Poucas perguntas são tão frequentes em grupos de arquitetura de software quanto “O que é Arquitetura de Software?” e “Qual é o papel do Arquiteto de Software?”. Este capítulo é uma tentativa de responder essas duas perguntas.

Há quem confunda as práticas de “Arquitetura de Software” com processos mais pesados e burocráticos, ou seja, incompatíveis com a agilidade. Entretanto, o entendimento mais ajustado é o inverso: arquitetura de software e agilidade são facilitadoras para gestão da volatilidade.

O que é arquitetura de software

Embora não exista consenso absoluto sobre o conceito, alguns aspectos são amplamente aceitos. Qualquer discussão madura sobre a arquitetura de um software aborda, de maneira mais ou menos qualificada, seus componentes, a responsabilidade destes e a forma como eles se relacionam. Aliás, isto está alinhado com a definição proposta pelo IEEE, que é uma das mais mencionadas.

Arquitetura de software pode ser definida como a organização fundamental de um sistema, seus componentes, as relações entre eles e o ambiente que guia seu design e evolução.

IEEE Standard 1471

Indiretamente, a referência a componentes, relacionamentos e responsabilidades também está presente na definição proposta no excelente “Software Architecture in Practice“. 

Software Architecture in Practice, 4th edition

Um verdadeiro clássico, agora revisado e ampliado. Trata-se de “leitura obrigatória” para quem deseja realizar uma abordagem séria e mais formal as práticas de arquitetura de software.

Acessar livro

A arquitetura de software de um programa ou sistema computacional é a estrutura ou estruturas do sistema que abrange os componentes de software, as propriedades externamente visíveis desses componentes e as relações entre eles.

Bass, Clements e Kasman

A arquitetura de um software não é um conjunto de diagramas, produzidos por alguém, frequentemente desatualizados. Os diagramas, aliás, são apenas um modelo, uma representação, da arquitetura real que está ou estará implementada no software.

As melhores arquiteturas, geralmente, tem componentes com baixo acoplamento. Ou seja, que funcionam e evoluem de maneira independente, com pouco impacto nos demais, tanto na manutenção quanto na operação, além do ganho em testabilidade (que é um ganho mais amplo, de engenharia). Por outro lado, arquiteturas ruins geralmente tem componentes fracamente delimitados, com forte acoplamento, difíceis de manter e, sobretudo, caros para testar e evoluir.

A “estratégia” na arquitetura de software

Estratégia é um padrão coerente para tomada de decisões. Ou seja, quando todas as pessoas de um grupo tomam decisões seguindo um mesmo padrão coerente, obedecendo um conjunto estável de critérios, diz-se que estão alinhados a uma mesma estratégia – mesmo quando, eventualmente, as decisões em si sejam diferentes.

Quando um time de desenvolvimento adota boas práticas de arquitetura, seus membros seguem uma estratégia comum para suas escolhas e isso é extremamente importante. Afinal, para cada problema tecnológico há uma continuidade crescente de respostas viáveis – com prós e contras – que dificultam o consenso. A alternativa selecionada deve ser aquela que for mais aderente aos objetivos de negócio, restrições e atributos de qualidade.
0
Considerações?x

Na prática, isso significa, por exemplo, que qual framework utilizar no frontend, por exemplo, é menos relevante, sob a perspectiva da arquitetura, que os critérios que foram utilizados para adotar tal tecnologia.

Considerações sobre os objetivos do negócio

Dos objetivos de negócio infere-se tanto o modelo de negócios como do modelo operacional que será suportado pelo software que se pretende desenvolver e manter.

O modelo de negócios compreende respostas para as perguntas “Quais são os produtos ou serviços oferecidos? Para quem?” e “Quanto é cobrado pelos benefícios gerados? De quem? Como?”. Já o modelo operacional implica em respostas para “Como a empresa gera seus produtos e serviços? Em que escala? Em que escopo? Como aprende?”

A transformação digital não começa na área de tecnologia

Transformação Digital e Ágil

Transformação digital e ágil são temas quentes. Nesse capítulo, mostro que elas, diferente do que se possa entender, não começam, de fato na área de tecnologia. Além disso, explico um pouco melhor os conceitos de “Modelo de negócios” e “Modelo Operacional”.

Ler capítulo

As respostas de todas as perguntas indicadas tensionam o contexto, demandando a introdução ou revisão de novas restrições e atributos de qualidade.

Considerações sobre Atributos de Qualidade e Restrições

Atributos de qualidade e restrições são os fundamentos para as tomadas de decisão arquitetônicas. Os atributos de qualidade são aprimorados ou danificados por essas decisões, enquanto as restrições incluem ou excluem diretamente partes da arquitetura (por exemplo, os componentes lógicos ou tecnologias).

Uma lista, não exaustiva, porém comum de atributos de qualidade incluem:

  • Desempenho, indicando quanto rapidamente um sistema consegue executar uma determinada atividade;
  • Escalabilidade, determinando a capacidade de um sistema de lidar com mais usuários, requisições, dados, mensagens, etc.
  • Disponibilidade, com relação ao percentual de requisições que um sistema consegue responder dentro de uma expectativa de performance.
  • Segurança, talvez o mais essencial dos atributos, indicando a capacidade de um sistema de preservar confidencialidade, integridade e disponibilidade frente a tentativas de desestabilizar o sistema.
  • Flexibilidade, indicando suporte a ampliação de escopo de features ou a capacidade de um sistema de permitir que uma mesma ação seja executada de mais de uma forma
  • Extensibilidade, permitindo a adição de features ou dados além dos planejados e implementados “no código”
  • Manutenabilidade, com vistas a estabilizar custos para manter
  • Evolvabilitycombinando a capacidade de um software evoluir, tanto em tecnologia quanto em features, sem sacrificar a manutenabilidade.
  • i18n e l10n

Uma lista não exaustiva de restrições, inclui:

  • Prazo e orçamento;
  • Listas de tecnologias aprovadas;
  • Necessidade de preservar retrocompatibilidade e gestão de legado;
  • Plataformas operacionais que precisam ser suportadas;
  • Relacionamento com vendors
  • Tamanho e skills do time

Definição: 'Arquitetura de Software' (Proposta)

Arquitetura de software trata das decisões relacionadas ao design de um software – seus componentes, as responsabilidades destes componentes e como se relacionam –  bem como a estratégia que governará sua evolução, de forma a atender os objetivos do negócio, respeitando restrições técnicas e não técnicas, atendendo atributos de qualidade, sempre buscando minimizar custo ou risco.

A relação de arquitetura com design de software


Saiba mais

Quando falamos sobre arquitetura, invariavelmente falamos sobre design de software. Entretanto, o oposto não é verdadeiro. As decisões sobre design que são parte da arquitetura de um software são aquelas que tem relação direta com o atendimento dos objetivos do negócio, respeito a restrições e atendimento dos atributos de qualidade.


A decisão de isolar acesso ao banco de dados em uma “classe repositório”, por exemplo, é uma decisão de design, mas, dificilmente será uma decisão de arquitetura. Afinal, dificilmente será fundamento para atendimento dos objetivos de negócio, respeito a restrições e atributos de qualidade. Por outro lado, a adoção de um cache é, quase sempre, uma decisão de arquitetura pois, este componente pode ser a resposta para atender atributos de qualidade como disponibilidade e performance.

Construir um software cloud-ready também é uma decisão de arquitetura, bem como adotar um ou outro fornecedor de nuvem. Aliás, as escolhas do banco de dados, das linguagens de programação, dos frameworks tanto para frontend quando backend também são exemplos de resoluções arquiteturais pois, certamente, terão implicações relevantes para a continuidade do software, logo, condições para atender o negócio e implicações sobre o orçamento (uma das restrições mais comuns).

Especificidades sobre injeção de dependências, composição ou agregação de classes, nomes de métodos e variáveis e, até mesmo princípios SOLID, quando relacionados a aspectos diretamente ligados ao código, são bons exemplos de design, mas não de arquitetura.

A maioria das decisões de design são individuais, em conformidade com os acordos estabelecidos pelo time de desenvolvimento e acontecem o tempo todo. Algumas decisões de design relacionadas com a arquitetura, por outro lado, têm impacto maior e são menos frequentes. Decisões arquiteturais raramente são produtos do trabalho individual.

Finalmente, decisões de arquitetura geralmente são mais difíceis e custosas de revisitar. Daí, talvez, venha a definição vaga de Ralph Johnson que utilizei na citação de abertura.

Arquitetura de software como descoberta

A prática da arquitetura de software é, então, também, uma prática de descoberta. Primeiro, do que se entende dos objetivos de negócio, restrições e atributos de qualidade. Estas informações, aliás, quase nunca evidentes e frequentemente incompletas inicialmente. Depois, de alternativas propositivas de design compatíveis.

De muitas formas, o método de trabalho para a prática de arquitetura de software assemelha-se a resolução de problemas Sudoku. Afinal, em ambos, no Sudoku e na prática de arquitetura, tudo começa com um conjunto incompleto de informações e a solução é encontrada interativamente, a partir do preenchimento de espaços em branco de acordo com aquilo que se sabe para, etapa por etapa, substituir possibilidades por certezas.

As distinções entre Sudoku e arquitetura, entretanto, começam no entendimento de que enquanto para problemas Sudoku há uma única solução possível. Enquanto isso, problemas arquiteturais, geralmente existem múltiplas alternativas viáveis.

Arquitetura de software como resolução de tensões


Saiba mais

Entre as informações disponíveis inicialmente, geralmente está uma visão superficial dos objetivos de negócio desejados, imposições de orçamento e normativas (restrições) e sinalizações sobre atributos de qualidade relacionados. Assim como em problemas  Sudoku, a partir dessas informações, faz-se inferências para clarificação contextual a partir destes elementos tensores.

De muitas formas, a prática de arquitetura de software equilibra forças e alivia tensões entre objetivos de negócio, restrições e atributos de qualidade.

Por exemplo, em um sistema que suporta prestadores de serviço, pode ser um objetivo de negócio a capacidade de processar recebimentos. Daí, infere-se a necessidade da observação de segurança como atributo de qualidade, que implica na restrição de apartar redes que hospedam serviços internos (controlados) daquelas que hospedam serviços externos através de uma DMZ.

Seguindo o exemplo anterior, o entendimento de segurança como atributo de qualidade, eventualmente implicará, também no atendimento de confidencialidade, integridade e disponibilidade. Na sequência, restrições associadas, como, por exemplo, adoção de tecnologias certificadas são inferidas e, dado o custo, obrigam a ampliação e descoberta de novos objetivos de negócio que “façam a conta fechar”.

Eventualmente, novas restrições externas podem ser impostas (como novas instruções normativas), tensionando o contexto, impactando nos objetivos de negócio e em atributos de qualidade. Nesses casos, novas inferências precisam ser feitas de forma a equilibrar as tensões e dissolver conflitos.

A relação de arquitetura com engenharia de software

A disciplina de engenharia de software contempla não apenas a escrita de código, mas todas as ferramentas e processos que uma organização usa para construir e manter o software ao longo do tempo. 

Winters, Manshreck e Wright

Arquitetura de software é uma das disciplinas da engenharia. Não mais, não menos!

A engenharia de software não é estática e trata do “ciclo de vida” do software. De forma análoga, a arquitetura de software tampouco é estática, ou seja, a arquitetura evolui na mesma medida em que os objetivos de negócio podem ser redefinidos, restrições são revisadas e atributos de qualidade determinados.
Há sempre, pelo menos, duas visões a respeito da arquitetura. A primeira, trata da arquitetura como ela está (AS-IS). A segunda, projeta como a arquitetura deverá ser (TO-BE). Seja, para adequar aos novos tempos, seja para compensar dívidas técnicas.

Quanto mais explícitas forem as condições atuais (AS-IS) e mais explícitas forem as expectativas para o futuro (TO-BE), mais fácil será planejar a evolução arquitetural através de “arquiteturas intermediárias”.

A arquitetura de software deve considerar e respeitar as outras disciplinas de engenharia ou, pelo menos, tê-las em consideração.

O projeto da Torre de Babel falhou por falta de comunicação, e por causa dessa falta, a organização falhou. 

Frederick P. Brooks Jr.

A relação da arquitetura de software com a estrutura organizacional

Tratar da arquitetura de um software implica, fatalmente, em tratar da estrutura da organização que o utiliza e vice-versa.
0
Você concorda?x

Organizações que desenvolvem sistemas de software tendem a produzir sistemas que são cópia das estruturas de comunicação dessas empresas.

Melvin Conway

A estrutura dos componentes de um software impacta na formação dos times que vão desenvolver o software. Não há, por exemplo, chances de implementar arquiteturas baseadas em microsserviços em estruturas organizacionais com times monolíticos. Se o time for indivisível, o software também o será!

Team Topologies

Um “novo clássico”! Team Topologies aborda de maneira clara e direta as complicações e oportunidades resultantes da Lei de Conway.

Acessar livro

A arquitetura de software, porém, excede a estrutura dos times de desenvolvimento. Na prática, a estrutura de componentes de um software acaba impactando também a própria estrutura corporativa da empresa que adotará o produto tecnológico. Isso leva, por exemplo, a profundas modificações, mesmo em empresas sólidas, quando há migração de um sistema chave ou, ainda, resistência acentuada a mudança e aumento dos custos.
0
Você concorda?x

A lei de Conway

Quais são os impactos da lei de Conway para a arquitetura de software? Essa é a temática desse vídeo – parte de uma playlist que preparamos para apresentar fundamentos das práticas arquiteturais.

Acessar vídeo

As práticas da arquitetura de software

As decisões de design que tem relação com a arquitetura são tão importantes que, idealmente, devem ser tomadas obedecendo algumas boas práticas. Ou seja, replicando os comportamentos comuns adotados por times eficientes que produzem software de boa qualidade, que atendem os objetivos do negócio, respeitando restrições a atingindo atributos de qualidade.
0
Considerações?x

As práticas de arquitetura de software maximizam a produtividade. Ou seja, a relação entre o valor obtido (desempenho) e o esforço dispensado (empenho). De maneira análoga, boa arquitetura maximiza o resultado, otimizando o investimento. Em termos simples, boa arquitetura de software colabora para melhorar o ROI de iniciativas de desenvolvimento e reduzir o TCO.

A fórmula da produtividade

No meio corporativo é comum falar sobre o “desafio da produtividade”. Mas, você já parou para pensar no que ser mais produtivo, de fato, significa? 

Nós costumamos explicar a produtividade utilizando uma fórmula simples. Entendemos que produtividade é definida pela proporção do desempenho (o resultado que se busca obter) e do empenho (o esforço ou custo necessário para gerar o desempenho).

Acessar episódio

As melhores práticas de arquitetura de software invariavelmente acionam as partes interessadas (stakeholders) para explicitar e atualizar os objetivos do negócio que precisam ser atingidos, focando nos resultados e não na forma. Elas também devem diagnosticar, até o último momento responsável, as restrições que devem ser observadas e assegurar que elas sejam respeitadas. Finalmente, também devem inferir os atributos de qualidade que garantem a eficiência no atendimento do negócio e das restrições.

As melhores práticas de arquitetura resolvem de maneira mais leve os principais trade-offs – direções conflitantes que precisam ser observadas – que emergem no levantamento dos objetivos e das restrições. Por exemplo, disponibilidade – um atributo de qualidade – conflita com segurança – uma restrição, afinal, disponibilidade implica em adição de componentes que ampliam a “superfície de ataque”.
0
Você pode apontar outros exemplos de trade-offs?x

A abrangência da arquitetura de software

As decisões arquiteturais impactam, obviamente, nas atividades de desenvolvimento, mas também tem relação com a manutenção, atualização, entrega (deploy) e operação do software. Por isso, arquitetura de software é parte do esforço de engenharia, que é mais amplo.

A boa engenharia de software, conforme a Google, contempla todas as atividades que habilitam um sistema a suportar as mudanças de escala, ao longo do tempo, sem sacrificar a eficiência. Seguramente, as decisões arquiteturais são parte crucial para o sucesso da engenharia.

Software Engineering at Google

Como a Google, uma das maiores empresas de tecnologia do mundo, trata engenharia de software? Quais foram as lições aprendidas pela companhia ao longo de sua jornada? Essa é a temática desse livro fantástico.

Acessar livro

A decisão de adotar microsserviços, por exemplo, transfere parte da complexidade de desenvolver um software para sua operação. Há mais o que operar e monitorar e obrigam a adoção de abordagens mais modernas e automatizadas. Não raro, microsserviços é uma tentativa de resolver um problema criando outro pior!

O arquiteto de software

Todo software tem uma arquitetura. Nem sempre, entretanto, ela é suportada por boas práticas arquiteturais.

Há quem defenda que as boas práticas arquiteturais devem ser reforçadas por todo o time de desenvolvimento e eu concordo com isso. Entretanto, também entendo que algo que é responsabilidade de todos, acaba recebendo cuidados de ninguém. O arquiteto de software, em um time de desenvolvedor de software, é o responsável por garantir que boas práticas de arquitetura sejam adotadas.

O arquiteto apoia os esforços de engenharia de software, tomando decisões que facilitem a gestão do ciclo de vida de um produto tecnológico.

Em um mundo onde especialistas sabem cada vez mais sobre cada vez menos, não se pode esperar que uma única pessoa seja capaz de tomar todas as decisões importantes relacionadas com a arquitetura. Entretanto, parece coerente ter alguém preocupado e responsável por garantir que essas decisões sejam tomadas – este é o papel do arquiteto.

O arquiteto de software é, idealmente, um orquestrador. Ele garante que todas as partes interessadas sejam ouvidas e suas ponderações sejam levadas em conta na formulação da arquitetura. Para isso, elabora e mantém artefatos abrangentes que facilitam o engajamento.

O arquiteto de software deve, de tempos em tempos, revisar a estrutura de componentes e suas relações de um software para garantir que os objetivos do negócio serão atingidos, as restrições obedecidas e os atributos de qualidade atendidos. Além de tudo isso, o arquiteto deve adotar postura “provocativa” para verificar se a entrega está maximizada frente ao melhor custo.

The Software Architect Elevator

Quais são as funções e responsabilidades do arquiteto de software? O que muda conforme o tamanho das organizações? Greg Hohpe apresenta uma visão madura e bem fundamentada para essas questões neste livro espetacular.

Acessar livro

Há, certamente, muitos times de tecnologia que tem sucesso em fazer entregas sem ninguém ocupando, formalmente, a posição de arquitetura. Entretanto, esses times são compostos ou, pelo menos, liderados por desenvolvedores muito experientes. Nesses casos, esses desenvolvedores tem cicatrizes relacionadas a decisões arquiteturais semelhantes as que são necessárias para o projeto em que estão trabalhando, diminuindo o risco da ausência do pensamento arquitetural mais especializado. Há ainda, claro, pessoas executando o ‘papel de arquiteto’, sem o devido reconhecimento formal.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

O arquiteto não é, necessariamente, um “dev sênior-sênior”

Em minha experiência, não conheci nenhum arquiteto de software que não tenha sido, também, excelente desenvolvedor. Entretanto, embora exista correlação, não consigo identificar causalidade.

Muito da confusão do arquiteto com um “dev sênior-senior” surge da incapacidade das empresas de ajustarem um plano de carreira adequado para times de tecnologia. Não raro, a posição do arquiteto de software é ofertada como uma promoção (um próximo passo natural) para um desenvolvedor e este não é o caso.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

O arquiteto de software precisa de soft skills suficientes para poder interagir com os diferentes stakeholders de maneira qualificada. Além disso, deve ter capacidade de abstração suficiente para representar componentes complexos de maneira compreensível. Finalmente, precisa ter “sensibilidade técnica” para identificar falhas arquiteturais e acionar as pessoas certas para que as decisões sejam as mais assertivas.

A alocação de uma pessoa em atividades de arquitetura pode variar significativamente conforme a complexidade ou os riscos do software que está sendo desenvolvido. Em muitos cenários, o arquiteto tem tempo para escrever código. Outras vezes, as atividades de orquestração podem ser demandantes ao ponto de que não sobre tempo para escrever código em quantidade relevante.

Importante, porém, destacar que hard skills nunca serão um problema, muito pelo contrário!
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

Definição: 'Arquiteto de Software' (Proposta)

O arquiteto de software é o responsável por garantir (não necessariamente executar) que as práticas de arquiteturais sejam executadas. Tem perfil “técnico” com excelentes essential skills, capaz de discutir desde com “escovadores de bits” até “altos executivos”.

As atividades de arquitetura durante a elaboração do design


Saiba mais

As atividades relacionadas a arquitetura, no desenvolvimento do design de software, incluem a orquestração para sua elaboração, mas também a avaliação da qualidade das proposições, orientação quanto a oportunidades/necessidades de melhoria e, finalmente, preparação para implementação. a preparação para a implementação, conforme o indicado no fluxograma abaixo.
0
Considerações?x

Importante destacar que no “centro” das atividades do arquiteto estão os objetivos de negócio, as restrições e os atributos de qualidade. Finalmente, a definição da função de avaliação da arquitetura que será o custo ou risco.

Just enough software architecture

Qual é o rigor necessário na execução das atividades de arquitetura? George Fairbanks defende que depende dos “riscos” envolvidos em cada projeto. Quanto maior o risco, maior a necessidade de rigor nas práticas!

Acessar livro

A partir de um conjunto qualificado e distensionado de objetivos de negócios, restrições e atributos de qualidade, emergem condições favoráveis para proposições de design. Ou seja, organização de componentes – com responsabilidades e regras explícitas de interação.
0
Considerações?x
Eventualmente, entretanto, proposições de design impactam no reconhecimento de novas restrições e na revisão dos atributos de qualidade para novo distensionamento.

Não raro, medidas para melhorar dois ou mais atributos de qualidade, respeitar restrições ou atender objetivos de negócio são conflitantes. Ou seja, não podem ser adotadas juntas. Há também cenários onde ações que favorecem a alguns dos objetivos arquiteturais prejudicam outros. Nessas horas, ocorre um trade-off.

É papel do arquiteto de software orquestrar interações entre todos os stakeholders para eliminar trade-offs.

As atividades de arquitetura para continuidade

Uma vez selecionada uma proposição de design, seguem atividades de implantação, operação e evolução, governadas por um conjunto de fitness functions que expressam, principalmente, objetivos de negócio e atributos de qualidade.

Em algum momento, a medida que ocorrem mudanças significativas de escala ou escopo, anomalias ocorrem e, na ocorrência, implicam em retomada de descobertas de objetivos de negócio, restrições e atributos de qualidade.

Quatro configurações de trabalho para o “arquiteto”


Saiba mais

Todo sistema de software possui uma arquitetura. Entretanto, ela nem sempre é planejada, tampouco idealizada por alguém que responde, pelo menos oficialmente, como arquiteto.


Gregory Hohpe ensina que há pelo menos quatro configurações possíveis para a atividade de arquitetura.

O arquiteto como “Ditador Benevolente”

Nessa configuração, cabe ao arquiteto definir o que precisa ser feito e ao time executar o que o arquiteto definir.

Embora aparentemente na contramão de estruturas modernas e ágeis, esta configuração pode ser necessária em times onde produzir o consenso é difícil. Geralmente, tais cenários são resultantes do excesso ou da falta absoluta da pressão por resultados. Ou ainda, por falta de equilíbrio de senioridade.
0
Por favor, deixe seu feedback aquix

No médio-longo prazo, times com uma cabeça, a do “ditador benevolente”, e diversos braços, o restante do time, são insustentáveis por promover comportamento medíocre.

Arquiteto como “membro do time”

Nessa configuração, o arquiteto assume a posição de orquestrador para as decisões mais importantes. Ele explicita e consolida opções com o time verificando sempre o atendimento dos objetivos do negócio, respeito a restrições e atendimento dos atributos de qualidade.

Geralmente, nessas configurações, há equilíbrio perceptível de senioridade na maior parte do time. As decisões nem sempre são tomadas rapidamente, mas, são sempre mais seguras.
0
Considerações?x

O maior risco, nessa configuração, é que o arquiteto passe a executar outras atividades, como escrever código, em demasia, deixando de cumprir seu papel primário.
0
Considerações?x

Arquitetura sem arquitetos

Nessa configuração, as atividades de arquitetura são diluídas entre os diversos membros do time, que assumem responsabilidade compartilhada pelos resultados.

Esse tipo de configuração só é possível em times com senioridade extremamente elevada, onde há consciência da natureza e da importância das atividades arquiteturais.

O maior risco, nessa configuração, é que o time negligencie aspectos como comunicação eficaz com outros stakeholders, migrando para outra configuração, “implícita” onde práticas arquiteturais simplesmente não são executadas.
0
Considerações?x

Arquitetura “implícita”

Nessa configuração, as atividades de arquitetura simplesmente não são executadas e a mesma “emerge organicamente” durante o processo de desenvolvimento. É comum em times alegadamente ágeis que acham práticas arquiteturais desnecessárias.

O resultado comum desse tipo de configuração é ver o time “fazendo outra vez” software que já fez no passado. Ou seja, reproduzindo soluções de projetos anteriores para problemas propostos no projeto atual.

Este tipo de configuração costuma ser o “gatilho” para adoção, em algum momento, do modelo com um “ditador benevolente”. Geralmente, quando o projeto sai dos trilhos.
0
Considerações?x

Qual é o jeito certo?

Não há jeito certo! Mas, com certeza, desenvolver software buscando arquiteturas implícitas é o jeito errado.
0
O que você pensa a respeito?x
A opção por ter um “ditador benevolente”, como um “igual” no time, ou ter as atividades diluídas depende da senioridade e da orientação do time.

Este é o início de uma longa jornada…

Gosto muito da ideia de dar passos consistentes na direção certa, o tempo todo. Nesta introdução, tentei consolidar impressões sobre arquitetura de software, suas práticas e as atribuições de um arquiteto. Nos próximos capítulos, vou apresentar algumas “boas práticas” de arquitetura que tenho vivenciado como arquiteto e consultor.

// TODO

Antes de avançar para o primeiro capítulo, recomendo as seguintes atividades:

  • Reflita sobre as práticas de arquitetura de software que você tem presenciado. O que tem funcionado? O que não tem gerado os resultados esperados?
  • Você consegue relacionar os principais componentes do software que está desenvolvendo, suas responsabilidades e a forma como estes se relacionam?
  • Você consegue relacionar os objetivos de negócio que precisam ser atingidos usando o software que está ajudando a desenvolver? Conhece as principais restrições? Saberia explicitar os atributos de qualidade?

Referências bibliográficas

BASS, Len; CLEMENTS, Paul; KASMAN, Rick. Software Architecture in Practice. 4. ed. Old Tappan, Nj: Pearson Education, 2021. (The SEI Series in Software Engineering).

BROOKS JUNIOR, Frederick P.. O mítico homem-mês: ensaios sobre engenharia de software. Chapel Hill, Nc: Addison-Wesley, 1995. Edição de Aniversário.

FOWLER, Martin. Software Architecture Guide. 2019. Disponível em: https://martinfowler.com/architecture/. Acesso em: 6 abr. 2021.

HOHPE, Gregory. Agile and Architecture: Friend, not Foe. 2020. Disponível em: https://exco.me/3J7npK7. Acesso em: 17 ago. 2021.

WIKIPEDIA. IEEE 1471. Disponível em: https://en.wikipedia.org/wiki/IEEE_1471. Acesso em: 6 abr. 2021.

WINTERS, Titus; MANSHRECK, Tom; WRIGHT, Hyrum (org.). Software Engineering at Google: lessons learned from programming over time. Gravenstein Highway North, Ca: O’Reilly Media, Inc, 2020.

Compartilhe este capítulo:

Compartilhe:

Comentários

Participe da construção deste capítulo deixando seu comentário:

Inscrever-se
Notify of
guest
3 Comentários
Oldest
Newest Most Voted
Feedbacks interativos
Ver todos os comentários
Paulo Júnior
Paulo Júnior
1 ano atrás

Elemar, quanto ao que você disse em: “A decisão de isolar acesso ao banco de dados em uma “classe repositório”, por exemplo, é uma decisão de design, mas, dificilmente será uma decisão de arquitetura. Afinal, dificilmente será fundamento para atendimento dos objetivos de negócio, respeito a restrições e atributos de qualidade”. Você não acha que essa decisão poderia ser fundamental para atender a alguns critérios de qualidade, tais como flexibilidade, testabilidade e manutenibilidade?

Jone Polvora
Jone Polvora
1 ano atrás
Responder para  Paulo Júnior

Acredito que o artigo quer nos explicar é que a arquitetura seria a definição em um nível mais alto da forma como o software e seus componentes devem se comportar e interagir, e que o padrão repositório é apenas um detalhe da implementação do sofware, é apenas uma das formas de abstração de acesso a banco de dados, ou seja, uma decisão de design, e claro, pela experiência de quem está implementando, seria ideal que a implementação escolhida seja testável.

Jone Polvora
Jone Polvora
1 ano atrás
Responder para  Paulo Júnior

A definição arquitetural está num nível acima das decisões de design, pois para se implementar a arquitetura que foi definida, não importa muito como cada componente foi implementado. As decisões de design são importantes sim, mas são definidas pelo time que vai implementar cada componente dessa arquitetura, e claro, cada time deve pensar na qualidade como um todo, mas acredito que não seja responsabilidade do arquiteto, mas de um tech leader com experiência dentro do time.

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mentoria

para arquitetos de software

Imersão, em grupo, supervisionada por Elemar Júnior, onde serão discutidos tópicos avançados de arquitetura de software, extraídos de cenários reais, com ênfase em systems design.

Consultoria e Assessoria em

Arquitetura de Software

EximiaCo oferece a alocação de um Arquiteto de Software em sua empresa para orientar seu time no uso das melhores práticas de arquitetura para projetar a evolução consistente de suas aplicações.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

+55 51 99942-0609 |  contato@eximia.co

+55 51 99942-0609  contato@eximia.co

3
0
Quero saber a sua opinião, deixe seu comentáriox
()
x