Pilviriippuvuuden hankala talous
Alennuksesta tuli strategia
Ensimmäinen merkittävä pilvilasku on harvoin ensimmäinen lasku. Ensimmäinen on yleensä helpotus. Ei palvelinhankintoja, ei odottelua hankintakierrokselle, ei keskusteluja kiinteistöhuollon kanssa jäähdytyksestä, ei sankarillista taulukkoa kapasiteetista seuraaville kolmelle vuodelle. Tiimi avaa tilin, ottaa palvelun käyttöön, katsoo sen toimivan ja tuntee kuin painovoima olisi väliaikaisesti kumottu. Lasku näyttää sivistyneeltä. Talous nyökkää. Arkkitehtuuri sanoo sanan joustava. Kaikki lähtevät kotiin kevyen osaamisen hehkun kanssa.
Sitten järjestelmästä tulee hyödyllinen. Silloin talous muuttuu. Data kasvaa. Lokit kasvavat, koska joku haluaa vihdoin tietää, mitä tapahtui. Hallinnoidusta tietokannasta tulee paikka, jossa operatiivinen muisti asuu. Viestijono kytketään alavirran järjestelmiin. Identiteettikerroksesta tulee etuovi. Datavarasto vastaanottaa vientejä, koska analyytikotkin ovat ihmisiä. Muutamista erikoispalveluista tulee normaaleja osia pinosta. Kuukausilasku on edelleen vain yksi numero, mutta se sisältää nyt useita tulevaisuuksia.
Pilviriippuvuudesta tulee epämukavaa, koska se alkaa mukavuutena ja kypsyy neuvotteluasemaksi. Kysymys ei ole siitä, onko pilvi hyvä vai huono. Se kehys on liian laiska aikuisille, joilla on tuotantojärjestelmiä. Kysymys on siitä, ymmärtääkö organisaatio, mitkä kustannukset ovat näkyviä, mitkä kustannukset ovat lykättyjä, mitkä kyvykkyydet ovat siirtyneet sen ulottumattomiin ja mitä kurssin muuttaminen vaatisi pysäyttämättä työtä, joka nyt riippuu alustasta.
Riippuvuuden kallein osa ei usein ole listattu hinta. Se on vaihtoehtojen menetys. Vaihtoehtoisuus on kyky neuvotella uudelleen, siirtää, yksinkertaistaa, keskeyttää, korvata tai kieltäytyä muuttamatta organisaatiota kriisihuoneeksi. Pilvi voi ostaa hyödyllistä vaihtoehtoisuutta varhain: nopeita kokeiluja, väliaikaista kapasiteettia, hallinnoituja tietoturvaominaisuuksia, maailmanlaajuista kattavuutta. Se voi myös kuluttaa vaihtoehtoisuutta myöhemmin, kun data, identiteetti, operaatiot ja osaaminen asettuvat niin tiukasti yhden toimittajan ympärille, että lähtemisestä tulee projekti, jolla on oma säärintamansa.
Pilviriippuvuus ei ole pilven käyttöä
Pilvipalveluiden käyttäminen on tavallista. Niistä riippuvainen oleminen on myös tavallista. Ongelma alkaa, kun riippuvuus on näkymätöntä päätöksiä tekeville ihmisille. Vuokratulla infrastruktuurilla toimiva työkuorma ei tallennu automaattisesti. Työkuorma, jonka tietomalli, identiteetti, havaittavuus, käyttöönottoprosessi, tietoturva-asento, varmuuskopiointistrategia, analytiikka ja henkilöstön toimintatavat kaikki olettavat yhden palveluntarjoajan, on eri asia. Toinen on isännöintiä. Toinen on toimintamalli, jonka keskiössä on toimittaja.
Riippuvuudella on kerroksia. On kaupallista riippuvuutta: alennukset, sitoumukset, varattu kapasiteetti, hyvitykset, markkinapaikkasopimukset, tukitasot ja hankintakalenterit. On teknistä riippuvuutta: omat sovellusrajapinnat, hallinnoidut tietokannat, tapahtumajärjestelmät, identiteettipalvelut, käyttöönottomallit, valvonta-agentit ja tallennuksen semantiikka. On organisatorista riippuvuutta: koulutus, toimintaohjeet, rekrytointiprofiilit, häiriötilanteiden toimintatavat, hyväksyntäprosessit ja lohdullinen uskomus siitä, että portaali on järjestelmä. Jokainen kerros voi olla järkevä. Yhdessä ne ratkaisevat, kuinka neuvoteltavissa tulevaisuus on.
Monet organisaatiot aliarvioivat organisatorisen kerroksen, koska se ei näy arkkitehtuurikaavioissa. Insinöörit oppivat sujuvaksi yhden palveluntarjoajan kanssa. Tietoturvatiimit oppivat sen käytäntömallin. Talous oppii sen laskutuskielen. Hankinta oppii sen sopimusrituaalit. Häiriötiimit oppivat sen kojelaudat. Tästä sujuvuudesta on hyötyä. Se myös luo vaihtokustannuksia. Toinen palveluntarjoaja voi olla teknisesti mahdollinen ja taloudellisesti järjetön, jos kenelläkään ei ole toimivaa sanastoa sen operoimiseen paineen alla.
Siksi riippuvuutta tulisi käsitellä hallittuna altistumisena eikä moraalisena epäonnistumisena. Sairaala voi perustellusti käyttää hallinnoituja pilvipalveluita ei-kriittiseen analytiikkaan ja silti pitää kliinisen jatkuvuuden lähempänä. Vähittäiskauppias voi hyväksyä korkean alustasidonnaisuuden nopean skaalautumisen vuoksi. Julkinen toimija voi valita tiukemman siirrettävyyden kansalaisten tietojen osalta. Virhe ei ole riippuvuuden valitseminen. Virhe on sen valitseminen vahingossa ja hinnan huomaaminen vasta, kun joku pyytää irtautumista.
Taloudellinen pinta-ala on suurempi kuin laskenta
Pilvikeskustelut alkavat usein laskennasta ja tallennuksesta, koska ne on helppo laskea. Se on kuin ravintolan arvioiminen perunoiden hinnan perusteella. Taloudelliseen pinta-alaan kuuluvat identiteetti, verkkoliikenne, lokit, varmuuskopiointi, replikointi, havaittavuus, tietoturvaskannaus, avaintenhallinta, hallinnoidut tietokannat, jonot, analytiikka, tiedonsiirto, tuki, vaatimustenmukaisuustodisteet, henkilöstön aika, siirtotyö ja kustannus sanoa ei oletusarvoille. Lasku on vain se osa järjestelmää, joka on kohtelias saapuessaan PDF-tiedostona.
Hallinnoidut palvelut voivat olla erinomaisia, koska ne muuttavat vaikean operatiivisen työn palvelurajaksi. Hallinnoitu tietokanta voi olla turvallisempi ja halvempi kuin huonosti ylläpidetty paikallinen tietokanta. Hallinnoitu jono voi säästää viikkoja insinöörityötä. Hallinnoitu identiteettikerros voi vähentää katastrofaalisia virheitä. Mutta muunnos ei ole katoamista. Työ siirtyy. Vastuu siirtyy vähemmän. Organisaatio omistaa edelleen tiedon laadun, käyttöoikeuskäytännöt, varmuuskopioinnin tarkoituksen, säilytyksen, palautusajan, todisteet ja häiriön seuraukset. Se on vuokrannut lihaksia, ei harkintakykyä.
Vaarallisin pilvibisnestapaus on sellainen, joka hinnoittelee palvelun ja jättää huomiotta sen luoman käyttäytymisen. Kun tallennus on helppoa, tiimit säilyttävät enemmän. Kun lokit ovat riittävän halpoja, tiimit lokittavat ilman luokittelua. Kun tiedon kopiointi on yksi painike, kopiot lisääntyvät. Kun hallinnoitu analytiikka on saatavilla, raaka-aine vienti ilmestyy. Kun kaikki tiimit voivat luoda resursseja, nimeämiskäytännöistä tulee kansanperinnettä. Mukavuus on arvokasta, mutta mukavuus ilman inventaariota muuttuu pieneksi veroviranomaiseksi arkkitehtuurin sisällä.
Hyvä pilvitalous alkaakin palvelukartasta, ei alennustaulukosta. Mitkä työmäärät ovat kriittisiä. Millä datalla on juridisia tai toiminnan kannalta arkaluonteisia vaatimuksia. Mitkä palvelut ovat omia. Mitkä ovat korvattavissa. Mikä data liikkuu maksullisten rajojen yli. Mitkä lokit tarvitaan todisteiksi. Mitkä varmuuskopiot testataan. Mitkä sitoumukset perustuvat todelliseen kysyntään. Ketkä voivat käyttää järjestelmää, kun portaali on hidas, lasku yllättää tai palveluntarjoaja muuttaa oletusasetusta.
Egress ei ole skandaali, se on oire
Egress-maksut saavat paljon huomiota, koska ne tuntuvat epäkohteliailta. Se, että joutuu maksamaan datan viemisestä pois paikasta, johon on maksanut sen viemisestä, tuntuu samalta kuin joutuisi maksamaan kokouksesta poistumisesta. Ärtymys on ymmärrettävää. Mutta egress ei ole koko ongelma. Se on näkyvä oire laajemmasta taloudellisesta rakenteesta: data muuttuu arvokkaammaksi palveluntarjoajalle, kun se pysyy paikallaan, ja kalliimmaksi asiakkaalle, kun se liikkuu.
Datan painovoima on osittain teknistä. Suuret tietoaineistot liikkuvat hitaasti. Johdetut tietoaineistot vaativat täsmäytystä. Indeksit, käyttöoikeudet, skeemat, metatiedot ja alkuperäketju eivät siirry automaattisesti. Alavirran järjestelmät olettavat polkuja. Analyytikot rakentavat muistikirjoja. Työnkulut riippuvat sijainneista. Siirtämisen kustannuksiin kuuluu kaistanleveys, mutta myös se inhimillinen työ, jolla siirretystä asiasta tehdään saapumisen jälkeen sama asia. Jokainen, joka on siirtänyt dataomaisuuden, tietää, että tavut ovat usein harvoja asioita, jotka eivät valehtele.
Datan painovoima on myös poliittista. Tiimi, joka haluaa lähteä alustalta, voi kohdata vastaväitteitä jokaiselta ryhmältä, joka on rakentanut sen ympärille. Tietoturva kysyy hallintakeinoista. Analytiikka kysyy putkistoista. Tuote kysyy viiveestä. Talous kysyy, miksi olemassa olevaa sitoumusta ei käytetä. Lakiasiat kysyvät, vaihtuvatko datan käsittelijät. Operatiivinen toiminta kysyy, kuka pitää hälytyspuhelinta. Mikään näistä vastaväitteistä ei ole typerä. Yhdessä ne muodostavat pysymisen talouden.
Vakava arkkitehtuuri hinnoittelee siirtämisen ennen kuin siirtämistä tarvitaan. Se pitää kriittisen datan avoimissa formaateissa. Se tallentaa skeemaversiot ja alkuperäketjun. Se erottaa lähdetietueet johdetuista mukavuuskerroksista. Se testaa viennin ja palautuksen. Se välttää sen, että jokaisesta analyyttisestä kopiosta tulee uusi riippuvuus. Se dokumentoi, mikä rikkoutuisi siirron aikana. Tämä työ voi tuntua pessimistiseltä kasvun aikana. Se tuntuu vähemmän pessimistiseltä, kun organisaatio saa uusimistarjouksen, jonka lämpö muistuttaa pysäköintisakkoa.
Sitoumukset ovat hyödyllisiä, kunnes niistä tulee politiikkaa
Varattu kapasiteetti, yritysalennukset, sitoutunut käyttö ja pilvihyvitykset voivat olla taloudellisesti järkeviä. Ne laskevat yksikkökustannuksia, kun kysyntä on todellista ja vakaata. Ne myös muuttavat käyttäytymistä. Sitoumuksesta voi tulla hiljainen kehotus käyttää enemmän yhtä alustaa, koska rahat on jo luvattu. Arkkitehtuuri alkaa seurata sopimusta työkuorman sijaan. Tämä ei ole korruptiota. Se on aritmetiikkaa, jolla on virkamerkki.
Sitoumukset ovat erityisen hankalia tekoäly- ja data-alalla, koska kysyntä on epävarmaa. Pilotti voi vaatia purskeisia kokeita. Tuotannon päätelmätyökuorma voi vakiintua. Harjoittelu voi vaatia satunnaisia suuria töitä. Lokitus ja arviointi voivat kasvaa hallinnon kehittyessä. Tallennustila voi kertyä, koska poistaminen vaatii enemmän kuria kuin luominen. Liian aikainen sitoutuminen voi saada organisaation optimoimaan ennusteteatteria varten. Liian myöhäinen sitoutuminen voi tuhlata rahaa. Kummassakin tapauksessa sitoumusta tulisi käsitellä riskipositiona, ei pelkkänä hankintavoittona.
Hyvitykset ansaitsevat oman varovaisuutensa. Ilmainen tai tuettu kapasiteetti voi olla hyödyllistä, erityisesti kokeiluihin ja yleishyödylliseen työhön. Se voi myös kylvää riippuvuuden ennen kuin organisaatio on hinnoitellut vakaan tilan. Tiimi rakentaa palveluiden varaan, jotka ovat tilapäisesti halpoja, integroituu syvälle ja huomaa myöhemmin normaalin laskun. Ensimmäinen vuosi ei ollut kustannus. Se oli syötti ennusteessa. Pahansuopuutta ei tarvita. Laskentataulukko teki työnsä pokkana.
Hyvä hallinto kysyy, mihin sitoumus velvoittaa operatiivisesti. Mitkä työkuormat kuuluvat sen piiriin. Mitkä on rajattu pois. Mitä tapahtuu, jos kysyntä laskee. Mitä tapahtuu, jos parempi palvelu on olemassa muualla. Vähentääkö alennus siirrettävyyttä. Tekeekö se kestävyydestä huonompaa palkitsemalla ylikulutuksesta. Piilottaako se paikallisen osaamisen ylläpidon kustannuksen. Alennus, joka heikentää tulevia valinnanmahdollisuuksia, tulisi kirjata sekä säästönä että altistumisena. Rahoitus ymmärtää sen kielen. Arkkitehtuurin tulisi myös.
Hallinnoidut palvelut siirtävät työtä, eivät vastuuta
Pilven vahvin argumentti on edelleen operatiivinen laatu. Useimmat organisaatiot eivät halua pyörittää kaikkea itse, eikä monien pitäisikään. Maailmassa on tarpeeksi huonosti ylläpidettyjä palvelimia, unohdettuja päivitysikkunoita, puoliksi testattuja varmuuskopioita ja sankarillisia ylläpitäjiä, jotka tietävät liikaa, koska kukaan ei kirjoittanut mitään ylös. Hallinnoitu infrastruktuuri voi parantaa luotettavuutta, turvallisuutta, nopeutta ja keskittymistä. Muuta väittäminen on nostalgiaa telinekaavion kanssa.
Mutta hallinnoitu ei tarkoita delegoitua oikeudellisessa tai institutionaalisessa mielessä. Jos hallinnoitu tietokanta menettää dataa, organisaatio kohtaa silti käyttäjän. Jos hallinnoitu identiteettikonfiguraatio myöntää liikaa pääsyoikeuksia, organisaatio omistaa silti tietoturvaloukkauksen. Jos hallinnoitu tekoälypalvelu tallentaa kehotteita tavalla, joka rikkoo käytäntöä, organisaatio selittää silti valinnan. Toimittaja voi jakaa vastuun, mutta tehtävä ei siirry toimittajalle. Se pysyy ärsyttävän paikallisena laitoksessa, joka lupasi palvelun.
Tämä ero on merkityksellinen kustannusten kannalta. Hallinnoidut palvelut voivat vähentää henkilöstötarvetta joissakin tehtävissä, mutta samalla ne lisäävät tarvetta arkkitehtuurille, tietoturvalle, toimittajahallinnalle, datan hallinnalle, FinOpsille ja auditoinnin osaamiselle. Jos liiketoimintaperuste poistaa vanhan operointitiimin ja unohtaa rahoittaa uuden valvontatyön, organisaatio ei ole säästänyt rahaa. Se on muuttanut näkyvän työn piiloriskiksi. Lasku näyttää siistiltä ensimmäiseen häiriöön asti, jonka jälkeen poissa olevista ihmisistä tulee omituisen kalliita.
Kypsä pilvitoimintamalli pitää siksi yllä riittävää sisäistä osaamista toimiakseen kykenevänä päämiehenä. Se tietää, miten palvelu toimii sillä tasolla, jota tarvitaan konfigurointiin, valvontaan, haastamiseen, palautukseen ja irtautumiseen. Sillä on toimintaohjeita, jotka kuvaavat muutakin kuin sen, mitä painiketta painetaan. Se osaa lukea lokit, kiertää avaimet, testata varmuuskopiot, rajoittaa pääsyä ja esittää toimittajille täsmällisiä kysymyksiä. Sen ei tarvitse rakentaa jokaista komponenttia. Sen on kuitenkin vältettävä joutumista matkustajaksi omassa infrastruktuurissaan.
Resilienssi on kaupallinen asenne
Resilienssi kuvataan usein teknisenä ominaisuutena: redundantit vyöhykkeet, varmuuskopiot, failover, jonot, uudelleenyritykset, piirikatkaisijat, katastrofipalautus. Kaikki tämä on merkityksellistä. Mutta resilienssi on myös kaupallista. Voiko organisaatio jatkaa toimintaansa sopimusriidan, tukiviiveen, alueellisen häiriön, hinnankorotuksen, tuotteen käytöstä poistamisen, käytäntömuutoksen, vientirajoituksen tai tilin jäädytyksen aikana. Nämä eivät ole pelkästään juridisia skenaarioita. Ne ovat vikatiloja, joilla on ostotilausnumerot.
Jotkin resilienssimallit ovat samaan aikaan sekä teknisiä että kaupallisia. Autoritatiivisten tietueiden säilyttäminen siirrettävissä formaateissa on sekä datan hallintaa että neuvottelua. Riippumattomat lokit ovat sekä havaittavuutta että todisteita. Paikallinen avainten hallinta on sekä tietoturvaa että neuvotteluvoimaa. Monialuemuotoilu on sekä saatavuutta että lainkäyttövallan altistumista. Testattu palautus ensisijaisen alustan ulkopuolella on sekä katastrofipalautusta että muistutus siitä, että poistuminen on mahdollista. Luokat ovat käteviä, kunnes todellisuus ei niistä välitä.
Monipilveä ehdotetaan joskus automaattiseksi vastaukseksi. Se voi auttaa tietyissä tapauksissa, erityisesti kun työkuormat on suunniteltu siirrettäviksi ja tiimeille on rahoitettu lisämonimutkaisuuden operointi. Siitä voi myös tulla kallista teatteria: kaksi alustaa, kaksi osaamisaluetta, kaksi tietoturvamallia, kaksinkertainen hämmennys, eikä yhtään todellista testattua poistumista. Monipilvi ei ole itsessään hyve. Hyve on uskottava valinta. Joskus se saavutetaan avoimilla formaateilla, kontitettujilla työkuormilla, siirrettävillä tietokannoilla, riippumattomalla identiteetillä ja toimittajakurilla, ei symmetrisellä päällekkäisyydellä.
Resilienssikysymyksen tulisi olla käytännöllinen. Mitkä työkuormat on pidettävä toiminnassa toimittajan stressin aikana. Kuinka kauan ne voivat heikentyä. Minkä datan on oltava saatavilla paikallisesti. Mitkä ohjaustason riippuvuudet ovat hyväksyttäviä. Mitkä hätätoimenpiteet voidaan tehdä ilman toimittajan hyväksyntää. Mitkä poistumiset on testattu. Mitkä tiimit ovat harjoitelleet niitä. Jos vastaus on enimmäkseen luottamusta, organisaatiolla on tunnelmataulu, ei resilienssiä.
Poistumissuunnitelma on osa laskua
Lopettamisen suunnittelua pidetään usein pessimisminä. Sitä pitäisi pitää kirjanpitona. Lopettamissuunnitelma ei tarkoita, että organisaatio aikoo lähteä huomenna. Se tarkoittaa, että organisaatio tietää, mitä lähteminen edellyttäisi, mikä vähentää todennäköisyyttä sille, että jäämisestä tulee pakollista. Suunnitelma voi olla vaatimaton: kartoita kriittiset palvelut, luokittele siirrettävyys, dokumentoi tietoformaatit, säilytä riippumaton näyttö, testaa vienti, tunnista korvaavat toimintamallit ja harjoittele palautusta niiden harvojen työkuormien osalta, joilla on todella merkitystä.
Lopettamisen ei tarvitse olla kaikki tai ei mitään. Hyvä suunnitelma tunnistaa osittaiset lopettamiset. Siirrä analytiikka ennen ydintoimintoja. Korvaa oma jonotusjärjestelmä yhdessä työnkulussa. Pidä varmuuskopiot ensisijaisen pilven ulkopuolella. Säilytä riippumaton identiteetin palautuspolku. Rakenna uudelleen kallein tallennuskerros. Erota tekoälyn arviointidata toimittajakohtaisesta työkalusta. Jokainen osittainen lopettaminen vähentää riippuvuuspainetta. Tarkoitus ei ole dramaattinen riippumattomuus. Tarkoitus on vähentää niitä tapoja, joilla organisaatio voidaan ajaa nurkkaan.
Epämiellyttävä osuus on se, että lopettaminen maksaa rahaa myös silloin, kun sitä ei käytetä. Avoimet formaatit vaativat kurinalaisuutta. Siirrettävät rakenteet voivat olla vähemmän käteviä. Henkilöstö tarvitsee koulutusta. Testit vievät aikaa. Riippumattomat lokit vaativat tallennustilaa ja käyttöoikeuksien hallintaa. Hankintaan tarvitaan vahvempia ehtoja. Arkkitehtuurikatselmoinnit kestävät kauemmin. Siksi lopettamisen hinta pitää hinnoitella nimenomaisesti. Jos johto päättää olla maksamatta siitä, se on päätös. Jos kukaan ei hinnoittele sitä, järjestelmä valitsee hiljaa riippuvuuden ja kutsuu sitä tehokkuudeksi.
On olemassa hyödyllinen sääntö: mitä kriittisempi työkuorma, sitä tylsempää lopettamisen näytön pitäisi olla. Ei dia, jossa lukee siirrettävä. Ei sopimuskohta, jossa luvataan kohtuullista apua. Tuore vienti. Palautettu näyte. Mitattu kesto. Luettelo menetetyistä ominaisuuksista. Nimetty omistaja. Tunnettu hinta. Jos se kuulostaa epäromanttiselta, hyvä. Romantiikka ei ole palautusstrategia.
Paikallinen osaaminen on taloudellista hallintaa
Yksi hiljaisimmista pilviriippuvuuden kustannuksista on osaamisen kaventuminen. Tiimit tulevat erittäin hyviksi yhden toimittajan konsolissa, käytäntökielessä, käyttöönottomallissa, hallinnoiduissa palveluissa ja tukirutiineissa. Se on tuottavaa, kunnes siitä tulee ainoa käytettävissä oleva kieli. Kun toimittaja ehdottaa uutta palvelua, tiimi arvioi sitä sujuvasti. Kun hallitus kysyy, onko olemassa toista polkua, vastaus on hitaampi, epämääräisempi ja yleensä kalliimpi, koska organisaatio ei ole harjoitellut ajattelua alustan ulkopuolella.
Taito on neuvotteluvoimaa. Tiimi, joka ymmärtää tietokantoja, voi haastaa hallitun tietokantaratkaisun suunnittelun. Tiimi, joka ymmärtää verkottumista, voi kyseenalaistaa tiedonsiirtotavat. Tiimi, joka ymmärtää identiteettiä, voi välttää pitämästä palveluntarjoajan oletusasetuksia tietoturvakäytäntönä. Tiimi, joka ymmärtää kustannusmalleja, voi huomata, milloin alennus muuttaa arkkitehtuuria. Tiimi, joka ymmärtää palautumista, voi vaatia todisteita lohdutuksen sijaan. Asiantuntemus ei edellytä, että kaikki tehdään itse. Se edellyttää, että osaa olla tarpeeksi vaarallinen palaverissa, mieluiten ennen lounasta.
Koulutuksen pitäisi siksi kattaa taustalla olevat kyvykkyydet, ei vain palveluntarjoajan sertifiointeja. Mikä on jono. Mitä idempotenssi tarkoittaa. Miten varmuuskopiot epäonnistuvat. Mikä tekee lokista käyttökelpoisen todisteena. Miten salausavaimen hallinta muuttaa valtaa. Mikä on data gravity. Miten sitoumukset vaikuttavat käyttäytymiseen. Miten mittaamme kustannuksen hyödyllistä tapahtumaa kohti. Palveluntarjoajan työkalut ovat tärkeitä, mutta niitä pitäisi käsitellä laajempien käsitteiden toteutuksina. Muuten organisaatio sekoittaa ruokalistan keittiöön.
Tämä pätee erityisesti julkisella ja puolijulkisella sektorilla. Laitokset, joilla on pitkiä velvollisuuksia, eivät voi antaa toiminnallisen kielensä olla kokonaan vuokrattua. Kunta, sairaala, koulu, vesilaitos tai valvontaviranomainen voi käyttää pilvipalveluita hyvin, mutta sen pitäisi silti ymmärtää kyvykkyydet, joista se on riippuvainen. Muuten julkinen vastuu muuttuu tukipyynnöksi, johon on liitetty logo, ja kaikki huomaavat liian myöhään, että hallinta tukipyyntöjonon kautta on rajallisesti perustuslaillista viehätystä.
Epämukava johtopäätös
Pilviriippuvuus on epämukavaa, koska se ei ole roistotarina. Pilvi voi olla oikea vastaus. Se voi vähentää hukkaa, parantaa tietoturvaa, nopeuttaa toimituksia, tukea tutkimusta, hoitaa piikkejä ja tehdä pienistä tiimeistä kykeneviä työhön, jota ne eivät muuten voisi edes yrittää. Monet pilven arvostelijat olettavat hiljaa paikallisen toiminnallisen huippuosaamisen tason, jota ei ole olemassa. Huonosti hoidettu yksityinen alusta ei ole suvereniteettia. Se on vain intiimimpi käyttökatkos.
Epämukavuus tulee tarpeesta laskea rehellisesti. Mukavuudella on arvoa. Lukkiutumisella on arvoa toimittajalle. Poistumisella on hinta. Osaamisella on hinta. Todisteilla on hinta. Siirrettävyydellä on hinta. Sitoumuksilla on sekä säästöjä että rajoitteita. Hallitut palvelut vähentävät osan työstä ja luovat muuta työtä. Vakava keskustelu asettaa kaiken tämän samalle pöydälle. Se kieltäytyy sekä fantasiasta, että vuokrattu infrastruktuuri on automaattisesti vapautta, että fantasiasta, että oma laitteisto on automaattisesti hallintaa.
Hyvä pilvistrategia valitsee riippuvuuden harkiten. Se käyttää hallittuja palveluita siellä, missä ne luovat todellista arvoa. Se vetää tiukemmat rajat kriittisen datan, todisteiden, identiteetin ja palautumisen ympärille. Se rahoittaa sisäistä osaamista. Se kohtelee sopimuksia osana arkkitehtuuria. Se testaa viennin ennen neuvotteluja. Se tietää, mitkä työmäärät voivat olla syvästi kytkettyjä ja mitkä on pidettävä siirrettävinä. Se näkee pilvilaskun ei rangaistuksena, vaan signaalina siitä, miten organisaatio on päättänyt toimia.
Opetus on tarpeeksi selvä ollakseen hyödyllinen. Pilvitalous on epämukavaa, koska se hinnoittelee tulevaisuuden, ei vain nykyhetkeä. Halpa polku voi olla halpa, koska joku muu pitää hallussaan poistumistietä. Kallis polku voi olla kallis, koska se säilyttää valinnanvapauden. Kumpikaan tosiasia ei yksinään ratkaise vastausta. Laitos ratkaisee sen nimeämällä, minkä on pysyttävä sen hallinnassa, mikä voidaan vuokrata, minkä on oltava siirrettävissä ja minkä hinnan se on valmis maksamaan mahdollisuudesta muuttaa mieltään.