Miten lähteä avaamaan rajapintoja?

API-rajapinnoilla voidaan rakentaa vaikka kokonaan uusia liiketoimintamalleja, ja monesti ne tuovat silkkaa säästöä. Miten rajapintojen avaamiseen kannattaa lähteä?

Rajapinta on englanniksi interface ja API tarkoittaa suomeksi käännettynä ohjelmiston kehitysrajapintaa. Käytän tässä blogipostauksissa API-rajapinta-ilmaisua, vaikka se onkin vähän tautologinen.

Klassinen ja mahdollisesti yksinkertaisin esimerkki rajapinnasta on verkkosivut. Jos organisaatiollasi on siis verkkosivut, tarjoat kömpelönä APIna html-koodia. Fiksumpi rajapinta voisi olla rakennettu hyödyntämään esimerkiksi verkkosivun tuotantojärjestelmää REST-rajapintojen pyörittämiseen.

HTML-koodi ja REST-rajapinnat ovat ohjelmisto-, käyttöjärjestelmä- ja lisenssivapaata. Voit tarjota HTML:ää linux-palvelimella ja sitä on yhtä helppo lukea iPhonella kuin Windows-tietokoneellakin. Hyvä rajapinta ei edellytä samojen laitteiden tai ohjelmistojen ostamista, joita sen toisella osapuolella on.

 

Muista tietoturva

Kaikki eivät ole aina kuitenkaan suoraan avoimien rajapintojen ystäviä. Tietoturvapuolella monella on kiusaus joko refleksinomaisesti todeta, että tosi hienoa kun kokeillaan uusia juttuja, mutta suin päin ei sellaisia pitäisi kokeilla. Tai jopa sanoa, että ei kannata kokeilla – koska emme kaikkein vaikeimpia rajapintoja osaa kuitenkaan tehdä, on ajanhukkaa puhua niistä.

Tietoturva on otettava tosissaan, mutta päätä ei kannata laittaa kuitenkaan pensaaseen. Rajapintojen turvallisesti tekeminen on mahdollista ja jopa välttämätöntä, jotta niitä osaa käyttää, kun moinen osoittautuu kaupallisesti välttämättömäksi.

Rajapinnoissa voi soveltaa sotasairaaloiden mallia ajankäytön priorisoinnille; jos ei ole pitkää kokemusta rajapinnoista, luottamuksellisille henkilötiedoille kannattaa varmasti aluksi sanoa ei. Ei aloiteta liian vaikeasta, potilas kuolee joka tapauksessa.

 

Opettele toiminnallisilla rajapinnoilla

Niin sanotuissa datarajapinnoissa on ideana, että niissä vain jaetaan tietoa, mutta niillä ei voi muuttaa tietoa. Lisäksi suoraviivaisimmissa ei varmasti ole edes henkilötietoja, jolloin niihin ei liity samoja riskejä.

Suoraviivaisen datarajapinnan tekeminen, jossa ei ole henkilötietoja, on helppoa. Neuvomme on, että kehitystiimille voi antaa varsin itsenäisen vastuun toteutuksesta, kunhan se tehdään laillisesti ja eikä se vaikuta organisaation toimintaan tai muuta tietoa missään.

Kiinnostavimpia sekä oppimisen että vaikuttavuuden kannalta ovat toiminnalliset rajapinnat, joihin ei kuitenkaan vielä liity henkilötietoja. Näihin kannattaa laittaa paukkuja, sillä ne ovat kohtuullisen haastavia, joten niiden rakentaminen antaa oppia oikeassa kontekstissa. Kun keskittyy luottamuksellisuuteen ja eheyteen, ja hoitaa ne mahdollisimman hyvin, voi edetä pikkuhiljaa myös henkilötietojen käsittelyä sisältäviin rajapintoihin.

 

Kun toimeen sitten ryhtyy, mitä pitäisi ottaa huomioon?

Kannattaa aloittaa siis avaamalla se kaikkein helpoin juttu, datarajapinnat. Tiimi voi tehdä sen itsenäisesti, ja siihen ei tarvitse laittaa aivan hirveästi paukkuja. Kannattaa kuitenkin varmistaa, ettei kukaan ole avaamassa rajapintoja yksin.

On hirveän vaikea tehdä turvallista työtä tehokkaasti. Projektissa on oltava mukana ainakin kaksi ihmistä, joista toisen tehtävä on tehdä ja toteuttaa, ja toisen työnä on tarkastaa, että laatu säilyy korkeana ja asiat tapahtuvat tietoturvallisesti ja säännösten mukaisesti. Asetelma on kuin keskushyökkääjällä ja maalivahdilla.

Datarajapintoja avatessa kannattaa varmistaa, että aikaa on vähän enemmän kuin jos sama data olisi tuotu organisaation verkkosivulle. Kun rajapintoja ollaan avaamassa ensimmäistä kertaa, opetellaan uutta. Kun rutiinit ovat ajan myötä kasassa, rajapintojen avaamisen pitäisi olla helpompaa kuin verkkosivujen avaaminen, sillä API-rajapintoihin ei liity esimerkiksi visuaalisen käyttöliittymän suunnittelua.

 

Ennen kuin etenet, suunnittele

API-rajapinnoissa hyvin suunniteltu on puoliksi tehty. Tekemisellä aloittaminen on hyvää hakkerieetosta, mutta mallilla tulee helposti avanneeksi enemmän kuin oli tarkoitus tai vääriä asioita. Sähläämällä taas voi käydä niin, että avaa dataa, joka ei kiinnosta ketään tai joka on muodossa, jossa kukaan ei voi sitä hyödyntää.

Dataan pitää myös tutustua. On täysin normaalia, että tiedossa, jossa ei pitänyt olla henkilötietoja, onkin seliteteksteihin laitettu sosiaaliturvatunnuksia, vaikka ohjeistus toisin sanoo. Varmista siis mitä rajapinnan kautta kulkeva data oikeasti sisältää.

Tietosuojalainsäädäntö on syytä tuntea huolella, varsinkin siinä vaiheessa kun rajapintaan liittyy henkilötietoja. Lakia tulee tuntea paitsi sen takia, ettei tule rikkoneeksi sitä, mutta myös siksi, että on ihan yhtä tärkeää osata perustella muille, miksi ei riko säännöksiä. Rajapintojen avaaminen voi herättää pelkoa esimerkiksi tietosuojarikkeistä, jolloin on hyvä tietää, mitä on tekemässä ja olla selkeät sävelet, jottei tärkeä työ mene hukkaan väärien pelkojen vuoksi.

 

Tunne lisenssit ja teetä uhka-analyysi

Pelkkä datan tunteminenkaan ei riitä, pitää olla myös selkeä ymmärrys siitä, mistä dataa luetaan, ja mistä siihen kirjaudutaan. Tieto pitää tuntea yhtä hyvin fyysisellä tasolla, tietojärjestelmätasolla sekä loogisella tasolla. Jos esimerkiksi osoite on väärin, on oltava kyky ymmärtää, mistä väärinkirjaus johtuu, ja kenen vastuulla on korjata se. Huonolaatuisen datan jakaminen ei kannata.

Uhka-analyysin teettäminen on myös kannattavaa kun suunnittelee rajapinnan avaamista. Se tarkoittaa sitä, että joku tietoa ja järjestelmiä ymmärtävä listaa kaikki mahdolliset kohdat, mikä rajapinnan avaamisen johdosta voi mennä pieleen. Voiko rajapintaa käyttää esimerkiksi luottamuksellisen tiedon joutumiseen vääriin käsiin?

Lisenssit kannattaa myös tuntea. Sellaiset sopimukset eivät ole harvinaisia, joissa rajapintojen käyttö on järjettömän kallista. Olisi piinallista herätä Oraclen myyntimiehen soittoon, jonka mukaan lisenssikustannukset ovat nousseet 15 000 kertaisiksi.

Katso webinaari: API-liiketoimintamallit

Sarvikuonojohtaja saa transformaatiossa köniinsä

Johtamista mitataan vaikeissa tilanteissa – muun muassa niissä, jossa organisaation tiukat luvut tuntuvat vaativan arvojen, roolin tai luonteenvastaisia toimia.

Mitä siis tehdä siinä tilanteessa, jossa itselle on otettu, tai alaiselle on annettu tehtävä, joka on vahvasti ristiriitainen, ja jossa onnistumisessa kovat tavoitteet taistelevat tekijän pehmeiden tavoitteiden kanssa?

Tällaisissa tilanteissa moni johtaja toimii vaistojen varassa ja toiminta usein noudattaa kiusallisen ennustettavia malleja ristiriidan yksityiskohdista riippumatta.

Johtaja voi olla:

Sarvikuonojohtaja vähät välittää organisaatioon muodostuvista vaikeista työyhdistelmistä, jossa onnistuminen edellyttää toisen näkökulman kokonaan jättämistä huomiotta, koska kompromisseille ei ole jäänyt tilaa. Kutsun tätä sarvikuonojohtamiseksi. Tyypillinen sarvikuonojohtajan sanonta on “ei kiinnosta, tärkeintä on, että pidät kiinni niistä tunnuslukulupauksista, jotka sovimme viime kehityskeskustelussa.”

Empaattinen johtaja tukee vaikeissa tilanteissa alaisen jaksamista, mutta sarvikuonojohtajan tavoin pitää tiukasti kiinni niistä lupauksista, jotka alaiselta on saatu puristettua. “Kyllä sä tämän jaksat. Ymmärrän, että voi olla vaikeaa, mutta kohta tää pahin vaihe on ohi.”

Kompromissijohtaja ämpyilee ja etsii vaikean tilanteen kohdalla kompromisseja, jotka vesittävät tavoitteen ja tuovat kaikille periksiannon fiiliksen. Mitään ei ole pakko tehdä kunnolla, kun aina voi pyytää luvan jättää puolitiehen.

Sumanpurkajajohtaja eli pehmeiden ja kovien arvojen välisiä ristiriitoja purkava johtaja voi parhaimmillaan yhdellä lauseella auttaa ymmärtämään ristiriidan näennäisyyden tai toisaalta tehdä rakenteellisiakin muutoksia, jotta ristiriita ei jää yhden kannettavaksi vaan se saatetaan jopa saada puretuksi.

 

Sumanpurkaja paketoi homman kasaan

Moni yritys ja tiimi käy läpi transformaatiota, harkitsee sellaista, tai pelkää moista, esimerkiksi vaikkapa ketteryyteen, asiakaslähtöisyyteen, leaniin tai itseohjautuvuuteen siirtymistä.

Transformaatiossa onnistuminen ja onnistumisen kustannukset riippuvat johtajan tavasta hallita pehmeiden ja kovien arvojen ristiriitaa. Transformaatiossa johtajan ja alaisen minäkuvan ja uuden roolin tai tiimidynamiikan hetkelliset ristiriidat voivat olla äärimmäisellä, avioeroon rinnastettavalla stressitasolla.

Transformaatiossa kompromissijohtaja epäonnistuu, sarvikuonojohtaja aiheuttaa irtisanomisten aallon ja empaattinen johtaja sairaslomien aallon. Vain sumanpurkajajohtaja voi saada homman pakettiin ilman merkittäviä taloudellisia vaurioita.

Erityisesti itseohjautuvat organisaatiot vaativat valtavan määrän ristiriitojen purkua onnistuakseen. Epäilen, että vain ristiriitoja purkamaan oppinut johtaja voi pitemmän päälle nauttia toiminnasta itseohjautuvassa organisaatiossa.

 

Mistä aloittaa?

Havainnoi omaa toimintaasi vaikeissa tilanteissa – vesitätkö muutoksen, painatko väkisin läpi tunteista välittäen tai välittämättä vai löydätkö usein viisastenkiven eli tavoitteista kiinni pitävän, mutta vaikeat emotionaaliset tai sosiaaliset tilanteet ennakkoon tai lennossa poistavan johtajan?

Muista, että pitemmän päälle et voi saada hyviä tuloksia, jos tiimissä on ahdistusta, pelkoa tai häpeää. Johtajan on mentävä kohti vaikeita tunteita ja auttaa niiden purkaminen systeemiä tai ajattelutapaa muuttamalla.

 
New call-to-action

Ketteryyden sanansaattajaksi – ensimmäiset kuukaudet menetelmäkonsulttina Codentolla

Pari kuukautta menetelmäkonsulttina Codenton riveissä on tuonut onnistumisia ja uusia näkökulmia ketterään tekemiseen. Tässä työssä oppii kollegoilta ja asiakkailtakin jatkuvasti uutta.

Aloitin urani devaajana, ja ajattelin aluksi että ohjelmistopuolen tekninen ongelmakenttä on se minun juttuni. Teinkin koodaushommia useamman vuoden, mutta sitten into vähän hiipui. Samalla huomasin että projektieni tärkeimmät haasteet löytyivät usein muualta kuin teknologian parista. Työnohjausta, kehitystiimin toimintaa ja työtapoja miettiessäni innostuin ketteristä menetelmistä ja etenkin scrumista.

Myöhemmin kiinnostus laajeni menetelmäkehitykseen ja esimerkiksi leaniin. Huomasin ehkä vähän yllätyksekseni, että työpaikan työtapojen ja kulttuurin parantaminen on itse asiassa todella kivaa hommaa.

 

Rekryprosessista hyötyä osaamiseen

Codentolle päädyin kesän kynnyksellä edellisellä työnantajallani alkaneen YT-prosessin seurauksena. En halunnut aloittaa kesälomaani ilman tietoa syksyn kuvioista, joten listasin top 4 yritystä, joihin haluaisin töihin. Codento tuli mukaan listaan, jopa hieman ehkä viime hetken huomiona.

Yritys oli tullut tutkalleni viime vuoden ScanAgile-tapahtumassa, jossa Karoliina Luoto ja Anu Takala olivat puhumassa S3-mallista. En ollut itse kuuntelemassa, mutta aiheesta keskusteltiin tapahtumassa ja kuulemastani tuli sellainen olo, että vau, noinhan näitä asioita pitäisi hoitaa.

Codentosta muistiin piirtyi mielikuva ketterästä ja kokeilevasta organisaatiosta. Soitin kaverille, joka työskenteli yrityksessä, ja utelin hieman, minkälaista työskentely Codentolla on. Kaveri kannusti hakemaan ja kertoi hyviä asioita yrityksen kulttuurista. Niinpä sitten hakemus lähti muiden ohessa myös Codentolle, joka vastasi hyvin nopeasti ja reippaasti.

Työnhakuprosessi oli hyvällä tapaa tiukka, ja siitä jäi huolellinen kuva. Rekrylounaalla käytiin läpi, minkälainen tyyppi olen, mitä haen, ja mitä kaikkea Codentolla kaivataan. Teknisessä työhaastattelussa taas luotiin simuloitu tilanne, jossa piti todella näyttää mihin pystyy. Haastattelun kolmas kierros oli lyhyen työpajan vetäminen codentolaisille. Rekryprosessi oli ehdottomasti intensiivisin työhaastattelurumba, jonka olen läpikäynyt, mutta luulen että siitä olisi ollut minulle hyötyä vaikkei minua olisi edes palkattu.

 

Kouluttamaan ja konsultoimaan

Aiemmin olen aina työskennellyt oman organisaation sisältä käsin, joten Codentolle menetelmäkonsultiksi pestautuminen on selkeästi uusi askel uralla. Tärkeältä tuntui mahdollisuus päästä asiakkaiden pariin ja näkemään erilaisia organisaatioita, ja sitä myöten kehittyä itsekin. Lisäksi mahdollisuus olla roolissa, jossa opiskellaan jatkuvasti uusia asioita, tuntui hyvältä valinnalta juuri nyt.

Nyt olen ollut parisen kuukautta työn parissa, ja se on ollut juuri sitä, mitä toivoin ja mitä minulle luvattiinkin. Tehtävissä on mukava tasapaino omien vahvuuksien hyödyntämisen ja uusien asioiden opettelun välillä. Vauhtiin pääsyä on tukenut hyvin periaate laittaa aina vähintään kaksi codentolaista jokaiseen projektiin.

 

S3 kiinnostaa menetelmäkonsulttia

Menetelmäihmisenä Codenton päätöksentekomalli kiinnosti minua, vaikka mitään vahvoja ennakkokäsityksiä minulla ei S3-mallista ollut. Yleisesti ottaen yhteisöllisellä päätöksenteolla on päätöksiä pahasti puurouttava ja jumiuttava maine, ja kuvitelmissa valtavat komiteat valmistelevat päätöksiä, jotka eivät koskaan tapahdu.

Halusin nähdä, miten Codentolla nämä asiat on ratkottu, ja mielestäni se on tehty sangen elegantisti. Jos on draivi tehdä jotain, ja jos se ei vaikuta muiden työhön, sen voi vain tehdä. Mutta toisaalta se, että isot asiat päätetään tietyn kaavan mukaan yhdessä, tuo luottamusta ja toimii hyvänä turvamekanismina sooloilua vastaan.

Codento on kasvussa ja onkin mielenkiintoista nähdä, miten S3 toimii kun yrityksessä työskentelee sata tai vaikkapa pari sataa henkilöä. Näen, että jos Sosiokratian saa toimimaan ja skaalautumaan, siinä on tosi iso voima. S3-mallista on menestystarinoita isojenkin firmojen kohdalla ja uskon että Codento liittyy jatkossa tuohon joukkoon.

 

Codentolla ketteryys on työkalu

Codenton työyhteisöstä olen pitänyt todella paljon. Minulle on tärkeää että työyhteisössä homma toimii, arvostan sitä paljon. Näin aluksi tutuimmaksi minulle on tullut kuuden hengen menetelmäporukkamme. On tosi hienoa olla töissä kovien asiantuntijoiden kanssa. Pelkkä työskentely heidän kanssa riittää omien taitojen kartuttamiseen, saati sitten jos opetellaan jotain ihan uutta. Olen aina halunnut työskennellä paikoissa, joissa on todella taitavia ihmisiä, koska heiltä oppii ja saa näkemystä ihan jo vaikka kahviautomaatilla keskustellessa.

Codenton suhtautuminen menetelmävalmennukseen on myös laajentanut näkemystäni työkentästäni. Ketterät menetelmät ovat tärkeä osa tekemistämme, mutta kuitenkin vain yksi työkalu. Jos asiakkaan tarpeisiin vastaa paremmin valmennus leanin, itseohjautuvuuden tai vaikkapa laajemman kulttuurimuutoksen saralla, niin silloin sovellamme niitä.

Nyt olen ollut mukana projektissa, jossa ketteröitetään useamman saman organisaation tiimin työtapoja. Olemme vetäneet workshoppeja ja valmentaneet kehitystiimejä. Päivät ovat toisinaan olleet pitkiä, mutta onnistumiset projekteissa ovat tuoneet todella hyvän fiiliksen.

Välillä on toki haastavaa mennä ulkopuolisena kertomaan miten kymmeniä vuosi käytössä olleet työtavat eivät ehkä olekaan enää hyviä. Toisaalta juuri ne hetket jolloin voi tällaisen lähtökohdan jälkeen kuukauden parin jälkeen todeta että muutosta on tapahtunut ja valmennettavat pitävät tehtyjä muutoksia hyvinä, ovat niitä kaikkein palkitsevimpia.

 

Töihin Codentolle? Katso avoimet paikat.

Kannustaminen tärkeää naisten saamiseksi teknologia-aloille – alanvaihto ei ole mahdotonta uran myöhäisemmässäkään vaiheessa

Codenton Cettu-laumaan mahtuu monta naisosaajaa.


Codentolainen Miili Halkka on alanvaihtaja, ja pitää Mimmit koodaa -hankkeen tyyppisiä avauksia tärkeinä, jotta lisää naisia saataisiin alalle. “En ole koskaan kokenut, että kukaan olisi alalla kiinnittänyt mitään erityistä huomiota siihen, että olen nainen”, hän kirjoittaa.

(lisää…)

Millä perusteella teknologia tulisi valita?

Gartnerin malleissa ja menetelmäkäsikirjoissa kaikki menee ihanasti, kun taas käytännön elämässä kehitystiimit ja IT-yksiköt joutuvat tekemään teknologiavalintoja usein puutteellisilla tiedoilla. Erityyppiset hankinnat tulevat eteen niin harvoin, että edellisen kierroksen jälkeen markkina ja sen pelurit ovat ehtineet muuttua täysin. Ostaja on helposti toimittajien mainospuheiden varassa. Vai onko? Ei välttämättä, kun pitää muutaman perusasian valintoja tehdessään mielessä.

 

1 Panosta liiketoimintakriittisyyden mukaan

Ihan ensin hankintaa miettiessä on syytä tunnistaa, minkä verran järjestelmään on perusteltua panostaa. Jos kyseessä on aivan liiketoiminnan keskiössä oleva järjestelmä, jolla etsitään kilpailuetua ja kirkkaampaa tulevaisuutta, sen kehittämiseen voidaan panostaa aivan eri tavalla kuin jos kysymys on toiminnan rutiineista.

Jos tarve kuuluu jälkimmäiseen kategoriaan, hankintaa suunniteltaessa kannattaa saman tien kääntää päälle vaihde, jolla ratkaisut tarpeisiin mietitään vaikka millä ilveellä olemassa olevien valmisratkaisujen ympärille ja kustomointia tehdään minimaalinen määrä.

Seuraavat alaluvut koskevat erityisesti ensimmäisen kategorian teknologioiden valitsemista, niihin kun on todella aihetta keskittyä.

 

2 Varmista käyttäjätarve

Seuraavaksi on ymmärrettävä käyttäjän tarve. Mikä on käyttäjän perusongelma, joka teknologian on syytä ratkaista? Millainen palvelu sen voisi ratkaista, ja miten pystymme varmistamaan että potentiaalisen toimittajan tai meidän itse kehittämämme teknologia oikeasti tekee näin?

Jos mahdollista, ennen investointia on hyvä käyttää viikko-pari sen varmistamiseen, että käyttäjätarve on oikeasti kuultu käyttäjiltä itseltään eikä mielikuviteltu kulmahuoneessa. Ja samalla on hyvä yksinkertaisimmalla mahdollisella prototyypillä myös varmistaa, että löyhästi kaavailemamme ratkaisu oikeasti täyttää tuon käyttäjätarpeen – ennen kuin olemme upottaneet siihen merkittäviä määriä aikaa ja rahaa.

 

3 Analysoi liiketoiminnan tarve

Lähdettäessä toimittamaan käyttäjille sitä mille löytyi toivottavasti huutava tarve, on seuraavaksi selvitettävä liiketoiminnan teknologialle asettamat reunaehdot. Miten asiakkaan toivoma asia aiotaan toimittaa? Onko valintoja, joita on syytä tehdä vaikkapa hinnoittelun tai järjestelmän toimintasyklien suhteen?

 

4 Tutki uudet fiksut työtavat

Käyttäjän ja liiketoiminnan tarpeen lisäksi teknologiaan useimmiten liittyy organisaation työn arkea: teknologialla tehtävää asiakaspalvelutyötä, ylläpitoa tai taustaprosessia. Teknologiaa valitessasi haluat luultavasti varmistaa, että organisaatiosi on hahmottanut työtavan jolla sitä tullaan käyttämään.

Yleensä tässä kohtaa ei haluta menettää sitä mahdollisuutta, että uuden teknologiavalinnan siivin voidaan uudistaa myös työtapa. Kun käytetään hetken aikaa työtavan analysointiin, huomataan, mikä osa tekemisestä oikeastaan tuottaa arvoa asiakkaalle. Arvovirtakartta on tähän hyvä väline. Analyysin jälkeen teknologiavalinnalla voidaan linjata, että työssä saadaan oikeasti keskityttyä asiakkaan saamaan arvoon ja pakolliset rutiinit pystytään hoitamaan mahdollisimman tehokkaasti.

 

5 Kartoita tietojärjestelmäympäristö

Harvoin teknologiaa päästään valitsemaan puhtaalle pöydälle. Yleensä ympärillä on elinkaaren eri vaiheissa olevia tietojärjestelmiä joihin uuden teknologian pitää liittyä, ja palapeli rajoittaa valintoja. Näiden mallintamisen tapaa tärkeämpää on, että ne ja niiden integrointitarpeet tunnistetaan ennen teknologian valintaa. Esimerkiksi: millaisia rajapintatarpeita teknologian pitäisi täyttää?

 

6 Huomaa muut rajoitukset

Edellä mainittujen lisäksi on olemassa yleensä vielä muitakin ulottuvuuksia, jotka rajoittavat teknologiavalintaa. Joskus teknologian käyttöönotolla on aikataulu, joka rajoittaa ratkaisuvaihtoehtoja – kehitykseen panostamiseen ei yksinkertaisesti ole aikaa, vaan pitää rakentaa olemassa olevien ratkaisujen päälle. Joskus toimintaan liittyy lainsäädäntöä, joka asettaa teknologialle rajoituksia, esimerkiksi tietojen sijainnin tai muiden tietoturvatekijöiden muodossa.

 

7 Mieti elinkaaritarpeet

Useimmiten tässä pohdinnan tässä kohtaa vaatimusten yhdistelmä ajaa jo kohti melko harvalukuista joukkoa teknologia- ja toteutustapavaihtoehtoja. Yksi pohdinta on kuitenkin vielä jäljellä: teknologian elinkaari. Useimmiten halutaan välttää joutumista tuoreen teknologian ensimmäisten kokeilijoiden joukkoon.

Kun teknologia on ollut jo jonkin aikaa olemassa, tarjolla on ilmaista etua muiden tekemistä virheistä ja kehittämistä perusasioista eli hienosti sanoen ekosysteemin kypsymisestä. Toisaalta jos kysymys on kriittisestä teknologiasta ja haetaan kilpailuetua, joskus kannattaa myös maksaa oppirahat ja olla eturintamassa.

Joka tapauksessa on hankittava markkinaymmärrystä ja joskus myös meediopalveluita hahmottaakseen myös elinkaaren loppupää: Miten pitkälle tulevaisuuteen teknologialle voi olettaa jatkuvuutta vs. käyttötarpeen mitta? Miltä ekosysteemin kehitys näyttää, vaikuttaako siltä että teknologialle on tarvittaessa löydettävissä ylläpitäjiä myös tulevaisuudessa? Olemmeko investoimassa kisojen voittajahevoseen vai näyttäkö uhkaavasti siltä että kyseessä on häviäjätallin kaakki?

 

Työkaluja:

Tarpeen pikadokumentointiin voit käyttää ohjelmiston visiolakanaa, ks. https://www2.codento.fi/lataa-lean-visiolakana-ohjelmistoprojektiisi/

Lisää prosessien analysoinnista ks. https://www2.codento.fi/2017/08/hyvaa-halvalla-nopeasti/

 

Lataa opas: Uuden verkkopalvelun teknologiavalinnat