Ühendatud toode võib näida valmis olevat juba ammu enne, kui sellega seotud inseneritöö on valmis. Prototüüp on stabiilne, andmed jõuavad pilve, rakendus näitab õigeid väärtusi ja esimene partii seadmeid on juba kasutajate käes. Sel hetkel võib taustsüsteem olla veel piisavalt lihtne, et meeskond tunneb peaaegu iga seadet eraldi. Seadete seadistamist saab teha skripti abil, konfiguratsioonimuudatusi saab teha käsitsi ja kui midagi peaks rikki minema, saab insener tavaliselt probleemi otse jälgida.
Seejärel peab see hakkama pärismaailmas elama. Ilmub teine riistvaraversioon. Mõned kliendid kasutavad endiselt esimest versiooni. Püsivara versioonid hakkavad erinema. Erineva kliendi või turu jaoks on vaja uut konfiguratsiooni, samas kui vanemad seadmed vajavad endiselt värskendusi ja tuge.
Miski pole tingimata katki. Seadme taga olev tarkvara on lihtsalt omandanud oma elutsükli.
Seda üleminekut on lihtne märkamata jätta, sest prototüüp võib jätkuvalt suurepäraselt töötada. Aga kui sama füüsilise toote mitu versiooni peavad väljal koos eksisteerima, ei ole taustsüsteem enam lihtsalt riistvara taga olev infrastruktuur. Sellest saab osa toote arhitektuurist endast.
Toimiv ühendatud prototüüp ei ole veel skaleeritav toode
Prototüübil on oluline ülesanne: tõestada süsteemi täielikku toimimist. Seade täidab oma põhifunktsiooni, püsivara suhtleb serveripoolse süsteemiga, telemeetria jõuab kohale, käsud edastatakse ja mobiilne või veebiliides avalikustab funktsionaalsuse kasutajale.
Tavaliselt pole tõestatud, kui hästi sama süsteem mitmekesisusega toime tuleb.
Esimesed kakskümmend seadet võivad kõik käitada sama püsivara, olla ehitatud sama riistvaraversiooni järgi ja konfigureeritud samade inseneride poolt. Selles etapis võib käsitsi registreerimine, otsesed konfiguratsioonimuudatused või väike sissejuhatav skript olla täiesti mõistlik. Tootmiskvaliteediga tööriistade loomine enne toote enda toimivuse tõestamist võib olla ennatlik.
Skaala muutus probleemiks. Seadmed jäävad võrguühenduseta, neid vahetatakse välja, need käitavad erinevat püsivara ja vajavad erinevaid kliendi konfiguratsioone. Tugi peab eristama seadet, mida pole kunagi õigesti ette valmistatud, valesti konfigureeritud või lihtsalt kättesaamatust seadmest.
Prototüübivõlg algab sageli nii: mitte halva otsusega, vaid ajutise otsusega, mis jääb kehtima ka pärast toote edasiliikumist. Ja üks esimesi asju, mis selle ülemineku nähtavale toob, on riistvara ise. Uus versioon ei asenda lihtsalt vana; see peab sellega koos eksisteerima.
Iga riistvarauuendus loob tarkvara elutsükli probleemi
Uus riistvaraversioon saabub harva vana puhta asendajana. Praktikas jäävad mõlemad versioonid kasutusse, mõnikord aastaid. Lisage üleminekupartii, paar püsivara haru ja kliendispetsiifilised konfiguratsioonid ning seadmepark muutub kiiresti mitmekesisemaks, kui algne tootemudel eeldab.
Tarkvarakiht ei saa enam iga üksust käsitleda abstraktse "seadmena". See peab teadma, mida see konkreetne üksus teha suudab.
Uuendatud plaat võib kasutada teistsugust andurit, sidemoodulit või kontrollerit. Uusima versiooni jaoks kehtivat käsku ei pruugi varasem versioon toetada. Kalibreerimisväärtused võivad muutuda. Konfiguratsioonipiirid võivad nihkuda. Ühele põlvkonnale sobiv püsivara pakett ei pruugi olla teise põlvkonna jaoks ohtlik.
Füüsiliste toodete insenerid töötavad juba sel viisil. Kaks komponenti, mis näevad välja peaaegu identsed, ei ole omavahel asendatavad, kui nende versioonid, tolerantsid või spetsifikatsioonid erinevad. Ühendatud tooted tekitavad tarkvara poolel sama probleemi: platvorm vajab usaldusväärset viisi, et aru saada, millise füüsilise toote versiooniga ta suhtleb ja millised reeglid sellele kehtivad.
Kujutage ette toodet, mille esimene versioon kasutab ühte kalibreerimisprotseduuri, samas kui teine toob sisse uue anduri ja teistsuguse parameetrite komplekti. Kliendi jaoks võivad mõlemad seadmed ikkagi olla sama toode. Platvormi jaoks aga mitte.
Kui neid erinevusi selgesõnaliselt ei esitata, kipuvad need rakenduse loogikasse erijuhtudena imbuma. Üks töövoog kontrollib seerianumbrite vahemikku. Teine kasutab riistvara genereerimise puhverserverina püsivara versiooni. Kolmas sisaldab erandit, mis lisati pärast seda, kui tugimeeskond avastas vanema partii, mis käitus reas erinevalt. Ükski neist parandustest ei tundu eraldi eriti ohtlik, kuid koos muudavad nad iga tulevase muudatuse põhjendamise raskemaks.
Vanem riistvara kaob harva graafikujärgselt. Tootemeeskonnad keskenduvad loomulikult uusimale versioonile, samas kui kliendid hoiavad varasemaid versioone sageli oodatust palju kauem. Seetõttu peab platvorm toetama mitut põlvkonda korraga, selle asemel et eeldada, et installitud baas koondub kunagi ühte praegusesse olekusse.
Kui see juhtub, muutuvad riistvara areng ja tarkvara elutsükli haldus lahutamatuks. Platvorm peab teadma mitte ainult seda, kus seade asub ja kas see on võrgus, vaid ka seda, mis see on, mida see saab käivitada, kuidas seda konfigureerida ja milliseid muudatusi on ohutu rakendada.
Ja enne, kui ühelegi neist küsimustest saab usaldusväärselt vastata, peab iga seade süsteemi sisenema järjepidevalt.
Käsitsi projekteerimine lõpetab skaleerimise, pakkudes välja uusi lahendusi.
Kui seadmepark on väike, tundub seadmete seadistamine lihtne: looge seadmekirje, sisestage seerianumber, genereerige volikirjad, määrake seade kliendile, rakendage konfiguratsioon ja liikuge edasi. Mõnekümne seadme puhul võib osa sellest käsitsi teha siiski õige valik olla.
Tootmismastaabis toimub aga seadmete varustamine seadme identiteedi, volituste, omandiõiguse, konfiguratsiooni ja elutsükli oleku ristumiskohas. Sissejuhatuse ajal tehtud viga võib mõjutada seadme toimimist ja tuge veel kaua pärast tehasest lahkumist.
Arvutustabel ei pruugi enam vastata tegelikult installitule. Asendusseade vajab õiget kliendi seost ilma vale identiteedi pärimiseta. Tehase lähtestamine loob protsessis uue tee. Paigaldaja saab seadme määrata valele kontole, jättes toe ülesandeks kindlaks teha, kas see on võrguühenduseta, valesti seadistatud või lihtsalt vale konfiguratsiooniga.
Kui nendele küsimustele vastamine nõuab arendajalt rutiinselt andmebaasi kontrollimist või sisemise skripti käivitamist, on protsess tootega skaleerimise lõpetanud.
Dubleerimine on veel üks hoiatusmärk. Iga tootevariant hakkab omandama oma sissejuhatava skripti, konfiguratsioonitööriista või installija töövoogu. Need erinevused võivad tunduda väikesed, kuid aluseks olev vastutus on sama. Varustamine on muutunud korduvkasutatavaks platvormi infrastruktuuriks, mitte konkreetse seadmega seotud seadistusülesandeks.
Ja see on harva ainus võimekus, mis peab olema korduvkasutatav.
Platvormikihist peaks saama korduvkasutatav infrastruktuur
Kui mitmel tootel või riistvaraversioonil on samad põhivajadused, ei ole mõned tarkvaravõimalused enam tootespetsiifilised. Head näited on seadme identiteet, seadistamine, ühenduvus, telemeetria, püsivara tarnimine, elutsükli olek, seadmepargi nähtavus ja diagnostika. Nende uuesti loomine iga uue variandi jaoks loob rohkem koodi ja rohkem toimimisviise, mida hallata, muutmata toodet ennast eristuvatmaks.
Meeskonnad harva seavad end sellise dubleerimisega tegelema. Iga toote ümber kuhjuvad väikesed erinevused, kuni meeskond haldab mitut teostust millestki, mis on saanud samaks insenerivastutuseks.
Selgem piir on tootekihi eraldamine platvormikihist. Tootekiht sisaldab käitumist, töövooge, liideseid, integratsioone ja domeeniloogikat, mis muudavad konkreetse seadme väärtuslikuks. Platvormikiht tegeleb mehaanikaga, mis peaks jääma samaks isegi riistvara muutudes.
Kui ühendatud tooted oma esimesest väljalaskest edasi liiguvad, muutuvad seadmete ettevalmistamine, seadmete elutsükli haldus, seadmepargi haldus ja tugitööriistad jagatud infrastruktuuriks, mitte ühekordseteks projektidetailideks. Ettevõtetele mõeldud IoT PaaS saab pakkuda seda korduvkasutatavat platvormikihti mitme toote või tootevariandi jaoks, käsitledes standardset seadmete ja andmete haldust korduvkasutatavate ehitusplokkide kaudu, samal ajal kui insenerimeeskonnad keskenduvad oma kohandatud töös riistvarale, töövoogudele ja kasutajakogemusele.
Ühtne alus peab siiski jätma ruumi tegelikele tooteerinevustele. Uus seade võib vajada erinevat andmemudelit, konfiguratsioonivoogu, integratsiooni või juhtimisloogikat ning neid erinevusi peaks olema lihtne sisse viia. Eesmärk on lihtsalt vältida iga erinevuse kaasaskandmist teise seadmeregistrisse, telemeetriakanalisse, varustamismehhanismi või seadmepargi haldamise tööriistade komplekti.
Esimese toote loomisel võib platvorm tunduda lisakuluna ja teise või kolmanda toote loomisel varana. Kui ühised töömehaanika põhimõtted on paigas, saab uus variant pärida toimiva aluse, selle asemel et kaasas olla uus tagaserver, mida meeskond peab toote kogu ülejäänud eluea jooksul hooldama.
Säilita eritellimusel valmistatud inseneritöö seal, kus toode on tegelikult erinev
Korduvkasutatav platvorm ei tohiks muuta ühendatud tooteid üldisemaks. Selle ülesanne on eemaldada korduv inseneritöö osadest, mis ei loo eristumist.
Kohandatud lahendused kuuluvad endiselt seadme käitumise, valdkonnapõhise loogika, töövoogude, kasutajakogemuse, spetsialiseeritud integratsioonide ja konkreetse toote füüsilise maailmaga suhtlemise viisi valdkonda. Just need on valdkonnad, kus insenerivalikud võivad muuta ühe toote teisest oluliselt paremaks.
Ümbritsev torustik väärib harva sama kohtlemist. Sama masina põhiversioon ja tööstusversioon võivad vajada erinevaid andureid, juhtelemente ja liideseid, kuid need ei tohiks vajada eraldi viise seadmete tuvastamiseks, püsivara versioonide jälgimiseks või seadmepargi haldamiseks.
Ma pigem näeksin, et insenerid kulutaksid selle aja toote käitumise täiustamisele reas, selle asemel, et taastada mehaanikat, mis meeskonnal juba mõne teise toote jaoks olemas on. Ühine alus ei vähenda kohandatud inseneritöö ulatust; see kaitseb seda pingutust infrastruktuuri poolt raiskamise eest.
Tõeline proovikivi saabub siis, kui meeskond alustab teise tootega.
Hea platvorm muudab järgmise toote loomise esimesest lihtsamaks.
Kui toode number kaks nõuab peaaegu sama platvormitööd kui toode number üks, siis on tegelikult väga vähe taaskasutatud.
Uus variant peaks saama pärida need operatsioonimudeli osad, mis pole muutunud: varustamisvood, identiteet, elutsükli mehaanika, seadmepargi tööriistad, püsivara protsessid, toe nähtavus ja tavalised integratsioonid. Seejärel suunatakse inseneritööd erinevuste lahendamisele – võib-olla uus andurite pakett, teine juhtimistöövoog või kliendispetsiifiline integratsioon –, selle asemel et vundamenti ümber ehitada.
Uus riistvarapõlvkond seab sama idee suurema surve alla. Selle võimalused võivad oluliselt muutuda, samal ajal kui vanemad seadmed jäävad aktiivseks. Küps platvorm suudab toetada mõlemat, sundimata meeskonda haldama kahte eraldi platvormivirna selle jaoks, mida kliendid ikka veel ühe tooteperena tajuvad.
Miski sellest ei nõua ühte monoliitset tagaserverit. Erinevad tooted võivad siiski vajada selgeid arhitektuurilisi piire. Oluline on vältida sama inseneritöö teist rakendamist ilma mõjuva põhjuseta.
See on siis, kui platvormist saab vara, mitte akumuleeritud üldkulu. Tugiteenustel on vähem paralleelseid tööriistu, mida mõista, väljalasked järgivad järjepidevamaid teid ja uue toote lisamisest saab kontrollitud laiendus, mitte järjekordne taustsüsteem, mille ettevõte pärib lõputult.
Platvormi käsitlemine tootearhitektuuri osana
Füüsiliste toodete disainimisel peetakse silmas muudatuste tegemist, hooldatavust, valmistatavust ja tulevasi muudatusi. Ühendatud toodete puhul on tarkvara poolel vaja sama distsipliini.
Esimene taustsüsteem võib olla ajutine. Sama võib juhtuda ka esimese seadistamise skripti või tugitööriistaga. Selles pole midagi olemuslikult halba. Probleemid algavad siis, kui need ajutised mehhanismid muutuvad vaikselt püsivaks arhitektuuriks, samal ajal kui toode ise edasi areneb.
Selleks ajaks pole ühendatud toode enam ainult riistvara, püsivara ja rakendus. See sõltub ka infrastruktuurist, mis tuvastab iga seadme, mõistab selle võimalusi, rakendab õiget konfiguratsiooni, toetab värskendusi ja aitab meeskondadel probleeme diagnoosida aastaid pärast tarnimist.
Kui seda kihti käsitletakse tootearhitektuurina, muutub jaotus selgemaks: standardmehaanika jääb korduvkasutatavaks, samas kui eritellimustööd hõlmavad seda, mis tegelikult eristab ühte toodet või tooteperekonda teisest.
Kõige tugevam platvorm ei ole lihtsalt see, mis võimaldab luua esimese ühendatud toote. See on see, mis võimaldab insenerimeeskonnal luua teise, kolmanda ja neljanda ilma iga kord uut serveripoolset süsteemi pärimata.
