Suuri harppaus

 

Tietojärjestelmien kehitys olioilla ja ketterästi

Siitä kun lopetin sovelluskehitys työn alkaa olla kutakuinkin 10 vuotta. Törmäsin tilanteeseen, jossa minulle tuli tarve kertoa ketterästä kehittämisestä ja Scrumista ja havaitsin yllätyksekseni, että mistään blogistani EI löytynyt yhtään  artikkelia aiheesta.

No nyt korjaan tämän puutteen.

Tietojärjestelmistä ja monimutkaisuuden hallinnasta

Tietojärjestelmien kehittämisen ja ylläpidon haaste on aina ollut niiden monimutkaisuus. 

Tietokoneiden teknologian kehittymisen myötä,  tietojärjestelmien monimutkaisuus on kasvanut lähes eksponentiaalisesti viimeiset 50 vuotta. On siis aika luonnollista, että tietojärjestelmien toteutukset ovat aina olleet tuskaista taistelua.

Monimutkaisuuden hallinta onkin keskeisin avaintekijä tämän työn menestykseen.

Ensimmäinen näkemäni voitto monimutkaisuuden hallinnassa olivat tietokantojen synty.  

Relaatiokantojen käyttöönotto toi merkittävän edistysaskeleen.

80-luvun lopulla oivalsin, että tiedon ja siihen luonnollisesti liittyvän toiminnan yhteenliittäminen toisi oleellisen yksinkertaistuksen kokonaisuuteen. Koko tietokantayhteisö etsi tällaista ratkaisua. Kun sitten silkasta uteliaisuudesta 1989 osallistuin Petrer Coadin kahden päivän olioseminaariin Tukholmassa, ymmärsin kahdessa tunnissa, että nämä ihmiset olivat löytäneet tuon ratkaisun ja  kuinka yksinkertainen ja elegantti se olikaan.

Siitä alkoi pitkä ja monivaiheinen matkani olioiden maailmassa. Se päättyi vasta 2010 Yleisradion uuden Areenan oliomallin laatimiseen ja se ensimmäisen version toteutukseen.

Tämän jälkeen alalla ja varsinkin Tieto OYJ:ssä toteutui imperium vastaisku konservatiivisim ja ohjelmistobisneksen vaatimukset aiheuttivat menetelmien taantumisen ainakin 10 vuodella taaksepäin enkä tiedä onko tästä vieläkään toivuttu. Uusi olioparadigma oli selvästi liian vaikea ja abstrakti vanhoille tekijöille. Tieto irtisanoin minut 2011 kuukausi jälkeen 60-vuotis syntymäpäivieni.

Olioanalyysissä, suunnittelussa ja toteutuksessa keskeisin tavoite on kompleksisuuden hallinnassa. Tämä saavuttamisessa on olioparadigma ja abstraktiotason hallinta täysin keskeisiä. Olimme Finnairilla hankkineet Smalltalk-kehitysympäristön ja olimme oppineet ohjelmoimaan sen avulla tehokkaasti vuoteen 1995 mennessä.

Olin tehnyt olioanalyysia ja oliomalleja ihan  alusta lähtien, mutta kun yritin välittää ajatuksiani ja opettaa mallintamista, niin ihmiset eivät tuntuneet ymmärtävän ja oivalsin. että ajatukseni eivät olleet riittävän selkeät ja kirkkaat. Kävin useissa olioseminaareissa ympäri maailmaan ja olin sekä kuuluut, että pääosin lukenut kaikkia merkittäviä guruja.

Meni kuitenkin melko pitkään, ennen kuin kykenin selkäsi ajattelemaan ja argumentoimaan asiasta. Oivalsin monta asiaa: olioitettujen tapahtumien merkityksen, liiketoiminnan oliomallin irrottamisen sovelluksien vastaavista. Lähes kukaan guruista ei irroittanut liiketoimintamallia sovellusmallista ja tämä johti lopputulosten tarpeettomaan monimutkaisuuten. Olin saanut ajatteluni kiteytettyä 2005 vuoteen mennessä. Näinä vuosina tein paljon olionanlyysi koulutusta. Näiltä ajoilta on myös peräisin kolme olioanalyysi videota, jotka tein Tiedolla. Nämä ajatukset on koottu blogiteksteihin IT-dinosaurus blogille.

Itse asiassa useasti oliomenetelmiin petyttiin juuri väärän abstraktiotason valinnan takia. Kun aiemmin oli juuri painotettu sitä, että kaikki asiat pitää ensin analysoida ja lyödä lukkoon pinitä yksityiskohtaa myöten. Tämä johti kompleksisuuden räjähdykseen, jota kukaan ei kyennyt hallitsemaan. Kompleksisuuden hallinnassa ylivoimaisesti tärkeintä on pitää detaljien määrää mahdollisimman pienenä, jotta keskeiset rakenteet ja mekanismit paljastuvat. Tästä oli hyvä  esimerkki, kun IBM kehitti oliosovellusta ja olin tavannut yhden suunnittelutiimin jäsenen. Puolen vuoden jälkeen kun kyselin siitä, hän kertoi että luokkia oli suunniteltu 20 000 ja toteutusta ei oltu vielä aloitettu. Tästä hankkeesta ei koskaan tullut mitään. Liiketoimintaytimen ensimmäisessä toteutuksessa on tärkeää olla alle 100 luokkaa mieluummin noin 30 liiketoimintaluokkaa. 

Seuraava askel tällä tiellä onkin sitte Ketterä sovelluskehitys. Olen tutustunut Scrumiin jossain 2000-luvun puolivälissä. Tämä itseohjautuvien tiimien työskentelytapa on alun perin peräisin Japanin teknologiateollisuudesta 1980 ja 1990 lukujen vaihteesta. Scrum kehitettiin tukemaan oliokehitystä. 

1900-luvun lopulla oli sovelluskehityksessä vallaa V-malli ja vesiputosmalli. Tässä uusi tietojärjestelmä analysoitiin ja suunniteltiin viimeistä piirto myöten ja sen jälkeen syntyneet suunnitelmat toteutetiin. Usein tuo ensivaihe saattoi kestää yli vuoden isolta työryhmältä. 

Käytännössä nämä periaatteet eivät toimineet koskaan, sillä rakennelma on jo teoriassa mahdoton. Ensinkin laajojen kokonaisuuksien toteutettavissa oleva virheetön suunnittelu on inhimillisesti mahdoton tehtävä. Tämä johti siihen, että suunnitelmiin jäi ylimalkaisuutta ja vaiketa kohdat ohitettiin. Suunnitelmat sisälsivät paljon ristiriitaisuuksia ja dokumentaatiota oli liian paljon ollakseen toteutusvaiheessa mitenkään hallittavissa. Oleelliset rakenteet hukkuivat detaljeihin. Hanki siis konkreettisesti hukkui omiin suunnitelmiinsa. Jälkeenpäin voi vain ihmetellä sitä sokeutta, kun itsepäisesti päätä hakattiin tähän samaan seinään kerta toisensa jälkeen! 

Kun Ken Schwaber vei 1995 asiakkaidensa käyttämät sovelluskehitys prosessien kuvaukset DuBontin (kemianteollisuuden) tuotantoprosessin asiantuntijoille, ei naurulle tullut loppua.

Nämä asiantunijat kertoivat sovelluskehtys on niin monimutkainen ja ennustamaton, että tämä onnistui vain “empiirisellä” menetelmällä. He kertoivat, että tämä ei ollut mitään uutta vaan näin toimitaan kaikkien monimutkaisten ja vaikeasti hallittavien prosessien kohdalla.

Aina 1900 loppupuolelle saakka yleisesti uskottiin sovelluskehitys hankkeiden voitavan analysoida ja suunnitella täydellisesti ennen toteutusta. Näin siis opetettiin ja yritettiin toimiakin, mutta tämä ei toteutunut koskaan ja niinpä 1900-luvun sovellushankkeiden historia  on todella surullinen epäonnistumisien kertomus.. Todellisuudessa edes analyysi ei ole mahdollinen kuin johonkin pisteeseen saakka, jossa sovitaan keskeisten osien toteutusten periaatteista.

Aivan oleellinen ero tähän saadaan aikaan kun 1) analyysi aloitetaan rajatulla abstraktille pelkästään liiketoiminnan oliomallilla. Tästä saadaan liiketoiminna ytimen oleellinen oliorakenne ja toiminnallisuus olioiden yhteistoimintamalleilla (collaboration diagrams). 

2) Koko kehittämistyötä ohjataan ketterästi. Tämä tarkoittaa sitä, että lyhyehkön suunnittelujakson jälkeen toteutetaan jotain konkreettista lopullisesta tavoitteesta ja sitä seuraa taas suunnittelu. 

Tuo koko toiminnan raami on sitten Scrum. Scrum antaa mahdollisuuden suunnitella lähellä olevaan  kohtuulliseen horisonttiin saakka ja sen jälkeen todentaa suunnitelma toteuttamalla jotakin. Näin edeten pienin askelin kaikki osapuolet voivat arvioida konkreetisia saavutuksia ja tarkistaa etenemisen suunta ja tehdyt ratkaisut.