Pripojený produkt môže vyzerať dokončený dávno predtým, ako je dokončené inžinierstvo okolo neho. Prototyp je stabilný, dáta sa dostanú do cloudu, aplikácia zobrazuje správne hodnoty a prvá várka zariadení je už v rukách používateľov. V tomto bode môže byť backend stále dostatočne jednoduchý na to, aby tím poznal takmer každé zariadenie jednotlivo. Zriaďovanie je možné spravovať pomocou skriptu, zmeny konfigurácie je možné vykonávať manuálne a ak niečo zlyhá, inžinier môže zvyčajne problém priamo vysledovať.
Potom musí začať žiť v reálnom svete. Objaví sa druhá hardvérová revízia. Niektorí zákazníci stále používajú prvú revíziu. Verzie firmvéru sa začínajú líšiť. Pre iného zákazníka alebo trh je potrebná nová konfigurácia, zatiaľ čo staršie zariadenia stále potrebujú aktualizácie a podporu.
Nič nie je nevyhnutne pokazené. Softvér, ktorý stojí za zariadením, si jednoducho osvojil vlastný životný cyklus.
Tento prechod sa dá ľahko prehliadnuť, pretože prototyp môže naďalej fungovať perfektne. Ale akonáhle v praxi musí koexistovať viacero verzií toho istého fyzického produktu, backend už nie je len infraštruktúrou za hardvérom. Stáva sa súčasťou samotnej architektúry produktu.
Funkčný prepojený prototyp ešte nie je škálovateľný produkt
Prototyp má dôležitú úlohu: dokázať, že systém funguje komplexne. Zariadenie vykonáva svoju základnú funkciu, firmvér komunikuje s backendom, telemetria prichádza tam, kam má, príkazy sa odosielajú späť a mobilné alebo webové rozhranie sprístupňuje funkcionalitu používateľovi.
Čo sa zvyčajne nepreukázalo, je to, ako dobre ten istý systém zvláda rozmanitosť.
Prvých dvadsať zariadení môže používať rovnaký firmvér, byť postavených na rovnakej hardvérovej verzii a konfigurovaných rovnakými inžiniermi. V tejto fáze môže byť manuálna registrácia, priame zmeny konfigurácie alebo malý úvodný skript úplne rozumný. Vytváranie nástrojov produkčnej úrovne skôr, ako sa produkt osvedčí, môže byť predčasné.
Rozšírenie mení problém. Zariadenia zostávajú offline, sú nahrádzané, používajú iný firmvér a vyžadujú si rôzne konfigurácie od zákazníka. Podpora musí rozlišovať medzi jednotkou, ktorá nebola nikdy správne nainštalovaná, a jednotkou, ktorá je nesprávne nakonfigurovaná alebo jednoducho nedostupná.
Dlh prototypu často začína takto: nie zlým rozhodnutím, ale dočasným rozhodnutím, ktoré zostáva v platnosti aj po tom, čo sa produkt presunie na ďalšiu úroveň. A jednou z prvých vecí, ktoré tento prechod vynútia, je samotný hardvér. Nová revízia nielenže nahradí starú; musí s ňou koexistovať.
Každá revízia hardvéru vytvára problém so životným cyklom softvéru
Nová hardvérová revízia zriedkakedy prichádza ako čistá náhrada za starú. V praxi obe verzie zostávajú v prevádzke, niekedy aj roky. Pridajte prechodnú dávku, niekoľko vetiev firmvéru a konfigurácie špecifické pre zákazníka a flotila sa rýchlo stane rozmanitejšou, než naznačuje pôvodný model produktu.
Softvérová vrstva už nemôže považovať každú jednotku za abstraktné „zariadenie“. Potrebuje vedieť, čo je daná konkrétna jednotka schopná robiť.
Revidovaná doska môže používať iný senzor, komunikačný modul alebo ovládač. Príkaz, ktorý je platný pre najnovšiu verziu, nemusí byť podporovaný staršou verziou. Kalibračné hodnoty sa môžu zmeniť. Konfiguračné limity sa môžu posunúť. Balík firmvéru vhodný pre jednu generáciu môže byť nebezpečný pre inú.
Inžinieri fyzických produktov už pracujú týmto spôsobom. Dva komponenty, ktoré vyzerajú takmer identicky, nie sú zameniteľné, ak sa líšia ich revízie, tolerancie alebo špecifikácie. Prepojené produkty vytvárajú rovnaký problém na strane softvéru: platforma potrebuje spoľahlivý spôsob, ako pochopiť, s ktorou verziou fyzického produktu komunikuje a aké pravidlá sa na ňu vzťahujú.
Predstavte si produkt, ktorého prvá revízia používa jeden kalibračný postup, zatiaľ čo druhá zavádza nový senzor a inú sadu parametrov. Pre zákazníka môžu byť obe jednotky stále rovnakým produktom. Pre platformu to tak byť nemôže.
Ak tieto rozdiely nie sú explicitne reprezentované, majú tendenciu prenikať do logiky aplikácie ako špeciálne prípady. Jeden pracovný postup kontroluje rozsah sériových čísel. Iný používa verziu firmvéru ako zástupcu pre generovanie hardvéru. Tretí obsahuje výnimku pridanú po tom, čo podpora zistila, že staršia dávka sa v praxi správala inak. Žiadna z týchto opráv sama o sebe nevyzerá obzvlášť nebezpečne, ale spolu sťažujú uvažovanie o každej budúcej zmene.
Starší hardvér zriedkakedy zmizne podľa plánu. Produktové tímy sa prirodzene zameriavajú na najnovšie revízie, zatiaľ čo zákazníci si často ponechávajú staršie verzie oveľa dlhšie, ako sa očakávalo. Platforma preto musí podporovať niekoľko generácií naraz, a nie predpokladať, že nainštalovaná základňa sa niekedy zblíži k jednému aktuálnemu stavu.
Keď sa to stane, vývoj hardvéru a správa životného cyklu softvéru sa stanú neoddeliteľnými. Platforma potrebuje vedieť nielen to, kde sa zariadenie nachádza a či je online, ale aj čo to je, čo na ňom môže bežať, ako by malo byť nakonfigurované a ktoré zmeny je bezpečné použiť.
A predtým, ako bude možné na ktorúkoľvek z týchto otázok spoľahlivo odpovedať, musí každé zariadenie vstúpiť do systému konzistentným spôsobom.
Zriaďovanie je miesto, kde manuálne inžinierstvo zastavuje škálovanie
Zriaďovanie vyzerá jednoducho, keď je flotila zariadení malá: vytvorte záznam zariadenia, zadajte sériové číslo, vygenerujte prihlasovacie údaje, priraďte jednotku zákazníkovi, použite konfiguráciu a pokračujte ďalej. Pre niekoľko desiatok zariadení môže byť manuálna manipulácia s časťou tejto činnosti stále tou správnou voľbou.
V produkčnom meradle sa však zriaďovanie nachádza na priesečníku identity zariadenia, poverení, vlastníctva, konfigurácie a stavu životného cyklu. Chyba urobená počas nasadenia môže ovplyvniť spôsob prevádzky a podpory zariadenia dlho po opustení továrne.
Tabuľka sa už nemusí zhodovať s tým, čo je skutočne nainštalované. Náhradné zariadenie potrebuje správne priradenie zákazníka bez toho, aby zdedilo nesprávnu identitu. Obnovenie továrenských nastavení vytvára ďalšiu cestu v procese. Inštalatér môže priradiť jednotku k nesprávnemu účtu a ponechať na podpore, aby určila, či je offline, nesprávne nastavená alebo jednoducho má nesprávnu konfiguráciu.
Keď zodpovedanie týchto otázok bežne vyžaduje, aby vývojár skontroloval databázu alebo spustil interný skript, proces sa prestal škálovať spolu s produktom.
Ďalším varovným signálom je duplikácia. Každý variant produktu si začína vytvárať vlastný onboardingový skript, konfiguračný nástroj alebo pracovný postup inštalátora. Tieto rozdiely sa môžu zdať malé, ale základná zodpovednosť je rovnaká. Poskytovanie sa stalo opakovane použiteľnou infraštruktúrou platformy, a nie len úlohou nastavenia pripojenou ku konkrétnemu zariadeniu.
A zriedkakedy je to jediná schopnosť, ktorú je potrebné znova použiť.
Vrstva platformy by sa mala stať opätovne použiteľnou infraštruktúrou
Keď niekoľko produktov alebo hardvérových revízií zdieľa rovnaké základné potreby, niektoré softvérové funkcie prestávajú byť špecifické pre daný produkt. Dobrými príkladmi sú identita zariadenia, poskytovanie, pripojenie, telemetria, dodávanie firmvéru, stav životného cyklu, prehľad o flotile a diagnostika. Ich opätovné zostavenie pre každý nový variant vytvára viac kódu a viac operačných ciest na údržbu bez toho, aby sa samotný produkt stal jedinečnejším.
Tímy sa len zriedka pustia do vytvárania tejto duplicity. Malé rozdiely sa hromadia okolo každého produktu, až kým tím neudržiava niekoľko implementácií toho, čo sa stalo tou istou inžinierskou zodpovednosťou.
Jasnejšia hranica spočíva v oddelení vrstvy produktu od vrstvy platformy. Vrstva produktu obsahuje správanie, pracovné postupy, rozhrania, integrácie a logiku domény, vďaka ktorým je konkrétne zariadenie cenné. Vrstva platformy sa zaoberá mechanikou, ktorá by mala zostať konzistentná aj pri zmene hardvéru.
Keďže pripojené produkty prekračujú hranice svojho prvého vydania, poskytovanie zariadení, správa životného cyklu zariadení, správa vozového parku a podporné nástroje sa stávajú zdieľanou infraštruktúrou, a nie len jednorazovými detailmi projektu. IoT PaaS pre podniky môže poskytnúť túto opakovane použiteľnú vrstvu platformy naprieč viacerými produktmi alebo variantmi produktov, pričom spravuje štandardnú správu zariadení a údajov prostredníctvom opakovane použiteľných stavebných blokov, zatiaľ čo inžinierske tímy sa zameriavajú na hardvér, pracovné postupy a používateľskú skúsenosť.
Spoločný základ musí stále ponechať priestor pre skutočné rozdiely medzi produktmi. Nové zariadenie môže vyžadovať iný dátový model, konfiguračný tok, integráciu alebo riadiacu logiku a tieto rozdiely by mali zostať ľahko zavádzateľné. Cieľom je jednoducho vyhnúť sa tomu, aby sa každý rozdiel ťahal za ďalší register zariadení, telemetrický kanál, mechanizmus poskytovania alebo sadu nástrojov na správu vozového parku.
Platforma sa môže zdať ako nadštandardná, kým tím vytvára prvý produkt, a ako aktívum pri druhom alebo treťom. Keď sú zavedené spoločné prevádzkové mechanizmy, nový variant môže zdediť funkčný základ namiesto toho, aby prišiel s ďalším backendom, ktorý bude musieť tím udržiavať po zvyšok životnosti daného produktu.
Zachovajte zákazkové inžinierstvo tam, kde je produkt skutočne odlišný
Opakovane použiteľná platforma by nemala robiť prepojené produkty generickejšími. Jej úlohou je odstrániť opakované inžinierstvo z častí, ktoré nevytvárajú diferenciáciu.
Úsilie o prispôsobenie sa stále týka správania zariadení, logiky špecifickej pre danú doménu, pracovných postupov, používateľskej skúsenosti, špecializovaných integrácií a spôsobu, akým konkrétny produkt interaguje s fyzickým svetom. To sú presne tie oblasti, kde môžu technické rozhodnutia výrazne zlepšiť jeden produkt oproti inému.
Čo si zriedkakedy zaslúži rovnaké zaobchádzanie, je okolité prevádzkové potrubie. Základná verzia a priemyselná verzia toho istého stroja môžu vyžadovať odlišné senzory, ovládacie prvky a rozhrania, ale nemali by vyžadovať samostatné spôsoby identifikácie zariadení, sledovania verzií firmvéru alebo správy flotily zariadení.
Radšej by som videl, ako inžinieri strávia ten čas zdokonaľovaním správania produktu v praxi, než prestavovaním mechaník, ktoré tím už má zavedené pre iný produkt. Spoločný základ neznižuje možnosti pre zákazkové inžinierstvo; chráni toto úsilie pred tým, aby ho spotrebovala infraštruktúra.
Skutočná skúška prichádza, keď tím začne s produktom číslo dva.
Dobrá platforma uľahčuje vývoj ďalšieho produktu ako prvého.
Ak produkt číslo dva vyžaduje takmer rovnakú prácu na platforme ako produkt číslo jeden, v skutočnosti sa toho opätovne použilo len veľmi málo.
Nový variant by mal byť schopný zdediť časti operačného modelu, ktoré sa nezmenili: postupy poskytovania, identitu, mechanizmy životného cyklu, nástroje pre flotilu, procesy firmvéru, prehľad o podpore a bežné integrácie. Inžinierske úsilie sa potom zameriava na rozdiely – možno nový balík senzorov, iný pracovný postup riadenia alebo integráciu špecifickú pre zákazníka – namiesto rekonštrukcie základov.
Nová generácia hardvéru vyvíja rovnakú myšlienku pod väčší tlak. Jeho možnosti sa môžu podstatne zmeniť, zatiaľ čo staršie jednotky zostanú aktívne v praxi. Vyspelá platforma dokáže podporovať obe bez toho, aby nútila tím udržiavať dva samostatné platformové balíky pre to, čo zákazníci stále vnímajú ako jednu produktovú rodinu.
Nič z toho si nevyžaduje jeden monolitický backend. Rôzne produkty môžu stále potrebovať jasné architektonické hranice. Dôležité je vyhnúť sa druhej implementácii tej istej inžinierskej zodpovednosti bez dobrého dôvodu.
Vtedy sa platforma stáva skôr aktívom ako nahromadenými réžiami. Podpora má menej paralelných nástrojov, ktorým musí rozumieť, vydania sa vydávajú konzistentnejšie a pridanie ďalšieho produktu sa stáva kontrolovaným rozšírením namiesto ďalšieho backendu, ktorý spoločnosť dedí na neurčito.
Zaobchádzajte s platformou ako so súčasťou architektúry produktu
Fyzické produkty sú navrhnuté s ohľadom na revízie, prevádzkyschopnosť, vyrobiteľnosť a budúce zmeny. Pripojené produkty vyžadujú rovnakú disciplínu na strane softvéru.
Prvý backend môže byť dočasný. Rovnako tak aj prvý skript na poskytovanie služieb alebo podporný nástroj. Na tom nie je nič inherentne zlé. Problémy začínajú, keď sa tieto dočasné mechanizmy potichu stanú trvalou architektúrou, zatiaľ čo samotný produkt sa neustále vyvíja.
Dovtedy už pripojený produkt nie je len hardvér, firmvér a aplikácia. Závisí tiež od infraštruktúry, ktorá identifikuje každé zariadenie, rozumie jeho možnostiam, aplikuje správnu konfiguráciu, podporuje aktualizácie a pomáha tímom diagnostikovať problémy roky po dodaní.
Keď sa táto vrstva začne považovať za architektúru produktu, rozdelenie sa stane jasnejším: štandardné mechaniky zostávajú opakovane použiteľné, zatiaľ čo práca na mieru sa zameria na to, čo skutočne odlišuje jeden produkt alebo produktovú skupinu od druhého.
Najsilnejšia platforma nie je len tá, ktorá umožňuje prvý pripojený produkt. Je to tá, ktorá umožňuje inžinierskemu tímu vytvoriť druhý, tretí a štvrtý produkt bez toho, aby zakaždým zdedil nový backend.
