Information architecture is a matter

Discussion (and original post), see the link: English edition copy

Keskustelu linkin takana kokonaisuudessaan : Finnish edition copy – Kirjoitus myös Suomeksi alempana …

 

Take the first review of Inmon‘s model compared to Kimball‘s model – both of those guys are the pioneers of the information architecture and a very well-known influencers from the early 1980’s.

Inmon: All corporate information, further processed, “one truth”. A central data warehouse. Data Warehouse including historical data – the Corporate Information Factory (CIF)

Inmon’s CIF includes the data from the operational systems, data transfer and processing processes (ETL), data warehouse, and the establishment of the special needs of smaller data warehouses (data marts). Data Marts are always the data warehouse data, “one truth”, never data from anywhere else. These are the special needs of different departments and processes, analytical solutions, etc.

Data integration is time-consuming step. This work requires the utmost diligence, discipline. The entire organization is committed to information architecture.

CIF: A Data Warehouse should be located in a normalized relational database format. History-containing structures may be permitted to also be “de-normalized”, at least to some extent.

The work is a long-term, construction will last a long time, but in return is expected to be and should be long-lasting and reliable data architecture.

Kimball’s model is considered to represent “opposite” view of how the company will design and build architecture. Kimball’s model is also called “dimensional” model (stars, snowflakes).

In this approach, dimensional data structures (data marts) come directly from the organization’s applications. The same information can be transferred to more than just a single data mart, depending on the function of the individual models.

Interest and the criterion of this approach is the speed of development. Analytical and reporting needs can be quickly implemented when there is not a target to design and build the whole enterprise on a common data repository. Inmon other hand says that Kimball’s model used for the company there is no “one truth”

Kimball’s model is clearly based on a process orientation, business process needs of each individual. So far, this approach is often a business point of view clearer, or at least in principle it seems to be easier and clearer.

Inmon: Kimball’s so-called first phase of the data model – Maintaining will be a big pain, and an even impossible task. Data is not integrated and data is duplicated a lot.

Well, each of us has a certainty our own views based on our own experience. Both models have pros and cons, depending on business requirements, the urgency and potential resourced development.

Kimball’s model is further developed in the 2000s from that of the first phase, with a conformed dimensions, which will help the integration of different data models. And more recently has become the Master Data Management (MDM). MDM represents in Kimball’s model “one truth” representing enterprise-level information architecture.

Inmon compares these two views in “A TALE OF TWO ARCHITECTURES‘.

Inmon believes that Kimball’s model has lost its fundamental interests, the construction speed, because the criteria for MDM enterprise-level data model is no longer possible to design and build a lightly and quickly.

Inmon guess also that Kimball’s model is based on its popularity in business intelligence industry- the sale must be continuously and rapidly. CIF architecture, design and construction will take from this perspective too long. Kimball’s high-speed data mart building model has provided a better basis for fast product sales.

That may be true. I think that this is not the only aspect of the matter. Inmon’s CIF aroused much interest in Finland in the late 1990 onwards. Many companies started to build enterprise-level data models and centralized data warehouse architecture. Construction phase began, however, might be too early. Business and management support was lacking. Things were “technicians” driven. And the time and resources spent simply too much. Cash benefits could not be seen. It is very natural drift towards faster development cycles, which more closely mirrors then Kimball’s designs.

Time is now different from 10 years ago. Business and technology maturity has evolved to broader understanding of information management architecture and construction. It is also interesting to note how Inmon describes in the publication “A Tale of Two Architechtures” Kimball’s model developed. And the best things about Kimball’s may combine Inmon’s DW 2.0 concept. You agree with Bill on that?

Bill Inmon explains more about DW 2.0 concept in this article.

But what about business process modeling – I still miss the obvious link between the processes and the data models. – Why? – Well, that we would not build a massive data architecture, and then begin to look for something to use it for. As Emiel van Bockel said in his presentation in Helsinki, construction must start by first identifying the information needed to base a decision. Rather than that we are looking for any decisions that we could use the “expensive” information.


 

Tietoarkkitehtuurilla on väliä

Otetaan ensin tarkasteluun Inmon:in malli vs Kimball:in malli – 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”, 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.

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ä lokakuussa, 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ä.

 

Published on: Jan 8, 2011 / Petri Hakanen