Artikkeli
13. helmikuuta 2018 · 3 min lukuaikaDigitalisaation perusteesit kuten “omni-kanavaisuus”, “asiakas360” ja ison datamassan hyödyntäminen vaativat arkkitehtuurilta kokonaisvaltaisuutta. Hyvällä arkkitehtuurilla varmistetaan, että yrityksen tarjoamat palvelut ja tiedot ovat käytettävissä kaikissa kanavissa.
Monissa organisaatioissa on huomattu, että pelkkä ketterän kehityksen vapaasti muodostama emergentti arkkitehtuuri ei tue monikanavaisuuden vaatimusta. Jotta palvelut voisivat olla monikanavaisia, datan ja prosessien olisi kuljettava järjestelmien välillä vaivattomasti.
Vaikka monet kyseenalaistavatkin yritysarkkitehtuurin tarvetta, on sen tärkeys päinvastoin kasvanut digitalisaation myötä. Ketteryys ohjata liiketoimintaa vaatii yritysarkkitehtuurin, joka tukee ketteryyttä ja muutosta. Hyvä yritysarkkitehtuuri tukee ketterää kehitystä – ei vaikeuta sitä.
Kokonaisuuden ymmärtäminen on ensiarvoisen tärkeää. On oltava taho, joka suunnittelee asioita riittävän isosti mutta käytännönläheisesti. Tämä on osoittautunut usein vaikeaksi. Liian ylätasolla liikkuvasta arkkitehtuurisuunnitelmasta ei ole hyötyä kellekään.
Hyvä yritysarkkitehtuuri tukee ketterää kehitystä – ei vaikeuta sitä.
Isommille organisaatioille tehtävä arkkitehtuurisuunnittelu täytyy jakaa pienempiin osakokonaisuuksiin ollakseen hallittava ja käytännönläheinen.
Monesti tässä epäonnistutaan, koska yritysarkkitehtuurin suunnittelu on virheellisesti jaettu organisaatiorakenteiden mukaisesti, jolloin arkkitehtuuri on alkanut muistuttaa organisaatiorakennetta (*). Organisaatiorakenne harvoin mukailee kehittämisen kannalta optimaalista arkkitehtuuria.
Organisaatiokaavioita piirrettäessä ei mietitä, että samalla vedeltäisiin paksulla pensselillä myös yritykselle kokonaisarkkitehtuuria. Tämän rakenteen ottaminen arkkitehtuurijaon pohjaksi tuottaa lopputuloksena usein kalliin, monimutkaisen ja toimimattoman IT-järjestelmien siilorakenteen. Tällaisen rakenteen päälle omni-kanavaisuuden, asiakas360:n, big datan ynnä muun toteuttaminen on vaikeaa tai jopa mahdotonta.
Arkkitehtuurin jakaminen pienempiin osiin on näennäisesti pieni askel, mutta käytännössä yksi tärkeimmistä askelista kohti hyvää yritysarkkitehtuuria.
Oleellista on ymmärtää jaon vaikutus yritysarkkitehtuurin lopputuloksiin. Siksi jako tulisi tehdä osana ylätason arkkitehtuurisuunnittelua. Jaon tulee huomioida sekä ketteryyden mahdollistaminen että kapselointi (encapsulation) ja riippuvuuksien minimointi. Pilkkomisessa tulee ymmärtää yrityksen liiketoiminta.
Avain on suunnittelun pilkkominen liiketoiminnan kannalta oikein jaettuihin ja hallittaviin kokonaisuuksiin - arkkitehtuuridomaineihin.
Arkkitehtuuridomainien tulee olla arkkitehtuurivisio- ja arvovirtalähtöisiä. Näillä ei siis tarkoiteta TOGAF-tyyppistä neljää standardimallista arkkitehtuuridomainia (business, applications, data ja technical). TOGAF:in tapa jakaa arkkitehtuurisuunnitteludomainit ei toimi, koska se jakaa arkkitehtuurityön sisältötyypin perusteella.
Arkkitehtuuridomainien välisten riippuvuuksien suunnittelu on ratkaisevassa roolissa, jotta iso kokonaisuus pysyy hallittavana. Vaikka arkkitehtuuridomainit pyritäänkin jakamaan mahdollisimman itsenäisiin kokonaisuuksiin, niiden välisten riippuvuuksien ymmärtäminen ja suunnittelu ovat ison arkkitehtuurikokonaisuuden ydinasia.
Riippuvuudet tulee suunnitella siten, että ketteryys on mahdollista sitä vaativissa arkkitehtuuridomaineissa, eivätkä riippuvuudet vähemmän ketteriin (ja ketteryyttä vaativiin) arkkitehtuuridomaineihin hidasta kehitystä.
Yritysten kehitysbudjetit ovat rajalliset, joten on tärkeää tunnistaa, mihin oma kehittäminen kannattaa kohdistaa ja missä voi hyödyntää valmiita palveluita tai tuotteita.
Arkkitehtuuridomainien välisten riippuvuuksien suunnittelu on ratkaisevassa roolissa, jotta iso kokonaisuus pysyy hallittavana.
Esimerkiksi Gartnerin Pace-Layered Application Strategy and IT Organizational Design (**) on hyvä apuväline arkkitehtuuridomainien luokittelussa. Pitää tunnistaa, missä arkkitehtuuridomaineissa tarvitaan ketteryyttä, mitä halutaan standardoida ja mitkä tippuvat tähän väliin. Tulee siis tunnistaa, millä alueilla halutaan innovoida tai vähintään erottua kilpailijoista ja millä taas sille ei ole tarvetta.
Innovatiiviseen ratkaisuun ei yleensä löydy valmista ohjelmistotuotetta, joten pääsääntöisesti se joudutaan kehittämään itse. Tuotetta joudutaan yleensä kustomoimaan, jos halutaan erottua kilpailijoista. Näillä asioilla on vaikutusta arkkitehtuuridomainien välisiin riippuvuuksiin. Riippuvuuksien tulee olla aina innovatiivisemmasta standardimpaan ja ketterämmästä jäykempään päin.
Kun arkkitehtuuridomainien riippuvuudet ovat selkeät, voidaan niiden sisällä suunnitella arkkitehtuuria kohtuullisen vapaasti, eli mahdollistaa ketteryys. Yritysarkkitehtuuria suunnitellaan itsenäisinä hallittavan kokoisina paloina, mutta kuitenkin kaikki suunnittelevat samaa isoa kokonaisuutta.
Käytännössä tärkein asia on kuitenkin se, että arkkitehtuuridomainit mahdollistavat kokonaisvaltaisesti suunnitellun ja modulaarisen yritysarkkitehtuurin rakentamisen. Tällä edesautetaan liiketoiminnan laajamittaista ketterää kehittämistä.
* Conwayn laki: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
** Gartner Pace-Layered Application Strategy and IT Organizational Design
Lue myös aiemmat arkkitehtuuria käsittelevät blogit:
Arkkitehdin rooli ketterässä organisaatiossa
Arkkitehtuuriohjauksen dilemma
Kirjoittaja
Tommi Laitila on kokenut yritysarkkitehti sekä ketterien ja lean -menetelmien valmentaja ja kouluttaja. Tommi on myös yksi Nitorin perustajista ja Nitorin teknologiajohtaja. Kestävän digitaalisen kehityksen lisäksi Tommi suhtautuu intohimoisesti purjehdukseen ja koripalloon.
