Savienots produkts var izskatīties pabeigts ilgi pirms tam, kad ir pabeigta ar to saistītā inženierija. Prototips ir stabils, dati sasniedz mākoni, lietotne rāda pareizās vērtības, un pirmā ierīču partija jau ir lietotāju rokās. Šajā brīdī aizmugursistēma joprojām var būt pietiekami vienkārša, lai komanda zinātu gandrīz katru ierīci atsevišķi. Nodrošināšanu var veikt ar skriptu, konfigurācijas izmaiņas var veikt manuāli, un, ja kaut kas neizdodas, inženieris parasti var tieši izsekot problēmai.
Tad tam jāsāk dzīvot reālajā pasaulē. Parādās otrā aparatūras versija. Daži klienti joprojām izmanto pirmo versiju. Programmatūras versijas sāk atšķirties. Dažādam klientam vai tirgum ir nepieciešama jauna konfigurācija, savukārt vecākām ierīcēm joprojām ir nepieciešami atjauninājumi un atbalsts.
Nekas nav obligāti salūzis. Ierīces programmatūrai vienkārši ir savs dzīves cikls.
Šo pāreju ir viegli nepamanīt, jo prototips var turpināt darboties nevainojami. Taču, tiklīdz laukā līdzās pastāv vairākām viena un tā paša fiziskā produkta versijām, aizmugursistēma vairs nav tikai infrastruktūra aiz aparatūras. Tā kļūst par daļu no paša produkta arhitektūras.
Darbojošs savienots prototips vēl nav mērogojams produkts
Prototipam ir svarīgs uzdevums: pierādīt, ka sistēma darbojas no sākuma līdz beigām. Ierīce veic savu pamatfunkciju, programmaparatūra sazinās ar aizmugursistēmu, telemetrija nonāk paredzētajā vietā, komandas veic atgriešanos, un mobilā vai tīmekļa saskarne nodrošina funkcionalitāti lietotājam.
Parasti tā nav pierādījusi, cik labi viena un tā pati sistēma tiek galā ar dažādību.
Pirmās divdesmit ierīces var darboties ar vienu un to pašu programmaparatūru, būt veidotas ar vienu un to pašu aparatūras versiju un konfigurētas to pašu inženieru. Šajā posmā manuāla reģistrācija, tiešas konfigurācijas izmaiņas vai neliels ieviešanas skripts var būt pilnīgi saprātīga. Ražošanas līmeņa rīku izveide, pirms produkts ir pierādījis savu efektivitāti, var būt pāragra.
Mērogošana maina problēmu. Ierīces paliek bezsaistē, tiek nomainītas, darbojas ar atšķirīgu programmaparatūru un tām ir nepieciešamas dažādas klientu konfigurācijas. Atbalsta dienestam ir jānošķir ierīce, kas nekad nav pareizi nodrošināta, no ierīces, kas ir nepareizi konfigurēta vai vienkārši nesasniedzama.
Prototipu parāds bieži sākas šādi: nevis ar sliktu lēmumu, bet gan ar pagaidu lēmumu, kas paliek spēkā pēc tam, kad produkts ir attīstījies tālāk. Un viena no pirmajām lietām, kas liek šai pārejai parādīties redzeslokā, ir pati aparatūra. Jauna versija ne tikai aizstāj veco; tai ir jāpastāv līdzās tai.
Katra aparatūras pārskatīšana rada programmatūras dzīves cikla problēmu
Jauna aparatūras versija reti kad tiek piegādāta kā pilnīga vecās versijas nomaiņa. Praksē abas versijas paliek darbībā, dažreiz gadiem ilgi. Pievienojiet pārejas partiju, dažas programmaparatūras atzarus un klientam specifiskas konfigurācijas, un iekārtu parks ātri kļūst daudzveidīgāks, nekā liecina sākotnējais produkta modelis.
Programmatūras slānis vairs nevar apstrādāt katru vienību kā abstraktu “ierīci”. Tam ir jāzina, ko šī konkrētā vienība spēj darīt.
Pārskatītā plate var izmantot citu sensoru, komunikācijas moduli vai kontrolieri. Komanda, kas ir derīga jaunākajai versijai, var netikt atbalstīta iepriekšējā versijā. Kalibrēšanas vērtības var mainīties. Konfigurācijas ierobežojumi var mainīties. Programmatūras pakotne, kas piemērota vienai paaudzei, var būt nedroša citai.
Fizisko produktu inženieri jau strādā šādā veidā. Divas komponentes, kas izskatās gandrīz identiskas, nav savstarpēji aizvietojamas, ja to versijas, pielaides vai specifikācijas atšķiras. Savienotie produkti rada to pašu problēmu programmatūras pusē: platformai ir nepieciešams uzticams veids, kā saprast, ar kuru fiziskā produkta versiju tā sazinās un kādi noteikumi uz to attiecas.
Apsveriet produktu, kura pirmajā versijā tiek izmantota viena kalibrēšanas procedūra, bet otrajā versijā tiek ieviests jauns sensors un atšķirīgs parametru kopums. Klientam abas ierīces joprojām var būt viens un tas pats produkts. Platformai tās nevar būt.
Ja šīs atšķirības netiek skaidri attēlotas, tās mēdz iesūkties lietojumprogrammu loģikā kā īpaši gadījumi. Viena darbplūsma pārbauda sērijas numuru diapazonu. Cita izmanto programmaparatūras versiju kā starpniekserveri aparatūras ģenerēšanai. Trešā satur izņēmumu, kas pievienots pēc tam, kad atbalsta dienests atklāja vecāku partiju, kas darbības laikā darbojās atšķirīgi. Neviens no šiem labojumiem pats par sevi neizskatās īpaši bīstams, taču kopā tie apgrūtina visu turpmāko izmaiņu pamatošanu.
Vecāka aparatūra reti kad pazūd pēc grafika. Produktu komandas, protams, koncentrējas uz jaunāko versiju, savukārt klienti bieži vien patur vecākas versijas daudz ilgāk nekā paredzēts. Tāpēc platformai ir jāatbalsta vairākas paaudzes vienlaikus, nevis jāpieņem, ka instalētā bāze kādreiz saplūdīs ar vienu pašreizējo stāvokli.
Kad tas notiek, aparatūras evolūcija un programmatūras dzīves cikla pārvaldība kļūst nedalāmas. Platformai ir jāzina ne tikai ierīces atrašanās vieta un pieejamība, bet arī tas, kas tā ir, ko tā var darbināt, kā tā jākonfigurē un kuras izmaiņas ir droši piemērot.
Un pirms uz kādu no šiem jautājumiem var sniegt ticamas atbildes, katrai ierīcei sistēmā ir jāievadās konsekventā veidā.
Nodrošināšana ir vieta, kur manuālā inženierija aptur mērogošanu
Nodrošināšana šķiet vienkārša, ja ierīču parks ir neliels: izveidojiet ierīces ierakstu, ievadiet sērijas numuru, ģenerējiet akreditācijas datus, piešķiriet ierīci klientam, lietojiet konfigurāciju un turpiniet. Dažiem desmitiem ierīču manuāla apstrāde joprojām var būt pareizā izvēle.
Tomēr ražošanas mērogā nodrošināšana notiek ierīces identitātes, akreditācijas datu, īpašumtiesību, konfigurācijas un dzīves cikla stāvokļa krustpunktā. Kļūda, kas pieļauta ieviešanas laikā, var ietekmēt ierīces darbību un atbalstu ilgi pēc tās atstāšanas no rūpnīcas.
Izklājlapa var vairs neatbilst tam, kas faktiski ir instalēts. Aizvietošanas ierīcei ir nepieciešama pareiza klienta saistība, nepārmantojot nepareizu identitāti. Rūpnīcas atiestatīšana izveido vēl vienu ceļu šajā procesā. Instalētājs var piešķirt ierīci nepareizam kontam, atstājot atbalsta dienestam iespēju noteikt, vai tā ir bezsaistē, nepareizi nodrošināta vai vienkārši ir nepareizā konfigurācijā.
Kad atbilde uz šiem jautājumiem regulāri prasa, lai izstrādātājs pārbaudītu datubāzi vai palaistu iekšēju skriptu, process vairs nav piemērojams produktam.
Dublēšanās ir vēl viena brīdinājuma zīme. Katrs produkta variants sāk iegūt savu ieviešanas skriptu, konfigurācijas rīku vai instalēšanas darbplūsmu. Šīs atšķirības var šķist nelielas, taču pamatā esošā atbildība ir tāda pati. Nodrošināšana ir kļuvusi par atkārtoti izmantojamu platformas infrastruktūru, nevis iestatīšanas uzdevumu, kas pievienots konkrētai ierīcei.
Un tā reti ir vienīgā spēja, kas ir jāizmanto atkārtoti.
Platformas slānim vajadzētu kļūt par atkārtoti izmantojamu infrastruktūru
Kad vairākiem produktiem vai aparatūras versijām ir vienādas pamatvajadzības, dažas programmatūras iespējas vairs nav specifiskas konkrētam produktam. Labi piemēri ir ierīces identitāte, nodrošināšana, savienojamība, telemetrija, programmaparatūras piegāde, dzīves cikla stāvoklis, flotes redzamība un diagnostika. To atkārtota izveide katram jaunam variantam rada vairāk koda un vairāk darbības ceļu, kas jāuztur, nepadarot pašu produktu atšķirīgāku.
Komandas reti kad cenšas radīt šādu dublēšanos. Katram produktam uzkrājas nelielas atšķirības, līdz komanda uztur vairākas ieviešanas tam, kas ir kļuvis par vienu un to pašu inženiertehnisko atbildību.
Skaidrāka robeža ir atdalīt produkta slāni no platformas slāņa. Produkta slānis satur uzvedību, darbplūsmas, saskarnes, integrācijas un domēna loģiku, kas padara konkrētu ierīci vērtīgu. Platformas slānis apstrādā mehāniku, kurai jāpaliek nemainīgai pat mainoties aparatūrai.
Tā kā savienotie produkti tiek izlaisti tālāk par savu pirmo izlaidumu, ierīču nodrošināšana, ierīču dzīves cikla pārvaldība, autoparka pārvaldība un atbalsta rīki kļūst par koplietojamu infrastruktūru, nevis vienreizējām projekta detaļām. IoT PaaS uzņēmumiem var nodrošināt šo atkārtoti izmantojamo platformas slāni vairākiem produktiem vai produktu variantiem, apstrādājot standarta ierīču un datu pārvaldību, izmantojot atkārtoti izmantojamus pamatelementus, savukārt inženieru komandas koncentrējas uz pielāgošanas darbu uz aparatūru, darbplūsmām un lietotāja pieredzi.
Kopīgam pamatam joprojām ir jāatstāj vieta reālām produktu atšķirībām. Jaunai ierīcei var būt nepieciešams atšķirīgs datu modelis, konfigurācijas plūsma, integrācija vai vadības loģika, un šīm atšķirībām jābūt viegli ieviešamām. Mērķis ir vienkārši izvairīties no tā, lai katra atšķirība tiktu ievilkta citā ierīču reģistrā, telemetrijas cauruļvadā, nodrošināšanas mehānismā vai ierīču parka pārvaldības rīku komplektā.
Kamēr komanda veido pirmo produktu, platforma var šķist kā papildu izdevumi, bet, veidojot otro vai trešo produktu, – kā aktīvs. Kad kopīgā darbības mehānika ir ieviesta, jauns variants var mantot funkcionējošu pamatu, nevis ierasties ar citu aizmugursistēmu, kas komandai būs jāuztur visu atlikušo produkta dzīves ciklu.
Saglabājiet pielāgotu inženieriju tur, kur produkts faktiski atšķiras
Atkārtoti izmantojamai platformai nevajadzētu padarīt savienotus produktus vispārīgākus. Tās uzdevums ir novērst atkārtotu inženieriju no detaļām, kas nerada diferenciāciju.
Pielāgošanas centieni joprojām pieder ierīces uzvedībai, konkrētai jomai raksturīgai loģikai, darbplūsmām, lietotāja pieredzei, specializētām integrācijām un veidam, kā konkrēts produkts mijiedarbojas ar fizisko pasauli. Tieši tās ir jomas, kurās inženiertehniskās izvēles var padarīt vienu produktu jēgpilni labāku par citu.
Apkārtējā santehnika reti ir pelnījusi vienādu attieksmi. Vienas un tās pašas iekārtas pamata versijai un rūpnieciskajai versijai var būt nepieciešami atšķirīgi sensori, vadības ierīces un saskarnes, taču tām nevajadzētu būt nepieciešami atsevišķi veidi, kā identificēt ierīces, izsekot programmaparatūras versijas vai pārvaldīt iekārtu parku.
Es labprātāk redzētu, ka inženieri šo laiku velta produkta uzvedības uzlabošanai reālos apstākļos, nevis pārveidojot mehāniku, kas komandai jau ir ieviesta citam produktam. Kopīgs pamats nemazina pielāgotas inženierijas iespējas; tas pasargā šo piepūli no infrastruktūras patērēšanas.
Īstais pārbaudījums notiek, kad komanda sāk darbu pie otrā produkta.
Laba platforma padara nākamo produktu vieglāku nekā pirmo.
Ja otrajam produktam ir nepieciešams gandrīz tāds pats platformas darbs kā pirmajam produktam, tad atkārtoti izmantots ir ļoti maz.
Jaunam variantam vajadzētu būt iespējai mantot tās darbības modeļa daļas, kas nav mainījušās: nodrošināšanas plūsmas, identitāti, dzīves cikla mehāniku, iekārtu parka rīkus, programmaparatūras procesus, atbalsta redzamību un kopīgās integrācijas. Pēc tam inženiertehniskie centieni tiek veltīti atšķirībām — iespējams, jaunam sensoru komplektam, citai vadības darbplūsmai vai klientam specifiskai integrācijai —, nevis pamatu rekonstrukcijai.
Jauna aparatūras paaudze rada lielāku spiedienu uz to pašu ideju. Tās iespējas var būtiski mainīties, kamēr vecākas ierīces paliek aktīvas darbībā. Nobriedusi platforma var atbalstīt abus, nepiespiežot komandu uzturēt divas atsevišķas platformu paketes tam, ko klienti joprojām uztver kā vienu produktu saimi.
Nevienam no šiem risinājumiem nav nepieciešama viena monolīta aizmugursistēma. Dažādiem produktiem joprojām var būt nepieciešamas skaidras arhitektūras robežas. Svarīgi ir izvairīties no vienas un tās pašas inženiertehniskās atbildības otrreizējas ieviešanas bez pamatota iemesla.
Tieši tad platforma kļūst par resursu, nevis uzkrātām papildu izmaksām. Atbalsta dienestam ir jāsaprot mazāk paralēlu rīku, izlaidumi tiek izstrādāti konsekventāk, un cita produkta pievienošana kļūst par kontrolētu paplašinājumu, nevis par vēl vienu aizmugursistēmu, ko uzņēmums manto uz nenoteiktu laiku.
Uztveriet platformu kā daļu no produkta arhitektūras
Fiziskie produkti tiek izstrādāti, ņemot vērā pārskatīšanas, apkalpojamības, ražojamības un nākotnes izmaiņas. Savienotajiem produktiem ir nepieciešama tāda pati disciplīna programmatūras pusē.
Pirmā aizmugursistēma var būt pagaidu. Tāpat var būt arī pirmais nodrošināšanas skripts vai atbalsta rīks. Ar to nav nekā principiāli slikta. Problēmas sākas, kad šī pagaidu mehānika klusi kļūst par pastāvīgu arhitektūru, kamēr pats produkts turpina attīstīties.
Līdz tam laikam savienotais produkts vairs nav tikai aparatūra, programmaparatūra un lietotne. Tas ir atkarīgs arī no infrastruktūras, kas identificē katru ierīci, izprot tās iespējas, piemēro pareizo konfigurāciju, atbalsta atjauninājumus un palīdz komandām diagnosticēt problēmas pat gadus pēc piegādes.
Kad šo slāni uzskata par produkta arhitektūru, dalījums kļūst skaidrāks: standarta mehānika paliek atkārtoti izmantojama, savukārt pielāgotais darbs iegulda to, kas faktiski atšķir vienu produktu vai produktu saimi no cita.
Spēcīgākā platforma nav tikai tā, kas padara iespējamu pirmā savienotā produkta izveidi. Tā ir tā, kas ļauj inženieru komandai izveidot otro, trešo un ceturto, katru reizi nemantojot jaunu aizmugursistēmu.
