Ohjelmistoarkkitehtuuria kuninkaille – 8 vinkkiä



Kuningas (c) epSos.de

Joskus muinoin, ei niin kovin kauan sitten, tietojärjestelmien suunnittelu ja toteuttaminen oli helppoa. Vaatimukset sai kysymällä tilaajan edustajilta, asiakkailta eli loppukäyttäjiltä ei kovin paljon tarvinnut kysellä. Kun vaatimukset olivat selvillä, oli suoraviivaista suunnitella ne täyttävä ohjelmistoarkkitehtuuri: tietokanta ja sen päälle lomakejärjestelmä käyttöliittymäksi. Käyttäjät käyttivät, koska heillä ei yleensä ollut muuta mahdollisuutta. Järjestelmät olivat näet pääosin työkäytössä, eikä samaan firmaan montaa kilpailevaa järjestelmää hankittu.

Nyt tilanne on toinen. Jokaisella on nykyään käytössä maailman parhaat ja viimestellyimmät käyttöliittymät, jotka toimivat kaikilla eri alustoilla tietokoneesta mobiiliin. Käyttöliittymät ovat helppokäyttöisiä, intuitiivisia, käyttäjään ja hänen toimintaansa mukautuvia. Käyttäjät – me kaikki – oletamme, että kaikki järjestelmät ovat vähintään yhtä hyviä kuin Facebook, Google Mail, Instagram, Spotify, Moves ja niin edelleen. Huonompia emme mukisematta käytä – jos käytämme laisinkaan.

Ohjelmistojen ja erityisesti ohjelmistoarkkitehtuurin suunnittelu on muuttunut yhtäkkiä paljon vaikeammaksi. Vaatimukset ovat niin kovia, verrokkiryhmän käyttöliittymät ja käytettävyys niin hyviä, ettei virheisiin ole varaa. Jos uuden järjestelmän käyttöliittymä ei miellytä tai sen käytettävyydessä on ongelmia ohjelmistoarkkitehtuurista johtuen, käyttäjät katoavat.

Käyttäjä on kuningas

Käyttäjästä on sukeutunut kuningas. Kuninkaana hän odottaa saavansa mitä parhainta palvelua: ilmaista, koska kuninkaat eivät maksa; helppokäyttöistä, koska kuninkaat eivät lue ohjeita; jatkuvasti parantuvaa, koska kuninkaalle ei mikään ole riittävän hyvää. Jos kuninkaan saa maksamaan, hän osoittautuu kitsaaksi. Isot lisenssimaksut liiketoiminnan perustana on syytä unohtaa.

Kuningas on myös kärsimätön. Järjestelmien on toimittava yhtä nopeasti, kuin kuninkaan ajatus. Oikeastaan järjestelmän on pystyttävä ennakoimaan kuninkaan ajatukset ja tarjottava kuninkaalle hänen tarvitsemiaan tietoja ja vaihtoehtoja jo ennen kuin kuningas itsekään tietää niitä haluavansa. Järjestelmän on oltava älykäs, mutta ei liiaksi, koska kuningas ei halua tulla aliarvioiduksi.

Joskus kuningas liikkuu netissä tuntemattomana, anonyyminä. Hän käyttää järjestelmiä aikansa ja jos hän jonkin järjestelmän havaitsee hyväksi ja hyödylliseksi, hän paljastaa identiteettinsä. Kuningas kuitenkin pahastuu, jos hänen anonyyminä ollessaan keräämänsä tieto ja tekemänsä valinnat katoavat. Kuningasta ei ole helppoa palvella. Hän on oikukas.

Ohjelmistoarkkitehtuuria kuninkaille

Miten sitten suunnitella kuninkaille sopivaa ohjelmistoarkkitehtuuria? Mitä asioita on otettava huomioon? Mitä ohjelmistoarkkitehdin on tiedettävä, mitä osattava? Ainakin seuraavat kahdeksan asiaa on syytä ottaa huomioon ohjelmistoarkkitehtiä valittaessa ja ohjelmistoarkkitehtuuria suunniteltaessa.

  1. Ohjelmistoarkkitehdin on tunnettava lukematon joukko moderneja järjestelmiä, ymmärrettävä niiden hyvät ja huonot puolet, erilaiset käyttöliittymäparadigmat ja niistä johtuvat vaatimukset järjestelmän muille osille. Arkkitehdin on siis syytä käyttää paljon aikaa erilaisiin järjestelmiin tutustumiseen. Kännykkää räpläävä ohjelmistoarkkitehti saattaa tehdä töitä, ei surffailla pitkästyneenä.
  2. Ohjelmistoarkkitehdin on pystyttävä tekemään luontevasti töitä käyttöliittymäsuunnittelijoiden ja käytettävyysasiantuntijoiden kanssa. Koska käyttöliittymän käyttäminen on paljon opettavaisempaa, kuin käyttöliittymästä puhuminen, ohjelmistoarkkitehdin on joko itse pystyttävä rakentamaan riittävän todenkaltainen prototyyppi tai oltava sosiaalisesti niin lahjakas, että saa koodaajat protoilemaan hyvinkin epämääräisten ideoiden perusteella.
  3. Ohjelmistoarkkitehdin on ymmärrettävä, mitkä käyttöliittymän ominaisuudet ovat olennaisen tärkeitä järjestelmän back-end monimutkaisuuden kannalta. Hänen on pystyttävä kertomaan tilaajalle/maksajalle, mitä minkäkinlainen käyttöliittymä tarkoittaa hinnan ja/tai aikataulun kannalta.
  4. Ohjelmistoarkkitehdin on oltava tiukkana joidenkin vaatimusten suhteen. Erityisesti vasteaikojen määrittäminen on olennaisen tärkeää. Miten kauan käyttäjä on valmis odottamaan? Vasteaika on hyvin olennainen tekijä järjestelmän hinnan määräytymisessä.
  5. Ohjelmistoarkkitehdin on syytä tajuta, että käyttäjät saattavat käyttää järjestelmää hyvin eri tavalla, kuin järjestelmä on suunniteltu käytettäväksi. Järjestelmää ei pidä mitoittaa tai muutoin rajoittaa.
  6. Ohjelmistoarkkitehdin on valmistauduttava jatkuvaan muutokseen. Järjestelmä on suunniteltava niin, että sitä on helppoa muuttaa käyttäjien käytöksessä havaittavien muutosten myötä. Järjestelmä on myös suunniteltava niin, että sitä voidaan muuttaa vähitellen, muutosten suosio käyttäjillä heidän tietämättään testaten.
  7. Ohjelmistoarkkitehdin on oltava rohkea. Hänen on uskallettava kertoa tilaajalle, jos tilaajan taustajärjestelmien tai muiden nykyjärjestelmien päälle ei voi rakentaa modernia käyttöliittymää. Ei ole järkeä tehdä huonoa käyttöliittymää vain ikivanhojen taustajärjestelmien vuoksi. Joko on korvattava vanhat järjestelmät uusilla tai piilotettava ne jonkin nerokkaan välikerroksen taakse.
  8. Ohjelmistoarkkitehti ei saa rakastua työnsä tuloksiin. Nykyinen kehitysvauhti voi vaatia järjestelmien uudelleen toteuttamisen muutaman vuoden välein. Olennaista on olla suututtamatta kuningasta.

Ohjelmistoarkkitehtuurin merkitys kasvaa koko ajan. On hyvä huomata, että kuningas pitää hyvästä ohjelmistoarkkitehtuurista, vaikkei hän siitä mitään ymmärräkään. Mitä vähemmän kuningas kiinnittää huomiota järjestelmään, sen parempi. Valitettavasti tämä vaatii vuosi vuodelta enemmän työtä ja osaamista ohjelmistoarkkitehdeiltä.

Tämän artikkelin on kirjoittanut Matti Kinnunen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *