Prijungtas produktas gali atrodyti baigtas gerokai anksčiau, nei bus baigta jį supančio inžinerinio projekto kūrimas. Prototipas yra stabilus, duomenys pasiekia debesį, programėlė rodo teisingas vertes, o pirmoji įrenginių partija jau yra naudotojų rankose. Tuo metu vidinė sistema vis dar gali būti pakankamai paprasta, kad komanda žinotų beveik kiekvieną įrenginį atskirai. Įrenginių paruošimas gali būti atliekamas naudojant scenarijų, konfigūracijos pakeitimus galima atlikti rankiniu būdu, o jei kas nors nepavyksta, inžinierius paprastai gali tiesiogiai atsekti problemą.
Tada jis turi pradėti gyventi realiame pasaulyje. Atsiranda antroji aparatinės įrangos versija. Kai kurie klientai vis dar naudoja pirmąją versiją. Programinės įrangos versijos pradeda skirtis. Skirtingam klientui ar rinkai reikalinga nauja konfigūracija, o senesniems įrenginiams vis tiek reikia atnaujinimų ir palaikymo.
Niekas nebūtinai sugedę. Įrenginio programinė įranga tiesiog įgavo savo gyvavimo ciklą.
Šį perėjimą lengva nepastebėti, nes prototipas gali toliau puikiai veikti. Tačiau kai lauke turi egzistuoti kelios to paties fizinio produkto versijos, vidinė sistema nebėra tik infrastruktūra už aparatinės įrangos. Ji tampa pačios produkto architektūros dalimi.
Veikiantis prijungtas prototipas dar nėra keičiamo dydžio produktas
Prototipas atlieka svarbią funkciją: įrodyti, kad sistema veikia nuo pradžios iki galo. Įrenginys atlieka pagrindinę savo funkciją, programinė įranga bendrauja su serveriu, telemetrija pasiekia reikiamą vietą, komandos grįžta atgal, o mobilioji arba žiniatinklio sąsaja pateikia funkcionalumą vartotojui.
Paprastai neįrodyta, kaip gerai ta pati sistema susidoroja su įvairove.
Pirmieji dvidešimt įrenginių gali naudoti tą pačią programinę-aparatinę įrangą, būti sukurti naudojant tą pačią aparatinės įrangos versiją ir konfigūruojami tų pačių inžinierių. Šiame etape rankinė registracija, tiesioginiai konfigūracijos pakeitimai arba nedidelis įdiegimo scenarijus gali būti visiškai logiškas. Gamybinės klasės įrankių kūrimas, kol produktas neįrodė savo veiksmingumo, gali būti per anksti.
Mastelio keitimas keičia problemą. Įrenginiai neveikia, yra keičiami, naudoja skirtingą programinę-aparatinę įrangą ir jiems reikalingos skirtingos klientų konfigūracijos. Palaikymo komanda turi atskirti įrenginį, kuris niekada nebuvo tinkamai paruoštas, nuo to, kuris yra netinkamai sukonfigūruotas arba tiesiog nepasiekiamas.
Prototipo skola dažnai prasideda taip: ne nuo blogo sprendimo, o nuo laikino sprendimo, kuris lieka galioti ir produktui pasikeitus. Ir vienas pirmųjų dalykų, priverčiančių šį perėjimą atsirasti, yra pati techninė įranga. Nauja versija ne tik pakeičia senąją; ji turi su ja egzistuoti.
Kiekviena aparatinės įrangos versija sukuria programinės įrangos gyvavimo ciklo problemą
Nauja aparatinės įrangos versija retai kada visiškai pakeičia senąją. Praktiškai abi versijos lieka rinkoje, kartais metų metus. Pridėjus pereinamąją partiją, kelias programinės įrangos atšakas ir klientui pritaikytas konfigūracijas, įrenginių parkas greitai tampa įvairesnis, nei rodo originalus produkto modelis.
Programinės įrangos sluoksnis nebegali kiekvieno įrenginio traktuoti kaip abstraktaus „įrenginio“. Jam reikia žinoti, ką tas konkretus įrenginys gali padaryti.
Atnaujintoje plokštėje gali būti naudojamas kitoks jutiklis, ryšio modulis arba valdiklis. Komanda, galiojanti naujausiai versijai, gali būti nepalaikoma ankstesnės versijos. Kalibravimo vertės gali pasikeisti. Konfigūracijos ribos gali pasikeisti. Vienai kartai tinkamas programinės įrangos paketas gali būti nesaugus kitai.
Fizinių produktų inžinieriai jau dirba tokiu būdu. Du komponentai, kurie atrodo beveik identiškai, nėra keičiami, jei skiriasi jų versijos, tolerancijos ar specifikacijos. Sujungti produktai sukuria tą pačią problemą programinės įrangos pusėje: platformai reikia patikimo būdo suprasti, su kuria fizinio produkto versija ji bendrauja ir kokios taisyklės jai taikomos.
Tarkime, kad pirmoje versijoje naudojama viena kalibravimo procedūra, o antroje – naujas jutiklis ir kitoks parametrų rinkinys. Klientui abu įrenginiai gali būti tas pats produktas. Platformai jie tokie būti negali.
Jei šie skirtumai nėra aiškiai pavaizduoti, jie linkę prasiskverbti į programos logiką kaip specialūs atvejai. Vienas darbo eigas tikrina serijos numerių diapazoną. Kitas naudoja programinės įrangos versiją kaip pakaitinį aparatinės įrangos generavimo rodiklį. Trečiasis apima išimtį, pridėtą po to, kai palaikymo komanda aptiko senesnę partiją, kuri lauke elgėsi kitaip. Nė vienas iš šių pataisymų atskirai neatrodo ypač pavojingas, tačiau kartu jie apsunkina kiekvieno būsimo pakeitimo pagrindimą.
Senesnė įranga retai kada išnyksta pagal grafiką. Produktų komandos natūraliai daugiausia dėmesio skiria naujausioms versijoms, o klientai dažnai ankstesnes versijas saugo daug ilgiau nei tikėtasi. Todėl platforma turi palaikyti kelias kartas vienu metu, o ne daryti prielaidą, kad įdiegta bazė kada nors pasieks vieną dabartinę būseną.
Kai tai įvyksta, aparatinės įrangos evoliucija ir programinės įrangos gyvavimo ciklo valdymas tampa neatsiejami. Platforma turi žinoti ne tik tai, kur yra įrenginys ir ar jis prijungtas prie interneto, bet ir kas tai yra, ką jis gali paleisti, kaip jį reikia konfigūruoti ir kuriuos pakeitimus saugu taikyti.
Ir prieš tai, kai į bet kurį iš šių klausimų galima patikimai atsakyti, kiekvienas įrenginys turi nuosekliai patekti į sistemą.
Rankinis inžinerijos pritaikymas yra ta vieta, kur nustoja būti plečiamas
Kai įrenginių parkas nedidelis, aprūpinimas atrodo paprastas: sukurkite įrenginio įrašą, įveskite serijos numerį, sugeneruokite kredencialus, priskirkite įrenginį klientui, pritaikykite konfigūraciją ir tęskite. Kelioms dešimtims įrenginių kai kuriuos šiuos veiksmus vis tiek gali būti tinkamas pasirinkimas tvarkyti rankiniu būdu.
Tačiau gamybos mastu aprūpinimas yra įrenginio tapatybės, kredencialų, nuosavybės, konfigūracijos ir gyvavimo ciklo būsenos sankirta. Klaida, padaryta diegimo metu, gali paveikti įrenginio veikimą ir palaikymą ilgai po to, kai jis iškeliauja iš gamyklos.
Skaičiuoklė gali nebeatitikti to, kas iš tikrųjų įdiegta. Pakeistam įrenginiui reikalingas tinkamas kliento susiejimas, kad jis nepaveldėtų neteisingos tapatybės. Gamyklinių parametrų atkūrimas sukuria kitą proceso kelią. Montuotojas gali priskirti įrenginį netinkamai paskyrai, palikdamas palaikymo komandai nustatyti, ar jis neprisijungęs prie interneto, neteisingai paruoštas, ar tiesiog turi neteisingą konfigūraciją.
Kai norint atsakyti į šiuos klausimus, kūrėjui įprastai reikia patikrinti duomenų bazę arba paleisti vidinį scenarijų, procesas nustojo būti taikomas kartu su produktu.
Dubliavimas yra dar vienas įspėjamasis ženklas. Kiekvienas produkto variantas pradeda įgyti savo atskirą įdiegimo scenarijų, konfigūravimo įrankį arba diegimo darbo eigą. Šie skirtumai gali atrodyti nedideli, tačiau pagrindinė atsakomybė yra ta pati. Parengimas tapo daugkartinio naudojimo platformos infrastruktūra, o ne su konkrečiu įrenginiu susieta sąrankos užduotimi.
Ir tai retai būna vienintelė galimybė, kurią reikia panaudoti pakartotinai.
Platformos sluoksnis turėtų tapti daugkartinio naudojimo infrastruktūra
Kai keli produktai ar aparatinės įrangos versijos turi tuos pačius pagrindinius poreikius, kai kurios programinės įrangos galimybės nustoja būti būdingos tik produktui. Įrenginio tapatybė, aprūpinimas, ryšys, telemetrija, programinės įrangos pristatymas, gyvavimo ciklo būsena, įrenginių parko matomumas ir diagnostika yra geri pavyzdžiai. Jų atkūrimas kiekvienam naujam variantui sukuria daugiau kodo ir daugiau operacinių kelių, kuriuos reikia prižiūrėti, nepadarant paties produkto išskirtinesnio.
Komandos retai kada imasi kurti tokį dublikatą. Maži skirtumai kaupiasi aplink kiekvieną produktą, kol komanda pradeda prižiūrėti kelis to, kas tapo ta pačia inžinerine atsakomybe, įgyvendinimus.
Aiškesnė riba yra atskirti produkto sluoksnį nuo platformos sluoksnio. Produkto sluoksnis apima elgseną, darbo eigas, sąsajas, integracijas ir domeno logiką, dėl kurių konkretus įrenginys yra vertingas. Platformos sluoksnis tvarko mechaniką, kuri turėtų išlikti pastovi net ir keičiantis aparatinei įrangai.
Prijungtiesiems produktams išleidžiant daugiau nei pirmąjį leidimą, įrenginių aprūpinimas, įrenginių gyvavimo ciklo valdymas, parko valdymas ir palaikymo įrankiai tampa bendra infrastruktūra, o ne vienkartinėmis projekto detalėmis. Įmonėms skirta daiktų interneto PaaS gali suteikti tą pakartotinai naudojamą platformos sluoksnį keliems produktams ar produktų variantams, tvarkydama standartinį įrenginių ir duomenų valdymą per pakartotinai naudojamus konstrukcinius blokus, o inžinierių komandos sutelkia dėmesį į aparatinę įrangą, darbo eigas ir naudotojo patirtį.
Bendras pagrindas vis tiek turi palikti vietos realiems produktų skirtumams. Naujam įrenginiui gali reikėti skirtingo duomenų modelio, konfigūracijos srauto, integracijos ar valdymo logikos, ir šiuos skirtumus turėtų būti lengva įdiegti. Tikslas yra tiesiog išvengti to, kad kiekvienas skirtumas būtų įtrauktas į kitą įrenginių registrą, telemetrijos srautą, aprūpinimo mechanizmą ar įrenginių parko valdymo įrankių rinkinį.
Kol komanda kuria pirmąjį produktą, platforma gali atrodyti kaip pridėtinės išlaidos, o kuriant antrąjį ar trečiąjį – kaip turtas. Kai bus įdiegti bendri veikimo mechanizmai, naujas variantas gali paveldėti veikiantį pagrindą, o ne atkeliauti su kita serverine sistema, kurią komanda turės prižiūrėti visą likusį to produkto gyvavimo laiką.
Išlaikykite individualią inžineriją ten, kur produktas iš tikrųjų skiriasi
Daugkartinio naudojimo platforma neturėtų paversti prijungtų produktų labiau bendriniais. Jos užduotis – pašalinti pakartotinę inžineriją iš dalių, kurios nesukuria diferenciacijos.
Individualūs sprendimai vis dar svarbūs įrenginio elgsenai, konkrečios srities logikai, darbo eigoms, naudotojo patirčiai, specializuotoms integracijoms ir tam, kaip konkretus produktas sąveikauja su fiziniu pasauliu. Būtent šiose srityse inžineriniai sprendimai gali padaryti vieną produktą reikšmingai geresnį už kitą.
Aplinkinė darbinė santechnika retai nusipelno vienodo dėmesio. To paties įrenginio pagrindinei ir pramoninei versijai gali reikėti skirtingų jutiklių, valdiklių ir sąsajų, tačiau joms neturėtų reikėti atskirų būdų įrenginiams identifikuoti, programinės įrangos versijoms sekti ar įrenginių parkui valdyti.
Verčiau norėčiau, kad inžinieriai tą laiką skirtų produkto elgsenos lauke tobulinimui, o ne komandos jau sukurtos mechanikos atkūrimui kitam produktui. Bendras pagrindas nesumažina individualios inžinerijos galimybių; jis apsaugo šias pastangas nuo infrastruktūros eikvojimo.
Tikrasis išbandymas įvyksta, kai komanda pradeda kurti antrąjį produktą.
Gera platforma leidžia sukurti kitą produktą lengviau nei pirmąjį.
Jei antrajam produktui reikia beveik tiek pat platformos darbo, kiek ir pirmajam, iš tikrųjų pakartotinai panaudota labai mažai.
Naujas variantas turėtų paveldėti nepasikeitusias veiklos modelio dalis: aprūpinimo srautus, tapatybę, gyvavimo ciklo mechaniką, įrenginių parko įrankius, programinės įrangos procesus, palaikymo matomumą ir įprastas integracijas. Inžinerinės pastangos tada skiriamos skirtumams – galbūt naujam jutiklių paketui, kitai valdymo darbo eigai ar klientui pritaikytai integracijai – užuot rekonstravus pagrindus.
Nauja aparatinės įrangos karta daro tą pačią idėją dar didesnį spaudimą. Jos galimybės gali gerokai pasikeisti, o senesni įrenginiai ir toliau veiks. Brandi platforma gali palaikyti abu, neverčiant komandos išlaikyti dviejų atskirų platformų rinkinių, kuriuos klientai vis dar suvokia kaip vieną produktų šeimą.
Visa tai nereikalauja vienos monolitinės sistemos. Skirtingiems produktams vis tiek gali reikėti aiškių architektūrinių ribų. Svarbu vengti antrojo tos pačios inžinerinės atsakomybės įgyvendinimo be rimtos priežasties.
Būtent tada platforma tampa turtu, o ne sukauptomis pridėtinėmis išlaidomis. Palaikymo komandai reikia suprasti mažiau lygiagrečių įrankių, išleidimai vyksta nuosekliau, o kito produkto pridėjimas tampa kontroliuojamu plėtiniu, o ne dar viena serverio sistema, kurią įmonė paveldi neribotą laiką.
Platformą traktuokite kaip produkto architektūros dalį
Fiziniai produktai kuriami atsižvelgiant į pataisymus, tinkamumą naudoti, gaminamumą ir būsimus pokyčius. Prijungtiems produktams reikalinga ta pati disciplina programinės įrangos pusėje.
Pirmoji serverio dalis gali būti laikina. Taip pat gali būti ir pirmasis parengimo scenarijus ar palaikymo įrankis. Tame nėra nieko blogo. Problemos prasideda, kai ši laikina mechanika tyliai tampa nuolatine architektūra, o pats produktas toliau tobulėja.
Tuo metu prijungtas produktas nebėra tik aparatinė įranga, programinė-aparatinė įranga ir programa. Jis taip pat priklauso nuo infrastruktūros, kuri identifikuoja kiekvieną įrenginį, supranta jo galimybes, pritaiko tinkamą konfigūraciją, palaiko atnaujinimus ir padeda komandoms diagnozuoti problemas praėjus metams po išsiuntimo.
Kai šis sluoksnis traktuojamas kaip produkto architektūra, skirtumas tampa aiškesnis: standartinė mechanika lieka daugkartinio naudojimo, o individualus darbas skirtas tam, kas iš tikrųjų skiria vieną produktą ar produktų šeimą nuo kito.
Stipriausia platforma yra ne tik ta, kuri leidžia sukurti pirmąjį prijungtą produktą. Ji leidžia inžinierių komandai sukurti antrą, trečią ir ketvirtą produktus, kiekvieną kartą nepaveldint naujos serverio sistemos.
