Sobre as práticas de arquitetura de software

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

Desenvolvimento de software é cada vez mais relevante. É difícil imaginar qualquer atividade, em qualquer empresa, em qualquer segmento, que não seja suportada, direta ou indiretamente, por algum tipo de sistema digital. Software bem-feito é, cada vez mais, premissa para a competitividade. Logo, mesmo empresas que não se declaram tecnológicas, tem a tecnologia como competência essencial. Nesse contexto, arquitetura de software ganha relevância, bem como a atuação do arquiteto.

Software bem-feito atende os objetivos do negócio, respeitando restrições e atingindo atributos de qualidade. Além disso, por sua importância, tem sua estratégia evolutiva bem definida. A arquitetura do software bem-feita é premissa para software bem-feito.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

Todo software tem sua arquitetura. Algumas emergem de forma não supervisionada e, por isso, têm qualidade questionável, implicando em software também de qualidade questionável. Boas arquiteturas dificilmente acontecem sem a atuação de alguém competente como responsável.

Eventualmente, bons sistemas são desenvolvidos a partir das “cicatrizes” do time. Ou seja, utilizando arquiteturas de sistemas desenvolvidos com êxito no passado como referência para uma nova solução. Entretanto, isso não é indicativo de que conhecimentos relacionados a arquitetura sejam menos importantes, apenas indica que decisões arquiteturais podem, eventualmente, ser “requentadas” para resolver cenários com problemas de negócio, restrições ou atributos de qualidade similares.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

Empresas de varejo, com frequência, contratam pessoas técnicas que tenham experiência atuando no varejo, por exemplo. Essa “preferência” se justifica pela intimidade com aspectos arquiteturais específicos.

Há também, sistemas que evoluem suas arquiteturas com base em modismos, influências de terceiros ou preferências difíceis de justificar. Nestes cenários, prejuízos acabam sendo percebidos mais tarde e por muito tempo. Geralmente, no longo prazo, tais soluções se convertem em “colchas de retalhos” com custo crescente de manutenção.
2
Você concorda com essa afirmação? Há algo a ponderar aqui?x

Como um projeto de software pode ter um “atraso” de mais de um ano? … Um dia de cada vez. (Frederick P. Brooks Jr.)


As oportunidades são muitas e os riscos são cada vez maiores. Ter ciência da importância de desenvolver sistemas com boas arquiteturas deve fazer parte, cada vez mais, da proposição competitiva da organizações. Profissionais com habilidades em conceber e implementar tais arquiteturas serão cada vez mais valorizados, independente do título que se dê a posição que ocupam.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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“. 
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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 sobreposição, difíceis de manter e, sobretudo, caros para evoluir.
0
Você concorda com essa afirmação? Há algo a ponderar aqui?x

A relação de arquitetura com design de software

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.
1
Você concorda com essa afirmação? Há algo a ponderar aqui?x

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.

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.
0
Você concorda?x

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.
0
Você concorda?x

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”.

Alinhamento de propósito habilita a autonomia para atuação.

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, de 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á!

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

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.

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.

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”.
1
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.

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!

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.

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.

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.

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.
2
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

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. 3. ed. Old Tappan, Nj: Pearson Education, 2012. (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.

SEVERO JUNIOR, Elemar R. A lei de Conway: fundamentos de arquitetura de software. Fundamentos de Arquitetura de Software. 2020. Disponível em: https://www.youtube.com/watch?v=3vC2vNwPoo8. Acesso em: 8 abr. 2020.

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
15 Comentários
Oldest
Newest Most Voted
Feedbacks interativos
Ver todos os comentários
Vinicius Lima
Vinicius Lima
1 mês atrás
Feedback no conteúdo deste capítulo Há, certamente, muitos times de tecnologia que tem sucesso em fazer entregas sem ninguém ocupando, formalmente, a posição de arquitetura.…" Ler mais »

“Nesses casos, esses desenvolvedores tem cicatrizes relacionadas a decisões arquiteturais semelhantes as que são necessários”
Segundo o contexto, o correto seria “necessárias” por estar se referindo a “cicatrizes relacionadas a decisões arquiteturais”.

Rodolfo Zattar
Rodolfo Zattar
1 mês atrás
Feedback no conteúdo deste capítulo Indiretamente, a referência a componentes, relacionamentos e responsabilidades também está presente na definição proposta no excelente "Software Architecture in Practice". " Ler mais »

Nesse caso, só a correção do título do livro, faltou o r no Practice.

Anderson Lima
Anderson Lima
1 mês atrás
Feedback no conteúdo deste capítulo Eventualmente, bons sistemas são desenvolvidos a partir das "cicatrizes" do time. Ou seja, utilizando arquiteturas de sistemas desenvolvidos com êxito…" Ler mais »

“podem, eventualmente, ser” ao invés de “podem, eventualmente, serem”

Guilherme Elias
Guilherme Elias
1 mês atrás
Feedback no conteúdo deste capítulo Software bem-feito atende os objetivos do negócio, respeitando restrições e atingindo atributos de qualidade. Além disso, por sua importância, tem…" Ler mais »

O que seria uma arquitetura bem feita? Fica em cheque tal afirmação por ser tão abstrata.

Agora falar que um bom software é aquele que permite o negócio evoluir por sua estratégia evolutiva, ai sim faz total sentido. O livro Building Evolutionary Architecture da patota da TW fala muito disso.

Wesley
Wesley
10 dias atrás
Responder para  Guilherme Elias

Vim aqui comentar algo parecido.

Acredito que uma arquitetura bem feita é aquela que está alinhada com o objetivo do software e que facilite a caminhada até esse objetivo. E possívelmente esse software estará alinhado com os objetivos da empresa, visto que será uma meio para alcançá-los.

Se uma empresa está constantemente evoluindo e se renovando, tal software deveria focar em tais qualidades em sua arquitetura (facilidade na manutenção e evolução por exemplo) de modo que não gere mais problemas do que aqueles que a empresa quer resolver (problemas do seu domínio).
Se a empresa é bem consolidade e mais estática, aqui possívelmente a arquitetura poderia focar mais em estabilidade e facilidade na manutenção.

João Paulo Melo
João Paulo Melo
1 mês atrás
Feedback no conteúdo deste capítulo As oportunidades são muitas e os riscos são cada vez maiores. Ter ciência da importância de desenvolver sistemas com boas…" Ler mais »

Elemar, essa é uma bela introdução, no geral software e sua arquitetura estão a serviço de algum negócio. Perfeito!
Acredito que caberia aqui mencionar que negócios ou empresas mudam o tempo todo, logo a capacidade evolutiva do software influencia *também* a capacidade de atender às mudanças em uma velocidade viável.

João Paulo Melo
João Paulo Melo
1 mês atrás
Feedback no conteúdo deste capítulo As melhores práticas de arquitetura resolvem de maneira mais leve os principais trade-offs - direções conflitantes que precisam ser observadas…" Ler mais »

Talves outro trade-off seria o cenário onde a necessidade de uma comunicação *síncrona* conflita com a autonomia ou independência dos interlocutores.

Carlos Mattos
Carlos Mattos
1 mês atrás
Feedback no conteúdo deste capítulo Há, certamente, muitos times de tecnologia que tem sucesso em fazer entregas sem ninguém ocupando, formalmente, a posição de arquitetura.…" Ler mais »

Tenho observado grandes empresas adotando um modelo de ‘escritório de arquitetura’ ou ‘architecture office’ onde desenvolvedores ou engenheiros de software com larga experiencia trabalham num modelo colaborativo e compartilhado, permitindo o uso otimizado do conhecimento e experiencia desses profissionais na concepcao de novas solucoes para seus clientes e parceiros. O desafio fica por conta dos obstáculos para movimentar esses profissionais dos projetos aos quais eles estao vinculados, onde na maioria das vezes estao atuando há um longo período e ocupam um papel-chave para o time.

Daniel Souza Makiyama
Daniel Souza Makiyama
1 mês atrás

Elemar, parabéns pela iniciativa! Segue um pequeno review:

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

acredito que a tradução neste caso ao invés de “a relações entre eles” seria “as relações entre eles”…

Daniel
Daniel
28 dias atrás
Feedback no conteúdo deste capítulo Há também, sistemas que evoluem suas arquiteturas com base em modismos, influências de terceiros ou preferências difíceis de justificar. Nestes…" Ler mais »

Concordo com esses pontos, eu já tive que trabalhar com uma empresa de mercado chamada cobrebem, pq a empresa que eu trabalhava, não queria usar um player de mercado mais moderno, por ter um custo mais elevado.

Guilherme
Guilherme
25 dias atrás
Feedback no conteúdo deste capítulo Há também, sistemas que evoluem suas arquiteturas com base em modismos, influências de terceiros ou preferências difíceis de justificar. Nestes…" Ler mais »

Acho importante considerar uma seção de aspectos históricos da arquitetura, começando pelo trabalho de David Parnas, dos anos 70, que aborda a modularização e indiretamente, coesão e acoplamento.

Wesley
Wesley
10 dias atrás
Feedback no conteúdo deste capítulo 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,…" Ler mais »

Aqui acho que vale destacar que, embora não sejam decisões de arquitetura, podem ser influenciadas por ela.
Podemos adotar IoC, DI, composição e SOLID visando alguns objetivos da arquitetura, como permitir fácil e rápida manutenção ou evolução ao termos um design mais desacoplado e testável.

Acredito que seja importante sempre ter em mente os objetivos da arquitetura no momento de design.
Uma vez li que arquitetura é a interpretação da relação entre os componentes do sistema e design é a interpretação da implementação dessa relação. Aqui acredito que interpretação tenha sido usado porque nem sempre o que tá implementado foi o acordado.

ElemarJúnior

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

Mentorias

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.

ElemarJúnior

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

TECH

&

BIZ

-   Insights e provocações sobre tecnologia e negócios   -   

55 51 9 9942 0609  |  me@elemarjr.com

55 51 9 9942 0609  |  me@elemarjr.com

bullet-1.png

55 51 9 9942 0609  |  me@elemarjr.com

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