Et tilkoblet produkt kan se ferdig ut lenge før prosjekteringen rundt det er fullført. Prototypen er stabil, dataene når skyen, appen viser de riktige verdiene, og den første gruppen med enheter er allerede i brukernes hender. På det tidspunktet kan backend-systemet fortsatt være enkelt nok til at teamet kjenner nesten hver enhet individuelt. Provisionering kan håndteres med et skript, konfigurasjonsendringer kan gjøres manuelt, og hvis noe feiler, kan en ingeniør vanligvis spore problemet direkte.
Så må den begynne å leve i den virkelige verden. En andre maskinvarerevisjon dukker opp. Noen kunder bruker fortsatt den første revisjonen. Fastvareversjoner begynner å avvike. En ny konfigurasjon er nødvendig for en annen kunde eller et annet marked, mens eldre enheter fortsatt trenger oppdateringer og støtte.
Ingenting er nødvendigvis ødelagt. Programvaren bak enheten har rett og slett fått sin egen livssyklus.
Den overgangen er lett å overse fordi prototypen kan fortsette å fungere perfekt. Men når flere versjoner av det samme fysiske produktet må sameksistere i felten, er ikke lenger backend bare infrastruktur bak maskinvaren. Det blir en del av selve produktarkitekturen.
En fungerende tilkoblet prototype er ennå ikke et skalerbart produkt
En prototype har en viktig oppgave: å bevise at systemet fungerer fra ende til annen. Enheten utfører sin kjernefunksjon, fastvaren kommuniserer med backend-systemet, telemetri kommer dit den skal, kommandoer foretar returreisen, og et mobil- eller webgrensesnitt eksponerer funksjonaliteten for en bruker.
Det det vanligvis ikke har bevist, er hvor godt det samme systemet håndterer variasjon.
De første tjue enhetene kan kjøre samme firmware, være bygget med samme maskinvarerevisjon og konfigureres av de samme ingeniørene. På det stadiet kan manuell registrering, direkte konfigurasjonsendringer eller et lite onboarding-skript være helt fornuftig. Det kan være for tidlig å bygge verktøy i produksjonsklassen før produktet har bevist sin verdi.
Skalering endrer problemet. Enheter forblir offline, blir erstattet, kjører ulik fastvare og krever forskjellige kundekonfigurasjoner. Kundestøtte må skille mellom en enhet som aldri ble riktig klargjort og en som er feilkonfigurert eller rett og slett ikke kan nås.
Prototypgjeld starter ofte slik: ikke med en dårlig avgjørelse, men med en midlertidig avgjørelse som forblir på plass etter at produktet har gått videre. Og en av de første tingene som tvinger frem denne overgangen er selve maskinvaren. En ny revisjon erstatter ikke bare den gamle; den må sameksistere med den.
Hver maskinvarerevisjon skaper et problem med programvarens livssyklus
En ny maskinvarerevisjon kommer sjelden som en ren erstatning for den gamle. I praksis forblir begge versjonene i felten, noen ganger i årevis. Legg til en overgangsbatch, noen få firmwaregrener og kundespesifikke konfigurasjoner, og flåten blir raskt mer mangfoldig enn den opprinnelige produktmodellen antyder.
Programvarelaget kan ikke lenger behandle hver enhet som en abstrakt «enhet». Det må vite hva den bestemte enheten er i stand til å gjøre.
Et revidert kort kan bruke en annen sensor, kommunikasjonsmodul eller kontroller. En kommando som er gyldig for den nyeste versjonen støttes kanskje ikke av en tidligere versjon. Kalibreringsverdier kan endres. Konfigurasjonsgrenser kan forskyves. En fastvarepakke som er egnet for én generasjon, kan være usikker for en annen.
Ingeniører innen fysiske produkter jobber allerede på denne måten. To komponenter som ser nesten identiske ut, er ikke utskiftbare hvis revisjonene, toleransene eller spesifikasjonene deres er forskjellige. Tilkoblede produkter skaper det samme problemet på programvaresiden: plattformen trenger en pålitelig måte å forstå hvilken versjon av det fysiske produktet den snakker med og hvilke regler som gjelder for det.
Tenk deg et produkt der den første revisjonen bruker én kalibreringsprosedyre, mens den andre introduserer en ny sensor og et annet sett med parametere. For kunden kan begge enhetene fortsatt være det samme produktet. For plattformen kan de ikke være det.
Hvis disse forskjellene ikke er representert eksplisitt, har de en tendens til å lekke inn i applikasjonslogikken som spesialtilfeller. Én arbeidsflyt sjekker et serienummerområde. En annen bruker en fastvareversjon som en proxy for maskinvaregenerering. En tredje inneholder et unntak lagt til etter at support oppdaget at en eldre batch oppførte seg annerledes i felten. Ingen av disse rettelsene ser spesielt farlige ut i seg selv, men sammen gjør de enhver fremtidig endring vanskeligere å resonnere rundt.
Eldre maskinvare forsvinner sjelden etter planen. Produktteam fokuserer naturlig nok på den nyeste revisjonen, mens kunder ofte beholder tidligere versjoner mye lenger enn forventet. Plattformen må derfor støtte flere generasjoner samtidig i stedet for å anta at den installerte basen noen gang vil samles mot en enkelt nåværende tilstand.
Når det skjer, blir maskinvareutvikling og programvarens livssyklushåndtering uatskillelige. Plattformen trenger ikke bare å vite hvor en enhet er og om den er online, men også hva den er, hva den kan kjøre, hvordan den skal konfigureres og hvilke endringer som er trygge å implementere.
Og før noen av disse spørsmålene kan besvares pålitelig, må hver enhet legges inn i systemet på en konsistent måte.
Provisionering er der manuell konstruksjon stopper skalering
Klargjøring ser enkelt ut når flåten er liten: opprett en enhetsoppføring, skriv inn et serienummer, generer påloggingsinformasjon, tilordne enheten til en kunde, bruk en konfigurasjon og fortsett. For noen få dusin enheter kan det fortsatt være det riktige valget å håndtere noe av dette manuelt.
I produksjonsskala ligger imidlertid klargjøring i skjæringspunktet mellom enhetsidentitet, påloggingsinformasjon, eierskap, konfigurasjon og livssyklusstatus. En feil som gjøres under onboarding kan påvirke hvordan enheten drives og støttes lenge etter at den forlater fabrikken.
Et regneark samsvarer kanskje ikke lenger med det som faktisk er installert. En erstatningsenhet trenger riktig kundetilknytning uten å arve feil identitet. Tilbakestillinger til fabrikkinnstillinger oppretter en ny vei gjennom prosessen. En installatør kan tilordne en enhet til feil konto, slik at det blir opp til kundestøtte å avgjøre om den er frakoblet, feil klargjort eller rett og slett har feil konfigurasjon.
Når det rutinemessig krever at en utvikler inspiserer en database eller kjører et internt skript for å svare på disse spørsmålene, har prosessen sluttet å skalere med produktet.
Duplisering er et annet varseltegn. Hver produktvariant begynner å få sitt eget onboarding-skript, konfigurasjonsverktøy eller installasjonsarbeidsflyt. Disse forskjellene kan se små ut, men det underliggende ansvaret er det samme. Provisionering har blitt en gjenbrukbar plattforminfrastruktur i stedet for en oppsettoppgave knyttet til en bestemt enhet.
Og det er sjelden den eneste funksjonen som må kunne gjenbrukes.
Plattformlaget bør bli gjenbrukbar infrastruktur
Når flere produkter eller maskinvarerevisjoner deler de samme grunnleggende behovene, slutter noen programvarefunksjoner å være produktspesifikke. Enhetsidentitet, klargjøring, tilkobling, telemetri, fastvarelevering, livssyklusstatus, flåtesynlighet og diagnostikk er gode eksempler. Å gjenoppbygge dem for hver ny variant skaper mer kode og flere driftsbaner å vedlikeholde uten at selve produktet blir mer særegent.
Teamene setter seg sjelden i kast med å skape denne dupliseringen. Små forskjeller akkumuleres rundt hvert produkt inntil teamet vedlikeholder flere implementeringer av det som har blitt det samme ingeniøransvaret.
En renere grense er å skille produktlaget fra plattformlaget. Produktlaget inneholder oppførselen, arbeidsflytene, grensesnittene, integrasjonene og domenelogikken som gjør en bestemt enhet verdifull. Plattformlaget håndterer mekanikk som bør forbli konsistent selv om maskinvaren endres.
Etter hvert som tilkoblede produkter går utover sin første utgivelse, blir enhetsklargjøring, enhetslivssyklusadministrasjon, flåteadministrasjon og støtteverktøy delt infrastruktur i stedet for engangsprosjektdetaljer. En IoT PaaS for bedrifter kan tilby det gjenbrukbare plattformlaget på tvers av flere produkter eller produktvarianter, og håndtere standard enhets- og dataadministrasjon gjennom gjenbrukbare byggeklosser mens ingeniørteamene holder sin tilpassede innsats fokusert på maskinvare, arbeidsflyter og brukeropplevelse.
Et felles fundament må fortsatt gi rom for reelle produktforskjeller. En ny enhet kan trenge en annen datamodell, konfigurasjonsflyt, integrasjon eller kontrolllogikk, og disse forskjellene bør forbli enkle å introdusere. Målet er ganske enkelt å unngå at enhver forskjell drar med seg et annet enhetsregister, telemetri-pipeline, provisjonsmekanisme eller sett med verktøy for flåtestyring.
Plattformen kan virke som en overheadkostnad mens teamet bygger det første produktet, og som en ressurs når det andre eller tredje produktet er på plass. Når de vanlige driftsmekanikkene er på plass, kan en ny variant arve et fungerende fundament i stedet for å komme med en annen backend som teamet må vedlikeholde resten av produktets levetid.
Behold tilpasset konstruksjon der produktet faktisk er annerledes
En gjenbrukbar plattform bør ikke gjøre tilkoblede produkter mer generiske. Dens jobb er å fjerne gjentatt konstruksjon fra delene som ikke skaper differensiering.
Tilpasset innsats hører fortsatt hjemme i enhetsatferd, domenespesifikk logikk, arbeidsflyter, brukeropplevelse, spesialiserte integrasjoner og måten et bestemt produkt samhandler med den fysiske verden på. Det er nettopp disse områdene der tekniske valg kan gjøre ett produkt betydelig bedre enn et annet.
Det som sjelden fortjener samme behandling er rørleggerarbeidet rundt maskinen. En basisversjon og en industriell versjon av samme maskin kan trenge forskjellige sensorer, kontroller og grensesnitt, men de bør ikke kreve separate måter å identifisere enheter, spore firmwareversjoner eller administrere en maskinpark.
Jeg vil heller se at ingeniører bruker den tiden på å forbedre hvordan produktet oppfører seg i felten enn å gjenoppbygge mekanikken teamet allerede har på plass for et annet produkt. Et felles fundament reduserer ikke muligheten for tilpasset konstruksjon; det beskytter den innsatsen fra å bli slukt av infrastruktur.
Den virkelige testen kommer når teamet starter produkt nummer to.
En god plattform gjør det neste produktet enklere enn det første
Hvis produkt nummer to krever nesten det samme plattformarbeidet som produkt nummer én, er det faktisk svært lite som har blitt gjenbrukt.
En ny variant bør kunne arve de delene av driftsmodellen som ikke har endret seg: klargjøringsflyter, identitet, livssyklusmekanikk, flåteverktøy, fastvareprosesser, støttesynlighet og felles integrasjoner. Ingeniørarbeidet går deretter inn på forskjellene – kanskje en ny sensorpakke, en annen kontrollarbeidsflyt eller en kundespesifikk integrasjon – i stedet for å rekonstruere grunnlaget.
En ny maskinvaregenerasjon setter den samme ideen under mer press. Kapasitetene kan endre seg betydelig mens eldre enheter forblir aktive i feltet. En moden plattform kan støtte begge deler uten å tvinge teamet til å opprettholde to separate plattformstabler for det kundene fortsatt oppfatter som én produktfamilie.
Ingenting av dette krever én monolittisk backend. Ulike produkter kan fortsatt trenge klare arkitektoniske grenser. Det som er viktig er å unngå en andre implementering av det samme ingeniøransvaret uten god grunn.
Det er da plattformen blir en ressurs i stedet for akkumulert overhead. Support har færre parallelle verktøy å forstå, utgivelser følger mer konsistente baner, og det å legge til et nytt produkt blir en kontrollert utvidelse i stedet for enda en backend som selskapet arver på ubestemt tid.
Behandle plattformen som en del av produktarkitekturen
Fysiske produkter utformes med tanke på revisjoner, brukbarhet, produksjonsevne og fremtidige endringer. Tilkoblede produkter trenger samme disiplin på programvaresiden.
Den første backend-funksjonen kan være midlertidig. Det samme kan det første provisjoneringsskriptet eller støtteverktøyet. Det er ingenting galt med det. Problemer begynner når disse midlertidige mekanikkene stille og rolig blir permanent arkitektur mens selve produktet fortsetter å utvikle seg.
Da er ikke det tilkoblede produktet lenger bare maskinvare, fastvare og en app. Det er også avhengig av infrastrukturen som identifiserer hver enhet, forstår dens funksjoner, bruker riktig konfigurasjon, støtter oppdateringer og hjelper team med å diagnostisere problemer år etter forsendelse.
Når det laget behandles som produktarkitektur, blir inndelingen tydeligere: standardmekanikk forblir gjenbrukbar, mens tilpasset arbeid går inn på hva som faktisk skiller ett produkt eller en produktfamilie fra et annet.
Den sterkeste plattformen er ikke bare den som gjør det første tilkoblede produktet mulig. Det er den som lar ingeniørteamet bygge det andre, tredje og fjerde uten å arve en ny backend hver gang.
