Information architecture is a matter
(English edition copy)Tietoarkkitehtuurilla on väliä
Otetaan ensin tarkasteluun Inmon:in malli vs Kimball:in malli (edellisissä olleet linkit vanhentuneet) – Molemmat mainituista herroista ovat tietoarkkitehtuurien pioneereja ja erittäin tunnettuja vaikuttajia jo 1980 luvulta alkaen.
Inmon: Kaikista organisation (Enterprise) tiedoista koostettuna ja jalostettuna ”yksi totuus”. Tietovarasto keskeinen. Tietovarastossa historioidut tiedot – Corporate Information Factory (CIF)
Inmon:in CIF pitää sisällään operatiiviset järjestelmät, tietoa tietovarastoon siirtävät ja jalostavat prosessit, tietovaraston ja tietovarastosta erityistarpeisiin muodostettavat pienemmät tietovarastot (data marts). Data Mart:it muodostetaan aina tietovarastosta, ”yhdestä totuudesta”, ei koskaan mistään muualta. Näitä erityistarpeita ovat mm. eri osastojen ja prosessien tarpeet, analyyttiset ratkaisut jne.
Aikaa vievä vaihe on organisaation eri sovellusten tietojen integrointi ja siirtäminen tietovarastoon. Tietovarasto ja koko CIF arkkitehtuuri rakennetaan koko organisaation näkökulmasta yhteiseksi ”totuudeksi”. Tämä työ vaatii äärimmäistä huolellisuutta, kurinalaisuutta ja koko organisaation sitoutumista mallinnettavaan ja rakennettavaan tietoarkkitehtuuriin.
CIF:issa tietovarasto tulee sijoittaa relaatiokantaan ja normalisoituun muotoon. Historian sisältävien rakenteiden sallitaan olevan myös ”de-normalisoituja”, ainakin jonkun verran.
Työ on pitkäjännitteistä, rakentaminen kestää pitkään, mutta vastineena tuloksen uskotaan olevan ja tulee olla pitkäkestoinen ja luotettava tietoarkkitehtuuri.
Kimball:in mallin katsotaan edustavan ”vastakkaista” näkemystä siitä, kuinka yrityksen tulee arkkitehtuurinsa suunnitella ja rakentaa. Kimball:in mallia kutsutaan myös ”dimensionaaliseksi” malliksi faktatauluineen ja dimensiotauluineen (tähtimalli, lumihiutale).
Tässä lähestymistavassa tiedot dimensionaalisiin rakenteisiin (data marts) tulevat suoraan organisaation sovelluksista. Sama tieto voidaan siirtää useampaankin kuin vain yhteen data mart:iin riippuen yksittäisten mallien funktiosta.
Etu ja peruste tässä lähestymistavassa on kehittämistyön nopeus. Analyyttiset ja raportoinnin tarpeet saadaan nopeasti toteutettua, kun ei oteta tavoitteeksi suunnitella ja rakentaa koko yrityksen käyttöön yhteistä tietovarastoa Inmon:in mallin mukaisesti. Mutta Inmon:in mukaan Kimball:in mallia mukaillen yritykseen ei synny ”yhtä totuutta”.
Kimball:in malli perustuu selkeästi prosessilähtöisyyteen, kunkin liiketoimintaprosessin tarpeisiin erikseen. Sikäli tämä lähestymistapa on usein liiketoiminnan näkökulmasta selkeämpi tai ainakin tuntuu lähtökohtaisesti siltä. Inmon:in mallissa prosessien tarvitsemat tiedot tulee ensin mallintaa koko yrityksen yhteisen näkemyksen omaavaan malliin ja siitä edelleen poimia prosessin käyttöön.
Inmon on Kimball:in mallista (ainakin tästä nk. Kimball:in ensimmäisen vaiheen mallista) sitä mieltä, että tietomallin ylläpitämisestä tulee ainakin isommalle yritykselle ajan myötä iso kipu ja mahdoton tehtävä. Tietoja ei ole integroitu ja tietoja monistetaan paljon.
No, meistä kukin muodostaa asiasta varmasti myös oman mielipiteensä omien kokemustemme perusteella. Molemmissa malleissa on hyvät ja huonot puolensa, riippuen liiketoiminnan vaatimuksista, kiireestä ja mahdollisuuksista resursoida kehittämistyötä. Laajan tietomallin ylläpitäminen erityisesti liiketoiminnan ja organisaation ja yritysrakenteiden muutoksissa on usein työlästä molemmissa tapauksissa.
Kimball:in malli on 2000 luvulla edelleen kehittynyt tuosta ensimmäisen vaiheen mallista ensin vahvojen dimensioiden suuntaan, joilla edesautetaan eri tietomallien integraatiota ja nyt viimeksi on tullut vahvasti mukaan Master Data Management (MDM). MDM edustaa Kimball:in mallissa jo ”yhtä totuutta” lähestyvää yritystason tietoarkkitehtuuria.
No tästäkin Bill Inmon pääsee nokittamaan ”kilpakumppaniaan” julkaisussaan ”A TALE OF TWO ARCHITECTURES” (linkki aikaa myöden tässäkin vanhentunut), jossa Inmon arvioi Kimball:in lähestyvän ja ennustaa seuraavan evoluution olevan CIF mallin mukaisen, mutta kevyesti piikittää Kimball:in löytäneen tämän totuuden yli 10 vuotta häntä itseään myöhemmin pitkän älykkään evoluution tuloksena.
Samalla Inmon arvioi MDM:n myötä Kimball:in mallin menettäneen perustavan etunsa, rakentamisen nopeuden, koska MDM perusteista yritystason tietomallia ei enää voi suunnitella ja rakentaa kevyesti ja nopeasti.
Inmon arvioi myös, että Kimball:in mallien suosio perustuu hyvin paljon business intelligence tuoteteknologian ja jakeluketjun kaupallisiin lähtökohtiin; myyntiä on saatava jatkuvasti ja nopeasti. CIF arkkitehtuurin suunnittelu ja rakentaminen kestää tästä näkökulmasta liian kauan. Kimball:in nopea data mart:ien rakentamismalli on tarjonnut paremman perustan nopeaan tuotemyyntiin.
Tuo voi olla tottakin. Mielestäni tämä ei ole kuitenkaan ainoa näkökulma asiaan. Inmon:in CIF herätti Suomessakin paljon kiinnostusta 1990 luvun loppupuolelta alkaen. Monet yritykset alkoivat rakentaa yritystason tietomalleja ja keskitettyä tietovarastoarkkitehtuuria. Rakentamisvaihe alkoi ehkä kuitenkin liian aikaisin puutteellisella liiketoiminnan ja johdon tuella ”teknikoiden” vetämänä. Ja aikaa ja resursseja kului yksinkertaisesti vain liikaa liiketoiminnalle näkyviin hyötyihin nähden. Näin on hyvin luonnollista ajautuminen nopeampaa kehityssykliin, joka mukailee sitten lähemmin Kimball:in kuin Inmon:in malleja.
Aika on kuitenkin nyt jo toinen kuin 10 vuotta sitten. Liiketoiminnan ja tekniikan kypsyys on kehittynyt laajempien tiedonhallinnan arkkitehtuurien ymmärtämiseen ja rakentamiseen. On myös mielenkiintoista huomata, kuinka Inmon kuvaa tuon julkaisun ”A Tale of Two Architechtures” loppupuolella Kimball:in mallin kehittyneen jo niin hyvin, että se sopii jo melkoisen hyvin yhdistettäväksi parhaista puolistaan CIF mallin parhaisiin puoliin, joita Inmon on mallintanut konseptiinsa DW 2.0. Samaa mieltä Billin kanssa?
(Bill inmon kertoo DW 2.0. konseptistaan myös tässä artikkelissaan; linkki ei enää toimi).
Nyt allekirjoittanut jää kaipaamaan vielä tähän tietoarkkitehtuuriin soveltuvaa liiketoiminnan prosessien, erityisesti tietointensiivisten prosessien kuten organisaation eri päätöstentekoprosessien mallintamista ja mallin yhteyttä tietoarkkitehtuuriin. Miksikö? No ettemme rakentaisi massiivista tietoarkkitehtuuria ja alkaisi sitten etsiä sille jotain käyttöä. Kuten Emiel van Bockel:kin mainitsi esityksessään Helsingissä, rakentamisen pitää lähteä tunnistamalla ensin päätöksien perustaksi tarvittavat tiedot, eikä etsimällä etsien hakea mahdollisia päätöksiä, joita hienoista tiedoista voisi tehdä.