Konektita produkto povas aspekti finita longe antaŭ ol la inĝenierado ĉirkaŭ ĝi estas kompleta. La prototipo estas stabila, datumoj atingas la nubon, la aplikaĵo montras la ĝustajn valorojn, kaj la unua aro da aparatoj jam estas en la manoj de la uzantoj. Tiam, la malantaŭa parto eble ankoraŭ estas sufiĉe simpla, ke la teamo konas preskaŭ ĉiun aparaton individue. Provizado povas esti pritraktita per skripto, agordaj ŝanĝoj povas esti faritaj mane, kaj se io malsukcesas, inĝeniero kutime povas rekte spuri la problemon.
Tiam ĝi devas komenci vivi en la reala mondo. Dua revizio de aparataro aperas. Kelkaj klientoj ankoraŭ uzas la unuan revizion. Firmvaraj versioj komencas diverĝi. Nova agordo estas bezonata por malsama kliento aŭ merkato, dum pli malnovaj aparatoj ankoraŭ bezonas ĝisdatigojn kaj subtenon.
Nenio estas nepre rompita. La programaro malantaŭ la aparato simple akiris propran vivciklon.
Tiun transiron facile preteratenteblas, ĉar la prototipo povas daŭre funkcii perfekte. Sed post kiam pluraj versioj de la sama fizika produkto devas kunekzisti surloke, la malantaŭa parto jam ne plu estas nur infrastrukturo malantaŭ la aparataro. Ĝi fariĝas parto de la produkta arkitekturo mem.
Funkcianta konektita prototipo ankoraŭ ne estas skalebla produkto
Prototipo havas gravan taskon: pruvi, ke la sistemo funkcias de komenco ĝis fino. La aparato plenumas sian kernan funkcion, la firmvaro komunikas kun la servilo, la telemetrio alvenas kien ĝi devus, la komandoj revenas, kaj poŝtelefona aŭ TTT-interfaco prezentas la funkciojn al uzanto.
Kion ĝi kutime ne pruvis estas kiom bone la sama sistemo traktas diversecon.
La unuaj dudek aparatoj povas ĉiuj uzi la saman firmvaron, esti konstruitaj laŭ la sama aparatara revizio, kaj esti agorditaj de la samaj inĝenieroj. En tiu stadio, mana registrado, rektaj agordaj ŝanĝoj, aŭ malgranda enkonduka skripto povas esti tute prudentaj. Krei produktad-nivelan ilaron antaŭ ol la produkto pruvis sin povas esti tro hasta.
Skalo ŝanĝas la problemon. Aparatoj restas senkonektitaj, estas anstataŭigitaj, funkciigas malsaman firmvaron, kaj postulas malsamajn klientajn agordojn. Subteno devas distingi unuon, kiu neniam estis provizita ĝuste, de unu, kiu estas miskonfigurita aŭ simple neatingebla.
Prototipa ŝuldo ofte komenciĝas tiel: ne per malbona decido, sed per provizora decido, kiu restas post kiam la produkto pluiris. Kaj unu el la unuaj aferoj, kiuj devigas tiun transiron al vidpunkto, estas la aparataro mem. Nova revizio ne simple anstataŭigas la malnovan; ĝi devas kunekzisti kun ĝi.
Ĉiu revizio de aparataro kreas problemon pri la softvara vivciklo
Nova revizio de aparataro malofte alvenas kiel pura anstataŭaĵo por la malnova. En praktiko, ambaŭ versioj restas surloke, kelkfoje dum jaroj. Aldonu transiran aron, kelkajn firmvarajn branĉojn, kaj klient-specifajn agordojn, kaj la aro rapide fariĝas pli diversa ol la originala produkta modelo sugestas.
La programara tavolo jam ne plu povas trakti ĉiun unuon kiel abstraktan "aparaton". Ĝi bezonas scii, kion tiu aparta unuo kapablas fari.
Reviziita plato povas uzi malsaman sensilon, komunikadan modulon aŭ regilon. Komando valida por la plej nova versio eble ne estas subtenata de pli frua. Kalibraj valoroj povas ŝanĝiĝi. Konfiguraj limoj povas ŝanĝiĝi. Firmvara pakaĵo taŭga por unu generacio povas esti nesekura por alia.
Fizikaj produktinĝenieroj jam laboras tiel. Du komponantoj, kiuj aspektas preskaŭ identaj, ne estas interŝanĝeblaj se iliaj revizioj, toleremoj aŭ specifoj malsamas. Konektitaj produktoj kreas la saman problemon flanke de la programaro: la platformo bezonas fidindan manieron kompreni, al kiu versio de la fizika produkto ĝi parolas kaj kiaj reguloj validas por ĝi.
Konsideru produkton, kies unua revizio uzas unu kalibran proceduron, dum la dua enkondukas novan sensilon kaj malsaman aron de parametroj. Por la kliento, ambaŭ unuoj eble ankoraŭ estas la sama produkto. Por la platformo, ili ne povas esti.
Se tiuj diferencoj ne estas reprezentitaj eksplicite, ili emas likiĝi en aplikaĵan logikon kiel specialaj kazoj. Unu laborfluo kontrolas serian numero-intervalon. Alia uzas firmvaran version kiel anstataŭanton por aparatara generado. Tria enhavas escepton aldonitan post kiam subteno malkovris pli malnovan aron kondutantan malsame surloke. Neniu el ĉi tiuj korektoj aspektas aparte danĝera per si mem, sed kune ili malfaciligas rezonadon pri ĉiu estonta ŝanĝo.
Pli malnova aparataro malofte malaperas laŭplane. Produktaj teamoj nature koncentriĝas pri la plej nova revizio, dum klientoj ofte konservas pli fruajn versiojn multe pli longe ol atendate. La platformo tial devas subteni plurajn generaciojn samtempe anstataŭ supozi, ke la instalita bazo iam ajn konverĝos al ununura nuna stato.
Post kiam tio okazas, la evoluo de aparataro kaj la administrado de la vivciklo de programaro fariĝas neapartigeblaj. La platformo bezonas scii ne nur kie aparato estas kaj ĉu ĝi estas enrete, sed ankaŭ kio ĝi estas, kion ĝi povas funkciigi, kiel ĝi devus esti agordita, kaj kiujn ŝanĝojn eblas sekure apliki.
Kaj antaŭ ol iu ajn el tiuj demandoj povas esti fidinde respondita, ĉiu aparato devas eniri la sistemon laŭ kohera maniero.
Provizado estas kie mana inĝenierado ĉesas skali
Provizado aspektas simpla kiam la floto estas malgranda: kreu aparatan rekordon, enigu serian numeron, generu akreditaĵojn, asignu la aparaton al kliento, apliku agordon, kaj daŭrigu. Por kelkaj dekduoj da aparatoj, pritrakti iujn el ĉi tio permane eble ankoraŭ estas la ĝusta elekto.
Tamen, ĉe produktada skalo, proviantado troviĝas ĉe la intersekciĝo de aparata identeco, akreditaĵoj, proprieto, konfiguracio kaj vivcikla stato. Eraro farita dum enkonduko povas influi kiel la aparato estas funkciigata kaj subtenata longe post kiam ĝi forlasas la fabrikon.
Kalkultabelo eble ne plu kongruas kun tio, kio estas efektive instalita. Anstataŭiga aparato bezonas la ĝustan klientan asocion sen heredi la malĝustan identecon. Fabrikaj restarigoj kreas alian vojon tra la procezo. Instalisto povas asigni aparaton al la malĝusta konto, lasante subtenon determini ĉu ĝi estas senkonekta, malĝuste provizita, aŭ simple portas la malĝustan agordon.
Post kiam respondi tiujn demandojn rutine postulas, ke programisto inspektu datumbazon aŭ rulu internan skripton, la procezo ĉesis skaliĝi kun la produkto.
Duobligado estas alia averta signo. Ĉiu produkta variaĵo komencas akiri sian propran enkondukan skripton, agordan ilon aŭ instalilan laborfluon. Tiuj diferencoj povas ŝajni malgrandaj, sed la subesta respondeco estas la sama. Provizado fariĝis reuzebla platforma infrastrukturo anstataŭ agorda tasko ligita al specifa aparato.
Kaj ĝi malofte estas la sola kapablo, kiu bezonas fariĝi reuzebla.
La platforma tavolo devus fariĝi reuzebla infrastrukturo
Post kiam pluraj produktoj aŭ aparataraj revizioj dividas la samajn bazajn bezonojn, iuj programaraj kapabloj ĉesas esti produktospecifaj. Aparata identeco, proviantado, konektebleco, telemetrio, firmvara liverado, vivcikla stato, flotovidebleco kaj diagnozoj estas bonaj ekzemploj. Rekonstrui ilin por ĉiu nova variaĵo kreas pli da kodo kaj pli da funkciaj vojoj por prizorgi sen igi la produkton mem pli distinga.
Teamoj malofte celas krei ĉi tiun duobligon. Malgrandaj diferencoj akumuliĝas ĉirkaŭ ĉiu produkto ĝis la teamo konservas plurajn efektivigojn de tio, kio fariĝis la sama inĝeniera respondeco.
Pli pura limo estas apartigi la produktan tavolon de la platforma tavolo. La produkta tavolo enhavas la konduton, laborfluojn, interfacojn, integriĝojn kaj domajnan logikon, kiuj igas specifan aparaton valora. La platforma tavolo prizorgas mekanikojn, kiuj devus resti koheraj eĉ kiam la aparataro ŝanĝiĝas.
Dum konektitaj produktoj progresas preter sia unua eldono, provizado de aparatoj, administrado de la vivciklo de aparatoj, administrado de flotaj aparatoj kaj subtenaj iloj fariĝas komuna infrastrukturo anstataŭ unufojaj projektaj detaloj. IoT PaaS (Interreto de Aĵoj kaj Servoj) por entreprenoj povas provizi tiun reuzeblan platforman tavolon trans pluraj produktoj aŭ produktaj variaĵoj, pritraktante norman aparatan kaj datumadministradon per reuzeblaj konstrubriketoj, dum inĝenieraj teamoj tenas siajn kutimajn klopodojn fokusitajn sur aparataro, laborfluoj kaj uzantosperto.
Komuna fundamento ankoraŭ devas lasi spacon por realaj produktaj diferencoj. Nova aparato eble bezonos malsaman datummodelon, konfiguracian fluon, integriĝon aŭ stiran logikon, kaj tiuj diferencoj devus resti facile enkondukeblaj. La celo estas simple eviti, ke ĉiu diferenco trenu laŭlonge de alia aparatregistro, telemetria dukto, provizmekanismo aŭ aro da flotadministraj iloj.
La platformo povas aspekti kiel superŝarĝo dum la teamo konstruas la unuan produkton kaj kiel aktivaĵo post la dua aŭ tria. Post kiam la komunaj funkciaj mekanismoj estas enkondukitaj, nova variaĵo povas heredi funkcian fundamenton anstataŭ alveni kun alia interna sistemo, kiun la teamo devos konservi dum la resto de la vivo de tiu produkto.
Konservu kutiman inĝenieradon kie la produkto estas efektive malsama
Reuzebla platformo ne devus igi konektitajn produktojn pli ĝeneralaj. Ĝia tasko estas forigi ripetan inĝenieradon de la partoj, kiuj ne kreas diferencigon.
Propra penado ankoraŭ apartenas al aparata konduto, domajno-specifa logiko, laborfluoj, uzanto-sperto, specialigitaj integriĝoj, kaj la maniero kiel aparta produkto interagas kun la fizika mondo. Ĝuste tiuj areoj estas kie inĝenieraj elektoj povas igi unu produkton signife pli bona ol alia.
Kio malofte meritas la saman traktadon estas la ĉirkaŭa funkcianta akvotubaro. Baza versio kaj industria versio de la sama maŝino eble bezonas malsamajn sensilojn, regilojn kaj interfacojn, sed ili ne devus postuli apartajn manierojn por identigi aparatojn, spuri firmvarajn versiojn aŭ administri floton.
Mi preferus vidi inĝenierojn pasigi tiun tempon rafinante kiel la produkto kondutas surloke ol rekonstruante mekanikojn, kiujn la teamo jam havas por alia produkto. Komuna fundamento ne reduktas la eblecon por kutima inĝenierado; ĝi protektas tiun penon de esti konsumita de infrastrukturo.
La vera testo venas kiam la teamo komencas produkton numero du.
Bona platformo faciligas la sekvan produkton ol la unuan
Se produkto numero du postulas preskaŭ la saman platforman laboron kiel produkto numero unu, tre malmulte estis fakte reuzita.
Nova variaĵo devus povi heredi la partojn de la funkcianta modelo, kiuj ne ŝanĝiĝis: provizfluojn, identecon, vivciklajn mekanikojn, flotajn ilojn, firmvarajn procezojn, subtenan videblecon kaj komunajn integriĝojn. Inĝenieraj penoj tiam iras al la diferencoj - eble nova sensora pakaĵo, alia kontrola laborfluo aŭ klient-specifa integriĝo - anstataŭ rekonstrui la fundamenton.
Nova generacio de aparataro metas la saman ideon sub pli grandan premon. Ĝiaj kapabloj povas ŝanĝiĝi konsiderinde dum pli malnovaj unuoj restas aktivaj surloke. Matura platformo povas subteni ambaŭ sen devigi la teamon konservi du apartajn platformajn stakojn por tio, kion klientoj ankoraŭ perceptas kiel unu produkta familio.
Nenio el ĉi tio postulas unu monolitan fonon. Malsamaj produktoj eble ankoraŭ bezonas klarajn arkitekturajn limojn. Gravas eviti duan efektivigon de la sama inĝeniera respondeco sen bona kialo.
Tiam la platformo fariĝas aktivaĵo anstataŭ akumulita kosto. Subteno havas malpli da paralelaj iloj por kompreni, eldonoj sekvas pli koherajn vojojn, kaj aldoni alian produkton fariĝas kontrolita etendaĵo anstataŭ alia interna servo, kiun la kompanio heredas senfine.
Traktu la platformon kiel parton de la produkta arkitekturo
Fizikaj produktoj estas desegnitaj konsiderante reviziojn, funkcieblecon, produkteblecon kaj estontajn ŝanĝojn. Konektitaj produktoj bezonas la saman disciplinon flanke de la programaro.
La unua fona sistemo povas esti provizora. Ankaŭ la unua proviza skripto aŭ subtena ilo povas. Nenio esence malbona estas pri tio. Problemoj komenciĝas kiam tiuj provizoraj mekanismoj kviete fariĝas permanenta arkitekturo dum la produkto mem daŭre evoluas.
Tiam, la konektita produkto jam ne plu estas nur aparataro, firmvaro kaj aplikaĵo. Ĝi ankaŭ dependas de la infrastrukturo, kiu identigas ĉiun aparaton, komprenas ĝiajn kapablojn, aplikas la ĝustan agordon, subtenas ĝisdatigojn kaj helpas teamojn diagnozi problemojn jarojn post la sendo.
Post kiam tiu tavolo estas traktata kiel produkta arkitekturo, la divido fariĝas pli klara: normaj mekanikoj restas reuzeblaj, dum kutima laboro eniras tion, kio efektive distingas unu produkton aŭ produktan familion de alia.
La plej forta platformo ne estas simple tiu, kiu ebligas la unuan konektitan produkton. Ĝi estas tiu, kiu permesas al la inĝeniera teamo konstrui la duan, trian kaj kvaran sen heredi novan fonon ĉiufoje.
