# Como não complicar demais a escolha da sua plataforma de IoT

> Por que avaliações de plataformas de IoT travam em planilhas de 80 linhas, quais decisões são difíceis de reverter e como um piloto de duas semanas com dispositivos reais substitui o RFP.

![Como não complicar demais a escolha da sua plataforma de IoT](https://tago.io/og/pt-br/blog/avoid-overcomplicating-your-iot-platform-choice.png)

A maioria dos times começa a avaliação de uma plataforma de IoT do jeito sensato. Uma lista curta com três ou quatro candidatas, uma planilha e requisitos vindos de cada área envolvida: SSO e logs de auditoria, alertas e gestão de firmware, um modelo de custos, um portal para clientes. Parece um trabalho criterioso, e nas duas primeiras semanas é.

Depois a planilha chega a 80 linhas. Todo fornecedor marca quase todos os itens, porque qualquer plataforma madura sabe armazenar telemetria, desenhar um gráfico e disparar um alerta. As diferenças que sobram estão em linhas que ninguém consegue pontuar sem usar o produto, então o time agenda mais demos. Três meses depois, a avaliação tem um modelo de pontuação ponderada, quatro apresentações de fornecedor e nenhum dispositivo enviando dados para lugar algum.

A complexidade vem de duas fontes, e nenhuma delas é o fornecedor. A primeira é avaliar recursos que você não vai usar no primeiro ano. A segunda é tratar a decisão como irreversível, o que faz parecer que cada linha precisa estar certa. A maioria não precisa. Uma lista curta de coisas é difícil de mudar depois. Todo o resto é configuração, e é para isso que serve um piloto.

![Reduza a avaliação ao que é difícil de reverter: uma planilha de requisitos com 80 linhas em que todo fornecedor pontua de 82 a 91 por cento se reduz às perguntas difíceis de reverter, exportação de dados em massa, preço no volume do terceiro ano, um portal com a sua marca para usuários finais, os dispositivos que você realmente tem e o seu próprio código dentro da plataforma, e termina em um piloto de duas semanas com dispositivos reais](https://tago.io/images/blog/avoid-overcomplicating-your-iot-platform-choice/cut-evaluation-to-hard-to-reverse.svg)

## Sinais de que você está complicando demais

Alguns padrões aparecem em quase toda avaliação travada que vi entre integradores de sistemas e times de produto de OEMs.

- A lista de requisitos tem linhas para recursos que ninguém consegue justificar nos próximos doze meses. Gêmeos digitais aparecem na planilha enquanto os dispositivos reais são 40 sensores de temperatura LoRaWAN em um galpão.
- Todo fornecedor pontua entre 82 e 91 por cento. Quando a diferença é tão pequena, a pontuação mede quem escreve datasheets melhor.
- Ninguém do time de avaliação passou mais de uma hora logado em alguma das candidatas.
- A expressão "à prova do futuro" aparece no documento de justificativa e ninguém sabe dizer contra qual futuro.
- Já se fala em uma segunda rodada de RFP para "esclarecer as respostas" da primeira.
- A data de início do piloto já mudou pelo menos duas vezes.

Se dois ou mais desses itens se aplicam, a planilha parou de ajudar.

## O que é de fato irreversível

A pergunta útil para cada linha não é "a plataforma faz isso" e sim "se errarmos aqui, quanto custa mudar de ideia em dois anos?" A maioria das linhas não passa nesse teste. Tipos de Widget, canais de alerta, formatos de relatório, papéis de usuário, layouts de dashboard e a integração com o ERP são coisas que você configura e reconfigura enquanto usar a plataforma. Errar nelas na hora da escolha custa uma tarde lá na frente.

Um conjunto pequeno de decisões não funciona assim, e é nele que vale gastar o tempo de avaliação.

**Propriedade e exportação dos dados.** Dois anos de telemetria são o ativo mais caro do projeto, e conseguir tirar tudo de uma vez, em um formato aproveitável, sem depender de ticket de suporte, define a força do fornecedor na hora da renovação. Veja como funciona a [exportação de dados](https://docs.tago.io/docs/tagoio/devices/data-management/data-export), se a API dá acesso bruto a tudo e onde os dados ficam. O [post sobre vendor lock-in](https://tago.io/blog/vendor-lock-in-in-iot-platforms) mostra o que testar.

**Comportamento do preço no volume do terceiro ano.** O preço com 50 dispositivos não diz nada. Modele a fatura com a quantidade de dispositivos e a taxa de mensagens que você espera no terceiro ano e descubra qual medidor move o número: dispositivos, data points, armazenamento, usuários ou outra coisa. Duas plataformas que custam o mesmo hoje podem ter uma diferença de três vezes em escala, e trocar depois significa migrar os dados do parágrafo anterior. A [comparação de preços em três anos](https://tago.io/blog/comparing-iot-platform-pricing-over-three-years) faz essa conta.

**Quem são os seus usuários finais.** Se quem olha os dados é a sua própria equipe de operações, o console do Admin já resolve. Se são clientes, locatários ou técnicos de campo que nunca podem ver as instalações uns dos outros, a plataforma precisa colocar na frente deles um portal com a sua marca e regras de acesso por usuário. Isso é arquitetura, não cosmética. Na TagoIO essa camada é o [TagoRUN](https://tago.io/run) com políticas de Access Management; construir isso por conta própria depois é um projeto, não uma configuração.

**Os dispositivos e as redes que você realmente tem.** Não os que talvez você adicione em 2028. Se a frota é LoRaWAN por um network server específico, dispositivos celulares falando MQTT ou um gateway Modbus antigo, a plataforma precisa decodificar esses payloads hoje.

**Superfície de integração.** O seu próprio código roda dentro da plataforma quando uma regra passa do que um menu comporta? Sistemas externos conseguem trocar dados nos dois sentidos por uma API documentada? Essa é a diferença entre uma plataforma que você estende e outra que você contorna.

A lista é essa. Se uma candidata passa, as linhas que restam são configuração que você vai conferir no piloto, e configuração não é motivo para manter a avaliação aberta.

## Troque a planilha por um piloto de duas semanas

A planilha responde perguntas na leitura. O piloto responde na prática, e a prática fica mais rápida depois que as perguntas difíceis de reverter estão resolvidas. O formato que funciona é enxuto e com prazo fechado: um caso de uso que importa para o negócio, dez a vinte dispositivos reais da sua frota, um local, um tipo de usuário e uma data de término fixa em duas semanas. Escreva antes de começar o que significa "funcionou": dispositivos decodificados e enviando dados, um dashboard que o usuário previsto consegue ler, um alerta que dispara em uma condição real, uma exportação dos dados coletados que o seu time consegue abrir.

Na TagoIO essas duas semanas costumam ser assim. Dias um e dois: adicione os dispositivos por um Connector da sua rede, ou escreva um Payload Parser se o dispositivo não estiver na lista. Dias três a cinco: monte o dashboard com Widgets padrão e converta para um Blueprint Dashboard, para que um layout sirva a todos os dispositivos. Segunda semana: uma Action que envia o alerta, um script de Analysis se a lógica precisar de mais do que um limite, e um usuário do TagoRUN entrando para ver só os dados dele. No último dia, exporte os dados e leia a fatura.

O que você aprende nessas duas semanas é o que a planilha não tinha como dizer: quanto tempo de verdade leva para decodificar um dispositivo novo, se o usuário previsto entende o dashboard sem treinamento, se os medidores de preço se movem como você modelou e como a plataforma se comporta quando o seu código de Analysis dá erro às 2 da manhã. O [guia do comprador](https://tago.io/blog/iot-platform-buyers-guide) tem as perguntas para fazer aos fornecedores antes dessa etapa; o piloto é onde você para de perguntar e confere.

## Quando a resposta certa é um teste pequeno, não outro RFP

Algumas versões dessa decisão não exigem processo de compra nenhum. Se você é um integrador de sistemas escolhendo a plataforma para o próprio negócio de serviços, ou um time de produto com algumas centenas de dispositivos no primeiro ano, uma escolha errada custa uma migração que dá para fazer em um trimestre. Nessa situação, a parte mais cara da decisão é o tempo gasto para tomá-la.

Uma conta gratuita ou de plano básico em duas candidatas, os mesmos dez dispositivos conectados nas duas e duas semanas de uso real dão uma resposta mais clara que uma terceira rodada de questionários para fornecedores. Construir sobre o AWS IoT Core ou uma stack open source é uma resposta legítima para alguns times, e o teste é o mesmo: conecte os dispositivos e conte as semanas até um dashboard funcionando.

Depois decida, e registre o motivo. As razões que vão importar em dois anos são as difíceis de reverter. Todo o resto você vai mudar pelo menos duas vezes de qualquer jeito.

## Recursos

- [Guia do comprador de plataformas de IoT: perguntas para fazer antes de decidir](https://tago.io/blog/iot-platform-buyers-guide)
- [Vendor lock-in em plataformas de IoT](https://tago.io/blog/vendor-lock-in-in-iot-platforms)
- [Comparando preços de plataformas de IoT em três anos](https://tago.io/blog/comparing-iot-platform-pricing-over-three-years)
- [Cinco passos para construir uma aplicação de IoT bem-sucedida](https://tago.io/blog/steps-to-build)

[llms.txt](https://tago.io/llms.txt)