Nyt alkaa rakennusalallakin näkyä sana "API" siellä sun täällä.
Huom! tämän blogin alaosassa on kaksi haastetta rakennusalalle (tiedän, että suurin osa ei jaksa lukea tätä loppuun asti...)
---
Open API ja REST API. Documented API. JSON.... jne. Näitä viljelevät ne kaverit, jotka eivät tajua mitä tuo tarkoittaa - kuten minäkin.
Olen yrittänyt opiskella APIen mahdollisuukisa tämän vuosikymmenen alusta lähtien, kun meidän firman softa-arkkitehti sellaiset minulle esitteli. Käsittääkseni / toivottavasti tämä on nyt meidän firman viimeisintä hottia:
https://designer-demo.granlunddesigner.fi/api/index
Ihan turha kysyä minulta mitä nuo tarkoittavat, mutta tiedän sen, että kun niitä lukee joku toisen firman devaaja ja hän haluaisi saada meiltä jonkun kiinteistön pumpun tiedot, niin me saadaan se hänelle toimitettua ilman yhtään ylimääräsitä työtä. Kunhan me luotetaan hänen softaan, kunhan meillä on kiinteistöomistajan oikeus jakaa se tieto.
Nyt päästään moneen herkulliseen asiaan kiinni. Saako tietoa jakaa ilman, että olemme sopineet tiedon antajan kanssa asiasta?
Mitä kun (ei jos) haemme tietoa monesta eri lähteestä ja muodostamme näistä tiedoista sellaista tietoa, jota ei ole olemassa? Onko tuo tieto meidän tietoa vai pitääkö meidän kysyä joltakin, että "Teidän tietoa on käytetty tämän tiedon tuottamiseen arviolta 12% verran. Saatte meiltä 1% alennuksen Saas -palvelustanne" ?
Esimerkki:
Haen lämpötiloja kiinteistöstä A1 olevilta toimistohuoneilta. Samalla haen ilmatieteenlaitokselta avoimen datan kautta ulkoilman lämpötiloja. Teen näiden kahden eri arvon kanssa trendikäyrän vuoden ajalta.
Sitten teen saman kiinteistölle A2 ja sen toimistohuoneille.
ja A3:selle. Ja neloselle jne.
Tiedän kaikien kohteiden pinta-alan avoimen kaupunkimallin kautta. Tiedän näiden kiinteistöjen nykyarvon. Tiedän näiden kiinteistöjen aurinkoenergiapotentiaalin avoimen datan kautta. Tiedän energiankulutuksen koska mittaamme sitä. Ja sen saan myös energialaitokselta. Tiedän sairaspoissaolot. Tiedän henkilöstön vaihtuvuuden.
Ym. tiedoista pystymme muodostamaan todella paljon uutta tietoja, joka palvelee kiinteistömassojen omistajaa. Mutta voisiko sitä tietoa jakaa myös muille? Edes anonyyminä, neliöpohjaisena tunnuslukutietona?
Jotta ym. skenaario on mahdollinen, niin tiedon pitää olla käytettävissä valituille softatoimittajille / yhteistyökumppaneille. Kukaan ei tee softaa, jos lopputuloksista pitää maksaa ensimmäisen tiedon tuottajalle. Vai maksaako?
Ensimmäisen tiedon tuottaja on triggeri, joka laukaisee koko analyysin eteenpäin. Tuosta triggeristä pitäisi olla hyötyä kaikille, jotka samaan kelkkaan lähtevät.
Ja sitten asian pihvi businessporukoille; miten tästä tehdään rahaa?
Vastaus: Lohkoketjuilla.
lämpötila / aikayksikkö = rahan arvoinen tieto.
Kun lähetän (siis joku kysyy sitä) APIn kautta lämpötilatiedon softa b:eelle, tienaan lohkoketjun kautta siitä 0,01 senttiä. Jos tämän minulta tulleen alkuperäisen lämpötilan lähettää softa b eteenpäin soft c:lle, niin saan siitä 0,01+0,01 senttiä. jne. jne.... jne^2.
Rahantuloa ei voi estää...
Blockchainin kautta originaalin tiedon tuottaja tienaa, transaktio on jäljitettävissä ja todistettavissa automaattisesti, ilman ihmisen työtä.
Kun softa b rikastaa omalla softalla minulta saatua tietoa, ja tämä rikastettu tieto on sellaista, jota itsekin tarvitsen niin me olemme lukittauduttu toisiimme. Saan siis ilmaiseksi tietoa, jota tarvitsen jonkun toiminnallisuuden toteuttamiseksi.
Tämä tarkoittaa sitä, että kannattaa tehdä itsensä niin tarpeelliseksi, että sinun tietoja hyödyntävä softa ei pysty toimimaan jollet pysty tarjoamaan tietoa heille.
Pitää olla kaikkien kilpailijoiden paras kaveri.
Tiedon jakaminen on uusi Musta.
Tiedon jakaminen laajentaa muut softat myyntiyksiköiksi.
Haaste 1
Haastan kiinteistöomistajat jakamaan omien kiinteistöjen tietoja avoimeen rajapintaan.
Esim. €/m2 , kWh/m2 tai muilla "anonyymisillä" arvoilla. Tai jos olette todella edistyneitä, juuri niillä mittaustuloksilla, jotka olette tehneet kiinteisössä. Eli yksittäisen tilan lämpötila, kosteus, äänitaso, viihtyvyys, ilman laatu rakennuksen sisällä ja ulkopuolella...
Näin voisimme rakentaa Suomessa tietokannan, josta oikeasti tiedämme miten eri tyyppisillä kiinteistöilä menee. Ja en tarkoita pelkkää energiaa, koska se on jo arkipäivää. Tarkoitan esim. todellisia siivouskustannuksia, käyttäjätyytyväisyyttä, vuokralaisten vaihtuvuutta, kahvinkeittimen täyttöastetta...
Ongelma 1: minne sitä tietoa talletetaan? Mikä avoin rajapinta? Missä?
Haaste 2:
Kaikki puhuu "Väylästä" jonne tieto laitetaan ja sitten se on jotenkin simbsalabBIM kaikkien käytettävissä.
Haastan rakennusalan tekemään "Väylän" vaatiman API speksit.
---
Meidän pitää sopia yhteisesti API VÄYLÄ. Ei muuta. Ei tarvitse sopia, kuka ylläpitää sitä. Ei tarvitse hypätä ylimmälle portaalle yhdellä hypyllä.
Kun API väylä on speksattu, voi softafirmat alkaa tehdä omia APEja siihen yhteensopiviksi. Vasta sen jälkeen, kun rakennusala pystyy osoittamaan yhteisen suunnana tiedon jakamisesta, voivat useat eri softatoimittajat alkaa tehdä siihen rajapintaan soveltuvia ohjelmistoja.
Tarkoitus ei ole tallettaa mitään API väylään (poislukien käyttäjien / firmojen tunnistautuminen). Tiedon tallennuksen hoitaa softat, jotka tukevat speksattua API väylää.
Kiinteistön omistaja voi valita itsellensä sopivat palveluntuottajan. Ja vaihtaa sitä toiseen, jos homma ei toimi. Uusi palveluntuottaja saadaan leivottua helposti olemassa olevaan systeemiin, sillä rajapinnat ovat tehty yhteisellä speksillä.
Rakennusalan pitää ensiksi sopia, minkälaisia API rakenteita tehdään. Siis näin yksinkertaisia speksejä koodareiden mietittäksi:
- Anna minulle kiinteistön nimi
- Anna minulle kiinteistön osoite
- Anaa minulle kiinteistön ikkunat
- Anna minulle kiinteistön ikkunat ja sen propertyt
- Anna minulle kiinteistön ikkunoiden propertyistä U-arvo
- Jaa kiinteistön ikkunat
- Jaa kiinteistöin ikkunann U-arvo
- Jaa ihan mitä vaan mitä ollaan löydetty
Ym. tarkoittaa sitä, että ei pidä määritellä, missä tieto on, vaan pitää määritellä rajapinnat.
Sen jälkeen kun olemme tehneet rajapinnat, softavalmistajat pystyvät tekemään softaa sen päälle.
Use-caset tulevat sen jälkeen, kun tiedetään, mitä tietoa on tarjolla.
Näin pääsemme avoimeen rajapintamäärittelyyn Suomen kiinteistöjen osalta. Näin saadaan softaa joka pystyy luottamaan avoimiin rajapintoihin.
Kun määrittelemme esim. buildingSMARTin kautta APIen tietosisältövaatimukset, pääsemme tasolle, jota ei muualla ole.
Ym. tekstistä päästään hienosti semanttiseen webiin, jota on tutkittu Drumbeat hankkeessa:
http://www.drumbeat.fi/
http://www.drumbeat.fi/pdf/RESTinterface.pdf
BIM Level 3 UK:ssa ei ole mitään meille Suomalaisille, me ollaan sentään jo 100 vuotiaita! Siis teinejä verrattuna britteihin, virtaa riittää.
Viikon kuva:
Suomi 100
Tosi mukavaa olla Suomalainen
Näytetään tekstit, joissa on tunniste API. Näytä kaikki tekstit
Näytetään tekstit, joissa on tunniste API. Näytä kaikki tekstit
lauantai 2. joulukuuta 2017
lauantai 5. marraskuuta 2016
API pelastaa maailman
Töissä, minun tehtäväni on kehittää prosesseja.
Yksi näistä teknisistä asioista kulminoituu jälleen kerran kolmikirjaimiseen akronyymiin: API.
Application Programming Interface, https://fi.wikipedia.org/wiki/Ohjelmointirajapinta
Ja tuon jälkeen voisi käydä vilkaisemassa tätä. http://avoinrajapinta.fi/
En osaa koodata. En ymmärrä softien sielunelämää. Mutta saan (onneksi) käyttää niitä töissäni.
Edustamani organisaation sovelluskehityksessä tietojen linkitys ja siirto/kopiointi on ollut mielestäni selvää aina. Mutta vasta viimeisten kuukausien aikana olen nähnyt sellaista kehitystä, mitä olen olettanut meillä olleen jo 4v. sitten.
Vasta nyt olen nähnyt rajapinnan, johon voi toinen yritys/softa integroitua muutaman päivän työllä. Vasta nyt minun powerpointtini alkaa toimia. En ymmärrä, miksi asiaa piti harjoitella 4 vuotta. Miksi softakehitys tekee itselleen helppoja ratkaisuja? Siirtelee tietoja omien tietokantojensa sisällä siten, että kolmannella osapuolella (tai edes itsellään) ei ole mitään mahdollisuutta tajuta, mitä tapahtuu? Mikseivät he ajattele kokonaisuutta joka on ulkona heidän softastastansa.
Teemme yhteistyötä erään globaalin pelaajan kanssa, Tässä projektissa linkitys Granlund Designerin ja Revitin välillä on ehdoton vaatimus. Miten linkki tehdään -> tietenkin API:lla !
Softa-arkkitehtimme oli tehnyt jo aikaisemmin avoimen API rajapinnan (https://designer-demo.granlunddesigner.fi/api/index ). Täysin nonsense for me...
Mutta tällä tiedolla ulkopuolinen koodari otti yhteyden parin tunnin koodauksella ja parilla sähköpostilla järjestelmäämme, Luki tietoja sekä kirjoitti niitä takaisin systeemimme. Päivän yhteisen hackathonin jälkeen meillä oli proto softan toiminnallisuuksista valmiina.
API, joka voidaan julkaista ulos vapaasti on ehdoton edellytys tietojen linkittämiselle. Olemme itse sählänneet useita integraatioprojekteja koska olemme oikeisseet muutamia mutkia, alittaneet riman väärissä paikoissa. Kunnollinen softa-arkkitehtuuri avoimien rajapintojen aikaansaamiseksi tietää töitä, mutta voitto häämöttää horisontissa. Elämä (ja markkinointi) helpottuu, kun tietää ja ymmärtää olevansa pieni osa kokonaisuutta, johon voi kytkeytyä avoimen API:n kautta.
Nykyisessä maailmassa ei ole softaa, joka on keskiössä, hallitsee "kaikkea" tietoa. Softat on ulkoradalla ja linkittyvät toisiinsa API:en kautta. Näin ainakin tällä hetkellä, kunnes joku keksii "väylän" jolla pelastetaan koko maailma... jonka kautta tieto siiryy simpsalabim järjestelmästä toiseen (mahtaakohan tuokin toimia apien kautta...).
Tämä on hienoa minulle, powerpointeissa oleva laatikot ja niiden välissä olevat viivat alkavat muodostua ohjelmistoiksi.
Viikon kuva:
Thanks Steven;
Yksi näistä teknisistä asioista kulminoituu jälleen kerran kolmikirjaimiseen akronyymiin: API.
Application Programming Interface, https://fi.wikipedia.org/wiki/Ohjelmointirajapinta
Ja tuon jälkeen voisi käydä vilkaisemassa tätä. http://avoinrajapinta.fi/
En osaa koodata. En ymmärrä softien sielunelämää. Mutta saan (onneksi) käyttää niitä töissäni.
Edustamani organisaation sovelluskehityksessä tietojen linkitys ja siirto/kopiointi on ollut mielestäni selvää aina. Mutta vasta viimeisten kuukausien aikana olen nähnyt sellaista kehitystä, mitä olen olettanut meillä olleen jo 4v. sitten.
Vasta nyt olen nähnyt rajapinnan, johon voi toinen yritys/softa integroitua muutaman päivän työllä. Vasta nyt minun powerpointtini alkaa toimia. En ymmärrä, miksi asiaa piti harjoitella 4 vuotta. Miksi softakehitys tekee itselleen helppoja ratkaisuja? Siirtelee tietoja omien tietokantojensa sisällä siten, että kolmannella osapuolella (tai edes itsellään) ei ole mitään mahdollisuutta tajuta, mitä tapahtuu? Mikseivät he ajattele kokonaisuutta joka on ulkona heidän softastastansa.
Teemme yhteistyötä erään globaalin pelaajan kanssa, Tässä projektissa linkitys Granlund Designerin ja Revitin välillä on ehdoton vaatimus. Miten linkki tehdään -> tietenkin API:lla !
Softa-arkkitehtimme oli tehnyt jo aikaisemmin avoimen API rajapinnan (https://designer-demo.granlunddesigner.fi/api/index ). Täysin nonsense for me...
Mutta tällä tiedolla ulkopuolinen koodari otti yhteyden parin tunnin koodauksella ja parilla sähköpostilla järjestelmäämme, Luki tietoja sekä kirjoitti niitä takaisin systeemimme. Päivän yhteisen hackathonin jälkeen meillä oli proto softan toiminnallisuuksista valmiina.
API, joka voidaan julkaista ulos vapaasti on ehdoton edellytys tietojen linkittämiselle. Olemme itse sählänneet useita integraatioprojekteja koska olemme oikeisseet muutamia mutkia, alittaneet riman väärissä paikoissa. Kunnollinen softa-arkkitehtuuri avoimien rajapintojen aikaansaamiseksi tietää töitä, mutta voitto häämöttää horisontissa. Elämä (ja markkinointi) helpottuu, kun tietää ja ymmärtää olevansa pieni osa kokonaisuutta, johon voi kytkeytyä avoimen API:n kautta.
Nykyisessä maailmassa ei ole softaa, joka on keskiössä, hallitsee "kaikkea" tietoa. Softat on ulkoradalla ja linkittyvät toisiinsa API:en kautta. Näin ainakin tällä hetkellä, kunnes joku keksii "väylän" jolla pelastetaan koko maailma... jonka kautta tieto siiryy simpsalabim järjestelmästä toiseen (mahtaakohan tuokin toimia apien kautta...).
Tämä on hienoa minulle, powerpointeissa oleva laatikot ja niiden välissä olevat viivat alkavat muodostua ohjelmistoiksi.
Viikon kuva:
Thanks Steven;
Tilaa:
Blogitekstit (Atom)