Verkkoon kytketty tuote voi näyttää valmiilta kauan ennen kuin sitä ympäröivä suunnittelu on valmis. Prototyyppi on vakaa, data saapuu pilveen, sovellus näyttää oikeat arvot ja ensimmäinen erä laitteita on jo käyttäjien käsissä. Tässä vaiheessa taustajärjestelmä voi olla vielä niin yksinkertainen, että tiimi tuntee lähes jokaisen laitteen erikseen. Valmistelu voidaan hoitaa skriptillä, kokoonpanomuutokset voidaan tehdä manuaalisesti, ja jos jokin epäonnistuu, insinööri voi yleensä jäljittää ongelman suoraan.
Sitten sen on alettava elää todellisessa maailmassa. Uusi laitteistoversio ilmestyy. Jotkut asiakkaat käyttävät edelleen ensimmäistä versiota. Laiteohjelmistoversiot alkavat erota toisistaan. Uusi kokoonpano tarvitaan eri asiakkaille tai markkinoille, kun taas vanhemmat laitteet tarvitsevat edelleen päivityksiä ja tukea.
Mikään ei välttämättä ole rikki. Laitteen taustalla oleva ohjelmisto on yksinkertaisesti saanut oman elinkaarensa.
Tämä siirtymä on helppo ohittaa, koska prototyyppi voi jatkaa toimintaansa täydellisesti. Mutta kun saman fyysisen tuotteen useiden versioiden on toimittava rinnakkain kentällä, taustajärjestelmä ei ole enää vain laitteiston takana oleva infrastruktuuri. Siitä tulee osa itse tuotearkkitehtuuria.
Toimiva yhdistetty prototyyppi ei ole vielä skaalautuva tuote
Prototyypillä on tärkeä tehtävä: todistaa, että järjestelmä toimii alusta loppuun. Laite suorittaa ydintehtävänsä, laiteohjelmisto kommunikoi taustajärjestelmän kanssa, telemetria saapuu perille, komennot tekevät paluumatkan ja mobiili- tai verkkokäyttöliittymä paljastaa toiminnallisuuden käyttäjälle.
Yleensä ei ole todistettu, kuinka hyvin sama järjestelmä käsittelee vaihtelua.
Ensimmäiset kaksikymmentä laitetta saattavat kaikki käyttää samaa laiteohjelmistoa, ne on rakennettu samalle laitteistoversiolle ja ne on konfiguroitu samojen insinöörien toimesta. Tässä vaiheessa manuaalinen rekisteröinti, suorat kokoonpanomuutokset tai pieni käyttöönottoskripti voivat olla täysin järkeviä. Tuotantolaatuisten työkalujen rakentaminen ennen kuin tuote on osoittanut toimivuutensa voi olla ennenaikaista.
Skaalaus muuttaa ongelman. Laitteet pysyvät offline-tilassa, ne vaihdetaan, niillä on eri laiteohjelmistot ja ne vaativat erilaisia asiakaskonfiguraatioita. Tuen on erotettava yksikkö, jota ei ole koskaan määritetty oikein, laitteesta, joka on määritetty väärin tai johon ei ole yksinkertaisesti yhteyttä.
Prototyyppivelka alkaa usein näin: ei huonolla päätöksellä, vaan väliaikaisella päätöksellä, joka jää voimaan tuotteen siirtymisen jälkeen. Ja yksi ensimmäisistä asioista, jotka pakottavat tämän siirtymän näkyviin, on itse laitteisto. Uusi versio ei yksinkertaisesti korvaa vanhaa; sen on toimittava sen rinnalla.
Jokainen laitteistopäivitys aiheuttaa ohjelmiston elinkaariongelman
Uusi laitteistopäivitys harvoin korvaa vanhan täysin. Käytännössä molemmat versiot pysyvät käytössä, joskus vuosia. Lisää siirtymäerä, muutama laiteohjelmistohaara ja asiakaskohtaiset kokoonpanot, ja laitekannasta tulee nopeasti monimuotoisempi kuin alkuperäinen tuotemalli antaa ymmärtää.
Ohjelmistokerros ei voi enää käsitellä jokaista yksikköä abstraktina "laitteena". Sen on tiedettävä, mitä kyseinen yksikkö pystyy tekemään.
Uudistettu piirilevy saattaa käyttää eri anturia, tiedonsiirtomoduulia tai ohjainta. Uusimmassa versiossa voimassa olevaa komentoa ei välttämättä tueta aiemmassa versiossa. Kalibrointiarvot voivat muuttua. Konfiguraatiorajoitukset voivat siirtyä. Yhdelle sukupolvelle sopiva laiteohjelmistopaketti ei välttämättä ole turvallinen toiselle sukupolvelle.
Fyysisten tuotteiden insinöörit työskentelevät jo tällä tavalla. Kaksi lähes identtiseltä näyttävää komponenttia eivät ole keskenään vaihdettavissa, jos niiden revisiot, toleranssit tai tekniset tiedot eroavat toisistaan. Yhdistetyt tuotteet luovat saman ongelman ohjelmistopuolella: alusta tarvitsee luotettavan tavan ymmärtää, minkä fyysisen tuotteen version kanssa se kommunikoi ja mitä sääntöjä siihen sovelletaan.
Tarkastellaan tuotetta, jonka ensimmäisessä versiossa käytetään yhtä kalibrointimenettelyä, kun taas toisessa versiossa otetaan käyttöön uusi anturi ja eri parametrit. Asiakkaalle molemmat yksiköt voivat silti olla sama tuote. Alustalle ne eivät voi olla.
Jos näitä eroja ei esitetä eksplisiittisesti, ne yleensä vuotavat sovelluslogiikkaan erikoistapauksina. Yksi työnkulku tarkistaa sarjanumeroalueen. Toinen käyttää laiteohjelmistoversiota laitteiston luomisen välityspalvelimena. Kolmas sisältää poikkeuksen, joka on lisätty sen jälkeen, kun tuki havaitsi vanhemman erän toimivan eri tavalla kentällä. Mikään näistä korjauksista ei näytä erityisen vaaralliselta yksinään, mutta yhdessä ne tekevät jokaisesta tulevasta muutoksesta vaikeamman perustella.
Vanhempaa laitteistoa harvoin katoaa aikataulussa. Tuotetiimit keskittyvät luonnollisesti uusimpaan versioon, kun taas asiakkaat usein pitävät aiempia versioita paljon odotettua pidempään. Alustan on siksi tuettava useita sukupolvia kerralla sen sijaan, että oletettaisiin, että asennettu laitekanta koskaan yhdistyy yhteen nykytilaan.
Kun näin tapahtuu, laitteiston kehitys ja ohjelmiston elinkaaren hallinta tulevat erottamattomiksi. Alustan on tiedettävä paitsi missä laite on ja onko se verkossa, myös mikä se on, mitä sillä voi ajaa, miten se tulisi konfiguroida ja mitkä muutokset ovat turvallisia tehdä.
Ja ennen kuin mihinkään näistä kysymyksistä voidaan vastata luotettavasti, jokaisen laitteen on liityttävä järjestelmään johdonmukaisesti.
Manuaalinen suunnittelu lopettaa skaalauksen provisioinnin avulla
Laitteen käyttöönotto näyttää yksinkertaiselta, kun laitekanta on pieni: luo laitetietue, syötä sarjanumero, luo tunnistetiedot, määritä laite asiakkaalle, ota käyttöön määritys ja jatka eteenpäin. Muutaman kymmenen laitteen kohdalla osan tästä manuaalinen käsittely voi silti olla oikea vaihtoehto.
Tuotantotasolla käyttöönotto kuitenkin tapahtuu laitteen identiteetin, tunnistetietojen, omistajuuden, kokoonpanon ja elinkaaren tilan leikkauspisteessä. Käyttöönoton aikana tehty virhe voi vaikuttaa laitteen toimintaan ja tukeen pitkään tehtaalta lähdön jälkeen.
Laskentataulukko ei välttämättä enää vastaa todellista asennusta. Vaihtolaite tarvitsee oikean asiakasliitoksen perimättä väärää identiteettiä. Tehdasasetusten palautus luo uuden polun prosessiin. Asentaja voi määrittää laitteen väärälle tilille, jolloin tuki selvittää, onko se offline-tilassa, väärin määritetty vai onko siinä yksinkertaisesti väärä kokoonpano.
Kun näihin kysymyksiin vastaaminen rutiininomaisesti vaatii kehittäjältä tietokannan tarkistamista tai sisäisen skriptin suorittamista, prosessi on lakannut skaalautumasta tuotteen kanssa.
Päällekkäisyys on toinen varoitusmerkki. Jokainen tuotevariantti alkaa hankkia oman käyttöönottoskriptinsä, määritystyökalunsa tai asennustyönkulkunsa. Nämä erot saattavat näyttää pieniltä, mutta taustalla oleva vastuu on sama. Käyttöönotosta on tullut uudelleenkäytettävää alustainfrastruktuuria eikä tiettyyn laitteeseen liitettyä asennustehtävää.
Ja se on harvoin ainoa ominaisuus, jota on voitava käyttää uudelleen.
Alustakerroksen tulisi muuttua uudelleenkäytettäväksi infrastruktuuriksi
Kun useilla tuotteilla tai laitteistoversioilla on samat perustarpeet, jotkin ohjelmisto-ominaisuudet lakkaavat olemasta tuotekohtaisia. Laitteen identiteetti, käyttöönotto, yhdistettävyys, telemetria, laiteohjelmiston toimitus, elinkaaren tila, laitekannan näkyvyys ja diagnostiikka ovat hyviä esimerkkejä. Niiden uudelleenrakentaminen jokaista uutta varianttia varten luo enemmän koodia ja lisää ylläpidettäviä toimintapolkuja tekemättä tuotteesta itsestään erottuvempaa.
Tiimit harvoin pyrkivät luomaan tällaista päällekkäisyyttä. Pieniä eroja kertyy jokaisen tuotteen ympärille, kunnes tiimi ylläpitää useita toteutuksia samasta suunnitteluvastuualueesta.
Selkeämpi raja on erottaa tuotekerros alustakerroksesta. Tuotekerros sisältää laitteen toiminnan, työnkulut, rajapinnat, integraatiot ja toimialueen logiikan, jotka tekevät siitä arvokkaan. Alustakerros käsittelee mekaniikkoja, joiden tulisi pysyä yhtenäisinä, vaikka laitteisto muuttuisi.
Kun verkottuneet tuotteet siirtyvät ensimmäisestä julkaisustaan eteenpäin, laitteiden käyttöönotto, laitteiden elinkaaren hallinta, laitekannan hallinta ja tukityökalut muuttuvat jaetuksi infrastruktuuriksi kertaluonteisten projektien yksityiskohtien sijaan. Yritysten IoT PaaS voi tarjota uudelleenkäytettävän alustakerroksen useille tuotteille tai tuotevarianteille, hoitaen vakiolaitteiden ja tiedonhallinnan uudelleenkäytettävien rakennuspalikoiden avulla, kun taas suunnittelutiimit keskittyvät räätälöityyn työhönsä laitteistoon, työnkulkuihin ja käyttäjäkokemukseen.
Yhteisen perustan on silti jätettävä tilaa todellisille tuote-eroille. Uusi laite saattaa tarvita erilaisen datamallin, konfigurointikulun, integroinnin tai ohjauslogiikan, ja näiden erojen käyttöönoton tulisi olla helppoa. Tavoitteena on yksinkertaisesti välttää se, että jokainen ero raahautuu mukanaan toiseen laiterekisteriin, telemetriaputkeen, provisiointimekanismiin tai laitekannanhallintatyökalujen joukkoon.
Alusta voi näyttää ylimääräiseltä työltä tiimin rakentaessa ensimmäistä tuotetta ja resurssilta toisen tai kolmannen tuotteen rakentaessa. Kun yhteiset toimintamekaniikat ovat paikoillaan, uusi variantti voi periä toimivan perustan sen sijaan, että sillä olisi oma taustajärjestelmänsä, jota tiimin on ylläpidettävä tuotteen loppuelämän ajan.
Pidä räätälöity suunnittelu siellä, missä tuote on todella erilainen
Uudelleenkäytettävän alustan ei pitäisi tehdä verkottuneista tuotteista geneerisempiä. Sen tehtävänä on poistaa toistuva suunnittelu osista, jotka eivät luo erottumista.
Räätälöinti kuuluu edelleen laitteen käyttäytymiseen, toimialakohtaiseen logiikkaan, työnkulkuihin, käyttökokemukseen, erikoistuneisiin integraatioihin ja tapaan, jolla tietty tuote on vuorovaikutuksessa fyysisen maailman kanssa. Juuri näillä osa-alueilla tekniset valinnat voivat tehdä yhdestä tuotteesta merkityksellisesti paremman kuin toisesta.
Ympäröivä putkisto ansaitsee harvoin samanlaista kohtelua. Saman koneen perusversio ja teollisuusversio saattavat tarvita erilaisia antureita, ohjaimia ja käyttöliittymiä, mutta niiden ei pitäisi vaatia erillisiä tapoja laitteiden tunnistamiseen, laiteohjelmistoversioiden seurantaan tai laitekannan hallintaan.
Mieluummin näkisin insinöörien käyttävän tuon ajan tuotteen käyttäytymisen hiomiseen kentällä kuin tiimin jo olemassa olevien mekaniikoiden uudelleenrakentamiseen toista tuotetta varten. Yhteinen perusta ei vähennä räätälöidyn suunnittelun mahdollisuuksia; se suojaa tätä työtä infrastruktuurin kulutukselta.
Todellinen testi tulee, kun tiimi aloittaa tuotteen numero kaksi.
Hyvä alusta tekee seuraavan tuotteen valmistamisesta helpompaa kuin ensimmäisen
Jos tuote numero kaksi vaatii lähes saman alustatyön kuin tuote numero yksi, sitä on itse asiassa käytetty uudelleen hyvin vähän.
Uuden variantin tulisi voida periä toimintamallin osat, jotka eivät ole muuttuneet: provisiointivirrat, identiteetti, elinkaarimekaniikka, laiteohjelmiston työkalut, laiteohjelmistoprosessit, tuen näkyvyys ja yleiset integraatiot. Suunnittelutyö keskittyy sitten eroavaisuuksiin – ehkä uuteen anturipakettiin, toiseen ohjaustyönkulkuun tai asiakaskohtaiseen integraatioon – sen sijaan, että perusta rakennettaisiin uudelleen.
Uusi laitteistosukupolvi asettaa saman idean suuremman paineen alle. Sen ominaisuudet voivat muuttua merkittävästi vanhempien yksiköiden pysyessä toiminnassa kentällä. Kypsä alusta voi tukea molempia pakottamatta tiimiä ylläpitämään kahta erillistä alustapinoa asiakkaille, jotka edelleen kokevat yhdeksi tuoteperheeksi.
Mikään tästä ei vaadi yhtä monoliittista taustajärjestelmää. Eri tuotteet saattavat silti tarvita selkeät arkkitehtoniset rajat. Tärkeää on välttää saman suunnitteluvastuun toista toteutusta ilman hyvää syytä.
Tällöin alustasta tulee voimavara eikä kertyviä lisäkustannuksia. Tukipalvelussa on vähemmän rinnakkaisia työkaluja ymmärrettävänä, julkaisut seuraavat johdonmukaisempia polkuja ja uuden tuotteen lisäämisestä tulee hallittu laajennus yrityksen loputtomiin perimän taustajärjestelmän sijaan.
Käsittele alustaa osana tuotearkkitehtuuria
Fyysiset tuotteet suunnitellaan ottaen huomioon niiden muutokset, huollettavuus, valmistettavuus ja tulevaisuuden muutokset. Verkkoon kytketyt tuotteet vaativat samanlaista kurinalaisuutta ohjelmistopuolella.
Ensimmäinen taustajärjestelmä voi olla väliaikainen. Niin voi olla myös ensimmäinen provisiointiskripti tai tukityökalu. Siinä ei ole mitään itsessään vikaa. Ongelmat alkavat, kun näistä väliaikaisista mekaniikoista tulee hiljaa pysyvä arkkitehtuuri, samalla kun itse tuote kehittyy edelleen.
Siihen mennessä verkkoon yhdistetty tuote ei ole enää vain laitteisto, laiteohjelmisto ja sovellus. Se on myös riippuvainen infrastruktuurista, joka tunnistaa jokaisen laitteen, ymmärtää sen ominaisuudet, käyttää oikeaa kokoonpanoa, tukee päivityksiä ja auttaa tiimejä diagnosoimaan ongelmia vuosia toimituksen jälkeen.
Kun tätä kerrosta käsitellään tuotearkkitehtuurina, jako selkeytyy: vakiomekaniikat pysyvät uudelleenkäytettävinä, kun taas räätälöity työ keskittyy siihen, mikä erottaa yhden tuotteen tai tuoteperheen toisesta.
Vahvin alusta ei ole pelkästään se, joka mahdollistaa ensimmäisen verkottuneeseen tuotteeseen perustuvan tuotteen. Se on se, jonka avulla suunnittelutiimi voi rakentaa toisen, kolmannen ja neljännen ilman, että hänen tarvitsee periä uutta taustajärjestelmää joka kerta.
