Rajapintojen harmonisointi ja standardointi

Eilen muodostin ajatuksen (en varmaankaan ensimmäisenä maailmassa):

Standardization is about conformity, Harmonization is about consistency. Both are needed in #API Economy

Nyt pitäisi hieman ehkä avata mitä tuo ajatus sisältää vaikka se ehkä tuntuukin itsestäänselvyydeltä. Standardit on hyvä asia, ainakin niin kauan kuin niiden soveltaminen on kohtuuden rajoissa. Suljetut standardit kuuluvat menneisyyteen ainakin niiltä osin kun rahastetaan PDF nipulla uudestaan ja uudestaan. Standardin tuottamisen kulut voi kattaa muutenkin ja businessta voi tehdä monella tavalla (vertaa open source). No, kuten sanottu standardit ovat hyviä, koska niillä luodaan perustaa ja yhtenäisyyttä.

Standardi = MVP

Oman näkemykseni mukaan standardit määrittävät Minimum Viable Product tyyppisesti riman alimman tason. Home automation on yksi sellainen teemo, jonka voi odottaa ”pääsevän” standardoinnin piiriin. On myös odotettavissa että syntyy kilpailevia REST rajapintojen standardeja ja evoluution suurimmassa osassa tapauksia karsii standardeja. Osa standardeista voi elää ja voida hyvin vaikka soveltajajoukko ei olisi laaja. Näin voi tapahtua esim globaalien jättien ajaessa omaa standardiaan joka tuotteeseen. Lisäksi oma veikkaukseni on että

de facto standardit valtaavat markkinoita enemmän ja formaalin jopa vuosien hyväksymisprosessin vaativien de jure standardien merkitys vähenee.

On lisäksi olettavaa, että pelkän määrittelyn tekemisellä ei saada mitään standardia laajasti leviämään, vaan vaaditaan yhtäaikaista referenssitoteutusta standardista. APIen kuvauskielet ovat tästä hyvä esimerkki. RAML, Swagger tai API Blueprint eivät ole de jure standardeja, silti ne ovat eniten sovelletut rajapintojen kuvauskielet. Swagger oli yhden yrityksen tuotteiden kautta ajama tapa kuvata rajapintoja, kunnes siitä tehtiin Open API Definition Format (OADF) ja standardi siirrettiin Open API Initiativen alle, edelleen avoimena ilman maksuja käyttöönotettavana. Toisin sanoen hyvästä käytännöstä jota koeteltiin markkinoilla vuosia tehtii standardi eikä toisinpäin.

Kilpailuedun tekeminen tapahtuu standardien seuraamisen sijasta toteuttamalla teknisesti tai palveluna lisäarvoa jota muut eivät tehneet.

Siinä kohdin ei sitten enää standardi auta. Lisäarvo voi olla tehokkaammat toteutukset tai yhdistelmämetodit, joilla vähennetään kehittäjän vaivaa. Lisäksi pienet kokonaisuudet tai alueet joilla businesta tehdään vähän (silti merkittävästi) tuskin koskaan pääsevät standardisoinnin piiriin. Tarvitaan siis keinoja harmonisointiin eli yhtenäisyyteen ei yhdenmukaisuuteen (standardointi).

Harmonisointi APIOps toimintatavalla

APIOps konsepti valmiine välineineen mahdollistaa API perheiden harmonisoinnin. Yksi käyttöesimerkki julkiselta sektorilta on isohko virasto jolla on useita rajapintoja. Käytännön esimerkki vaikkapa Opetushallitus. Heille olisi eduksi että API:t ovat johdonmukaisia ja yhtenäisiä. Yhtenäiset rajapinnat madaltavat kehittäjien oppimiskynnystä ja siten nopeuttavat sovellus ja palvelukehitystä.

APIOps lähtee Design-First periaatteesta, jossa rajapintojen hyödyntäjät eli kehittäjät otetaan mukaan API:n kehittämiseen alusta alkaen, ei vasta kun API alkaa olemaan loppusilausta vaille valmis.

Jokaisella rajapinnalla on oma koneluettava kuvauksensa, josta voidaan automaattisesti tuottaa testattava rajapinta ja dokumentaatiot ilman manuaalista koodaamista. Vertailemalla rajapintojen kuvauksia, löydetään helposti epäyhtenäiset toiminnot ja voidaan harmonisoida kehittäjäkokemus (DX) jo alusta alkaen. Vastaavasti kun tehdään API perheeseen uutta rajapintaa, voidaan hyödyntää aiempia kuvauksia.

APIOps on 2015 kehitetty malli API kokonaisuuksia tehokkaaseen kehittämiseen ja ylläpitämiseen. Niin ja se on Suomesta. Olen menossa esittelemään mallia API Strategia konferenssiin Texasiin 17.11.2015. Suomen APIOps yhteisö on aloittanut rakentamaan omaa verkkopresensiään osoitteeseen: apiops.net.

APIOps is about harmonizing and building consistent API families

I was giving a APIOps concept presentation at DevOps Finland meetup in Pasila. Eficode was hosting the event and the space was crowded with devops specialists. Without saying, it was clear that the audience was the best possible for pitching. Participants were experts and not holding back on feedback; it was hard and to the point!

One topic that raised discussion was how to include continuous integration to the APIOps process, which is Design driven. My answer was that I haven’t yet had time to think that over. For time being I have limited the feature scope to MVP just to get something done and clear. And yet, the concept is not clear but requires more pitching and modifications.

Another more interesting topic that came up in discussions with a few participants after the presentation was the scope of applying APIOps. I have been too focused on thinking APIOps through development of one API. The value comes when scope is bigger. DevOps principles and practices fit in the scope of one API.

Harmonizing API families between various partners.

One of the participants in this small group chatting was Toni Willberg from RedHat. It came as a lightning to me that APIOps is about building and harmonizing consistent API families or ecosystems.

APIOps is not about speed. APIOps is not about automation itself. That is what DevOps is about.

APIOps: With the help of using API descriptions and sandboxes generated from there, result functions as communication platform, which can be utilized to create harmonized multi-partner API ecosystems.

Harmonization cuts costs in integration and development, enables lower learning curve for the API consumers, creates stability and increases security, and enables automatization in large scale IoT systems.

API orchestration with Design-First approach

APIOps process starts with API design in collaboration with API consumers and other key partners. Using API description standards like RAML, Swagger and API Blueprint enables automatic generation of API sandbox and mockup server from API description at any point of the design process. In other words, it enables iteration and API (human) testing without manual coding. This process is done with each API. Then we will have group of APIs which can be tested to work together.

In other words we are talking about API orchestration, enabling seamless API networks.

JulkICT liittyi virallisesti API-talouteen

Eilisen hyvä uutinen oli että Suomen julkinen sektori (JulkICT) siirtyi API-talouden rintamaan yksityisen sektorin rinnalle. Tämä tapahtui MindTrek tapahtumassa Tampereella, kun Valtiovarainministeriön Kimmo Mäkinen toi esille linjauksen (toivottavasti menee oikein) API-first toimintamallin vaatimuksesta osana digitaalisten palveluiden kehitystä.

Strategian luominen

Aiemmin on erilaisissa projekteissa koskettu API-taloutta ja sen elementtejä, kuten mietitty API guide lines tuomista osaksi kansallista palvelukehitystä, mutta puuttuu API:en osalta strategia. Mäkisen Kimmon esittämät periaatteet ovat alku ja sisältyisi API-strategiaan, mutta tarvitaan syvyyttä ja konkretiaa. Strategialla tarkoitan muun muassa sitä että API:en hallintamalli on viimeistelty ja otettu käyttöön. Hallintamalli on työn alla VM:ssä. Lisäksi voisi olla paikallaan ajaa API:en kehittämiseen nykyaikainen kehitystä kiihdyttävä Design-First ajattelu, jossa prosessien automatisoinnin kautta minimoidaan hidastavia tekijöitä kuten manuaalinen koodaus ja osallistetaan API:en kuluttajat alusta asti rajapinnan kehittämiseen. Lisäksi on laitettava paukkuja kehittäjäystävällisten API-hallintaratkaisujen käyttöönottoon. Onneksi osa toimista on jo käynnissä mukaan lukien liityntäkatalogin PoC, joka tulee listamaan palveluväylän rajapinnat. Myös sopiminen lisensseistä, joilla rajapintoja tehdään tulisi sopia kansallisella tasolla. Lisäksi API:en kautta välitettävään sisältöön tulisi semanttisella tasolla sekä tietomallien osalta ottaa kantaa.

API-strategiaryhmä

Saattaisi olla paikallaan perustaa Suomeen ketterä API-strategiaryhmä osana JulkICT:tä. Ryhmä määrittäisi linjat (ml yllämainitut asiat), teettäisi sisällöt asiantuntijoilla ja miettisi jalkautuksen. Ryhmässä tulisi olla 5-8 jäsentä ja sisältää edustus yksityiseltä ja julkiselta sektorilta (sis kuntasektori).

API Jamming – concrete contribution every time

APIOps community has started with having traditional meetups, where people tell war stories around APIs. Well, not much even that since we are a newly established community which has had only two meetups so far. Anyway, we already got bored. API people are fast moving species. We want action!

Therefore we decided today, that instead of having stage shows, we want to have team shows and Jams.

Idea is to use open source APInf API -management platform as playground for ideas and visions. Why APInf?

• It’s based on open source API Umbrella, which has a few paid developers in the States.
• APInf is API Umbrella UX with steroids. In other words, UX is rewritten on top of Meteor and it’s open source (available in Github). And guess what? The UX is also developer by paid development team.

Wait! This gets even better. The two teams work together! We can’t have a better situation for community to partner with. Furthermore, API -management is one key element in APIOps design driven concept and therefore it makes sense to work around that. Of course we can do other things as well.

API Jam every month

Anyway, the idea is to organize Mini API Jams every month. Instead of talking, we implement, design, create concepts and do stuff! Intention is to create a roadmap for 6 months and in every Jam select a feature which community wants to see in the APInf platform and hack around it.

We can select items to hack from the product backlog or have our own ideas. APInf team can make the backlog public and we as community can vote for the top features. Of course there are features which we as more or less volunteers want to leave alone and in the hands of paid developers.

Jam was selected over hackathon because it does not make connotation to hard core coding. Instead it’s more relaxed sounding word.

From new features to low hanging fruits

The options are limited for Jams and people participating. If the feature is totally new, it might make sense to focus on defining the feature with user stories, do some concepts or draw mockups. In some cases the feature might be so called low hanging fruit, something relatively easy to hack with. It’s obvious that Jamming is not just about coding, but we need people with different skill sets. That opens up opportunities for all to participate and have fun.

Concrete contribution every time

Since all components are open source and available all the time for everyone, we can start working when ever we want. In some cases we will not be able to finish work during the Jam. That’s fine. We  commit what we have. Aim is to have something concrete to push upstream every time.

We will start API Jamming in October. See more details from Meetup.com

APIOps & APItalisti for dummies videot

Tuli mieleen että pitäisi tuottaa 3 lyhyttä animaatiota tai videota tukemaan viestin välitystä. Kolme aihetta ovat:

• What is APIOps?
• What is APItalist?
• What makes APIops and APitalist winning combination?

Kestoltaan varmaan 1-2 minuuttia per video. Animaatio saattas toimia paremmin niin eri tarvitse metsästää esiintyjiä.

Videot palvelisivat isompaa joukkoa tarjoten perustiedot helposti omaksuttavassa muodossa johdatukseksi keskustelulle erilaisissa tilaisuuksissa.

Rahoitus joukkoistamalla

Tämänhän voisi rahoittaa joukkoistamalla. Suomesta löytyy firmoja jotka on tästä kiinnostuneita ja jos vaikka 3Scale tai API Evangelist lähtis mukaan muutamalla satasella.

Videot lopuksi juutubeen ja osallistuneiden yritysten logot näkyviin videolla. Mielessä on jo pari yritystä, joiden kautta tämän voisi teettää. Nyt vain joukkoistus vaikkapa Holvin avulla. Joko tehdään? Kuka lähtee mukaan?