Povezani proizvod može izgledati dovrš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 već je u rukama korisnika. U tom trenutku, pozadinski sustav još uvijek može biti dovoljno jednostavan da tim poznaje gotovo svaki uređaj pojedinačno. Pružanje usluga može se obaviti skriptom, promjene konfiguracije mogu se izvršiti ručno, a ako nešto ne uspije, inženjer obično može izravno pratiti problem.
Zatim mora početi živjeti u stvarnom svijetu. Pojavljuje se druga revizija hardvera. Neki kupci još uvijek koriste prvu reviziju. Verzije firmwarea počinju se razlikovati. Potrebna je nova konfiguracija za drugog kupca ili tržište, dok stariji uređaji i dalje trebaju ažuriranja i podršku.
Ništa nije nužno pokvareno. Softver iza uređaja jednostavno je stekao vlastiti životni ciklus.
Taj prijelaz 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, pozadinski sustav više nije samo infrastruktura iza hardvera. Postaje dio same arhitekture proizvoda.
Radni povezani prototip još nije skalabilan proizvod
Prototip ima važnu zadaću: dokazati da sustav radi od početka do kraja. Uređaj obavlja svoju osnovnu funkciju, firmver komunicira s pozadinskim sustavom, telemetrija stiže tamo gdje treba, naredbe se vraćaju, a mobilno ili web sučelje izlaže funkcionalnost korisniku.
Ono što obično nije dokazalo jest koliko dobro isti sustav podnosi raznolikost.
Prvih dvadeset uređaja mogu koristiti isti firmware, biti izgrađeni na istoj reviziji hardvera i konfigurirani od strane istih inženjera. U toj fazi, ručna registracija, izravne promjene konfiguracije ili mali onboarding skript mogu biti sasvim razumni. Izrada alata produkcijske razine prije nego što se proizvod dokaže može biti preuranjena.
Skala mijenja problem. Uređaji ostaju izvan mreže, zamjenjuju se, koriste drugačiji firmver i zahtijevaju različite konfiguracije korisnika. Podrška mora razlikovati jedinicu koja nikada nije ispravno opskrbljena od one koja je pogrešno konfigurirana ili jednostavno nedostupna.
Prototipni dug često počinje na ovaj način: ne s lošom odlukom, već s privremenom koja ostaje na snazi nakon što je proizvod premješten. I jedna od prvih stvari koja prisiljava taj prijelaz na vidjelo je sam hardver. Nova revizija ne samo da zamjenjuje staru; 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 prijelaznu 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". Mora znati što ta određena jedinica može učiniti.
Revidirana ploča može koristiti drugačiji senzor, komunikacijski modul ili kontroler. Naredba koja vrijedi za najnoviju verziju možda nije podržana od strane starije verzije. Vrijednosti kalibracije mogu se promijeniti. Ograničenja konfiguracije mogu se pomaknuti. Paket firmvera prikladan 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 shvati s kojom verzijom fizičkog proizvoda komunicira i koja se pravila na nju primjenjuju.
Razmotrimo proizvod čija prva revizija koristi jedan postupak kalibracije, dok druga uvodi novi senzor i drugačiji skup parametara. Za kupca, obje jedinice mogu i dalje biti isti proizvod. Za platformu to ne mogu biti.
Ako te razlike nisu eksplicitno predstavljene, one imaju tendenciju procuriti 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 iznimku dodanu nakon što je podrška otkrila stariju seriju koja se drugačije ponaša na terenu. Nijedan od ovih ispravaka ne izgleda posebno opasno sam po sebi, ali zajedno otežavaju svaku buduću promjenu.
Stariji hardver rijetko nestaje na vrijeme. Proizvodni timovi se prirodno usredotočuju na najnoviju reviziju, dok kupci često zadržavaju starije verzije puno dulje 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.
Nakon što se to dogodi, evolucija hardvera i upravljanje životnim ciklusom softvera postaju nerazdvojni. Platforma treba znati ne samo gdje se uređaj nalazi i je li online, već i što je, što može pokretati, kako bi trebao biti konfiguriran i koje su promjene sigurne za primjenu.
I prije nego što se na bilo koje od tih pitanja može pouzdano odgovoriti, svaki uređaj mora ući u sustav na dosljedan način.
Pružateljstvo 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 desetaka uređaja, ručno rukovanje dijelom ovoga i dalje može biti pravi izbor.
Međutim, u produkcijskoj skali, pružanje usluga nalazi se na presjeku identiteta uređaja, vjerodajnica, vlasništva, konfiguracije i stanja životnog ciklusa. Pogreška napravljena tijekom uvođenja u rad može utjecati na način rada i podrške uređaja dugo nakon što napusti tvornicu.
Proračunska tablica možda više ne odgovara onome š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šci da utvrdi je li izvan mreže, neispravno opskrbljen 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 skalirati s proizvodom.
Dupliciranje je još jedan znak upozorenja. Svaka varijanta proizvoda počinje dobivati vlastiti skript za uvođenje u rad, alat za konfiguraciju ili tijek rada instalacijskog programa. Te razlike mogu izgledati male, ali temeljna odgovornost je ista. Pružanje usluga postalo je višekratno upotrebljiva infrastruktura platforme, a ne zadatak postavljanja vezan uz određeni uređaj.
I rijetko je to jedina sposobnost koja treba postati ponovno upotrebljiva.
Sloj platforme trebao bi postati infrastruktura za višekratnu upotrebu
Nakon što nekoliko proizvoda ili revizija hardvera dijele iste osnovne potrebe, neke softverske mogućnosti prestaju biti specifične za proizvod. Identitet uređaja, opskrba, povezivost, telemetrija, isporuka firmvera, stanje životnog ciklusa, vidljivost flote i dijagnostika dobri su primjeri. Njihova ponovna izgradnja za svaku novu varijantu stvara više koda i više operativnih putova za održavanje, a da sam proizvod ne čini prepoznatljivijim.
Timovi rijetko kreću u stvaranje ovog dupliciranja. 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 odvojiti sloj proizvoda od sloja platforme. Sloj proizvoda sadrži ponašanje, tijekove rada, sučelja, integracije i logiku domene koja čini određeni uređaj vrijednim. Sloj platforme obrađuje mehaniku koja bi trebala ostati dosljedna čak i kada se hardver promijeni.
Kako povezani proizvodi prelaze svoje prvo izdanje, opskrba uređajima, upravljanje životnim ciklusom uređaja, upravljanje voznim parkom i alati za podršku postaju zajednička infrastruktura, a ne detalji pojedinačnog projekta. IoT PaaS za poduzeća može pružiti taj sloj platforme za višekratnu upotrebu na više proizvoda ili varijanti proizvoda, rješavajući standardno upravljanje uređajima i podacima putem višekratnih gradivnih blokova, dok inženjerski timovi usmjeravaju svoje prilagođene napore na hardver, tijekove rada i korisničko iskustvo.
Zajednički temelj i dalje mora ostaviti prostora za stvarne razlike u proizvodima. Novi uređaj može zahtijevati drugačiji model podataka, tijek konfiguracije, integraciju ili logiku upravljanja, a te razlike trebale bi ostati jednostavne za uvođenje. Cilj je jednostavno izbjeći da svaka razlika bude teret za još jedan registar uređaja, telemetrijski cjevovod, mehanizam opskrbe ili skup alata za upravljanje voznim parkom.
Platforma može izgledati kao režijski teret dok tim gradi prvi proizvod, a kao resurs kod drugog ili trećeg. Nakon što su uspostavljeni uobičajeni operativni mehanizmi, nova varijanta može naslijediti radnu osnovu umjesto da dođe s drugim pozadinskim sustavom 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. Njezin je zadatak ukloniti ponovljeno inženjerstvo s dijelova koji ne stvaraju diferencijaciju.
Prilagođeni napori i dalje pripadaju ponašanju uređaja, logici specifičnoj za domenu, tijekovima rada, korisničkom iskustvu, specijaliziranim integracijama i načinu na koji određeni proizvod komunicira 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 jest okolna operativna vodovodna instalacija. Osnovna i industrijska verzija istog stroja mogu zahtijevati različite senzore, kontrole i sučelja, ali ne bi trebale zahtijevati odvojene načine za identifikaciju uređaja, praćenje verzija firmvera ili upravljanje voznim parkom.
Radije bih vidio da 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; š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 ponovno upotrijebljeno.
Nova varijanta trebala bi moći naslijediti dijelove operativnog modela koji se nisu promijenili: tokove opskrbe, identitet, mehaniku životnog ciklusa, alate za vozni park, procese firmvera, vidljivost podrške i uobičajene integracije. Inženjerski napor zatim ide na 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 mogu se znatno promijeniti dok starije jedinice ostanu aktivne na terenu. Zrela platforma može podržati oboje bez prisiljavanja tima da održava dva odvojena platformska paketa za ono što kupci još uvijek doživljavaju kao jednu obitelj 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 dosljednije puteve, a dodavanje još jednog proizvoda postaje kontrolirano proširenje umjesto još jednog backenda koji tvrtka nasljeđuje na neodređeno vrijeme.
Tretirajte platformu kao dio arhitekture proizvoda
Fizički proizvodi dizajnirani su imajući na umu revizije, jednostavnost korištenja, proizvodnost i buduće promjene. Povezani proizvodi zahtijevaju istu disciplinu na strani softvera.
Prvi backend može biti privremen. Isto tako može i prvi skript za opskrbu 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 se sam proizvod nastavlja razvijati.
Do tada, povezani proizvod više nije samo hardver, firmver i aplikacija. 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 u dijagnosticiranju problema godinama nakon isporuke.
Nakon što se taj sloj tretira kao arhitektura proizvoda, podjela postaje jasnija: standardne mehanike ostaju ponovno upotrebljive, dok prilagođeni rad obuhvaća ono što zapravo razlikuje jedan proizvod ili obitelj proizvoda od drugog.
Najjača platforma nije samo ona koja omogućuje prvi povezani proizvod. To je ona koja omogućuje inženjerskom timu da izgradi drugi, treći i četvrti bez nasljeđivanja novog backenda svaki put.
