Pitääkö kokonaisarkkitehtuuria johtaa? Eikö se tapahdu itsestään? Ai, eikö? No, kenen tehtävä se oikein on? Mitä sitten pitäisi tehdä?
Kokonaisarkkitehtuuri voi olla Lean-periaatteita noudattavaa eli asiakaslähtöistä, virtaustehokasta, hukkaa välttävää, jatkuvaa parantamista jne. Mielestäni kokonaisarkkitehtuuri on jo määritelmällisesti ketterää, mutta ehkä se ei olekaan itsestään selvää.
EU:n tietosuoja-asetus GDPR edellyttää organisaatioilta varsin tarkkaa tietoa siitä, mitä kaikkia henkilötietoja käsitellään, kuinka kauan ja millä perusteella sekä missä tiedot sijaitsevat. Tämän kaiken selvittäminen on huomattavasti helpompaa, kun kokonaisarkkitehtuuri on käytössä.
Valmisohjelmistoa valittaessa tehdään usein pitkiä listoja toiminnoista, joita tuotteen pitää sisältää. Tietomalli jää sitä vastoin helposti analysoimatta.
Kieli on ajattelun väline. Sen takia onkin vähän kurjaa, jos ei malteta miettiä fiksuja suomennoksia. Toisaalta, kyllähän termejä käännetään, mutta jäävätkö ne elämään...
Valitse sopivin! Valittavalle ohjelmistolle asetettujen vaatimusten määrä on usein suuri. Tämä aiheuttaa haasteita valinnalle. Ilman vaatimusten priorisointia valituksi saattaakin tulla eniten ominaisuuksia sisältävän ”paras” tuote – ei sopivin.
Kokonaisarkkitehtuuria tulee käyttää, jotta siitä olisi jotain hyötyä. Käytännössä voi kuitenkin käydä niin, että päädytään vain tuottamaan kasoittain arkkitehtuurikuvauksia ja toivotaan, että kyllä ne hyödyt sieltä syntyvät.
