Você já ouviu falar no Usain Bolt, multicampeão olímpico e mundial, em corrida de 100 metros? E se eu te falar do Eliud Kipchoge, recordista de tempo em maratona (abaixo de 2 horas)? Bom, ambos são campeões mundiais, ídolos em suas categorias e o principal, ambos usam a corrida para ter todo esse curriculum, porém, […]
Você já ouviu falar no Usain Bolt, multicampeão olímpico e mundial, em corrida de 100 metros? E se eu te falar do Eliud Kipchoge, recordista de tempo em maratona (abaixo de 2 horas)? Bom, ambos são campeões mundiais, ídolos em suas categorias e o principal, ambos usam a corrida para ter todo esse curriculum, porém, um usa a corrida para ser fundista (corrida longa) e o outro usa a mesma para Sprint rápido (100 metros).
Quando falamos do universo de tecnologia, funciona exatamente assim, nem sempre a mesma “tecnologia e/ou metodologia” pode trazer o mesmo resultado e além, a mesma tecnologia pode apresentar resultados completamente diferentes. Vamos a um exemplo simples:
Imagine o desenvolvimento de um novo ERP, você sabe exatamente a quantidade de funcionários que vai utilizar esse sistema, que não terá grandes oscilações de acesso, dados, transações e, além disso, o uso vai ser especificamente para o financeiro, uma vez que, você está em um estágio de maturidade, e usa sistemas específicos para cada função/necessidade. Nesse cenário, é iminente a preocupação com uma arquitetura que gere integrações sem fricção ou com o desafio de desenvolver um sistema de alta escalabilidade e automação de testes para releases (novas funcionalidades) praticamente semanais?
Pois bem, no cenário descrito acima, concorda comigo que o ideal seria desenvolver um sistema de ERP e que esse fosse acoplado a uma arquitetura de Midleware a qual você consiga expor API’s, para receber informações tratadas pelos seus sistemas específicos e automaticamente alimentar o sistema de ERP para que ele possa processar as entradas e saídas financeiras. Nesse mesmo cenário, concorda que um sistema ERP estável não deveria sofrer alterações seguidas e se isso for uma verdade, você não tem a necessidade de investir em automação de testes e tampouco gerar uma esteira de releases?
Se você concordou com os argumentos acima, combinamos então, que nesse cenário, você não tem a necessidade de usar DevOps, Microsserviços, automação de testes e demais sopas de letrinhas que se tornaram a moda do momento. Automaticamente, você vai evitar alguns custos em seu projeto e com a exposição do seu time no uso de tecnologias que não são tão comuns de conhecimento até o momento no Mercado e automaticamente com menos mão de obra disponível e que por necessidade de Inovar por Inovar, podem causar “N” problemas nesse projeto e “queimar” uma excelente tecnologia, arquitetura e metodologia.
Logo, eu quis te mostrar, que muitas vezes optamos por algumas tecnologias apenas por serem a moda do momento. Mas, isso significa que não devemos utilizá-las, que não devemos nos preparar para utilizar e não devemos realizar mudanças? Não! Muito pelo contrário, é aqui que entra a jornada, aqui que entra a preparação, a capacitação e, principalmente, o momento certo, o projeto certo ao qual devemos utilizar. Veja:
Imagine o cenário no qual solicitam o desenvolvimento de um sistema para o usuário final (consumidor) e que não temos ideia de quantas features vão surgir na jornada do consumidor, não sabemos a quantidade de acessos que esse sistema vai ter e também a quantidade de informações que iremos transacionar no mesmo. Esse é um cenário volátil, inserto e obscuro, logo o ideal é lançar mão de uma arquitetura modular, escalável e ágil de implementações, alterações e substituições, concorda? Então aqui sim vale a pena falarmos de micro serviços, DevOps, automação de testes e também Midleware de integrações, pois quanto mais sistemas prontos pudermos acoplar, menos tempo iremos perder para reinventar a roda.
Nunca devemos ter medo da mudança e sim nos prepararmos para ela, cercados de pessoas que tenham experiência naquilo, que para nós é novo e tenha certeza que o novo para você, com certeza é o normal para alguém e o que for normal para você pode ser o novo para ele. Na jornada do “novo”, cerque-se de pessoas, times, parceiros, consultorias que tenham experiência até que você a detenha, até que para você seja normal, até que a Cultura do seu time sobre aquela nova metodologia e tecnologia seja tranquila e carregue o DNA do time, ou seja, você construiu uma jornada ao novo normal e agora está pronto para a próxima novidade.
Não vamos usar a tecnologia pela tecnologia, uma vez que você detém conhecimento do todo, você está apto a escolher e a empregar a melhor tecnologia, metodologia, etc. O momento e ao projeto certo, se estivermos falando de obscuridade e muitas features, tenho certeza da esteira de desenvolvimento e dos Microserviços, agora, se estivermos falando de sistemas não complexos e de alto conhecimento, não abra mão de ter arquitetura de integrações, porém não há necessidade das demais aqui listadas.
*Rafael Carrenho é Vice-Presidente de Inovação da Quality Nextech
