Arkkitehtuuri­ohjauksen dilemma

Tämä on ollut erityisen ikävä yllätys yrityksissä, joissa on vuosia määrätietoisesti investoitu kokonaisarkkitehtuurin kehitykseen. Sen tavoitteena oli ohjata yrityksen arkkitehtuurin kehitystä, mutta kävikin päinvastoin:

Yrityksen johdolle on syntynyt valheellinen mielikuva, että kokonaisuus olisi hallinnassa.

Tarve ei kuitenkaan ole kadonnut mihinkään – arkkitehtuurivisio ja ymmärrys IT-arkkitehtuurin kokonaiskuvasta on tärkeämpää kuin koskaan, jotta yritys voi tuottaa uusia, kattavampia ja jopa organisaatiorajat ylittäviä digitaalisia palveluja.

Kehittämisen nopeus on kuitenkin noussut aivan uudelle tasolle. Jos vielä vuosikymmen sitten pystyttiin kehittämisen portfolio kiinnittämään koko vuodelle tai jopa vuosiksi eteenpäin, nyt dynaamisimmissa yrityksissä alkaa olla vaikea kiinnittää se seuraavalle kvartaalille.

Perinteinen holistinen yritysarkkitehtuurityö ja sen hallintamallit eivät enää pysy mukana tällaisessa vauhdissa.

Kun soppaan tuodaan vielä mukaan ketterät menetelmät, joissa päätöksen tekoa hajautetaan ketterille toteutustiimeille, tekniikoiden nopea kehittyminen sekä pilviteknologian ja big datan kaltaiset mullistukset, ollaan ihmeellisessä tilanteessa: tiedetään, että onnistumisen edellytyksenä on arkkitehtonisen kokonaiskuvan ymmärtäminen ja ohjaus, muttei ole keinoa pitää sitä ajantasaisena saati varautua vielä tuntemattomaan tulevaan.

Ketterät menetelmät tarjosivat ratkaisuksi muovautuvaa suunnittelua (emergent design), jossa arkkitehtuuri muodostuu ratkaisua tehdessä ja ongelmia ratkotaan sitä mukaa kun ne tulevat vastaan. Tämä toimikin mainiosti riittävän rajatuissa ympäristöissä ja oli erinomainen tapa päästä eroon perinteisestä vahvasta ja usein kehitystä hidastavasta arkkitehtuurin etukäteen suunnittelusta ”design up front”.

Muovautuva suunnittelu nopeutti kehitystä ja poisti paljon perinteisiä hitausmomentteja.

Se kuitenkin hämärsi entisestään isoa kuvaa. Kun ketterän kehittämisen käyttö yrityksissä laajeni, alettiin huomata, ettei arkkitehtuuri ollut enää hallittavissa.

Kun digitalisaatio toi mukanaan tarpeita rakentaa palveluita yli pitkien arvoketjujen, tämä ei enää onnistunutkaan. Huomattiin, että oli menty ääripäästä toiseen – jäykästä villiin – eikä sekään lopulta ollut oikea ratkaisu. Niin kuin monesti, kultainen keskitie on jossain siinä välissä.

Ratkaisu tämän päivän nopeaan digitalisaatioon ei todellakaan ollut perinteinen holistinen arkkitehtuuriohjaus (kuten TOGAF), mutta ylätason arkkitehtuuriohjauksen poistaminenkaan ei tuonut haluttuja tuloksia.

Nyt useimmat isot yritykset ovat limbossa, jossa tehdään huonosti jalkautuvaa ylätason arkkitehtuuriohjausta ja ketterä tekeminen lisää entropiaa jatkuvasti.

Tarvitaan mahdollisimman Lean arkkitehtuuriohjaus, joka ottaa asioita huomioon jo kehitysportfolion tasolla, mutta mahdollistaa kuitenkin päätöksenteon hajauttamisen ja tiimien autonomian mahdollisimman pitkälle.