API nana ko?

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

Tiedon epävarmuus

Lähitulevaisuudessa kaikki tieto on pilvessä, ehkä myös 3d-mallit.

Tieto on hajautettu objektitasolle, kuten nyt toimitaan IFC-malleissa. Venttiili tietää olevansa venttiili ja sille on liitetty lisäinformaatiota attribuuteilla. Venttiili tulee tietämään itsestään paljon muutakin, jota ei ole sille erikseen koodattu.

Kun sanon ym. lauseen ylläpidon ammattilaisille, saan sääliviä katseita. Isoa tietomäärää ei pysty kuulemma hallitsemaan ja pikkuosilla ei ole merkitystä kokonaisuuden kannalta. Tietoa pitää pystyä päivittämään, isoa massaa on vaikea (mahdoton) hallita. Minun vastaus siihen on, että pitäisi päästä pois excelistä / perinteisistä hierarkisista tietokantanäkymistä kohti tiedonhallintaa ja sitä kautta koota iso kuva perustuen pienempiin palasiin. Tällä matkalla olen alkukuopassa, työ jatkuu.

Pitää pystyä elämään epävarmuuden kanssa.

Lisäinformaation oikeellisuudesta ei ole mitään määritelmää. Kun luovutan mallini toiselle osapuolelle, toinen osapuoli ei pysty tietämään, mikä tieto on totta, arvausta tai pahimmassa (sekä normaalimmassa) tapauksessa: "Se ohjelma vaan laittoi sen tiedon sinne".

Tässä piilee tietomallien tulevaisuuden suurin ratkaistavissa oleva ongelma.
Olemme ohittaneet sen pisteen, että suunnittelijat eivät osaa käyttää softaa.
Olemme ohittaneet sen pisteen, että mallinnettaisiin vanhalla piirustusprosessilla.
Olemme ohittaneet sen pisteen, että tilaaja ei tietäisi, miten malleja haluaa käyttää rakentamisessa.

Tietomalliselostukset, dokumentit yms. yleismaailmalliset julkilausumat eivät kerro mitään. Tiedon on oltava sisällä objektissa. Jokaisen mutterin pitää tietää minimissään oma syntymäajankohta, kuka minut suunnitelmaan sijoitti, kuka minut muutti, kuka minut deletoi. Kaikille asioille tultava ajankohta objektille. Näitä asioita ei suunnittelija objektille anna, softa hoitaa sen.

Tulemme kohtaamaan ongelmia, kun tietosisältöön ei voi luottaa. En usko, että paperilla olevat taulukkomuotoiset LoDit asiaa selvittävät. Onko se muuten Level of Details vai Development... sen kanssa saa aina hyvin kulumaan puolisen tuntia bim-palavereissa. Eräs proffa esitti, että pitäisi olla LoE, Level of Estimation -> olen valitettavasti samaa mieltä. Nämä asiat pitää olla rakennettuna softaan sisälle, pilveen koko suunnitteluryhmän käytettäväksi. Softan tulee tukea prosessia / suunnitelman kehittämistä, tiedon luonti ja oikeellisuuden arvaus ei voi olla ihmisen viitseliäisyyden varassa.

Vanha viisaus on ollut, että: "Epävarmuuden kanssa on kyettävä elämään". Miksi pitäisi arvata jotain asiaa, jos joku kuitenkin tietää oikean vastauksen? Miksei se tieto voisi olla googlemaisesti semanttisessa webissä josta löydän tiedon muutaman hakusanan avulla?

Kun tähän päästään, minulla tulee olla kyky analysoida, onko saamani tieto totta vai ei. Samalla logiikalla kuin nykyisinkin - etsin googlella tietoa, saan paljon vastauksia joista 98% on turhaa, mutta yleensä ensimmäisten kymmenen vastauksen joukossa on ratkaisu. Tai ainakin kun klikkaan ensimmäistä ratkaisua, pääsen syvemmälle uusiin mahdollisuuksiin ja sitten löydän haluamani informaation.

Iso muutos on se, että virallista, oikeaa tietoa ei ole olemassa. On vain se tieto, joka on tarjolla siinä hetkessä, kun sitä kysytään. Sillä tarkkuudella, kun se on pystytty toimittamaan ko. projektin vaiheessa.

Tähän ollaan jo otettu ensiaskeleet nykyisessä rakentamisprosessissa. On hyväksytty, että IFC-mallit talletetaan esim. viikoittain työmaan käyttöön. Muutospiirustukset laitetaan kuitenkin harvemmin, kun on tehty "isoja" muutoksia. Työmaalla on siis mahdollisimman ajankohtainen tieto IFC-malleissa, mutta piirustukset laahaavat perässä. En ole kuullut yhdeltäkään työmaalta, että tämä olisi ongelma. Muutospiirustuksia käytetään vain lisälaskujen viitteinä.

Toinen esimerkki on energiasimuloinnit. Ne kuuluu tehdä siinä vaiheessa projektia, jossa on mahdollisuus vaikuttaa rakennuksen energiakäyttäytymiseen (hankevaihe/ehdotussuunnittelu). Kukaan ei kuvittele silloin tulevan lopullisia energiankulutustietoja. Mutta saamme eri vaihtoehtojen vaikutukset selville, jonka perusteella voidaan tehdä päätöksiä etenemisestä. Siis paras käytettävissä oleva tieto siinä ajankohdassa kuin simulointi on tehty.

Tarvitsen ohjelmistoja, jotka kommunikoivat toistensa välillä pilven sisällä. Tähän tarvitsen pilviservereitä, jotka hoitavat kommunikoinnin ilman, että minä teen mitään. Minun tehtävä on syöttää parasta mahdollista tietoa pilveen Toisen projektissa mukana olevan velvollisuus on käyttää sitä tietoa, jos sattuu / haluaa sen jostain löytää.

"Jos sattuu / haluaa sen jostain löytää". Mahdoton ajatus perinteisillä sopimusmalleilla.

Viikon kuva:

Yksi näistä palloista (simuloinneista) on oikea vaihtoehto: