Järjestelmäsi toimii erinomaisesti. Niin kauan kuin henkilö, joka tietää miksi, on töissä.
Kuvittele yritys, jolla on seitsemän vuotta toiminnassa ollut järjestelmä. Se on syntynyt vaiheittain. Aluksi sen teki yksi software house. Sitten osa siirtyi freelancerille. Myöhemmin toinen tiimi lisäsi B2B-moduulin. Seuraava toimisto yhdisti CRM:n. Joku muu integroi maksut.
Järjestelmä toimii.
Yritys ansaitsee sillä rahaa.
Työntekijät käyttävät sitä päivittäin.
Asiakkaat eivät edes tiedä, kuinka monta prosessia tapahtuu taustalla.
On kuitenkin yksi ongelma.
Kukaan ei enää tarkalleen tiedä, miten kaikki toimii.
Dokumentaatio on osittain Confluencessa. Jotain on Google Drivessa. Muutamia tietoja on tiketeissä. Yksi integraatio on kuvattu neljä vuotta vanhassa sähköpostissa.
Ja tärkein tieto on "luultavasti Łukasz muistaa".
Vaan Łukasz lähti kolme vuotta sitten.
Ja kolmen vuoden ajan ei tapahtunut mitään.
Kunnes eräänä tiistaiaamuna.
Järjestelmä toimii. Onko siis kaikki kunnossa?
Tämä on yksi petollisimmista tiloista, joissa yrityksen järjestelmä voi olla.
Se toimii.
Ei ole vikoja.
Käyttäjät ovat tyytyväisiä.
Myynti käyttää sovellusta.
Tilaukset kulkevat.
Tiedot menevät CRM:ään.
Raportit generoituu.
Joten luonnollinen reaktio on: Älkää koskeko. Miksi mennä muuttamaan jotain, mikä toimii?
Ja totta - ei ole syytä muuttaa toimivaa järjestelmää vain siksi, että se on mahdollista.
Ongelma on, että järjestelmä voi olla teknisesti vakaa mutta organisatorisesti hyvin epävakaa.
Se voi toimia tänään, mutta kukaan ei tiedä, mitä tapahtuu, kun pitää vaihtaa palvelinta, API-toimittajaa, domainia, kirjastoa, autentikointitapaa tai osa liiketoimintaprosessista.
Se voi olla tehokas, mutta riippuvainen yhdestä henkilöstä.
Se voi olla turvallinen, mutta kukaan ei tiedä, missä kaikki avaimet ovat.
Sitä voidaan kehittää, mutta vain ihminen, joka tietää kaikkien päätösten historian, pystyy siihen.
Ja tässä kohtaa astuu kuvaan käsite bus factor.
Kuinka moni voi kadota, ennen kuin projekti alkaa olla ongelmissa?
Bus factor on hyvin yksinkertainen mutta brutaali käsite.
Kysymme: Kuinka monen ihmisen täytyy tulla tavoittamattomiksi, jotta projektin ylläpito ei enää sujuisi?
Jos vastaus on: "Yksi", meillä on ongelma.
Jos vastaus on: "Kaksi, mutta molemmat työskentelevät toisessa yrityksessä", meillä on vielä suurempi ongelma.
Ei kyse ole kirjaimellisesta ihmisten "häviämisestä".
Ohjelmoija voi lopettaa työt yrityksessä.
Freelancer voi lopettaa yhteistyön.
Software house voi lopettaa palvelun tarjoamisen.
Järjestelmän ylläpitäjä voi vaihtaa työpaikkaa.
Henkilö, joka vastaa tietystä integraatiosta, voi siirtyä toiseen tiimiin.
Tiedon omistaja voi yksinkertaisesti sairastua tai olla muutaman viikon tavoittamattomissa.
Jos hänen kanssaan katoaa kyky ymmärtää järjestelmää, yrityksellä ei ole henkilöstöongelmaa.
Sillä on liiketoiminnallinen ongelma.
Koodi ei aina kerro, miksi jotain toimii
Voidaan sanoa: "Meillä on lähdekoodi. Uusi kehittäjä voi lukea sen tarvittaessa."
Teoriassa kyllä.
Käytännössä koodi vastaa ensisijaisesti kysymykseen: miten järjestelmä tekee jotain.
Se ei aina vastaa kysymykseen: miksi sitä tehdään juuri tällä tavalla.
Ja se on suuri ero.
Koodissa voi olla ehto: "Jos asiakkaalla on tietty tilityyppi, suorita operaatio X."
Uusi kehittäjä löytää sen.
Mutta mistä hän tietää miksi?
Se voi olla liiketoimintavaatimus.
Se voi olla jäämä jäljeltä vanhasta integraatiosta.
Se voi olla suojaus ulkoisen API:n virheeltä.
Se voi olla kiertotie ongelmalle, joka esiintyi viisi vuotta sitten.
Se voi olla ratkaisu yhden suurimman asiakkaan epätavalliseen tapaukseen.
Se voi olla siellä hyvin perustellusta syystä.
Tai ei mistään syystä.
Ilman kontekstia sitä on vaikea arvioida.
Siksi järjestelmädokumentaation ei pitäisi rajoittua ohjeisiin:
"klikkaa tässä, ja sitten täällä".
Arvokkain dokumentaatio kuvaa usein päätöksiä ja riippuvuuksia, ei pelkästään toimintojen käyttöä.
Vaarallisinta tietoa on se, joka on vain jonkun pään sisällä
Yrityksillä on usein dokumentaatiota. Mutta dokumentaatio ei aina ole sama asia kuin tieto.
Voimme esimerkiksi olla kuvaus API:sta – mutta ei tietoa, miksi käytämme juuri sitä API:ta.
Voimme olla ohjeet käyttöönotosta – mutta ei luetteloa kaikista paikoista, joissa pitää muuttaa konfiguraatiota.
Voimme olla kuvaus integraatiosta – mutta emme tiedä, mitä tapahtuu, jos ulkoinen toimittaja muuttaa autentikointia.
Voimme pitää luetteloa palvelimista – mutta emme tiedä, mikä niistä on kriittinen tietylle prosessille.
Voimme olla pääsy repoosi – mutta ei pääsyä tilille, jolla tuotantoinfrastruktuuri sijaitsee.
Nämä ovat juuri niitä elementtejä, jotka voivat muuttaa näennäisesti yksinkertaisen muutoksen useiden päivien tutkinnaksi.
Viiden vuoden ajan toiminut integraatio on silti riippuvuus
Yksi usein laiminlyödyistä alueista ovat ulkoiset palvelut;
- Maksut.
- SMS.
- Sähköposti.
- CRM.
- ERP.
- Kartat.
- Kuljetusjärjestelmät.
- Markkinointialustat.
- Kirjanpitojärjestelmät.
- Pilvipalvelut.
- Ulkoiset API:t.
- Open source -kirjastot.
Jokainen tällainen asia on osa suurempaa ekosysteemiä.
Jos järjestelmä käyttää kymmentä ulkoista palvelua, meillä ei ole yhtä järjestelmää. Meillä on järjestelmä plus kymmenen riippuvuutta. Ja jokainen niistä voi muuttua.
Toimittaja voi muuttaa API:a.
Se voi lopettaa palvelun.
Se voi muuttaa hinnoittelumallia.
Se voi poistaa vanhan version.
Se voi esitellä uusia turvallisuusvaatimuksia.
Se voi tulla ostetuksi toisella yrityksellä.
Siksi yhä tärkeämmäksi tulee tieto komponenttien alkuperästä ja ohjelmistoriippuvuuksista. NIST korostaa muun muassa SBOMin eli Software Bill of Materialsin merkitystä – formaalia luetteloa ohjelmiston rakentamiseen käytetyistä komponenteista. Tällainen luettelo auttaa ymmärtämään, mistä järjestelmä koostuu ja arvioimaan nopeammin haavoittuvuuksien tai toimitusketjun muutosten vaikutuksia.
Liiketoiminnan kannalta se on hyvin yksinkertainen kysymys:
Tiedätkö, mistä järjestelmäsi riippuu?
Ja nyt kuvittele software house -vaihdos
Se on yksi hetki, jolloin kaikki puutteet tulevat päivänvaloon.
Yritys on tehnyt yhteistyötä vuosia yhden toimittajan kanssa. Yhtäkkiä yhteistyö loppuu. Syitä voi olla monia; strategian muutos. Budjetin muutos. Toimiston myynti. Organisaatio-ongelmat. Puuttuvat kyvykkyydet jatkokehitykseen. Tai yksinkertaisesti yritys haluaa toisen kumppanin.
Uusi software house kysyy:
"Missä repositorio on?" - On.
"Missä infrastruktuuri on?" - On.
"Miten tuotantoon otetaan?" - "Emme tiedä, sen teki edellinen tiimi."
"Miten ERP-integraatio toimii?" - "Luultavasti tämän palvelimen kautta."
"Mitkä ovat API-avaimet?" - "Niiden pitäisi olla sähköpostissa."
"Mitkä API:t ovat tuotannossa?" - "Emme tiedä."
"Mitkä prosessit ovat kriittisiä?" - "Täytyy kysyä Łukaszilta."
Łukasz ei enää työskentele siellä...
Ja juuri siksi projektin siirtäminen ei ole pelkästään koodin siirtoa. On siirrettävä myös tieto.
Dokumentaatio ei ole kustannus. Se on vakuutus
Monissa yrityksissä dokumentaatiota tehdään "kun on aikaa".
Eli yleensä koskaan.
Tai projektin lopussa.
Tai kun joku kysyy.
Se on virhe.
Dokumentaatio on yksi mekanismeista, jotka rajoittavat operatiivista riskiä. Se ei tuota suoraan myyntiä. Se ei paranna konversiota. Se ei näytä vaikuttavalta esityksissä.
Mutta kriisitilanteessa se voi olla ero: "korjaamme sen tänään"
ja: "ensin meidän täytyy löytää henkilö, joka muistaa, miten se toimi".
NISTin uudemmissa ohjeissa turvallisuuden, yksityisyyden ja ohjelmistotoimitusketjun riskien hallinnasta järjestelmän tarkoituksen, tilan, kontrollien sekä vastuuhenkilöiden ja heidän toimintojensa dokumentointi nähdään osana järjestelmällistä hallintatapaa.
Se kuvastaa hyvin muutosta ajattelussa.
Dokumentaatio ei ole vain kehittäjän työkalu.
Se on osa organisaation jatkuvuutta.
Mitä pitäisi dokumentoida?
Kyse ei ole 800 sivun dokumentaation tekemisestä, jota kukaan ei koskaan avaa.
Hyvän dokumentaation pitäisi vastata ensisijaisesti kysymyksiin, jotka nousevat esiin, kun jotain muuttuu tai lakkaa toimimasta.
- Kuka omistaa järjestelmän?
- Missä koodi sijaitsee?
- Missä tuotanto sijaitsee?
- Mikä on käyttöönottoprosessi?
- Mitkä ympäristöt on olemassa?
- Mitkä ovat kriittiset integraatiot?
- Mistä ulkoisista palveluista käytämme?
- Kuka on niiden toimittaja?
- Millaisia sopimuksia ja tilejä meillä on?
- Missä avaimet ja pääsytiedot ovat?
- Kuka on oikeutettu?
- Miten varmuuskopiointi on järjestetty?
- Miten järjestelmä palautetaan?
- Mitä open source -komponentteja käytetään?
- Mitkä kirjastot ovat vanhentuneita?
- Mitkä ovat tärkeimmät arkkitehtuuripäätökset?
- Mitkä osat ovat liiketoiminnalle kriittisiä?
- Mitä tapahtuu, jos tietty ulkoinen palvelu lakkaa toimimasta?
Tämä ei ole dokumentaatio "kehittäjille".
Se on kartta teknologian vaikutuksista liiketoimintaan.
"Se toimii, joten ei kosketa" voi olla strategia. Mutta sen hinta pitää tietää
Kaikki yritykset eivät tarvitse vanhan järjestelmän uudistusta.
Kaikki legacy-järjestelmät eivät ole huonoja.
Kaikkia vanhoja koodeja ei tarvitse kirjoittaa uudelleen.
Päinvastoin - joskus vakaa, vanhempi järjestelmä on paljon parempi ratkaisu kuin kallis migraatio ilman selvää syytä.
Ongelma ei ole järjestelmän ikä.
Ongelma on tieto siitä, missä kunnossa se on.
Jos tiedämme, miten järjestelmä toimii, mistä se riippuu, missä riskit ovat ja kuka sen pystyy ylläpitämään, voimme tietoisesti päättää:
- jätämme sen ennalleen,
- modernisoimme,
- kirjoitamme osan uudelleen,
- migreeraamme,
- tai emme tee mitään.
Jos emme tiedä tätä, päätös "emme koske" ei ole strategia.
Se on arvaus.
Miltä perittyjärjestelmän auditointi näyttää?
Kun software house saa olemassa olevan järjestelmän, ensimmäinen askel ei saisi olla: "Kirjoitetaan se uudelleen." - Ensin se pitää ymmärtää.
Hyvän auditoinnin tulisi kattaa muun muassa sovellusarkkitehtuuri, lähdekoodi, tietokanta, infrastruktuuri, käyttöönottoprosessi, riippuvuudet, integraatiot, turvallisuus, palveluihin pääsy ja dokumentaatio.
Vähintään yhtä tärkeää on liiketoiminnan ymmärtäminen;
- Mitkä prosessit ovat kriittisiä?
- Mitkä toiminnot ovat käytössä päivittäin?
- Mitkä moduulit tuottavat liikevaihtoa?
- Mitkä osat voidaan ottaa pois käytöstä ilman seurauksia?
- Mitä tapahtuu, jos tietty integraatio lakkaa toimimasta?
- Mitkä osat ovat kaikkein riskialtteimpia?
Vasta teknisen ja liiketoiminnallisen näkökulman yhdistämisen jälkeen voidaan sanoa, mitä todella tarvitsee muuttaa.
Auditointi ei välttämättä vaadi mullistusta
Joskus auditoinnin tulos on yllättävän yksinkertainen.
Järjestelmä on kunnossa, tarvitsee vain:
- täydentää dokumentaatiota.
- järjestää käyttöoikeudet.
- päivittää muutamia kirjastoja.
- siirtää tileihin omistajuus.
- kuvata käyttöönottoprosessi.
- lisätä monitorointia.
- varmistaa varmuuskopiointi.
- ottaa toinen henkilö mukaan alueisiin, jotka vain yksi kehittäjä tunsi.
Ja yhtäkkiä bus factor muuttuu yhdestä kolmeen.
Ei tarvitse kirjoittaa koko sovellusta uudelleen.
Ei tarvitse heittää pois seitsemän vuoden työtä.
Ei tarvitse rakentaa kaikkea alusta.
Joskus suurin ongelma ei ole teknologia.
Se on kartan puute.
Järjestelmän pitäisi selvitä sen luojien lähdöstä
Tämä on ehkä tärkein periaate: hyvä järjestelmä selviää siitä, että kehittäjä lähtee.
Sen pitää kestää ylläpitäjän vaihdos.
Sen pitää kestää software house -vaihdos.
Sen pitää kestää yritysjärjestelyt.
Sen pitää kestää usean vuoden kehittäminen.
Se ei tarkoita, että jokaisen kehittäjän täytyy ymmärtää jokainen koodirivi. Se tarkoittaa, että liiketoiminnan kannalta kriittinen tieto ei voi olla pelkästään yhden ihmisen päässä.
Sillä työntekijä voi lähteä.
Freelancer voi lopettaa yhteistyön.
Toimisto voi hävitä.
Toimittaja voi muuttaa palveluaan.
Ja yrityksen on silti pystyttävä toimimaan.
Teknologian pitäisi olla organisaation omaisuutta, ei yksilön muistin
Tämä on erityisen tärkeää pitkään rakennetuissa järjestelmissä.
Jos yritys maksaa ohjelmistosta, sen pitäisi tietää paitsi missä koodi sijaitsee:
sen pitäisi tietää:
- mitä se omistaa,
- mistä se riippuu,
- kuka pääsee käsiksi,
- kuka voi muuttaa sitä,
- miten se voidaan ottaa käyttöön,
- miten se voidaan palauttaa,
- miten se voidaan siirtää toiselle tiimille.
NIST korostaa nykyisissä due diligence -materiaaleissaan mm. alkuperää, resilienssiä, kyberturvakäytäntöjä ja riippuvuuksia toimitusketjussa. Tämä osoittaa laajemman suunnan: organisaatioiden pitäisi entistä useammin tietää eivät vain kuka toimitti järjestelmän, vaan myös mistä järjestelmä koostuu ja mitä riskejä sen ylläpitoon liittyy.
Tämä ei ole enää vain IT-osaston asia.
Tämä on liiketoimintariskien hallintaa.
Pahin hetki tuntea järjestelmäsi on vikatilanne
Voit käyttää muutaman päivän auditointiin.
Voit järjestää dokumentaation.
Voit tarkistaa riippuvuudet.
Voit kuvata arkkitehtuurin.
Voit tarkistaa pääsyt.
Voit määrittää, kuka todella vastaa eri osa-alueista.
Voit vähentää bus factoria.
Tai voit odottaa.
Siihen asti, kun järjestelmä lakkaa toimimasta.
Silloin kysymykset ovat täsmälleen samat.
Vain paine on suurempi, käyttäjät odottavat, myynti voi pysähtyä, ja jokainen tunti maksaa rahaa.
Siksi kannattaa esittää itselleen yksi kysymys ennen kuin ongelma ilmenee: Jos huomenna katoaisi henkilö, joka parhaiten tuntee järjestelmäsi, tietäisimmekö silti, miten sitä ylläpidetään?
Jos vastaus on "ei", se ei tarkoita, että järjestelmä olisi huono.
Se tarkoittaa, että yrityksellä on piilevä riski, jota se ei ole vielä joutunut aktiiviseksi.
Me Web24:ssä otamme vastuun muustakin kuin koodista
Olemassa olevan projektin ottaminen haltuun on täysin erilaista työtä kuin uuden järjestelmän aloittaminen alusta alkaen.
Ensin pitää ymmärtää, mitä jo on.
Mikä toimii.
Mikä on kriittistä.
Mikä on riippuvuus.
Mikä on ongelma.
Mikä on vain jälki aiemmista päätöksistä.
Ja ennen kaikkea - missä tieto sijaitsee, ilman jota järjestelmää ei voi turvallisesti kehittää.
Vasta sitten voidaan suunnitella jatkotoimet.
Joskus se on modernisointi.
Joskus kehitys.
Joskus infrastruktuurin järjestäminen.
Joskus ylläpidon ottaminen omiin käsiin.
Ja joskus yksinkertaisesti kunnon järjestelmäkartta, jota kukaan ei ole ehtinyt tehdä vuosien aikana.
Sillä vastuullisen software housen ei pitäisi rakentaa teknologiaa, joka toimii vain, kun oikea ihminen istuu koneen ääressä.
Järjestelmän pitäisi olla suurempi kuin yhden ihmisen muisti.
Ja liiketoiminnan pitäisi olla varma siitä, että kun joku lähtee, teknologia ei lähde hänen mukaansa.
