Pingauksia verkkoon

Näkökulmia tietoturvaan ja tietoliikenteeseen

Mistä tunnistat huonon arkkitehtuurin (tai että sitä ei ole ollenkaan)?

16. marraskuuta 2017

Kuva: kaatuneet shakkinappulat

Tuntuuko, että yrityksen päivittäinen toiminta ei ole tehokkaimmillaan ja tarvittaisiin jotain ryhtiä ICT-järjestelmien toimintaan ja käyttöönottoon? Tuntuuko, että kustannukset karkaavat käsistä ja resurssit eivät riitä? Tuntuuko, että asiakastyytyväisyys ja luottamus yrityksen palveluihin ei ole paras mahdollinen?

Tässä lista varoittavia merkkejä, joista tunnistat, että yritykseltä puuttuu arkkitehtuuri tai se ei toimi kunnolla.

Yksittäisratkaisut. Kaikki haluavat oman parhaan ratkaisunsa ja toimintaa ei ajatella kokonaisuutena. Yksittäisten järjestelmien välille joudutaan rakentamaan liitoksia ja se on työlästä.

 

Päällekkäiset järjestelmät. Jokainen järjestelmä tai sovellus on tarpeellinen ainakin yhden ominaisuuden takia, mutta turhaa päällekkäisyyttä on paljon. Päällekkäisyyden ylläpitäminen maksaa ja vie resursseja.

 

Päällekkäinen tieto. Usein sovellukset tarvitsevat samaa tietolähdettä, mutta saman tietokannan käyttäminen ei ole mahdollista. Tiedon monistaminen eri paikkoihin on hankalaa, työlästä ja riskialtista. Työ tehdään liian usein käsin. Turhan työn määrä ja virheiden mahdollisuus kasvaa.

 

Liikaa rajapintoja. Kaikkien käytössä olevien järjestelmien, sovellusten ja tietovarastojen välillä tarvitaan paljon liitoksia.  Aikaa menee entistä enemmän rajapintojen toteuttamiseen kuin uusien ominaisuuksien hyödyntämiseen ja käyttöönottoon. Suuri määrä rajapintoja tekee ympäristöstä herkän ja vaikeasti hallittavan. Palveluväylä ei ratkaise todellisia ongelmia, vaan piilotettu hämähäkinverkon jonkun järjestelmän taakse.

 

Purkkaviritykset. Kiire ja välinpitämättömyys johtavat nopeisiin ja kestämättömiin "saadaan-tämä-vain-jotenkin-toimimaan-ja-se-riittää"-virityksiin. Järjestelmistä tulee vikaherkkiä ja vaikeasti korjattavia ja uusittavia.

 

Vanhentunut tekniikka. Varsinkin liiketoimintakriittisissä järjestelmissä ja infrastruktuurissa voi olla vaikea luopua vanhasta tekniikasta ja korvata se lopullisesti uudella. Vanhan ylläpitäminen syö resursseja, maksaa ja vaikeuttaa uusien järjestelmien ja sovellusten käyttöönottoa huomattavasti.

 

Huono käytettävyys. Järjestelmät eivät toimi kunnolla ja ne eivät täytä käyttäjien tarpeita. Ylläpitäjien aika kuluu järjestelmien korjailuun ja käyttäjät odottavat ja tuskailevat miten saisivat järjestelmällä jotain aikaiseksi. 

 

Tiedon rikkonaisuus. Kun tietoa on monessa paikassa ja sitä käsitellään manuaalisesti, se helposti korruptoituu ja kaikki tieto ei ole oikeassa paikassa saatavilla.

 

Järjestelmät luovat monimutkaisuutta. Helppojen yksinkertaisten prosessien toteuttamiseen tarvitaan monimutkaisia järjestelmiä. Samoja työtehtäviä joudutaan toistamaan useaan kertaan. Tuotteet on valittu huonosti ja ne eivät toimi yhteen. Käyttäjät turhautuvat, kun aika tuhrautuu turhaan työhön.

 

Työkalujen ja ominaisuuksien puute. Käyttäjillä on jatkuva tarve uusille työkaluille tai ominaisuuksille, joita ei voida toteuttaa olemassa olevilla järjestelmillä. Työkalut on valittu väärin, koska ne eivät toteuta käyttäjien tarpeita.

 

Kommunikaation ja yhteistyön puutteet. Järjestelmät eivät tue moderneja kommunikoinnin ja yhteistyön tarpeita ja välineitä. Käyttäjien yhteistyö ei toimi, tieto ei kulje ja aikaa kuluu hukkaan.

 

Huono tai liika muokattavuus. Järjestelmää ei voi muokata omaan käyttöön sopivaksi tai koko järjestelmä tehdään juuri tätä tapausta varten. Kummassakin ääripäässä on riskinä, että järjestelmä ei toteuta haluttuja ominaisuuksia. 

 

Isot kulut. Järjestelmän päivittäminen tai uusien ominaisuuksien tuominen maksaa maltaita. Muutos vaatii lisäksi paljon työtä ja konsultteja avuksi.

 

Turhat ohjeet. IT-osasto tuottaa ohjeita ja määrityksiä kaikkeen mahdolliseen, joita kukaan ei sitten kuitenkaan lue, saati noudata. Arkkitehtuuria ei ole otettu osaksi toimintaa ja prosesseja. Se jää ylätason höpinäksi, joka ei hyödytä ketään.

 

Turhat työt. Kaikki edellä mainittu tehottomuus johtaa koko organisaation kattavaan turhaan työhön. Ihmisiä tarvitaan siirtelemään ja muokkaamaan tietoa, koska järjestelmät eivät kykene toimimaan keskenään. Päällekkäisten ja usein monimutkaisten järjestelmien ylläpitoon kuluu suurin osa ajasta ja aikaa ei jää tuottavammalle uusien asioiden kehittämiselle.

 

Huono asiakastyytyväisyys. Kaikki nämä mainitut asiat vaikuttavat suoraan tai välillisesti yrityksen tärkeimpään eli asiakastyytyväisyyteen. Asiakkaiden tyytyväisyys ja luottamus näkyvät liiketoiminnan tuloksina.

 

Mikä on siis huonon arkkitehtuurin todellinen hinta?

Ainakin valtava määrä hukattua aikaa ja rahaa kaikkeen turhaan järjestelmien ja tiedon pyörittelyyn. Jos nämä resurssit saataisiin muuhun käyttöön, se voisi poikia jotain hyödyllistä ja eteenpäin vievää toimintaa, ja motivoida työntekijät aivan uudelle tasolle. Huono arkkitehtuuri johtaa tuotantojärjestelmien häiriöihin ja sitä kautta liiketoiminnan jatkuvuuteen. Asiakkaiden ja käyttäjien suuntaan pelissä on yrityksen ja palveluiden maine, uskottavuus ja luottamus. Pahimmillaan kyseessä voi olla ihmishenget. Olisiko siis aika laittaa arkkitehtuuri kuntoon kulmia suoristamatta ja mutkia oikomatta? 

Seuraavassa blogitekstissäni kerron mitä hyvään arkkitehtuuriin kuuluu ja miten sen toteuttamisessa voi onnistua.


Antti Leimio

 

Olen helsinkiläinen tietoliikenneinsinööri, jolla on pitkä kokemus tietoliikenteestä palveluntarjoajan verkoissa. Olen rakentanut tietoliikenneratkaisuja erilaisille palveluille ja sovittanut palveluita verkon päälle. Erikoisosaamistani ovat MPLS-tekniikka ja -palvelut, konesaliverkot, internet, sekä IP multicast ja audio/videopalvelut.

 

Vapaa-ajalla tykkään puuhailla jotain konkreettista, kotoilla ja matkailla. Harrastan rintamamiestaloelämää lähiössä vaimon ja kolmen tyttären kanssa. Yritän seurata alaa ja jakaa ideoita ja näkemyksiä: Teknisempää ja viihteellisempää asiaa Twitterissä ja yleisempää LinkedInissä.