Aava Platform -konseptin arviointi

Transkriptio

1 TUTKIMUSRAPORTTI VTT-R Aava Platform -konseptin arviointi Kirjoittajat: Luottamuksellisuus: Juho Eskeli, Päivi Parviainen luottamuksellinen

2 2 (26) Raportin nimi Aava Platform konseptin arviointi Asiakkaan nimi, yhteyshenkilö ja yhteystiedot Aava ohjelmistot, Jari Heiskanen Asiakkaan viite Projektin nimi Projektin numero/lyhytnimi Raportin laatija(t) Sivujen/liitesivujen lukumäärä Juho Eskeli, Päivi Parviainen 26/0 Avainsanat Raportin numero VTT-R Tiivistelmä Tässä raportissa kuvataan Aava Ohjelmistojen tuote- ja liiketoimintakonseptin arvioinnin tulokset. Arviointi on arvioijien näkemys, ja perustuu arvioinnin suorittajien kokemukseen ja tulkintaan toimittajan kanssa järjestettyjen tapaamisten pohjalta, sekä arvioijien muuhun tietämykseen aihealueelta. Aava Ohjelmistojen toiminta perustuu Aava Platformin kehittämiseen ja sen muokkaamiseen erilaisiin asiakastarpeisiin. Aava Ohjelmistojen pääasialliset toiminta-alueet ovat yritysten toiminnanohjausjärjestelmät (ERP) ja niiden osat (esim. asiakkuuksienhallinta eli CRM), julkaisu- ja sisällönhallintajärjestelmät (CMS), sekä yritysten omat spesifiset tiedonhallintaan liittyvät ongelmat. Aava Platform koostuu loogisesti ns. ydinosuudesta mikä toteuttaa yleiskäyttöisyyteen vaadittavat tukitoiminnot sekä ohjelmiston rungon. Ytimen lisäksi kokonaisuus muodostuu asiakaskohtaisista laajennuksista (esim. CRM). Aava Platformin vahvuus on erityisesti sen käytettävyydessä, muokattavuudessa ja asiakaskohtaisen räätälöinnin helppoudessa. Käytetyt tekniset ratkaisut mahdollistavat muokattavuuden ja räätälöinnin pienellä työmäärällä. Merkittävä vahvuus on myös räätälöintien eristäminen, eli räätälöintejä ei tarvitse tehdä aina uudestaan uusille versioille. Luottamuksellisuus Luottamuksellinen Oulu Laatija Tarkastaja Hyväksyjä Juho Eskeli, Tutkija VTT:n yhteystiedot Kaitoväylä 1, PL1100, Oulu, Finland Jakelu Aava Ohjelmistot Tuomas Ihme, Erikoistutkija Matias Vierimaa, Teknologiapäällikkö VTT:n nimen käyttäminen mainonnassa tai tämän raportin osittainen julkaiseminen on sallittu vain VTT:ltä saadun kirjallisen luvan perusteella.

3 3 (26) Sisällysluettelo 1 Johdanto Tulosten yhteenveto Analyysin yksityiskohtainen kuvaus Yhteenveto...25

4 4 (26) 1 Johdanto 1.1 Tavoite Tässä raportissa kuvataan Aava Ohjelmistojen (jäljempänä Aava) tuote- ja liiketoimintakonseptin arvioinnin tulokset. Tehty työ koostui workshopeista asiakkaan kanssa, joissa käytiin läpi tuotetta ja tuotekehitysmallia sekä tuotteen ja tuotekehitysmallin analysoinnista näiden perusteella. Lisäksi tehtiin pienimuotoinen tuotteen kokeilu ja tutustuttiin tuotteen toiminnasta tehtyihin videoihin. Projektin tavoitteena oli Aava Ohjelmistojen tuote- ja liiketoimintakonseptin arviointi. Päämääränä oli arvioida järjestelmän hyötyjä, uutuusarvoa ja mukautuvuutta. Uutuusarvolla tarkoitetaan mm. sitä kuinka järjestelmä suhtautuu vastaaviin järjestelmiin tai järjestelmiin joiden alueelle Aava Platformia voidaan soveltaa. Mukautuvuus puolestaan tarkoittaa sitä miten / millä mekanismeilla Aava Platform tukee räätälöintejä tiettyyn tarkoitukseen. 1.2 Kohteen kuvaus ja rajaukset Työ tehtiin workshop -tyyppisesti Aavan henkilöiden kanssa sekä pienimuotoisella tuotteen käyttökokeilulla, ei tarkalla analyysillä itse tuotteesta esimerkiksi laajojen käyttötapausten tai suunnitelmallisen testaamisen kautta. Lisäksi tietoturvaselvitys ei sisältynyt hankkeeseen. Dokumentissa esitettävä arviointi on arvioijien näkemys, ja perustuu arvioinnin suorittajien kokemukseen ja tulkintaan toimittajan kanssa järjestettyjen tapaamisten pohjalta, sekä arvioijien muuhun tietämykseen aihealueelta. 1.3 Raportin käyttö Aava ohjelmistot saa käyttää raporttia vapaasti haluamiinsa käyttötarkoituksiin. 2 Tulosten yhteenveto Tässä kappaleessa esitetty tulosten tarkastelu perustuu demonstraatiotilaisuudessa kerättyyn lähdemateriaaliin, Aava Ohjelmistojen lausuntoihin ja materiaaliin joka on saatavilla Aava Ohjelmistojen julkisilta internet-sivuilta, Aava Ohjelmistojen laatimiin, tiettyjä asioita tarkentaviin videoihin, sekä pieneen tuotteen käyttökokeiluun. 2.1 Tekniset ratkaisut Tässä kappaleessa käsitellään Aava Platformin teknisiä ratkaisuja eli sen arkkitehtuuria, keskeisimpiä komponentteja sekä järjestelmän suorituskykyä ja luotettavuutta.

5 5 (26) Aava Platformin ohjelmistokomponenttivalintoja voidaan pitää onnistuneena siinä mielessä, että komponentit ovat laajalti käytössä (esim. Memcached referenssit), joten ne ovat kokeiltua tekniikkaa ja kypsyydeltään hyvällä tasolla, mikä myös varmistaa osaltaan luotettavan ja tehokkaan toimintaympäristön. Käytetty sovelluskehityskehikko (RoR) helpottaa ja nopeuttaa kehitystyötä eliminoimalla muuten manuaalisesti tehtäviä toimenpiteitä. Aava Platformissa käytetty JRuby ohjelmointikieli mahdollistaa Ruby ja Java ohjelmakoodiin yhdistämisen, laajentaen käytettävissä olevin ohjelmistokirjastojen tarjontaa. Java ja Ruby ohjelmakoodit tallennetaan eri tiedostoihin ja ne risteävät vain, kun Rubystä kutsutaan Java-kirjastoja (tai päinvastoin). Aava Platformissa tällaisia risteämiä on vain muutamia, jolloin ohjelmointikielten sekoittumisen merkitys kehitystyöhön minimoituu. Aava Platform on suunniteltu tietokantariippumattomaksi, eli se tukee käytännössä kaikkia tietokantaohjelmistoja joissa on tuki JDBC-rajapinnalle. Usean tietokannan tuki on oleellinen esimerkiksi tapauksissa joissa asiakkaalla on käytössään MySQL:stä eriävä tietokantaohjelmisto, ja asiakas ei ole halukas hallinnoimaan useita eri tietokantoja jo olemassa olevien lisenssien ja tukisopimuksien johdosta. Suorituskyvyn osalta demonstroitu järjestelmä vaikutti ripeältä, eikä myöskään tiedon määrän lisääminen järjestelmään vaikuttanut hidastavan sitä. Tuotantokäytön kannalta suuntaa antavia tuloksia saatiin demonstraatiotilaisuudessa simuloimalla usean käyttäjän aiheuttamaa kuormitusta vastaavaa tilannetta. Simulointi suoritettiin rasittamalla järjestelmää ajamalla useassa säikeessä ennalta määritettyä testikuviota. Simuloinnin tuloksena vasteajat pysyivät siedettävinä myös kovemmassa rasituksessa, järjestelmän toimiessa muutenkin stabiilisti. Järjestelmä on suunniteltu ohjelmistokomponenttien osalta niin, että se on mahdollista hajauttaa usealle palvelimelle mikä mahdollistaa suorituskyvyn lisäämisen ja luotettavuuden parantamisen palvelimia lisäämällä. Myös järjestelmän kykyä hajauttamiseen on demonstroitu käytännössä. Lähestymistapa mahdollistaa edullisten palvelimien käyttämisen suorituskyvyn ja luotettavuuden lisäämiseen, jolloin järjestelmä voi kustannustehokkaasti toimia käyttäjä- ja tietomääriltään sekä luotettavuusvaatimuksiltaan hyvinkin erilaisissa toimintaympäristöissä. 2.2 Käytettävyys ja toiminnallisuus Erilaisien toiminnallisuuksien kirjo Aava Platformissa on kattava. Aava Platformista löytyy mm. kansainvälisyyden tuki, yksityiskohtaisesti määriteltävissä olevat käyttäjäkohtaiset käyttöoikeudet, monipuoliset rajapinnat tiedon tuomiseen ja viemiseen ulkoisiin järjestelmiin, sekä intuitiivinen ja selkeä käyttöliittymä joka mahdollistaa monipuolisen tiedon hakemisen, analysoinnin, muokkaamisen, luonnin ja julkaisemisen. Raportin kirjoittajien kokemusten perusteella Aava Platformin käyttöliittymä on selkeä ja helppokäyttöinen verrattuna useisiin avoimen lähdekoodin järjestelmiin ja kaupallisiin tuotannonohjausjärjestelmiin. Esimerkiksi käyttäjän kannalta epäoleellisia painikkeita käyttöliittymästä ei löydy. Myös ominaisuuksiltaan erilaiset terminaalit ja selainteknologiat on otettu huomioon käyttöliittymää

6 6 (26) suunnitellessa. Ulkonäkömuutoksia käyttöliittymään voidaan tehdä yksinkertaisesti tyylitiedostoja muokkaamalla. Käyttäjille tarjotaan mahdollisuudet muokata käyttöliittymää vastaamaan heidän omia tarpeitaan, ja tallentaa muokatut näkymät jatkuvaan käyttöön. Muokkausmahdollisuuksia ovat mm. kenttien järjestely ja näytettävien kenttien valinta. Myös tietohallinto voi muokata käyttöliittymää ohjatusti esimerkiksi käyttäjäryhmäkohtaisesti. Käyttäjät voivat luoda ja tallentaa tarkoitusperiään parhaiten vastaavat raportit sisällyttämällä niihin haluamansa kentät, sekä suodattaa tuloksia hakuparametreillä. Vastaavat haku-, järjestely- ja suodatustoiminnot ovat tarjolla myös muutoin kuin pelkästään raportteja käsitellessä. Käyttöoikeuksien määrittäminen on suoritettavissa aina suurista kokonaisuuksista hyvin yksityiskohtaisiin asetuksiin saakka. Kansainvälisyyden tuki on huomioitu järjestelmää suunniteltaessa. Rajapinnoissa ulkoisiin järjestelmiin on tuettu useita yleisesti käytössä olevia web-teknologioita. Integraatioita ulkoisiin järjestelmiin voidaan luoda käyttämällä samoja rajapintoja joita käyttöliittymä hyödyntää. Vastaavaa lähestymistapaa on sovellettu myös eräässä avoimen lähdekoodin tuotannonhallintajärjestelmässä, josta raportin kirjoittajalla on kokemuksia, tosin vain yhtä web-teknologiaa (XML-RPC) käyttäen. Tietoa voidaan tuoda ja viedä järjestelmässä myös eri tiedostoformaatissa kuten XLS- tai CSV-muodossa. 2.3 Tuotekehitysprosessi Aava ohjelmistojen tuotekehitysprosessi selkeä vahvuus on asiakkaan näkökulman mukaanotto sekä tuotteen määritysvaiheessa, että käyttöönoton tuessa. Aava Platformin geneerisyys mahdollistaa asiakaskohtaisten ominaisuuksien rakentamisen ja niiden ylläpidon helposti, joten asiakkaan tarpeiden määritys ja niiden varmistaminen tehdään prototyyppien avulla. Tämä on hyvä käytäntö ja heikko kohta useiden muiden toimijoiden toiminnassa. Tuotekehitysprosessin perusasiat, kuten tuotteen versionhallinta ja vikojen hallinta, ovat kunnossa. Myös tuotteen testaus vaikuttaisi olevan riittävällä tasolla, mm. Aava Platformin geneerisyys auttaa riittävän testikattavuuden saavuttamisessa rajallisella työmäärällä. Muut tuotekehitysprosessin elementit ovat luonnollisesti vasta muotoutumassa organisaation pienen koon vuoksi formaaleja sisäisiä prosesseja ei välttämättä tarvitakaan. Kuitenkin, hyvien käytäntöjen kuvaamisen voi myös aloittaa epäformaalisti jo nyt. Mikäli organisaation koko kasvaa, on syytä määritellä käytännöt, joilla varmennetaan tehdyn työn tasainen laatu (tekijästä riippumatta). 2.4 Muutosten hallinta, ylläpidettävyys ja räätälöinti Aava Platformissa kantava ajatus on sen mahdollisimman hyvä muokattavuus erilaisiin käyttökohteisiin. Muokattavuutta Aava Platformissa tukevat erinäiset tekniset ratkaisut. Tällaisia ratkaisuja ovat mm. joustava työnkulkujärjestelmä, sen luokkarakenne ja mallipohjainen kehitysympäristö. Aava Platform koostuu loogisesti ns. ydinosuudesta mikä toteuttaa yleiskäyttöisyyteen vaadittavat tukitoiminnot sekä ohjelmiston rungon. Ytimen lisäksi kokonaisuus muodostuu asiakaskohtaisista laajennuksista (esimerkiksi asiakastietojen hallinta eli CRM).

7 7 (26) Aava Platform hyödyntää mallipohjaista kehitystä ja malleista automaattista koodin tuottamista. Aavan tapauksessa mallipohjainen kehitysympäristö on saatu toimimaan tehokkaasti, mikä osaltaan mahdollistaa selkeän sovellusarkkitehtuurin, ylläpidettävyyden sekä nopeat asiakaskohtaiset toteutukset. Aava Platformin prosessi-moottori mahdollistaa mm. tuotannonhallintajärjestelmissä yleisesti käytettyjen työnkulkujen suorittamisen. Myös kytkeytyminen ulkoisiin järjestelmiin on mahdollista. Työnkulut Aava Platformissa mallinnetaan Unified Modeling Language (UML)-kielellä. UML:sta on käytössä versio 1.4. Käytännön toteutukset saadaan tuotettua puoliautomaattisesti mallista. Tietyt asiat kuten tilasiirtymien yhteydessä luotavat uudet objektit voidaan määrittää jo UML-mallissa, mutta joissakin tapauksissa on tarpeen tehdä lisäyksiä (esim. toimintojen automatisointi) käsin räätälöitävään lähdekoodiin. Eräissä avoimen lähdekoodin ERP-järjestelmissä (joista raportin kirjoittajalla on kokemuksia), työnkulkujen kuvaaminen on melko työlästä, ainakin tapauksissa joissa työnkulut vaikuttavat useampaan kuin yhteen loogiseen moduuliin. Tällöin kokonaisuuden hahmottaminen hankaloituu, mikä osaltaan vaikeuttaa yrityslogiikan oikeellisuuden varmistamista. Aava Platformin selkeät rajapinnat objekteilla helpottavat määrittelyä ja työnkulkujen graafinen esitys helpottaa kokonaisuuden käsittämistä. Järjestelmään on rakennettu käyttäjille kattava määrä erilaisia näkymiä tiedon käsittelyyn. Näkymät on suunniteltu yleiskäyttöisiksi mikä osaltaan vähentää tarvittavaa räätälöintityötä, mutta toisaalta saattaa olla että nämä näkymät eivät yleiskäyttöisyydestään johtuen aina taivu kaikkiin tilanteisiin (esim. tuotteen ravintoarvot näyttävä widget). Tällöin on tarpeen räätälöidä näkymiä asiakaskohtaisiksi, jossa voidaan käyttää pohjana jo olemassa olevia näkymiä. Kypsyydeltään järjestelmän arkkitehtuuri on vakaa, merkittäviä rakenteellisia muutoksia ei ole tehty noin vuoteen. Järjestelmä ytimessä on lähdekoodia suhteellisen vähän, mikä osaltaan helpottaa järjestelmän hahmottamista. Kommenttien määrä lähdekoodissa on suhteellisen vähäinen, mikä voi hankaloittaa uusien järjestelmän parissa toimivien kehittäjien työtä. Kuitenkin myös uudet kehittäjät ovat käytännössä päässeet sisälle järjestelmään hyvin. Asiakkaan kannalta järjestelmän päivitykset on suunniteltu niin, ettei niiden pitäisi vaikuttaa olemassa oleviin toiminnallisuuksiin, tai lisätä esimerkiksi asiakkaan kannalta turhia ominaisuuksia. Aava Ohjelmistojen kannalta on oleellista suunnitella Aava Platformin päivitykset niin etteivät päivitykset vaikuta asiakaskohtaisiin räätälöinteihin asiakkuuksien lisääntyessä ja erityyppisten asiakasratkaisujen kasvaessa. Tämä helpottaa tuotteenhallintaa, koska tällöin ei synny eri variantteja tuotteesta. Aavan mukaan kaikki (ensimmäisen toimituksen jälkeen) asennukset ovat toimineet suoraan päivitysten jälkeen ilman asennus/asiakasspesifisiä lisätöitä vaikka jokainen on ollut täysin räätälöity kokonaisuus. Räätälöinnit, eli mallipohjaisesti tuotetun lähdekoodin laajentamiset ja muokkaukset on eristetty tuotetusta koodista eri hakemistoon ylläpidettävyyden parantamiseksi. Räätälöintien eristämisen osalta Aava Ohjelmistojen lähestymistapa vaikuttaa läheisesti samalta kuin edellä mainitussa avoimen lähdekoodin ERP-järjestelmässä, jossa räätälöinnit ovat myös eristetty omaan

8 8 (26) hakemistoonsa, joskaan vastaavia luokkien ylikirjoittamisen ja laajentamisen tukia kyseisessä ERP:ssä ei ole. Tuotannonhallintajärjestelmien tapauksessa räätälöinnit ovat olleet yleisesti hyvin hitaita ja kalliita toimenpiteitä, mutta Aava Platformin kohdalla asiakaskohtaisista räätälöinneistä suoriudutaan nopeasti ja kohtuullisen pienellä työmäärällä. Asiakkaan kannalta hyvä asia on, että Aava Ohjelmistot on osaltaan myötämielinen asiakkaiden itse suorittamiin räätälöinteihin. Tällöin osaava asiakas voi tarpeen tullen toteuttaa itse räätälöintityön. Aava Ohjelmistojen kannalta tämä teettää kuitenkin lisätyötä, ellei palvelusopimuksessa erikseen suljeta asiakkaan itse tekemiä räätälöintejä Aavan ylläpitovastuun ulkopuolelle. 2.5 Liiketoiminta-ajatus ja tuotekonsepti Aava Ohjelmistojen toiminta perustuu Aava Platformin kehittämiseen ja sen muokkaamiseen erilaisiin asiakastarpeisiin. Aava Platform soveltuu moneen erilaiseen käyttötarkoitukseen, joten kohdemarkkinoita ei ole järkevää rajata. Pääasialliset toiminta-alueet ovat kuitenkin yritysten toiminnanohjausjärjestelmät (ERP) ja niiden osat (esim. CRM), julkaisu- ja sisällönhallintajärjestelmät (content management), sekä yritysten omat spesifiset tiedonhallintaan liittyvät ongelmat. Lisäksi ohjelmistoyritys voi alkaa tekemään omia tuotteitaan Aava päällä ja maksaa lisenssimaksuja Aavalle. Maailmalla on useita sekä avoimen lähdekoodin että kaupallisia tuotteita samoihin käyttötarkoituksiin kuin mihin Aava Platform voidaan mukauttaa. Aava tarjoaa kuitenkin useita etuja verrattuna moneen muuhun tuotteeseen, esimerkiksi Aava Platformin geneerisyys mahdollistaa sen muokkaamisen asiakastarpeisiin sopivaksi, eli ohjelmisto sovitetaan asiakkaan toimintaan, eikä asiakkaan tarvitse muuttaa toimintaansa ohjelmiston mukaiseksi, kuten usein ERP järjestelmien osalta on tilanne. Lisäksi tuotteen käytettävyys on erittäin hyvä, joka alentaa tuotteen käyttökynnystä ja vähentää käyttäjien tekemiä virheitä. Aava ohjelmistot myös pyrkii avoimuuteen toiminnassaan, eli esimerkiksi toimittajariippuvuutta pyritään välttämään. Asiakaskohtaisten ominaisuuksien määritys edellyttää usein toimiala-osaamista, esimerkiksi toimialan termit, toimintatavat ja lainsäädäntö tulee tuntea. Aava Platform tukee kuitenkin tässä, kun prototyyppien ja asiakkaan mukaan ottaminen kautta voidaan varmentaa tehtyjä ratkaisuja. Tämä kuitenkin edellyttää, että asiakkaalla tai Aava ohjelmistoilla on tarvittava asiantuntemus. 3 Analyysin yksityiskohtainen kuvaus 3.1 Järjestelmän arkkitehtuuri Tässä kappaleessa esitellään tarkasteltavan tuotteen tekninen analyysi arkkitehtuuritasolla. Lisäksi tarkastellaan tuotteen suorituskykyä ja luotettavuutta arkkitehtuurin näkökulmasta, sekä Aava ohjelmistojen omien lausuntojen perusteella.

9 9 (26) Järjestelmä on rakennettu tunnettuja avoimen lähdekoodin komponentteja käyttäen. Järjestelmän oleellisimmat komponentit ovat: Java Virtual Machine (JVM), JRuby 1, Ruby on Rails 2, MySQL 3, Memcached 4, Apache HTTP server 5, Jetty 6 sekä Apache Solr 7. JRuby on järjestelmän kehityksessä käytetty sovelluskieli, jota ajetaan JVM:n päällä. JRuby on laajennus Ruby ohjelmointikieleen joka mahdollistaa kaksisuuntaisen integraation Java-kielisiin ohjelmistoihin. Kaksisuuntaisuudella tarkoitetaan tässä tapauksessa sitä, että Java ohjelmistoista on mahdollista suorittaa kutsuja JRuby:llä tuotettuihin ohjelmistoihin, ja vastaavasti JRuby ohjelmistoista Java-kielellä tuotettuihin ohjelmistoihin. Ruby on dynaamisesti tyypitetty yleiskäyttöinen oliopohjainen ohjelmointikieli. Ruby on Rails (RoR) on sen sijaan web-sovellusten kehittämistä helpottamaan luotu avoimen lähdekoodin kehikko Ruby ohjelmointikielelle. Se on myös Aava Platformissa erittäin keskeinen osa, koska Aava Platform on rakennettu kyseistä RoR-kehikkoa käyttäen. Ensimmäinen RoR:n julkinen versio on vuodelta 2005, ja sittemmin RoR:lle on syntynyt aktiivinen kehittäjäkunta ja laaja käyttäjäpohja erilaisissa web-sovelluksissa. RoR mahdollistaa teoriassa nopean sovelluskehityksen tukemalla erilaisia menetelmiä jotka vähentävät manuaalisesti ohjelmoitavan sovelluskoodin määrää. Tällaisia keinoja ovat esim. automaattinen mallien ja näkymien generoiminen ohjelmiston jollekin osa-alueelle, joita voidaan myöhemmin käsin erikoistaa paremmin tarkoitukseen sopiviksi. RoR:ssa keskeisessä roolissa on Model-View-Controller (MVC)-arkkitehtuuri. Koska MVC-arkkitehtuuri on RoR:ssa ns. sisäänrakennettuna, on sillä kohtuullisen helppoa luoda sovelluksia jotka seuraavat MVC-arkkitehtuurin määrityksiä. MVC-arkkitehtuurissa eristetään omiin yksikköihinsä kukin sen kolmesta osaalueesta (malli, näkymä, kontrolleri). MVC-arkkitehtuurissa mallit (Model) ovat ohjelmiston tietorakenteita, näkymät (View) ohjelmiston käyttöliittymäkomponentteja ja kontrollerit (Controller) ohjelmiston sovelluslogiikkaa. Tällä lähestymistavalla on pyritty selkeyttämään sovelluksen rakennetta sekä helpottamaan kehitystyön jakamista komponentteihin. Muita hyötyjä ovat esimerkiksi erilaisten näkymien tuottaminen pienellä vaivalla, koska näkymät voivat käyttää yhtenäisiä rakenteita varsinaiselle toimintalogiikalle Tietokantana Aava Platformissa on tällä hetkellä avoimen lähdekoodin tietokantaohjelmisto MySQL. Tietokannan vaihtoa toiseen ei ole kokeiltu käytännössä, mutta Aava ohjelmistojen mukaan kaikki JDBC- rajapinnan omaavat tuotteet on tuettu. Järjestelmässä käytetty RoR:n ActiveRecord-komponentti mahdollistaa tietokannan vaihtamisen toiseen vaivattomasti. ActiveRecord tarjoaa mahdollisuuden olioiden tallennuksen sellaisenaan tietokantaan (Object Relational Mapping). ActiveRecordin Single Table Inheritance (STI) ei tue Aava Platformin periytymismallia täydellisesti, minkä vuoksi STI:tä käytetään Aava Platformissa ainoastaan templateihin. Muu moninperintä Aava Platformissa hoidetaan Rubyn

10 10 (26) peritymismallia eli Mixin:eitä käyttäen. Tämä järjestely tarkoittaa käytännössä sitä, että UML kuvauksista generoidaan tietokantamallit käyttäen open source työkalua ja muut tekniset ratkaisut huolehtivat siitä, että ohjelmiston mallit ja luokat ovat synkronoidut keskenään. Aava Platformissa sen palvelinkomponentti on tilaton (sessionless), koska Memcached ohjelmisto huolehtii ajonaikaisesta tilatiedon hallinnasta. Memcached on suunniteltu toimimaan välimuistina web-pohjaisille ohjelmistoille, niin että tarve suorittaa toistuvia ja hitaita tietokantakyselyitä vähenee ja sen sijaan samat tiedot saattavat löytyä nopeasta keskusmuistista. Varsinaiset järjestelmätiedot (esim. asiakastiedot) on tallennettu pysyvästi tietokantaan (MySQL). Tätä arkkitehtuurin osa-aluetta demonstroitiin sammuttamalla palvelin-komponentti ja käynnistämällä se uudelleen. Näiden toimenpiteiden jälkeen järjestelmän toiminta jatkui normaalisti aikaisemmasta tilanteesta ennen palvelin-komponentin sammuttamista. Aava Platformissa Memcachedin käyttö mahdollistaa myös palvelinkomponentin hajauttamisen tarvittaessa useammalle palvelimelle. Tällaisessa tapauksessa käytettäisiin myös ns. kuormansäädintä (load balancer) jonka tehtävänä on huolehtia tulevien kyselyiden allokoinnista vapaille palvelimille jonkin ajoitusalgoritmin (scheduling) perusteella. Apache HTTP palvelin on laajalti maailmalla käytetty avoimen lähdekoodin ohjelmisto. Aava Platformissa Apache vastaa käyttäjien kyselyihin heidän ohjatessaan selaimensa Aava Platformin osoitteeseen. Apache palvelee staattiset tiedostot (avoimet ja autentikoitavat) sekä välittää pyynnöt (reverse proxy) jatkokäsiteltäväksi kulloisenkin kyselyn tyypille kuuluvalle komponentille. Näitä komponentteja ovat Jetty, Ruby Rack/RoR ja Solr. RoR ja Solr pyörivät Jettyn päällä. Apache välittää pyynnöt Jettylle, joka puolestaan ohjaa kyselyt RoR:lle. Solr integraatio toimii yhden noden tapauksessa suoran API:n kautta [EmbeddedSolrServer Usean noden tapauksessa Solria ajetaan servlettinä omassa sovelluspalvelimessa. Jetty on avoimen lähdekoodin HTTP- ja Java servlet sovelluspalvelin. Jettyä voidaan käyttää esim. Java ohjelmistokomponenttien tarjoamiseen palveluina (web services). Apache Solr on avoimen lähdekoodin hakualusta. Solria voidaan ajaa servlettinä sopivassa palvelinohjelmistossa, esim. Jettyssä. Solr perustuu tunnettuun Lucenehakukoneeseen. Yksi Solr:n tärkeimmistä ominaisuuksista on faceted search, joka mahdollistaa hakujen rajauksen tietyin parametrein. Aava Platformissa järjestelmään kuvattavien prosessien ja tietoalkioiden määritys tapahtuu UML-kielellä mallintamalla. Koodin tuottaminen malleista on toteutettu kehittämällä käytettyyn mallinnusohjelmistoon erillinen plug-in, joka hoitaa lähdekoodin tuottamisen. 3.2 Keskeisimmät komponentit Tässä kappaleessa arvioidaan Aava Platformin kannalta keskeisimpien komponenttien luotettavuutta ja vaihdettavuutta. Tämä on oleellista järjestelmän ylläpidettävyyden näkökulmasta. Luotettavuuteen on syytä kiinnittää huomiota

11 11 (26) avoimen lähdekoodin komponentteja käyttäessä, koska yksittäisillä toimijoilla on yleensä erittäin rajalliset mahdollisuudet vaikuttaa avoimen lähdekoodin kehittäjäyhteisöihin, ja tätä kautta komponenttien tulevaisuuteen. Aava Platformin komponentit on esitelty kappaleessa 3.1. Ruby on Rails on Aava Platformin kehityksessä käytetty sovelluskehikko. RoR on kypsyydeltään hyvällä tasolla johtuen vuodesta 2005 jatkuneesta aktiivisesta avoimen lähdekoodin yhteisöjen suorittamasta kehitystyöstä sekä laajasta käyttäjäkunnasta joka on ohjannut kehikon kehitystä. Aava Ohjelmistojen kannalta kehikon vaihtaminen toiseen ei ole järkevää, johtuen kiinteästä integraatiosta Aava Platformiin ja koska kehikon vaihtaminen tarkoittaisi käytännössä uutta tuoteprojektia. Kehikon vaihtamiselle ei ole kuitenkaan mitään perusteita johtuen sen elinvoimaisuudesta ja hyvistä tulevaisuudennäkymistä, joten valintaa voidaan pitää onnistuneena. MySQL on avoimen lähdekoodin tietokantaohjelmisto joka on maailmalla hyvin yleisessä käytössä. MySQL on todettu toiminnassa suorituskykyiseksi ja luotettavaksi tuotteeksi, joten tältä osin ongelmaa ei ole. MySQL:n tulevaisuudennäkymiin ja jatkokehitykseen liittyy kuitenkin riski omistajavaihdoksen kautta, koska uudella omistajalla on myös muita tietokantaohjelmistoja portfoliossaan. Aava Ohjelmistojen kannalta tämä ei kuitenkaan ole riski, koska Aava Platformin tietokanta on vaihdettavissa mihin tahansa JDBC-rajapintaa tukevaan tietokantaan, kuten esimerkiksi PostgreSQL:n, tarpeen niin vaatiessa. Aava Platformissa hyödynnetään mallipohjaista kehitystä, eli UML-kielen versiolla 1.4 määritetyistä kuvaajista tuotetaan suoritettavaa lähdekoodia. UML mallien hallinnoimiseen käytetään avoimen lähdekoodin ohjelmistoa ja koodin tuottamiseen kyseiseen ohjelmistoon kehitettyä laajennusta. Tässä tapauksessa riskit liittyvät siihen missä sisäisessä tietoformaatissa kyseinen työkalu UMLmallit tallentaa ja siihen kuinka tiukasti mallista lähdekoodin tuottava laajennus on integroitu kyseiseen UML-sovellukseen. UML:ssa kuvauksiin käytettävä esittämistapa on standardisoitu, mutta työkalujen tallentamisessa käyttämä formaatti ei ole aina välttämättä standardin mukainen. Tällöin mallien siirtäminen työkalusta toiseen hankaloituu. Kuitenkaan Aava Ohjelmistojen tapauksessa tallennusformaatti ei ole ongelma, koska UML työkalu on yhteensopiva OMG:n [ UML-tallennusformaattimäärityksien kanssa. Myöskään lähdekoodia tuottavan laajennuksen siirtäminen toiseen työkaluun ei ole iso ongelma, koska alkuperäinen laajennus on pyritty toteuttamaan niin että sen logiikka on mahdollisimman irrallaan UML työkalusta. Memcached on päivittäisessä operatiivisessa toiminnassa useilla isoilla toimijoilla kuten Youtube, Wikipedia, Flickr, Digg ja Twitter [ Tällä perusteella sen voidaan todeta olevan luotettava ja suorituskykyinen komponentti. Myöskään vaihdettavuuden osalta riskiä ei ole, koska Aava Ohjelmistot voi halutessaan siirtyä käyttämään esim. käyttömuistipohjaista tilatiedonhallintaa (mahdollista aiemmissa Aava Platformin versioissa). Jettyn kannalta luotettavuus ei ole niin olennaista koska se voidaan vaihtaa helposti mihin tahansa muista vastaavista sovelluspalvelimista (esim. Tomcat). Vaihdettavuuden mahdollistaa standardisoitu Java Servlet-teknologia.

12 12 (26) Apache:n on tällä hetkellä maailman eniten käytetty web-palvelin, joten sen tulevaisuuden näkymien osalta riski on olematon. Apache on myös helposti irrotettavissa ja korvattavissa toisella web-palvelimella. Solr perustuu Apache Lucene hakukoneeseen (ensijulkaisu 2000). Myös Solr:lla on pitkä historia, sen kehitys aloitettiin jo Monet kävijämääriltään suuret ja sisällöltään laajat sivustot käyttävät Solria hakukoneenaan (esim. digg ja SourceForge) [ 3.3 Järjestelmän suorituskyky ja luotettavuus Järjestelmän hajauttaminen useammalle palvelimelle (klusterointi) on mahdollista järjestelmäarkkitehtuurin perusteella. Hajauttamista suunnitellessa on oletettu että tietokannan hajauttaminen useammalle palvelimelle on mahdollista, eli käytetyn tietokantaohjelmiston tulee tukea tätä ominaisuutta (MySQL:ssä tuettu). Lisäksi varsinaisen palvelinohjelmiston hajauttamisen usealle palvelimelle mahdollistaa sen tilattomuus (Memcached). Hajautuksessa järjestelmän kyvykkyys palvella tapahtumia sekunnissa lisääntyisi teoriassa lähes lineaarisesti palvelimia lisäämällä. Kuitenkin siirryttäessä yhden palvelimen kokoonpanosta esim. kahteen palvelimeen kasvu ei ole aivan lineaarinen, koska komponenttien (MySQL, Memcached, Solr) hajauttaminen heikentää suorituskykyä aluksi muutamia prosentteja (verrattuna lineaariseen kasvuun). Lisäksi hajautuksen ajatuksena on, että lisättävät palvelimet eivät ole suorituskyvyltään huipputasoa vaan vastaavasti voidaan käyttää useita halpoja palvelimia, millä tähdätään kustannustehokkuuteen. Tällaisen palvelimen suorituskyvyksi Aava Ohjelmistot arvioi n. 100 tapahtumaa sekunnissa. Konkreettisesti tämä voisi tarkoittaa esim. seuraavaa: jos yksittäinen käyttäjä tekee palvelupyynnön keskimäärin kymmenen sekunnin välein, tällöin palvelin joka kykenee palvelemaan sata pyyntöä sekunnissa voi hoitaa tuhat yhtäaikaista käyttäjää. Järjestelmän suorituskyvyksi Aava Ohjelmistojen mittausten perusteella esitettiin n. kahdeksan tapahtumaa sekunnissa modernia prosessoriydintä kohden. Keskimääräinen vasteaika yksittäiselle kyselylle järjestelmässä on n. 150ms. Myöskään tiedon määrän lisääminen järjestelmään ei vaikuta oleellisesti sen suorituskykyyn tai toimintaan. Demonstraatiossa järjestelmään oli tallennettu n erilaista tietoalkiota joiden joukosta seulottiin hakuparametrein 1200 alkiota niin, että järjestelmä palautti alkiot joutuisasti. Järjestelmässä on otettu huomioon luotettavuus ja saavutettavuus mm. arkkitehtuuria suunnitellessa ja erityisesti ohjelmistokomponentteja valitessa. Kaikki merkittävimmät järjestelmän komponentit (RoR, Memcached, MySQL) voidaan hajauttaa useammalle palvelimelle. Sovelluspalvelimia lisäämällä voidaan kasvattaa tulevien tapahtumien käsittelykapasiteettia, mutta myös vastaavasti parantaa kokonaisjärjestelmän vikasietoisuutta. Esimerkiksi tilanteessa jossa jokin järjestelmän yksittäinen sovelluspalvelin (RoR) vikaantuu, järjestelmän toiminta ei pysyvästi häiriinny, koska kuormansäädin reitittää jo allokoidut pyynnöt uudelleen seuraavalle toimivalle palvelimelle ja kokonaisjärjestelmän toiminta palautuu normaaliksi. Tällöin myös Memcached:n käyttö takaa sen, että käyttäjäkohtainen tilatieto on ajan tasalla. Kuormansäätimen vioittumiseen voidaan varautua kuormansäädinklusterilla jossa toinen

13 13 (26) kuormansäädin on aktiivinen ja toinen on varalla. Memcached:n häiriötapauksessa kokonaisjärjestelmä lakkaa tällä hetkellä toimimasta, mutta ottaen huomioon Memcached:n luotettavuuden riskin voidaan arvioida olevan hyvin pieni. Mikäli riski kuitenkin realisoituu, Aava Platformissa voidaan siirtyä pienin muutoksin käyttämään käyttömuistipohjaista tilatiedon hallintaa. Memcached:n hajauttamisella voidaan hallita aiempaa suurempia määriä ajonaikaista tilatietoa, ja vastaavasti useampia käyttäjiä. Vastaavasti tietokannan, eli MySQL:n, hajauttamisella voidaan eliminoida tilanne jossa yksittäinen tietokantapalvelin muodostuisi suorituskyvyn kannalta pullonkaulaksi järjestelmässä. Tietokannan hajauttamisella voidaan myös replikoida järjestelmään tallennetut tiedot jolloin luotettavuus paranee. 3.4 Käytettävyys ja toiminnallisuus Tässä kappaleessa esitellään Aava Platformista löytyviä toiminnallisuuksia ja tarkastellaan Aava Platformin käytettävyyttä. Tiedon kohdentamiseen eri sidos- ja kohderyhmille Aava Platform tarjoaa erittäin yksityiskohtaisella tasolla määriteltävät käyttöoikeudet. Käyttöoikeuksiin liittyen on mahdollista määrittää esimerkiksi ylätasolla kuka saa käyttää vaikkapa Customer Relations Management (CRM) liittyviä toimintoja tai tarkemmalla tasolla oikeudet minkä tahansa tietoalkion tietyn kentän näkemiseen ja muokkaamiseen. Pakollisia kenttäkohtaisia tarkistuksia ei Aava Platformissa ole sen suunnittelufilosofian mukaisesti, mutta tarkistuksia on mahdollista lisätä joustavasti asiakkaan pyynnöstä. Kansainvälisyys on tuettu niin, että järjestelmään voidaan kuvata esim. eri maissa käytetyt yksiköt (valuutat, paino, ym.). Myös ohjelmistossa käytetty kieli on mahdollista vaihtaa. Tiedon tuomiseen ja viemiseen on Aava Platformissa monipuolinen tuki. Näissä rajapinnoissa kyetään käyttämään useita eri yhteysteknologioita, mm. SOAP, FTP ja Web Services (WS) ja tiedostoissa esim. XLS ja CSV formaatit. Monipuolinen yhteysteknologioiden ja tiedostoformaattien tuki Aava Platformissa mahdollistuu mm. RoR:n ja Javan kautta. Varsinaisia ennalta määriteltyjä rajapintoja Aava Platformissa ei ole, Aava ohjelmistojen mukaan Aava Platformin arkkitehtuuri mahdollistaa rajapintojen ja integraatioiden tekemisen ulkoisiin järjestelmiin tarvittaessa helposti. Käytännössä integraatiot voivat käyttää samaa HTTPrajapintaa kuin käyttöliittymäkin, eli ottaa vastaan SOAP tai HTTP POST muotoista dataa ja palauttaa sitä esimerkiksi HTTP, XML/SOAP tai JSON muodossa. Etuna integraatioita suunnitellessa on siis Aava Platformin joustavuus ja sen yleiskäyttöinen rakenne. Järjestelmään tehtäviä migraatioita, eli tiedon siirtämistä järjestelmästä tai järjestelmän versiosta toiseen, varten Aava Platformissa on olemassa määrättyjä apuluokkia, mutta käytännössä tarvittavat mekanismit on ohjelmoitava tapauskohtaisesti. Migraatioita on suoritettu Aava platformia käyttäville asiakkaille. Myös Aava Platformin integrointi ulkoiseen järjestelmään, käyttäen uutta ehostettua vientirajapintaa, oli raporttia kirjoitettaessa meneillään. Vanhojen rajapintojen kautta integraatioita on tehty mm. Benjonin tekijänoikeustietokantaan.

14 14 (26) Käyttöliittymä on pyritty suunnittelemaan olemassa olevia standardeja käyttäen niin, että sitä pystytään helposti ja nopeasti muokkaamaan. Käytännössä tämä on toteutettu pyrkimällä teknisesti laadukkaaseen toteutukseen ja esim. huomiomaan kaikkialla (mm. näkymät) ohjelmistossa että tarvittavat muutokset ulkonäköön voidaan suorittaa tyylitiedostoja (Cascading Style Sheets) muokkaamalla. Käyttöliittymän muokkausoperaatiot voivat olla esim. väriteeman hallintaa tai käyttöliittymän muokkaamista eri resoluution terminaaleille. Myös selaimien yleiset toiminnallisuudet kuten palaaminen edelliselle sivulle tai lähentäminen toimivat normaaliin tapaan. Käyttöliittymä on myös pyritty suunnittelemaan intuitiiviseksi, mikä tarkoittaa sitä että esimerkiksi samantapaiset toiminnot löytyvät aina samasta paikasta, eikä nappuloita joudu etsimään sivun alalaidasta tai muista piiloista. Käyttäjät pystyvät myös vaikuttamaan siihen miltä käyttöliittymä heille näyttää. Käyttöliittymässä olevia eri näkymiä ja ikkunoita ja kenttiä käyttäjät pystyvät siirtelemään hyvinkin vapaasti mieleiseensä järjestykseen. Myös käyttäjän kannalta turhat kentät voidaan piilottaa järjestelmästä häntä hämäämästä. Edellä mainittuja kentän piilotuksia voidaan myös suorittaa käyttäjäryhmäkohtaisesti, tai vaikkapa tiettyyn näkymään liittyen pakotetusti tietohallinnon toimesta. Raportteja on mahdollista luoda joustavasti valitsemalla raporttiin sisällytettävät sarakkeet ja rivit käyttöliittymästä. Valinnan lisäksi voidaan suorittaa tiedon rajausta erilaisilla hakusanoilla ja operaattoreilla. Myös monipuolinen tiedon järjestäminen on mahdollista. Aava Platformin ehdoton vahvuus on sen tarjoamat joustavat ja monipuoliset mahdollisuudet tiedon visualisoinnin ja analysoinnin tukeen. Esimerkiksi pudotusvalikosta tietyn tietoalkion valitseminen on helppoa myös suuren tietomäärän joukosta, koska tähän tarkoitukseen on olemassa widget joka mahdollistaa tiedon seulonnan hakusanalla. Ohjelmistoon on evaluoinnin aikana lisätty uutena toiminnallisuutena tabit tarkoituksena helpottaa tiedon käsittelyä. Tabien ajatuksena on mahdollistaa henkilökohtaisten näkymien tallentaminen. Esimerkkinä näkymästä voisi olla sivu jolle on listattu työntekijät ja työntekijöihin liittyvät attribuutit (esim. etunimi, sukunimi, ikä). Myös listattavien tietoalkioiden (tässä tapauksessa työntekijät) järjestely näkymään jonkin määritellyn kriteerin perusteella on mahdollista. Toisena esimerkkinä voisi olla vaikka laskuluettelo, jossa on eri näkymissä maksetut, maksamattomat ja myöhässä olevat laskut. Jokaisessa näkymässä voisi olla eri kentät näkyvissä, esim. maksetuissa on näkyvissä maksupäivä ja maksusekä eräpäivän erotus kun maksamattomissa näkyy pelkkä eräpäivä. Määrittelyt näkymään käyttäjä voi tehdä yksinkertaisesti käyttöliittymästä piilottamalla tai ottamalla käyttöön haluamansa kentät ja määrittelemällä sopivat haku- ja järjestelykriteerit. Suunniteltuja uusia ominaisuuksia: Asiakkaan kanssa pidetyssä tuotteen esittelytilaisuudessa tuli esille joitakin järjestelmään suunnitteilla olevia kehityskohteita. Kyseiset kehityskohteet on listattu alle. Nämä ovat myös arvioijien mielestä hyödyllisiä kehityskohteita, etenkin break down raporttien, muutoshistorian ja hälytysten osalta. Esimerkiksi muutoshistorian implementointi mahdollistaa minkä tahansa kentän arvon

15 15 (26) vaihtamisen aikaisempaan versioonsa (esim. tuotekuvauksen palauttamisen virhetilanteessa). - Ns. break down, eli erittelyraportit. Näissä raporteissa luodaan graafinen esitys datasta valittujen sarakkeiden (esim. vuosi, tuotot) perusteella. - Muutoshistoriaominaisuus järjestelmään tallennetuille objekteille. Muutoshistoria mahdollistaa jokaiselle alkiolle ja sen attribuuteille suoritettujen muutosten ylläpidon ja tarkastelun. - Hälytykset. Järjestelmä varoittaa käyttäjää mikäli jokin tapauskohtaisesti seurattavaksi asetettu raja-arvo on ylittynyt tai tietyn tapahtuman yhteydessä, esim. kun myyntitilaus hyväksytään tuotantoon, järjestelmään lisätään uusi henkilö, tuote poistetaan järjestelmästä, jne. - Käyttäjää kouluttava toiminto, eli järjestelmä tarjoaa käyttäjälle hänen osaamisen tasoansa (esim. aloittelija, kehittynyt käyttäjä) vastaavan käyttöliittymän. Ja kun käyttäjästä alkaa tuntua siltä että hän tarvitsee kehittyneempiä toimintoja, hän voi itsenäisesti siirtyä käyttämään vaativampaa käyttöliittymää. 3.5 Tuotekehitysprosessi Uuden tuotteen kehitys aloitetaan järjestämällä työpaja asiakkaan kanssa. Tässä työpajassa keskustellaan asiakkaan termeillä asiakkaan tarpeista eikä puhuta teknisistä asioista. Työpajassa asiakas kertoo miten hän tekee nyt kohteena olevan toiminnon ja mikä siinä on mahdollisesti ongelmana, eli käydään läpi asiakkaan prosessi käyttäen asiakkaan termejä. Työpajaan osallistuu ohjelmoija sekä tekninen henkilö joka osaa keskustella asiakkaan kanssa. Monimutkaisemmissa tapauksissa, kuten esimerkiksi tuotannonohjausjärjestelmän määrittelyssä, järjestetään työpaja jossa käydään eri näkökulmista ihmisten työtä läpi. Tällainen työpaja kestää yleensä koko päivän, mutta yksinkertaisemmissa tapauksissa, kuten vaikkapa CRM-järjestelmän määrittelyssä, työpaja saattaa kestää pari tuntia. Työpajan jälkeen Aava Ohjelmistojen henkilöt suunnittelevat ja toteuttavat järjestelmän prototyypin. Järjestelmän koosta riippuen prototyyppi voidaan toimittaa asiakkaalle työpajaa seuraavina päivinä (keskimäärin kolmesta viiteen päivään, mutta isommassa tapauksessa voi mennä pidempäänkin). Prototyyppi testataan ensin Aava Ohjelmistojen toimesta, tarkoituksena varmentaa että perusasiat toimivat. Testaus tehdään lähinnä käyttöliittymän kautta: olemassa oleva skripti käy läpi perusrakenteet ja tämän jälkeen testataan käyttöliittymän kautta käsin prosessit joita asiakkaan on tarkoitus käyttää. Kun perustoiminnallisuus on varmennettu, prototyyppi toimitetaan asiakkaalle (esim. järjestämällä asiakkaalle pääsy testikoneelle). Prototyyppiä esitellään lyhyesti asiakkaalle käymällä läpi perusperiaatteet. Esittelyn jälkeen asiakas kokeilee prototyyppiä n. kaksi viikkoa ja voi tällöin myös tutustua käyttöön perehdyttäviin videoihin Aavan Internet-sivuilla. Kokeilun aikana asiakas kirjaa kaikki havaintonsa järjestelmästä, jonka jälkeen järjestetään uusi työpaja jossa havainnot käydään läpi. Viesti asiakkaalle kokeilun alkaessa on, että järjestelmän

16 16 (26) käytössä ei tarvitse olla varovainen, vaan voi rohkeasti kokeilla toimintoja (vakuutetaan että käyttäjän ei ole mahdollista rikkoa järjestelmää). Toisen työpajan jälkeen järjestelmään tehdään tarvittavat muutokset minkä jälkeen järjestelmä toimitetaan tuotantokäyttöön. Aava Platformin asennus on nopeaa (muutamia minuutteja), sen jälkeen kun ympäristö pystytetty Testaus ja vikojen hallinta Aava Platformin toimintaa testataan verifioimalla linkkien toiminta ja tarkkailemalla järjestelmän muistin, säikeiden ym. käyttäytymistä. Varsinainen toiminnallisuuden oikeellisuus tarkastetaan manuaalisesti käymällä järjestelmää läpi tietyiltä osin käyttöliittymän kautta. Lisäksi Aava Platform on Aava ohjelmistojen sisäisessä käytössä, jolloin toimintaa myös testataan. Uudet ominaisuudet tuodaan ensin omassa käytössä olevaan järjestelmään, jolloin mahdolliset viat löydetään ennen asiakkaille toimitusta. Asiakaskohtaisten räätälöintien vaikutus järjestelmään on rajallinen, minkä johdosta testaaminen yksinkertaistuu. Asiakaskohtaisissa räätälöinneissä testataan vain ne kohdat joihin muutoksia on tehty. Räätälöinnit koostuvat pääasiassa asiakaskohtaisista objekteista ja attribuuteista, widgeteistä, prosesseista ja käyttöliittymistä. Nämä kaikki kyetään hallitsemaan manuaalisen testauksen kautta. Varsinaiseen Platformiin myöhemmin tehtävät muutokset eivät vaikuta mihinkään yllämainituista asioista johtuen välissä olevasta abstraktiotasosta. Vikojen raportointi toimii tällä hetkellä suoraan järjestelmän kehittäjään (puhelimella tai sähköpostitse), mutta jatkossa on tarkoitus tehdä vikojenhallinta ja raportointi Aava Platformilla. Myös parannukset (feature request) on tarkoitus tallentaa järjestelmään Versionhallinta Versionhallinnassa on käytössä Subversion ohjelmisto. Tuotekehityksessä on käytössä kolme haaraa (branch): kehityshaara (development branch), jossa kehityksen alla oleva versio, testaushaara (testing branch), jota testataan ja kokeillaan mm. omassa käytössä, sekä tuotantohaara (production branch), josta asiakkaan versiot tehdään.. Lisäksi ohjelmiston päivitys asiakkaille hoidetaan samasta haarasta. Myös asiakaskohtaisesti räätälöidyt Aava Platformit on tallennettu versionhallintaan. Edellä mainittua Aava Ohjelmistot kutsuu versiottomaksi järjestelmäksi, mikä tarkoittaa sitä että järjestelmästä on olemassa yksi perusversio josta tehdään asiakastoimitukset ja asiakaskohtaiset räätälöinnit on eristetty. Jokaisella asiakkaalla on versionhallinnassa oma haara, joka otetaan ulos (check out) asennuksen instanssit (instances) hakemistoon (eli jokaisen asennuksen yhteydessä tehdään kaksi check outtia: platform ja asiakaskohtainen instanssi). Platformista on aina vain yksi versio, joka on yhteensopiva kaikkien instanssien kanssa. Asiakaskohtaiset räätälöinnit hallitaan erillään platformista, näin voidaan myös päivittää tarvittaessa vain toista, asiakaskohtaisia räätälöintejä tai platformia.

17 17 (26) 3.6 Muutosten hallinta ja ylläpidettävyys Aava Platform on pyritty suunnittelemaan hyvin yleiskäyttöiseksi. Yleiskäyttöisyys tässä tarkoittaa sitä, että järjestelmällä pystytään teoriassa hallitsemaan minkälaista tietoa tahansa. Karkealla tasolla hallinnoilla tarkoitetaan tiedon lisäämistä, poistamista, hakemista, muokkaamista, julkaisemista, ja analysointia. Kaikki alkiot Aava Platformissa periytetään samasta luokasta, jossa on määritelty järjestelmän yleisluontoisuuden kannalta oleellisia asioita, käyttäen Rubyn mixin-menetelmää. Yksi kyseisessä luokassa määritelty seikka on esimerkiksi järjestelmässä esiintyvien objektien puurakenne, mikä mahdollistaa käytännössä varsin monipuoliset tietorakenteet. Työnkulkujen (workflow) määritykset Aava Platformissa kuvataan tilakoneina UML:lla, joista tuotetaan lähdekoodia. Työnkulkuihin voidaan tilasiirtymien yhteyteen lisätä automatisoituja toimintoja tuotettua lähdekoodia muokkaamalla. UML mallissa voidaan myös määritellä tilasiirtymän myötä synnytettävät uudet objektit, esimerkiksi kun myyntitilauksessa kutsutaan hyväksy-tapahtumaa, niin järjestelmä synnyttää ohjautuvuuksien sekä muiden sääntöjen perusteella tarvittavat tuotanto- tai ostotilaukset, varastovaraukset ja muut objektit joita malliin on määritelty. Objekteihin voi liittyä useita työnkulkuja, ja tilasiirtymissä on mahdollista vaikuttaa myös järjestelmän muihin työnkulkuihin tarpeen niin vaatiessa (esim. tilauksen varmistaminen käynnistää toimitusprosessin). Työnkulkujen määrityksen ohella järjestelmään mallinnetaan UML:lla luokkina tarvittavat objektit, objektien attribuutit sekä relaatiot muihin objekteihin. Edellä mainituista kuvauksista tuotetaan järjestelmään lähdekoodia ja tietokantamallit. Näin saadaan aikaan jo pääosin toimiva yritys-logiikka, jota voidaan räätälöidä asiakkaalle paremmin sopivaksi. Räätälöity koodi sijaitsee erillisissä tiedostoissa, joten tuotettuun koodin ei koskaan tehdä käsin muutoksia, vaan sitä laajennetaan ja/tai muokataan Ruby-ohjelmointikielen metaohjelmointimenetelmillä. Aava Platformin workflow-moottori voidaan kytkeä tarvittaessa ulkoisiin järjestelmiin, mikä mahdollistaa prosessikuvauksissa ulkoisiin järjestelmiin liittyvien signaalien käsittelyn. Toimivan järjestelmän tuottamista mallipohjaisesti tuottamalla esiteltiin työpajassa, ja menetelmä vaikuttaa käytännössä tehokkaalta ja nopealta tavalta tuottaa asiakaskohtaisia räätälöintejä Aava Platformista. Olemassa olevilla työnkulun mekanismeilla pitäisi olla Aava Ohjelmistojen mukaan mahdollista kuvata tuotannonohjausjärjestelmissä kaikki yleisesti käytetyt prosessit. Työnkulkujen ja objektien lisäksi järjestelmässä tulee olla näkymiä joista järjestelmää voidaan käyttää. Järjestelmässä olemassa olevat näkymät on lähtökohtaisesti suunniteltu niin, että ne käsittävät suurimman osan mahdollisista tilanteista. Nämä yleiskäyttöiset näkymät hyödyntävät UML-malleissa määriteltyjä luokkakohtaisia attribuutteja, millä tarkoitetaan sitä, että jos näkymän tarkoituksena olisi näyttää asiakkaan tiedot, niin nämä kentät (attribuutit) otettaisiin kyseisen UML-mallin asiakas luokasta. Kuitenkin näkymät ovat tavallaan luokkariippumattomia, eli yhdessä näkymässä voi olla tietoja useista luokista, koska järjestelmän tekninen rakenne ja käyttäjien työn kannalta oleellinen rakenne eivät useinkaan vastaa toisiaan. Esimerkiksi yrityslistassa voi olla yhdessä sarakkeessa yritykseen liittyvät henkilöt tai tapahtumat, jotka molemmat ovat yrityksen assosiaatioita ja kyseisissä kentissä olevat tiedot ovat

18 18 (26) niiden assosiaatioiden dataa. Edellä mainitulla mekanismilla on pyritty vähentämään erilaisten näkymien tuottamiseen tarvittavaa työmäärää sekä helpottamaan järjestelmän käyttöä, koska näin kaikki oleellinen tieto saadaan samaan näkymään. Uusia toiminnallisuuksia Aava Platformiin voidaan lisätä pudottamalla (käsitteellisiä) moduuleita järjestelmään. Uusien ominaisuuksien lisääminen jo tuotannossa olevana järjestelmään on pyritty suunnittelemaan niin että se käy mahdollisimman vaivattomasti, vaikuttamatta järjestelmässä jo olemassa oleviin tietoihin. Käytännössä toiminnallisuuksia muokataan käsittelemällä järjestelmän tietorakenteita, eli Aavan tapauksessa konfiguraatioita. Mitään varsinaisia moduuleita ei siis ole, vaan esim. CRM tapauksessa moduuli koostuisi perusobjektien (yritys, henkilö) lisäksi kolmesta uudesta objektista: mahdollisuudet, tapahtumat ja tehtävät. Lisäksi järjestelmä on pyritty suunnittelemaan niin, että ei pääse syntymään tilannetta jossa loogiset moduulit (esim. asiakkuuksienhallinta ja laskutus) ovat sellaisessa riippuvuussuhteessa keskenään, jossa toisen moduulin päivityksen yhteydessä toinen moduuli rikkoutuu. Aava ohjelmistojen mukaan tämä onnistuu koska teknisesti ei ole olemassa erillisiä moduuleita vaan kaikilla toiminnallisuuksilla on käytössä sama lähdekoodi. Myös järjestelmässä käytössä olevat toiminnallisuudet voidaan säätää hyvinkin yksityiskohtaisesti, joten päivityksien johdosta järjestelmään ei tule asiakkaan kannalta turhia ominaisuuksia. Järjestelmän keskeisiin ohjelmistokomponentteihin ei ole Aava ohjelmistojen mukaan tehty isoja muutoksia aikoihin, mitä voidaan pitää eräänlaisena indikaattorina järjestelmän kypsyydestä. Myös pelkästään lähdekoodin määrää tarkastelemalla järjestelmä vaikuttaa hyvin hallittavalta, sillä ohjelmistokoodia järjestelmän ytimessä on n riviä. Mikäli lähdekoodiin määrään luetaan lisäksi näkymien tuottamiseen tarvittavat ohjelmistokomponentit, on koodirivien lukumäärä tällöin huomattavasti suurempi. Aava Platformin yleisluontoisuudesta ja sen toteuttamiseen vaadittavan lähdekoodin rakenteesta johtuen lähdekoodin käsittämisessä saattaa olla aluksi pieni kynnys Aava Platformiin harjaantumattomalle sovelluskehittäjälle. Lisäksi kommentteja ja muuta dokumentaatiota lähdekoodissa on melko vähän. Suurin haaste kehittäjille on kuitenkin geneerisyyteen vaadittavan ajattelutavan omaksuminen ja sen toteuttamiseen vaadittavien metaohjelmointimenetelmien hallitseminen. Edellä mainituista seikoista huolimatta näyttää kuitenkin siltä, että myös uudet kehittäjät ovat kyenneet omaksumaan järjestelmän ja sen kehitysfilosofian, koska demonstraatiotilaisuudessa esiteltiin myös näiden kehittäjien työn tuloksia. Lisäksi peruskehittäjiltä, jotka luovat sovelluksia järjestelmän päälle, ei vaadita syvällistä ymmärrystä järjestelmän metamallista. Ylläpidettävyyteen täytyy kuitenkin kehittäjien määrän kasvaessa kiinnittää huomiota. Ylläpidettävyyden takaamiseksi Aava Ohjelmistoilla olikin ajatus, että Aava Platformin ytimen kehitys rajattaisiin pienemmän, kokeneen joukon tehtäväksi. 3.7 Järjestelmän räätälöinti Aava Platform koostuu loogisesti ns. ydinosuudesta mikä toteuttaa yleiskäyttöisyyteen vaadittavat tukitoiminnot sekä ohjelmiston rungon. Lisäksi Aava Platform koostuu asiakaskohtaisista laajennuksista, jotka toteuttavat tiettyjä toiminnallisuuksia Aava Platformin yleiskäyttöisyyttä hyväksikäyttäen (esim. asiakastietojen hallinta eli CRM).

19 19 (26) Lähdekoodin tuottamisen jälkeen UML-kuvauksesta saadaan toimiva järjestelmä (ydinosuus ja asiakaskohtaiset laajennukset), mutta joskus järjestelmää joudutaan räätälöimään. Räätälöinnit ovat tarpeen esim. tilanteissa joissa tarvitaan monimutkaisempia, jotain logiikkaa sisältäviä attribuutteja. Tällaiset muokkaukset ovat usein käsin tehtäviä. Esim. tilausrivin hinta yhteensä laskukaava lisätään räätälöintiluokkaan: class OrderItem; def total_price; price* quantity; end; end;. Myös erikoistuneet käyttöliittymäwidgetit joudutaan tekemään käsin, esim. widgetti joka näyttää ravintoarvot tuotteelle, kun kyseessä on elintarvike. Järjestelmään tehtävät muokkaukset voidaan eristää. Eristys onnistuu Ruby ohjelmointikielessä ylikirjoittamalla luokat. Luokkia voidaan ylikirjoittaa tai laajentaa, eli lisätä niihin metodeita. Myös luokkien metodien ylikirjoittaminen tai laajentaminen on mahdollista. Edellä mainitut muokkaukset, ylikirjoittamiset ym. tallennetaan omaan hakemistoonsa ylläpidon helpottamiseksi. Mikäli asiakas tarvitsee esim. räätälöidyn näkymän johonkin tiettyyn tilanteeseen, tällaisen näkymän luominen on mahdollista. Näkymän räätälöinnissä tehtävä työ on manuaalista koodaamista, mutta räätälöintiä voidaan helpottaa hyväksikäyttämällä jo olemassa olevia näkymiä sekä RoR:n menetelmiä. Räätälöintityönä voitaisiin tehdä esimerkiksi erillinen sivusto varastonhallinnan näkökulmasta ja vastaavasti asiakkaille verkkokaupan näkökulmasta. Molemmat sivustot käyttäisivät tässä tapauksessa sovelluksen olemassa olevia rakenteita, jolloin Aava Ohjelmistojen mukaan tarvittava työmäärä on kohtuullisen pieni (90% Aava Platformia, 10% räätälöintiä), koska voidaan käyttää Aava Platformia ja sen tietorakenteita, hakumekanismeja ym. Asiakaskohtaisten räätälöintien rikkoutuminen päivityksen yhteydessä vältetään Aava Platformissa sen versiottomalla järjestelmällä. Eli järjestelmästä on olemassa yksi perusversio josta asiakastoimitukset tehdään, ja asiakaskohtaiset räätälöinnit on eristetty. Päivitykset pyritään suunnittelemaan niin, että asiakaskohtaiset räätälöinnit eivät rikkoudu. Aava Ohjelmistojen kanta asiakkaan omiin räätälöinteihin on se, että ne ovat periaatteessa sallittuja ja järjestelmää kehitetään siihen suuntaan (ns. developer lisenssi), että tätä voidaan tukea paremmin. Toimintaperiaatteena on myös kaikenlainen tiettyyn toimittajaan lukitsemiseen tähtäävän toiminnan ja pakkomyynnin välttäminen. Mikäli asiakaskohtaiset räätälöinnit jotka on tehty Aava Ohjelmistojen toimesta rikkoutuvat esim. Aava Platformin päivityksestä, asia korjataan. Mikäli kyseessä on asiakkaan itse suorittama räätälöinti, menetellään tapauskohtaisesti. Tulevaisuudessa on myös tarkoitus ohjeistaa asiakkaita siitä mitä räätälöintejä suositellaan asiakkaan itse tehtäviksi. 3.8 Liiketoiminta-ajatus ja tuotekonsepti Aava ohjelmistojen toiminta perustuu Aava Platformin kehittämiseen ja sen muokkaamiseen erilaisiin asiakastarpeisiin. Aava Platformissa hyödynnetään voimakkaasti avoimen lähdekoodin ohjelmistokomponentteja. Aava Platform soveltuu moneen erilaiseen käyttötarkoitukseen, joten kohdemarkkinoita ei ole järkevää rajata. Pääasialliset toiminta-alueet ovat kuitenkin yritysten

20 20 (26) toiminnanohjausjärjestelmät (ERP) ja niiden osat (esim. CRM), julkaisu- ja sisällönhallintajärjestelmät (content management), sekä yritysten omat spesifiset tiedon hallintaan liittyvät ongelmat. Asiakkaille tehtävien ominaisuuksien hinnoittelu (mm. tarvittava työmäärä) voi olla haastavaa, mutta sama tilanne on muillakin toimijoilla ja toimitusten määrän kasvaessa myös kokemus ja sitä kautta arvioiden tarkkuus kehittyy. Järjestelmän ylläpitolisenssi on 20 % varsinaisen järjestelmän lisenssin hinnasta. Ylläpitolisenssin piiriin kuuluvat muut kuin asiakaskohtaiset lisätoiminnallisuudet. Käytännössä asiakkaat saavat ylläpitolisenssillä kaikki uudet ominaisuudet (esim. tabit) joita järjestelmään kehitetään. Asiakkaan itse tekemät räätälöinnit eivät kuulu ylläpitolisenssin piiriin, vaan asiakkaan vastuulla on päivittää tällaiset muutokset ajan tasalle. Erillinen kehittäjä-lisenssi käyttäjille on myös mahdollinen. Nykyisellään ylläpidon piiriin kuuluvat asiat määritellään tapauskohtaisesti sopimuksessa. Aava Platformin asentaminen suositellaan hoidettavaksi niin, että asiakas omistaa lisenssin ja palvelimen. Asiakas voi ajaa ohjelmistoa omalla palvelimellansa, tai vaihtoehtoisesti missä tahansa hosting-palvelussa, jolloin asiakas maksaa lisäksi palvelusta. Software as a Service (SaaS) mallin tukeminen ei ole suunnitelmissa. mutta asiakkaalle voidaan järjestää vastaava konsepti ulkopuolisen rahoituksen, virtuaalipalvelimen ja täyden ylläpitosopimuksen kautta. Tällöin asiakas saavuttaa useimmat SaaS-mallin hyödyt mutta riskit ovat pienempiä. Tällä hetkellä asiakkaiden asennukset ovat pääosin virtuaalikoneilla. Toisaalta platformia voidaan kyllä käyttää kolmansien osapuolten Saas konseptin pohjana (kolmas osapuoli voi rakentaa SaaS-mallilla toimivaa liiketoimintakonseptia Aavan päälle) Aava Platform verrattuna perinteiseen ERP projektiin Nykyisiin ERP ratkaisuihin ja niiden käyttöönottoon liittyy tunnettuja ongelmia, joihin Aava Platform tarjoaa vastauksia ja omaa täten kilpailuedun muihin tuotteisiin nähden. Taulukko 1. Perinteisten ERP projektien haasteet vs. Aava Ohjelmistojen toiminta Perinteinen ERP Raskas ja kankea määrittelyvaihe, joka huonosti tehtynä usein pilaa koko projektin ERP ei sovi yhteen yrityksen omien liiketoimintaprosessien kanssa Aava Ohjelmistot & Platform Aava Ohjelmistojen tuotekehitysprosessin selkeä vahvuus on asiakkaan näkökulman mukaanotto sekä tuotteen määritysvaiheessa, että käyttöönoton tuessa. Aava Platformin geneerisyys mahdollistaa asiakaskohtaisten ominaisuuksien rakentamisen ja niiden ylläpidon helposti, joten asiakkaan tarpeiden määritys ja niiden varmistaminen tehdään prototyyppien avulla Aava Platform luodaan asiakkaan tarpeeseen eli järjestelmä mukautuu asiakkaaseen eikä asiakas järjestelmään. Prosessit luodaan vastaamaan asiakkaan tapaa tehdä asiat.

21 21 (26) Perinteinen ERP Projektin kesto (ajallisesti) Kustannukset nousevat odotettua suuremmaksi Ongelmat yhteistyökumppaneiden kanssa (ongelmat ERP järjestelmien toimittajien kanssa johtuvat usein osaamisesta sovellusalueeseen tai järjestelmään liittyen) Muutosten aiheuttamat vaikeudet Muutosvastarinta ERP:n ulkopuolelle jäävät usein esimerkiksi CMS (Content Management System), tuotehallinta (PDM, PLCM) tai muut yrityksen toiminnalle spesifiset tarpeet Aava Ohjelmistot & Platform Platformissa panostettu erityisen paljon ja se onkin VTT:n asiantuntijoiden arvion mukaan erittäin hyvä verrattuna kaupallisiin ja avoimen lähdekoodin tuotannonohjausjärjestelmiin joista heillä on kokemuksia. Aava Platformiin tehtävä sovelluskehitys on äärimmäisen nopeaa ja järjestelmä saadaan yleensä asiakkaan käyttöön 2-30 päivässä Aava Ohjelmistojen hinnoittelumalli perustuu tarjouksella annettuun kiinteään kokonaishintaan, joka sisältää kaiken tarvittavan toiminnallisuuden ja palvelut, jotka asiakkaan käytännön ongelman ratkaisemiseen tarvitaan. Aava Ohjelmistot tekee itse järjestelmän räätälöinnin, joten heillä on järjestelmästä paras mahdollinen asiantuntemus. Aava Ohjelmistot tuottaa nopeasti prototyypin asiakkaan kokeiltavaksi ja kokeilun perusteella parannettavaksi, jolloin käyttäjät pääsevät vaikuttamaan tuotteeseen. Aava Platform on suunniteltu tukemaan jatkuvan kehityksen mallia, jolloin järjestelmää voidaan laajentaa ja muokata missä tahansa sen elinkaaren vaiheessa samalla työmäärällä, kuin jos se olisi tehty alkuvaiheessa Aava Platformin helppo käytettävyys ja johdonmukainen käyttölogiikka helpottaa järjestelmän käyttöönottoa ja käyttäjien sitouttamista järjestelmään Aava Platformilla voidaan helposti toteuttaa mikä tahansa tietojärjestelmä yrityksen tarvitsemalla tavalla, joten järjestelmien määrä pienenee tuoden kustannushyötyjä sekä yksinkertaistaen kokonaisuutta Asiakastoimitukset Tuotekonseptin toimivuutta voidaan arvioida mm. asiakkaille toimitettujen tuotteiden kautta. Parhaillaan toimituksessa on täysimittainen ERP-järjestelmä elintarviketeollisuudessa toimivan yrityksen tuotannonohjaukseen. Järjestelmä kattaa myynnin, ostot, varastonhallinnan, tuotannonohjauksen, toimitukset, tuotehallinnan (sisältäen tuote- ja tuotannon rakenteet sekä tuotetiedon hallinnan), asiakkuudenhallinnan, myynnin budjetoinnin sekä muut oleelliset osat pois lukien taloushallinnon. Tähän mennessä asiakkaille on tehty seuraavanlaisia toimituksia:

22 22 (26) Unikulma Unikulman autot ajoivat paljon turhia ajoja, koska toimituksia ei suunniteltu logistisesti järkevästi. Myyjät eivät sänkyjen ja muiden tuotteiden toimituksia luvatessaan tienneet, mitä muissa myymälöissä oli luvattu. Aava Platformin päälle luotiin järjestelmä, joka ohjasi toimitukset määrätyille alueille määrättyinä ajankohtina. Esimerkiksi Etelä-Espooseen maanantaisin kello 8-14, keskiviikkoisin ja perjantaisin Näin asiakas sai edelleen päättää, milloin hän toimituksen halusi, mutta autot eivät pyörineet enää pitkin Suomea, vaan pysyivät pienemmällä alueella. Ensimmäisen vuoden aikana saavutettiin yli 50% säästöt kuljetuskustannuksiin, vähentäen ajoja noin km. Järjestelmä maksoi itsensä takaisin alle kahdessa viikossa. Työkalutuonti Työkalutuonti on keskittynyt laadukkaiden työkalujen tekniseen tukkukauppaan. Perinteisesti asiat oli hoidettu puhelimessa ja faxilla. Nyt haluttiin helpottaa tilaamista ja tarjota enemmän tietoa tuotteista ja yrityksestä. Työkalutuonnille rakennettiin ammattimaiseen ostamiseen suunniteltu tilaus- ja tuotehallintajärjestelmä, jolla kaikki tuotetiedot saatiin yhteen paikkaan asiakkaat pääsevät näkemään tuotetiedot ja tekemään itse tilauksia. Benjon Benjon on keskittynyt immateriaalioikeuksien hallintaan ja valvontaan. Se oli tehostamassa toimintaansa paremmalla tiedon keräämisellä ja hyödyntämisellä, mutta asiakkuuden- ja asiakastiedon hallinta osoittautuivat haasteellisiksi ilman kunnollisia työkaluja. Yritys kokeili muutamaa tunnetuinta asiakkuudenhallintatuotetta, mutta ne eivät taipuneet Benjonin tarpeisiin. Tarvittiin pitkälle räätälöity asiakkuudenhallintajärjestelmä (CRM), joka integroituisi heillä käytössä olevaan tavaramerkkien hallintajärjestelmään sekä yrityksen muihin järjestelmiin. Aava Platformin päälle rakennettiin täysin räätälöity CRM-järjestelmä, joka integroitiin heillä käytössä olevaan tavaramerkkien hallintajärjestelmään ja joka tuki Benjonin tapaa toimia. Laajennettavuus oli tärkeää, jotta jokaiseen uuteen tulevaan tarpeeseen ei tarvitsisi hankkia aina uutta järjestelmää. Muut Sisällönhallinta- ja julkaisujärjestelmä Räätälöity tilausjärjestelmä markkinointimateriaalin julkaisuun ja jakamiseen Nämä toimitukset osoittavat, että Aava Platform on sovellettavissa erilaisiin asiakastarpeisiin toimivaksi Tulevaisuudessa nousevat ominaisuudet Toinen näkökulma tuotekonseptin toimivuuteen on mahdollisesti tulevaisuudessa tärkeiden ominaisuuksien huomiointi. Gartner julkaisee säännöllisesti arvioita tulevista asioista / ominaisuuksista (näitä kutsutaan hype cycleksi). Seuraavassa

23 23 (26) kuvataan, miten Aava platformissa on näitä huomioitu. Tämän pohjalta voidaan arvioida Aava platformin käyttökelpoisuutta myös tulevaisuudessa. Kuva 1. Gartner hype cycle for application architecture (2009) Aava platformissa on huomioitu Gartnerin arvioimia tulevia trendejä (hype cycle) mm. sovellusarkkitehtuurien osalta. Aava mainitsee seuraavat trendit merkittävimpinä huomioituina ominaisuuksina: RIA Rich Client: Aavassa on panostettu erityisen paljon työtä ja aikaa käyttöliittymään, jotta käyttäjän työ helpottuisi ja nopeutuisi. Se hyödyntää laajalti Ajax tekniikkaa ja selaimessa ajettavaa toiminnallisuutta, jolloin käytettävyys paranee ja työn tehokkuus paranee. WEB-Oriented Architecture: Aava perustuu puhtaaseen Web-arkkitehtuuriin, jonka ansiosta sen integroiminen muihin järjestelmiin helpottuu ja joka nykytietämyksen perusteella takaa mahdollisimman pitkän elinkaaren järjestelmälle. Lisäksi Aavassa Web-ajattelu on tuotu niin lähelle, että esimerkiksi täysin räätälöityjen asiakasnäkymien tekeminen on yhtä helppoa, kuin tavallisten Web-sivujen teko. Esimerkiksi järjestelmästä voitaisiin tuottaa yrityksen nettisivuille tosiaikaiset tiedot tuotteista tai tuotannosta lähes samalla kustannuksella, kuin tehtäisiin staattinen sivu yhdestä tuotteesta. Model-Driven Architecture: Aavan järjestelmäarkkitehtuuri perustuu Webpohjaiseen arkkitehtuuriin mutta sen business-logiikka perustuu tietomalliin, joka yleensä tuotetaan UML-työkalulla, johon Aava on tehnyt liitännäisen. Aavan tapauksessa voidaan puhua teknisestä ja loogisesta arkkitehtuurista, joista jälkimmäinen määrittelee sen mitä järjestelmällä voidaan tehdä ja miten se

24 24 (26) ylipäätään toimii. Voidaankin siis sanoa, että Aavan looginen arkkitehtuuri on oikeastaan dynaaminen malli, joka perustuu tehtyyn tietomalliin. Kuva 2. Gartner hype cycle for ERP (2009) Aava platformissa on huomioitu Gartnerin arvioimia tulevia trendejä (hype cycle) mm. ERP järjestelmien osalta. Aava mainitsee seuraavat trendit merkittävimpinä huomioituina ominaisuuksina: Business Process Templates: Aava Platformin prosessimalli perustuu metarakenteisiin, joita voidaan kuvata visuaalisesti esimerkiksi UML-työkalulla. Tällä tavoin järjestelmän toimintalogiikka on itse asiassa kokoelma kaavioita, joista asiakas voi valita jonkun pohjaksi ja muuttaa sitä mielensä mukaan. Kun prosessi on mallinnettu, se ajetaan järjestelmään sisään ja tämänkin jälkeen rakennetta voidaan muuttaa muokkaamalla kaaviota ja ajamalla muutokset sisään. Packaged Integration: Aavan WEB-pohjainen arkkitehtuuri mahdollistaa vakiomuotoiset rajapinnat johtuen siitä, että kaikki toiminnallisuus ohjataan muutenkin selaimesta HTTP-rajapinnan yli. Tämä mahdollistaa kaikkien ominaisuuksien kutsumisen vakiomuotoisilla HTTP-kutsuilla jolloin integraatioiden tekeminen yksinkertaistuu huomattavasti. Open-Source ERP infrastructure: Aava Platformissa kaikki ulkoiset osat ovat yleisesti käytettyjä avoimen lähdekoodin komponentteja. Tällä tavoin järjestelmästä ei koidu sen elinkaaren aikana muita kustannuksia (ulkoisia lisenssimaksuja tms.), kuten vaikka uuden käyttöjärjestelmäversion asennuksesta tai uudesta tietokantaversiosta.