Um produto conectado pode parecer finalizado muito antes de sua engenharia estar concluída. O protótipo está estável, os dados chegam à nuvem, o aplicativo exibe os valores corretos e o primeiro lote de dispositivos já está nas mãos dos usuários. Nesse ponto, o backend ainda pode ser simples o suficiente para que a equipe conheça praticamente cada dispositivo individualmente. O provisionamento pode ser feito por meio de um script, as alterações de configuração podem ser feitas manualmente e, se algo falhar, um engenheiro geralmente consegue rastrear o problema diretamente.
Então, o sistema precisa começar a funcionar no mundo real. Uma segunda revisão de hardware é lançada. Alguns clientes ainda estão usando a primeira revisão. As versões de firmware começam a divergir. Uma nova configuração é necessária para um cliente ou mercado diferente, enquanto os dispositivos mais antigos ainda precisam de atualizações e suporte.
Nada está necessariamente quebrado. O software por trás do dispositivo simplesmente adquiriu um ciclo de vida próprio.
Essa transição é fácil de passar despercebida, pois o protótipo pode continuar funcionando perfeitamente bem. Mas, quando várias versões do mesmo produto físico precisam coexistir em campo, o backend deixa de ser apenas a infraestrutura por trás do hardware e passa a fazer parte da própria arquitetura do produto.
Um protótipo conectado e funcional ainda não é um produto escalável.
Um protótipo tem uma função importante: provar que o sistema funciona de ponta a ponta. O dispositivo executa sua função principal, o firmware se comunica com o servidor, a telemetria chega ao destino correto, os comandos retornam e uma interface web ou móvel expõe a funcionalidade ao usuário.
O que geralmente não se comprovou é o quão bem o mesmo sistema lida com a variedade.
Os primeiros vinte dispositivos podem executar o mesmo firmware, ser fabricados com a mesma revisão de hardware e configurados pelos mesmos engenheiros. Nessa fase, o registro manual, alterações diretas de configuração ou um pequeno script de integração podem ser perfeitamente viáveis. Construir ferramentas de nível de produção antes que o produto tenha comprovado seu valor pode ser prematuro.
A escala altera o problema. Os dispositivos ficam offline, são substituídos, executam firmwares diferentes e exigem configurações diferentes do cliente. O suporte precisa distinguir uma unidade que nunca foi provisionada corretamente de uma que está mal configurada ou simplesmente inacessível.
A dívida de protótipos geralmente começa assim: não com uma decisão ruim, mas com uma decisão temporária que permanece em vigor mesmo depois que o produto já evoluiu. E uma das primeiras coisas que força essa transição a se tornar visível é o próprio hardware. Uma nova versão não substitui simplesmente a antiga; ela precisa coexistir com ela.
Cada revisão de hardware cria um problema no ciclo de vida do software.
Uma nova revisão de hardware raramente chega como uma substituição direta da antiga. Na prática, ambas as versões permanecem em uso, às vezes por anos. Adicione um lote de transição, algumas ramificações de firmware e configurações específicas do cliente, e a frota rapidamente se torna mais diversificada do que o modelo original do produto sugeria.
A camada de software não pode mais tratar cada unidade como um "dispositivo" abstrato. Ela precisa saber o que aquela unidade específica é capaz de fazer.
Uma placa revisada pode usar um sensor, módulo de comunicação ou controlador diferente. Um comando válido para a versão mais recente pode não ser compatível com uma versão anterior. Os valores de calibração podem mudar. Os limites de configuração podem ser alterados. Um pacote de firmware adequado para uma geração pode ser inseguro para outra.
Os engenheiros de produtos físicos já trabalham dessa forma. Dois componentes que parecem quase idênticos não são intercambiáveis se suas revisões, tolerâncias ou especificações forem diferentes. Produtos conectados criam o mesmo problema no lado do software: a plataforma precisa de uma maneira confiável de entender com qual versão do produto físico está se comunicando e quais regras se aplicam a ela.
Considere um produto cuja primeira versão utiliza um procedimento de calibração, enquanto a segunda introduz um novo sensor e um conjunto diferente de parâmetros. Para o cliente, ambas as unidades podem parecer o mesmo produto. Para a plataforma, porém, não.
Se essas diferenças não forem representadas explicitamente, elas tendem a se infiltrar na lógica do aplicativo como casos especiais. Um fluxo de trabalho verifica um intervalo de números de série. Outro usa a versão do firmware como um indicador da geração do hardware. Um terceiro contém uma exceção adicionada depois que o suporte descobriu que um lote mais antigo estava se comportando de maneira diferente em campo. Nenhuma dessas correções parece especialmente perigosa isoladamente, mas juntas elas dificultam a compreensão de qualquer alteração futura.
Hardware antigo raramente desaparece no prazo previsto. As equipes de produto naturalmente se concentram na revisão mais recente, enquanto os clientes frequentemente mantêm versões anteriores por muito mais tempo do que o esperado. Portanto, a plataforma precisa suportar várias gerações simultaneamente, em vez de presumir que a base instalada algum dia convergirá para um único estado atual.
Quando isso acontece, a evolução do hardware e o gerenciamento do ciclo de vida do software tornam-se inseparáveis. A plataforma precisa saber não apenas onde um dispositivo está e se está online, mas também o que ele é, o que ele pode executar, como deve ser configurado e quais alterações podem ser aplicadas com segurança.
E antes que qualquer uma dessas perguntas possa ser respondida de forma confiável, cada dispositivo precisa entrar no sistema de maneira consistente.
O provisionamento é onde a engenharia manual deixa de ser escalável.
O provisionamento parece simples quando a frota é pequena: crie um registro de dispositivo, insira um número de série, gere credenciais, atribua a unidade a um cliente, aplique uma configuração e pronto. Para algumas dezenas de dispositivos, lidar com parte disso manualmente ainda pode ser a escolha certa.
Em escala de produção, no entanto, o provisionamento situa-se na interseção da identidade do dispositivo, credenciais, propriedade, configuração e estado do ciclo de vida. Um erro cometido durante a integração pode afetar a forma como a unidade é operada e suportada muito tempo depois de sair da fábrica.
Uma planilha pode não corresponder mais ao que está realmente instalado. Um dispositivo de substituição precisa da associação de cliente correta, sem herdar a identidade errada. A restauração de fábrica cria um caminho adicional no processo. Um instalador pode atribuir uma unidade à conta errada, obrigando a equipe de suporte a determinar se ela está offline, provisionada incorretamente ou simplesmente com a configuração errada.
Quando responder a essas perguntas rotineiramente exige que um desenvolvedor inspecione um banco de dados ou execute um script interno, o processo deixa de ser escalável com o produto.
A duplicação é outro sinal de alerta. Cada variante de produto começa a ter seu próprio script de integração, ferramenta de configuração ou fluxo de trabalho de instalação. Essas diferenças podem parecer pequenas, mas a responsabilidade subjacente é a mesma. O provisionamento tornou-se uma infraestrutura de plataforma reutilizável, em vez de uma tarefa de configuração vinculada a um dispositivo específico.
E raramente é a única capacidade que precisa se tornar reutilizável.
A camada de plataforma deve se tornar infraestrutura reutilizável.
Quando vários produtos ou revisões de hardware compartilham as mesmas necessidades básicas, algumas funcionalidades de software deixam de ser específicas do produto. Identidade do dispositivo, provisionamento, conectividade, telemetria, distribuição de firmware, estado do ciclo de vida, visibilidade da frota e diagnósticos são bons exemplos. Recriá-las para cada nova variante cria mais código e mais caminhos operacionais para manutenção, sem tornar o produto em si mais distinto.
As equipes raramente têm a intenção de criar essa duplicação. Pequenas diferenças se acumulam em torno de cada produto até que a equipe esteja mantendo várias implementações do que se tornou a mesma responsabilidade de engenharia.
Uma delimitação mais clara consiste em separar a camada de produto da camada de plataforma. A camada de produto contém o comportamento, os fluxos de trabalho, as interfaces, as integrações e a lógica de domínio que tornam um determinado dispositivo valioso. A camada de plataforma lida com os mecanismos que devem permanecer consistentes mesmo com as mudanças de hardware.
À medida que os produtos conectados evoluem além do seu primeiro lançamento, o provisionamento de dispositivos, o gerenciamento do ciclo de vida dos dispositivos, o gerenciamento de frotas e as ferramentas de suporte tornam-se infraestrutura compartilhada, em vez de detalhes isolados de projetos. Uma plataforma PaaS de IoT para empresas pode fornecer essa camada de plataforma reutilizável em vários produtos ou variantes de produtos, lidando com o gerenciamento padrão de dispositivos e dados por meio de blocos de construção reutilizáveis, enquanto as equipes de engenharia mantêm o foco em hardware, fluxos de trabalho e experiência do usuário.
Uma base comum ainda precisa deixar espaço para diferenças reais entre os produtos. Um novo dispositivo pode exigir um modelo de dados, fluxo de configuração, integração ou lógica de controle diferentes, e essas diferenças devem permanecer fáceis de introduzir. O objetivo é simplesmente evitar que cada diferença implique em um novo registro de dispositivos, pipeline de telemetria, mecanismo de provisionamento ou conjunto de ferramentas de gerenciamento de frota.
A plataforma pode parecer um custo adicional enquanto a equipe está desenvolvendo o primeiro produto e um recurso valioso no segundo ou terceiro. Uma vez que os mecanismos operacionais comuns estejam implementados, uma nova variante pode herdar uma base funcional em vez de chegar com um novo backend que a equipe terá que manter pelo resto da vida útil do produto.
Mantenha a engenharia personalizada apenas onde o produto for realmente diferente.
Uma plataforma reutilizável não deve tornar os produtos conectados mais genéricos. Sua função é eliminar a necessidade de retrabalho nas partes que não criam diferenciação.
O esforço de personalização ainda se aplica ao comportamento do dispositivo, à lógica específica do domínio, aos fluxos de trabalho, à experiência do usuário, às integrações especializadas e à forma como um determinado produto interage com o mundo físico. São exatamente nessas áreas que as escolhas de engenharia podem tornar um produto significativamente melhor do que outro.
O que raramente merece o mesmo tratamento é a infraestrutura operacional circundante. Uma versão básica e uma versão industrial da mesma máquina podem precisar de sensores, controles e interfaces diferentes, mas não devem exigir maneiras distintas de identificar dispositivos, rastrear versões de firmware ou gerenciar uma frota.
Eu preferiria ver os engenheiros dedicando esse tempo a aprimorar o comportamento do produto em campo, em vez de reconstruir mecanismos que a equipe já possui para outro produto. Uma base compartilhada não reduz o escopo da engenharia personalizada; ela protege esse esforço de ser consumido pela infraestrutura.
O verdadeiro teste começa quando a equipe inicia o desenvolvimento do segundo produto.
Uma boa plataforma torna o próximo produto mais fácil de desenvolver do que o primeiro.
Se o produto número dois requer praticamente o mesmo trabalho de plataforma que o produto número um, muito pouco foi realmente reutilizado.
Uma nova variante deve ser capaz de herdar as partes do modelo operacional que não foram alteradas: fluxos de provisionamento, identidade, mecânica do ciclo de vida, ferramentas de gestão de frota, processos de firmware, visibilidade do suporte e integrações comuns. O esforço de engenharia, então, se concentra nas diferenças — talvez um novo pacote de sensores, um fluxo de trabalho de controle diferente ou uma integração específica para o cliente — em vez de reconstruir a base.
Uma nova geração de hardware coloca a mesma ideia sob maior pressão. Suas capacidades podem mudar substancialmente, enquanto unidades mais antigas permanecem ativas em campo. Uma plataforma madura pode suportar ambas sem forçar a equipe a manter duas pilhas de plataforma separadas para o que os clientes ainda percebem como uma única família de produtos.
Nada disso exige um backend monolítico. Produtos diferentes ainda podem precisar de limites arquitetônicos claros. O importante é evitar uma segunda implementação da mesma responsabilidade de engenharia sem um bom motivo.
É nesse momento que a plataforma se torna um ativo, em vez de um custo acumulado. O suporte passa a ter menos ferramentas paralelas para entender, os lançamentos seguem caminhos mais consistentes e a adição de outro produto se torna uma extensão controlada, em vez de mais um sistema que a empresa herda indefinidamente.
Considere a plataforma como parte da arquitetura do produto.
Os produtos físicos são projetados levando em consideração revisões, facilidade de manutenção, capacidade de fabricação e mudanças futuras. Os produtos conectados exigem a mesma disciplina no lado do software.
O primeiro backend pode ser temporário. O mesmo vale para o primeiro script de provisionamento ou ferramenta de suporte. Não há nada inerentemente errado nisso. Os problemas começam quando esses mecanismos temporários se tornam, silenciosamente, arquitetura permanente, enquanto o próprio produto continua a evoluir.
A essa altura, o produto conectado não é mais apenas hardware, firmware e um aplicativo. Ele também depende da infraestrutura que identifica cada dispositivo, entende suas capacidades, aplica a configuração correta, oferece suporte a atualizações e ajuda as equipes a diagnosticar problemas anos após o envio.
Quando essa camada é tratada como arquitetura de produto, a divisão fica mais clara: os mecanismos padrão permanecem reutilizáveis, enquanto o trabalho personalizado se concentra no que realmente distingue um produto ou família de produtos de outro.
A plataforma mais robusta não é simplesmente aquela que torna possível o primeiro produto conectado. É aquela que permite à equipe de engenharia construir o segundo, o terceiro e o quarto sem ter que herdar um novo backend a cada vez.
