Ang isang konektadong produkto ay maaaring magmukhang tapos na bago pa man makumpleto ang inhinyeriya sa paligid nito. Ang prototype ay matatag, ang data ay umaabot sa cloud, ang app ay nagpapakita ng mga tamang halaga, at ang unang batch ng mga device ay nasa kamay na ng mga user. Sa puntong iyon, ang backend ay maaaring sapat pa ring simple upang malaman ng team ang halos bawat device nang paisa-isa. Ang provisioning ay maaaring pangasiwaan gamit ang isang script, ang mga pagbabago sa configuration ay maaaring gawin nang manu-mano, at kung may mangyaring hindi maganda, ang isang engineer ay karaniwang direktang masusubaybayan ang problema.
Pagkatapos ay kailangan na itong magsimulang mamuhay sa totoong mundo. Lumilitaw ang pangalawang rebisyon sa hardware. Ginagamit pa rin ng ilang customer ang unang rebisyon. Nagsisimulang mag-iba-iba ang mga bersyon ng firmware. Kailangan ng bagong configuration para sa ibang customer o merkado, habang ang mga lumang device ay nangangailangan pa rin ng mga update at suporta.
Walang anumang bagay na kinakailangang sira. Ang software sa likod ng device ay mayroon nang sariling lifecycle.
Madaling makaligtaan ang transisyong iyan dahil ang prototype ay maaaring patuloy na gumana nang perpekto. Ngunit kapag maraming bersyon ng iisang pisikal na produkto ang kinailangang magsabay sa larangan, ang backend ay hindi na lamang imprastraktura sa likod ng hardware. Ito ay nagiging bahagi na mismo ng arkitektura ng produkto.
Ang isang gumaganang konektadong prototype ay hindi pa isang scalable na produkto
Ang isang prototype ay may mahalagang trabaho: patunayan na ang sistema ay gumagana nang tuluyan. Ginagampanan ng device ang pangunahing tungkulin nito, nakikipag-ugnayan ang firmware sa backend, dumarating ang telemetry kung saan ito dapat dumarating, ang mga command ay babalik, at inilalantad ng isang mobile o web interface ang functionality sa isang user.
Ang karaniwang hindi nito napapatunayan ay kung gaano kahusay na pinangangasiwaan ng parehong sistema ang pagkakaiba-iba.
Ang unang dalawampung device ay maaaring gumamit ng parehong firmware, idisenyo ayon sa parehong rebisyon ng hardware, at i-configure ng parehong mga inhinyero. Sa yugtong iyon, ang manu-manong pagpaparehistro, direktang pagbabago sa configuration, o isang maliit na onboarding script ay maaaring maging lubos na makatuwiran. Ang pagbuo ng production-grade tooling bago pa man mapatunayan ng produkto ang sarili nito ay maaaring maging napaaga.
Binabago ng scale ang problema. Nananatiling offline ang mga device, pinapalitan, nagpapatakbo ng iba't ibang firmware, at nangangailangan ng iba't ibang configuration ng customer. Kailangang matukoy ng support ang pagkakaiba ng unit na hindi kailanman na-provision nang tama mula sa unit na mali ang pagkaka-configure o sadyang hindi maabot.
Ang utang sa prototype ay kadalasang nagsisimula sa ganitong paraan: hindi sa isang masamang desisyon, kundi sa isang pansamantalang desisyon na nananatili sa lugar pagkatapos na mailipat ang produkto. At isa sa mga unang bagay na nagtutulak sa transisyon na iyon na makita ay ang hardware mismo. Ang isang bagong rebisyon ay hindi lamang pinapalitan ang luma; kailangan itong umiral kasama nito.
Ang bawat rebisyon ng hardware ay lumilikha ng problema sa lifecycle ng software
Bihirang dumating ang isang bagong rebisyon sa hardware bilang isang malinis na kapalit para sa luma. Sa pagsasagawa, ang parehong bersyon ay nananatili sa larangan, minsan ay sa loob ng maraming taon. Magdagdag ng isang transition batch, ilang sangay ng firmware, at mga configuration na partikular sa customer, at ang fleet ay mabilis na magiging mas magkakaiba kaysa sa iminumungkahi ng orihinal na modelo ng produkto.
Hindi na kayang ituring ng software layer ang bawat unit bilang isang abstraktong "device." Kailangan nitong malaman kung ano ang kayang gawin ng partikular na unit na iyon.
Ang isang binagong board ay maaaring gumamit ng ibang sensor, communication module, o controller. Ang isang command na balido para sa pinakabagong bersyon ay maaaring hindi suportado ng mas nauna. Maaaring magbago ang mga halaga ng calibration. Maaaring magbago ang mga limitasyon sa configuration. Ang isang firmware package na angkop para sa isang henerasyon ay maaaring hindi ligtas para sa isa pa.
Ganito na ang paraan ng paggamit ng mga pisikal na inhinyero ng produkto. Dalawang bahagi na halos magkapareho ang hitsura ay hindi maaaring palitan kung magkaiba ang kanilang mga rebisyon, tolerance, o detalye. Ang mga konektadong produkto ay lumilikha ng parehong problema sa panig ng software: ang platform ay nangangailangan ng isang maaasahang paraan upang maunawaan kung aling bersyon ng pisikal na produkto ang kinakausap nito at kung anong mga patakaran ang naaangkop dito.
Isaalang-alang ang isang produkto na ang unang rebisyon ay gumagamit ng isang pamamaraan ng pagkakalibrate habang ang pangalawa ay nagpapakilala ng isang bagong sensor at isang iba't ibang hanay ng mga parameter. Para sa customer, ang parehong yunit ay maaaring pareho pa rin ang produkto. Para sa platform, hindi maaaring pareho sila.
Kung ang mga pagkakaibang iyon ay hindi tahasang ipinapakita, may posibilidad na makapasok ang mga ito sa lohika ng aplikasyon bilang mga espesyal na kaso. Sinusuri ng isang workflow ang isang hanay ng serial-number. Ang isa naman ay gumagamit ng bersyon ng firmware bilang proxy para sa pagbuo ng hardware. Ang pangatlo ay naglalaman ng isang exception na idinagdag matapos matuklasan ng suporta ang isang mas lumang batch na kumikilos nang iba sa field. Wala sa mga pag-aayos na ito ang mukhang mapanganib nang mag-isa, ngunit kapag pinagsama-sama, ginagawang mas mahirap isipin ang bawat pagbabago sa hinaharap.
Bihirang mawala ang mga lumang hardware sa tamang oras. Natural na nakatuon ang mga product team sa pinakabagong rebisyon, habang ang mga customer ay kadalasang nagpapanatili ng mga naunang bersyon nang mas matagal kaysa sa inaasahan. Samakatuwid, kailangang suportahan ng platform ang ilang henerasyon nang sabay-sabay sa halip na ipagpalagay na ang naka-install na base ay magtatagpo sa iisang kasalukuyang estado.
Kapag nangyari iyon, ang ebolusyon ng hardware at pamamahala ng lifecycle ng software ay hindi na mapaghihiwalay. Kailangang malaman ng platform hindi lamang kung nasaan ang isang device at kung ito ay online, kundi pati na rin kung ano ito, ano ang maaari nitong patakbuhin, paano ito dapat i-configure, at kung aling mga pagbabago ang ligtas na ilapat.
At bago masagot nang maaasahan ang alinman sa mga tanong na iyon, kailangang pumasok muna ang bawat device sa sistema sa pare-parehong paraan.
Ang provisioning ay kung saan ang manual engineering ay humihinto sa pag-scale
Mukhang simple ang paglalaan kapag maliit ang fleet: lumikha ng record ng device, maglagay ng serial number, bumuo ng mga credential, italaga ang unit sa isang customer, maglapat ng configuration, at magpatuloy. Para sa ilang dosenang device, ang manu-manong paghawak ng ilan dito ay maaaring tamang pagpipilian pa rin.
Gayunpaman, sa antas ng produksyon, ang provisioning ay nasa interseksyon ng pagkakakilanlan ng device, mga kredensyal, pagmamay-ari, configuration, at estado ng lifecycle. Ang isang pagkakamaling nagawa habang onboarding ay maaaring makaapekto sa kung paano pinapatakbo at sinusuportahan ang unit kahit matagal na itong umalis sa pabrika.
Maaaring hindi na tumutugma ang isang spreadsheet sa aktwal na naka-install. Kailangan ng isang kapalit na device ang tamang customer association nang hindi namamana ng maling pagkakakilanlan. Ang mga factory reset ay lumilikha ng isa pang landas sa proseso. Maaaring magtalaga ang isang installer ng isang unit sa maling account, na nag-iiwan sa suporta upang matukoy kung ito ay offline, mali ang pagkaka-provision, o sadyang gumagamit lamang ng maling configuration.
Kapag ang pagsagot sa mga tanong na iyon ay regular na nangangailangan ng isang developer na siyasatin ang isang database o magpatakbo ng isang internal na script, ang proseso ay tumigil sa pag-scale gamit ang produkto.
Ang pagdoble ay isa pang babala. Ang bawat variant ng produkto ay nagsisimulang makakuha ng sarili nitong onboarding script, configuration tool, o installer workflow. Ang mga pagkakaibang iyon ay maaaring mukhang maliit, ngunit ang pinagbabatayan na responsibilidad ay pareho. Ang provisioning ay naging reusable platform infrastructure sa halip na isang gawain sa pag-setup na nakakabit sa isang partikular na device.
At bihirang ito lamang ang kakayahang kailangang magamit muli.
Ang platform layer ay dapat maging magagamit muli na imprastraktura
Kapag ang ilang produkto o rebisyon sa hardware ay may parehong pangunahing pangangailangan, ang ilang kakayahan ng software ay hindi na partikular sa produkto. Ang pagkakakilanlan ng device, provisioning, koneksyon, telemetry, paghahatid ng firmware, estado ng lifecycle, visibility ng fleet, at mga diagnostic ay magagandang halimbawa. Ang muling pagbuo ng mga ito para sa bawat bagong variant ay lumilikha ng mas maraming code at mas maraming operational path na dapat panatilihin nang hindi ginagawang mas kakaiba ang produkto mismo.
Bihirang magtakda ang mga pangkat na lumikha ng ganitong pagdoble. Naipon ang maliliit na pagkakaiba sa bawat produkto hanggang sa mapanatili ng pangkat ang ilang implementasyon ng kung ano ang naging parehong responsibilidad sa inhinyeriya.
Ang isang mas malinis na hangganan ay ang paghiwalayin ang product layer mula sa platform layer. Ang product layer ay naglalaman ng mga gawi, daloy ng trabaho, interface, integrasyon, at domain logic na nagpapahalaga sa isang partikular na device. Ang platform layer ang humahawak sa mga mekanika na dapat manatiling pare-pareho kahit na nagbabago ang hardware.
Habang lumalagpas ang mga konektadong produkto sa kanilang unang paglabas, ang paglalaan ng device, pamamahala ng lifecycle ng device, pamamahala ng fleet, at support tooling ay nagiging ibinahaging imprastraktura sa halip na mga detalye ng proyekto na minsanan lamang gawin. Ang isang IoT PaaS para sa mga negosyo ay maaaring magbigay ng magagamit muli na layer ng platform sa maraming produkto o variant ng produkto, na humahawak sa karaniwang pamamahala ng device at data sa pamamagitan ng mga magagamit muli na building block habang pinapanatili ng mga engineering team ang kanilang custom na pagsisikap na nakatuon sa hardware, workflow, at karanasan ng user.
Ang isang karaniwang pundasyon ay kailangan pa ring mag-iwan ng puwang para sa mga tunay na pagkakaiba ng produkto. Ang isang bagong device ay maaaring mangailangan ng ibang modelo ng data, daloy ng configuration, integration, o control logic, at ang mga pagkakaibang iyon ay dapat manatiling madaling ipakilala. Ang layunin ay iwasan lamang na maging sanhi ng pagkaantala ng bawat pagkakaiba sa isa pang device registry, telemetry pipeline, provisioning mechanism, o hanay ng mga tool sa pamamahala ng fleet.
Ang plataporma ay maaaring magmukhang nasa ibabaw habang binubuo ng pangkat ang unang produkto at parang isang asset pagdating ng pangalawa o pangatlo. Kapag nailagay na ang mga karaniwang mekanismo ng operasyon, maaaring magmana ang isang bagong variant ng pundasyon sa halip na magkaroon ng isa pang backend na kailangang panatilihin ng pangkat habang buhay ng produktong iyon.
Panatilihin ang pasadyang inhinyeriya kung saan ang produkto ay talagang naiiba
Hindi dapat gawing mas generic ng isang reusable platform ang mga konektadong produkto. Ang trabaho nito ay alisin ang paulit-ulit na inhinyeriya mula sa mga bahaging hindi lumilikha ng pagkakaiba-iba.
Ang custom effort ay nabibilang pa rin sa pag-uugali ng device, domain-specific logic, mga workflow, karanasan ng user, mga espesyalisadong integrasyon, at ang paraan ng pakikipag-ugnayan ng isang partikular na produkto sa pisikal na mundo. Iyan mismo ang mga aspeto kung saan ang mga pagpipilian sa engineering ay maaaring gawing mas makabuluhan ang isang produkto kaysa sa iba.
Ang bihirang nararapat sa parehong pagtrato ay ang nakapalibot na tubo ng tubig. Ang isang pangunahing bersyon at isang pang-industriya na bersyon ng iisang makina ay maaaring mangailangan ng magkaibang sensor, kontrol, at interface, ngunit hindi sila dapat mangailangan ng magkahiwalay na paraan upang matukoy ang mga device, subaybayan ang mga bersyon ng firmware, o pamahalaan ang isang fleet.
Mas gugustuhin ko pang gugulin ng mga inhinyero ang oras na iyon sa pagpino kung paano gumagana ang produkto sa larangan kaysa sa muling pagbuo ng mga mekanika na mayroon na ang koponan para sa isa pang produkto. Ang isang pinagsasaluhang pundasyon ay hindi nakakabawas sa saklaw para sa custom engineering; pinoprotektahan nito ang pagsisikap na iyon mula sa pagkaubos ng imprastraktura.
Ang tunay na pagsubok ay darating kapag sinimulan ng koponan ang produktong pangalawa.
Ang isang mahusay na plataporma ay ginagawang mas madali ang susunod na produkto kaysa sa una
Kung ang produktong dalawa ay nangangailangan ng halos parehong platform work gaya ng produktong una, kakaunti lang ang aktwal na nagamit muli.
Dapat na kayang manahin ng isang bagong variant ang mga bahagi ng operating model na hindi nagbago: mga daloy ng provisioning, pagkakakilanlan, mekanika ng lifecycle, mga tool sa fleet, mga proseso ng firmware, kakayahang makita ang suporta, at mga karaniwang integrasyon. Pagkatapos, ang pagsisikap sa engineering ay pumapasok sa mga pagkakaiba — marahil isang bagong pakete ng sensor, isa pang daloy ng trabaho sa pagkontrol, o isang integrasyon na partikular sa customer — sa halip na muling buuin ang pundasyon.
Mas mabigat na pressure ang ilalagay ng bagong henerasyon ng hardware sa parehong ideya. Maaaring magbago nang malaki ang mga kakayahan nito habang nananatiling aktibo sa larangan ang mga lumang yunit. Kayang suportahan ng isang mature na plataporma ang pareho nang hindi pinipilit ang koponan na magpanatili ng dalawang magkahiwalay na platform stack para sa kung ano ang itinuturing pa rin ng mga customer bilang isang pamilya ng produkto.
Hindi nangangailangan ng iisang monolitikong backend ang lahat ng ito. Maaaring kailanganin pa rin ng iba't ibang produkto ang malinaw na mga hangganan sa arkitektura. Ang mahalaga ay ang pag-iwas sa pangalawang pagpapatupad ng parehong responsibilidad sa inhinyeriya nang walang matibay na dahilan.
Doon nagiging isang asset ang platform sa halip na naipon na overhead. Mas kaunting parallel tools ang kailangang intindihin sa suporta, mas pare-pareho ang mga landas na sinusunod ng mga release, at ang pagdaragdag ng isa pang produkto ay nagiging isang kontroladong extension sa halip na isa pang backend na minana ng kumpanya nang walang katiyakan.
Ituring ang plataporma bilang bahagi ng arkitektura ng produkto
Ang mga pisikal na produkto ay dinisenyo nang isinasaalang-alang ang mga rebisyon, kakayahang magamit, kakayahang magawa, at mga pagbabago sa hinaharap. Ang mga konektadong produkto ay nangangailangan ng parehong disiplina sa aspeto ng software.
Maaaring pansamantala ang unang backend. Gayundin ang unang provisioning script o support tool. Walang likas na mali doon. Nagsisimula ang mga problema kapag ang mga pansamantalang mekanismong iyon ay tahimik na nagiging permanenteng arkitektura habang ang produkto mismo ay patuloy na nagbabago.
Sa panahong iyon, ang konektadong produkto ay hindi na lamang hardware, firmware, at isang app. Nakadepende rin ito sa imprastraktura na tumutukoy sa bawat device, nakakaintindi sa mga kakayahan nito, naglalapat ng tamang configuration, sumusuporta sa mga update, at tumutulong sa mga team na masuri ang mga problema ilang taon pagkatapos ng pagpapadala.
Kapag ang layer na iyon ay itinuring na arkitektura ng produkto, nagiging mas malinaw ang paghahati: ang mga karaniwang mekanika ay nananatiling magagamit muli, habang ang mga pasadyang gawain ay pumapasok sa kung ano talaga ang nagpapaiba sa isang produkto o pamilya ng produkto mula sa iba.
Ang pinakamalakas na plataporma ay hindi lamang ang siyang nagbibigay-daan sa unang konektadong produkto na maging posible. Ito ay ang siyang nagbibigay-daan sa pangkat ng inhinyero na bumuo ng pangalawa, pangatlo, at pang-apat nang hindi namamana ng bagong backend sa bawat pagkakataon.
