Maailma muuttuu, vai muuttuuko? Kolme onnistumisen edellytystä integraatioprojekteille

Menetelmiä, välineitä ja osapuolia on softaprojekteissa enemmän kuin koskaan aiemmin. Onko teknologian määrä ylittämässä hallittavuuden, ja onko yhtään projektia mahdollista saada enää onnistumaan? Vanhat perusasiat kantavat haastavissakin projekteissa.

Vanhassa vitsissä kysytään, kuinka iso joukko ruotsalaisia tarvitaan vaihtamaan hehkulamppu. Aidolta nykyajan vitsiltä saattaa kuulostaa, kuinka paljon erilaisia ratkaisuja ja ihmisiä vaaditaan nykyään siihen, että tieto siirtyy paikasta a paikkaan b (ottaen huomioon, että tekniikka on parempaa kuin koskaan aiemmin). On lähettävän- ja vastaanottavan pään järjestelmää, palomuuria, kuormantasainta, väylää, turvakerrosta, verkkokonfiguraatiota, virustorjuntaa, sertifikaattia jne.

Mieleen voi tulla, kuinka yhtään projektia on mahdollista saada onnistumaan tässä teknologiaviidakossa. Ratkaisu on yllättävän yksinkertainen: paluu perusasioihin. Yli 20 vuoden kokemuksella väistämättömä onnistumisen edellytyksiä ovat:

  • määrittely
  • dokumentointi
  • johtaminen

Vuonna 1998 kuulin lausahduksen, että viime kädessä menetelmillä tai välineillä ei ole mitään merkitystä, vaan ainoastaan sillä, ketkä työn suorittavat. Punnitaan ajatusta: Jos tiedetään, mitä tehdään (määrittely), osataan tehdä oikeat ratkaisut (suunnitellaan eli dokumentoidaan miten tehdään) ja tiedetään, milloin tehdään (johtaminen), niin onnistuminen on todennäköisintä. Näin onkin yllättäen ollut niissä projekteissa, joihin olen yli 20 vuoden aikana osallistunut roolissa tai toisessa. Tai eihän toki kaikissa – niissä, jotka ovat menneet pieleen, on ollut toisenlaisiakin tapoja.
 

Näitä SOA-maailman onnistumisen perusasioita olemme pyrkineet noudattamaan esimerkkiprojektissamme, jota olen kuvaillut aiemmissa teksteissäni.

Uutta teknologiaa tai ketteriä menetelmiä, vanhat periaatteet pätevät

Aika ajoin kehittäjäpiireissä nousee pinnalle erilaisia ilmiöitä. Viime vuosina on kohistu REST-tekemisestä. Myös ketterästä kehityksestä puhuminen pysyy muodissa. Ei pidä ymmärtää väärin; en tyrmää kumpaakaan, kun niitä sovelletaan oikein.

Ketteriä menetelmiä kiitetään nopeasta liikkeellelähdöstä. Ketterä menettely ei kuitenkaan ole vapautus sille, ettei tarvitse tietää tai dokumentoida, mitä tehdään. Jos nopeus saavutetaan määrittelyn ja dokumentoinnin kustannuksella, voi käydä niin, että tekeminen on kivaa, ketterää ja päämäärätöntä – Päämäärättömyydellä viittaan sellaisiin ketteriin projekteihin, joissa kaikkein ketterintä on valmistumispäivän siirto eteenpäin. Liiketoiminnan kannalta se ei riitä, vaan on tultava myös valmista. Ketterä projekti onkin helppo aloittaa, mutta vaikea päättää, jos perusasiat eivät ole kunnossa.

Ketterä menettely ei ole vapautus sille, ettei tarvitse tietää tai dokumentoida, mitä tehdään.

REST on osoittautunut juuri niin helpoksi kuin olen pelännytkin. Sen käyttö on kehittäjistä mukavaa, kun voi välitellä tietoa helposti muokattavassa JSON-formaatissa, ja itse palvelua on nopea ja helppo muuttaa. Ainut pikku juttu, joka tuppaa unohtumaan, on se, että palveluviidakossa nämä periaatteet eivät lainkaan toimi.

Lähes kaikissa tuntemissani tapauksissa olisi ollut nopeampaa määrittää rajapinnat selkeästi (esim. WSDL/XSD, tai REST/XML). Järjestelmien välinen palveluiden käyttö olisi valmistunut puolessa nyt käytetystä ajasta tuotantoon, koska kaikilla osapuolilla olisi alusta alkaen ollut sama näkemys siitä, mitä dataa kulkee ja missä tarkassa formaatissa.

Liian harva REST-rajapintojen tekijä näyttää tuntevan esim. Richardsonin Maturity Modelin, tai ainakin siltä näyttää, kun erinäisiä REST-toteutuksia katsoo. Vielä kun muistellaan, mitä kaikkea ”yllättäviä” ongelmia tuli 90-luvulla verkkosovellusten myötä (URL-enkoodaus, merkistöt, parametrien välittäminen, purkaminen, tietoturva, jne.), niin nyt samat kuopat näytetään käyvän läpi REST-maailmassa pääosin niiden ihmisten toimesta, jotka eivät olleet kompuroimassa 90-luvulla. REST toteuttaminen näyttää vieläkin olevan valitettavan villiä touhua, ja eri välineet tukevat sitä omilla tavoillaan. Osassa projekteja siitä on tullut jopa pakollinen paha, jonka kautta luullaan automaattisesti saavutettavan kustannussäästöjä.

Perusasiat eivät ole muuttuneet 20 vuodessa – temppu on pitää ne mielessä, ja samalla ottaa haltuun uusia tekniikoita ja toimintatapoja.

Käytännössä REST-tekemisessä on noudatettava samoja tylsiä periaatteita kuin muussakin tekemisessä. Oikeastaan perusasiat eivät ole muuttuneet lainkaan 20 vuoden aikana. Edelleen pitää tietää mitä tehdään, miten ja milloin. Temppu onkin pitää nämä periaatteet mielessä, ja silti ottaa haltuun uusia tekniikoita ja toimintatapoja, ketterästi vieläpä.

Teknologian liialliseen määrään liittyvään kysymykseen minulla ei ole vastausta. Sitä joutuu jokainen itse punnitsemaan. Lukijat, mitä sanotte? 

Jaatko Teron periaatteet, vai janoatko päästä haastamaan ne? Haemme integraatioarkkitehtejä, katso avoimet paikat:

New Call-to-action



tiedon hyödyntäminen   integraatio




Tero Rönkä | Chief SOA Architect

Tero Rönkä | Chief SOA Architect

Teron erityisosaamista on liiketoiminnan ja IT:n yhdistäminen sopivia tekniikoita hyödyntäen. Hän on käytännönläheisenä arkkitehtinä keskittynyt viime vuodet integraatioihin ja palvelupohjaisiin ratkaisuihin, aina toteutuksesta hallinnointiin. Terolle on tärkeää olla tempautumatta nopeatahtisen arjen vietäväksi: hän tarkastelee asioita analyyttisen rauhallisesti ja arvostaa konkreettisia lopputuloksia. Hänen johtoajatuksensa on, että ylimitoitettujen toiveiden ja täydellisyyden tavoittelun sijaan kannattaa keskittyä lopputuloksiin, jotka ovat konkretisoitavissa hyödyksi arjessa. Vapaa-ajalla Tero tuulettaa ajatuksia polkupyörän selässä ja frisbeegolfkentällä.

Kirjoittajan kaikki blogitekstit

Tilaa blogikirjoitukset sähköpostiisi




Seuraa meitä somessa

LinkedIn Twitter Facebook YouTube