Avointa lähdekoodia ja rajapintoja - avoimilla menetelmillä?

Kun puhumme ohjelmointirajapinnoista (API), keskustelu pyörii yleensä lähdekoodin, teknologioiden ja alustojen ympärillä. Mutta jokaisen menestyvän APIn taustalla on jotain vähemmän näkyvää: APIen suunnittelu- ja hallintamenetelmä. Eräs laajimmille levinneimmistä näistä on APIOps Cycles, suunnittelu- ja hallintamenetelmä, joka tuo jatkuvan parantamisen periaatteet (DevOps) API-hallinnan maailmaan.

Menetelmä on kehitetty alunperin Suomessa englanniksi, ja se on lokalisoitu tänä kesänä suomeksi, saksaksi, brasilian portugaliksi ja ranskaksi. Koko menetelmä ja siihen liittyvät keskeiset työkalut on tarjolla nyt avoimella lähdekoodilla. APIOps Cycles on rekisteröity tavaramerkki ja canvasten designit ja menetelmän sisältö on lisenssoitu CC-BY-SA 4.0.

Mutta todellinen kysymys on: pitäisikö menetelmien kuten APIOps Cycles pysyä suljettuina, yrityskohtaisina vai olla avoimesti lisenssoituja?

Itselleni vastaus on selvä – menetelmien avoin lisensointi ei ole vain parempi vaihtoehto, se on välttämättömyys. Syyt ovat pitkälti samoja tai samankaltaisia kuin avoimen lähdekoodin ohjelmistoilla:

1. Menetelmät vahvistuvat käytön kautta

Menetelmä on arvokas vain siinä määrin kuin tiimit sitä harjoittavat. Suljetut menetelmät jäävät helposti siiloihin ja hyödyttävät vain pientä joukkoa käyttäjiä. Avoimen lähdekoodin menetelmät puolestaan skaalautuvat orgaanisesti: käytännön tekijät jakavat malleja, soveltavat niitä uusille alueille ja palauttavat parannuksia takaisin yhteisöön.

Scrum- ja Agile-viitekehysten menestys ei koskaan johtunut siitä, että joku “omisti” ne – vaan siitä, että ne olivat avoimesti jaettuja ja kehitettyjä. Sama logiikka pätee APIOps Cyclesiin.

2. APIt perustuvat yhteentoimivuuteen

APIt on luotu luomaan yhteisiä standardeja järjestelmien, tiimien ja organisaatioiden välille. Olisi ironista – ja haitallista – jos menetelmä, jolla APIt suunnitellaan ja hallitaan, olisi suljettu.

Kun APIOps Cycles pidetään avoimena, varmistetaan, että tiimit eri toimialoilta voivat puhua samaa kieltä. Näin liiketoimintaprosessien tasolla saavutettu yhteentoimivuus peilaa sitä yhteentoimivuutta, jota odotamme API-protokollien tasolla.

3. Innovaatio tarvitsee kollektiivista älykkyyttä

API-kenttä kehittyy nopeasti – uudet standardit (GraphQL, AsyncAPI), uudet vaatimukset (PSD2, GDPR), uudet turvallisuusmallit. Suljettu menetelmä vaarantaa pysähtymisen, koska sen kehitys riippuu vain yhden organisaation kyvystä mukautua.

Avoimen lähdekoodin menetelmät hyötyvät kollektiivisesta älykkyydestä: fintechin, terveydenhuollon, telealan tai julkisen sektorin toimijat tuovat omat rajoitteensa ja parannuksensa takaisin kehitykseen. Näin APIOps Cyclesista tulee elävä menetelmä, ei jäätynyt ohjekirja.

4. Kynnysten madaltaminen hyödyttää koko ekosysteemiä

Kaikilla organisaatioilla ei ole budjettia konsulttien palkkaamiseen tai suljettuihin viitekehyksiin sitoutumiseen. Jos APIOps Cyclesin ainoa käyttöönottotapa olisi liittyä suljettuun ekosysteemiin, pienemmät tiimit ja startupit jäisivät ulkopuolelle.

Avoimeksi tekeminen demokratisoi pääsyn:

- Startupit voivat ottaa sen käyttöön ilman esteitä.
- Suuryritykset voivat pilotoida sitä ennen käytön “virallistamista”.
- Yliopistot voivat opettaa sitä ja valmistaa seuraavan sukupolven API-tuotepäälliköitä.
- Tämä inklusiivisuus kasvattaa osaajapohjaa ja vahvistaa koko API-taloutta.

5. Avoimuus on luottamuksen signaali

Lopulta avoimuus on myös uskottavuusliike. Yritykset ja hallinnot ottavat paljon mieluummin käyttöön menetelmän, jota he voivat nähdä, haaroittaa ja johon he voivat luottaa – ettei se ole musta laatikko. Koska API-hallinta koskee sääntelyä, turvallisuutta ja vaatimustenmukaisuutta, läpinäkyvyys ei ole ylellisyyttä – se on välttämättömyys.

API-talous kukoistaa avoimuudella. Standardit kuten OpenAPI ja AsyncAPI ovat jo kerran todistaneet sen. Menetelmien kuten APIOps Cycles tulisi kulkea samaa polkua.