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

Segurança da informação refere-se ao conjunto de práticas, medidas e procedimentos adotados para proteger as informações e dados sensíveis de uma organização ou indivíduo contra ameaças, acessos não autorizados, perda, roubo, danos ou alterações indesejadas. O objetivo é garantir a confidencialidade, integridade e disponibilidade dos dados, bem como preservar sua autenticidade e evitar que caiam em mãos erradas.  A segurança da informação é essencial em um mundo altamente conectado e dependente de sistemas computacionais, redes e tecnologias digitais. Ela abrange várias áreas, incluindo:  Confidencialidade: Garantir que as informações estejam acessíveis apenas a pessoas autorizadas, impedindo o acesso não autorizado por meio de autenticação, criptografia e controle de acesso.  Integridade: Assegurar que os dados sejam precisos, completos e não sofram alterações não autorizadas durante o armazenamento, transmissão ou processamento.  Disponibilidade: Certificar-se de que as informações estejam disponíveis e acessíveis quando necessário, evitando interrupções causadas por falhas, ataques ou desastres.  Autenticidade: Garantir que as informações sejam atribuídas corretamente a seus autores e que a origem dos dados seja verificável.  Não repúdio: Garantir que o autor de uma ação não possa negar a autoria ou a realização de uma transação.  Gerenciamento de riscos: Identificar, analisar e mitigar ameaças e vulnerabilidades para proteger as informações de possíveis incidentes de segurança.  Impactos da ausência de segurança da informação A falta de segurança da informação pode ocasionar uma série de impactos negativos significativos para indivíduos, organizações e até mesmo para a sociedade como um todo. Alguns dos principais impactos incluem:  Roubo de dados: Hackers e criminosos cibernéticos podem invadir sistemas desprotegidos e roubar informações confidenciais, como dados pessoais, números de cartões de crédito, informações bancárias e outros dados sensíveis. Esse tipo de roubo pode levar a fraudes financeiras, roubo de identidade e extorsão.  Vazamento de informações: Vazamento de informações sensíveis, como segredos comerciais, propriedade intelectual ou informações governamentais confidenciais. Como resultado, esses vazamentos podem prejudicar a competitividade das empresas, a segurança nacional e a privacidade das pessoas.  Prejuízo à reputação: Quando uma organização sofre uma violação de segurança, sua reputação pode ser seriamente comprometida. A percepção pública da falta de cuidado com os dados dos clientes pode afetar negativamente a confiança de clientes e parceiros comerciais.  Interrupção dos negócios: Ataques cibernéticos, como ransomware ou negação de serviço (DDoS), podem deixar sistemas inoperantes e interromper as operações de empresas. Essa interrupção pode causar perda de produtividade, danos financeiros e frustração dos clientes.  Perda financeira: Como o custo de reparar sistemas comprometidos, pagar resgates de ransomware ou enfrentar litígios relacionados a violações de dados.  Violações regulatórias e legais: Em muitos países, existem leis e regulamentos que exigem proteção adequada dos dados dos clientes e das informações sensíveis. A falta de segurança pode levar a violações dessas leis, o que pode resultar em multas, penalidades e ações legais.  Espionagem e ciberguerra: Facilitar a espionagem cibernética e até mesmo ataques cibernéticos de larga escala entre países, prejudicando a segurança nacional e a estabilidade geopolítica.  Danos à confiança digital: Minar a confiança geral nas tecnologias digitais, o que pode desacelerar a adoção de novas tecnologias e prejudicar a economia digital.  Medidas de Segurança Para mitigar tais impactos, é fundamental que indivíduos e organizações invistam em medidas de segurança da informação, como criptografia, autenticação forte, treinamento em conscientização de segurança, atualizações regulares de software e auditorias de segurança. Além disso, é essencial que governos e setores industriais trabalhem em conjunto para desenvolver políticas e padrões de segurança cibernética mais robustos.  Alguns elementos comuns para garantir a segurança da informação incluem firewalls, sistemas de detecção e prevenção de intrusões (IDS/IPS), antivírus, criptografia, backups regulares, políticas de senha fortes, treinamento de conscientização de segurança e monitoramento de atividades suspeitas.  É dever de cada um de nós zelar pela segurança da informação, reconhecendo a importância de uma postura vigilante em nossas ações cotidianas. A responsabilidade não recai apenas sobre especialistas em tecnologia ou departamentos específicos, mas sim sobre cada indivíduo. Por isso, desconfiar, verificar e validar as informações recebidas é uma prática fundamental para evitar cair em armadilhas de engenharia social. Afinal, essa forma de ataque cibernético pode se originar de fontes inesperadas e aparentemente confiáveis. Somente ao assumirmos o papel de nosso próprio aliado na segurança digital, poderemos construir uma base sólida para proteger nossa privacidade, dados pessoais e informações sensíveis. Ao fortalecermos nossa consciência e a adoção de medidas preventivas, podemos contribuir significativamente para um ambiente online mais seguro e confiável para todos.  É importante ter atenção com ferramentas de inteligência artificial como Chat GPT ou Google Bard. Jamais coloque e-mail corporativo para acessar essas ferramentas, pois pode representar um risco significativo para a segurança de informações sensíveis da empresa em que você trabalha. Ao utilizar essas plataformas, opte sempre por utilizar um e-mail pessoal. Além disso, é essencial estar ciente das políticas de privacidade e segurança das ferramentas de inteligência artificial utilizadas.  Conclusão A segurança da informação é fundamental para proteger dados pessoais, informações financeiras, segredos comerciais, propriedade intelectual e outros ativos valiosos de indivíduos e organizações, especialmente em um cenário onde a ameaça de ciberataques e violações de dados é cada vez mais constante. 

Olá a todos, me chamo Douglas Dourado e este é meu primeiro artigo no Tech Writers. Abordarei os meus aprendizados na carreira como Business Analyst (ou Analista de Negócios). Para poder elucidar esse assunto, primeiramente preciso voltar um pouco no tempo. Ingressei na empresa Softplan em maio de 2013 para participar do Projeto Puma do nosso cliente Tribunal de Justiça do Estado de São Paulo (TJSP), mais especificamente para os processos digitais de Segunda Instância. Esse projeto foi de suma importância para nosso cliente pois, com ele, os processos que eram morosos foram otimizados dia a dia tanto para os serventuários quanto para todas as outras pessoas envolvidas naquele período. Comecei minha carreira como Analista de Sistemas e, nesse tempo, com a ajuda de várias pessoas envolvidas no meu ciclo profissional, consegui absorver muitas coisas até chegar aonde estou hoje, atuando como Business Analyst. Este artigo irá trazer algumas dicas de quem já percorreu o caminho e será interessante para quem busca seguir carreira na área de produto. Em todos esses anos, destaco 3 importantes habilidades que aprendi e que considero pilares importantes para quem quer trilhar essa carreira. São elas: Resiliência, Comunicação entre Equipes e Sinergia com o cliente. Habilidades essenciais para um Business Analyst Resiliência De acordo com o dicionário virtual, o termo Resiliência pode ser definido resumidamente como: a capacidade de enfrentar e superar adversidades. Ao longo da sua carreira algumas adversidades podem aparecer, mas a resiliência nos ajuda a percorrer os acontecimentos, aprender com eles e ter mais tranquilidade e confiança para conduzir os próximos passos. Portanto, aprenda a recalcular a rota, reorganizar e seguir em frente. Comunicação entre equipes A comunicação entre as equipes é algo também muito importante. Isso porque, para estarmos em um nível de segurança, dependemos de outras equipes e pessoas. Como diria o saudoso Chacrinha: “Quem não se comunica, se trumbica”. Em alguns momentos nesse cargo você vai precisar encaminhar demandas, negociar e conduzir reuniões com clientes e equipe. Aprenda técnicas de comunicação assertiva, storytelling, busque ser claro e objetivo, adequando sua comunicação para cada ouvinte, se o seu cliente for formal, adeque-se. Caso o ambiente exija mais termos técnicos, utilize-os ou até mesmo o contrário: aprenda a explicar cenários complexos com palavras e exemplos simples. Mas, lembre-se que o primeiro passo para uma boa comunicação é saber ouvir e entender a necessidade do outro. Sinergia com o cliente Existe diversos formatos e fluxos de trabalho dentro do cargo de Business Analyst, inclusive aqui dentro da Softplan. No projeto em que ingressei, o Analista de Negócio tem contato direto com o cliente em alguns momentos, para, por exemplo, mapear requisitos e necessidades. Caso esse for seu caso, busque seguir essas dicas: eu sempre me atentava em absorver o máximo de informação possível do que os usuários tinham a dizer para conseguir analisar o cenário. Foco no seu cliente, entender a necessidade dele, fazer perguntas adequadas e estar com uma visão dinâmica é essencial. Não saia de uma reunião com dúvida, tenha clareza sobre o que você precisa entregar para aquele cliente, isso é essencial para uma entrega de qualidade. Quer seguir a carreira de Business Analyst? Portanto, para você que quer seguir carreira na área de Business Analyst busque desenvolver habilidades de resiliência, comunicação e foco no cliente. Essas habilidades são pilares essenciais que eu aprendi ao longo da minha carreira e utilizo diariamente. E para você que quer trabalhar conosco na Softplan, não deixe de conferir nossas vagas!

No que se refere a disciplina de arquitetura no desenvolvimento de software, nos deparamos com vários tipos de arquitetura. Cada qual, com suas características e especificidades.  Nesse artigo iremos abordar três tipos de arquitetura, são elas: Arquitetura de Software, Arquitetura de Soluções e Arquitetura Corporativa. Apesar de serem arquiteturas diferentes e terem funções específicas em algum momento durante o desenvolvimento elas acabam fazendo interface entre si.  Arquitetura de Software  Essa arquitetura é a que está mais próxima do código e do desenvolvedor. Concentra-se na organização interna de um sistema e aborda a divisão do sistema em componentes, como: classes, módulos ou serviços. Também define qual será a interação entre eles, sendo responsável por aspectos como a modularidade, escalabilidade, segurança e reutilização de código.  Algumas das definições dessa arquitetura:  • Qual a linguagem de programação será adotada; Por exemplo: Java ou .NET C#.  • Quais frameworks e bibliotecas usar na solução;Por exemplo, caso opte pela linguagem de programação Java, utilizar o Spring Boot Framework para facilitar e agilizar o desenvolvimento de aplicativos web e de microsserviços.  • Qual a forma de acesso a camada de dados, e de que maneira ocorrerá a persistência, se por algum framework de Mapeamento Objeto-Relacional ou manualmente. Caso opte por um ORM definir qual será a ferramenta utilizada; Por exemplo: Hibernate ou EclipseLink.  • Qual o modelo arquitetural será usado na implementação e os padrões arquiteturais adequados que atendam aos requisitos do sistema. Por exemplo: MVC, Arquitetura em Camadas, Cliente-Servidor, Hexagonal ou Orientada a Serviços.  • Qual a forma de comunicação entre os componentes do sistema; Por exemplo: HTTP, REST ou Mensageria Assíncrona.  • De que forma se dará a escalabilidade e como o sistema será dimensionado para lidar com aumentos de carga e demanda; Por exemplo: Balanceamento de Carga, Escalonamento Horizontal/Vertical ou Particionamento de Dados.  Qual seguir? Esses tópicos listaram alguns exemplos de decisões arquiteturais que podem ser tomadas durante o processo de definição de uma arquitetura de software. Para essas definições não existe a resposta certa ou errada. Apenas a que melhor se encaixa para atender uma necessidade dentro de um contexto do negócio. Essas decisões são muito importantes e devem ser tomadas com bastante embasamento e cautela, pois mudá-las mais tarde afetará toda a estrutura do sistema, ocasionando custos e atrasos indesejados no projeto. Por isso, é indicado a realização de Provas de Conceitos (POC's) para que as decisões tomadas sejam as mais assertivas possíveis e que garantam um sistema robusto, escalável e de alta qualidade.  É importante que o arquiteto de software tenha um bom conhecimento técnico e com base em suas experiências tome a melhor decisão para que o desenvolvimento seja fluido e cadenciado. Além do mais, o arquiteto deve estar preparado para agir em momentos de crise. Muitas vezes, ele poderá ser demandado para identificar problemas específicos e de complexidade elevada, como por exemplo debugar uma biblioteca ou framework para tomar uma decisão importante e corrigir um problema em produção, fazendo com que a operação volte a funcionar normalmente.  Arquitetura de Soluções  A Arquitetura de Soluções está em uma camada superior em relação a Arquitetura de Software, e é responsável por transformar o requisito do negócio em componentes de engenharia que irão atuar em conjunto para resolver o problema e atender as necessidades do negócio. Abrange a definição dos sistemas envolvidos, a integração entre eles, as interfaces de comunicação e as estratégias para garantir que a solução como um todo funcione de maneira eficaz e atinja seus objetivos. Esse tipo de arquitetura é ideal para identificar áreas dentro de uma organização onde pode haver uma redução de custos, melhorar seu desempenho e automatizar os processos de modo a tornarem mais eficientes, otimizados e padronizados.  A principal diferença entre Arquitetura de Software e Arquitetura de Soluções é que a primeira trata apenas de questões relacionadas a engenharia, enquanto a segunda é responsável por garantir que um produto de software resolva um problema de negócio específico dentro da estratégia de uma empresa. Atividades que estão associadas a esta disciplina: • Compreender e analisar os requisitos do negócio e do sistema para identificar as necessidades e os objetivos da solução; Por exemplo: Entrevistas/workshops, estudos de viabilidade e criação de diagramas de contexto.  • Criar e liderar os processos de integração entre sistemas para atender os requisitos de negócio; Por exemplo: Definição de interfaces, serviços web (API's REST) e Middleware de integração (Kafka).  • Identificar e definir as medidas de segurança necessárias para proteger a solução contra ameaças; Por exemplo: Autenticação, Autorização, Criptografia e proteção de dados sensíveis.   • Colaborar com stakeholders (desenvolvedores, analistas de negócios e gerentes de projeto), para garantir a compreensão e a adoção da arquitetura de soluções; Por exemplo: Comunicação clara das decisões arquiteturais, realização de revisões técnicas e a obtenção de feedback dos envolvidos.  • Identificar os riscos associados à solução e desenvolver estratégia para mitigá-los; Por exemplo: Análise de riscos técnicos, operacionais e segurança.  • Considerar os requisitos de desempenho, como tempo de resposta e capacidade de processamento, e também a capacidade de escalar a aplicação para lidar com picos de aumento de carga; Por exemplo: Uso de caches, escalonamento horizontal, arquitetura de microsserviços ou serviços de mensageria.  Vínculo forte Podemos concluir que a arquitetura de soluções está na divisão entre o técnico e o negócio, e que há um vínculo forte entre essas duas vertentes, considerando a importância de que a solução técnica está sendo definida para resolver um problema de negócio. As habilidades de comunicação na arquitetura de soluções são imprescindíveis, pois há frequentemente um contato direto com a área de negócio, que normalmente tem o conhecimento técnico muito pequeno ou inexistente, com isso, cabe ao papel do arquiteto de soluções ser capaz de explicar e traduzir de forma simples toda a solução técnica que será construída, de uma forma abstrata o suficiente para que todos entendam. Algo importante a se considerar é o conhecimento necessário para representar a arquitetura através de diagramas, como por exemplo o C4, e que ele possa representar de forma clara os componentes do software, a interface com outros sistemas, o fluxo de dados e demais informações que forem pertinentes tanto para a engenharia quanto para o negócio.  Arquitetura Corporativa Define-se arquitetura corporativa como uma série de conhecimentos técnicos e habilidades de gestão que integram a tecnologia aos objetivos do negócio, é uma visão mais ampla que abrange a arquitetura de todo o ambiente de tecnologia da informação da organização. Determina os princípios, políticas e os padrões de governança que orientam a estruturação dos sistemas de software e infraestrutura de uma empresa, se concentrando em como os diferentes sistemas e soluções se encaixam dentro do contexto organizacional, garantindo a consistência, a integração e a eficiência dos recursos de TI.A arquitetura corporativa também considera fatores estratégicos e de negócios, alinhando a tecnologia da informação com os objetivos e necessidades da organização. Ela pode incluir a definição de modelos de processos de negócios, a gestão do portifólio de sistemas, a governança de TI e a definição de políticas de segurança da informação.  Decisões tomadas dentro desse tipo de arquitetura:  • Padronização de linguagem de programação e frameworks utilizados nas soluções dentro da empresa, delimitando quais tecnologias estarão habilitadas para serem utilizadas; Por exemplo: Utilizar a stack Java com Spring Boot Framework em soluções de API.  • Padronização de bases de dados; Por exemplo: SQLServer e Oracle.  • Processos de controle de mudança para auditoria de publicações em ambiente produtivo; Por exemplo: Controle de acesso e permissões, revisão e aprovação de alterações. • Definir e documentar um modelo de arquitetura que a organização irá trabalhar; Por exemplo: Criar um diagrama que ilustre as principais camadas da arquitetura, abrangendo as camadas de apresentação, negócio e dados.  • Avaliar a implantação de novas tecnologias; Por exemplo: Realização de Provas de Conceito (POC's) e pesquisas de mercado.  • Implementar soluções corporativas de DevOps; Por exemplo: Automação de compilação e empacotamento utilizando o Jenkins como esteira de CI/CD.  Importância da arquitetura corporativa Ter uma arquitetura corporativa é muito importante, pois define padrões que a empresa toda deve adotar e seguir, e ajuda a alinhar os objetivos estratégicos da organização com suas atividades operacionais, auxiliando na identificação de redundâncias, ineficiências e oportunidades de otimização, permitindo a simplificação, consolidação e racionalização dos recursos resultando em maior eficiência operacional e redução de custos. A arquitetura corporativa auxilia na gestão do ciclo de vida dos sistemas de TI, desde o planejamento estratégico, estabelecendo padrões de qualidade, governança e conformidade para o desenvolvimento, implantação, operação e manutenção dos sistemas garantindo uma gestão efetiva e sustentável dos ativos de TI.  Conclusão Nesse artigo, abordamos os três principais tipos de arquitetura existentes no desenvolvimento de software, os detalhes de cada tipo e como eles se relacionam entre si. Essa divisão é importante para que cada arquitetura foque em uma área específica de modo que as três juntas possam abranger todo o ciclo de desenvolvimento de um software. Como vimos a arquitetura de software está mais próxima ao código e ao desenvolvedor, a arquitetura de soluções mais voltada ao negócio que a solução pretende resolver e a arquitetura corporativa para definir os padrões tecnológicos que a organização deve adotar para as soluções de software implementadas. A aplicação desses tipos de arquitetura varia de acordo com o tamanho da organização, quanto maior, mais separado e específico os tipos de arquitetura, e quanto menor, menos separação entre os tipos de arquitetura, e muitas das vezes se fundindo em apenas um tipo. É importante salientar que, para cada tipo de arquitetura, pode-se executar um papel diferente por parte do arquiteto, e cada qual com suas habilidades específicas para cada área, porém as habilidades de comunicação, senso crítico, proatividade e resiliência são comuns para todos os tipos de arquitetura. Referências https://blog.xpeducacao.com.br/o-que-e-arquitetura-de-software https://www.infoq.com/br/articles/papel-arquiteto-solucao

Aqui no time de suporte da Projuris, quando recebemos um ticket (também conhecido por muitos como chamado), analisamos cuidadosamente qual é a demanda do cliente e o qual o seu impacto na operação.   Já dizia o ditado: “a vida imita a arte”. Por isso, posso dizer que nossa vida tem muita relação com um ticket de suporte. Podemos até dividir nas mesmas etapas de análise para resolver um problema. Serviço, categoria e urgência.  Em relação a análise do serviço, podemos comparar com a vida ao separar em áreas todos os pontos da vida, sejam eles na área pessoal, profissional ou espiritual. Ou seja, buscar, de forma ampla, não só a sua a identificação, mas também, a sua melhor forma de atuação.  Logo depois do serviço, chegamos na categoria, que podemos relacionar como se fosse a dúvida, problema ou tarefa. Esta questão é importante para analisarmos as atitudes para contornar este problema. Os problemas, que são parte da vida dos seres humanos, podem ser confundidos com a dúvida. Mas, há diferença: enquanto as dúvidas se referem ao desconhecimento ou falta de interpretação sobre algo, os problemas não seguem o mesmo fluxo.   Os problemas são apontamentos em que deveriam seguir assim, mas não são. Por exemplo: Todas as demandas em que não temos respostas, ao menos no primeiro momento, são consideradas problemas, podendo haver soluções no momento ou no futuro.  Se os problemas se referem a como fazer, não é um problema, mas sim, uma dúvida.  O último item, na minha opinião é o mais simples. São as tarefas, que são operações sobre determinado ponto.   E quando falamos sobre urgência, classificamos em: blocante, urgente, alta, média e baixa.  Blocante é categoria na qual paralisa toda a operação e todos os usuários da organização. Sob a ótica da vida, a categoria blocante é algo que deve ser resolvido imediatamente.  A urgente se assemelha com a blocante, entretanto, não paralisa toda a operação. Pode ser resolvida com mais calma.  As categorias alta, média e baixa são problemas em que se devemos analisar quais serão os impactos no cotidiano.  As urgências ajudam a entender as demandas prioritárias. Até porque, quanto mais grave, maior o seu impacto.  Ticket de suporte ou da vida? Agora eu te pergunto: quem é o especialista por trás deste ticket da vida? Isso mesmo, sou eu, você, nós. Por isso, ser especialista nas suas próprias “demandas” (o que também podemos chamar de autoconhecimento) é um elemento essencial para compreender as questões que lhe afligem. E quanto mais você se organiza, classifica seus problemas e os prioriza, melhor você os resolverá, tornando sua vida mais tranquila. 

Se você atua com projetos de software e já teve a necessidade de tratar objetos individuais e coleções de objetos de forma uniforme, o padrão de projeto Composite vai te ajudar. Descubra a seguir como o padrão Composite auxilia na criação de interfaces de usuário mais intuitivas e no processamento de árvores de objetos de forma eficiente. Neste artigo, convidamos você a explorar os benefícios desse padrão, que simplifica estruturas hierárquicas e oferece maior flexibilidade na manipulação de elementos. Confira abaixo o que é o Composite, quais suas vantagens e desvantagens e veja um exemplo prático da sua implementação. O que é o Composite? O Composite é um padrão de projeto estrutural que permite tratar de maneira uniforme os objetos individuais e composições de objetos, formando uma estrutura hierárquica. Ele é o quarto padrão desta categoria apresentado pela "Gang of Four" (GoF). Como os próprios autores colocam, a intenção oficial deste padrão é “compor objetos em estruturas de árvore para representar hierarquias partes-todo". Com o Composite, um objeto individual e um grupo de objetos são tratados da mesma maneira, pois ambos implementam uma interface comum. Como funciona o padrão de projeto Composite? Dentro do padrão Composite, encontramos uma classe abstrata conhecida como "Componente", que estabelece uma interface compartilhada para objetos individuais e grupos de objetos. Os objetos individuais são representados por uma classe concreta que implementa o Componente, enquanto os grupos de objetos são representados por uma classe composta que também implementa o Componente. A estrutura hierárquica é criada através da composição, na qual um grupo de objetos pode incluir outros objetos individuais ou grupos de objetos. Essa estrutura permite a realização de interações recursivas, e dessa forma possibilita a aplicação de operações a todos os objetos na hierarquia. O padrão Composite é ideal para quando há a necessidade de tratar objetos individuais e coleções de objetos de forma homogênea, simplificando o código e conferindo maior flexibilidade. Seu uso é comum em interfaces de usuário, processamento de árvores e outras estruturas hierárquicas. Como é a implementação do Composite? Para entender melhor a implementação do Composite, vamos analisar o exemplo a seguir: Em um supermercado, você possui duas formas de comprar um refrigerante: É possível comprar a unidade Ou comprar um fardo com 12 unidades Aqui, nós temos um Composite: a noção de que o fardo (estrutura) se comporta como um produto, e que ele pode dizer seu preço delegando o seu valor, somando assim os custos das unidades filhas e utilizando como seu próprio. Claro, o cenário acima só faz sentido se o fardo não possuir um valor fixo, e sim que seu valor se resume no total de unidades que há dentro do mesmo. Vejamos um código do cenário descrito (no caso, utilizando Java para exemplificar): No exemplo acima, definimos uma interface Produto, que será implementada tanto pela unidade de “refrigerante”, quanto pelo fardo. O método em comum que será implementado por eles, no nosso caso, é o getValor(). O refrigerante, por sua vez, possui o valor e um nome. A implementação do getValor(), por ser uma única unidade, apenas retorna o seu próprio valor. Acima temos o fardo de refrigerantes, atuando como Composite, seu “valor” é delegado para as unidades que há dentro dele. Ou seja, se houver 5 unidades de refrigerante, cada uma com um valor “5”, o valor do fardo será de 25. O interessante neste design pattern é que a complexidade desse tipo de estrutura não acaba por aí. Como a classe FardoDeRefrigerante possui uma lista dentro de si do tipo Produto, ela é capaz de suportar até mesmo outros fardos dentro de si mesma. Exemplo da Estrutura de um Composite Apesar de o “fardo de refrigerante” não ser o melhor exemplo nesse caso, podemos imaginar uma caixa dentro de outra caixa, e cada uma delas com produtos de diferentes valores dentro de si, as caixas internas totalizaram o valor dos produtos internos, e a caixa externa totalizaria o valor das caixas internas, parecendo muito com a estrutura abaixo: Exemplo de como a estrutura de um composite pode ficar. Fonte: “Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos” Normalmente utiliza-se o padrão de projeto Composite, por exemplo, para rodar uma bateria de validações em cima de um objeto. Enquanto o Decorator serve para estender funcionalidades dentro de uma classe já existente, sem alterar a classe original e preservando os princípios SOLID. A forma de implementação pode variar bastante dependendo de como que você utiliza, mas o importante é conhecer o padrão e saber quando encaixá-lo no seu sistema. Não siga à risca os diagramas propostos pela GoF, ou os exemplos citados, adeque-os de acordo com suas necessidades e situações. Quando usar o padrão de projeto Composite? Aplica-se o padrão de projeto Composite nas situações em que há uma estrutura hierárquica de objetos e quando se deseja tratar objetos individuais e grupos de objetos de forma uniforme, simplificando o código e fornecendo maior flexibilidade. Aqui estão algumas situações de exemplo do uso do padrão Composite: Estruturas Hierárquicas:  O padrão Composite é ideal para lidar com estruturas hierárquicas, como árvores ou grafos, onde os nós podem ser objetos individuais ou grupos de objetos. Modelagem de Interface de Usuário:  É comum utilizar o padrão Composite na construção de interfaces de usuário, especialmente quando há elementos que podem conter outros elementos, como menus, botões e painéis. Processamento de Documentos: O Composite pode ser útil para tratar elementos como documentos com seções, parágrafos, listas, etc, de forma uniforme. Manipulação de Gráficos: Se você precisa lidar com elementos gráficos, como formas, linhas e grupos de formas, o Composite permite tratá-los de maneira uniforme e facilita a aplicação de operações a todos os elementos. Implementação de Estruturas de Dados: Também é possível aplicar o Composite na implementação de estruturas de dados como arrays, listas e matrizes, em que tratam-se os elementos individuais e os grupos de elementos de forma semelhante. Quais os prós e contras de usar o Composite? Confira os principais prós e contras do Composite: PrósContrasSimplifica a estrutura hierárquicaPode ter impacto na eficiência em estruturas muito grandesOferece flexibilidade na manipulação de objetos e operações recursivasPode exigir maior esforço de design e implementação inicialPromove reuso do códigoRequer uma interface comum bem definida No entanto, é importante lembrar que os prós e contras do Composite podem variar dependendo do contexto e dos requisitos específicos do projeto. Portanto, é essencial considerar cuidadosamente esses aspectos antes de decidir utilizar o design pattern Composite. E você já sabia como implementar o Composite? Aproveite e confira outros conteúdos de tecnologia no Tech Writers.