Artikkelit

Skaalautuva, monipuolinen tuotetiedonhallinta
Janne Costiander

Monipuolinen ja skaalautuva tuotetiedonhallinta

/in /by

Reilu vuosi sitten, lokakuun lopussa 2018, julkaisimme uuden sukupolven version Adeona PIM -tuotetiedonhallinnan järjestelmästä. Ensimmäinen vuosi uuden tuotesukupolven kanssa on ollut rohkaiseva ja lisännyt entisestään uskoa siihen, että olemme oikealla tiellä. Kuvaan tässä hieman mitä taustalla on tehty ja mitä ensimmäisen vuoden aikana on tapahtunut. 

Parempi käyttäjäkokemus ja pilvivalmis teknologia 

Muutama vuosi sitten teimme ison päätöksen. Halusimme uudistaa merkittävästi Adeona PIM-tuotetta, niin teknisesti kuin käyttökokemukseltaan. Erilaisten pohdintojen jälkeen päädyimme siihen, että haluamme uusia tuotteen luomalla sen käytännössä kokonaan uudestaan. Tähän meillä oli muutamia eri perusteita: 

  • parempi käyttäjäkokemus ja täysin selainpohjainen käyttöliittymä 
  • joustava, pilvivalmis teknologia, joka mahdollistaa teknisen skaalautuvuuden, erilaiset toimitusmallit ja helpon päivitettävyyden 
  • teknologiat, joiden kanssa on mukava ja tehokas työskennellä ja jotka houkuttelevat meille parhaita kykyjä 
  • tekemisen muuttaminen nopeammaksi: miten luoda nopeammin uusia ominaisuuksia ja toimittaa niitä asiakkaiden käyttöön 

API ja suorituskyky suunnittelun taustalla

Heti uuden version suunnittelun alussa meille oli selvää, että tuote rakentuisi vahvasti API-ajattelun pohjalle. API tarkoittaa ohjelmointirajapintaa, jonka välityksellä esimerkiksi eri sovellukset voivat siirtää tietoa. Tuotteessamme käyttäisimme yhtä hyvin dokumentoitua julkista API:a (public API), oli sitten kyse ”meidän käytöstä” (esim. käyttöliittymän ja palvelimen välinen keskustelu) tai API:n käytöstä esim. asiakkaan tai vaikkapa verkkokauppakumppanin toimesta. Heti ensimmäisestä versiosta asti tämä ajatus on pitänyt, ja rajapintadokumentaatiosta olemme saaneet paljon positiivista palautetta, kuin myös API:n selkeydestä ja helppokäyttöisyydestä. Meidän API on REST API, jossa tiedot välitetään käyttäen JSON-sanomia. 

Heti uuden version suunnittelun alussa meille oli selvää, että tuote rakentuisi vahvasti API-ajattelun pohjalle. Toinen suunnittelua ohjannut periaate oli maksimoida järjestelmän suorituskyky, vaikka tuotemäärät olisivat suuria.

Toinen suunnittelua ohjannut periaate oli maksimoida järjestelmän suorituskyky, vaikka tuotemäärät olisivat suuria. Maailmalla on paljon PIM-tuotteita, tai sen kaltaisia, jotka toimivat hyvin muutamien satojen tuotteiden ylläpitoon esim. verkkokaupan taustalla. Meidän asiakkaissa on usein kymmeniä tai jopa satoja tuhansia tuotenimikkeitä, joten me haluamme tukea paljon suurempia tuotemääriä ja silti mahdollistaa hyvän käyttäjäkokemuksen ja loistavan suorituskyvyn. Useat teknologiavalinnoistamme tukevat tätä, mutta myös järjestelmän arkkitehtuurissa on tehty ratkaisuja tähän liittyen.

Käytämme järjestelmän taustalla sekä perinteistä relaatiotietokantaa (PostgreSQL), että vahvasti indeksointiin perustuvaa hakumoottoria (Elasticsearch), joista hyödynnetään niiden parhaita puolia. Relaatiotietokanta auttaa mm. tiedon eheyden varmistamisessa ja hakumoottori nopeissa hauissa ja tiedon nopeassa striimaamisessa esim. integraatioissa. PIM-arkkitehtuurissamme on logiikka, joka lähes reaaliaikaisesti indeksoi relaatiotietokantaan tulevat muutokset hakumoottoriin. Käyttöliittymässä taas on satsattu joustaviin ja helposti käytettäviin Excel-pohjaisiin vienti- ja tuontiominaisuuksiin. 

Toimitusmalli asiakastarpeen mukaan

Asiakkaamme ovat kaiken kokoisia ja toimivat eri toimialoilla. Osa asiakkaistamme haluaa kaikki järjestelmänsä omaan (tai kumppaninsa) konesaliin. Toisaalta yhä useampi haluaa järjestelmänsä käyttöpalveluna. Näistä syistä haluamme olla järjestelmän toimituksen suhteen mahdollisimman joustavia ja tukea erilaisia malleja. 

Taustalla olemme tuotteistaneet järjestelmätoimituksen, riippumatta siitä haluaako asiakkaamme järjestelmän meiltä palveluna (SaaS) vai omaan ympäristöönsä. Tuotteistuksessa käytetään konttiteknologiaa (Docker), jolla tekninen ympäristö saadaan vakioitua ja toisaalta tuettua myös helppoa ja joustavaa päivitettävyyttä. Konttien käytön lisäksi olemme tuotteistaneet myös mm. järjestelmän tiedon automaattisen varmistamisen off-site pilvipalveluun (Google Cloud Storage), riippumatta siitä missä järjestelmä muuten pyörii. 

Olemme tuotteistaneet järjestelmätoimituksen, riippumatta siitä haluaako asiakkaamme järjestelmän meiltä palveluna (SaaS) vai omaan ympäristöönsä.

Uuden tuoteversion myötä yhä useampi asiakkaamme haluaa PIM-järjestelmänsä meiltä SaaS-mallilla. Tällöin me vastaamme koko järjestelmästä ja asiakas vain käyttää sitä ja hyödyntää järjestelmän dataa esimerkiksi API:n kautta. 

Jatkuvat päivitykset helposti ja nopeasti 

Yksi tavoitteistamme uuden tuotesukupolven osalta oli mahdollistaa nopeat ja helpot päivitykset sekä nopeampi uusien ominaisuuksien kehitys. Elämä uuden tuotesukupolven kanssa on lähtenyt liikkeelle mukavasti ja ensimmäisen virallisen versiojulkaisun (10/2018) jälkeen olemme tehneet yhteensä 12 versiojulkaisua, eli noin yhden joka kuukausi. Näissä päivityksissä on tullut noin 500 uutta ominaisuutta tai parannusta. 

Jokainen uusi versiojulkaisu on ollut jokaisen asiakkaamme käytettävissä noin viikon kuluttua julkaisusta. Päivittäminen on helppoa ja nopeaa. Adeona PIM -käyttöliittymässä on ”PIM News” -toiminto, jonne asiantuntijamme kirjoittavat vinkkejä uusista ominaisuuksista, sekä niiden käytöstä. 

Meille on tärkeää myös, että järjestelmän taustalla olevat komponentit päivittyvät. Näin vältymme siltä, että keräisimme ns. teknistä velkaa ja tulevina vuosina joutuisimme tekemään valtavan suuria päivityksiä. Adeona PIM hyödyntää lukuisia avoimeen lähdekoodiin perustuvia kirjastoja ja sovelluskomponentteja. Useat niistä päivittyvät ja kehittyvät vauhdilla ja pidämme huolen että emme jää kehityksestä jälkeen. 

Kehitys yhdessä asiakkaidemme kanssa 

Asiakkaistamme muodostuva Adeona Community -käyttäjäyhteisö on aktiivisesti mukana Adeona PIM -kehityksessä. Vuonna 2019 järjestimme kaksi työpajaa, joissa yhdessä asiakkaidemme kanssa suunnittelimme uusia ominaisuuksia ja priorisoimme jo kehityksessä olevia piirteitä. 2020 yhteisömme toivottavasti jatkaa kasvuaan ja saamme entistä enemmän arvokasta palautetta tuotteen kehittämiseksi. Tule sinäkin mukaan! 

Janne Costiander

Rajapinnoista ja niiden avoimuudesta

/in /by

Modernin sovelluksen elinehto on toimiva julkinen API. Ennen kuin katsotaan tarkemmin, mitä API meidän näkökulmasta tarkoittaa ja miten niistä saadaan parhaat hyödyt irti, käydään läpi vähän perusteita.

API (Application Programming Interface) tarkoittaa sovellusrajapintaa, jota kautta sovelluksen tiedot ja toiminnallisuus on saavutettavissa sekä mahdollistaa ohjelmointityön sovellukseen tai sen osaan, esimerkiksi standardikirjastoon liittyen. Nämä rajapinnat voivat olla hyvin matalalla tasolla ja liittyä järjestelmän sisäiseen toimintaan. Esimerkiksi käytettävän Open Source -kirjaston kutsuihin järjestelmän sisällä. Tässä kirjoituksessa katsotaan kuitenkin tarkemmin julkisia rajapintoja. Niitä, joiden kautta sovellus on laajennettavissa tai integroitavissa, sekä sovelluksen tieto laajasti hyödynnettävissä.

API-keskeinen arkkitehtuuri

Perinteisesti sovellusrajapinnat on nähty enimmäkseen järjestelmien sisäisinä tai lähinnä integrointiin liittyvinä. Modernit sovellukset toimivat kuitenkin enemmän palveluina, ja filosofiana on järjestelmän helppo laajentaminen ja sen sisältämän tiedon laaja hyödyntäminen. Modernit sovellukset käyttävät ja tarjoavat jopa useita sovellusrajapintoja. Esimerkiksi sosiaalisen median sovellusten, kuten Facebook ja LinkedIn, käyttö perustuu pitkälti rajapintoihin joiden ympärille on tehty erilaisia käyttöliittymiä (selain, mobiili jne.).

API-keskeisessä arkkitehtuurissa sovellukset keskustelevat näiden julkisten rajapintojen kautta. Yksittäisen sovelluksen ohjelmointikielellä tai sisäisellä rakenteella ja logiikalla ei ole merkitystä, kun rajapinnat on tehty yleisten käytäntöjen mukaan. API-keskeinen arkkitehtuuri helpottaa myös päätelaiteriippumattomien sovellusten rakentamista. Esimerkiksi eri mobiilikäyttöjärjestelmille tehdyt sovellukset voivat käyttää samaa yleistä rajapintaa.

Adeona_PIM_2017

RESTful API

Kun käytetään yleisiä käytäntöjä ja de facto-standardeja, on sovellusten liittäminen helppoa ja datan hyödyntäminen tulee mahdolliseksi erilaisissa sovelluksissa.

REST (Representational state transfer) on tilaa tallentamaton HTTP-protokollaan perustuva arkkitehtuurimalli sovellusrajapintojen tekemiseen. Tyypillisesti REST API tarjoaa tiedon JSON (JavaScript Object Notation)- tai XML-formaatissa.  Me käytämme REST-rajapinnassamme JSON-formaattia, joka on avoin, luettavaan tekstiin ja attribuutti-arvo-pareihin perustuva vallalla oleva formaatti.

Avoin API

Yksi API-keskeisen arkkitehtuurin perusajatuksia on, että rajapinnat on avoimesti saatavilla ja niihin löytyy avoimesti saatavilla oleva hyvä dokumentaatio. Hyväkin rajapinta jää käyttämättä, jos sitä on hankala käyttää tai dokumentaatio ei ole saatavilla. Parhaimmillaan koko järjestelmän tietomassa sekä logiikka on saavutettavissa rajapinnan kautta. Näin järjestelmän liittäminen, integrointi tai laajentaminen omilla liittyvillä sovelluksilla on joustavaa.

Avoin rajapinta ei tarkoita sitä, että kaikki järjestelmän tieto on kaikkien saatavilla. Rajapintakutsut todennetaan ja järjestelmä voi sitten rajata kullekin rajapintaa kutsuvalle ne tiedot, joihin oikeudet riittävät.

Lue lisää Adeona PIM -rajapinnoista ->

Lisätietoja rajapinnoista muualla:

https://en.wikipedia.org/wiki/Application_programming_interface

https://en.wikipedia.org/wiki/Representational_state_transfer

Patrik Palatz

Vision of a CIO: Kill ’em all!

/in /by

Kävin hiljattain mielenkiintoisen keskustelun erään keskisuuren kotimaisen yrityksen tietohallintojohtajan kanssa. Hän oli tullut taloon noin vuosi takaperin ja vaikutti siltä, että strategiatyö kokonaisarkkitehtuurin parissa oli saatu päätökseen ja että tiekartta järjestelmäarkkitehtuurin osalta alkoi olla aika selkeä. Kohtalaisen kokoista modernisointia, remppaa ja järjestelmäuudistusta tiedossa seuraavan kolmen vuoden sisään. Tai neljän vuoden,

koska ainahan nää suunnitelmat vähän venähtää.

Kaverin 2020 vuoden visio miellytti marinoidun PIM-konsultin korvaa. Vapaasti mukaillen tavoitteena on uudistettu, moderni arkkitehtuuri, jossa masterdata ja siihen liittyvät prosessit on laitettu kuntoon, tieto virtaa API-ajattelun mukaisesti ja asiakkaiden kanssa pystytään kommunikoimaan mahdollisimman hyvin tietovarantoja ja automaatiota hyödyntäen.

Sopivan mutkattoman jutustelun keskeltä yksi sutkautus jäi mieleen.

Mulla on tässä siis tavoitteena tappaa noin 16 järjestelmää, jonka jälkeen tilalla olisi enää 5 tai 6 järjestelmää. Eli Metallican hengessä Kill ’em All!

Innostusta ilmassa ja aivot kävivät kierroksella, aivan loistava meininki! Plussaa tietysti siitä, että saatiin nuoruusvuosien suosikkibändikin sotkettua samaan soppaan bisnesapplikaatioiden, rajapintojen ja datan kanssa. Tuli myös sellainen fiilis, että näiden kanssahan voisi olla kiva tehdä hommia tulevaisuudessa.

Tapaamisen jälkeen jäin kuitenkin pohtimaan tämän päivän tietohallinnon johtamisen haasteita. Tästä jos jostain aiheesta on toki kirjoiteltu pitkään ja paljon ja monista eri näkökulmista. Ja meillä Suomessa on kansainväliselläkin tasolla tunnistettua todella kovaa osaamista (josta Tietohallintomalli  yhtenä esimerkkinä).

Mutta nyt minulla jäi raksuttamaan nimenomaan tuosta Metallica-näkökulmasta.

Nuo CIO:n speksaamat jäljelle jäävät 5-6 järjestelmää ovat tietysti liiketoimintakriittisiä pääjärjestelmiä, jotka omistavat kullekin järjestelmälle ominaisen perustiedon. Tässä tapauksessa joukkoon kuuluu myös sähköisen kaupankäynnin alusta, jolla mm. pyöritetään tulevaisuudessa eri liiketoimintayksiköiden verkkokauppaa.

canter_sieniasateella_blogi

Tämä on perusta, jonka päällä bisnes ja ydinprosessit pyörivät. Masterdataa hallitaan ja hoivataan parhaiden käytäntöjen mukaan ja modernit rajapinnat tarjoilevat sen oikeisiin paikkoihin oikeaan aikaan. BI- ja analytiikkatyökalujen avulla tuotetaan arvokasta tietoa päätöksenteon tueksi, jotta toimintaa osataan kehittää oikeaan suuntaan ja voidaan johtaa tiedolla eikä mutulla.

Sitten on se kerros, joka on täynnä sovellusten ja työkalujen silppua ja jonka reunaviivat ovat ärsyttävän hyhmäiset.

Liiketoiminta haluaa kehittää asiakaskokemusta ja kommunikointia, verkkokauppaa ja myyjien työkalupakkia – markkinoinnin digihärpäkkeistä puhumattakaan. Kaikki tämä mahdollisimman ketterästi kiitos. Samanaikaisesti kulut pitää pysyä kurissa ja toiminnan tehostua.

Ihmiset yksiköstä ja toimenkuvasta riippumatta haluavat puolestaan käyttää työkaluja, jotka on nopea oppia ja joiden käyttäminen on helppoa ja tehokasta. Varsin luonnollista. Jos tämä ei toteudu, ongelmat tuppaavat viime kädessä kasautumaan data-kuvernöörien ja tietohallinnon pöydälle.

Miten tätä jatkuvasti kasvavaa ja uudelleen muotoutuvaa sovellusten, apuohjelmien ja pilvipalvelujen ryteikköä pitäisi hallita? Kenellä on vastuu mistäkin? Kuka edes tietää mitä kaikkia appseja meillä on käytössä mihinkin tarkoituksiin? Onko meille oikea malli ”Master of Apps” vai ”…And Apps for All”? Mitä tietoa missäkin käytetään? Syntyykö jossain bisnesvinkkelistä arvokasta tietoa, joka pitäisi kytkeä johonkin prosessiin tai analytiikan piiriin? Ja niin edelleen…

Ei muuten käy kateeksi tämän päivän tietohallintojohtajia.

Eikä ihmetytä yhtään miksi maailmalla keksitään kilpaa uusia titteleitä ja rooleja johtamaan näitä alueita, koska yhden miehen/naisen show ei ole riittänyt enää pitkään aikaan.

Kiinnostaisi kuulla elävän elämän esimerkkejä mitä tapoja teillä on käytössä sovellusten ja tietovirtojen kuvaamiseen. Onko olemassa tai tullut vastaan jotain hyviä valmiita malleja vai oletteko kehitelleet tai piirtäneet sellaiset itse omiin tarpeisiinne? Laita kommenttia tai heitä viestillä privaatisti. Vaihdan mielelläni ajatuksia aiheesta.

Meinasin seuraavalla kerralla avautua ja avata hieman miten olen itse tavannut jäsentää tämän päivän vaatimuksiin vastaavan informaatioarkkitehtuurin viitekehyksen tuotetiedonhallinnan ja digikehittämisen näkökulmasta. En suosittele kuitenkaan pidättämään hengitystä sitä odotellessa, koska inboxiini kilahti tätä kirjoittaessa ehdotus otsikolla ”Sieniretki Nuuksion metsissä”. Hyvää syksyä!