Blogi on siirtynyt!

Blogi on nykyisin paikassa: Onks tietoo; siis kotisivuillani www.arihovi.com : täällä.

Tietoarkkitehtuurista

Onko tietoarkkitehtuurin (informaatioarkkitehtuurin) laatiminen vaikeaa, onko se työlästä ja kalenteriaikaa vievää? Miten liiketoimntaihmiset saa mukaan?

Jos oikeat liiketoimintaihmiset saadaan mukaan käsitemallinnukseen, voidaan yllättävänkin nopeasti saada aikaan hyvät mallit ja kuvaukset organisaation keskeisistä tiedoista eri tietojärjestelmissä. Samalla myös määritellään käsitteet, jolloin sovitaan yhdessä onko se artikkeli, tuote tai materiaali sama vai eri asia. On tärkeää että mallinnuksen vetäjä on kokenut ja osaa ratkoa ristiriitoja. Liiketoimintaihmiset ovat aina kiireisiä, joten tehdä työpajojen on oltava mahdollisimman tehokkaita. Oikein organisoituna, ja hyviä menetelmiä käyttämällä on saatu aikaan hyvät kuvaukset ja mallit rasittamatta käyttäjiä liikaa - muuten he helposti jäävät tulematta seuraaviin istuntoihin. Mallinnuksessa osallistujat lisäksi oppivat toisiltaan ja sitoutuvat.

Tietoarkkitehtuurin rooli kokonaisarkkitehtuurissa on keskeinen. Käsitteiden määrittely tukee ja helpottaa sovellus- ja prosessiarkkitehtuurien laatimista.

ERP-järjestelmien hankinnassa keskitytään yleensä prosesseihin ja tiedot, tietorakenteet ja niiden määritelmät jäävät taka-alalle. Tietomalleja ei juuri käsitellä. Tämä voi pysäyttää tietokeskeisen ajattelun jopa vuosiksi. Tiedot ja tietojen rakenteet ovat kuitenkin huomattavasti pysyvämpiä ajan saatossa kuin prosessit – vähän kuin talon perustukset. Koskaan ei kuitenkaan ole myöhäistä aloittaa tietojen saamista hallintaan tietoarkkitehtuurimenetelmien avulla.

Pakko-SQL?

Pakkoruotsi lopetettiin, tarvittaisiinko pakko-SQL?

SQL on levinnyt käytännössä ainoaksi tietokantakieleksi. Oracle, SQL Server, DB2, MySQL ja monet muut tietokannat ovat SQL-pohjaisia Itse asiassa ne eivät ymmärrä muuta kieltä kuin SQL.

SQL näyttää helpolta ja alkuun pääseekin aika vaivattomasti. Toisaalta se on myös hyvin voimakas ja ilmaisuvoimainen kieli. Yllättävän moni DW/BI –alueella toimiva henkilö ei kuitenkaan osaa SQL:aa kovin syvällisesti. Monet BI-tuotteethan generoivat SQL:aa, joten syntyy vaikutelma, että ei sitä tarvitse osatakaan. Itse olen sitä mieltä, että SQL:n hyvästä hallinnasta on suurta hyötyä lataustoimissa, tietovarastotietokannan tutkimisessa ja testaamisessa, raporttien laatimisessa – itse asiassa sille on käyttöä lähes koko ajan. Tiukoissa paikoissa vain SQL:aa kirjoittamalla saadaan riittävä suorituskyky.

Olen harrastanut ja käyttänyt SQL-kieltä siitä lähtien, kun ensimmäisen kerran pääsin sitä kokeilemaan. Kyseessä oli Oraclen 4.2 –versio IBM:n ensimmäisessä PC:ssä. ”Uskomatonta miten paljon ohjelmointia voin säästää muutamilla liitoksilla” ajattelin tuolloin innostuneena. Sittemmin olen kirjoittanut pari kirjaakin aiheesta. Olen vuosien saatossa hionut esimerkkejä ja harjoitustehtävia ja koulutan edelleen SQL- peruskurssia ja laajempaa SQL syventävät päivät kurssia. Ideana on runsaiden harjoitustehtävien ja väliin lomitetun teorian avulla saada mukaan työpaikalle heti käyttöön otettavissa olevaa osaamista.

No – pakko-SQL:aa en kannata, mutta suosittelen lämpimästi vapaaehtoista opiskelua.

Osaatko indeksoida tietokantasi?

Relaatiotietokannan käytännön suorituskykyyn vaikuttaa ratkaisevasti se, minkälaiset indeksit tauluille on määritelty (jos termi ei ole tuttu, kerrottakoon lyhyesti: indeksit ovat erillisiä tietorakenteita, jotka nopeuttavat tietojen hakuja; tietokantojen optimoijat käyttävät indeksejä automaattisesti hyväksi; indekseihin ei viitata ohjelmissa, joten tietokantaa voi tehostaa indeksejä virittämällä – koskematta ohjelmiin ja kyselyihin).

Vaikka indeksien vaikutus suorituskykyyn tunnetaan yleisesti, asiasta on yllättävän vähän tietoa saatavissa. Tiedossani ei esimerkiksi ole kuin yksi nimenomaan indekseihin syvällisesti paneutuva kirja. Kyseessä on ”Relational Database Index Design and the Optimizers”, kirjoittajina Tapio Lahdenmäki ja Mike Leach.

Kirjan kirjoittaja, ystäväni Tapio Lahdenmäki on vuosikausia tutkinut indeksointia ja kehittänyt ainutlaatuisia menetelmiä ja kaavoja tälle alueelle. Hän on myös käytännössä konsultoinut ja testannut menetelmiään ja niillä on saatu hämmästyttäviä tuloksia. Tapahtumankäsittely-ympäristössä joidenkin tapahtumien vastausaika saattaa hidastua, jopa pariin minuuttiin. Tapsan indeksointimenetelmillä vastausaika saadaan pariin sekuntiin tai jopa alle sekuntiin. Aikamoinen prosentuaalinen parannus! Ja mikä parasta: parannus tehdään indeksointia muuttamalla: ohjelmiin ei tarvitse koskea!

Uskon, että monet sovellukset ja tietovarastoratkaisut tälläkin hetkellä tekevät aivan turhaa ja hidasta levylukutoimintaa. Ongelmaa ratkotaan pahimmillaan vaihtamalla isompaan koneeseen – kun ratkaisuksi riittäisivät suhteellisen yksinkertaiset indeksointitoimet.

Miten oppia indeksoimaan? Lahdenmäen Tapsan kirja on hyvä tietolähde. Tapsa on myös kehittänyt yli kymmenen vuoden ajan indeksointikurssiaan ja sen hyvin tarkkaa ja havainnollista materiaalia. Tapsa on tehnyt pitkän päivätyön IBM:n spesialistina ja itsenäisenä konsulttina ja on nyt vetäytynyt ansaitulle eläkkeelle. Onneksi toinen tietokantaguru Lauri Pietarinen jatkaa kurssin pitämistä Tapsan aineistolla ja tuella. Lauri on pitkän tietokantakokemuksensa avulla päässyt hyvin sisään aiheeseen ja onkin jo pitänyt kurssia menestyksellä useaan kertaan. Lauri on myös luontaisesti hyvä kouluttaja.

Väittäisin, että näin syvällistä indeksointikurssia ei ole USA:ssakaan saatavissa. Jos haluat kehittää asiantuntemustasi todellisen ekspertin tasolle, kannattaa kurssille osallistua. Lisätiedot: www.arihovi.com.

Liittyisinkö TDWI Finlandiin?

The Data Warehouse Institute Finland on Suomessa toimiva tietovarastoinnin ja business Intelligence –alueiden yhdistys, joka kuuluu maailmanlaajuiseen The Data Warehousing Institute (TDWI) yhteisöön. TDWI:n palvelut, jäsenille postitettavat julkaisut ja verkkosivustot ovat jäsenten käytettävissä.

Suomen osasto järjestää mielenkiintoisia esitelmä- ja keskustelutilaisuuksia. Kannattaa käydä kotisivuilla
http://www.dw-institute.fi ajoittain tutkimassa mitä on tulossa.

Olen kuulunut hallitukseen muutaman vuoden ja tuntuu, että toiminta on muuttunut aktiivisemmaksi viime aikoina. Puheenjohtajamme Petri Hakanen (Affecto) on vaivoja säästämättä neuvotellut maailmanluokan puhujia tilaisuuksiimme ja on muutenkin kehittänyt toimintaa, mm. Linkedinissä, jossa jo iso joukko kiinnostuneita seuraa keskustelua. Hallituksessa ideoimme jäsentilaisuuksia ja muita etuja jäsenille.

Kannattaa liittyä, liittymismaksulla saat hyviä jäsenetuja ja samalla edistät jaloa tietovarastoinnin aatetta. Käy kotisivuilla tutustumassa!

Yksi puhuu aidasta, toinen aidanseipäästä

Olin viime viikolla taas asiakkalla mallintamassa tietovarastoa. On palkitsevaa huomata, miten mallintaminen auttaa selkiyttämään ihmisten kommunikointia. Kuten otsikko vihjaa, ihmiset puhuvat todella usein epäselvillä käsitteillä. Voit itse miettiä, hyvä lukijani, mitä tarkoitat käsitteellä ”juna”. Onko se tiettyyn aikaan lähtevä vuoro, tietty välimatka vai enemmänkin tietty veturi vaunuineen? Monia mielikuvia syntyy, mutta BI- ja arkkitehtuuriratkaisut edellyttävät yhteisiä, tarkkoja määritelmiä.

Tietojen mallinnuksessa eli käsiteanalyysissä käsitteet määritellään yhdessä ja kirjataan ylös. Käsitteiden määrittely on välttämätöntä tietovaraston tai informaatioarkkitehtuurin suunnittelun yhteydessä, miten muuten voit yhdistellä ja analysoida tietoja. Määrittely auttaa epäsuorasti myös itse liiketoimintaa, ei kulu niin paljon aikaa hukkaan väärinymmärryksissä ja aita-aidanseiväs-väittelyissä.

Ostetaan tietovarasto!

Monet valmisohjelma- ja ERP-toimittajat tarjoavat nykyään tietovarastotyyppistä ratkaisua järjestelmänsä kylkeen. Yleensä kyseessä on maksullinen lisäosa. Tähän rajattuun tietovarastoon ladataan sitten tietoja itse tietojärjestelmästä ja tarjolla on erilaisia raportteja.
Ratkaisu tähtää siihen, että käyttäjä pääsee helpommin kiinni tietojäjrestelmän tietoihin. Yleisestihän valitetaan että ”tiedot saa kyllä sisään mutta mitään ei saa ulos”. Tähän asiaan saadaan siis helpotusta.

Isommissa organisaatiossa tilanne on kuitenkin monimutkaisempi. Useimmiten on monta hankittua sovellusta – eri toimittajilta. Hankitaanko silloin monta pikkutietovarastoa? Ongelmana on, että tietojen siiloutumisen ongelma ei ratkea. Tiedot ovat edelleen hajallaan pienoistietovarastoissa. Asiakastietojen integrointi ei helpotu ja kustannustietoja yhdistellään toimintalukuihin edelleen Excelissä.

Oman, erillisen tietovaraston rakentaminen saattaa arveluttaa. Asiaa kannattaa lähestyä arkkitehtuurinäkökulmasta: minkälainen tietovarastoarkkitehtuuri palvelisi parhaiten liiketoimintaa lähiaikoina ja toimisi kestävänä "DW-infrana" myös lähivuosina.