Propojený produkt může vypadat hotový dlouho předtím, než je dokončeno inženýrství kolem něj. Prototyp je stabilní, data se dostanou do cloudu, aplikace zobrazuje správné hodnoty a první várka zařízení je již v rukou uživatelů. V tomto okamžiku může být backend stále dostatečně jednoduchý, aby tým znál téměř každé zařízení jednotlivě. Zřizování lze řešit pomocí skriptu, změny konfigurace lze provádět ručně a pokud něco selže, technik může problém obvykle přímo vysledovat.
Pak se musí začít používat v reálném světě. Objeví se druhá hardwarová revize. Někteří zákazníci stále používají první revizi. Verze firmwaru se začínají lišit. Pro jiného zákazníka nebo trh je potřeba nová konfigurace, zatímco starší zařízení stále potřebují aktualizace a podporu.
Nic není nutně rozbité. Software, který je za zařízením, si jednoduše získal svůj vlastní životní cyklus.
Tento přechod lze snadno přehlédnout, protože prototyp může i nadále fungovat perfektně. Jakmile ale v praxi musí koexistovat více verzí stejného fyzického produktu, backend už není jen infrastrukturou za hardwarem. Stává se součástí samotné architektury produktu.
Fungující propojený prototyp ještě není škálovatelný produkt.
Prototyp má důležitý úkol: dokázat, že systém funguje od začátku do konce. Zařízení plní svou základní funkci, firmware komunikuje s backendem, telemetrie přichází tam, kam má, příkazy se vracejí zpět a mobilní nebo webové rozhraní zpřístupňuje funkcionalitu uživateli.
Co se obvykle neprokázalo, je to, jak dobře tentýž systém zvládá rozmanitost.
Prvních dvacet zařízení může používat stejný firmware, být postavena na stejné hardwarové revizi a konfigurována stejnými inženýry. V této fázi může být manuální registrace, přímé změny konfigurace nebo malý úvodní skript zcela rozumný. Vytváření nástrojů pro produkční účely dříve, než se produkt osvědčí, může být předčasné.
Měřítko mění problém. Zařízení zůstávají offline, jsou nahrazována, používají jiný firmware a vyžadují jinou zákaznickou konfiguraci. Podpora musí rozlišovat mezi jednotkou, která nebyla nikdy správně zprovozněna, a jednotkou, která je špatně nakonfigurovaná nebo jednoduše nedostupná.
Prototypový dluh často začíná takto: ne špatným rozhodnutím, ale dočasným rozhodnutím, které zůstává v platnosti i poté, co se produkt přesune na jinou úroveň. A jednou z prvních věcí, která tento přechod vynutí, je samotný hardware. Nová revize nejen nahrazuje tu starou; musí s ní koexistovat.
Každá revize hardwaru vytváří problém životního cyklu softwaru
Nová hardwarová revize zřídkakdy přichází jako čistá náhrada za tu starou. V praxi obě verze zůstávají v provozu, někdy i roky. Přidejte přechodovou dávku, několik větví firmwaru a konfigurace specifické pro zákazníka a flotila se rychle stane rozmanitější, než naznačuje původní model produktu.
Softwarová vrstva již nemůže s každou jednotkou zacházet jako s abstraktním „zařízením“. Potřebuje vědět, co daná konkrétní jednotka dokáže.
Revidovaná deska může používat jiný senzor, komunikační modul nebo řadič. Příkaz, který je platný pro nejnovější verzi, nemusí být podporován starší verzí. Kalibrační hodnoty se mohou změnit. Konfigurační limity se mohou posunout. Firmware vhodný pro jednu generaci může být pro jinou nebezpečný.
Inženýři fyzických produktů již tímto způsobem pracují. Dvě komponenty, které vypadají téměř identicky, nejsou zaměnitelné, pokud se liší jejich revize, tolerance nebo specifikace. Propojené produkty vytvářejí na straně softwaru stejný problém: platforma potřebuje spolehlivý způsob, jak pochopit, s jakou verzí fyzického produktu komunikuje a jaká pravidla se na ni vztahují.
Představte si produkt, jehož první revize používá jeden kalibrační postup, zatímco druhá zavádí nový senzor a jinou sadu parametrů. Pro zákazníka mohou být obě jednotky stále stejným produktem. Pro platformu to tak být nemohou.
Pokud tyto rozdíly nejsou explicitně reprezentovány, mají tendenci pronikat do aplikační logiky jako speciální případy. Jeden pracovní postup kontroluje rozsah sériových čísel. Jiný používá verzi firmwaru jako zástupce pro generování hardwaru. Třetí obsahuje výjimku přidanou poté, co podpora zjistila, že starší dávka se v praxi chová odlišně. Žádná z těchto oprav sama o sobě nevypadá nijak zvlášť nebezpečně, ale společně ztěžují zdůvodnění každé budoucí změny.
Starší hardware jen zřídka mizí včas. Produktové týmy se přirozeně zaměřují na nejnovější revize, zatímco zákazníci si starší verze často ponechávají mnohem déle, než se očekávalo. Platforma proto musí podporovat několik generací najednou, spíše než předpokládat, že se instalovaná základna někdy sblíží s jedním aktuálním stavem.
Jakmile k tomu dojde, vývoj hardwaru a správa životního cyklu softwaru se stanou neoddělitelnými. Platforma potřebuje vědět nejen, kde se zařízení nachází a zda je online, ale také co to je, co na něm může běžet, jak by mělo být nakonfigurováno a které změny je bezpečné použít.
A než bude možné na kteroukoli z těchto otázek spolehlivě odpovědět, musí každé zařízení do systému vstoupit konzistentním způsobem.
Zřizování je místo, kde manuální inženýrství zastavuje škálování
Zřizování se zdá být jednoduché, když je flotila zařízení malá: vytvořit záznam o zařízení, zadat sériové číslo, vygenerovat přihlašovací údaje, přiřadit jednotku zákazníkovi, použít konfiguraci a jít dál. U několika desítek zařízení může být ruční zpracování některých z těchto činností stále správnou volbou.
V produkčním měřítku se však zřizování nachází na průsečíku identity zařízení, přihlašovacích údajů, vlastnictví, konfigurace a stavu životního cyklu. Chyba způsobená během zavádění může ovlivnit provoz a podporu jednotky dlouho poté, co opustí továrnu.
Tabulka se již nemusí shodovat s tím, co je skutečně nainstalováno. Náhradní zařízení potřebuje správné přidružení zákazníka, aniž by zdědilo nesprávnou identitu. Obnovení továrního nastavení vytváří další cestu procesem. Instalační technik může přiřadit jednotku k nesprávnému účtu a ponechat na podpoře, aby určila, zda je offline, nesprávně zprovozněna nebo jednoduše obsahuje nesprávnou konfiguraci.
Jakmile zodpovězení těchto otázek rutinně vyžaduje, aby vývojář prozkoumal databázi nebo spustil interní skript, proces se s produktem přestal škálovat.
Dalším varovným signálem je duplikace. Každá varianta produktu si začíná vytvářet vlastní onboardingový skript, konfigurační nástroj nebo instalační postup. Tyto rozdíly se mohou zdát malé, ale základní odpovědnost je stejná. Zřizování se stalo opakovaně použitelnou infrastrukturou platformy, nikoliv instalačním úkolem připojeným ke konkrétnímu zařízení.
A jen zřídka je to jediná schopnost, kterou je třeba znovu použít.
Vrstva platformy by se měla stát znovu použitelnou infrastrukturou
Jakmile několik produktů nebo hardwarových revizí sdílí stejné základní požadavky, některé softwarové funkce přestávají být specifické pro daný produkt. Dobrými příklady jsou identita zařízení, zřizování, konektivita, telemetrie, dodávání firmwaru, stav životního cyklu, přehled o vozovém parku a diagnostika. Jejich opětovné sestavení pro každou novou variantu vytváří více kódu a více provozních cest k údržbě, aniž by samotný produkt byl čímkoli odlišnější.
Týmy se jen zřídka snaží o vytvoření této duplicity. Kolem každého produktu se hromadí malé rozdíly, dokud tým nezačne spravovat několik implementací toho, co se stalo stejnou technickou odpovědností.
Jasnější hranicí je oddělení vrstvy produktu od vrstvy platformy. Vrstva produktu obsahuje chování, pracovní postupy, rozhraní, integrace a logiku domény, díky nimž je konkrétní zařízení cenné. Vrstva platformy se stará o mechaniku, která by měla zůstat konzistentní i při změně hardwaru.
S tím, jak se propojené produkty vyvíjejí po svém prvním vydání, se zřizování zařízení, správa životního cyklu zařízení, správa vozového parku a podpůrné nástroje stávají sdílenou infrastrukturou, nikoli jen jednorázovými detaily projektu. IoT PaaS pro podniky může poskytnout tuto opakovaně použitelnou vrstvu platformy napříč více produkty nebo variantami produktů a zvládat správu standardních zařízení a dat prostřednictvím opakovaně použitelných stavebních bloků, zatímco technické týmy se zaměřují na hardware, pracovní postupy a uživatelskou zkušenost.
Společný základ musí stále ponechat prostor pro skutečné rozdíly mezi produkty. Nové zařízení může vyžadovat jiný datový model, konfigurační tok, integraci nebo řídicí logiku a tyto rozdíly by měly být snadno zaváděny. Cílem je jednoduše zabránit tomu, aby se každý rozdíl táhl s sebou další registr zařízení, telemetrický kanál, mechanismus zřizování nebo sadu nástrojů pro správu vozového parku.
Platforma se může jevit jako nadbytečná, když tým vytváří první produkt, a u druhého nebo třetího jako aktivum. Jakmile jsou zavedeny běžné provozní mechanismy, může nová varianta zdědit funkční základ, místo aby přišla s dalším backendem, který bude muset tým udržovat po zbytek životnosti daného produktu.
Zachovat zakázkové inženýrství tam, kde se produkt skutečně liší
Znovupoužitelná platforma by neměla propojené produkty dělat obecnějšími. Jejím úkolem je odstranit opakované inženýrství z částí, které nevytvářejí odlišnost.
Úsilí o zakázkovou úpravu stále patří do oblasti chování zařízení, logiky specifické pro danou doménu, pracovních postupů, uživatelské zkušenosti, specializovaných integrací a způsobu, jakým konkrétní produkt interaguje s fyzickým světem. To jsou přesně ty oblasti, kde mohou technické volby jeden produkt významně zlepšit oproti jinému.
Co si jen zřídka zaslouží stejné zacházení, je okolní provozní potrubí. Základní verze a průmyslová verze stejného stroje mohou vyžadovat různé senzory, ovládací prvky a rozhraní, ale neměly by vyžadovat oddělené způsoby identifikace zařízení, sledování verzí firmwaru nebo správy vozového parku.
Raději bych viděl, jak inženýři tráví ten čas zdokonalováním chování produktu v praxi, než přestavováním mechanismů, které tým již má zavedené pro jiný produkt. Společný základ neomezuje prostor pro zakázkové inženýrství; chrání toto úsilí před tím, aby bylo spotřebováno infrastrukturou.
Skutečná zkouška přichází, když tým začne s produktem číslo dvě.
Dobrá platforma usnadňuje tvorbu dalšího produktu než prvního.
Pokud produkt číslo dva vyžaduje téměř stejnou práci na platformě jako produkt číslo jedna, bylo ve skutečnosti znovu použito jen velmi málo.
Nová varianta by měla být schopna zdědit části provozního modelu, které se nezměnily: procesy zřizování, identitu, mechanismy životního cyklu, nástroje pro vozový park, procesy firmwaru, přehled o podpoře a společné integrace. Inženýrské úsilí se pak zaměřuje na rozdíly – možná nový balíček senzorů, jiný řídicí pracovní postup nebo integraci specifickou pro zákazníka – namísto rekonstrukce základů.
Nová generace hardwaru vyvíjí stejnou myšlenku pod větší tlak. Její schopnosti se mohou podstatně změnit, zatímco starší jednotky zůstanou v provozu. Vyspělá platforma může podporovat obojí, aniž by nutila tým udržovat dva oddělené platformy pro to, co zákazníci stále vnímají jako jednu produktovou řadu.
Nic z toho nevyžaduje jeden monolitický backend. Různé produkty mohou stále vyžadovat jasné architektonické hranice. Důležité je vyhnout se druhé implementaci stejné inženýrské odpovědnosti bez dobrého důvodu.
Tehdy se platforma stává spíše aktivem než nahromaděnými režijními náklady. Podpora má méně paralelních nástrojů k pochopení, vydání se řídí konzistentnějšími cestami a přidání dalšího produktu se stává kontrolovaným rozšířením namísto dalšího backendu, který společnost dědí na dobu neurčitou.
Považujte platformu za součást architektury produktu
Fyzické produkty jsou navrhovány s ohledem na revize, provozuschopnost, vyrobitelnost a budoucí změny. Propojené produkty vyžadují stejnou disciplínu na straně softwaru.
První backend může být dočasný. Stejně tak první zřizovací skript nebo podpůrný nástroj. Na tom není nic inherentně špatného. Problémy začínají, když se tyto dočasné mechanismy tiše stanou trvalou architekturou, zatímco samotný produkt se dále vyvíjí.
V té době už připojený produkt není jen hardware, firmware a aplikace. Záleží také na infrastruktuře, která identifikuje každé zařízení, rozumí jeho možnostem, aplikuje správnou konfiguraci, podporuje aktualizace a pomáhá týmům diagnostikovat problémy i roky po dodání.
Jakmile je tato vrstva považována za architekturu produktu, rozdělení se stane jasnějším: standardní mechaniky zůstávají opakovaně použitelné, zatímco zakázková práce se zaměřuje na to, co skutečně odlišuje jeden produkt nebo produktovou řadu od druhého.
Nejsilnější platforma není jen ta, která umožňuje vznik prvního propojeného produktu. Je to ta, která umožňuje inženýrskému týmu postavit druhý, třetí a čtvrtý produkt, aniž by pokaždé zdědil nový backend.
