Et forbundet produkt kan se færdigt ud længe før ingeniørarbejdet omkring det er færdigt. Prototypen er stabil, data når skyen, appen viser de rigtige værdier, og den første batch af enheder er allerede i brugernes hænder. På det tidspunkt kan backend-systemet stadig være simpelt nok til, at teamet kender næsten hver enhed individuelt. Provisionering kan håndteres med et script, konfigurationsændringer kan foretages manuelt, og hvis noget fejler, kan en ingeniør normalt spore problemet direkte.
Så skal den begynde at leve i den virkelige verden. En anden hardwarerevision dukker op. Nogle kunder bruger stadig den første revision. Firmwareversionerne begynder at afvige. En ny konfiguration er nødvendig for en anden kunde eller et andet marked, mens ældre enheder stadig har brug for opdateringer og support.
Intet er nødvendigvis i stykker. Softwaren bag enheden har simpelthen fået sin egen livscyklus.
Den overgang er let at overse, fordi prototypen kan fortsætte med at fungere perfekt. Men når flere versioner af det samme fysiske produkt skal sameksistere i felten, er backend'en ikke længere bare infrastruktur bag hardwaren. Den bliver en del af selve produktarkitekturen.
En fungerende, forbundet prototype er endnu ikke et skalerbart produkt
En prototype har en vigtig opgave: at bevise, at systemet fungerer fra start til slut. Enheden udfører sin kernefunktion, firmware kommunikerer med backend'en, telemetri ankommer, hvor den skal, kommandoer foretager returrejsen, og en mobil- eller webgrænseflade eksponerer funktionaliteten for en bruger.
Hvad det normalt ikke har bevist, er hvor godt det samme system håndterer variation.
De første tyve enheder kan alle køre den samme firmware, være bygget til den samme hardwarerevision og være konfigureret af de samme ingeniører. På det tidspunkt kan manuel registrering, direkte konfigurationsændringer eller et lille onboarding-script være helt fornuftigt. Det kan være for tidligt at bygge værktøjer i produktionskvalitet, før produktet har bevist sit værd.
Skalering ændrer problemet. Enheder forbliver offline, bliver udskiftet, kører forskellig firmware og kræver forskellige kundekonfigurationer. Support skal skelne mellem en enhed, der aldrig blev korrekt provisioneret, og en, der er forkert konfigureret eller simpelthen ikke kan nås.
Prototypgæld starter ofte på denne måde: ikke med en dårlig beslutning, men med en midlertidig beslutning, der forbliver på plads, efter at produktet er gået videre. Og en af de første ting, der fremtvinger denne overgang, er selve hardwaren. En ny revision erstatter ikke blot den gamle; den skal sameksistere med den.
Enhver hardwarerevision skaber et problem i softwarens livscyklus
En ny hardwarerevision ankommer sjældent som en ren erstatning for den gamle. I praksis forbliver begge versioner i felten, nogle gange i årevis. Tilføj en overgangsbatch, et par firmware-grene og kundespecifikke konfigurationer, og flåden bliver hurtigt mere forskelligartet, end den oprindelige produktmodel antyder.
Softwarelaget kan ikke længere behandle hver enhed som en abstrakt "enhed". Det er nødt til at vide, hvad den pågældende enhed er i stand til at gøre.
Et revideret kort kan bruge en anden sensor, et andet kommunikationsmodul eller en anden controller. En kommando, der er gyldig for den seneste version, understøttes muligvis ikke af en tidligere version. Kalibreringsværdier kan ændres. Konfigurationsgrænser kan forskydes. En firmwarepakke, der er egnet til én generation, kan være usikker for en anden.
Fysiske produktingeniører arbejder allerede på denne måde. To komponenter, der ser næsten identiske ud, kan ikke udskiftes, hvis deres revisioner, tolerancer eller specifikationer er forskellige. Forbundne produkter skaber det samme problem på softwaresiden: Platformen har brug for en pålidelig måde at forstå, hvilken version af det fysiske produkt den kommunikerer med, og hvilke regler der gælder for den.
Forestil dig et produkt, hvis første revision bruger én kalibreringsprocedure, mens den anden introducerer en ny sensor og et andet sæt parametre. For kunden kan begge enheder stadig være det samme produkt. For platformen kan de ikke være det.
Hvis disse forskelle ikke er eksplicit repræsenteret, har de en tendens til at sive ind i applikationslogikken som særlige tilfælde. Én arbejdsgang kontrollerer et serienummerinterval. En anden bruger en firmwareversion som en proxy for hardwaregenerering. En tredje indeholder en undtagelse, der er tilføjet, efter at support opdagede, at en ældre batch opførte sig anderledes i felten. Ingen af disse rettelser ser særligt farlige ud i sig selv, men sammen gør de enhver fremtidig ændring sværere at ræsonnere over.
Ældre hardware forsvinder sjældent til tiden. Produktteams fokuserer naturligt på den nyeste revision, mens kunder ofte beholder tidligere versioner meget længere end forventet. Platformen skal derfor understøtte flere generationer på én gang i stedet for at antage, at den installerede base nogensinde vil samles på en enkelt nuværende tilstand.
Når det sker, bliver hardwareudvikling og softwarelivscyklusstyring uadskillelige. Platformen skal ikke kun vide, hvor en enhed er, og om den er online, men også hvad den er, hvad den kan køre, hvordan den skal konfigureres, og hvilke ændringer der er sikre at anvende.
Og før nogen af disse spørgsmål kan besvares pålideligt, skal hver enhed indtastes i systemet på en ensartet måde.
Provisionering er hvor manuel udvikling stopper skalering
Klargøring ser simpel ud, når flåden er lille: opret en enhedspost, indtast et serienummer, generer legitimationsoplysninger, tildel enheden til en kunde, anvend en konfiguration, og fortsæt. For et par dusin enheder kan det stadig være det rigtige valg at håndtere noget af dette manuelt.
I produktionsskala ligger provisionering dog i krydsfeltet mellem enhedsidentitet, legitimationsoplysninger, ejerskab, konfiguration og livscyklusstatus. En fejl begået under onboarding kan påvirke, hvordan enheden betjenes og understøttes, længe efter den forlader fabrikken.
Et regneark stemmer muligvis ikke længere overens med det, der rent faktisk er installeret. En erstatningsenhed skal have den rigtige kundetilknytning uden at arve den forkerte identitet. Fabriksnulstillinger skaber en anden vej gennem processen. En installatør kan tildele en enhed til den forkerte konto og overlade det til support at afgøre, om den er offline, forkert provisioneret eller blot har den forkerte konfiguration.
Når besvarelsen af disse spørgsmål rutinemæssigt kræver, at en udvikler inspicerer en database eller kører et internt script, er processen stoppet med at skalere med produktet.
Duplikering er endnu et advarselstegn. Hver produktvariant begynder at få sit eget onboarding-script, konfigurationsværktøj eller installationsworkflow. Disse forskelle kan se små ud, men det underliggende ansvar er det samme. Provisionering er blevet en genanvendelig platforminfrastruktur i stedet for en opsætningsopgave, der er knyttet til en bestemt enhed.
Og det er sjældent den eneste funktion, der skal genbruges.
Platformlaget bør blive til genanvendelig infrastruktur
Når flere produkter eller hardwarerevisioner deler de samme grundlæggende behov, ophører nogle softwarefunktioner med at være produktspecifikke. Enhedsidentitet, provisionering, tilslutningsmuligheder, telemetri, firmwarelevering, livscyklusstatus, flådesynlighed og diagnosticering er gode eksempler. Genopbygning af dem for hver ny variant skaber mere kode og flere driftsstier at vedligeholde uden at gøre selve produktet mere unikt.
Teams sætter sig sjældent for at skabe denne overlapning. Små forskelle akkumuleres omkring hvert produkt, indtil teamet vedligeholder flere implementeringer af det, der er blevet det samme tekniske ansvar.
En renere grænse er at adskille produktlaget fra platformlaget. Produktlaget indeholder den adfærd, arbejdsgange, grænseflader, integrationer og domænelogik, der gør en bestemt enhed værdifuld. Platformlaget håndterer mekanikker, der skal forblive konsistente, selv når hardwaren ændres.
Efterhånden som forbundne produkter bevæger sig ud over deres første udgivelse, bliver enhedsklargøring, enhedslivscyklusstyring, flådestyring og supportværktøjer til delt infrastruktur i stedet for engangsprojektdetaljer. En IoT PaaS til virksomheder kan levere det genanvendelige platformslag på tværs af flere produkter eller produktvarianter og håndtere standard enheds- og datastyring gennem genanvendelige byggesten, mens ingeniørteams holder deres brugerdefinerede indsats fokuseret på hardware, arbejdsgange og brugeroplevelse.
Et fælles fundament skal stadig give plads til reelle produktforskelle. En ny enhed kan have brug for en anden datamodel, konfigurationsflow, integration eller kontrollogik, og disse forskelle bør forblive lette at introducere. Målet er simpelthen at undgå, at enhver forskel trækker et andet enhedsregister, telemetri-pipeline, provisioneringsmekanisme eller sæt af flådestyringsværktøjer med sig.
Platformen kan virke som en overhead, mens teamet bygger det første produkt, og som et aktiv, mens det andet eller tredje produkt bygger. Når de fælles driftsmekanikker er på plads, kan en ny variant arve et fungerende fundament i stedet for at ankomme med en anden backend, som teamet skal vedligeholde resten af produktets levetid.
Behold specialudvikling, hvor produktet rent faktisk er anderledes
En genanvendelig platform bør ikke gøre forbundne produkter mere generiske. Dens opgave er at fjerne gentagen ingeniørkunst fra de dele, der ikke skaber differentiering.
Brugerdefineret indsats hører stadig hjemme i enhedsadfærd, domænespecifik logik, arbejdsgange, brugeroplevelse, specialiserede integrationer og den måde, et bestemt produkt interagerer med den fysiske verden på. Det er præcis de områder, hvor tekniske valg kan gøre ét produkt betydeligt bedre end et andet.
Det, der sjældent fortjener samme behandling, er det omgivende driftsmæssige VVS. En basisversion og en industriel version af den samme maskine kan have brug for forskellige sensorer, kontroller og grænseflader, men de bør ikke kræve separate måder at identificere enheder, spore firmwareversioner eller administrere en flåde.
Jeg ville hellere se ingeniører bruge den tid på at forbedre, hvordan produktet opfører sig i felten, end at genopbygge mekanikker, som teamet allerede har på plads til et andet produkt. Et fælles fundament reducerer ikke muligheden for specialudviklet udvikling; det beskytter den indsats mod at blive opslugt af infrastruktur.
Den virkelige test kommer, når teamet starter produkt nummer to.
En god platform gør det næste produkt nemmere end det første
Hvis produkt nummer to kræver næsten det samme platformarbejde som produkt nummer et, er der faktisk kun meget lidt blevet genbrugt.
En ny variant bør kunne arve de dele af driftsmodellen, der ikke er ændret: provisioneringsflows, identitet, livscyklusmekanik, flådeværktøjer, firmwareprocesser, supportsynlighed og fælles integrationer. Den tekniske indsats går derefter i retning af forskellene – måske en ny sensorpakke, en anden kontrolworkflow eller en kundespecifik integration – i stedet for at rekonstruere fundamentet.
En ny hardwaregeneration sætter den samme idé under større pres. Dens muligheder kan ændre sig væsentligt, mens ældre enheder forbliver aktive i marken. En moden platform kan understøtte begge dele uden at tvinge teamet til at vedligeholde to separate platformstakke for det, kunderne stadig opfatter som én produktfamilie.
Intet af dette kræver én monolitisk backend. Forskellige produkter kan stadig have brug for klare arkitektoniske grænser. Det vigtige er at undgå en anden implementering af det samme tekniske ansvar uden en god grund.
Det er på det tidspunkt, at platformen bliver et aktiv i stedet for akkumuleret overhead. Support har færre parallelle værktøjer at forstå, udgivelser følger mere ensartede stier, og tilføjelse af endnu et produkt bliver en kontrolleret udvidelse i stedet for endnu en backend, som virksomheden arver på ubestemt tid.
Betragt platformen som en del af produktarkitekturen
Fysiske produkter designes med revisioner, servicevenlighed, fremstillingsevne og fremtidige ændringer i tankerne. Forbundne produkter kræver den samme disciplin på softwaresiden.
Den første backend kan være midlertidig. Det samme kan det første provisioneringsscript eller supportværktøj. Der er intet iboende galt med det. Problemerne begynder, når disse midlertidige mekanismer stille og roligt bliver til permanent arkitektur, mens selve produktet fortsætter med at udvikle sig.
På det tidspunkt er det forbundne produkt ikke længere bare hardware, firmware og en app. Det afhænger også af den infrastruktur, der identificerer hver enhed, forstår dens funktioner, anvender den rigtige konfiguration, understøtter opdateringer og hjælper teams med at diagnosticere problemer år efter forsendelse.
Når dette lag behandles som produktarkitektur, bliver opdelingen tydeligere: standardmekanikker forbliver genbrugelige, mens brugerdefineret arbejde handler om, hvad der rent faktisk adskiller et produkt eller en produktfamilie fra et andet.
Den stærkeste platform er ikke blot den, der gør det første forbundne produkt muligt. Det er den, der lader ingeniørteamet bygge det andet, tredje og fjerde uden at arve en ny backend hver gang.
