Hiper crescimento em produtos e serviços digitais e os limites para o sucesso - parte 3

Impactos na performance tecnológica e dívida técnica

Nos artigos anteriores discutimos sobre o crescimento acelerado em empresas de tecnologia e como esse crescimento acelerado causa impactos em diversas partes da empresa, por exemplo, no atendimento ao cliente, assim como no tempo para servi-lo.

No artigo de hoje vamos falar sobre o impacto do crescimento acelerado na infra-estrutura tecnológica da empresa, sua performance e como a dívida técnica e a falta de atenção a manutenção e evolução contínua podem levar a limites para suportar a demanda.

Impactos na dívida técnica da pilha tecnológica

Empresas em crescimento acelerado normalmente se beneficiam de um product/market fit que catapulta o motor de crescimento causando ao mesmo tempo os seus principais benefícios e desafios da escala.

O que é comum em empresas com essas características, principalmente startups, é que a pilha tecnológica que atingiu o problem/solution fit seja escalada rapidamente ( e sem tempo para adequação ou refatoração ) para a fase de product/market fit fazendo com que um produto ou serviço digital com alto potencial dependa de componentes tecnológicos que tem dificuldades para suportar os desafios de curto/médio prazo da empresa.

A velocidade acelerada com que as mudanças nesta base de código precisam ser efetuadas, as indefinições e incertezas naturais de negócio, gaps de comunicação e em muitos casos a incapacidade técnica acaba gerando um ambiente propício para o acúmulo de dívidas técnicas, o que invariavelmente gera limites para o crescimento acelerado, além de aumentar o custo total da posse daquele ativo digital.

• fonte: Vincent Dnl Drawings

Existem muitos motivos para dívidas técnicas acontecerem em sistemas e produtos digitais ao longo do tempo, seja por conta de uma estratégia mal definida que resulta em sistemas e componentes desalinhados com a intenção estratégica, seja por causa da qualidade dos talentos envolvidos em seu desenvolvimento e/ou impacto por conta de turnover de pessoas na empresa, ou por falhas em processo e a falta de uma arquitetura emergente que tenha encaixe com os objetivos de curto/médio/longo prazo da empresa.

“Poor management of tech debt hamstrings companies’ ability to compete. The complications created by old and outdated systems can make integrating new products and capabilities prohibitively costly. Challenges hidden in the architecture can spring surprises that make projects run over budget and miss deadlines. Much of IT employees’ time is spent managing complexity rather than thinking innovatively about the future.”

• fonte: Mckinsey Digital: Tech Debt - Reclaiming Tech Equity

Independente dos motivos que as causaram, dívidas técnicas limitam a capacidade de uma empresa em crescimento acelerado de conseguir manter e evoluir os seus sistemas em um ritmo e custo aceitáveis no médio/longo prazo.

• fonte: Mckinsey Digital: Tech Debt - Reclaiming Tech Equity. Pesquisa com CIOs sobre o custo da dívida técnica em TI.

Os principais efeitos de uma dívida técnica mal administrada durante o crescimento acelerado de uma empresa é o aumento do leadtime para introduzir mudanças e acompanhar as necessidades de negócio da empresa ou ainda o efeito observado na necessidade de mais esforço, normalmente traduzido em mais pessoas, para manter, evoluir e gerenciar a complexidade do sistema ao longo do tempo, entre outros impactos negativos como: baixa moral de equipe, insatisfação e turnover alto, falta de atenção a qualidade e resultado para a empresa e o cliente.

• Acima: decisões arquiteturais e de desenvolvimento equivocadas geram dívidas técnicas ( e o acumulo de dívidas técnicas ) que por sua vez aumentam a complexidade e dificuldade de manutenibilidade na base de código, que aumentam as chances de decisões arquiteturais e desenvolvimento equivocadas acontecerem no futuro, apertando mais uma vez o ciclo de dívida técnica.

De novo, estamos falando de um tema de capacidade para atender a demanda crescente e evitar se entrar no ciclo de capability trap que já discutimos em artigos anteriores. Caso a capacidade não seja expandida na hora correta e da maneira correta para atender aos objetivos de negócios e simultaneamente evoluir e aumentar a qualidade da base de código, gerenciando as dividas técnicas, corre-se o risco de entrar no ciclo abaixo:

• Acima: Quanto maior o acúmulo de dívida técnica aumentando a complexidade e dificuldade de manutenibilidade na base de código, menor é a agilidade para se efetuar mudanças e atender aos objetivos de negócio, aumentando o gap de performance ( expectativa e realizado ), aumentando a pressão por resultados, o que cria um ambiente onde mais decisões arquiteturais e de desenvolvimento equivocadas possam acontecer, apertando mais uma vez o ciclo de dívida técnica.

Todos esses fatores acima limitam ou desaquecem os ciclos de crescimento acelerado e impactam a percepção dos clientes e usuários para continuarem buscando os produtos e serviços daquela empresa.

Impactos na performance da infra-estrutura de tecnologia

Por se tratar de informação em vez de um item físico, muitas vezes é difícil determinar de maneira precisa a capacidade de carga disponível da infraestrutura de tecnologia para identificar os gargalos e filas que limitam a capacidade atual. Normalmente fazemos testes de carga para determinar esses limites, simulando os diferentes casos de uso de clientes e as diferentes quantidades em picos de acesso que gostaríamos de suportar.

No entanto, a lei de Little aqui também pode ser muito útil para ajudar a determinar a relação entre requisições de usuários aos sistemas de tecnologia e tempo médio de resposta percebido pelo cliente em um navegador ou aplicativo.

Por exemplo, para celebrar os 50 anos da Lei de Little foram avaliadas diversas aplicações dessa lei e uma delas foi como utilizá-la para calcular a carga e tempo de resposta de servidores, neste caso foi usado como exemplo uma aplicação de alto uso como o Facebook:

“(…) An item will be a 'request’ to retrieve a piece of data needed for a response that Facebook wants to make to a member or “post” data that is derived from new activity by members. Therefore, the connections are

L = average number of requests in process
A = average arrival rate of requests ( requests/second )
W = average response time per request (seconds) = latency (seconds).

Latency is a key performance measure for computers (low is good) and has an unspoken 'average' implicitly attached, but response time seems more meaningful for a layperson.

(…)

There are a very large number of threads executing instructions in real time on a server running Facebook operations. Because of the speed of modern nanosecond chips compared to the speed of a Facebook member who is making requests in seconds, we can work in a massively parallel way (even though each thread is actually serial). We can 'time slice' or ‘multiprocess,' moving from a stopped thread to a ready thread, although the CPU must know how to find the location of the stopped thread so that it can go back there. Note that this will cost the CPU some time and will require some memory.

Time slicing and multiprocessing introduce a factor of, say, 10 in the number of threads that can be handled, thereby creating 100s or 1,000s or 100,000s of threads being worked on at once in terms of a Facebook member’s time scale. For the input rate of all online members, let A = the average rate of total thread processing required after all members’ requests have been broken down into whatever detailed subtasks are required. Let L be the average number of stopped threads in queue during some relevant time. Then W = average response time, measured, say, in seconds.”

• fonte: Little’s Law as viewed on its 50th anniversary por John Little

Picos de acesso consomem recursos finitos da infraestrutura tecnológica para servir ao cliente. Uma empresa em crescimento acelerado constantemente encontra esses limites e precisa tomar decisões arquiteturais para habilitar espaço para mais crescimento e mitigar os impactos na experiência do cliente e capacidade de servir ao cliente.

Reparem no gráfico abaixo, que descreve a relação entre latência e requesta por segundo, assim como requests in process e requests por segundo, o mesmo comportamento que vimos no caso de sobrecarga no atendimento ou na capacidade de entrega de um e-commerce é evidenciado.

• fonte: Little’s Law as viewed on its 50th anniversary por John Little ( sinalização em vermelho feita posteriormente )

Ou seja: conforme a quantidade de requisições em processamento cresce consumindo toda a capacidade disponível da infraestrutura de tecnologia o tempo para servir aumenta até um ponto em que o sistema fica, para todos os sentidos, indisponível para servir ao cliente, esse ponto é evidenciado pelo circulo vermelho nas figuras acima, claramente denotando um sistema operando acima da sua capacidade.

Obviamente nesse contexto a expansão da capacidade pode acontecer em uma variação de três temas:

• escalabilidade horizontal e/ou escalabilidade vertical da infraestrutura, normalmente suportada por alguma solução na nuvem ou virtualização de recursos compartilhados

• refatoração da aplicação para remover gargalos de performance e evoluir a sua base de código para suportar a demanda

• implementação de artifícios arquiteturais como filas, buffers ou caches de parte dos dados e serviços amortecendo o impacto do crescimento acelerado garantindo a capacidade de continuar servindo a demanda.

Independente do caminho para a solução, vemos o mesmo padrão se repetindo porém em outro lugar da corporação, assim como vemos efeitos similares aos descritos anteriormente.

No próximo artigo vamos falar sobre os impactos do crescimento acelerado na estrutura organizacional e cultura das empresas.