Miksi rakensimme Ambientia Data Platformin?

Kaikki alkoi asiakkaan kysymyksestä

Alkuvuodesta yksi tiimeistämme sai melko tarkkaan rajatun kysymyksen: voisimmeko rakentaa data-alustan, joka ei olisi suoraan sidottu johonkin suureen kaupalliseen alustaekosysteemiin ja jonka voisi ajaa myös omassa ympäristössä (on-premises)? Kysymys tuli kiinnostavaan aikaan. Data-insinöörimme ja arkkitehtimme olivat jo usean vuoden ajan keskustelleet toisesta ongelmasta: modernit data-alustat ovat tehokkaita, mutta niiden mukana tulee myös paljon monimutkaisuutta. Merkittävä osa kehitystyöstä voi kulua konfigurointiin, pipeline-riippuvuuksien hallintaan, ajastettuihin ajoihin sekä sen selvittämiseen, mitä järjestelmässä on muuttunut ja missä.

Asiakkaan kysymys osui yhteen tämän olemassa olevan turhautumisen kanssa. Sen sijaan, että olisimme keskittyneet lisäämään alustaan uusia ominaisuuksia, aloimme pohtia, miten data-alustasta voisi tehdä helpommin ymmärrettävän, ylläpidettävän ja siirrettävän. Halusimme tietää, mitä datavirran jokaisessa vaiheessa tapahtuu, pitää tärkeät konfiguraatiot näkyvinä ja koneellisesti luettavina sekä välttää tilanteen, jossa jokin teknologiavalinta muuttuisi pysyväksi vain siksi, että sen korvaaminen myöhemmin olisi liian vaikeaa.

Yhdestä tarpeesta muodostui toistuva ilmiö

Aluksi tästä olisi voinut tulla vain yhden asiakkaan ratkaisu. Kevään aikana kehitimme ideaa yhdessä asiakkaan kanssa ja arvioimme komponentteja, jotka voisivat muodostaa ratkaisun perustan. Sitten toinen asiakas nosti esiin samankaltaisen tarpeen. Se muutti keskustelun suuntaa. Jos sama kysymys nousi esiin useammassa kuin yhdessä paikassa, ehkä ratkaisu kannattaisi suunnitella kunnolla kerran sen sijaan, että ratkoisimme samanlaista ongelmaa erikseen joka kerta.

Siinä vaiheessa ideasta alkoi muodostua Ambientia Data Platform. Meillä oli jo arkkitehtuurikonsepti ja joukko arvioituja komponentteja, vaikka valmista alustaa ei vielä ollut.

Kun aloimme visualisoida arkkitehtuuria, kuvittelimme toisistaan riippumattomia rakennuspalikoita, joilla jokaisella on selkeä vastuualue. Jokaisen palikan pitäisi toimia osana kokonaisuutta, mutta yhdestäkään ei saisi tulla korvaamatonta. Tästä ajatuksesta muodostui myös ADP:n visuaalisen identiteetin perusta. Tämän jälkeen teimme yhdessä Ambientian liiketoimintajohdon kanssa päätöksen edetä rohkeasti: yhdistää data-, arkkitehtuuri-, DevOps- ja avoimen lähdekoodin osaamisemme, rakentaa alusta ja viedä idea markkinoille.

Mitä päätimme ADP:n olevan

Ensimmäinen arkkitehtuuriperiaate oli, että jokaisen komponentin on oltava korvattavissa. ADP:llä on oletusarkkitehtuuri (default stack), ja me vastaamme siihen kuuluvien komponenttien arvioinnista, niiden elinkaaren seuraamisesta sekä kokonaisuuden ylläpitämisestä toimivana alustana. Itse arkkitehtuurin ei kuitenkaan pitäisi olla pysyvästi riippuvainen yhdestäkään komponentista. Kyse ei ole keskenään vaihdettavien lisäosien markkinapaikasta, vaan harkitusta oletusarkkitehtuurista, joka perustuu selkeisiin rajapintoihin ja mahdollisuuteen korvata komponentti silloin, kun siihen on hyvä syy.

Toinen periaate oli koneellisesti luettava konfiguraatio. Tärkeän konfiguraation ei pitäisi sijaita vain graafisessa käyttöliittymässä tai yksittäisen henkilön muistissa. Haluamme sen olevan näkyvää, versionhallittua ja toistettavasti käyttöönotettavaa. Sama ajattelutapa koskee myös datan muokkaukseen ja hallintaan käytettäviä sääntöjä. Teknisestä näkökulmasta tämä tekee alustasta helpomman ymmärtää, arvioida ja rakentaa uudelleen. Se antaa myös tekoälyavusteiselle kehitykselle hyödyllisen roolin: tekoäly voi auttaa konfiguraatioiden ja välivaiheen logiikan tuottamisessa ilman, että kyseinen logiikka piilotetaan ihmisiltä, jotka vastaavat alustasta

Kolmas periaate oli semantiikka. Datan siirtäminen ja muokkaaminen ei riitä, jos kukaan ei tiedä, mitä data liiketoiminnan näkökulmasta tarkoittaa. Tekoälyvalmiuden näkökulmasta tämä korostuu entisestään. Toimiva dataperusta tarvitsee datan rinnalle määritelmiä, liiketoimintasääntöjä, datasopimuksia ja laatutietoja. Haluamme myös tämän tiedon olevan versionhallittua. ADP voi tukea semanttista kerrosta, mutta vedämme sen roolille selkeän rajan: ADP on data-alusta, ei tekoälyalusta. Sen tehtävänä on tarjota luotettavaa, ajantasaista ja merkityksellistä dataa analytiikan ja tekoälyratkaisujen käyttöön.

Arkkitehtuurista toimivaan datavirtaan

Kun periaatteet olivat riittävän selkeitä, siirryimme kaavioista toteutukseen. Olemme asentaneet ensimmäiset avoimen lähdekoodin komponentit ja rakentamassa ensimmäistä päästä päähän kulkevaa datavirtaa alustan läpi. Ensimmäiseksi testitapaukseksi valitsimme tarkoituksella jotain, jonka koko tiimi ymmärtää: sähkön ennusteet ja toteumat. Aihe on itsessään tuttu, mutta sen hyödyntäminen edellyttää koko ketjun toimimista lähdejärjestelmästä ingestioon, datasopimuksiin, raakadataan, transformaatioihin ja mallinnukseen asti, jotta tuloksia voidaan lopulta hyödyntää ja visualisoida.

Data kulkee nyt onnistuneesti tämän polun läpi. Seuraava vaihe on testata yhtä tärkeimmistä arkkitehtonisista oletuksistamme: komponenttiriippuvuutta. Mitä tapahtuu, jos poistamme yhden komponentin? Voiko toinen ottaa sen paikan? Onko muu arkkitehtuuri edelleen järkevä? Kyky vastata näihin kysymyksiin käytännössä on meille tärkeämpää kuin pelkästään kuvailla ADP:tä modulaariseksi.

Pidä vaihtoehdot avoimina

ADP:tä ei ole tarkoitettu korvaamaan kaikkia organisaation olemassa olevia data-alustoja. Monissa tapauksissa siihen ei ole mitään syytä. Yrityksellä voi jo olla toimiva alusta Azure-, Fabric-, AWS-, Google Cloud-, Snowflake- tai muussa ympäristössä. ADP voi toimia näiden rinnalla tilanteissa, joissa suurempi hallittavuus tai siirrettävyys on tärkeää.

Tarve voi nousta esiin yritysoston yhteydessä, organisaatiomuutoksissa tai pilvistrategian uudelleenarvioinnin aikana. Se voi liittyä myös vain tiettyyn arkaluonteiseen tietokokonaisuuteen eikä koko organisaation dataomaisuuteen. Yhdistävä tekijä ei ole tietty teknologia tai toimiala. Se on päätös pitää merkitykselliset vaihtoehdot avoimina sen sijaan, että oletettaisiin koko data-arkkitehtuurin kulkevan yhtä ja samaa polkua.

Yritysosto on tästä hyvä esimerkki. Uuden yrityksen liittyminen konserniin ei välttämättä tarkoita, että kaikki data-alustat pitäisi välittömästi sulauttaa konsernin olemassa olevaan ympäristöön. Erillinen hallittu alusta voi mahdollistaa liiketoiminnan etenemisen samalla, kun pitkän aikavälin ratkaisuista tehdään päätöksiä. Joskus liiketoiminnan integrointi kannattaa tehdä ennen kuin kaikki alustat integroidaan.

Omista merkitys, älä pelkkää dataa

Tämän vuoksi uskomme myös, että omistajuuden täytyy ulottua raakadataa pidemmälle. Datan ympärillä olevat määritelmät, transformaatiologiikka, datasopimukset ja laatua koskevat säännöt tekevät datasta hyödyllistä. Ne määrittävät, mitä asiakas tarkoittaa, miten tietty mittari lasketaan, mitä muunnoksia dataan on tehty ja mitä muut voivat odottaa lopputulokselta. Jos tätä tietoa ei voida siirtää mukana, data ei ole niin siirrettävää kuin aluksi näyttää.

Semanttinen kerros on yksi paikka, jossa tämä konkretisoituu. Organisaatio voi jatkaa nykyisten data-alustojensa käyttöä samalla, kun tärkeät liiketoimintamääritelmät ja säännöt ylläpidetään ADP:ssä versionhallittuina kokonaisuuksina. Nämä määritelmät voidaan sen jälkeen tarjota rajapintojen kautta analytiikkatyökaluille, muille data-alustoille ja tekoälysovelluksille. Datan ei tarvitse sijaita yhdessä paikassa, jotta organisaatio voi hallita siihen liittyviä määritelmiä, sääntöjä ja liiketoimintamerkityksiä.

Ambientian rooli on auttaa teknisen perustan rakentamisessa ja ylläpidossa, arvioida komponentteja sekä auttaa organisaatiota pääsemään alkuun. Voimme myös hyödyntää tekoälyavusteisia menetelmiä semanttisten määritelmien ja muiden koneellisesti luettavien resurssien tuottamisen nopeuttamiseksi. Liiketoiminnan merkityksen tulee kuitenkin säilyä organisaation omissa käsissä. Tekninen alusta voi tukea tätä ymmärrystä, mutta se ei voi päättää, mitä asiakas, tuote tai liikevaihtoluku liiketoiminnalle tarkoittaa.

Missä olemme nyt

ADP sai alkunsa asiakkaan kysymyksestä ja kohtasi samalla teknisen haasteen, joka oli kytenyt taustalla jo vuosia. Toinen asiakas auttoi meitä näkemään, että tarve saattoi olla laajempi, ja se riitti muuttamaan idean alustakonseptiksi. Tällä hetkellä ensimmäinen teknologiakokonaisuus on toiminnassa, data kulkee alustan läpi lähteestä kulutukseen asti, ja testaamme arkkitehtuurin perusoletuksia käytännössä.

Tiedämme myös, ettei ADP sovi jokaiselle organisaatiolle. Se on mielekäs vaihtoehto organisaatioille, jotka haluavat ottaa konkreettisen askeleen kohti parempaa datan hallintaa ja siirrettävyyttä sekä ovat valmiita ymmärtämään ja omistamaan datan liikkumiseen ja merkitykseen liittyvät pelisäännöt.

Olemme nyt rakentaneet tämän vaihtoehdon.

Testaamme sitä, opimme jatkuvasti ja selvitämme, missä tilanteissa se tuottaa eniten arvoa. Jos organisaatiossanne pohditaan samankaltaisia kysymyksiä, keskustelemme mielellämme aiheesta lisää.