Sobre as práticas de arquitetura de software

Este capítulo possui uma versão mais recente:

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 é atividade 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.

Todo software tem sua arquitetura. Algumas “emergiram” de forma não supervisionada e, por isso, têm qualidade questionável. Software bem-feito tem boa arquitetura e é difícil que isso aconteça sem a atuação de alguém competente como arquiteto.
5
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.
2
Que definições você utiliza para arquitetura de software?x

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)

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.
2
Você concorda com essa afirmação? Há algo a ponderar aqui?x
Por outro lado, arquiteturas ruins geralmente tem componentes fracamente delimitados, com forte sobreposição, difíceis de manter e, sobretudo, caros para evoluir.

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

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

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

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

As melhores práticas de arquitetura resolvem de maneira 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”.

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

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

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

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

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

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.

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.
4
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.
1
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?

Compartilhe este capítulo:

Compartilhe:

Comentários

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

Inscrever-se
Notify of
guest
27 Comentários
Oldest
Newest Most Voted
Feedbacks interativos
Ver todos os comentários
Daniel
Daniel
2 anos atrás
Feedback no conteúdo deste capítulo A maioria das decisões de design são individuais, em conformidade com os acordos estabelecidos pelo time de desenvolvimento e acontecem…" Ler mais »

Elemar, você pode relacionar mais alguns exemplos concretos de decisões de design? Em parágrafo anterior você cita a criação da classe repositório como uma decisão de design e a escolha por cloud-ready como sendo decisão de arquitetura. Você pode exemplificar outras decisões de design individual e decisões de design na arquitetura? Na minha opinião a afirmação de que “elas tem impacto maior e são menos frequentes”, ficou muito vago e abstrato.

Ewerton Mattos
Ewerton Mattos
2 anos atrás
Responder para  Daniel

Concordo. Pra mim não ficou bem claro a distinção entre decisões de design e decisões arquiteturais.

Daniel
Daniel
2 anos atrás
Feedback no conteúdo deste capítulo Há quem defenda que as boas práticas arquiteturais devem ser reforçadas por todo o time de desenvolvimento e eu concordo…" Ler mais »

Elemar, que tal adicionar em algum ponto do texto qual é o papel do Engenheiro de Software e as diferentes responsabilidades em relação a um Arquiteto?

Ewerton Mattos
Ewerton Mattos
2 anos atrás
Responder para  Daniel

Concordo, existe uma dificuldade em distinguir as responsabilidades deste dois profissionais.
Certa vez li um texto que dizia que essa confusão existe porque o conceito de Arquiteto e Engenheiro aqui no Brasil é o exato oposto do que é nos EUA e Europa, pra explicar melhor, lembro que o texto tinha uma tabela mais ou menos assim:

  • Arquiteto no Brasil: Um DEV muito experiente que se preocupa em como os componentes do software relacionam-se entre si.
  • Engenheiro no Brasil: Um analista que se preocupa com todo o ciclo de desenvolvimento de um produto (desde o levantamento de requisitos até o deploy e treinamento dos usuários
  • Arquiteto Fora do Brasil: O termo não é muito usado por lá, mas tem atuação mais abrangente que o Engenheiro.
  • Engenheiro Fora do Brasil: Um DEV com qualquer experiência, o termo é comummente usado para designar alguém que é apenas programador.

Particularmente, acho que a definição brasileira esta “menos errada”.

Daniel
Daniel
2 anos atrás
Feedback no conteúdo deste capítulo A alocação de uma pessoa em atividades de arquitetura pode variar significativamente conforme a complexidade ou os riscos do software…" Ler mais »

Uma questão que me vem aqui é a dificuldade para o alcance do equilíbrio entre as responsabilidades do Arquiteto e quando ele não escreve mais código de forma a se distanciar da realidade dos desenvolvedores e começar a apenas definir modelos bonitos no papel, mas que estão longe da realidade do dia a dia das equipes.

Antonio Nascimento
Antonio Nascimento
2 anos atrás
Feedback no conteúdo deste capítulo Todo software tem sua arquitetura. Algumas “emergiram” de forma não supervisionada e, por isso, têm qualidade questionável. Software bem-feito tem…" Ler mais »

Uma coisa a se deixar claro aqui é que o diferencial é a existência de pessoas competentes. As vezes essa pessoa competente desenha uma boa arquitetura sem necessariamente possuir o título de arquiteto.

Wiliam Buzatto
Wiliam Buzatto
2 anos atrás
Feedback no conteúdo deste capítulo Embora não exista consenso absoluto sobre o conceito, alguns aspectos são amplamente aceitos. Qualquer discussão madura sobre a arquitetura de…" Ler mais »

Hoje eu penso muito que tudo é sobre relacionamentos(ligações e conexões), desde o menor nivel(atributos) até o mais amplo (entre sistemas)
Como uma classe se relaciona com outra, uma função, um componente, container, sistemas.
A Arquitetura é como as coisas se relacionam.

Antonio Nascimento
Antonio Nascimento
2 anos atrás
Feedback no conteúdo deste capítulo As melhores arquiteturas, geralmente, tem componentes com baixo acoplamento. Ou seja, que funcionam e evoluem de maneira independente, com pouco…" Ler mais »

Sempre levo esse como o feijão com arroz da arquitetura. Alta coesão e Baixo acoplamento. Se o trabalho de um arquiteto tivesse que ser reduzido a apenas uma atividade, essa atividade seria manter o equilíbrio destes dois itens.

Wiliam Buzatto
Wiliam Buzatto
2 anos atrás
Feedback no conteúdo deste capítulo As melhores arquiteturas, geralmente, tem componentes com baixo acoplamento. Ou seja, que funcionam e evoluem de maneira independente, com pouco…" Ler mais »

Acredito que isso possui grande valor em projetos de software, pois também habilita maior testabilidade.
Outro ponto que anda junto com baixo acoplamento é a coesão interna das partes desacopladas, afinal software precisa de bons relacionamentos.

William Santos
William Santos
2 anos atrás
Feedback no conteúdo deste capítulo As decisões sobre design que são parte da arquitetura de um software são aquelas que tem relação direta com o…" Ler mais »

Há um breve post do Kent Beck que sugere que arquitetura e design sejam “apenas design”, ou seja, que essa divisão em níveis entre o que seria arquitetura e design não faria sentido.

Segue o link:
https://kentbeck.substack.com/p/elements-all-the-way-down

Ricardo Viana
Ricardo Viana
2 anos atrás
Feedback no conteúdo deste capítulo Todo software tem sua arquitetura. Algumas “emergiram” de forma não supervisionada e, por isso, têm qualidade questionável. Software bem-feito tem…" Ler mais »

Isso é um fato, sou testemunha de casos em que a escolha da arquitetura foram apenas por saber que muitas empresas no mercado tem usando por exemplo, aplicação da modinha atual uma aplicação front-end e outra back-end baseada na arquitetura SOFEA, mas que talvez não atenda a necessidade do cliente e o seu negocio, importante alguém competente para desenhar boa arquitetura.

Wiliam Buzatto
Wiliam Buzatto
2 anos atrás
Feedback no conteúdo deste capítulo 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,…" Ler mais »

Discordo em partes.
Frequentemente acredito que é causalidade.
Não vejo uma empresa contratando arquiteto que não tenha forte background de desenvolvimento.
A causalidade entra aqui: Muitas vezes o Dev sênior não encontra uma maneira de progressão de carreira desejada e acaba tornando-se Arquiteto.

Há empresas que possuem papéis de Dev Master, Dev Principal etc. dando um horizonte maior para esses excelentes Desenvolvedores. Todos ganham.

Antonio Nascimento
Antonio Nascimento
2 anos atrás
Feedback no conteúdo deste capítulo A maioria das decisões de design são individuais, em conformidade com os acordos estabelecidos pelo time de desenvolvimento e acontecem…" Ler mais »

Daniel, um exemplo de decisão individual de design é quando um programador decide utilizar algum padrão de projeto com o intuito de completar uma tarefa. Estou correto?

Antonio Nascimento
Antonio Nascimento
2 anos atrás
Feedback no conteúdo deste capítulo As práticas de arquitetura de software maximizam a produtividade. Ou seja, a relação entre o valor obtido (desempenho) e o…" Ler mais »

Além de melhorar o ROI, uma boa arquitetura necessita ter um custo de manutenção (TCO) baixo.

Bruno Soares
Bruno Soares
2 anos atrás

Seria bom ter uma definição de design de software, antes de definir quais são e não são arquiteturais?

Henrique Eduardo Souza
Henrique Eduardo Souza
2 anos atrás
Feedback no conteúdo deste capítulo Todo software tem sua arquitetura. Algumas “emergiram” de forma não supervisionada e, por isso, têm qualidade questionável. Software bem-feito tem…" Ler mais »

Vejo muitos softwares construídos com base na “carteirada driven architecture”, as muitas vezes até existe um profissional competente por trás da solução, mas a companhia tem a necessidade vender a licenças de software A ou B ou cloud A, W ou G e acaba empurrando contra a vontade do Arquiteto o melhor cenário para o cliente. Eu já fui parte de um processo assim, o que me restou foi abandonar a consultoria e muitas vezes fui taxado de “onesticida” por avisar ao cliente que a prática poderia custar mais caro com esse cenário.

Felipe Salvador
Felipe Salvador
2 anos atrás
Feedback no conteúdo deste capítulo 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,…" Ler mais »

Ainda existe o arquiteto de software nas empresas atualmente? Uma pessoa deve ser responsável por toda a arquitetura de um sistema ou isso deveria ser tarefa pra vários ou talvez pra equipe inteira?
Li um artigo recente sobre o processo de arquitetura em uma grande empresa em que todo o time ajudou a desenhar a arquitetura.

Antonio Nascimento
Antonio Nascimento
2 anos atrás
Feedback no conteúdo deste capítulo A decisão de adotar microsserviços, por exemplo, transfere parte da complexidade de desenvolver um software para sua operação. Há mais…" Ler mais »

A máxima não existe bala de prata também vale para microserviços. Apesar de suas vantagens, dependendo do tamanho da empresa e sua visão de crescimento uma arquitetura de microserviços atrapalha mais que ajuda

Matheus Bortolon
Matheus Bortolon
2 anos atrás
Feedback no conteúdo deste capítulo Todo software tem sua arquitetura. Algumas “emergiram” de forma não supervisionada e, por isso, têm qualidade questionável. Software bem-feito tem…" Ler mais »

Em times com profissionais muito experientes, a arquitetura pode ser eficiente para o cenário mas não estar aderente ao planejamento estratégico da empresa.

Antonio Nascimento
Antonio Nascimento
2 anos atrás
Feedback no conteúdo deste capítulo 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,…" Ler mais »

Eu acho que isso se encaixa muito com o modelo Dreyfus de aquisição de competência. Quanto maior seu conhecimento, mais capaz de enxergar o “Big Picture” você se torna. Acho muito difícil (diferente de impossível) uma pessoa sem o tempo de experiência necessário ser capaz de possuir o alto grau de abstração necessário para executar a tarefa de arquitetura.

Pedro Oliveira
Pedro Oliveira
2 anos atrás
Feedback no conteúdo deste capítulo 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,…" Ler mais »

O trabalho de arquitetura consiste em proposição, avaliação de riscos, custos e impactos e posterior tomada de decisão.

Sem sólidos conhecimentos técnicos, o arquiteto vira apenas uma fonte de eco e propagador de ruídos (essa é minha experiência, pelo menos).

Esses conhecimentos técnicos podem ser focados em outras áreas, que não desenvolvimento (infraestrutura, banco de dados, sistemas embarcados, etc. – dependendo do negócio).

Julgamento sem conhecimento é palpite vazio.

Bruno Soares
Bruno Soares
2 anos atrás

Seria correto afirmar que em softwares com arquitetura problemática, antes de agir devemos entender quem está sendo mais afetado são a regra de negócio, as restrições ou a qualidade?

Evandro Oliveira
Evandro Oliveira
2 anos atrás
Feedback no conteúdo deste capítulo Na prática, isso significa, por exemplo, que qual framework utilizar no frontend, por exemplo, é menos relevante, sob a perspectiva…" Ler mais »

É muito comum no processo de desenvolvimento do frontend começar a projetar o sistema a partir das ferramentas que um framework disponibiliza ao invés de primeiro entender quais são os desafios que precisam ser resolvidos a nível de arquitetura.

Marcos Tito
Marcos Tito
2 anos atrás
Feedback no conteúdo deste capítulo Todo software tem sua arquitetura. Algumas “emergiram” de forma não supervisionada e, por isso, têm qualidade questionável. Software bem-feito tem…" Ler mais »

Sim concordo. Diria que uma boa arquitetura facilita a construção de um software bem-feito.

Marcos Tito
Marcos Tito
2 anos atrás
Feedback no conteúdo deste capítulo Embora não exista consenso absoluto sobre o conceito, alguns aspectos são amplamente aceitos. Qualquer discussão madura sobre a arquitetura de…" Ler mais »

Arquitetura de Software é o que delimita até onde os desenvolvedores de uma solução, podem exercer sua criatividade, sem que causem mais danos do que benefícios.

Andrew Bezerra
Andrew Bezerra
2 anos atrás

Uma definição que mais me chamou atenção foi a do Clements: “The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them and properties of both.”
Gostaria muito de saber sua opnião sobre essa definição. 😉

Bruno Lima
Bruno Lima
2 anos atrás
Feedback no conteúdo deste capítulo As práticas de arquitetura de software maximizam a produtividade. Ou seja, a relação entre o valor obtido (desempenho) e o…" Ler mais »

Concordo totalmente.
Em cenários onde a arquitetura é ruim, perdas financeiras ocorrem em um curto prazo devido a vários fatores: indisponibilidade da aplicação, bugs, maior tempo para entrega de mudanças requisitadas pelo negócio e, consequentemente, impactando no resultado da empresa.

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

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