Datan merkitys liiketoiminnalle kasvaa jatkuvasti. Datamäärien kasvaessa myös datapalveluiden saavutettavuus ja sujuva käyttökokemus ovat tulevaisuudessa yrityksille elinehto. Siksi data-alustojen toteutuksessa siirrytään enenevissä määrin moderneihin pilvipohjaisiin sekä API-lähtöisiin arkkitehtuureihin.
Useita datahankkeita kuvaa hyvin jo ilmestyessään vuonna 1998 kulttimaineen saavuttaneen South Parkin toisen kauden 17. jakso Gnomes (Tontut). Jaksossa South Parkin sankarit Stan, Kyle, Cartman ja Kenny sekä kaverinsa Tweek huomasivat, että heiltä häviää alushousuja. Lopulta pojat löytävät pienikokoisten kalsaritonttujen yhdyskunnan, joka pöllii southparkilaisten alusvaatteita rahat ja rikkaudet mielessään. Kysyttäessä kehittämänsä liiketoimintasuunnitelman neroudesta, kuvaavat kalsaritontut ideaansa seuraavasti:
• Vaihe 1: Kerää kalsareita
• Vaihe 2: ?
• Vaihe 3: Voitto
Vaiheen 2 puuttuminen osoittaa, että tontuilla ei ollut varsinaista suunnitelmaa pienellä viekkaudella kartutetun kalsarikokoelmansa monetisointiin.
Puutteellinen liiketoimintasuunnitelma. Kuva: Wikipedia (”Gnomes” South Park)
Kuten South Parkin kalsaritontuilla, vaiheen 2 puuttuminen on paljastunut tyypilliseksi ongelmaksi myös monen oikean yrityksen data platform -hankkeissa. Tyypillisiä data-alustahankkeiden kohtaamia haasteita ovat muiden muassa:
- kompleksinen liiketoiminnan malli
- monimutkaiset lähdejärjestelmät, suljetut rajapinnat ja integrointihaasteet
- siiloutunut liiketoiminnan ympäristö ja tiedon omistajuus
- siiloutunut teknologiainfrastruktuuri (esim. IT/OT-erottelu)
- puutteellisesti dokumentoidut tietolähteet
- uusien teknologioiden mukanaan tuomat osaamisvaatimukset ja osaajien puute.
Data-arkkitehtuurit puberteetti-iässä
Moneen muuhun verrattuna ovat tietojärjestelmät insinöörialana vielä nuoressa iässä. Esimerkiksi sillanrakennus, eräs klassisimmista insinöörialoista, voidaan tiettävästi ajoittaa jo vuoteen 850 EAA. Digitaalisten tietojärjestelmät ensiaskelet juontavat juurensa vasta vuoteen 1935, jolloin Alan Turingin teoksia julkaistiin Cambridgen yliopistossa.
Tietojärjestelmäalan sisällä Big Data ja Data Platform -teemaan liittyvät Data Warehouse ja Data Lake -konseptit ovat vielä huomattavasti nuorempia, lähes lapsen kengissä. Koko Big Data -termi on ensimmäisen kerran esiintynyt akateemisissa julkaisuissa vasta vuonna 1997 ja ensimmäiset, yleisesti käytössä olevat kaupalliset tuotteet kuten Apache Hadoop, AWS S3, Google Storage ja Azure Data Lake yleistyivät vasta 2010-luvulla.
Yksi insinööritieteiden perussäännöistä on, että osaaminen ja tarkkuus kasvavat kokemuksen, eli yritysten ja erehdysten kautta sekä myötä. Tämä näkyy myös tähän asti toteutettujen data-arkkitehtuurien maturiteetissa.
Sillanrakennuksen taito on noin 3 000 vuoden takaa, kun digitaalisten tietojärjestelmien ensiaskelet otettiin Cambridgen yliopistossa vuonna 1935.
Vaikka Data Platform -termin alle kuuluvat konseptit ovat hädin tuskin saavuttaneet edes varhaisteini-ikää, ei yksikään yritys halua pysähtyä odottamaan alan kehittymistä. Useat yritykset ovatkin lähteneet liikkeelle vahvalla ”data on uusi öljy”-ajatuksella tavoitteenaan tarjota eri käyttäjäkunnille dataa buffet-pöydistä tutulla itsepalveluperiaatteella.
Yritysten kilpavarustelua ovat vauhdittaneet teknologiatalojen markkinoinnissa esiintyvät vahvat lupaukset AI- ja koneoppimiseen perustuvalla analytiikalla saavutettavista pikavoitoista. Vaikka palveluntarjoajat intoutuvat toisinaan hieman epärealistisiin lupauksiin, on todellisuus kuitenkin kiistämätön: tulevaisuudessa data ja sen hyödyntäminen tulee vääjäämättä näyttelemään entistä suurempaa roolia yritysten kilpailukyvyn parantamisessa. Monelle yhtiölle data ja sen taitava hyödyntäminen ovat jo nyt suorastaan elinehto.
Tyypillinen tietovarastoarkkitehtuuri ja sen haasteet
Suurin osa tämän päivän tietovarastohankkeista rakentuu edelleen keskitetyn organisaation ja monoliittisen arkkitehtuurin varaan. Siinä keskeisinä komponentteina ovat:
- tiedostopohjainen tietoallas
- relaatiopohjainen tietokanta
- eräajoihin perustuva ETL-integraatiotyökalu
- BI- ja raportointityökalu
Tyypillisesti tämän kaltaiset projektit vastaavat organisaatioiden hyvin perinteiseen DW- ja analytiikkatarpeeseen. Tulevaisuuden data-alusta-arkkitehtuurin on kuitenkin vastattava pelkän raportoinnin lisäksi myös operatiivisen monitoroinnin ja reaaliaikaisen analytiikan tarpeisiin. Kasvavana trendinä on erityisesti teollisuusyrityksissä nähtävissä tuotannon reaaliaikaisten sovellusten tarpeet. Aikaisemmin näitä tarpeita on tyydytetty erilaisilla automaatiotoimittajien täsmäsovelluksilla, mutta jatkossa myös tehtaiden tuotannon sovelluskehityksessä katseet kääntyvät enenevissä määrin moderneihin hybridi-pilvipohjaisiin data-alustoihin:
- Tehtaan operaattoreille tulee tarjota reaaliaikaisesti päivittyviä monitorointinäkymiä, jotka voidaan esittää tehtaan valvomoissa, tuotantokoneiden läheisyydessä sekä työnjohdon mobiilisovelluksissa.
- Kunnossapidon asiantuntijoille tulee tarjota itsepalveluperiaatteella toimiva näkymä tuotantokoneiden tuottamaan prosessimittausdataan siten, että käyttäjä voi helposti porautua pitkän aikavälin trendistä aina laitteiden tuottamaan millisekuntitason raakadataan.
- Kunnossapidon päivystyksen tulee pystyä lähettää työnjohdolle akuuteista tapahtumista ja hälytyksistä reaaliaikaisia tekstiviestejä.
- Kumppaneille tulee tarjota tietoturvalliset REST API- sekä tapahtuma-rajapinnat, jotta yritys voi jo kertaalleen kerätyn datan perusteella toteuttaa innovatiivisia kehityshankkeita valitsemiensa kumppaneidensa kanssa.
”Tulevaisuuden data-alusta-arkkitehtuurin on vastattava pelkän raportoinnin lisäksi myös operatiivisen monitoroinnin ja reaaliaikaisen analytiikan tarpeisiin.”
Edellä mainitut esimerkit tuottavat haasteita perinteisissä, puhtaasti DW- ja bisnesanalytiikan tarpeista syntyneissä tietovarastoarkkitehtuureissa. Tämän vuoksi on syntymässä – ja jo syntynyt – uusia, entistä kokonaisvaltaisempia data-alusta-arkkitehtuureja ja niitä tukevia teknologioita.
Tulevaisuuden data-alustahankkeet noudattavat tuoteajattelua, mikropalveluarkkitehtuuria sekä DevOps-toimintatapoja
Yksi uuden lähestymistavan virstanpylväistä näki päivänvalon keväällä 2019, jolloin Zhamak Dehghani julkaisi näkemyksensä tulevaisuuden Data Mesh -konseptista. Vastaavasti kuin nykyaikaisissa sovellusarkkitehtuureissa on jo hyvän tovin siirrytty monoliittisista järjestelmistä mikropalveluihin, tulevat organisaatiot Data Mesh -arkkitehtuurissa myös siirtymään moniliittisistä tietovarastoistaan mikropalveluperiaatteiden mukaisesti toteutettuihin loogisesti hajautettuihin datapalveluihin.
Samaa arkkitehtuurillista ajattelumallia edustaa myös Gartner. Pian Dheghanin artikkelin julkaisun jälkeen vuoden 2020 Gartner IT Symposium/XPO -tapahtumassa lähes jokainen esitys nojasi kahteen teemaan: Composable Business Architecture sekä Packaged Business Capabilities.
PBC (Packaged business capability) on noussut suosituksi teemaksi Zhamak Dehghanin Data Mesh -konseptiin liittyvien näkemysten pohjalta.
Gartnerin näkemyksen mukaan kaikki liiketoiminnan sovellukset voidaan tulevaisuudessa toteuttaa kokoelmana paketoituja digitaalisia liiketoimintakyvykkyyksiä. Niitä yhdistellään yhä uudelleen toistensa kanssa, mitä tekemällä luodaan jälleen täysin uusia innovatiivisia kyvykkyyksiä.
Sekä Zhamak Dheghanin esittelemä Data Mesh, että Gartnerin Composable Business Architecture -teema nojaavat vahvasti modernin sovelluskehityksen ja integraatioiden periaatteisiin. Siinä hajautettu arkkitehtuuri ja API-pohjainen ekosysteemilähestyminen näyttelevät merkittävää roolia. Tämän perusteella voikin sanoa, että data-alustahankkeet tulevat jatkossa noudattamaan seuraavia periaatteita:
- Tuoteajattelu – Yksittäisten dataprojektien sijaan syntyy monipuolisia datatuotteita, joilla voi olla yrityksen sisäisiä tai ulkoisia asiakkaita. Kuten millä tahansa tuotteella, tulee myös datatuotteilla olla nimetty tuoteomistaja sekä -tiimi, joka omistaa sen koko elinkaarensa ajan aina määrittelystä suunnitteluun, toteutukseen, julkaisuun ja ylläpitoon, sekä kauniiksi lopuksi tuotteen hallittuun alasajoon. Käyttäjälähtöisten tuotteiden ja palveluiden suunnittelusta on viime aikoina julkaistu lukuisia hyviä artikkeleita ja kirjoja, jotka tarjoavat aiheeseen kiinnostavia näkökulmia ja hyödyllisiä vinkkejä.
- Domain-Driven Design (DDD) – Eric Evans jätti nimensä historiankirjoihin julkaisemalla vuonna 2003 yhden aikakautemme merkittävimmistä teoksista: Domain-Driven Design: Tackling Complexity in the Heart of Software. Kirjassaan Evans kiteytti yksiin kansiin ohjelmistosuunnittelun prinsiipit, käsitteistöt sekä joukon menetelmiä siitä miten ohjelmistoja tulee mallintaa ja suunnitella liiketoiminta edellä. Vaikka alkuperäinen teos on jo kirjoitettu lähes 20 vuotta sitten, moni Evansin esittelemistä perusasioista elää edelleen vahvasti ohjelmistoarkkitehtiyhteisössä. Aiheesta on sittemmin jalostettu useita eri kirjoja ja kursseja.
- Lambda-arkkitehtuuri – Datan käsittelyssä hyödynnetään sekä erä- että tapahtumapohjaisia streaming-menetelmiä. Osa datasta käsitellään jatkossakin perinteisellä eräajomenetelmällä, mutta kasvava osa datasta on luonteeltaan sellaista, että se pitää viiveiden minimoimiseksi käsitellä sitä mukaa kun tietoa syntyy. Esimerkiksi tuotantolaitosten reaaliaikaiset prosessidatat (IoT ja telemetriamittaukset) ovat luonteeltaan tällaisia.
- Mikropalvelut ja API-arkkitehtuuri – Mikropalvelut ja API:t ovat moderni tapa rakentaa sovelluksia ja integraatioita myös osana data-arkkitehtuuria. Muun muassa ketterien menetelmien puolestapuhujana tunnettu kehittäjälegenda Martin Fowler on viime vuosikymmenten aikana kiteyttänyt useita mikropalveluarkkitehtuurin keskeisiä ajatuksia. Liiketoimintamallinnuksen ja mikropalveluarkkitehtuurin lopputuloksena syntyvä liiketoiminnan kyvykkyys julkaistaan API-rajapinnat tarjoavana tuotteistettuna datapalveluna, joka piilottaa sen alla olevien teknologioiden monimutkaisuuden tarjoten liiketoiminnan tarvitsemat kyvykkyydet yhtenäisellä käsitteistöllä.
- DevOps – Mikropalveluita on käytännössä mahdoton hallita ilman saumatonta DevOpsia ja korkeaa automaatiotasoa. Siksi mikropalvelut ja DevOps kulkevat käsi kädessä. Ratkaisun osana DevOps-putket rakennetaan huolellisesti ja luodaan uudelleenkäytettäviä malleja, joita voi hyödyntää useissa mikropalveluissa. Lisäksi ympäristöjen hallinta, verkot, palvelinklusterit, tietovarastot ja muut resurssit toteutetaan ohjelmallisesti ja automatisoidusti IaC-ratkaisuilla (Infrastructure-as-Code). Tämä pätee myös tulevaisuuden data-arkkitehtuureihin.
Yhteenveto
Löytyykö relaatiomallin mukainen tietovarasto tulevaisuudessakin yritysten tiedonhallinnan keskiöstä ja mikä on sen ja esimerkiksi digitaalisia palveluita tarjoavan API-alustan keskinäiset roolit? Tänä päivänä molemmilla on oma toisistaan erillinen paikka arkkitehtuurissa, mutta jatkossa uskomme, että tämä ero on kuroutumassa monella tavalla umpeen. Tulemme varmuudella pian näkemään, kuinka yhä useammat yritykset siirtyvät keskitetyistä, monoliittisista relaatiopohjaisista tietovarastoistaan hajautettuihin API-arkkitehtuureihin. Niissä tuotteistetut, API-rajapinnoin julkaistavat datapalvelut julkaisevat selkeitä ja ymmärrettäviä liiketoimintakyvykkyyksiä moninaisiin tarpeisiin: johdon kuukausittaisesta raportoinnista tehtaan tuotantolinjan reaaliaikaiseen hälytykseen ja kunnossapitotyöntekijän mobiilisovelluksen ilmoituksiin – ja miksei myös kalsaritontuille omassa tärkeässä tehtävässään alusvaatetalouden kirittämiseksi.
Viitteet:
- [1] Maailman vanhin edelleen käytössä oleva silta Turkin Izmirissä on rakennettu n. 850 ennen ajanlaskun alkua. Lähde: Guiness World Records.
- [2] Application-controlled demand paging for out-of-core visualization, Michael Cox and David Ellsworth (1997).
Me Nortalilla olemme erikoistuneet sekä modernin sovelluskehityksen että data-alustojen suunnitteluun ja toteutukseen. Konsultoimme myös haastavia bisnesideoita menestykseen.
