Tecnologia e Estratégia de Negócios
Os cargos conhecidos como “C-Level”, ou da “Diretoria” em português, são todos estratégicos. Esta é a liderança que conduz a empresa aos seus objetivos de negócios. Até aqui nenhuma novidade. Porém, quando falamos de “startups”, as empresas inovadoras que nascem baseadas nas novas tecnologias disruptivas, o papel de um dos executivos do “C-Level” torna-se muito mais estratégico.
Este é o caso do “CTO”, o “Chief Technology Officer”. Muitos executivos do setor têm experiencia em gestão de equipes técnicas, mas não tem mais as habilidades técnicas de buscar novas tecnologias ou pesquisar uma nova arquitetura. Outros jovens promissores, conhecem várias tecnologias, tem habilidades em buscar novas ferramentas, mas não tem experiência na gestão de equipes e menos ainda visão de negócios.
E para as empresas startups, que buscam investimentos o custo de contratar um profissional especializado também se torna um “desafio”.
Como sair desse impasse?
Na minha carreira, tive a oportunidade de trabalhar em grandes empresas de tecnologia e grandes bancos de varejo, desenvolvendo soluções de negócios para grandes empresas no Brasil, Estados Unidos, Canadá e diversos países da América Latina. Nessas andanças pelo mundo aprendi não só extrair o melhor das diversas tecnologias para expandir negócios como também as características de diferentes mercados.
Desse aprendizado posso trazer as seguintes dicas para quem está vivendo esse impasse:
· Avaliar a situação atual da sua empresa ou projeto de empresa com muita clareza. Ou seja, ver onde você está, o que você tem hoje em termos de condições de investimento, equipe, infraestrutura e onde você quer chegar;
· Busque um Hub de Inovação, mentoria. Existem várias universidades e empresas que oferecem este tipo de serviço até gratuitamente;
· Ao invés de contratar um recurso fixo, contrate um prestador de serviços;
O que isso pode mudar na sua empresa?
Tenho atuado em vários projetos de empresas médias e startups nos últimos anos e poderia listar vários casos de sucesso aqui, mas vou exemplificar com um caso em que pude contribuir com a arquitetura de uma plataforma de dados que migrou do ambiente monolítico (Datawarehourse tradicional com bancos de dados relacionais) para o ambiente de nuvem (Cloud Services) com disponibilização de dados em tempo real (Microserviços).
No caso que comento, tratava-se de uma Fintech que havia recebido um aporte para expansão dos negócios. Eles tinham uma plataforma simples, mas que gerou interesse dos investidores, só que para escalar a operação e conseguir atingir as metas de expansão que os investidores esperavam precisava ter uma infraestrutura melhor. Ao mesmo tempo, não poderiam simplesmente desligar a infraestrutura atual e ligar a nova.
Fazer esse processo com a operação funcionando, não foi fácil, mas é fundamental saber que para esses projetos precisamos primeiro criar um ambiente de teste, para validação da arquitetura.
Isso é importante, para avaliar os ganhos em termos de processamento, latência e disponibilidade das aplicações que vão rodar na nova plataforma.
E essa visão é que vai garantir se o que se espera em termos de ganhos financeiros e escala com a nova estrutura serão factíveis.
Outro ponto que devemos considerar para esse tipo de migração, é que as limitações de uma única ferramenta (DW) são evidentes para muitas empresas, em termos de flexibilidade, escala, custo, agilidade e outras que fazem parte da arquitetura moderna na nuvem.
Porém, a mudança de um sistema monolítico é dolorosa para a maioria das empresas.
Muitas empresas desejam substituir um banco de dados local não escalonável e caro (Oracle ou MS-SQL), por um serviço em nuvem, como Amazon Redshift (serviço de data warehouse) ou Amazon Athena (serviço Presto gerenciado), Azure Databricks (serviço Spark gerenciado) ou Google BigQuery. Eles esperam que o serviço de nuvem único substitua o banco de dados local monolítico único. Aí está um exemplo de um dos equívocos mais comuns na inovação tecnológica.
Pois a limitação está no uso de uma única ferramenta e não apenas no local onde ela está operando.
Em resumo podemos concluir que:
· Não devemos usar apenas um único armazenamento de dados, isso limitará nossa capacidade de aumentar o uso de dados.
· Devemos ver para crer, testar antes de adotar novas ferramentas e tecnologias, para amadurecer a partir do estágio de “boa ideia”.
· Devemos ter uma perspectiva de longo prazo ao projetar nossos sistemas técnicos, para permitir o crescimento ilimitado dos negócios da empresa.
Além destes pontos técnicos da tecnologia para permitir o crescimento da empresa, a governança de dados e a experiência do cliente, seja interno ou externo devem também ser observadas nesse processo.
O CTO tem como missão levantar as necessidades de otimização desses processos, inclusive para avaliar a automação de algumas atividades com base no ganho de escala da nova arquitetura.
Como podem notar, o tempo todo estamos alinhando tecnologia e negócios no mesmo patamar.
Só conseguiremos obter bons resultados com o uso de novas tecnologias se as conhecermos o suficiente para validar sua aplicação em benefício do usuário final. E para saber qual ou quais benefícios ela trará ao usuário final, precisamos conhecer bem setor da economia em que estamos atuando.
Por isso, nessas horas é tão importante e estratégico ter como CTO um profissional experiente em tecnologia e negócios, seja um consultor ou mentor.
Caso contrário, o custo dos erros por falta de experiência, pode sair muito mais caro que a contratação desse profissional.
Fontes:
Site Tech Mundo — Por que utilizar micro serviços e contêineres? — https://www.tecmundo.com.br/software/210075-utilizar-microsservicos-conteineres.htm
