Järjestelmäarkkitehtuurin rakentaminen ulkopuoliseen asiantuntijayhteistyöhön

Konsultointiyritys oli määrännyt Talotekniikkatukku Oy:ltä saamaansa toimek-siannon suorittamiseen asiantuntijan projektipäällikön nimikkeellä. Määrityksen laadinta alkoi lokakuun 2001 alussa heti määritystarjouksen hyväksynnän jäl-keen it -palvelutarjoajan nimeämän projektipäällikön johtamalla aloituspalaveril-la. Aloituspalaverissa tutkija esitteli projektin taustat, tähän mennessä läpikäydyt vaiheet, nykyisen tilanteen sekä kertasi projektin tavoitteet. Projektin tavoitteina tutkija esitteli projektille siihen mennessä muodostuneita perusvaatimuksia, joita olivat tiivistetysti edullisuus, kehitettävän konstruktion tekninen yksinkertaisuus ja käytettävyyden vaatimukset. Esittelyn pohjalta konsultti muodosti oman koko-naiskuvan asiasta.

Aloituspalaverin jälkeen tutkijan ja konsultointiyritystä edustaneen projektipääl-likön välinen vuorovaikutus jäi vähäiseksi: Määrityksen laatijana toiminut kon-sultti esitti sähköpostilla yksittäisiä tarkentavia kysymyksiä, joihin tutkija vastasi logistiikka- ja tietohallinto-osaston tuella niin hyvin kuin osasi. Logistiikkajohto sai alustavan tarjouksen projektin teknisestä toteuttamisesta lokakuun 2001 lo-pulla³¹⁹. Alustavassa tarjouksessa esitettyjä arvioita vaadittavasta työmäärästä ja aiheutuvista kustannuksista pidettiin logistiikkajohdossa erittäin korkeina³²⁰. Kalliina pidetty toteutusehdotus oli vastoin projektille esitettyä edullisuus -perusvaatimusta³²¹. Aiemmin esitetyistä Access-sovelluksen roolivaihtoehdoista konsultointiyrityksen esittämä ratkaisu olisi tarkoittanut neljännen mallin mu-kaista rakennetta (ks. KUVIO 27).

Konsultin tekemän tarjouksen ohella tutkijan kiinnostus kohdistui myös tietotek-nisen määritysraportin sisältöön. Miksi kustannusten arvioitiin nousevan niinkin korkeiksi? Toteutusehdotus ei tarjonnut Access-sovellukselle mitään roolia, sillä ehdotuksessa päädyttiin ratkaisuun, jossa kaikki ominaisuudet ohjelmoitaisiin sovelluskehityksenä uudelleen Windows-käyttöjärjestelmään Access-tietokannan pohjalta. Korkeiksi nousevat kustannukset olivat osittain seurausta tästä suuresta ohjelmointityötarpeesta. Edellä esitetyistä Access-sovelluksen roolivaihtoehdois-ta ehdotus oli suoraan neljännen vaihtoehdon mukainen. Konsultti ei ollut huo-mioinut kaikkia tutkijan Talotekniikkatukku Oy:n puolelta projektille esittämiä konstruktion toteuttamiskelpoisuusvaatimuksia, mutta mitään perusteluja näiden perusvaatimusten huomioimatta jättämisellekään ei konsultilla ollut esittää.

319 Lopullinen määritysyhteenvetoraportti valmistui joulukuun alussa.

320 Tarjouksessa arvioitiin pelkän tietokantaosion tekniseen toteutukseen ilman linkityksiä IBM-toiminnanohjausjärjestelmästä kuluvan jopa 40 henkilötyöpäivää (htp), mikä tarkoitti käytännös-sä yhden konsultin kahden kuukauden työpanosta. Linkitysten toteuttaminen saattaisi johtaa jopa uuteen erilliseen projektiin alkaen taas määritystarjouksen tekemisestä. Lisää kustannuksia aihe-uttaisivat tarvittavat laite- ja ohjelmistolisenssi-investoinnit, joiden suuruudesta ei konsulttitalo osannut tässä vaiheessa esittää vielä minkäänlaisia arvioita.

321 Myös tutkija arvioi tarjouksessa esitetyn tekniseen toteutukseen vaadittavan työmäärän suure-na ja tarjousta kaiken kaikkiaan yllätyksellisenä.

toteknisesti ehdotus oli erittäin todennäköisesti toimiva³²², mutta sitä ei pidetty tietoteknisesti yksinkertaisena³²³. Käytettävyys -perusvaatimustakaan vaihtoehto ei täyttänyt: Tietojen syöttäminen tietovarastoon perustui määrämuotoiseksi oh-jelmoituun graafiseen käyttäjäliittymään, jonka päivittäminen ilman ulkopuolista asiantuntija-apua oli mahdotonta. Myös tietokantaan yhdistettävien perustieto-taulujen päivittämiseen piti ohjelmoida oma ylläpitoliittymänsä. Tietovaraston tietojen käsittelyyn sekä tietokantakyselyjen ja raporttien generointiin oli mah-dollista joko ohjelmoida omat graafiset käyttäjäliittymänsä tai tietovarastoon oli mahdollista linkittää Access-ohjelma. Muuta viittausta Access-ohjelmaan ei tek-nisessä määrityksessä esiintynyt. Graafisten käyttäjäliittymien vaihtoehdossa hyödyntämiseen liittyvien ominaisuuksien määrä oli suoraan verrannollinen suo-ritettavan ohjelmointityön määrään. Ehdotuksen katsottiin olevan niin pahasti ristiriidassa hankkeelle asetettujen toteuttamiskelpoisuusvaatimusten kanssa, että se päätettiin hylätä silläkin uhalla, että koko projekti tulisi epäonnistumaan. Ta-pahtuneen johdosta logistiikassa heräsi uusia vaikeita kysymyksiä: Miksi yhteis-työ konsulttitalon kanssa epäonnistui? Eikö konstruktiota voitukaan rakentaa täysin käyttäjien ehdoilla ”käyttäjälähtöisesti” eli olivatko asiakasinformaatiojär-jestelmän käyttökelpoisuudelle asetetut vaatimukset olleet sittenkin epärealisti-sia?

Tutkijan oman näkemyksen mukaan ennakko-odotusten vastainen toteutusehdo-tus oli ainakin osittain seurausta konsulttiyhteistyön epäonnistumisesta. Tutkijan ja konsultin välinen vuorovaikutus jäi erittäin yksipuoliseksi, jolloin riittävän syvälle menevää keskustelua todellisen yhteisymmärryksen löytämiseksi ei ollut mahdollista syntyä. Vuorovaikutus tuntui olevan lähinnä tutkijan vastaamista konsultin esittämiin kysymyksiin. Vaikka aloituspalaverissa nostettiin esille tär-keinä pidetyt järjestelmälle asetetut perusvaatimukset, ohitettiin ne nopeasti il-man tarkempaa pohdintaa ja analyysia³²⁴.

Ensimmäinen konsulttiyhteistyö tarjosi tuloksena it- teknisesti toimivaa toteutus-vaihtoehtoa, mutta vaihtoehto ei täyttänyt muita käyttäjälähtöisesti määriteltyjä vaatimuksia toivotulla tavalla. Konsultoiva yritys oli tietohallinto-osaston valit-sema. Tietohallinto oli valintaa tehdessään etsinyt erityisesti verkottamisen asi-antuntijaa, koska tietohallinto uskoi Access-osaamista olevan tutkijalla itsellään riittävästi. Olihan valmis testattu tietokantademo jo olemassa ja kenen tahansa käytettävissä. Verkottamisen asiantuntijalla oli puolestaan vahvaa osaamista par-haista olemassa olevista verkkoratkaisuista, joihin Access-ohjelmasovellus ei kuitenkaan liittynyt millään tavalla. Tietoteknisesti toimivuuden näkökulmasta Access-ohjelman käyttämistä pidettiin yksittäiskäyttöön alun perin kehitettynä

322 Ehdotuksessa hyödynnettiin mm. monissa toimiviksi osoittautuneissa tietokantapohjaisissa järjestelmäratkaisuissa paljon käytettyä ns. SQL-tiedonpakkausprotokollaa.

323 Asiasta olivat samaa mieltä tutkijan ohella logistiikkajohto sekä tietohallinnon tietohallinto-päällikkö ja järjestelmäasiantuntija.

324 Tässä yhteydessä tutkija pohti myös kysymystä, ”mihin hävisi Access?” Määrityksessä ohjel-maa ei käsitelty käytännössä lainkaan, sillä ratkaisuesityksessä sovellukselle annettiin mahdolli-nen rooli, mutta tämän mahdollisen roolin teknistä toteutusta ei käsitelty millään tavoin.

ohjelmana yleisesti jopa erittäin huonona vaihtoehtona verkottamisratkaisuja kartoitettaessa. Yksittäisen käyttäjän näkökulmasta tilanne oli kuitenkin päinvas-tainen; tietojen käsittely, kyselyjen ja raporttien generointi kyseisellä ohjelmalla olisi ollut erittäin kätevää ja hyödyllistä.

Yhteenvetona ja johtopäätöksenä tapahtuneesta voitiin logistiikassa todeta, että vaikka it -konstruktion toimivuus -vaatimuksesta ei voitu tinkiä, ei sen tavoitte-leminen kuitenkaan tapahtunut toivotulla tavalla. Access-ohjelman tarjoamista vaihtoehdoista ja mahdollisuuksista ei edelleenkään oltu täysin selvillä, koska verkottamisen asiantuntujakonsultti sovelsi ratkaisuehdotuksessaan verkottami-sen näkökulmasta parhaita tietoteknisiä ratkaisuja, joihin Access-sovellus ei kui-tenkaan liittynyt millään tavalla. Tutkijan ehdotuksesta ja logistiikkajohdon tu-kemana projektissa päätettiin pyrkiä eteenpäin etsimällä uusi yrityksen ulkopuo-linen asiantuntija, tällä kertaa korostetusti Access-osaamisen ammattilainen.

Tietohallinto löysi joulukuussa 2001 uuden, nyt Access-sovellukseen erikoistu-neen asiantuntijan. Uusi aloituspalaveri järjestettiin tammikuun 2002 alussa³²⁵. Palaveri alkoi jo kehitetyn Access-luonnoksen sisältöön tutustumisella ja ohjel-man käyttötarkoituksen selvittämisellä. Lisäksi käytiin läpi projektin vaiheet, käsiteltiin ohjelmiston käyttökelpoisuudelle asetettuja perusvaatimuksia sekä esiteltiin yrityksen tietojärjestelmän perusrakenne. Palaverin loppupuoli käytet-tiin keskusteluun käsillä olevan ongelman eli verkottamiseen liittyvien kysymys-ten parissa³²⁶. Palaverissa sovittiin, että konsultti tutustuu tutkijan ohjelmoimaan Access-relaatiotietokantaluonnokseen omalla tietokoneellaan tarkemmin, testaa tietokantaluonnosta oman työnantajansa verkkoympäristössä ja laatii tältä pohjal-ta parhaaksi katsomansa ratkaisuvaihtoehdot ongelmien ratkaisemiseksi. Sopi-vimmasta ratkaisuvaihtoehdosta tultaisiin tekemään määritysdokumentti ja sa-massa yhteydessä tultaisiin määrittelemään myös konsultoinnista aiheutuvat kus-tannukset tarkemmin, minkä pohjalta Talotekniikkatukku Oy voisi päättää jat-kosta.

Kahden päivän kuluttua aloituspalaverista Access-asiantuntija lähetti sähköpos-titse määritysdokumentin ensimmäisen luonnoksen, jossa ratkaisuvaihtoehtoa oli luonnosteltu kokonaisuutena. Luonnos sisälsi ratkaisuehdotukset tietojen linkit-tämisestä ja päivitlinkit-tämisestä IBM-toiminnanohjausjärjestelmästä Access-tietokantaohjelmaan, tietojen käsittelemisestä ja tallentamisesta varastoissa sekä Access-ohjelman toimivuuden varmistamisesta erilaisten kyselyjen ja raporttien generoimiseksi³²⁷. Ongelmien ratkaisemiseksi it- konstruktiolle asetettujen

325 Aloituspalaveriin osallistuivat ainoastaan tutkija ja uusi konsultti.

326 Palaverin aikana tutkijalle muodostui tapaamisesta vaikutelma, että molemmat palaverin osa-puolet, sekä konsultti että tutkija Talotekniikkatukku Oy:n edustajana, ymmärsivät toisiaan erit-täin hyvin.

327 Tekniset ratkaisut pohjautuivat linkitysten osalta päätietojärjestelmän ODBC-tiedonsiirtoprotokollan ja Windows NT-käyttöjärjestelmään sisältyvän Scheduler-apuohjelman käyttöön. tietokannan toimivuuden ja verkon kuormituksen vähentämiseksi Access-ohjelmaan konfiguroitu päätaulu ”irrotettiin” Windows-palvelimelle SQL-tiedonpakkaus-formaattiin pohjautuvaksi tietovarastoksi. Tietojen syöttämisen ja tallentamisen helpottamiseksi

tökelpoisuus -perusvaatimusten mukaisesti ei ainakaan toistaiseksi ollut mitään esteitä todettavissa. Alustava kustannusarvio vaikutti jopa alhaiselta verrattuna ensimmäisen konsultointiyrityksen vastaaviin laskelmiin verrattuna³²⁸. Access-sovelluksen rooli osana it -konstruktiota oli muodostumassa tässä kappaleessa aiemmin esitetyistä vaihtoehdoista toisen mallin mukaiseksi (ks. KUVIO 25).

Ensimmäiset uuteen konstruktioon liittyvät testaukset suoritettiin Talotekniikka-tukku Oy:n tietoverkossa tammikuun lopulla kolme viikkoa aloituspalaverin jäl-keen. Testit osoittivat Access-asiantuntijan esittämän ratkaisuvaihtoehdon toimi-vaksi, vaikka yksittäisiä ohjelmistovirheitä konstruktiosta vielä mm. linkitettävi-en tietojlinkitettävi-en osalta löytyikin. Myös varastossa tietojlinkitettävi-en talllinkitettävi-entamisongelman voitiin katsoa tulleen ratkaistuksi, sillä testien perusteella yksittäisen asiakaspalautteen tallentaminen vaati verkkokapasiteettia erittäin vähän³²⁹.

Tietojen käsittelyyn liittyvä testaaminen varastossa nosti esille myös muita kon-struktion käytettävyyteen liittyviä vaatimuksia. Konkon-struktion innovointivaiheessa todettiin tietojen linkittämisen IBM-toiminnanohjausjärjestelmästä olevan tar-peellista, jotta vältytään päällekkäisiltä tietojen syöttämiseltä tietojärjestelmän eri osissa³³⁰. Testausvaiheessa realisoitui myös uusi tarve, joka oli tietojen linkittä-misen automatisointi: Asiakaspalautteeseen liittyvät IBM-järjestelmän tiedot piti saada siirtymään Windows-tietovarastoon automaattisesti ilman erillistä manuaa-lisesti tapahtuvaa päivittämistä. Ratkaisu oli kuitenkin melko helposti ratkaista-vissa, sillä Windows NT-käyttöjärjestelmä sisälsi käyttövalmiina Win-dows Scheduler -apuohjelman, joka voidaan ohjelmoida suorittamaan tietojen päivitystapahtumaan määräajoin tapahtuvaksi. Päivitystapahtumassa ohjelma tarkistaa IBM-reklamaatiojärjestelmästä uuden asiakaspalautteen ja siirtää kaikki uudet tapahtumat kertasiirtona Windows SQL-tietovarastoon. Aluksi päivitysvä-liksi määriteltiin yksi vuorokausi, jolloin päivitys ajoitettiin tapahtuvaksi joka aamu klo 07:00. Testaamisen edetessä tämä päivitystiheys ei kuitenkaan riittänyt, sillä käytettävyyden parantamiseksi tietojen piti päivittyä nopeammin reaaliajas-sa. Tietojen reaaliaikaisuus -vaatimuksen perusteella päivitysväli muutettiin tunnin välein tapahtuvaksi. Tietojen reaaliaikaisella päivityksellä pyrittiin var-mistamaan se, että uusi asiakaspalaute saataisiin mahdollisimman pian järjestel-mään tallentamisen jälkeen myös käsittelyyn varastoissa.

alhaisen verkkokapasiteetin toimintaympäristössä relaatiotietokanta jaettiin osiin. Tietojen tallen-taminen nopeutuu ja toimivuus paranee, kun tietokannan jakamisen tuloksena tiedot tallentuvat tietokannasta tietovarastoon tietuekohtaisesti sen sijaan, että yksittäisen tietueen tallennustarve vaatii koko massiivisen tietokannan uudelleen tallentamisen.

328 Seuraavan kolmen viikon aikana yhteydenpito tutkijan ja konsultin välillä oli tiivistä ja tuona aikana käytiin läpi paljon yksityiskohtia konstruktion rakenteeseen liittyen.

329 Yksi asiakaspalautetietueen tallennustapahtuma vaati verkkokapasiteettia n. 15 kilotavua.

Kapasiteettitarve oli niin vähäinen, että verkon toimivuuteen ohjelman aiheuttamalla kuormituk-sella ei enää pitänyt olla merkittävää vaikutusta. Muussa tapauksessa verkkokapasiteettitason oltaisi voitu perustellusti todeta olleen liian alhainen.

330 Ks. keskitetty järjestelmäarkkitehtuuri (esim. Granlund & Malmi 2004).

It -konstruktion teknisistä ratkaisuehdotuksista valmistui vuorovaikutteisen yh-teistyön tuloksena kaksi määritysdokumenttia tasan kuukausi aloituspalaverin jälkeen eli helmikuun alussa vuonna 2002³³¹ (ks. LIITE 8). Koska ratkaisuehdo-tusten toteuttaminen oli jo käytännössä edennyt hyvinkin pitkälle ja konsultoin-tiyrityksen arvioimat kustannukset tuntuivat varsin kohtuullisilta, päätettiin pro-jekti toteuttaa ja saattaa päätökseen mahdollisimman pian³³². Määrityksen katsot-tiin toteuttavan hyväksyttävällä tavalla it -konstruktiolle asetetut käyttökelpoi-suus -perusvaatimukset.

4.3 Kehitetyn asiakaspalautetta rekisteröivän informaatiojärjestelmän