Tietojen minimointi on suunnittelun osaamisala
Lomake, jossa on kolmekymmentäkahdeksan kenttää
Rakennuksen kallein data ei ollut varastossa. Se oli ilmoittautumislomakkeessa. Kolmekymmentäkahdeksan kenttää kolmella eri näytöllä, sellaisen prosessin itsevarmuudella, joka oli selvinnyt useista organisaatiomuutoksista oppimatta niistä mitään. Tuotetiimi sanoi, että useimmat kentät olivat valinnaisia. Analytiikkatiimi sanoi, että joistakin niistä saattaisi olla hyötyä myöhemmin. Tukitiimi sanoi, että lisäkonteksti auttoi erikoistapauksissa. Lakiosasto sanoi, että tietosuojaseloste mainitsi keräämisen. Tekniikka sanoi, että tietokannassa oli jo valmiit sarakkeet. Kaikilla oli syynsä. Käyttäjän peukaloa särki.
Sitten saapui poistopyyntö henkilöltä, joka ei ollut koskaan saanut ilmoittautumista loppuun. Järjestelmä oli tallentanut keskeneräisen lomakkeen tilan, hylätyn istunnon metatiedot, laitetiedot, markkinoinnin kohdistuksen, validointivirheet, tukichatin katkelmat ja petospisteytyksen, jota kukaan ei muistanut lisänneensä. Osa tiedoista oli ensisijaisessa tietokannassa. Osa analytiikassa. Osa lokeissa. Osa viestijonossa, joka tyhjeni yleensä, paitsi silloin kun ei tyhjentynyt. Pyyntö ei ollut teknisesti vaikea siksi, että data oli arvokasta. Se oli vaikea siksi, että data oli päässyt järjestelmään ilman selvää syytä ja vaeltanut sitten paikkoihin, joissa oli parempaa kahvia kuin kuria.
Siksi tietojen minimointi on tekniikan alan kurinalaisuutta. Se ei ole tyylikäs lause käytäntöasiakirjassa, ei periaate, joka esitellään perehdytyksen yhteydessä, eikä taulukkolaskenta, jota käydään läpi kerran vuodessa ihmisten toimesta, joilla on sankarillinen keskittymiskyky. Se on suunnittelua siitä, mitä järjestelmään saa tulla, minkä muodon se saa ottaa, minne se saa kulkea, kuinka kauan se saa elää, kuka sitä saa nähdä, mitä siitä saa tulla ja milloin järjestelmän on kieltäydyttävä siitä. Minimointi tapahtuu ennen keräämistä, käsittelyn aikana, lokeissa, malleissa ja poistossa. Jos se tapahtuu vain asiakirjassa, sitä ei ole tapahtunut.
Vähemmän on tekninen valinta
Ihmiset pitävät minimointia usein pidättyväisyytenä, mikä on totta mutta puutteellista. Pidättyväisyys on toteutettava jossakin. Lomakkeessa on oltava vähemmän kenttiä. Tapahtumassa on oltava vähemmän ominaisuuksia. Tietomallissa on oltava tarkoitus jokaista kenttää kohti. Putkistossa on oltava validointi, joka hylkää ylimääräiset attribuutit. Mallin koulutustehtävässä on oltava kelpoisuussäännöt. Lokirivissä on oltava poistaminen. Raporttinäkymässä on oltava koostaminen. Varmuuskopiolla on oltava säilytysluokka. Viennillä on oltava laajuus. Kehittäjätyökalussa on oltava turvalliset oletusarvot. Järjestelmä, joka vain pyytää ihmisiä muistamaan vähemmän dataa, päätyy lopulta keräämään enemmän dataa, yleensä perjantaina kello 17.42, kun kiertotapa tuntuu järkevältä.
Tekninen valinta alkaa tarkoituksesta. Ei tarkoituksesta inspiroivana substantiivina, vaan tarkoituksesta operatiivisena rajoitteena. Kentällä tulisi olla ilmoitettu käyttötarkoitus, omistaja, oikeusperusta tai käytäntöperusta, arkaluonteisuusluokka, säilytysaika, alavirran kuluttajat ja poistokäyttäytyminen. Se kuulostaa byrokraattiselta, kunnes tiimi yrittää poistaa kentän ja huomaa, ettei kukaan tiedä, miksi se on olemassa. Lause "saattaa olla hyödyllinen myöhemmin" ei ole tarkoitus. Se on varastointisuunnitelma, jonka on kirjoittanut ahdistus.
Teknisten alojen tiimit ymmärtävät rajoitteet, kun ne ovat konkreettisia. Muistibudjetit, viivevaatimukset, API-sopimukset ja rajoitukset muovaavat suunnittelua, koska niitä valvotaan. Databudjetit ansaitsevat saman aseman. Palvelun tulisi tietää, mitkä kentät se saa hyväksyä. Taulun tulisi tehdä valinnaisesta keräämisestä näkyvää, ei piilottaa sitä tyhjiä arvoja sallivien sarakkeiden taakse. Putkiston tulisi epäonnistua, kun kielletty attribuutti ilmestyy. Ominaisuusvaraston tulisi tietää, voidaanko ominaisuutta käyttää analytiikkaan, mallin koulutukseen, automaattisiin päätöksiin vai vain suoraan palvelun toimittamiseen. Minimoinnista tulee todellista, kun järjestelmällä on sanottavaa ovella.
Valinnaiset kentät ovat silti kenttiä
Valinnaiset kentät aiheuttavat enemmän ongelmia kuin niiden vaatimaton nimi antaa ymmärtää. Tiimit lisäävät niitä, koska ne eivät estä käyttäjää. Se kuulostaa vaarattomalta. Mutta valinnainen data on silti luokiteltava, suojattava, testattava, poistettava, vietävä, selitettävä ja puolustettava. Se näkyy silti lokeissa. Se houkuttelee silti analytiikkaa. Se luo silti puuttuvuuden malleja, joista voi tulla signaaleja. Se monimutkaistaa silti käyttöoikeuksien hallintaa. Siitä tulee silti osa järjestelmän mielikuvaa. Valinnainen keräys on keräystä pehmeämmällä äänellä.
Vapaa teksti on lahjakkain rikoksentekijä. Lomake pyytää lisätietoja. Tukipyyntö kysyy, mitä tapahtui. Käsittelijä kirjaa hyödyllisen yksityiskohdan. Käyttäjä liittää asiakirjan. Yhtäkkiä kenttä sisältää lääketieteellisiä tietoja, ammattiliiton jäsenyyttä, velkoja, perheristiriitoja, poliittisia huomautuksia, tunnistetietoja ja vitsin, joka vanhenee huonosti oikeudenkäynnissä. Vapaa teksti voi olla tarpeen, erityisesti monimutkaisissa palveluissa. Mutta se ei ole halpaa. Se vaatii poistamisen, tarkoituksen rajat, käyttösäännöt, säilytyksen ja hakukurin. Vapaan tekstin kenttä on pieni ovi, josta koko maailma voi astua sisään, usein väärin kirjoitettuna.
Minimointi ei tarkoita valinnaisten kenttien tai vapaan tekstin kieltämistä. Se tarkoittaa niiden kustannusten tekemistä näkyviksi. Voiko prosessi toimia luokalla tekstin sijaan. Voiko kenttä olla työnkulun paikallinen ja jättää sen analytiikan ulkopuolelle. Voiko arkaluonteiset mallit havaita ja poistaa. Voiko arvo vanhentua nopeasti. Voiko käyttäjä nähdä ja korjata sen. Voiko henkilökuntaa kouluttaa olemaan liittämättä kokonaisia historia-asiakirjoja muistiinpanoon, koska kenttä on ottanut ne kohteliaasti vastaan. Tekniikan on tuettava näitä valintoja. Muuten valinnaisesta tulee pysyvää vahingossa.
Johdettu data perii ongelman
Yksi syy siihen, että minimointi tuntuu yksinkertaiselta periaatteissa ja vaikealta käytännössä, on se, että järjestelmät luovat uutta dataa. Syntymäajasta tulee ikäryhmä. Postinumerosta tulee huono-osaisuuspiste. Hakuhistoriasta tulee kiinnostusvektori. Tukikeskustelusta tulee tunneleima. Tapahtumamallista tulee petossignaali. Asiakirjasta tulee upotus. Klikkivirrasta tulee asiakaspoistuman todennäköisyys. Alkuperäinen kenttä voidaan poistaa, kun johdannainen jatkaa merkityksen kantamista. Järjestelmä ei ole poistanut tosiasiaa. Se on vaihtanut sen vaatteet.
Johdettu data voi olla vähemmän arkaluonteista kuin raakadata. Aggregointi, ryhmittely, hajautus, tokenisointi ja paikallinen ominaisuuksien erottelu voivat vähentää altistumista. Mutta johdettu data voi olla myös arkaluonteisempaa, koska se tekee väitteen, jota käyttäjä ei ole koskaan antanut. Riskipisteet, segmentit, päätellyt ominaisuudet tai suositukset voivat vaikuttaa kohteluun. Jos minimointi jättää johdannaiset huomiotta, siitä tulee seremonia, joka suoritetaan etuovella, kun taas tehdas sen takana jatkaa tosiasioiden valmistamista.
Insinöörityön kurinalaisuus tarkoittaa, että herkkyys ja käyttötarkoitus kulkevat muutosten mukana. Ominaisuuden tulisi tietää lähdekenttänsä, sallitut käyttötavat, säilytysluokkansa, laaturajansa ja poistoriippuvuutensa. Mallin tuotoksen tulisi tietää, onko se ohimenevä ehdotus, tallennettu tietue, laukaisin ihmisen tarkistukselle vai automaattisen päätöksenteon osa. Upotusindeksin tulisi tietää, mitkä asiakirjat ovat kelpoisia, milloin ne indeksoitiin ja miten poisto etenee. Datajäljitys ei ole koristelua. Se on tapa, jolla minimointi seuraa dataa sen jälkeen, kun se lakkaa näyttämästä syöttölomakkeelta.
AI saa ylijäämän tuntumaan kannattavalta
AI-järjestelmät vaikeuttavat minimointia, koska ylijäämädata näyttää tulevalta kyvykkyydeltä. Säilytä vanhat tiketit, niistä voi olla hyötyä tukiautomaatiolle. Säilytä transkriptit, niillä voi kouluttaa paremman luokittelijan. Säilytä käyttäytymistapahtumat, niistä voi olla hyötyä personoinnille. Säilytä hylätyt hakemukset, ne voivat paljastaa petoksia. Säilytä lokit, niistä voi olla hyötyä arvioinnille. Joskus tämä pitää paikkansa. Data voi parantaa malleja. Mutta totta ei ole sama asia kuin perusteltua. Ruokakomerossa voi olla hyödyllisiä asioita, ja se voi silti olla paloturvallisuusriski, jos kukaan ei tiedä, mitä sen sisällä on.
Koulutusdatalla on pitkä varjo. Kun tietueita käytetään mallien kouluttamiseen, hienosäätöön, arviointiin tai kehotteisiin, ne voivat vaikuttaa käyttäytymiseen tavoilla, jotka eivät ole yhtä suoraviivaisia kuin tietokannan rivi. Jotkin järjestelmät voivat poistaa esimerkkejä ja kouluttaa uudelleen. Jotkin voivat peittää tai suodattaa. Jotkin voivat vain dokumentoida rajoitteet. Mitä aikaisemmin minimointipäätös tehdään, sitä halvempaa ja puhtaampaa se on. Päättää koulutuksen jälkeen, että kenttää ei olisi koskaan pitänyt sisällyttää, on mahdollista samassa mielessä kuin kakun paistamisen purkaminen on projekti. Sillä on kokouksia.
AI-tiimien tulisi siksi kohdella koulutuskelpoisuutta ensiluokkaisena hallintakeinona. Jokainen palvelutietue ei ole koulutusmateriaalia. Jokainen suostumustila ei salli uudelleenkäyttöä. Jokainen tukitiketti ei kuulu arviointiin. Jokaisesta lokista ei pitäisi tulla kehoteasiayhteyttä. Jokaisen asiakirjan ei pitäisi päätyä indeksiin. Putkiston tulisi valvoa tätä ennen kuin malli näkee datan. Jos mallin laatu riippuu kaiken nielemisestä, koska kukaan ei suunnitellut tehtävää kunnolla, ongelma ei ole se, että yksityisyys on vaikeaa. Ongelma on arkkitehtuuri, joka yrittää syödä läksynsä.
Telemetria on se paikka, josta hyve vuotaa
Monet järjestelmät minimoivat tuotedatan ja kaatavat sitten kaiken telemetriaan. Virhejäljet, analytiikkatapahtumat, istuntotallenteet, virheenkorjauskuormat, kaatumisraportit, mallikehotteet, kyselymerkkijonot, otsikot, ominaisuusliput ja ajoitustiedot kerääntyvät palvelun ympärille kuin pöly palvelintelineen alle. Jokainen yksittäinen tieto on perusteltavissa erikseen. Yhdessä ne voivat rakentaa käyttäjästä elävämmän kuvan kuin tietokanta, joka huolellisesti minimoitiin. Havainnointi ilman kuria on valvontaa hakulaitteen kanssa.
Suunnittelutiimit tarvitsevat havainnointia. Sokeat järjestelmät eivät ole turvallisia, yksityisiä, luotettavia eivätkä edullisia. Kysymys ei ole siitä, kirjataanko lokia, vaan siitä, mitä kirjataan, millä tarkkuudella, kenelle, kuinka kauan ja millä poistamisella. Tuotantovirhe saattaa tarvita pyynnön tunnisteen, palveluversion, vikaluokan ja valitut viittaukset. Se ei todennäköisesti tarvitse koko viestiä, raakaa dokumenttia, käyttöoikeustunnusta eikä käyttäjän koko lomaketilaa. Virheenkorjaustiedot voidaan poimia otoksina, rajata, peittää tai tilapäisesti avata hallittujen menettelyjen mukaisesti. Mikään luonnonlaki ei edellytä, että jokaisesta poikkeuksesta tulee päiväkirjamerkintä.
AI-telemetria ansaitsee erityistä huomiota. Kehotteet voivat sisältää liitettyä yksityistä dataa. Hakujäljet voivat paljastaa arkaluonteisia aiheita. Tuotetut tulosteet voivat sisältää faktoja, joita ei pitäisi tallentaa. Työkalukutsut voivat paljastaa aikomuksia. Arviointivirheet voivat muuttua pitkäikäisiksi esimerkeiksi. Kustannus- ja viivelokit voivat paljastaa käyttäytymismalleja. Minimoitu järjestelmä ei ole se, joka kieltäytyy tarkkailemasta itseään. Se on se, joka tarkkailee pienemmillä ja terävimmillä välineillä.
Säilytys on ominaisuus, ei ajastettu tehtävä
Säilytys toteutetaan usein myöhään, ajastettuna siivoustyönä ja toiveikkaana kommenttina. Näin järjestelmistä tulee museoita. Oikea säilytys alkaa suunnittelusta. Jokaisella dataluokalla on oltava elinajanodote. Jotkin tietueet ovat lyhytikäistä operatiivista tilaa. Jotkin ovat oikeudellista näyttöä. Jotkin ovat käyttäjälle näkyvää tilitietoa. Jotkin ovat aggregoidtuja mittareita. Jotkin ovat mallin arviointimateriaalia. Jotkin ovat varmuuskopiojäämiä. Niiden kaikkien kohteleminen säilytettävinä toistaiseksi ei ole pragmatismia. Se on hamstraamista käyttöönottoputkella.
Hyödyllinen säilytyssuunnittelu vastaa tylsiin kysymyksiin ajoissa. Milloin kello käynnistyy. Mikä tapahtuma nollaa sen. Mikä kopio on ensisijainen. Mikä johdettu data perii vanhenemisen. Mikä näyttö on säilytettävä sisällön poistamisen jälkeen. Miten varmuuskopiot käsitellään. Miten poisto todistetaan. Mitä tapahtuu, kun oikeudenkäynti-, auditointi- tai turvallisuuspidätykset ovat voimassa. Kuka saa pidentää säilytystä. Mitkä kojelaudat rikkoutuvat, kun vanha data katoaa. Jos kukaan ei osaa vastata näihin kysymyksiin, siivoustyöstä tulee symbolinen luuta varastossa, jossa ei ole ovia.
Säilytystä on myös testattava. Poistopolku, joka toimii vain onnellisessa polussa, ei ole poistopolku. Sen on katettava tietokannat, blob-varastot, hakuhakemistot, välimuistit, tapahtumavirrat, analytiikan, viennit, ominaisuuskaupat, arviointijoukot ja varmuuskopiot tarvittaessa. Sen on tallennettava kuitit säilyttämättä poistettua sisältöä. Sen on tehtävä virheet näkyviksi. Sen on oltava niin tylsää, ettei kenenkään tarvitse koota työryhmää joka kerta, kun käyttäjä käyttää oikeuttaan. Hyvä säilytys ei ole dramaattista. Se on sen viehätys.
Käyttöoikeuksien hallinta ei pelasta huonoa keräystä
On houkutteleva väite, että tiimit voivat kerätä laajasti ja suojata myöhemmin käyttöoikeuksien hallinnalla. Joskus laaja keräys on välttämätöntä, mutta käyttöoikeuksien hallinta ei ole moraalinen pesukone. Jos dataa kerätään ilman tarvetta, jokaisen myöhemmän kerroksen on puolustettava sitä: identiteetti, valtuutus, lokitus, salaus, valvonta, poisto, koulutussuodattimet, vientirajoitukset ja häiriötilanteisiin vastaaminen. Edullisin suojattava data on data, joka ei koskaan saavu. Tämä ei ole filosofista. Se on toimintabudjetti, joka piileskelee periaatteessa.
Pääsynhallinta pyrkii myös laajenemaan paineen alla. Tukipyyntö tarvitsee väliaikaisen roolin. Analyytikko tarvitsee laajemman tietoaineiston määräaikaa varten. Migraatio tarvitsee järjestelmänvalvojan oikeudet. Mallin arviointi tarvitsee esimerkkejä. Toimittaja tarvitsee hätätuen. Jokainen pyyntö voi olla perusteltu. Laaja kerääminen muuttaa perustellut poikkeukset suureksi hyökkäyspinta-alaksi. Minimointi pitää pääsynhallinnan rehellisenä vähentämällä sitä, mitä rooli voi alun perin paljastaa.
Hyvä pääsynhallinnan suunnittelu toimii yhdessä minimoinnin kanssa. Palvelut saavat vain tarvitsemansa kentät. Käyttöliittymät näyttävät vähemmän oletuksena. Analyytikot työskentelevät näkymillä, joissa on tarkoitus ja tietojen peittäminen. Insinöörit debuggaavat viitteillä ja näytteillä, eivät tuotantodumpeilla. Agentit ja automatisoidut työkalut saavat kapeat käyttöoikeudet. Break-glass-pääsy jättää vahvan jäljen. Järjestelmän pitäisi tehdä vähiten tunkeilevasta polusta helppo polku. Jos turvallinen polku vaatii kolme hyväksyntää ja käsin kirjoitetun YAML-loitsun, ihmiset kiertävät sen luovuudella, joka yleensä varataan verolomakkeille.
Minimointi vaatii tuoteharkintaa
Insinöörit eivät voi tehdä minimointia yksin. He voivat rakentaa hallinnan, mutta tuote- ja toimialueen tiimien on päätettävä, mikä on työn kannalta välttämätöntä. Kenttä voi näyttää tietokantasuunnittelijasta liialliselta ja tapauskäsittelijästä välttämättömältä. Mittaus voi näyttää tuotepäälliköstä harmittomalta ja mitattavasta henkilöstä tunkeilevalta. Mallin ominaisuus voi parantaa tarkkuutta mutta muuttaa palvelun hyväksyttävää luonnetta. Nämä ovat harkintakysymyksiä. Insinöörin ammattitaitoa on tehdä harkinnasta eksplisiittistä, testattavaa ja mahdollisuuksien mukaan palautettavaa.
Parhaat keskustelut ovat konkreettisia. Mitä päätöstä tämä kenttä parantaa. Kuinka usein. Kenelle. Mitä tapahtuu, jos se puuttuu. Voidaanko se kerätä myöhemmin tarvittaessa. Voiko se olla karkeampi. Voiko se laskea paikallisesti. Voiko se näkyä vain tarkastajalle. Voiko se vanhentua. Voiko se korvata vähemmän henkilökohtaisella todisteella. Tuoko se harhaa, leimaa tai uuden velvoitteen. Tiimi, joka ei osaa vastata näihin kysymyksiin, voi silti päättää kerätä. Sen tulisi ainakin tietää lainaavansa ongelmia, ei löytävänsä kypsyyttä.
Tässä myös kuiva operatiivinen todellisuus auttaa. Jokainen kenttä tarvitsee testit. Jokainen kenttä tarvitsee migraatiot. Jokainen kenttä tarvitsee pääsynhallintasäännöt. Jokainen kenttä esiintyy vienneissä, mockeissa, fixtureissa, analytiikassa, dokumentaatiossa ja tukityökaluissa. Jokainen kenttä voi muuttua vääräksi. Pienempi skeema ei ole vain yksityisempi. Se on usein ymmärrettävämpi, luotettavampi ja halvempi muuttaa. Minimalismi ei ole estetiikkaa. Se on tuleva ylläpito, joka kieltäytyy joutumasta väijytykseen.
Silmukka, joka pitää datan pienenä
Minimointi ei ole kertaluonteinen siivous. Uudet ominaisuudet tuovat kenttiä. Uusi analytiikka tuo tapahtumia. Uudet mallit haluavat opetusaineistoa. Uudet säädökset luovat vaatimuksia todisteista. Uudet häiriöt luovat lokitietoja. Uudet esihenkilöt pyytävät kojelautoja. Vanha data saa tunnearvoa, kun joku muistaa kaavion vuodelta 2021. Ilman kierrosta dataomaisuus kasvaa kuin puutarha, jota kastellaan kokousmuistioilla.
Käytännöllinen kierto alkaa ennen keräämistä. Kysy, mitä työ vaatii. Luokittele kenttä tai tapahtuma. Suunnittele pienin toimiva muoto. Varmista sopimus vastaanoton yhteydessä. Mittaa, käytetäänkö dataa. Poista se käytöstä, kun tarkoitus päättyy. Käy läpi johdannaiset, lokit, viennit ja mallit. Kirjaa päätös. Toista, kun työnkulku muuttuu. Tämä ei ole hohdokasta, mutta se on halvempaa kuin huomata häiriön aikana, että organisaatio on pitänyt yksityistä museota kolmessa formaatissa ja unohdetussa jonossa.
Kierron pitäisi tuottaa todisteita itsestään. Järjestelmän pitäisi pystyä osoittamaan, miksi kenttä on olemassa, kuka sen omistaa, mitkä palvelut sitä käyttävät, kuinka usein sitä käytetään, mitä säilytyskäytäntöä sovelletaan ja miten poisto etenee. Tämä ei ole vain viranomaisia varten. Se auttaa kehittäjiä poistamaan asioita ilman pelkoa. Useimmat järjestelmät säilyttävät liikaa, koska kukaan ei tiedä, mikä poisto on turvallista. Minimointi helpottuu, kun organisaatio pystyy erottamaan kantavan datan koristeellisesta roinasta.
Kuri
Datan minimointi ei ole dataa vastaan. Se on tarkoitusta puolesta. Se pakottaa tiimin kertomaan, mitä se tarvitsee, miksi se tarvitsee sitä, kuinka tarkkaa sen on oltava, kuka sitä saa käyttää ja milloin sen pitäisi lakata olemasta. Tämä kuri parantaa yksityisyyttä, mutta se parantaa myös järjestelmäsuunnittelua. Pienemmistä kuormista on helpompi päätellä. Kapeammat skeemat on helpompi siirtää. Lyhyempi säilytys vähentää selvittelyn tuskaa. Puhtaampi telemetria tekee häiriöistä helpompia ymmärtää. Harvemmat opetusnäytteet, joilla on selkeä kelpoisuus, voivat voittaa suuremman kyseenalaisen aineiston kasauksen. Periaate on eettinen, laillinen ja syvästi käytännöllinen.
Vaikein osa on kulttuurinen. Organisaatiot pitävät datasta, koska data tuntuu vaihtoehtoisuudelta. Sen säilyttäminen tuntuu turvalliselta. Sen poistaminen tuntuu lopulliselta. Mutta vaihtoehtoisuus ilman omistajuutta on velkaa. Jokainen lisäkenttä on lupaus suojata, selittää, korjata, viedä ja poistaa. Jokainen johdettu ominaisuus on uusi väite. Jokainen loki on mahdollinen tallenne. Jokainen varmuuskopio on viivästynyt väittely. Minimointi vaatii järjestelmää ansaitsemaan sen, mitä se säilyttää. Tämä on korkea rimakynnys, ja siksi se on hyödyllinen.
Kolmenkymmenenkahdeksan kentän lomake ei tarvinnut yksityisyyslauseketta. Se tarvitsi pienemmän skeeman, paremmat oletusarvot, tiukemman vastaanoton, luokitellun telemetrian, rajatun analytiikan, koulutuskelpoisuuden, säilytyskuitit ja riittävästi tuoteroihkua myöntääkseen, että myöhemmin ei ole tarkoitus. Se on työtä. Ei dramaattista, ei mystistä, ei innovaatiolle vihamielistä. Vain insinöörin kurinalaisuutta sovellettuna datajärjestelmien vanhimpaan totuuteen: sitä mitä et koskaan kerää, ei voi vuotaa, ei voi ajautua, ei voi käyttää väärin, eikä sen unohtamiseen tarvita komiteaa.