Milloin ja miksi Atlassian-ympäristön auditointi kannattaa tehdä?

Olen tehnyt tänä vuonna puolen tusinaa Atlassian-järjestelmäauditointia erilaisille asiakkaille, mm. suomalaiselle teollisuuden konsernille, korkeakoululle, sekä IT-järjestelmiä tuottavalle softatalolle. Konsultointityön arjessa olen päässyt näkemään monenlaista Atlassian-työkaluinstanssia, mikä myös paljastaa työkalujen nykytilaa organisaatioissa.

Kiinnostus auditointeja kohtaan on kasvussa

Yhteinen trendi näyttää selvästi olevan siirtymä pois Atlassian Server -ympäristöistä, tyypillisesti Cloudiin, mutta toisinaan myös Data Centeriin. Vanhan ympäristön auditointi on näissä tilanteissa olennainen, sillä Server, Data Center ja Cloud eroavat niin lisensiointimalliltaan (ts. kustannuksiltaan) kuin myös teknisesti toisistaan.

Auditoinnin löydökset paljastavat ennen migraatioprojektia mahdolliset haasteet ja tuovat kriittistä lisäaikaa niiden ratkaisemiseen. Lisäksi auditointilöydöksien perusteella voidaan aikaansaada merkittäviä kustannussäästöjä.

Asiakkaat lähestyvät meitä kysymyksillä, jotka liittyvät toimintamalleihin tai teknisiin ratkaisuihin, ja olemme tapauksen arvioinnin jälkeen päätyneet tarjoamaan olemassa olevan järjestelmän tai toimintatapojen auditointia. Tämä tulee kyseeseen, kun tilanteet järjestelmiä käyttäessä tai kehittäessä ovat hankalia sisäistää ilman Atlassian -työkalujen tai agilen syväosaamista.

Asiakkaamme ovat olleet audit-prosesseihimme sekä lopputuloksena syntyviin raportteihin erittäin tyytyväisiä!

Auditoinnin yleisimmät hyödyt:

• Kustannussäästöt vaihtoehtoisilla lisensointimalleilla
• Tiimien työskentelyn tehostaminen
• Sisällön ja konfiguraatioiden rapautumisen esiin tuominen
• Tietoturvariskien tunnistaminen
• Paljastaa migraatioissa esiin nousevat kriittiset haasteet etukäteen

Lisää tehoja niin järjestelmiin kuin työskentelyyn

Yleisin asiakkaiden järjestelmiä koskettava piirre liittyy järjestelmien ikään. Meillä on Suomessa lukemattomia organisaatioita, joissa Jiraa, Confluencea ja muita Atlassian -työkaluja on käytetty jo yli kymmenen vuotta.

Atlassian-työkalujen asennuskannassa ikä näkyy vanhojen konfiguraatioiden sekä sisällön määrässä. Mitä kauemmas historiaan sovelluksessa katsoo, sitä enemmän näkyy ristiriitaisia tai puuttuvia konfiguraatioita, sekä artifakteja vanhoista versiopäivityksistä, platform-migraatioista tai käytöstä poistuneista lisäosista.

Myös organisaatioiden tavat käyttää työkaluja ovat vuosien saatossa muuttuneet ja vaikka se reflektoituu tyypillisesti uusimmissa konfiguraatioissa, niin vanhemmat taas saattavat olla pahastikin heitteillä, vaikka ne ovat vielä tuotannonomaisessa käytössä.

Tuotannonomaisilla projekteilla usein paljon töitä jonossa. Tämä on henkilökunnalle kuormittavaa, sillä tekemättömät työt tuntuvat kivenjärkäleiltä hartioilla, ja järjestelmällekin on hankalaa availla jokaisella sivulatauksella isoa backlogia – niinpä backlogien siivous on sekä ihmisten että järjestelmän etu.

Auditoinneissa kiinnitämme järjestelmän iän tuomiin ongelmiin erityistä huolta tarkastellen niin globaaleja asetuksia, projekteja kuin myös järjestelmän tiedostojärjestelmistä löytyviä lokeja.

Käyttäjänhallinnassa parantamisen varaa

IT-osastoilla yleisesti on tiedossa keskitetyn käyttäjänhallinnan edut, mutta käyttäjänhallintapolitiikan jalkautus Atlassian-työkaluihin usein ontuu. Järjestelmiin useimmiten tulee käyttäjätunnukset ulkoisen IDP:n kautta (esim. AD), mikä on ideaalitilanne, mutta järjestelmän sisällä luvitukset pohjautuvat kirjavaan käytäntöön.

Jira ja Confluence antavat mahdollisuuden määrätä käyttöoikeuksia projekti- ja yksittäisten käyttäjien tasolla, mikä vuosien edetessä johtaa haasteelliseen tilanteeseen, kun mainittuja yksittäisluvituksia ja ryhmäpohjaisia on sekaisin keskenään.

Käyttäjähallinnassa on selvästi eniten parantamisen varaa vanhoissa järjestelmissä, missä on potentiaalisesti ollut montaa pääsyhallintapolitiikkaa, mahdollisesti monta peräkkäistä järjestelmäomistajaa ja jopa peräkkäisiä ulkoisia IDP-järjestelmiä.

Suosituksemme on selkeä 3-tasoinen käyttäjäryhmämalli (katselija-, normaali käyttäjä- ja admin-käyttäjäryhmä), joka luodaan projektitasolle, ja mikäli projektikategorisointia käytetään, niin mahdollisesti myös projektikategoriatasolla. Tärkeintä on siirtyä pois henkilökohtaisista luvituksista, sillä niiden hallinta järjestelmän ikääntyessä on työlästä ja kuormittaa organisaation varsinaisen IT-tuen sijasta Atlassian-työkalutukea.

Selkeää kustannussäästöä saavutetaan työkalujen lisensioinnilla vain sellaiselle henkilökunnalle, joka niitä aktiivisesti tarvitsee. Tämä kumpuaa Atlassianin lisensointimallista, jossa työkalun hinta tulee käyttäjämäärän mukaan. Auditoinneissa teemme analyysin lisensioitujen käyttäjien työkalukäytöstä ja suosituksen kustannustehokkaasta lisenssimäärästä sekä lisensiointiperiaatteesta.

Kustannustehokkuutta yhdenmukaistamisella

Jiran joustavat projektiasetukset ovat sen selkeä vahvuus, mutta audit-löydöstemme mukaan joustavuus johtaa myös punaisen langan unohtumiseen samankaltaisten tiimien asetuksissa. Ylläpitotyöhön tuo tehokkuutta ja kustannussäästöä, kun esimerkiksi muutos- tai lisätöitä tarvitsee tehdä vain yhteen uusiokäytettyyn konfiguraatiomalliin, sen sijaan että monilla projekteilla on aina omat asetuksensa.

Jiran joustavan konfiguraatiomallipohjaisen toiminnan sivutuotteena järjestelmään jää usein järjestelmän luomia konfiguraatiomalleja, joita joko ei käytetä enää lainkaan tai ne ovat käytöstä poistuneilla projekteilla. Suosituksemme on pitää järjestelmä puhtaana myös ylläpitopuolelta, sillä järjestelmässä olevat turhat konfiguraatiomallit tuovat ylimääräistä monimutkaisuutta esimerkiksi tulevaisuuden päivityksiin tai alustanvaihtoon kuten Server-Cloud-migraatio.

Yhdenmukaisten konfiguraatiomallien käyttäminen on erityisen tärkeää, kun organisaatiossa ajetaan yhteistä kehitysmallia. Koska konfiguraatiomallit ovat toimintokohtaiset, voi uusiokäyttöominaisuudesta saada paljon hyötyä myös, kun toimintamallit ovat erilaisia. Esimerkiksi käyttöoikeus-, kenttäkonfiguraatio-, ja ilmoitusmallit ovat usein uusiokäytettävissä läpi erilaistenkin kehitysmallien.

Auditissa käymme läpi niin projektikohtaiset asetukset, globaalit konfiguraatiomallit kuin myös järjestelmän pohjakonfiguraation. Teemme suositukset konfiguraatioiden tulevaisuudesta, joita asiakas voi itse pikkuhiljaa toteuttaa tai voimme tehdä niitä asiakkaan puolesta auditin jälkeen.

Maailma muuttuu, niin myös Atlassian-ympäristöt

Tärkein neuvo, jonka antaisin, on pysytellä ajan hermolla siinä, mitä Atlassian-työkalujen sisällä tehdään. Tämä koskettaa niin toimintamalleja, tiimien tilannetta työkaluissa, konfiguraatioiden linjaamista sovellusten tämänhetkisten ominaisuuksien kanssa, käyttäjähallintaa, kuin myös käytössä olevia lisäosia.

Ajatus on kokonaisvaltainen, mutta sitä voi jakaa osa-alueisiin, mikäli se tuo mahdollisuuden modernisoida järjestelmän osa-alueita yksi kerrallaan sen sijaan, että ajan puutteessa ei tehdä mitään.

Modernisointi tuo kustannustehokkuutta järjestelmän käyttämiseen ja ylläpitoon, ja vähentää pinnan alla kyteviä ongelmia. Modernisointiprojekti, niin pieni kuin suuri, on aina sopiva tilaisuus myös samalla linjata konfiguraatiomalleja yhteisen linjan mukaiseksi, erityisesti jos mallit ovat jääneet organisaation yleisestä IT-politiikasta jälkeen.

Onko tarvetta auditoinnille?

Auditoinnin lopputuotteena syntyy raportti, joka sisältää suosituksia järjestelmän käytön ja konfiguraation suhteen. Auditointia tilatessa asiakas valitsee auditoinnin laajuuden valmiilta listalta osa-alueita, joita ovat mm. tekniset konfiguraatiot, palvelunhallinnalliset toimintatavat (tuki ja ympäristön ylläpito ym.), sekä kehitysmallit ja sisältö. Auditoinnit kestävät yleensä noin 1-3 päivää laajuudesta riippuen. Auditointi hoidetaan etätyönä, ja vaatii pääsyn asiakkaan järjestelmään. Valmistumisen jälkeen tulokset käydään läpi yhteisessä päätöspalaverissa.