Você sabe se a sua aplicação está em condições de Lock-In? 

De forma sucinta, o Lock-In ocorre quando você fica preso a algum produto, ferramenta ou recurso por não existir compatibilidade para uma possível migração para outro item que faça a mesma função, mantendo um padrão. Tudo bem, vou traduzir de maneira mais amigável para quem não é da área de Tecnologia, mas possui produtos de TI no mercado.

Fazendo uma analogia, Imagine que você entra em uma concessionária, encontra aquele belo BYD Dolphin Mini (sim, um carro elétrico) no precinho atrativo “no mercado brasileiro” e resolve efetuar a compra. Após efetuar os pagamentos e emitir a documentação, você sai com o seu carro da concessionária todo feliz e na primeira curva, você cai em um buraco que estoura o pneu ao ponto de não ter como arrumar.

O primeiro passo? Procurar a concessionária ou uma loja de pneus para arrumar o problema.  Além de outros desafios (como guincho especial, entre outros), você descobre que no mercado brasileiro não existe o pneu específico para venda, nem na concessionária e muito menos nas lojas de pneus. Além disso, descobre que não pode diminuir ou aumentar o tamanho da roda para utilizar um pneu padrão de mercado e assim, “sanar o problema”. Parabéns, você está em um Lock-In pois não existem alternativas viáveis no mercado brasileiro para substituição e o que configura o seu Lock-In é a espera da “vinda” do produto para o Brasil por meio de importação ou até mesmo a troca do veículo. Dirigir um automóvel todo mundo sabe, mas trocar de carro é fácil? Definitivamente não.

O Lock-In geralmente ocorre pela decisão de utilizar um produto, um recurso, ou qualquer outra parte de uma determinada tecnologia disponível pelos players de mercado acoplados ao seu produto, com o objetivo de economizar dinheiro e aumentar a produtividade. Você consegue o que quer, mas fica amarrado naquela tecnologia (seja por contrato, por formato de utilização, por ser fora do padrão mais conhecido e também, por não arquitetar de forma correta o percurso que o seu produto deve perseguir para que a “troca” seja muito menos traumática).

Existem diversos tipos de Lock-In que acontecem em grandes produtos disponíveis no mercado, desde bancos digitais até sistemas de identificação biométrica. A substituição é sempre um trauma.

Mas como evitar o Lock-In?

O melhor caminho é utilizar ferramentas livres (de código aberto) que já estão validadas pelos desenvolvedores, mas isto também tem custo, que é a disponibilização de mais uma “máquina virtual” ou mais um “POD” dentro do seu ecossistema (que também pode estar em Lock-In, entendeu?). Os benefícios são gigantescos, mas como sempre, a análise de criação de todas as fases do produto deve ser pensada com muito cuidado para não existir o que chamamos de “dependência eterna”. E digo isso pois é muito mais fácil sair de um Lock-In (que é problemático) do que ficar preso em uma ferramenta por falta de atualização, manutenção ou descontinuidade.

E o Lock-In é sempre prejudicial?

A resposta é não: Alguns lock-ins são necessários pois atuam como ferramentas “padrão” de mercado, e nestes casos, raramente sofre-se com este problema. E se sofrer, o “chaveamento” pode ser feito de forma simples, claro, desde que bem arquitetada a implementação antes da distribuição. Grandes exemplos disso são as conhecidas ferramentas de dupla autenticação, além dos serviços de processos, fluxos e até as mais conhecidas ferramentas de BPMN/ECM que já são consagradas e de fácil migração.

Quer um belo exemplo de Lock-In? O Workplace deixará de existir. Tem solução? Sim, várias de mercado e ainda gratuitas. A migração será fácil? Talvez, tudo vai depender do modelo de implementação das integrações e já avisando: Se você cadastrou os usuários na “mão”, você vai sofrer. Já em questão de adaptação ao novo recurso, o Lock-In é extremamente baixo pois nos dias atuais, migramos mais de ferramentas do que compramos roupas novas.

E o que devo fazer para ter um bom “meio termo”?

Uma boa especificação de arquitetura, um bom entendimento da infraestrutura e a escolha das ferramentas adequadas devem ser consideradas antes mesmo da concepção do projeto. Alguns Benchmarks são essenciais para saber se vale a pena o investimento direto no “produto de fácil acesso” ou se é melhor investir no recurso mais complexo, porém livre.

Então considere:

• Bons arquitetos (seja de solução ou de software);
• Uma equipe com conhecimentos híbridos (especialização é só para algo especial ;))
• Simulações (no papel) exaustivas de como o seu projeto funcionará
• Orçamentos de custos entre Farms prontos ou uso de Farm gerenciado pela estrutura
• Se o que você precisa ofertar realmente precisa passar por um processo de Lock-In
• Performance (por isso digo: Às vezes o Lock-In se justifica)
• O tão dito “best practices” para desenvolvimento de projetos (conceitos atualizados)
• O “tamanho do bonde”: Isto define banco de dados, processamento, cache e muitas outras coisas
• O quanto “a sua balada será visitada”. Cuidar do cache e do Front End
• Migração (e é aqui que o bolso dói)

A moral da história:

O Lock-In é preocupante, desafiador e até temeroso, mas não é de todo mal quando planejado. O que mais leio é: Fuja do Lock-In. E o que eu mais digo é: Planeje bem o seu produto.

Estar no “hype” é legal pois chama a atenção, mas tem seus custos e os players adoram isto. Não importa se o seu negócio vai bombar ou se vai “afundar” como o Titanic, o que o player quer é o seu dinheiro, que ele chama de investimento.

Invista direito, pense alto, planeje sempre, fale pouco e evidencie tudo. Vai demorar? SIM, vai demorar e talvez você crie algo até um pouco mais “obsoleto” na “visão do hype” em relação ao mercado, mas… Lembram Bate Papo do UOL, né? O caminho é sempre o mesmo para quem planeja pouco.

Quer discutir sobre isto conosco? Marque uma visita de nossa equipe especializada.

Flavio Almeida,
Arquiteto de Soluções.