Temas dessa edição
Nuvem: mais é menos?
À medida que os maiores provedores de nuvem alcançaram quase a igualdade em sua funcionalidade central, o foco competitivo mudou para os serviços extras que podem fornecer, encorajando-os a lançar novas ofertas em uma velocidade vertiginosa. Em sua urgência para competir, lançam novos serviços com pontas soltas e funcionalidades incompletas. A ênfase na velocidade e a proliferação de produtos, por meio tanto da aquisição como de serviços precipitadamente criados, muitas vezes resulta não só em bugs como também em documentação ruim, automatização difícil e integração incompleta entre as próprias partes dos fornecedores. Isso causa frustração para os times que tentam entregar software com a funcionalidade prometida pelo provedor de nuvem e se deparam com constantes obstáculos. As empresas escolhem fornecedores de nuvem por uma variedade de fatores e, muitas vezes, em um nível alto na organização. Nosso conselho para os times: não suponham que todos os serviços de seu provedor de nuvem designado sejam iguais em qualidade, testem suas capacidades principais e estejam abertos para opções alternativas de código aberto ou uma estratégia de polycloud, caso seus próprios trade-offs para comercialização justifiquem a sobrecarga operacional de gerenciá-los.
Protegendo a cadeia de suprimento de software
As organizações devem resistir a regras de governança supervalorizadas que precisam de inspeção e aprovação manuais demoradas. Em vez disso, proteção de dependência automatizada (Função de aptidão de desvio de dependência), segurança (Política de segurança como código) e outros mecanismos de governança (Custo de execução como função de aptidão de arquitetura) protegem as partes do software importantes, mas não urgentes. Esse tópico que trata de políticas, compliance e governança como código reapareceu muitas vezes em nossas conversas. Vemos uma evolução natural no ecossistema de desenvolvimento de software no que diz respeito à ampliação da automação: integração contínua com testes automatizados, entrega contínua, infraestrutura como código e, agora, governança automatizada. Construir automação em torno do custo com nuvem, gerenciamento de dependência, estruturas de arquitetura e outros processos manuais antigos mostram uma evolução natural; estamos aprendendo como podemos automatizar todos os aspectos importantes da entrega de software.
Interpretando a caixa preta do aprendizado de máquina
O aprendizado de máquina frequentemente parece descobrir soluções para os problemas que os humanos não conseguem, usando identificação de padrões, back propagation e outras técnicas bem conhecidas. Contudo, apesar de seu poder, muitos desses modelos são inerentemente obscuros, ou seja, seus resultados não podem ser explicados com inferência lógica. Isso é um problema na medida que humanos têm o direito de saber como uma decisão foi tomada ou quando há risco de introduzir vieses de preconceito, amostragem, algoritmos ou outros no modelo. Estamos vendo agora o surgimento de ferramentas como What-If e técnicas como o teste com viés ético que nos ajudam a encontrar as limitações e prever o resultado desses modelos. Embora essas melhoras em interpretação sejam um passo na direção certa, explicar redes neurais profundas ainda é um objetivo difícil de se alcançar. Por isso, cientistas de dados estão começando a considerar a explicabilidade como uma preocupação de primeira classe ao escolherem um modelo de aprendizado de máquina.
Desenvolvimento de software como um esporte de equipe
Desde o começo do nosso Technology Radar, advertimos sobre ferramentas e técnicas que isolam membros dos times de tecnologia uns dos outros, dificultando o feedback e a colaboração. Frequentemente, quando novas especializações aparecem, profissionais, fornecedores e ferramentas insistem que alguma parte do desenvolvimento deve ser feita em um ambiente isolado, longe do caos do ambiente “normal”. Rejeitamos essa afirmação e constantemente procuramos por novas maneiras de retomar o desenvolvimento de software como um esporte de equipe. O feedback é muito importante quando desenvolvemos coisas complexas como software. Embora projetos cada vez mais precisem de especialização, lutamos para encaixá-los em colaboração e feedback regulares. Particularmente, não gostamos do meme “10x engineers” e preferimos focar na criação e na viabilização do “equipes 10x”. Vemos isso atualmente influenciando a forma como design, ciência de dados e segurança podem ser integrados com times multifuncionais e apoiados em sólida automação. A próxima fronteira está trazendo mais atividades de governança e compliance para o jogo.
Artigos selecionados
Publicamos artigos relacionados ao Technology Radar ao longo do ano. Inscreva-se para continuar se informando.
Contribuições
Vol.21
O Technology Radar é preparado pelo Conselho Consultivo de Tecnologia da ThoughtWorks, composto por:
Downloads
Baixe edições anteriores