Conhecimento e tecnologia que transformam

Somos uma das maiores desenvolvedoras de software do país e atendemos diversos segmentos de extremo impacto para a sociedade, com soluções que são referência de transformação digital nos setores público e privado.

Conheça a Softplan
+ 0 anos
de mercado
+ 0
colaboradores especializados
+ 0 prêmios
nacionais e internacionais
+ 0
clientes de diversos segmentos

Soluções inovadoras e customizadas para cada setor

Imagem Soluções Digital Transformation

Soluções Digital Transformation

Oferecemos soluções de transformação digital para diversas instituições do Setor Público.

Imagem Soluções MultiSaaS

Soluções MultiSaaS

Oferecemos um ecossistema de soluções que atendem as demandas de gestão de negócios recorrentes em diversos segmentos.

Veja quem já inovou com nossos softwares

Ford
Cielo
Assaí
Natura
BTG Pactual
TJSP
Prefeitura Ribeirão Preto
Prefeitura Barueri
Cury Construtora
Lumis Construtora
Unimed Grande Florianópolis
Prefeitura de Juíz de Fora
Encorp
Prefeitura de Balneário Camboriú
DER DF
"

O que nossos clientes têm a dizer

O Obras.gov vai muito além da gente simplesmente lançar as informações dentro do sistema digital (...) Ele pega o processo desde a origem até o seu final, até o encerramento de um contrato. Tudo sendo lançado dentro do sistema. Aonde a operacionalidade da gestão do contrato passa a ser não só fazer uploads de documentos, não é só escanear e subir os documentos, mas sim processar as informações.

Humberto Schmidt

Coord. Projeto Avança Saúde São Paulo | Secretaria Municipal de Saúde de São Paulo 

Acreditamos que em médio prazo veremos Barueri efetivamente sem papel, em especial, já começando pela Secretaria de Administração. Fico muito feliz com a empresa Softplan, que pelo que vi é muito conceituada, transparente e que trabalha com órgãos públicos de primeira linha, como o nosso Tribunal de Justiça do Estado de São Paulo. Já é um ponto muito confiável e que, com a competência do CIT, nós rapidamente chegaremos a um êxito em Barueri e teremos ainda mais orgulho da nossa cidade.

Cilene Rodrigues Bittencourt

Secretária de Administração da Prefeitura de Barueri

O Sienge é a espinha dorsal, o principal sistema. Qualquer outra ferramenta que precise ser utilizada por alguma das áreas da empresa tem que partir do que nós tivermos no Sienge.

Sabrina Ribeiro

COO da Cury Construtora

O Assaí preza muito pela saúde de nossos clientes e colaboradores. O Checklist Fácil permite que a gente consiga fazer o controle simultâneo de todas as lojas, entender as melhorias e já tratar as inconformidades. Se fosse tudo em papel, seria bem complicado.

Natalia Figueiredo

Coordenadora de Formação Técnica em Segurança dos Alimentos do Assaí Atacadista

"

Últimas postagens no blog

Ver todas
ESG e Tech: Tudo a ver!

TECH WRITERS

ESG e Tech: Tudo a ver!

O que é ESG ESG é um acrônimo que aglutina ações, práticas e frentes de trabalho relacionadas à temática de Meio ambiente (E de Environment), Social e Governança. Essa tríade constitui um conjunto de práticas e princípios corporativos já inescapáveis como direcionador de investimentos, reputação e share of mind and hearts. A correlação positiva entre o desempenho em ESG (quando executado de forma estratégica, holística e genuína) e um resultado superior tanto em termos financeiros quanto de reputação já foi comprovada. Esses papers da Harvard Business Review e do Center for Sustainable Business da NYU explicam em detalhes essa correlação. E esse vídeo da consultoria KPMG explica de forma mais sucinta o que é ESG. Quem quiser fazer um cursinho rápido pra mergulhar um pouco mais profundo, recomendo esse aqui da consultoria, e parceira da Softplan, Deep ESG.  No último ano a Softplan começou a mergulhar fundo nesse assunto. O mapeamento de relevância de impactos da companhia em seus clientes (o mais importante stakeholder da empresa ao lado de colaboradores) é uma entre as múltiplas iniciativas de um programa de ESG. Em uma empresa como a Softplan, em que nos consideramos "especialistas em traduzir conhecimento e tecnologia em soluções que simplificam e impactam diariamente a vida de milhares de pessoas no Brasil e no mundo”, permear esse conhecimento na área desenvolvimento (aqui considerando produto, design, engenharia e arquitetura de software) possa talvez ser a estratégia mais efetiva para fazer valer essa afirmação. Concluímos recentemente esse trabalho de mapeamento para as soluções que atendem clientes do Setor Público, seguindo essa norma bem rigorosa do Global Reporting Initiative.  Impactos, fatos e como ESG e Tech se combinam  Falando sobre Segurança da Informação, nosso "mestre Jedi" Alexandre Golin elencou, em 2009, os 4 princípios do SAJ Tribunais à época: Integridade, Autenticidade, Não-repúdio e Irretroatividade (arrisco a dizer que tem um quinto princípio oculto que é a inviolabilidade). De lá pra cá muitos conceitos, práticas e exigências foram aperfeiçoadas, inclusive aqui na Softplan. Atualmente, temos muito orgulho em afirmar que esses quatro (ou cinco) princípios são norteadores de todas as soluções da companhia. Pois bem, Segurança da Informação, em uma dobradinha com Privacidade de Dados, foi considerado um impacto relevante pelos clientes de todas as soluções para setor público. Na dúvida sobre atualizar determinado componente da aplicação? Saiu um monte de curso gratuito de Devops e não sabe qual fazer? Questões relacionadas à segurança da informação e privacidade de dados serão sempre um porto seguro.  Não vamos esquecer do ‘E’ de Environment, que também tem tudo a ver com Produto, Design, Desenvolvimento e Arquitetura. Redução de emissão de carbono é um impacto relevante em praticamente todas as soluções. Uma coisa que une todas as soluções da Softplan é a digitalização de processos e redução do uso de papel. Por exemplo, o lema da 1Doc é "Vamos tirar do papel?". O saldo em emissões de CO₂ da substituição do papel, além de tudo que não é emitido pelo papel não ser produzido, transportado, armazenado e descartado, por processos digitais e suas emissões decorrentes do consumo de energia dos datacenters e infraestruturas costuma ser positivo em mais de 75%. Mas e se eu disser pra vocês que em 2022 o conjunto dos 92 tribunais do Brasil imprimiu mais de 500 milhões de folhas de papel? Esses dados são dos Tribunais como um todo, que não são necessariamente da área judicial. Dá uma pena danada, né? Mas, por que será que eles ainda imprimem tanto papel se mais de 90% de seu acervo é digital? Será que é só porque é mais cômodo? Provavelmente não. Nossos designers têm investido bastante para trazer maior ergonomia e conforto às nossas telas, para minimizar a necessidade de impressão. Esse assunto oferece um roadmap gigante de épicos e stories e discoveries. E as métricas de resultado estão aqui na nossa cara. Cada vez mais órgãos públicos possuem programas de logística sustentável onde o consumo de papel é aferido. E pra quem gosta de economia comportamental, fica a dica de inserir aquele nudge esperto no rodapé de cada página: “A não impressão desse papel evitou o desmatamento de N árvores”.  Ainda dentro do ‘E’, Devops/DBAs que fazem a gestão de dados na nuvem, vocês sabiam que os consoles da AWS permitem a adoção de critérios de sustentabilidade? Dá pra selecionar regiões mais eficientes (máquinas mais performáticas e novas, fonte de energia renovável), implementar “design que garanta alta utilização e maximização de eficiência de energia do hardware subjacente” e usar serviços gerenciados. Para quem não conhece, é um mundo novo e, na maioria das vezes, a sustentabilidade vai gerar economia financeira e eficiência operacional.  A atuação da Softplan no setor público permite que nossas soluções tenham um impacto direto em milhões de pessoas. Em 2022 os portais de acesso externo de nossas soluções tiveram um volume médio 4,3 bilhões de consultas e 3,2 milhões de novos processos/demandas por mês! Garantir uma entrega de qualidade aos clientes significa mais prosperidade, eficiência e bem-estar à sociedade, que passa a ter acesso a serviços públicos mais eficientes e de melhor qualidade. Mas, como assim?  Vamos pensar em um Tribunal de Justiça: Como medimos a eficiência (opa, mais um Impacto, e esse talvez o mais importante, dentro do ‘S’ de Social) de um Tribunal? Nós sabemos quais são os resultados esperados de um Tribunal eficiente. E também sabemos como nossa solução contribui diretamente e indiretamente para esses resultados. Esse conhecimento, disseminado dentro dos times (reiterando, nosso modelo de atuação exige conhecimento e propriedade em todos os níveis funcionais das áreas fim), provê uma referência tanto para os clientes quanto pra gente, do que priorizar, qual o ritmo das entregas e como vamos medir se as entregas estão trazendo os resultados esperados.  E o que importa para um Tribunal de Justiça? Ele precisa oferecer um canal para usuários externos consultarem e abrirem processos judiciais. Melhorar e ampliar o acesso da sociedade aos órgãos públicos também é um impacto mapeado. Esse canal precisa ter acesso amplo (múltiplos serviços) e ser ágil (performático e com alta disponibilidade). Perceberam que essas características, que possuem métricas muito objetivas, já oferecem os drivers necessários para o grooming? Na parte da eficiência, mapeamos no máximo 4 indicadores por solução. Foi difícil (para nós e para os clientes), porém focar nos mais importantes ajuda a pensar na big picture. No caso de Tribunais, um dos indicadores mede variações de estoque de um ano para o seguinte, outro indicador mede a duração dos processos, outro a capacidade de atender a demanda (que é dinâmico e depende das entradas) e outro, a Meta 2 do CNJ, determina que se devem julgar primeiro os processos mais antigos. Está aqui um direcionador fantástico para estimular os times e os clientes para conceber e implementar soluções que: reduzam o estoque de processos, priorizando os mais antigos, dentro de durações de processos sustentáveis e sempre ligados no benchmarking dos Tribunais do mesmo porte. Para PMs e POs que adoram matrizes de priorização, aqui há um prato cheio para pontuar stories e tasks.  Essa pegada funciona para todas as nossas soluções! Vamos pensar no Sider, que digitaliza inúmeros serviços dentro das estruturas de secretarias de infraestrutura e departamentos de estradas e rodagens. Aqui também temos o impacto do acesso de cidadãos e empresas a esses serviços. Os portais de acesso atuam como balcões virtuais de atendimento. E como se mede o nível desse serviço? Primeiramente o serviço precisar estar disponível e ser amplo, tem que dar pra fazer tudo por lá: consultar, abrir demandas, pedir e acessar informações e documentos e pagar coisas. Em seguida, pode-se avaliar o tempo de atendimento dos principais serviços. Está aqui o driver para o desenvolvimento! Precisamos ampliar o acesso e diminuir ao máximo o tempo de atendimento. Para fazer isso, temos que estar cientes também do arcabouço regulatório dos órgãos. Atender a esse arcabouço também é um impacto relevante indicado pelos clientes. Tem que diminuir o tempo, respeitando os trâmites, procedimentos e prazos legais.  Como a Softplan tem capilaridade nacional e expertise, aqui podemos atuar em rede, como um hub, absorvendo, alimentando, retroalimentando, transferindo e compartilhando conhecimento e boas práticas entre órgãos de todo o país. Certeza de que alguém acabou de correlacionar isso com a transformação digital. Pois bem, fomentar a transformação digital foi considerado um impacto relevante em todas as nossas soluções que atendem ao setor público. Aqui ampliamos o alcance de ESG para times residentes, de suporte, de comunicação e de relacionamento.   Perceberam como ESG e você (colega Dev, DBA, PM, PO, UXer e afim) tem tudo a ver? Não é simples, mas também não é nada do outro mundo.  Recapitulando:  Precisamos definir impactos e seus indicadores e métricas de forma metodologicamente rigorosa, engajar clientes e especialistas internos (e externos) de forma genuína.  Coletar e disponibilizar dados e evidências em forma de indicadores.  Usar os dados como insumo, considerando contexto e especificidades. Não subestimar o ambiente externo, pois ele é complexo e dinâmico.  Permear o conhecimento no time. Fomentar discussões e análises críticas. Focar sempre na big picture. Quais são os principais impactos e os indicadores que mexem os ponteiros? Focar neles prioritariamente.  Garantir que, ao longo do tempo, os impactos relevantes sigam relevantes e os indicadores adequados sigam adequados. Voltar para primeira opção. 

Angular: Por que você deve considerar esse framework front-end para sua empresa

TECH WRITERS

Angular: Por que você deve considerar esse framework front-end para sua empresa

Um medo de toda equipe é escolher uma ferramenta que se tornará obsoleta rápido. Caso você esteja desenvolvendo aplicações há alguns anos, possivelmente já vivenciou isso. Por isso, a escolha de boas ferramentas é uma tarefa que envolve responsabilidade, pois pode guiar o projeto (e a empresa) para o sucesso ou para um mar de problemas e gastos. Neste artigo, vamos entender os usos e benefícios do framework Angular. Escolher um framework front-end não é diferente e também envolve pesquisas e estudos. A escolha de uma “stack”, como chamamos nesse mundo, é trivial tanto para o presente mas também para o futuro. No entanto, algumas perguntas irão surgir no meio dessa escolha:  Encontraremos profissionais capacitados para lidar com esse framework?  Conseguiremos manter um ritmo de atualizações?  Há um plano bem definido para a direção que o framework está indo?  Há uma comunidade (entendemos aqui também por grandes empresas apoiando) engajada?  Todas essas perguntas devem ser respondidas antes de começar qualquer projeto, pois negligenciar uma telas pode levar a cenários devastadores para o produto, e consequentemente para a empresa e seus lucros.  Motivações para se usar um framework  A resposta talvez mais direta seja que as vezes é bom não ficar reinventando a roda. Problemas rotineiros como lidar com rotas de uma aplicação web, ou mesmo o controle de dependências, geração do bundle otimizado para publicação em produção, todas essas tarefas já tem boas soluções desenvolvidas, e, por isso, escolher um framework que te entrega esse conjunto de ferramentas é perfeito para ganhar produtividade, solidez no desenvolvimento de uma aplicação e também manter a mesma sempre atualizada seguindo as melhores práticas.  Bem como as motivações diretas, posso citar também:  A facilidade de encontrar ferramentas que se integram com o framework  A busca por um software com qualidade, integrado a testes e outras ferramentas que irão tornar o processo de desenvolvimento maduro  Muitas situações e problemas já resolvidos (porque há muita gente trabalhando com a tecnologia)  Motivações para o uso do framework do Angular:  Construído usando Typescript, uma das linguagens mais populares do momento  Arquitetura MVC  Controle e Injeção de dependências  Modularização (com opção de carregamento lazy load)  Boas bibliotecas para integração  Comunidade grande e engajada  1835 contribuidores no repositório oficial  Oficialmente apoiada e mantida pelo time do Google  A solidez do Angular  Atualmente, podemos afirmar com clareza que o framework é estável, recebendo atualizações frequentes por sua natureza fundada no open-source. Isso porque é mantido pelo time do Google, que procura sempre deixar o roadmap do que está por vir o mais claro possível, o que é muito bom. Além disso, a comunidade Angular é bastante ativa e engajada. É difícil você ter um problema que já não foi resolvido.  Uma das preocupações de todo desenvolvedor é em relação a mudanças drásticas de uma ferramenta. Quem viveu a época da mudança da V1 para V2 do Angular sabe essa dor, praticamente a mudança foi total. Porém, o framework de forma correta se fundou com base no Typescript que trouxe robustez e mais um motivo para sua adoção: com o Typescript, temos possibilidades que o Javascript sozinho não consegue resolver: tipagem forte, integração com o IDE facilitando a vida dos desenvolvedores, reconhecimento de erros em tempo de desenvolvimento, e muito mais.  Atualmente, o framework está na versão 17 e vem ganhando cada vez mais maturidade e solidez, com o incremento de funcionalidades inovadoras como defer lançada recentemente.  Upgrade facilitado  O framework fornece um guideline para todo upgrade através do site https://update.angular.io, esse recurso ajuda muito a guiar a atualização do seu projeto.  CLI completo  O Angular é um framework. Logo, ao instalar seu pacote teremos o CLI pronto para inicializar novos projetos, gerar componentes, executar testes, gerar o pacote final e manter as atualizações da sua aplicação:  Para criar seu primeiro projeto, basta abrir o seu terminal, e rodar o comando a seguir:  Sólidos projetos de interface  Se você precisa de um design para sua aplicação que fornece componentes já prontos para uso como alertas, janelas de modal, avisos snackbar, tabelas, cards, uma das possibilidades mais populares é a escolha do Material Angular, um bom ponto para seguir o seu software com ele é porque é mantido pelo Google, logo sempre que o framework avança em versão o Material usualmente acompanha essa atualização.  Além do Material, existem outras opções na comunidade, como o PrimeNG, que trás um conjunto muito interessante (e grande) de componentes.  Suporte a biblioteca Nx  O Angular possui suporte completo ao projeto Nx, que possibilita escalar seu projeto de forma bastante consistente, garantindo principalmente cache e possibilidades avançadas para você manter e escalar sua aplicação local ou no seu ambiente de CI.  Aqui estão alguns exemplos específicos de como o Nx pode ser usado para melhorar um projeto Angular:  Você pode criar uma biblioteca Angular que pode ser reutilizada em vários projetos.  Você pode criar um monorepo que contenha todos os seus projetos Angular, o que facilita a colaboração entre equipes.  Você pode automatizar tarefas de desenvolvimento comuns, como a execução de testes e a implantação de seus projetos.  Testes (unitários e E2E)  Além do Karma e o Protactor que nasceram com o framework, agora você é livre para usar projetos populares como Jest, Vitest e Cypress.  State com Redux  Uma das bibliotecas mais utilizadas pela comunidade é a NgRx Store, que fornece gerenciamento de estado reativo para aplicativos Angular inspirados em Redux.  GDEs brasileiros  No Brasil temos atualmente dois GDEs Angular, o que é importante para nosso país e também para geração de conteúdo Angular em português, trazendo para nossa comunidade novidades e insights sempre atualizados direto do time do Google.  Loiane Gronner William Grasel Alvaro Camillo Neto Grandes empresas utilizando e apoiando  Talvez a mais notória seja o Google, mantenedor oficial do framework. A empresa possui diversos produtos construídos usando Angular e nos últimos anos vem apoiando ainda mais o desenvolvimento e evolução da ferramenta.  Um ponto importante ao escolher um framework é saber que grandes empresas estão utilizando, isso porque nos dá um sinal de que aquela ferramenta terá apoio para atualizações e evolução já que ninguém gosta de ficar reescrevendo produtos do zero, aqui vou citar algumas empresas globais que usam Angular em seus produtos, sites, serviços para a web:  Google  Firebase  Microsoft  Mercedes Benz  Santander  Dell  Siemens  Epic  Blizzard’s  No cenário nacional também temos exemplos de grandes empresas utilizando o framework com sucesso, podemos citar algumas:  Unimed Cacau Show  Americanas  Checklist Fácil  Picpay  Quer saber mais? Se interessou em começar com Angular? Acesse https://angular.dev/, a mais nova documentação do framework que trás tutoriais, playground e uma boa documentação bem explicada.  Bom código! 

Modelo Arquitetural: como escolher o ideal para seu projeto

TECH WRITERS

Modelo Arquitetural: como escolher o ideal para seu projeto

O que é um Modelo Arquitetural e qual a sua importância?  Basicamente, um modelo arquitetural é a estrutura abstrata sobre a qual sua aplicação será implementada.  "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, & Kasman, Software Architecture in Practice)  Para definir o modelo que mais irá se adequar ao seu projeto, precisamos conhecer bem as estratégias de curto, médio e longo prazo da empresa, os requisitos não funcionais e arquiteturais do software, assim como a curva de crescimento de usuários ao longo do tempo e a volumetria de requisições.  Bem como os pontos citados ao longo deste artigo, existem ainda outros a levar em conta na decisão de qual modelo arquitetural aplicar. Como exemplo, podemos listar:  Preocupações de segurança;  Armazenamento de dados;  Lockins;  Volume total de usuários;  Volume de usuários simultâneos;  TPS (transações por segundo);  Plano de disponibilidade/SLA;  Requisitos legais;  Disponibilidade em um ou mais tipos de plataformas;  Integrações.  O levantamento de arquitetura, RAs (requisitos arquiteturais), VAs (variáveis arquiteturais), RFs (requisitos funcionais), RNFs (requisitos não funcionais) e os critérios que definem cada um desses itens influenciam diretamente na escolha do modelo correto.  A escolha do modelo arquitetural pode impactar todo o life cycle da aplicação. Por isso, esse é um assunto que devemos tratar com grande atenção. O uso de MVPs (principalmente aqueles que não vão para produção), podem auxiliar muito nessa tarefa. Eles dão uma oportunidade única de errar, ajustar, errar novamente, provar conceitos, ajustar e errar quantas vezes forem necessárias para que no final o software possua a arquitetura na versão mais acertada, trazendo assim os verdadeiros ganhos dessa escolha.  Como estão divididos os modelos arquiteturais  É ideal deixar claro que como muitas definições no mundo do software, o que é, e quais são os modelos arquiteturais podem variar. Por isso, neste artigo procurei dividi-los em quatro grandes grupos: monolítico, semimonolítico (ou monolito modular), monolito distribuído (ou microlito) e microcomponentizado.  Monolítico  Modelo em que todos os componentes formam um único aplicativo ou executável integrados em um único código-fonte. Neste caso, todo ele é desenvolvido, implantado e escalado como unidade única.  Figura 1 – Exemplo de Modelo Monolítico. Prós  Simplicidade: como o aplicativo é tratado como uma unidade única e coesa, ele se torna mais simples, já que todas as partes estão contidas em um único código-fonte.  Maior aderência a Padrões de Projeto: levando em conta que temos um único código-fonte, outro fator que facilita é que os próprios padrões de projetos (Design Patterns, 01/2000) foram escritos em épocas de dominância dos monolitos, tornando a aplicação dos mesmos mais aderente.  Maior desempenho: devido à baixa latência na comunicação, os monolitos costumam ter um bom desempenho, mesmo utilizando tecnologias mais defasadas.  Menor consumo de recursos: a baixa complexidade, a simplicidade e a menor sobrecarga de comunicação entre camadas favorecem o menor consumo de recursos.  Troubleshooting facilitado: Criação dos ambientes de desenvolvimento e debugs são feitos de forma facilitada em monolitos, pois neles os componentes partilham dos mesmos processos. Outro fator que podemos levar em conta é que monolitos possuem menos pontos de falha externos, simplificando a busca por erros.  Contras  Tamanho de times limitados: quebras relacionadas a Continuous Integration e conflitos de merge acontecem com maior regularidade em monolitos, gerando dificuldades de trabalho paralelo para grandes times.  Escalabilidade: a escalabilidade pode ser limitada em certos aspectos. Mesmo com facilidade na escalabilidade vertical, muitas vezes a escalabilidade horizontal pode se tornar um problema que poderá afetar o crescimento da aplicação.  Disponibilidade de janelas: normalmente, para um monolito ocorrem trocas de executáveis, o que necessita de uma janela de disponibilidade sem que usuários acessem o aplicativo, o que não acontece com outros modelos arquiteturais que podem utilizar outras técnicas de deploy como o Blue-Green ou até mesmo trabalhar com imagens ou pods. Tecnologia única: a baixa diversidade tecnológica muitas vezes pode se tornar um impedimento para o crescimento da aplicação por atender somente um tipo de sistema operacional, por exemplo, ou não atender de forma integral novas features solicitadas pelos clientes por não possuir atualizações que tenham capacidade de solucionar problemas complexos.  Maior gasto com compilação e execução: grandes monolitos geralmente têm um tempo elevado para compilar e fazer a execução local, gerando um maior comprometimento de tempo de desenvolvimento.  Quando Usar  Escalabilidade e Disponibilidade Baixas: se a aplicação possui uma escala limitada em que, por exemplo, o número de usuários é baixo ou a alta disponibilidade não é mandatória, o modelo monolítico é uma boa solução.  Aplicações Desktop: o modelo monolítico é altamente indicado para aplicações desktop.  Times de baixa senioridade: modelos monolíticos, devido à sua simplicidade e localização dos componentes, possibilitam que times de baixa senioridade possam trabalhar com uma melhor performance.  Recursos limitados: para uma infraestrutura limitada com recursos escassos.  Semimonolítico (ou Monolito Modular)  Modelo em que as aplicações são compostas por partes de estruturas monolíticas. Neste caso, a combinação tenta equilibrar a simplicidade do modelo monolítico e a flexibilidade do microcomponentizado. Atualmente, esse modelo arquitetural costuma ser bastante confundido com microsserviços.  Figura 2 – Exemplo de Modelo Semimonolítico.  Prós  Traz benefícios dos modelos monolítico e microcomponentizado: com isso, é possível manter partes como estruturas monolíticas e microcomponentizar somente componentes que têm a real necessidade.  Diversidade tecnológica: possibilidade de usar diversas abordagens tecnológicas.  Infraestrutura diversificada: este modelo pode ser desenvolvido para utilizar tanto infra On-Premise quanto Cloud, favorecendo a migração entre ambas.  Suporta times maiores: a segmentação dos componentes favorece que vários times trabalhem paralelamente, cada qual em seu escopo. Especialidades Técnicas: devido à segmentação, aproveita-se melhor as hard skills do time, tais como frontend, UX, backend, QA, arquitetos, etc.  Contras  Padronização: devido ao grande número de componentes que podem surgir em um modelo semimonolítico, a padronização (ou falta dela) pode se tornar um grande problema.  Complexidade: a complexidade inerente a esse tipo de modelo também tende a aumentar com novas features. Logo, novos recursos como mensageria, cache, integrações, controle de transações, testes, entre outros, podem adicionar ainda mais complexidade ao modelo.  Budget: em modelos que amparam o uso de diversas tecnologias com times grandes, são necessários mais profissionais especialistas e com nível maior de senioridade, ocasionando muitas vezes um gasto maior com despesas de pessoal.  Troubleshooting complexo: a própria complexidade do modelo e a diversidade de tecnologias tornam cada vez mais difícil o troubleshooting da aplicação. Isso se dá devido à grande quantidade de pontos de falhas (inclusive externos à aplicação) que passam a existir e à comunicação entre eles.  Quando Usar  Aceito em Vários Cenários: é um modelo flexível que pode atender vários cenários, porém nem sempre da melhor forma.  Pouca Definição: em projetos que possuem incertezas ou até mesmo que não possuem a total definição de seus requisitos, este modelo é o mais indicado.  Em médias e grandes equipes: como dito, a divisão dos componentes em vários grupos facilita o trabalho paralelo de médias e grandes equipes. Normalmente, os grupos possuem seus próprios repositórios de código, o que torna o trabalho paralelo mais ágil.  Senioridade Diversa: este modelo se beneficia de times com essa formatação, pois softwares semimonolíticos apresentam desafios variados, tanto nas camadas de frontend e backend quanto em questões de infraestrutura (IaC – Infrastructure as a Code).  Infraestrutura: para uma infraestrutura Cloud-based ou híbrida, este modelo é mais aplicável. É um modelo que permite, por exemplo, uma adoção gradual entre On-Premise e Cloud, facilitando a adaptação e minimizando impactos operacionais.  Monolito Distribuído  Essa modelagem é uma modelagem "moderna" que também vem sendo implementada e confundida com o modelo microcomponentizado/microsserviços.   "You shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile." (Fowler, Martin. 2015)  Em resumo, neste modelo arquitetural o software é construído com bases do modelo monolítico, mas implantando conforme o modelo microcomponentizado. Atualmente, muitos o consideram um antipattern.  Figura 3 – Exemplo de Modelo Monolíto Distribuído. Não valeria à pena listarmos as características de prós (não sei se tem), mas ainda vale citar características que vão contra: este modelo arquitetural reúne pontos negativos dos outros dois estilos com o qual é confundido.   Nele, os serviços são altamente acoplados e também possuem vários tipos de complexidade, tais como: operacional,  testabilidade, deployment, comunicação e infraestrutura.  O alto acoplamento, principalmente entre os serviços de backend, traz sérias dificuldades no deployment, sem contar com o aumento expressivo de pontos de falha no software.  Microcomponentizado  Modelo de software em que todos os componentes são segmentados em pequenas partes totalmente desacopladas. Dentro de microcomponente, podemos citar:  Microfrontends  Microdatabases  Microvirtualizações  Microsserviços  Microbatches  BFFs  APIs  Figura 4 – Exemplo de Modelo Microcomponentizado. "A microservice is a service-oriented application component that is tightly scoped, strongly encapsulated, loosely coupled, independently deployable, and independently scalable" (Gartner, n.d.).  As opiniões se convergem a dizer que, todo o microsserviço que deu certo, primeiro foi um monolito que ficou grande demais para ser mantido e chegou a um ponto comum de ter que ser separado.  Prós  Escalabilidade: a escalabilidade neste modelo torna-se bastante flexível. Conforme a necessidade, escala-se os componentes de maneira específica. Desenvolvimento Ágil: as equipes podem trabalhar de forma independente em cada componente, facilitando a implantação contínua e acelerando o ciclo de desenvolvimento.  Resiliência: caso um componente falhe, não afeta necessariamente toda a aplicação. Isso melhora a resiliência geral do sistema. É importante salientar que existem abordagens de pontos únicos de falha a fim de evitar esse tipo de problema.  Tecnologia Diversificada: cada componente pode ser desenvolvido utilizando tecnologias diferentes, permitindo a escolha da melhor ferramenta para cada tarefa específica. Além disso, também favorece as skills existentes em cada time.  Facilidade de Manutenção: mudanças em um componente não afetam automaticamente outros, facilitando a manutenção e atualização contínua.  Desacoplamento: os componentes são independentes uns dos outros, o que significa que as mudanças em um serviço não afetam automaticamente outros, facilitando a manutenção.  Contras  Custo: custo elevado de todos os componentes deste modelo (input, output, requisições, armazenamento, ferramentas, segurança, disponibilidade, entre outros).  Tamanho: softwares microcomponentizados costumam ser maiores em sua essência. Não somente o tamanho da aplicação, mas todo o ecossistema que a permeia desde o commit até o ambiente produtivo.  Complexidade Operacional: existe um aumento exponencial da complexidade nesse modelo. Projetar bons componentes arquiteturais para que essa complexidade seja gerida é de grande relevância. É importante escolher e gerir bem ferramentas de logging, APM e Continuous Monitoring, por exemplo. Gerenciar muitos microsserviços pode ser complexo. É necessário um esforço adicional para monitorar, orquestrar e manter os serviços em execução.  Latência: a comunicação entre microsserviços pode se tornar complexa, especialmente em sistemas distribuídos, exigindo estratégias adequadas de comunicação e gerenciamento de API.  Overhead de Rede: o tráfego de rede entre microsserviços pode aumentar, especialmente em comparação com arquiteturas monolíticas, o que pode afetar o desempenho.  Consistência entre Transações: garantir consistência em operações que envolvem vários microsserviços pode ser desafiador, especialmente quando se trata de transações distribuídas.  Testabilidade:  testar interações entre microsserviços pode ser mais complexo do que testar uma aplicação monolítica, exigindo estratégias de teste eficientes.  Infraestrutura: pode ser necessário investir em uma infraestrutura robusta para suportar a execução de vários microsserviços, incluindo ferramentas de orquestração de contêineres e sistemas de monitoramento.  Dispersão Técnica: neste ponto, podemos dizer que existe uma ação da Lei de Conway "Reversa", pois os times, assim como tecnologias e ferramentas, tendem a seguir a dispersão e segregação. Nos times, cada um passa a ter conhecimento de uma pequena parte de um grande todo. Dessa forma, para tecnologias e ferramentas, cada desenvolvedor usa o framework ou ferramentas que mais lhe convém.  Domain-Driven Design: para aumentar as chances de sucesso desse modelo é necessário que os times tenham conhecimento de DDD. Quando Usar  Volumetria: a arquitetura de microsserviços/microcomponentes tem se mostrado eficaz em sistemas de alta volumetria, ou seja, aqueles que precisam lidar com grandes quantidades de transações, dados e usuários.  Disponibilidade: uma das principais razões para se adotar esse tipo de arquitetura é a disponibilidade. Quando bem construído, um software que adota microcomponentização não tende a falhar como um todo quando pequenas partes apresentam problema. Sendo assim, outros componentes continuam em operação enquanto o componente problemático se recupera.  Escalabilidade: se diferentes partes de sua aplicação têm requisitos de escalabilidade distintos, os microsserviços podem ser úteis. Você pode dimensionar apenas os serviços que precisam de mais recursos, em vez de escalar toda a aplicação.  Tamanho dos Times: times pequenos podem ser problemas. Configurações, boilerplates, ambientes, testes, integrações, processos de input e output.  Resiliência > Desempenho": em casos de incerteza, por exemplo, do volume de requisições e até onde ele pode chegar como grandes e-commerces em períodos de alto acesso (black friday) onde é necessário que o software seja mais resiliente e tenha um desempenho mediano.  Checklist Comparativo Figura 5 – Checklist Comparativo entre modelos. Conclusão  Em síntese, a escolha do modelo arquitetural é crucial para o sucesso do projeto, exigindo uma análise criteriosa das necessidades e metas. Cada modelo arquitetural tem suas vantagens e desvantagens e devemos guiar a decisão pelo alinhamento com os requisitos específicos do projeto. Ao considerar as estratégias da empresa, requisitos e levantamentos arquiteturais, é possível tomar uma decisão que impactará positivamente o ciclo de vida da aplicação.  O trabalho (e apoio) do time de arquitetura é de extrema importância. Sendo também de grande importância que a gestão e áreas correlatas apoiem disponibilizando tempo para o levantamento de toda essa gama de informações.   Ficou em dúvida ainda? A princípio, comece pelo semimonolítco/monolito modular. Da mesma forma, dê muita atenção a modelagem do banco de dados.  Referências  Gartner. (s.d.). Microservice. Recuperado de https://www.gartner.com/en/information-technology/glossary/microservice  Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.  Bass, L., Clements, P., Kazman, R. (2013). Software Architecture in Practice (3rd ed.). Addison-Wesley.  Microservices Architecture (12/2023). Recuperado de https://microservices.io/  Fowler, S. J. (2017). Microsserviços Prontos para a Produção. Novatec.  Treinamento ArchExpert. (s.d.). Conteúdo Premium. Recuperado de https://one.archoffice.tech/  Monolith First (06/2015). Recuperado de https://martinfowler.com/bliki/MonolithFirst.html  Microservices. Acessado em 01/2024. Recuperado de https://martinfowler.com/tags/microservices.html

Multi-brand design systems: o que são e principais benefícios

TECH WRITERS

Multi-brand design systems: o que são e principais benefícios

O que são multi-brand design systems  Os multi-brand design systems são sistemas com atributos que os tornam flexíveis para o uso em diferentes contextos, padrões visuais e de design de interfaces. São desenvolvidos para os casos nos quais uma única biblioteca visa atender a produtos de diferentes marcas.  Geralmente, esse tipo de design system também é independente de frameworks, plataformas ou tecnologias — são os chamados tech-agnostic design systems.  Atualmente, o design system agnóstico mais popular é o Lightning, desenvolvido pela Salesforce, também criadora do conceito.  Benefícios  Além de ser uma fonte única de verdade, o multi-brand design system compartilha o custo da operação, tornando o trabalho verdadeiramente colaborativo entre times. Segundo designers do grupo Volkswagen, a implementação do GroupUI trouxe os seguintes resultados:  Aumento da agilidade, eficiência e redução de custos são alguns dos benefícios dos multi-brand design systems. Escalabilidade  Desenvolvidos com base no conceito de design tokens, viabilizam que a mesma biblioteca seja replicada em diferentes produtos, independentemente do framework em que são desenvolvidas. Ao mesmo tempo, permitem que cada um desses produtos use seus próprios padrões visuais. Outro ponto muito relevante é o compartilhamento de características como boas práticas, responsividade, acessibilidade, performance, UX e ergonomia.  Uso em diferentes tecnologias  Atualmente, é comum encontrar em design systems, mesmo naqueles que atendem a uma única marca, diferentes bibliotecas para produtos web, iOs e Android. Isso acontece devido à existência de diferentes especificações para navegadores desktop e mobile, bem como entre dispositivos com sistemas operacionais nativos, como Apple e Google. Trabalhando de forma independente dessas tecnologias, é possível instanciar um mesmo design system em componentes de bibliotecas distintas para atender a essas particularidades.  Ganho de eficiência  Segundo dados divulgados por lideranças de UX e design systems do Grupo Volkswagen, por meio da apresentação Multibrand Design System within the Volkswagen group & its brands, há um grande aumento de agilidade, produtividade e eficiência ao trabalhar com o conceito multi-brand.  Eficiência operacional com o uso de multi-brand design systems. (Fonte: YouTube)  Comparando o esforço necessário entre um produto sem design system, passando por um que possui seu design system, e chegando a um que adota a metodologia multi-brand, é possível perceber uma redução incremental e considerável dos esforços de UI (design de interfaces) e desenvolvimento. Essa implementação possibilita uma forma de trabalho mais orientada à experiência do usuário e discovery, ao liberar recursos para estas atividades, que até então estavam sendo consumidos na design e implementação de interfaces.  Padronização  Um design system detalhado e bem especificado torna-se uma fonte única da verdade. Quando compartilhado dentro da organização, além de facilitar muito o trabalho das equipes, viabiliza uma padronização consistente, evitando a necessidade das mesmas discussões, descobertas e definições, que passam a estar prontas para serem reusadas como resultado  do desenvolvimento constante de um design system.  Fácil personalização  Segundo especialistas, a principal característica de um sistema de design multi marcas é a flexibilidade. Neste contexto, tornar personalizável significa permitir que cada produto possa aplicar suas decisões de design visual. Para que isto seja possível, criam-se bibliotecas de design tokens. Elas que podem ser facilmente duplicadas e personalizadas, gerando padrões visuais distintos para cada marca e produto.   Design tokens podem ser interpretados como variáveis que carregam atributos de estilo, como por exemplo uma cor da marca, que aplicada como token, permite que, ao trocar-se o valor carregado pela variável, reflita a mudança em todos os lugares onde a cor é apresentada na interface.   No exemplo acima, temos especificações de cores de marca para três diferentes design systems, sendo que na coluna da esquerda temos o token, que permanecerá o mesmo em todos os produtos. Já o valor carregado pela variável é diferente em cada um dos casos. Essas definições se aplicam a qualquer outro atributo visual, como tipografia, espaçamentos, bordas, sombreamento e até animações.    Estrutura de design systems multi-marcas  Segundo Brad Frost, um dos mais influentes consultores de design systems da atualidade e autor do livro Atomic Design, recomenda-se que design systems multi-marcas possuam três camadas:  Estrutura de três níveis de um design system. (Fonte: Brad Frost)  Tech-agnostic (1ª camada)  O nível agnóstico de um design system é a base para os demais, por isso, ele contempla apenas os códigos html, css e java script, com o intuito de renderizar componentes no navegador. Essa camada é importantíssima a longo prazo, já que permite o reaproveitamento futuro de um design system. Por exemplo, no cenário atual, pode-se dizer que a linguagem mais popular é o React. Porém, nem sempre foi assim e não se sabe qual será a próxima tecnologia a se destacar. Por esse motivo, é importante haver uma camada base, que tenha sua aplicação possibilitada em novas tecnologias, sem que seja necessário iniciar um novo design system a partir do zero.  Nessa primeira camada, designers e desenvolvedores constroem os componentes do design system em um ambiente de oficina, documentados em alguma ferramenta como Figma e Zeroheight. O resultado desse trabalho são componentes renderizados no navegador, tendo em vista que o framework adotado hoje pode não ser o mesmo adotado no futuro.  Tech-specific (2ª camada)  O nível específico de tecnologia é onde já existe uma dependência com alguma tecnologia e/ou plataforma e, além disso, encontra-se a oportunidade de gerar uma camada de design system para todos os produtos que usam a mesma tecnologia. Um bom exemplo desse tipo de design system é o Bayon DS, que atende aos produtos SAJ. Também é possível utilizá-lo para para desenvolver qualquer outro produto que use a tecnologia React.  Prod-specific (3ª camada)  A terceira camada é onde tudo se torna muito específico e todo o esforço é feito para um determinado produto. Nesse nível, podem ser criadas documentações referentes a padrões bem singulares e que se aplicam apenas àquele determinado contexto. Seguindo o conceito de Atomic Design, nessa camada são criados os componentes de maior complexidade e menor flexibilidade, como páginas e templates, a fim de gerar padrões de produto.  Na terceira camada, aplicações individuais consomem a versão específica da tecnologia selecionada, via gerenciadores de pacotes como npm e yarn.  Como estamos colocando em prática esses novos conceitos  Há alguns meses, após a divulgação da iniciativa Inner Source, começamos a estudar uma forma de transformar o Bayon, para que pudesse "receber" esse novo conceito. Pessoalmente, iniciei uma pesquisa aprofundada sobre os temas discutidos neste artigo. Além disso, meus gestores me proporcionaram a oportunidade de participar de um bootcamp avançado sobre design systems, que me trouxe muito aprendizado.  Em paralelo à pesquisa, reunimos alguns profissionais com conhecimento sobre o Bayon, representados por colegas dos times de arquitetura e design de produto das verticais JUS, para debatermos as possibilidades de atuação para converter o nosso design system para os padrões mais recentes.  Juntos, diagnosticamos qual a forma mais correta para criação e aplicação de uma biblioteca de design tokens, permitindo-nos remover nosso atual framework, o Material UI, para que, em seu lugar, haja a implementação do novo design system agnóstico da Softplan.  Web components e Stencil  Através de encontros recorrentes com representantes das empresas do Grupo Softplan, discute-se a possibilidade de desenvolvermos uma biblioteca de web components. Nela, aplica-se cada atributo visual ou decisão de design através de design tokens, permitindo uma completa personalização que garante que cada componente apresentará as características visuais do produto correspondente.   Web components são um conjunto de APIs que permitem a criação de tags HTML personalizadas, reutilizáveis e encapsuladas para uso em páginas e aplicativos Web. Possuem muitas vantagens, como compatibilidade com aplicações que usam ou não frameworks, compatibilidade com todos os principais navegadores e disponibilidade de bibliotecas open source que reduzem o custo da operação.   Somando a esta tecnologia, utiliza-se também o Stencil.js, um compilador open source que compartilha conceitos encontrados nos frameworks mais populares e que simplifica ainda mais o desenvolvimento de componentes, bem como a aprendizagem por parte de desenvolvedores.  Referências  Multibrand Design System within the Volkswagen group & its brands  Design tokens — What are they & how will they help you?  Design Systems Should be JavaScript Framework Agnostic  Creating multi-brand design systems  Managing technology-agnostic design systems  Salesforce Lighning DS  Managing technology-agnostic design systems  Multibrand Design System within the Volkswagen group & its brands (Vídeo)  In the file: Creating multi-brand design systems (Vídeo)  Atomic Design by Brad Frost—An Event Apart Austin 2015  Webcomponents.org  MDN Web Docs  Stenciljs  Criando Web Components com StencilJS (Youtube)  Construindo web components com Stencil JS

Softplan é reconhecida pelo Prêmio Top de Marketing e Vendas com Construsummit 2023

SALA DE IMPRENSA

Softplan é reconhecida pelo Prêmio Top de Marketing e Vendas com Construsummit 2023

A Softplan foi reconhecida com o Prêmio Top de Marketing e Vendas, na categoria “Tecnologia”, pelo case do Construsummit 2023 – o maior evento de gestão e tecnologia voltado para a indústria da construção realizado no mês de setembro, em Florianópolis. Organizada pela Associação dos Dirigentes de Vendas e Marketing do Brasil (ADVB/SC), a premiação reconhece empresas catarinenses por cases e estratégias de marketing inovadoras com positivos resultados em vendas. Neste ano, a 37ª edição do prêmio contou com 16 projetos vencedores, distribuídos nas categorias varejo, tecnologia, serviços, comunicação, indústria e micro e pequenas empresas (MPE). “É muito gratificante receber esse reconhecimento de uma entidade como a ADVB/SC, pois o Construsummit é um evento elaborado por todos os colaboradores da Softplan e ter isso como um de nossos resultados demonstra o tamanho de nosso empenho e do nosso impacto para a indústria da construção”, diz Ionan Diretor Executivo da Softplan para a Indústria da Construção. Realizado pelas soluções Sienge, Construmarket, CV CRM, Prevision, Refera, Collabo e eCustos, a quinta edição do Construsummit contou com cerca de 1.500 pessoas de todas as regiões do Brasil, incluindo 700 C-Levels, além de gestores e representantes das principais entidades do setor. “Em dois dias de evento, promovemos a maior rede de networking entre agentes da construção civil já realizada, resultando em mais de 2,2 mil potenciais oportunidades de novos negócios entre empresas do grupo e integrantes do ecossistema”, destaca o executivo. A Softplan anunciou que próxima edição do evento já está confirmada para setembro de 2024, com a expectativa de receber 2 mil participantes. Para acompanhar mais detalhes sobre o Construsummit 2024, acesse o site oficial.

André Tavares, novo CFO da Softplan, deve preparar a empresa para a entrada no mercado de capitais

SALA DE IMPRENSA

André Tavares, novo CFO da Softplan, deve preparar a empresa para a entrada no mercado de capitais

André Tavares de Andrade acumula uma experiência de mais de 15 anos na área e, antes de assumir o novo posto, como novo Chief Financial Officer (CFO) da companhia, era vice-presidente financeiro da Anima Educação, liderando as áreas de tesouraria, controladoria e relações com investidores. Um dos fatores que atraíram o novo CFO para o Grupo Softplan foi o projeto de crescimento e transformação, com forte protagonismo no setor de tecnologia na América Latina. “É uma empresa sólida, longeva e de elevada reputação que busca dar um novo salto em termos de crescimento e de evolução contínua em governança, aliada à visão dos fundadores de perpetuação da companhia e de incansável inovação”, destacou o executivo. Veja a reportagem completa no Pipeline aqui.

Seja softplayer

Trabalhe em uma das maiores empresas de desenvolvimento de software no Brasil, que valoriza sua equipe com parceria e autonomia.

Imagem seja softplayer
Conheça o portal Visão Softplan, nosso novo hub de conteúdos sobre negócios e tecnologia! Clique aqui