Povezani proizvod može izgledati završeno mnogo prije nego što je inženjering oko njega završen. Prototip je stabilan, podaci stižu u oblak, aplikacija prikazuje ispravne vrijednosti, a prva serija uređaja je već u rukama korisnika. U tom trenutku, backend može još uvijek biti dovoljno jednostavan da tim poznaje gotovo svaki uređaj pojedinačno. Pružanje usluga se može obaviti pomoću skripte, promjene konfiguracije mogu se izvršiti ručno, a ako nešto ne uspije, inženjer obično može direktno pratiti problem.
Zatim mora početi živjeti u stvarnom svijetu. Pojavljuje se druga revizija hardvera. Neki kupci i dalje koriste prvu reviziju. Verzije firmvera počinju se razlikovati. Potrebna je nova konfiguracija za drugog kupca ili tržište, dok starijim uređajima i dalje trebaju ažuriranja i podrška.
Ništa nije nužno pokvareno. Softver iza uređaja je jednostavno stekao vlastiti životni ciklus.
Taj prelaz je lako propustiti jer prototip može nastaviti savršeno dobro raditi. Ali kada više verzija istog fizičkog proizvoda mora koegzistirati na terenu, backend više nije samo infrastruktura iza hardvera. On postaje dio same arhitekture proizvoda.
Funkcionalni povezani prototip još nije skalabilan proizvod
Prototip ima važan zadatak: dokazati da sistem funkcioniše od početka do kraja. Uređaj obavlja svoju osnovnu funkciju, firmver komunicira sa backendom, telemetrija stiže tamo gdje treba, komande se vraćaju, a mobilni ili web interfejs pruža funkcionalnost korisniku.
Ono što obično nije dokazalo jeste koliko dobro isti sistem podnosi raznolikost.
Prvih dvadeset uređaja mogu koristiti isti firmver, biti izgrađeni na istoj reviziji hardvera i konfigurirani od strane istih inženjera. U toj fazi, ručna registracija, direktne promjene konfiguracije ili mali skript za uvođenje u rad mogu biti sasvim razumni. Izrada alata proizvodnog nivoa prije nego što se proizvod dokaže može biti preuranjena.
Skala mijenja problem. Uređaji ostaju van mreže, zamjenjuju se, koriste drugačiji firmver i zahtijevaju različite konfiguracije korisnika. Podrška mora razlikovati jedinicu koja nikada nije ispravno omogućena od one koja je pogrešno konfigurirana ili jednostavno nedostupna.
Dug prototipa često počinje na ovaj način: ne lošom odlukom, već privremenom koja ostaje na snazi nakon što je proizvod prešao na drugu fazu. Jedna od prvih stvari koja prisiljava taj prelaz na vidjelo je sam hardver. Nova revizija ne samo da zamjenjuje staru; ona mora koegzistirati s njom.
Svaka revizija hardvera stvara problem životnog ciklusa softvera
Nova revizija hardvera rijetko dolazi kao čista zamjena za staru. U praksi, obje verzije ostaju na terenu, ponekad i godinama. Dodajte prelaznu seriju, nekoliko grana firmvera i konfiguracije specifične za kupca, i flota brzo postaje raznolikija nego što originalni model proizvoda sugerira.
Softverski sloj više ne može tretirati svaku jedinicu kao apstraktni "uređaj". Potrebno je da zna šta ta određena jedinica može da uradi.
Revidirana ploča može koristiti drugačiji senzor, komunikacijski modul ili kontroler. Komanda koja važi za najnoviju verziju možda nije podržana od strane starije. Vrijednosti kalibracije se mogu promijeniti. Ograničenja konfiguracije se mogu pomjeriti. Paket firmvera pogodan za jednu generaciju može biti nesiguran za drugu.
Inženjeri fizičkih proizvoda već rade na ovaj način. Dvije komponente koje izgledaju gotovo identično nisu zamjenjive ako se njihove revizije, tolerancije ili specifikacije razlikuju. Povezani proizvodi stvaraju isti problem na strani softvera: platformi je potreban pouzdan način da razumije s kojom verzijom fizičkog proizvoda komunicira i koja se pravila na nju primjenjuju.
Razmotrimo proizvod čija prva revizija koristi jednu proceduru kalibracije, dok druga uvodi novi senzor i drugačiji skup parametara. Za kupca, oba uređaja mogu i dalje biti isti proizvod. Za platformu to ne mogu biti.
Ako te razlike nisu eksplicitno predstavljene, one imaju tendenciju da procure u logiku aplikacije kao posebni slučajevi. Jedan tijek rada provjerava raspon serijskih brojeva. Drugi koristi verziju firmvera kao zamjenu za generiranje hardvera. Treći sadrži izuzetak dodan nakon što je podrška otkrila stariju seriju koja se drugačije ponaša na terenu. Nijedna od ovih ispravki ne izgleda posebno opasna sama po sebi, ali zajedno otežavaju svaku buduću promjenu.
Stariji hardver rijetko nestaje na vrijeme. Proizvodni timovi se prirodno fokusiraju na najnoviju reviziju, dok kupci često zadržavaju ranije verzije mnogo duže nego što se očekivalo. Platforma stoga mora podržavati nekoliko generacija odjednom, umjesto da pretpostavlja da će instalirana baza ikada konvergirati na jedno trenutno stanje.
Kada se to dogodi, evolucija hardvera i upravljanje životnim ciklusom softvera postaju nerazdvojni. Platforma treba znati ne samo gdje se uređaj nalazi i da li je online, već i šta je, šta može da pokreće, kako treba da bude konfigurisan i koje promjene je bezbedno primeniti.
I prije nego što se na bilo koje od tih pitanja može pouzdano odgovoriti, svaki uređaj mora ući u sistem na konzistentan način.
Provisioning je mjesto gdje ručni inženjering prestaje sa skaliranjem
Pružanje usluga izgleda jednostavno kada je flota mala: kreirajte zapis uređaja, unesite serijski broj, generirajte vjerodajnice, dodijelite uređaj korisniku, primijenite konfiguraciju i nastavite dalje. Za nekoliko desetina uređaja, ručno rukovanje dijelom ovoga i dalje može biti pravi izbor.
Međutim, na nivou produkcije, obezbjeđivanje se nalazi na presjeku identiteta uređaja, akreditiva, vlasništva, konfiguracije i stanja životnog ciklusa. Greška napravljena tokom implementacije može uticati na način na koji se uređaj koristi i podržava dugo nakon što napusti fabriku.
Tabela se možda više ne podudara sa onim što je stvarno instalirano. Zamjenski uređaj treba ispravnu povezanost korisnika bez nasljeđivanja pogrešnog identiteta. Vraćanje na tvorničke postavke stvara još jedan put kroz proces. Instalater može dodijeliti uređaj pogrešnom računu, ostavljajući podršku da utvrdi da li je van mreže, da li je nepravilno podešen ili jednostavno ima pogrešnu konfiguraciju.
Nakon što odgovaranje na ta pitanja rutinski zahtijeva od programera da pregleda bazu podataka ili pokrene interni skript, proces je prestao da se skalira zajedno s proizvodom.
Dupliranje je još jedan znak upozorenja. Svaka varijanta proizvoda počinje nabavljati vlastiti skript za uvođenje u rad, alat za konfiguraciju ili tijek rada instalacijskog programa. Te razlike mogu izgledati male, ali osnovna odgovornost je ista. Pružanje usluga postalo je višekratno upotrebljiva infrastruktura platforme, a ne zadatak postavljanja vezan za određeni uređaj.
I rijetko je to jedina sposobnost koja treba da postane ponovo upotrebljiva.
Sloj platforme treba da postane infrastruktura za višekratnu upotrebu
Kada nekoliko proizvoda ili revizija hardvera dijele iste osnovne potrebe, neke softverske mogućnosti prestaju biti specifične za proizvod. Identitet uređaja, obezbjeđivanje, povezivost, telemetrija, isporuka firmvera, stanje životnog ciklusa, vidljivost flote i dijagnostika su dobri primjeri. Njihova ponovna izgradnja za svaku novu varijantu stvara više koda i više operativnih puteva za održavanje, a da sam proizvod ne čini prepoznatljivijim.
Timovi rijetko kreću u pravljenje ove duplikacije. Male razlike se akumuliraju oko svakog proizvoda sve dok tim ne održava nekoliko implementacija onoga što je postala ista inženjerska odgovornost.
Čistija granica je odvajanje sloja proizvoda od sloja platforme. Sloj proizvoda sadrži ponašanje, tokove rada, interfejse, integracije i logiku domene koja čini određeni uređaj vrijednim. Sloj platforme se bavi mehanikom koja bi trebala ostati konzistentna čak i kada se hardver promijeni.
Kako povezani proizvodi prevazilaze svoje prvo izdanje, obezbjeđivanje uređaja, upravljanje životnim ciklusom uređaja, upravljanje voznim parkom i alati za podršku postaju zajednička infrastruktura, a ne detalji pojedinačnih projekata. IoT PaaS za preduzeća može obezbijediti taj sloj platforme za višekratnu upotrebu na više proizvoda ili varijanti proizvoda, rukovajući standardnim upravljanjem uređajima i podacima putem višekratnih gradivnih blokova, dok inženjerski timovi fokusiraju svoje prilagođene napore na hardver, tokove rada i korisničko iskustvo.
Zajednička osnova i dalje mora ostaviti prostora za stvarne razlike u proizvodima. Novom uređaju može biti potreban drugačiji model podataka, tok konfiguracije, integracija ili logika upravljanja, a te razlike bi trebale ostati jednostavne za uvođenje. Cilj je jednostavno izbjeći da svaka razlika bude posljedica još jednog registra uređaja, telemetrijskog kanala, mehanizma za obezbjeđivanje ili skupa alata za upravljanje voznim parkom.
Platforma može izgledati kao višak dok tim gradi prvi proizvod, a kao resurs kod drugog ili trećeg. Nakon što se uspostave uobičajene operativne mehanike, nova varijanta može naslijediti funkcionalnu osnovu umjesto da dođe s drugim backendom koji će tim morati održavati do kraja životnog vijeka tog proizvoda.
Zadržite prilagođeni inženjering tamo gdje je proizvod zapravo drugačiji
Platforma za višekratnu upotrebu ne bi trebala učiniti povezane proizvode generičkijima. Njen zadatak je ukloniti ponovljeno inženjerstvo s dijelova koji ne stvaraju diferencijaciju.
Prilagođeni napori i dalje pripadaju ponašanju uređaja, logici specifičnoj za domen, radnim procesima, korisničkom iskustvu, specijaliziranim integracijama i načinu na koji određeni proizvod interaguje s fizičkim svijetom. To su upravo područja gdje inženjerski izbori mogu učiniti jedan proizvod značajno boljim od drugog.
Ono što rijetko zaslužuje isti tretman jeste okolna operativna vodovodna instalacija. Osnovna i industrijska verzija iste mašine mogu zahtijevati različite senzore, kontrole i interfejse, ali ne bi trebale zahtijevati odvojene načine za identifikaciju uređaja, praćenje verzija firmvera ili upravljanje voznim parkom.
Radije bih vidio kako inženjeri provode to vrijeme usavršavajući ponašanje proizvoda na terenu nego obnavljajući mehaniku koju tim već ima za drugi proizvod. Zajednička osnova ne smanjuje mogućnost prilagođenog inženjeringa; ona štiti taj trud od toga da ga potroši infrastruktura.
Pravi test dolazi kada tim započne s proizvodom broj dva.
Dobra platforma olakšava izradu sljedećeg proizvoda od prvog
Ako proizvod broj dva zahtijeva gotovo isti rad na platformi kao i proizvod broj jedan, vrlo malo toga je zapravo ponovo upotrijebljeno.
Nova varijanta bi trebala biti u stanju naslijediti dijelove operativnog modela koji se nisu promijenili: tokove pružanja usluga, identitet, mehaniku životnog ciklusa, alate za vozni park, procese firmvera, vidljivost podrške i uobičajene integracije. Inženjerski napori se zatim ulažu u razlike - možda novi paket senzora, još jedan tijek rada kontrole ili integraciju specifičnu za kupca - umjesto rekonstrukcije temelja.
Nova generacija hardvera stavlja istu ideju pod veći pritisak. Njegove mogućnosti se mogu značajno promijeniti dok starije jedinice ostanu aktivne na terenu. Zrela platforma može podržati oboje bez prisiljavanja tima da održava dva odvojena platformska steka za ono što kupci još uvijek doživljavaju kao jednu porodicu proizvoda.
Ništa od ovoga ne zahtijeva jedan monolitni backend. Različiti proizvodi i dalje mogu zahtijevati jasne arhitektonske granice. Važno je izbjegavati drugu implementaciju iste inženjerske odgovornosti bez dobrog razloga.
Tada platforma postaje prednost, a ne akumulirani režijski troškovi. Podrška ima manje paralelnih alata za razumijevanje, izdanja slijede konzistentnije puteve, a dodavanje još jednog proizvoda postaje kontrolirano proširenje umjesto još jednog backenda koji kompanija nasljeđuje na neodređeno vrijeme.
Tretirajte platformu kao dio arhitekture proizvoda
Fizički proizvodi su dizajnirani imajući na umu revizije, upotrebljivost, proizvodnost i buduće promjene. Povezani proizvodi zahtijevaju istu disciplinu na strani softvera.
Prvi backend može biti privremen. Isto tako može biti i prvi skript za pružanje usluga ili alat za podršku. U tome nema ništa inherentno loše. Problemi počinju kada te privremene mehanike tiho postanu trajna arhitektura dok sam proizvod nastavlja da se razvija.
Do tada, povezani proizvod više nije samo hardver, firmver i aplikacija. On također ovisi o infrastrukturi koja identificira svaki uređaj, razumije njegove mogućnosti, primjenjuje ispravnu konfiguraciju, podržava ažuriranja i pomaže timovima da dijagnosticiraju probleme godinama nakon isporuke.
Kada se taj sloj tretira kao arhitektura proizvoda, podjela postaje jasnija: standardne mehanike ostaju ponovo upotrebljive, dok prilagođeni rad obuhvata ono što zapravo razlikuje jedan proizvod ili porodicu proizvoda od drugog.
Najjača platforma nije samo ona koja omogućava prvi povezani proizvod. To je ona koja omogućava inženjerskom timu da izgradi drugi, treći i četvrti bez nasljeđivanja novog backend-a svaki put.
