Uutisia ja puheenvuoroja

Lue blogista digitaalisuuden arkkitehtien tuoreimmat uutiset ja näkökulmat.

Kirjoittaja: Marko Oja
Marko Oja
Marko Oja
Data-arkkitehti, joka auttaa asiakasta ymmärtämään tekniikan mahdollisuudet ja muuntaa innovatiiviset ideat teknisiksi ratkaisuiksi. Ketterät kehitysmenetelmät ja kehitystyötä tukevat prosessit ovat lähellä Markon sydäntä.

Edelliset postaukset

Azure Purviewin massapäivitykset - Mitä - Miksi - Miten?

Keskustelu Azure Purviewin ympärillä käy kuumana ja aihe on monilla mielessä. Sen mahdollisuudet ja toiminnallisuudet vakioprosessien ulkopuolelta jäävät kuitenkin usein vähemmälle huomiolle. Blogissa esitellään käyttötapauksia, jotka vaativat Purviewin toiminnallisuuksien laajentamista, sekä millaisia vaihtoehtoja näiden toteuttamiseksi on olemassa. Blogikynää alkoi taas pienen tauon jälkeen syyhyämään, kun tuli vastaan aihe, josta en löytänyt kunnollista kirjoitusta edes englanniksi. Päätinkin vetää nyt yhden...

Stroll in the Azure IIoT jungle - Cloud1

There are many different services on Azure that are used for IIoT solutions. Playfully I call this versatile stack as a jungle. And why not. We can see few different layers there from usage and also from architectural perspective. But before we go into details let’s take a step back to see the forest from the trees so to speak.  Download our blueprint about IIoT.

Tekniikka yksistään ei ratkaise tiedon laadun ongelmia

Väitän, että monessa yrityksessä tiedon hallinta ei ole osa jokapäiväistä tekemistä, eli tiedon omistajuutta, eikä laadun tarkkailuprosesseja ole selkeästi määritelty. Asiaa sekoittaa uusien lähteiden monimuotoisuus. Kaikella tiedolla ei enää ole vastaavaa teknistä määritelmää siitä, milloin se olisi oikein. Tällaisesta hyvä esimerkki on ulkoiset lähteet, kuten sosiaalinen media, jossa tiedon oikeellisuutta mitataan pikemminkin sen merkityksellisyytenä haluttuihin käyttötapauksiin kuin teknisillä raja-arvoilla.

Virheet minimiin, myös uusista lähteistä

Tiedon laadusta puhuttaessa on perinteisesti pääsääntöisesti keskitytty ihmisen tuottamien virheellisten arvojen havaitsemiseen. Virheitä voi syntyä puhtaan huolimattomuuden takia, kuten vaikkapa väärän arvon syöttämisestä. Tai ne voivat olla prosessipohjaisia, eli vaikkapa tilauksen sulkeminen ennen toimituksen tapahtumista. Tai teknisen järjestelmän kiertämistä, kuten vapaatekstikenttien määrämuotoinen käyttö, eli käyttötapaus, jossa selitekenttää käytetään tallentamaan tuotenumero.

Mikä arkkitehtuuri sopii parhaiten laadun mittaamiselle?

Kuten blogisarjan edellisistä osista kävi ilmi, tiedon laatu on monitahoinen ongelma. Yrityksellä tulisi olla määriteltyjä prosesseja, joilla tiedon laatua pyritään aktiivisesti parantamaan. Näiden tulisi olla osa yrityksen laajempaa datastrategiaa. Mittaamisen tulisikin olla keskeinen osa strategiaa, ja sen toteuttamiseksi Data Platform on arkkitehtuurillisesti luonteva paikka.

Yksi Data Lakehouse low-codella, kiitos

Jos seuraat datamaailman trendejä, niin olet varmaankin kuullut jo Data Lakehousesta. Se on Databricksin ehdottama arkkitehtuuri, joka käyttää Delta-tauluja tietoaltaan tallennusmuotona.

Huonolaatuinen data maksaa, ja se maksaa paljon

Tosiasia on, että huonolaatuinen data maksaa yritykselle huomattavia summia. Tästä esimerkkinä vaikkapa IBM:n tutkimus vuodelta 2018, jossa arvioitiin huonon datan maksavan pelkästään Yhdysvalloissa 3,1 biljoonaa dollaria vuosittain. Se on iso tukku rahaa. Ja vastaavia tutkimuksia on ollut useita.

Tiedon laatu. Ei wow-elämyksiä, vaan how-elämyksiä.

Tiedon laatu aiheena tuskin herättää kovinkaan monella wow-elämyksiä. Enkä tiedä kuinka pahan inflaation se on kärsinyt viimeisimpien hypetermien myllerryksessä. Tekoälyhän tuli ja sen piti tuoda ratkaisu kaikkeen, eikö vain? Totta puhuen, eihän siinä ihan niin käynyt.

API-kehityksestä liiketoiminnalle kiinnostavaa Power BI:n avulla

API:t eli ohjelmointirajapinnat ovat tänä päivänä kiinteä osa modernia Data Platformia. Ei pelkästään tiedon lähteenä, vaan myös tiedon jakelukanavana. Rajapintojen etuina ovat keskitetty tietoturva, yhdenmukainen datamalli sekä kehityksen joustavuus ja skaalautuvuus. Ei siis ihme, että meille data-alan ammattilaisille näiden käyttäminen ja rakentaminen on tuttua. API-kehittämisessä, kuten muussakin Data Platform -kehityksessä, ongelmana on usein saada liiketoiminnan kehittäjät innostumaan näistä toiminnalle...

Tiedon laadunhallinnan tulisi lähteä analytiikasta

Tuotannon tehostamiseen johtavassa analyysissä käyttäjä havaitsee poikkeaman erään mittalaitteen tiedoissa. Käyttäjä valitsee poikkeaman graafilta, kirjoittaa viestin ja lähettää havainnon eteenpäin raportilta. Tieto merkitään epäluotettavaksi, ja sitä hyödyntävät raportit indikoivat tilanteen käyttäjille. Heräte mahdollisesti epäluotettavasti tiedosta lähetetään tiedosta vastaavalle henkilölle, mukanaan informaatio siitä, kuka merkinnän on tehnyt ja miksi se on merkattu. Mukana kulkee myös tarkka tieto siitä...


Asiakkaitamme

Autamme monia yrityksiä eri toimialoilta saamaan datasta kilpailuetua.

Tilaa blogi