Hyvä arkkitehtuuri IT-Projektissa

Kirjoitin aikaisemmin Tampereen PM-Clubin avajaistilaisuudessa pitämästäni esitelmästä , jossa esittelin keinoja, millä estetään ns. Megakatastrofi, eli liiketoimintaa vahingoittava totaalinen epäonnistuminen käyttöönottovaiheessa. Näitä keinoja ovat: Perusasiat kuntoon Suorituskykytestaus Pilotointi Mahdollisuus palata […]

05.06.2012 // Tero // No Comments //

Kirjoitin aikaisemmin Tampereen PM-Clubin avajaistilaisuudessa pitämästäni esitelmästä , jossa esittelin keinoja, millä estetään ns. Megakatastrofi, eli liiketoimintaa vahingoittava totaalinen epäonnistuminen käyttöönottovaiheessa. Näitä keinoja ovat:

  • Perusasiat kuntoon
  • Suorituskykytestaus
  • Pilotointi
  • Mahdollisuus palata takaisin vanhaan toimivaan järjestelmään

Sain yleisöstä kommentin, että eikö tähän listalle kuuluisi myös hyvä arkkitehtuuri. Vastasin kysymykseen mielestäni melko huonosti ja asia jäi mietityttämään. Siksi palaan siihen nyt.

Ei voida kiistää sitä, etteikö hyvä arkkitehtuuri olisi tärkeä asia. Ongelmana projektipäällikön ja muunkin johdon kannalta on, että

mistäs tiedät onko arkkitehtuuri hyvä?

IT-järjestelmän tai ohjelmiston arkkitehtuurisuunnittelu ei ole mikään triviaali tehtävä, eikä sitä ole myöskään sen laadun arviointi. Organisaatiossa ei tyypillisesti ole kovinkaan montaa henkilöä, joilla on kompetenssia arvioida arkkitehtuurisuunnitelman hyvyyttä ja nämä henkilöt eivät koskaan ole joutilaita vaan aina hyvinkin työllistettyjä.

Toki yleensä ongelmaan vastataan valitsemalla arkkitehdeiksi henkilöitä, joilla tiedetään olevan hommaan vaadittava pätevyys, mutta kun se Maailman Paras Arkkitehtikin voi tehdä virheitä. Ja kun niillä miehillä/naisilla on pelattava, mitä joukkueessa on, niin joskus joudutaan tekemään kompromissejä ja ottamaan riskiä tässäkin asiassa.

Toinen ongelma on, että vaikka arkkitehtuuri olisi hyvin suunniteltu, voi järjestelmän toiminta kaatua hyvinkin pieneen yksityiskohtaan. Vaikka kaikki kolmannen osapuolen komponentit olisi huolella valitttu ja testattu, niin silti voi olla, että juuri meidän käyttämässämme ympäristössä, juuri ja vain meidän tarvitsemallamme konfiguraatiolla juuri meidän tuotantoliikenteellä jostain komponentista paljastuu aikaisemmin tuntematon vika, joka kyykkää koko järjestelmän.

Juuri näihin riskeihin mainittu neljän kohdan lista puree: vaikka arkkitehtuurisuunnitelmassa on bugi tai jokin komponentti ei toimi niin kuin pitäisi, niin silti voidaan estää tilanteen leviäminen käsiin ja selvitään jotenkuten kuivin jaloin.


Leave a Comment

Your email address will not be published. Required fields are marked *

Kommentoi