Suvereniteetti on arkkitehtuuripäätös, ei hosting-valinta

Yritys päättää haluavansa hallita tietojaan. Hankkeelle annetaan budjetti, toimittaja valitaan, ja puolentoista vuoden päästä järjestelmät toimivat kotimaisessa konesalissa sopimusehdoin, joihin lakitiimi on tyytyväinen. Hallitukselle kerrotaan, että yritys on nyt suvereeni.

Sitten joku kysyy käytännön kysymyksen. Jos toimittaja nostaisi hintojaan jyrkästi ensi vuonna, kuinka kauan lähteminen kestäisi? Kukaan ei osaa vastata. Tietomalli kuuluu toimittajan tuotteeseen. Hyväksyntäketjut on konfiguroitu toimittajan hallintanäkymissä. Salausavaimet ovat toimittajan avainpalvelussa, ja asiakasvastauksia luonnosteleva kielimalli kutsutaan toimittajan tilin kautta. Palvelimet siirtyivät. Riippuvuus ei.

Syy on se, että suvereniteettia käsiteltiin kysymyksenä siitä, missä, vaikka se on kysymys siitä, kuka voi tehdä mitä kysymättä lupaa. Sijainnilla on väliä: se ratkaisee, mitä lakia sovelletaan ja kenet voidaan velvoittaa luovuttamaan tietoja. Mutta se on yksi ominaisuus monien joukossa, ja se on ainoa, jonka voi ostaa valmiina. Muut on suunniteltava sisään.

Missä ”suvereeni” pettää huomaamatta

Avaimet muualla. Jos salausavaimet ovat palveluntarjoajan hallitsemassa palvelussa, palveluntarjoaja voi lukea tiedot – ja niin voi kuka tahansa, joka voi velvoittaa palveluntarjoajan. Omassa maassa säilytetty, mutta jonkun toisen avaimella salattu data on sijoitettua, ei hallittua.

Liiketoiminnan malli, jota ei voi ottaa mukaan. Jokainen järjestelmä tarjoaa viennin. Harva vie suhteet, säännöt ja historian muodossa, jonka toinen järjestelmä pystyy lataamaan. Joukko tauluja ilman sarakkeiden merkitystä on varmuuskopio, ei irtautuminen.

Logiikka konfiguraatiossa. Hyväksyntärajat, hinnoittelusäännöt ja ohjaukset: kun ne ovat klikkauksia suljetussa näkymässä, niitä ei voi lukea, tarkistaa eikä siirtää. Yrityksen toimintatapa on muodossa, jota vain yksi tuote ymmärtää.

Yksi malli, yksi palveluntarjoaja. Jos kaikki kielityö kulkee yhden ulkoisen mallin kautta yhdellä tilillä, yrityksen toimintakyky riippuu nyt kyseisen palveluntarjoajan hinnoista, saatavuudesta ja käyttöehdoista. Se on toimitusketjun riski, ja se näkyy harvoin riskirekisterissä.

Irtautuminen, jota kukaan ei ole harjoitellut. Irtautumissuunnitelma, jota ei ole koskaan toteutettu, on toive. Ensimmäinen kerta, kun kukaan testaa, pystyykö yritys siirtymään, on yleensä se hetki, jolloin sen on pakko.

Mitä suunnitella sen sijaan

Käsittele suvereniteettia joukkona arkkitehtuurin ominaisuuksia, joista kunkin voi tarkistaa henkilö, jonka ei tarvitse luottaa toimittajan sanaan.

Avaimet ovat yrityksen omat. Salausavaimet luodaan ja säilytetään yrityksen hallitsemalla infrastruktuurilla, eikä alustan operoija voi käyttää niitä ilman yrityksen osallisuutta.

Yrityksen malli kulkee datan mukana. Kohteet, suhteet ja säännöt kuvataan avoimessa, luettavassa muodossa ja versioidaan, jotta se, mitä liiketoiminta tarkoittaa tilauksella tai asiakkaalla, voi lähteä tietojen mukana. Se on ontologian tehtävä: merkitys elää datan rinnalla eikä yhden toimittajan tuotteen sisällä.

Logiikka on luettavissa. Säännöt ja prosessit tallennetaan tarkistettavina artefakteina historioineen, ei konfigurointinäkymän tilana. Jos agentti muutti sääntöä, muutoksella on tekijä, syy ja hyväksyntä.

Mallit ovat vaihdettavissa. Kielityö reititetään tehtäväkohtaisesti, joten arkaluonteinen työ voi mennä omalla laitteistolla toimivalle mallille ja yleinen työ kärkimallille, ja kumman tahansa voi vaihtaa kirjoittamatta uudelleen niitä käyttäviä prosesseja. Kun pieni malli omalla laitteistolla riittää, arkkitehtuurin pitäisi antaa käyttää sitä.

Ohjelmistopino on avointa lähdekoodia siellä, missä sillä on väliä. Avoin lähdekoodi ei takaa suvereniteettia, mutta se poistaa sen yhden riippuvuuden, josta ei voi koskaan neuvotella pois: luvan ylipäätään ajaa ohjelmistoa.

Tähän suunnitteluun Hurukania rakennetaan. Sen Tietoturva ja suvereniteetti -kerros valvoo käyttöoikeudet palvelimella, auditoi jokaisen muutoksen ihmisen, agentin tai järjestelmän tekemäksi, toimii yrityksen valitsemalla infrastruktuurilla ja kirjaa irtautumisen heti alussa. Se on rakenteilla eikä käytössä, joten tässä kuvattu on suunnitelma, ei näyttöä toteutuneesta.

Testi, jonka voi tehdä tällä viikolla

Valitse yksi merkittävä prosessi. Laskutus on hyvä ehdokas, koska se koskettaa asiakkaita, hintoja, maksuja ja lainsäädäntöä. Vastaa kirjallisesti viiteen kysymykseen:

1. Missä tämän datan salausavaimet ovat, ja kuka pystyy käyttämään niitä?
2. Jos kaikki vietäisiin ulos tänään, pystyisikö toinen järjestelmä toistamaan sen, mitä lasku täällä tarkoittaa: sen tilat, hyväksyntäsäännöt ja kytkökset tilauksiin ja maksuihin?
3. Missä tämän prosessin säännöt ovat, ja voiko ihminen lukea ne kirjautumatta toimittajan työkaluun?
4. Mitkä ulkoiset mallit käsittelevät tätä dataa, kenen tilillä, ja mitä prosessille tapahtuu, jos malli ei ole käytettävissä viikkoon?
5. Milloin tämä prosessi tai sen kopio viimeksi siirrettiin toiselle infrastruktuurille?

Jokainen kysymys, jonka vastaamiseen kuluu yli päivä, osoittaa riippuvuuden, jota kukaan ei suunnitellut. Vastaukset näyttävät myös, mikä data ansaitsee eniten huolellisuutta – siitä kertoo erillinen kirjoitus siitä, mikä data ei saa poistua talosta.

Hosting-sopimuksena ostettu suvereniteetti kestää ensimmäiseen kovaan neuvotteluun asti. Avaimiin, malliin, logiikkaan ja irtautumiseen suunniteltu suvereniteetti on yhä olemassa, kun neuvottelu muuttuu vaikeaksi. Hurukanin yleiskuvaus näyttää, miten kerrokset sopivat yhteen.