Suoraa puhetta webin tekemisestä ja teknologioista – haastattelussa Vesa Palmu
Otathan huomioon, että tämä artikkeli on yli 10 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreena lukemisena samasta kategoriasta: Rajasoft osti Buorren kehitystiimin.
Vierityspalkin haastattelussa nyt pitkän linjan web-ammattilainen Vesa Palmu. Haastattelussa käymme ensin läpi CMS-markkinan historiaa, ja miten Drupalin nousu suhteutuu tähän. Vesa arvioi isoimpia CMS-markkinan muutoksia viime vuosien aikana ja analysoi mm. frameworkkien nousua.
Vesa Palmu on Wunderkrautin toimitusjohtaja ja mukana myös kansainvälisen Drupal-yhdistyksen hallituksessa. Vesa asuu nykyisin Lontoossa ja päätyönään puhuu Drupalin ja Wunderkrautin puolesta isoille yhtiöille eri puolilla Eurooppaa. Vesalla on kuitenkin pitkä historia erilaisten CMS-tuotteiden kanssa, ja onpa Vesa ennen Wunderkrautin aikaansa työskennellyt myös konsulttina auttaen asiakkaita ostamaan web-uudistusprojekteja.
Miten kuvailisit webin teknologiakentän muutosta viimeisen 15 vuoden aikana?
“Alan alkuvaiheet nyt olivat mitä olivat, melkoista sekoilua ja kaikenlaisia teknologioita. Kiinnostavin vaihe alkoi kun “yhden tarkoituksen tuotteet” alkoivat toisen nousunsa. Tätä ennen tuotekenttä oli todella kirjava ja vain Vignetten kaltaiset jätit toimivat siellä laajemmin. Olisiko tämä ollut 2007 suurinpiirtein. Vajaa kymmenen vuotta sitten. Näitä olivat SharePointit, WordPressit, ym. tuotteet. Tuotteita, jotka tekivät yhden asian erittäin hyvin. Tällöin nähtiin myös paljon näiden tuotteiden väärinkäyttöä – kun tunnettiin vain yksi tuote, niin sillä sitten yritettiin tehdä kaikki asiat.
Hiukan myöhemmin nousivat frameworkit, kuten Ruby on Rails, Django ja monet muut. Näiden ideahan on se, että edelleen koodataan räätälöityjä toteutuksia, mutta koodaaminen on vain paljon tuottavampaa kuin aiemmin. Tietysti tätä samaa yritti Java ja monet muut jo aiemmin, mutta Ruby on Rails oli luultavasti ensimmäinen, joka oikeasti lunasti nämä lupaukset.
Viime vuodet webin teknologiakenttä onkin kehittynyt moneen eri suuntaan samanaikaisesti.”
Miten näet nykytilanteen, ja kuinka Drupal istuu tähän kaikkeen?
“Yhtäällä meillä on nämä julkaisujärjestelmätuotteet, kuten Sitecore ja WordPress. Toisessa laidassa meillä on frameworkit, joilla voi koodata hyvin monenlaisia asioita melko tehokkaasti. Sitten meillä on vielä näiden kahden välissä Drupalin kaltaiset CMF:t (content management frameworkit).
Drupal on frameworkkeihin nähden erittäin tehokas featurejen tekemisessä, mutta työläs yksityiskohtien saralla. Frameworkeissa asia on toisinpäin, featuret ovat työläitä ja yksityiskohdat tulevat tehtyä ikäänkuin siinä sivussa. Frameworkeilla saa nopeasti hyvännäköisiä juttuja, mutta mitä laajempi ja monimutkaisempi kokonaisuus pitää tehdä, sitä kalliimmaksi projekti tulee. Drupalilla voi saada monimutkaisiakin juttuja aikaiseksi jo parissa viikossa, mutta sitten käyttöliittymien ja käytettävyyden hiominen edelleen kestää aikaa ja maksaa rahaa.
Verrattuna julkaisujärjestelmätuotteisiin taas voisi sanoa, että Drupalilla voi tehdä hyvän julkaisujärjestelmän, mutta se ei ole kummoinen julkaisujärjestelmä ilman konfigurointia. Eron voi kärjistää siihen että Drupalilla voi rakentaa WordPressin, muttei toisinpäin. Drupal vaatii myös toimittajalta enemmän järjestelmäkohtaista erikoisosaamista kuin tuote tai framework.
Oikeastaan noiden kolmen kategorian (julkaisujärjestelmätuotteet, frameworkit, CMF:t) lisäksi meillä on vielä monenlaiset SaaS-palvelut, kuten Kotisivukone, Squarespace ja muut täysin käyttövalmiit yhden asian ihmeet.
Markkinaosuudet riippuvat voimakkaasti verkkosivuston tyypistä. Vähemmän ammattimaisissa sivustoissa SaaS-palvelut ja julkaisujärjestelmät ovat luultavasti 99% markkinasta. Isommissa ja monimutkaisemmissa sivustoissa markkinaosuudet muuttuvat nopeasti. Jos joku tilasto tarkastelisi pelkästään suuria verkkosivustoja, väittäisin Drupalin olevan selkeä markkinajohtaja.
Jos mietitään koko ekosysteemeissä liikkuvia rahavirtoja ovat julkaisujärjestelmät ja SaaS -tuotteet luultavasti 60%. Näiden välille on vaikea vetää rajaa, koska WordPress yksin on niin suuri peluri toimien molemmissa kategorioissa. Frameworkit ovat luultavasti noin 30% koska ne ovat de-facto standardi startupeille. Viimeinen 10% jää Drupalin kaltaisille järjestelmille ja lukumääräisesti pienemmälle määrälle ammattimaisia verkkopalveluita.
Jonkin verran tietysti vaikuttaa myös näiden eri alueiden oppimiskynnykset kehittäjille. Frameworkithan ovat näistä ehdottomasti helpoimpia oppia ja yksi kehittäjä voi osata helposti useita sujuvasti.
Julkaisujärjestelmätuotteet taas voivat olla ihan mitä vain, joko järjettömän vaikeita tai todella helppoja. Drupalin kaltaiset taas ovat yleensä tyypillisesti vaikeimpia kehittäjille, eikä ole realistista olettaa yksittäisen kehittäjän pysyvän perillä monesta tälläisestä järjestelmästä. Tämä vaikuttaa myös siihen, kuinka paljon eri vaihtoehtoja yksittäinen toimittaja voi tarjota asiakkailleen.
Netti kasvaa ja kehittyy samanaikaisesti monella eri rintamalla tällä hetkellä. Kaikilla näillä on oma alueensa markkinasta. SaaS-tuotteiden osuus tulee varmasti kasvamaan, mutta muuten on vaikea ennustaa kehitystä.
Lisäksi markkinat ovat aika erilaisia eri puolilla maailmaa. Saksa on ihan oma markkinansa, samoin jenkit, jopa Ruotsi. Esimerkiksi Typo3 on edelleen iso peluri Saksassa, mutta käytännössä kuollut muualla. Sama pätee EPiServeriin, joka on iso Ruotsissa ja saanut jonkun verran jalansijaa pohjoisessa Euroopassa muttei laisinkaan esillä muualla maailmassa.
Eli paljon on menty eteenpäin, eri markkinat tulevat jatkossa todennäköisesti samankaltaistumaan lisää.”
Mikä on muuttunut paremmaksi vuosien varrella?
“1) Perussaittien pistäminen pystyyn on ihan ilmaista ja triviaalia nykyisin verrattuna kymmenen vuoden takaiseen. Markkinointi verkossa on edelleen vaikeata, mutta teknisenä suoritteena pienten saittien tekeminen on täysin triviaalia.
2) Kunnollinen pilotointi on nykyisin paljon helpompaa. Todella liiketoimintakriittisen ja bisnekselle merkityksellisen ison saitin tekeminen on edelleen vaikeata, mutta nykyisin pilotointi on helpompaa. Kokeilemisen mahdollisuudet ovat aivan huikeat verrattuna esimerkiksi vuonna 2000 olleisiin mahdollisuuksiin. Silloin olisi todella tarvinnut puoli miljoonaa euroa kunnolliseen kokeiluversioonkin. Nykyisin parilla kymppitonnilla tekee ihmeitä, ja saa oikeata palautetta asiakkailta ennen kuin tekee isompia päätöksiä.”
Mikä on vaikeata edelleen? Mitkä asiat eivät ole muuttuneet?
“1) Ihmiset edelleen kuvittelevat, että hyvin suunniteltu on melkein tehty. Komplekseista projekteista ei ole tullut sen helpompia. Kun pitää muuttaa isosti ihmisten toimintatapoja ja työvälineitä, niin asiat ovat todella vaikeita. Tässä puolessa tarvitaan edelleen enemmän ketteryyttä, pilotointia ja vaiheittaisia esimerkkejä onnistumisesta.
2) Pakko sanoa, että useimmat ongelmista liittyvät organisaatioiden sisäiseen organisoitumiseen – eli johtamisen ongelmiin. Harva iso IT-hanke epäonnistuu tekniikan takia, ne epäonnistuvat huonon muutosjohtamisen takia.
3) Jos teknisistä ongelmista nyt joku pitää mainita, niin massiivinen skaalautuminen on edelleen vaikeata mittakaavan kasvaessa jatkuvasti. Etenkin kun puhutaan globaalista mittakaavasta, niin tämä on edelleen haastava ja harvojen aidosti osaama osa-alue.
4) Myös tietoturva on yhä isompi asia, varkaudet, huijaukset ja vakoilu tietoverkoissa ovat iso ongelma ja business. Ja kun valtiotkin tekevät sitä, niin siihen ei ehkä kannata odottaa ratkaisuja lähitulevaisuudessa.”
Mitä kehittäisit alan tarjonnassa, eli toimistoissa?
“Olisihan alan toimistoissa paljon korjattavaa. Itse en esimerkiksi allekirjoita pelkästään sinisen meren strategia -ajattelua kun kyse on asiantuntijapalveluista. Kova ja jatkuva kilpailu pitää yrityksen hyvässä kunnossa ja auttaa myös laajenemaan.
Pienille alle sadan hengen yrityksille suosittelisin keskittymistä. Ei ole realistista esimerkiksi osata kymmeniä teknologioita erittäin hyvin. Kannattaa valita ne toimintatavat, työkalut ja toimialat joissa voi olla todella hyvä ja panostaa näihin. On parempi valikoida ne asiakkaat ja projektit, jotka sopivat omiin vahvuuksiin kuin yrittää tarjota jokaiselle asiakkaalle jotain, ettei vain tarvitsisi kieltäytyä projekteista. Ei:n sanominen onkin toimittajille tyypillisesti paljon vaikeampaa ja tärkeämpää kuin kyllä:n.”
Lue lisää: Web-sovellukset ja räätälöidyt tietojärjestelmät – kaikki artikkelit Vierityspalkissa
Perttu Tolvanen
Perttu on Vierityspalkin päätoimittaja ja kirjoittaja.
Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja toinen perustaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton konsulttiyhtiö, joka suunnittelee digitaalisia palveluita ja auttaa asiakkaita onnistumaan uudistushankkeissaan. Ota yhteyttä Perttuun!
24 kommenttia on “Suoraa puhetta webin tekemisestä ja teknologioista – haastattelussa Vesa Palmu”
Kommentointi on suljettu.
Perttu Tolvanen
Kiitos Vesalle haastattelusta. Allekirjoitan itse erityisesti tuon markkinan jakautumisen hyvin erilaisiin alueisiin. Alan firmoille tämä tuntuu myös olevan vaikea asia hahmottaa, koska sillä omalla vasaralla edelleen yritetään tehdä vähän kaikkea.
Omasta näkökulmastani katsoen sanoisin, että julkaisujärjestelmillä paljon asioita tehneet ovat keskimäärin pidemmällä kuin esimerkiksi monet räätälikoodausta harrastavat tahot. Julkkareilla isoja juttuja tehneet ovat yleensä “maksaneet oppirahansa”, kuten Vesakin mainitset jutun alussa. Enää ei olla niin innokkaita tekemään kaikkia mahdollisia asiointiportaaleita tai mobiilisovelluksia sen oman julkaisujärjestelmän päälle. Esim. .Net-kentällä Azuren päälle räätälisovelluksien tekeminen on jo kohtuullisen yleistä alan toimijoiden parissa.
Tällä hetkellä frameworkkeja pääasiallisesti käyttävät firmat tuntuvat olevan enemmän huumaantuneita niistä leluistaan ja tunkevat niitä taas sitten joka paikkaan. Tai ainakin vierastavat asioiden ratkomista julkaisujärjestelmillä. Asiakkaiden ongelmat nähdään hyvin erikoisina ja aina lähdetään koodaamaan räätälinä – vaikka järkevämpää olisi pilkkoa isoa kokonaisuutta selkeämmin räätäliosiin ja julkaisujärjestelmäosioihin.
Kaupallisesti katsoen kyse on tietysti joskus myös siitä, että frameworkeilla tekeminen ei vaadi niin kokeneita tekijöitä – junnuja koodareita joilta frameworkit sujuvat, löytyy helpommin. Ja edelleen, on jokseenkin ennustettavampaa ja turvallisempaa tehdä isoja juttuja räätälinä. Alkuvaiheessa ei tarvitse miettiä niin paljon sitä, että mikä mahtaa olla kehityspolku parin vuoden päähän. Siksi tietysti etenkin startupeille frameworkit sopivatkin erittäin hyvin.
Tosin toki markkinassa osaaminen on parantunut myös huikeasti tässä kymmenen vuoden aikana. Kokeneita webin tekijöitä löytyy tästäkin maasta jo todella paljon, ja myös erittäin osaavia arkkitehteja, jotka ovat nähneet erilaisia tapoja – ja osaavat valita järkevästi tekniikoita ja menetelmiä.
Markkinaosuuksien osalta tuo isojen saittien määritelmä on varmaan se kaikkein vaikein. Jos tuota euromääräisyyttä käyttää mittarina, niin voi tosiaan hyvinkin olla, että Drupal on isoin globaalisti. Sen verta isoja “työmaita” ympäri maailmaa on. Mutta ei se markkina ihan heti ole selkeytymässä, sen verta isoja työmaita on pitkin poikin palloa myös Sitecorella, Adobella, Oraclella ym “isoilla pojilla”.
Allekirjoitan sen myös, että markkinat samankaltaistuvat varmasti pitkässä juoksussa jos ei mitään yllättävää tapahdu. Tosin kuinka nopeasti se tapahtuu? En usko esim. jonkun Typo3:sen tai EPiServerin valta-aseman murtuvan ihan lähivuosina. Jonkinlaista eroosiota varmasti tapahtuu, mutta paikallisten markkinoiden vahvuus on etenkin Euroopassa yllättävän kova, sanoisin. Sitä vastoin uskon, että markkinat polarisoituvat seuraavina vuosina hallitsevien pelureiden eduksi. Eli EPiServeristä ja Typo3:sesta voi tulla entistäkin vahvempi, kun pienemmät haastajat menettävät markkinaa.
Tosin viime kädessä tämän ratkaisevat nimenomaan alan toimistot. Ja mikäli kaikki haluavat sitä sinistä merta, niin erikoisilla vehkeillä asioiden tekeminen vain yleistyy. Jos taas punaisen meren edut nähdään laajemmin (mihin itse kannustat jutun lopussa), niin sitten vahvat alueellisetkin toimijat todennäköisesti pärjäävät entistä paremmin – isompien ekosysteemien ohessa.
Allekirjoitan itse aivan täysin sen, että alan toimistojen perisynti on pyrkiä erottautumaan kilpailijoista kaikin tavoin. Siitä erottumisesta on unohtunut se ‘positiivinen’ -etuliite, joka kyllä etenkin liiketalouskirjallisuudessa siihen yleensä keskeisesti eteen liitetään. Eksoottisella teknologiavalinnalla (tai valitsemattomuudella) lähinnä erottelee itsensä ulos koko markkinasta, eli ei pääse edes shorttilistalle eikä tapaamisiin. Punaisessa markkinassa kisa on toki joka kerta kovempi, ja pitää erottua osaamisella, tekemisen tavoilla, kokemuksella ja näkemyksellä. Punaisen markkinan etuna on sitten toki se, että niitä kisoja on paljon enemmän, on varaa välillä myös hävitä.
On jotenkin todella ihmeellistä minusta, että miten moni alan toimisto erottelee itsensä ulos eksoottisella teknologiavalinnalla (tai sillä että ei ole erikoistunut yhtään mihinkään) eikä sitten pääse edes kisaamaan muilla vahvuuksillaan.
Mikko Paltamaa
Hyvä haastattelu/kirjoitus. Oman firmamme näkemykset eri järjestelmistä sekä ennustukset markkinoiden kehittymisestä ovat hyvin pitkälti samoja kuin Vesalla.
Miika Niemelä
Nyt on pakko tarttua yhteen melko räikeään epäkohtaan muuten ihan asiallisessa jutussa. Palmu toteaa artikkelissa eri markkina-alueista: “Sama pätee EPiServeriin, joka on iso Ruotsissa ja saanut jonkun verran jalansijaa pohjoisessa Euroopassa muttei laisinkaan esillä muualla maailmassa.”
Seuraavaksi faktat pöytään. EPiServerillä on toimintaa yli 30 maassa, sillä on 10 maatoimistoa sekä yli 6000 asiakasta, joille on toteutettu noin 22 000 verkkopalvelua. Tämän lisäksi EPiServer on ollut listattuna visionääriksi viitenä vuonna peräkkäin Gartnerin WCM -taikaneliössä. Kyseiseen raporttiin ei olisi mitään asiaa, jos toiminta rajoittuisi pelkästään pohjoiseen Eurooppaan. Suosittelen vierailemaan verkkosivuillamme ja tutustumaan julkisiin referensseihimme: bit.ly/1xRX4Hc
Perttu Tolvanen
Kiitos täydennyksestä, Miika.
Itsekin ehkä sanoisin, että kyllä EPiServerin jalanjälki on esim. Typo3:sta huomattavasti isompi. Vesan pointti globaalien ja paikallisten pelureiden eroista on toki relevantti tuolla korjauksellakin. EPiServer on ensisijaisesti alueellinen peluri vielä, ja globaalisti Sitecore on jättänyt kaikki muutkin .Net-pelurit ihan lähtöviivalle niin sanotusti.
Ei EPillä toki mitenkään huonosti mene, joten vaikka maailmanvalloitus ei etenekään samalla tavalla kuin Sitecorella, niin eipä esim. suomalaisen, ruotsalaisen tai norjalaisen asiakkaan tarvitse sellaisesta paljon huolta kantaa.
Mutta kuten omassa kommentissani toteankin jo aiemmin, niin “merkittävä paikallisuus” voi olla jatkossa entistäkin isompi juttu. Kyllä isoistakin webbiprojekteista moni on vielä jatkossakin aika paikallisia, eivätkä kaikki tarvitse aidosti globaalia kumppaniverkostoa. Täten Drupal tulee kisaamaan EPiServereiden ja kumppaneiden kanssa vielä pitkään.
Vesa Palmu
Pidän kiinni näkemyksestäni EPin osalta Miikan vastineesta huolimatta. Perustan näkemykseni pääosin siihen mihin eri järjestelmiin omilla markkinoillamme törmäämme ja puolueettomiin numeroihin jotka ovat paremmin vertailukelpoisia kuin eri järjestelmien valmistajien omat numerot.
Toki näkemykseni perustuu vain omiin pääasiallisiin markkinoihimme, eli yhdeksään maahan Euroopassa ja Yhdysvaltoihin. Esimerkiksi Sitecorea, WordPressiä ja AEM:a näkee tiuhaan, EPiä todella harvoin Pohjoismaiden ulkopuolella. Tilanne on vastaava Typon osalta saksankielisellä markkinalla ja toisaalta Typon omien numeroiden mukaan sillä on tehty yli 500 tuhatta palvelua. En siis varsinaisesti allekirjoita Pertun väitettä EPin huomattavasti Typoa isommasta jalanjäljestä.
Tarkoitus ei ole dissata EPiä vaan todeta miltä todelliset markkinaosuudet kansainvälisesti näyttävät. Gartnerin raportti on aika puhtaasti pay-to-play, eikä esimerkiksi Drupalia löydy raportista vaan yksittäinen Drupal -toimittaja Acquia. Ei EPin pieni koko kansainvälisesti vertailtuna siitä hyvää tai huonoa tuotetta tee.
Julkkarimarkkina laajasti katsottuna on edelleen voimakkaassa kasvussa ja muutoksessa. Jopa pieneneväkin markkinaosuus voi tarkoittaa merkittävää kasvua absoluuttisissa numeroissa. Markkinaakin enemmän kasvaa sen “bruttokansantuote”, eli rahamäärä mikä tällä alalla liikkuu. Kaikki josta voi tulla digitaalista digitalisoituu ajan mittaan. On siis aika varma että markkinalle on tulossa myös uusia pelureita jatkuvasti.
Antti Peisa
Perttu, mitä pidät eksoottisena teknologiavalintana pienten sivustojen (5000€ – 40 000€) kokoluokassa, joilla ei päästä edes shortlistille? Ja minkä vuoksi harvinaisempi teknologia on yksinään riittävä syy jäädä ulos shorttilistalta?
Jos puhutaan puhtaasti teknologioista, niin mielestäni tuohon kokoluokkaan löytyy useita erittäin hyviä teknologioita (nopeasti mieleen tulee ProcessWire, Concrete5, Silverstripe, Craft, Perch… sekä useat kotimaiset cms:t). WordPress toki myös yksi näistä, mutta ei suinkaan ainoa. Itseasiassa katsottuani nuo “isot wp-sivustot” semman videot, mielikuvani siitä, että jos saitti ei ole blogi/uutisvirtatyylinen, sillä on hieman enemmän kokoa (satoja, ellei tuhansia sivuja), mahdollisesti muutama integraatio, niin wordpressillä homma menee enemmän tai vähemmän säätämiseksi ja virittelyksi (joka näkyy sitten sekavina ylläpitonäkyminä ja kalliina kustannuksina).
Perttu Tolvanen
Listaamasi järjestelmät ovat hyviä esimerkkejä tuollaisista työkaluista. Toki lista voisi olla pidempikin, jos otetaan vaikka Euroopassa käytössä olevia työkaluja mukaan. Suomessa nuo kolme ensimmäistä mainitsemaasi lienevät ne tyypillisimmät (ProcessWire, Concrete5 ja Silverstripe) julkaisujärjestelmät, jotka ovat monella tapaa päteviä, mutta joilla ei ole merkittävää markkinaa vielä olemassa (verrattuna esim. WordPressiin tai Drupaliin) – ja jotka siis puhtaasti ominaisuuksia katsoen voisivat hyvin haastaa Drupalin ja WordPressin monessa projektissa.
Yleisesti ottaen sanoisin, että mitä merkityksellisempi verkkopalvelukanava on asiakkaan toiminnalle, niin sitä enemmän asiakkaat painottavat turvallisuuteen ja ennustettavaan tulevaisuuteen liittyviä kriteereitä. Eksoottinen teknologiavalinta nousee siis yhä enemmän riskiksi sitä mukaa kun palveluiden liiketoimintamerkitys kasvaa – ja useimpien organisaatioiden kohdalla verkon (ja oman palvelun) merkitys omalle liiketoiminnalle kasvaa koko ajan.
Lisäksi julkaisujärjestelmät ovat lähentyneet toisiaan todella merkittävästi viime vuosina. WP-semman caset olivat hyviä esimerkkejä siitä, että vaikka WP:ssa on ehdottomasti ongelmansa ja rajoitteensa, niin se on monella tapaa riittävän hyvä erittäin moneen asiaan (ja todella hyvä monessa sellaisessa asiassa jota muut eivät sitten tee).
Antti Peisa
En vieläkään saanut konkreettista kuvaa miten riskit “eksoottisista” (lue: tuhansien kehittäjien hyödyntämistä ratkaisuista) aidosti realisoituvat? Eiköhän wordpressiä ostaessa myös ratkaisevaa ennenkaikkea ole se talo ja tiimi, josta ostetaan – etenkin jos verkkopalvelukanava on asiakkaan toiminnalle merkitysellinen? Tällöin ollaan nimenomaan niissä integraatioissa, tunnistuspalveluiden käytöistä, monien eri palveluiden sovittamisesta yhtenäiseksi käyttökokemukseksi jne… En usko, että näitä projekteja ja palveluita kovinkaan usein siirrellään sellaisenaan WP-toimittajalta toiselle? Vai tapahtuuko tätä usein?
Drupal ei omiesi sanojenkaan mukaan ole se vahvin peluri tuossa hintaluokassa (alle 40 000€). Jos oikein tulkitsen viestiäsi, mielestäsi tuossa hintaluokassa ei kannata tehdä verkkopalveluita juuri millään muulla teknologialla, kuin WordPressillä – ja tämä koska WordPressin ympärillä on laajin ekosysteemi?
Haiskahtaa hivenen “Nobody ever got fired for choosing IBM” -teemalta. Konsultti tuskin saa kuraa niskoilleen, kun suosittelee suosituinta? ;)
http://www.quora.com/What-does-the-phrase-Nobody-ever-got-fired-for-choosing-IBM-mean
Hieno järjestelmähän WordPress on, mutta ei suinkaan aina se paras valinta projektiin kuin projektiin.
Perttu Tolvanen
Kyllä WP-saitteja oikeasti siirrellään silloin tällöin toimittajalta toiselle, samoin Drupal-saitteja, samoin EPiServer-saitteja, samoin SharePoint-ympäristöjä. Ei se ole pelkkää myyntipuhetta, ja se onnistuu yleensä hyvin vaivattomasti (kaikissa mainituissa tapauksissa).
Minun näkökulmahan on nimenomaan kumppanikenttään perustuva näkökulma. Asiakkaat Suomessa preferoivat kotimaisia kumppaneita edelleen hyvin vahvasti, ja siinä on paljon järkeä, koska sujuva viestintä on edelleen hyvin isossa roolissa web-projekteissa. WordPressin vahvuudet perustuvat hyvään tuotteeseen JA hyvään kumppanikenttään (Suomessa). Kolmantena isona asiana tulee sitten se lisäosien ekosysteemi (tai laajemminkin globaali ekosysteemi).
Tuo IBM-viittaus osuisi esim. SharePointtiin aika hyvin. Kyllähän muutama vuosi sitten tehtiin SharePointilla paljon verkkosivustoja (ja joitain edelleen), ja SharePointin kohdalla toteutuu täydellisesti se, että ostetaan pelkästään turvallisuuden näkökulmasta (ja ehkä nimenomaan vielä oman työpaikan turvallisuuden näkökulmasta…;)
Eiköhän näin teknologiavalintakonsulttina minun kannattaisi puhua ihan eri tavalla, jos ajattelisin vain oman bisnekseni helppoutta.
WordPress ei suinkaan sovellu kaikkiin asioihin, ja eikä se julkaisujärjestelmänä ole edelleenkään mitenkään erityisen soveltuva esim. perinteisille organisaatiosaiteille. Käytännössähän perinteisen organisaatiosaitin konseptia pitäisi aina taivuttaa enemmän sisältövirtoihin perustuvaksi, jos haluaa tehdä saitin järkevästi WordPressillä. Tämä vain yhtenä esimerkkinä sen haasteista.
Minun näkökulmasta isoin ongelma tässä markkinassa on se, että osa alan toimistoista yrittää erottua liikaa yksilöllisillä teknologiavalinnoillaan, kun pitäisi keskittyä rakentamaan ryhmittymiä ja sitten kilpailla muilla asioilla kuin teknologioilla. Teknologiavalinnasta ei ole tullut vähemmän tärkeätä, mutta yhä enemmän teknologiavalinnassa painaa paikallinen kumppanitarjonta ja globaali ekosysteemi ko. tuotteen ympärillä.
Jostain syystä moni alan toimija ei ymmärrä sitä miten isoksi riskiksi asiakkaat kokevat yhden toimittajan järjestelmät. Eikä siinä ole hirveästi eroa, että onko kyse jostain avoimen koodin järjestelmästä jos sitä järjestelmää osaavia toimistoja on Suomessa vain yksi tai kaksi. Tämä sama ongelma tosin vaivaa kaupallistenkin järjestelmien kanssa toimivia tahoja. Jostain syystä muutamille alan toimistoille ei kelpaa EPiServer, Drupal tai WordPress millään, vaan on pakko yrittää tuoda jotain omaa vaihtoehtoa vaikka suurin osa asiakkaista pitää sitä vain heidän tilannetta vaikeuttavana asiana.
Sanon tämän nyt hyvin suoraan, koska näin sen näen. Minusta alan toimistojen pitäisi ajatella enemmän asiakkaiden näkökulmaa ja heidän tulevaisuuden kehityspolkujaan. Alan toimistot edelleen kelaavat liikaa sitä, että millä vehkeellä saisi yksittäisen projektin tehtyä sen 10-20% paremmin tai helpommin. Kisa on mennyt siitä ohi lähes kokonaan, asiakkaatkin ajattelevat nykyisin paljon enemmän sitä, että miten he pärjäävät valitun teknologian kanssa seuraavat seitsemän vuotta.
Ja sitten jos on ehdottomasti sitä mieltä, että oma teknologia on todella ylivertainen, niin kyllä sille teknologialle sitten luulisi olevan mahdollista puhua muitakin tahoja käyttäjiksi. Ja varsinkin jos on avoimen koodin tuote, niin luulisi että muutkin tämän maan tuhansista koodareista innostuisivat siitä sitten tosissaan. Siksi minulle ei riitä, että ProcessWirea, Concrete5:sta ja Silverstripeä tekee vain se 1-2 pientä firmaa tässä maassa. WordPress ja Drupal ovat todistaneet, että tarjolla voi olla laajempaakin tarjontaa asiakkaille.
Antti Peisa
Noista toimittajan vaihdoista en ole koskaan itse kuullut (muuta kuin kauhutarinoita), mutta kertonee vain, että olen autuaan kaukana tuosta maailmasta :) Meille asia on näkynyt niin, että 5 vuotta sitten syliin tuli “pois Joomlasta” -asiakkaita, nyt on muutaman vuoden ollut trendi “pois Drupalista” ja jännityksellä odotan, tuleeko tässä lähivuosina vielä “pois WordPressistä” trendi. Mielestäni kussakin tapauksessa taustalla on ollut tilanne, jossa on tehty teknologiavalinta vain teknologian (ja kenties sen suosion/trendikkyyden?) vuoksi – eikä riittävän tarkkaan pohdittu millä ratkaisulla ne omat tarpeet oikeasti kannattaisi toteuttaa.
Olen monesta kohtaa kanssasi täysin samaa mieltä ja näistä syistä mekin puhumme asiakkaillemme minimaalisen vähän tekniikkaa ja järjestelmiä. Meillä on hyvin spesifi kohderyhmä (järjestöt ja liitot), joilla on useita haastavia erityispiirteitä:
– monimutkainen organisaatiorakenne (toimisto, piirit, alueet, yhdistykset, luottamustehtävät, jaostot jne.), joka heijastuu lähes aina suoraan käyttäjä- ja oikeushallintaan ja käytännössä aina vaatii integraatioita jäsenrekisteriin tunnistuksen kanssa (jollei ole puhtaasti julkinen sivusto).
– pienehköt budjetit
– paljon “legacyjärjestelmiä”, joihin tulee integroitua. Esim. suurimmat liitot pyörittävät jäsenrekistereitään pitkälti hyvin vanhoilla järjestelmillä
– laajalti toimintaa verkossa: uutisvirtaa, tapahtumia ilmoittautumisineen, jäsenen asiointipalveluita, verkkolehtiä, työtiloja sidosryhmille, intranet- ja extranetit, keskusteluja, verkkokauppoja…
Kun me teimme (ja teemme) teknologiavalintoja, niin kyllä ne tehdään puhtaasti asiakkaan tarpeiden perusteella. Me olemme ratkomassa asiakkaidemme ongelmia ja siihen meillä pitää olla riittävän hyvät työkalut. Teknologia on meidän työkalu asiakkaan ongelmien ratkaisuun.
Olen nähnyt nyt muutaman casen, joissa meidän vanhalta alustalta (Directo) ollaan pompattu WP:n päälle. Meidän kannalta ikävimmissä tapauksissa emme ole olleet mukana edes tarjouskilpailussa, koska linjaus on ollut, että “me päätettiin siirtyä WordPressin päälle”. Kun tiedustelemme syytä, niin vastaus on ollut, että “ei me oikeastaan tiedetä, se on nyt suosittu ja siihen on paljon tekijöitä”.
Projekteihin on lähdetty viestinnällinen kärki edellä ja mielestäni useimmat noista saiteista ovatkin viestinnällisesti erittäin onnistuneita (pelaavat nimenomaan vahvoilla uutisvirroilla). Jossain kohtaa projektia on kuitenkin kaikilla tullut vastaan nuo ylläolevat teemat ja jokainen näistä asiakkaista on päätynyt pitämään (ja maksamaan ylläpitoa) sekä vanhasta järjestelmästä, että uudesta vain viestinnällisestä puolestaan. Hämmentävintä on, että nämä asiat ovat tulleet yllätyksenä projektin aikana. Toivottavasti näistä opitaan – en näe mitään pahaa siinä mallissa, jossa järjestöt irrottavat julkisen viestinnän irti muusta kokonaisuudestaan ja tekevät sen niin kevyesti kuin mahdollista – mutta tällöin tulee huomioida myös muut tarpeet ja varautua, että niihin tarvitaan jatkossa erilliset järjestelmät.
Innostuminen uusista teknologioista ottaa aikansa ja kun on investoinut osaamista (hakannut Drupalia tai WordPressiä jokusen vuoden), niin ei niin helposti katso muita vaihtoehtoja – etenkin jos ei ole päättävässä asemassa tahi totaalisen intohimoinen devaaja. ProcessWiren päällä on mielestäni hienosti kuhinaa ja Suomessakin jo varsin mukavasti: fi.processwire.com
Mikko Paltamaa
Olen kyllä täysin samaa mieltä siitä, että ei kukaan järkevä asiakas ryhdy ostamaan yhden tai parin firman käsissä olevaa järjestelmää, koska a) hankinnan riskit ovat älyttömät ja b) yhtä hyvin ja luultavasti halvemmalla voisi hankkia järjestelmän, jolla on miljoonia käyttäjiä ja vaikka kuinka paljon palvelutarjontaa. Toki aina löytyy asiakkaita, jotka eivät ajattele järkevästi.
Sanon näin siitäkin huolimatta, että esimerkiksi WordPress ja Drupal ovat monilta osin ihan naurettavia viritelmiä, enkä yhtään epäile, etteikö monikin firma osaisi rakentaa niiden yksittäisiä osa-alueita paljon paremmin. Sillä ei kuitenkaan ole tässä tapauksessa juurikaan merkitystä, ennen kuin joku tekee selvästi paremman järjestelmän ja saa sen jotenkin hilattua myös yhtä suosituksi.
Sitä odotellessa kannattaa keskittyä käyttämään ja parantelemaan suosituimpia järjestelmiä.
Perttu Tolvanen
Antti: On totta, että erittäin monet asiakkaat valikoivat järjestelmiä puhtaasti trendikkyyden näkökulmasta. Kyllä meillekin tällä hetkellä tulee asiakkaita, jotka haluavat meidän apua esim. vaatimusmäärittelyn ja tarjouspyynnön laatimisessa ja ovat jo etukäteen päättäneet, että haluavat WordPressin. Ja osalle näistä meidän ensimmäinen asia on se, että kyseenalaistamme teknologiavalinnan, koska esim. laajoihin ja hierarkisiin kokonaisuuksiin WordPress voi olla hyvin hankala (etenkin jos käyttöoikeuksia vielä pitää voida määrittää sivustohierarkian mukaisesti). Ja uskokaa tai älkää, niin tällaisia sivustoja on vielä paljon, ja ne voivat olla ihan järkeviäkin :)
Monien isojen järjestöjenkin verkkopalvelut kuuluvat tällaisiin ehkä yleistrendistä poikkeaviin kokonaisuuksiin, joissa oikeasti voi olla aika paljon omanlaisia juttujaan – kuten Antti ansiokkaasti listaatkin.
Usein näissä se isoin asia on kuitenkin se, että kaikille avoin, viestinnällinen puoli kannattaa eriyttää kirjautumisen takana olevista asioista. Näin siltä julkaisujärjestelmältä ei tarvitse edellyttää mitään integraatioita johonkin vanhaan asiakasrekisteriin. Eli monesti asiakkaan tilannetta eniten auttaa konseptillinen selkeyttäminen.
Erillisten järjestelmien omistaminen julkiseen webbiin ja extranetteihin (saatika introihin) ei oikeasti ole yleisesti ottaen mitenkään ongelmallista tai kallista – yleensä jopa halvempaa pitkällä tähtäimellä, etenkin jos yhtään aktiivisesti haluaa kehittää palveluita. Hyvin harvalla organisaatiolla oikeasti on järkevää syytä niputtaa kirjautumisen takana olevia palveluita osaksi verkkosivustoprojektiaan. Ehkä joku yksinkertainen salasanan takana oleva osio on vielä ihan ok, mutta eivät laajemmat kokonaisuudet.
Järjestöjenkin extrat ovat yleensä hyvin erityyppisiä palveluita kuin julkiset sivustot, joten saman alustan päälle tekeminen ei ole usein mitenkään helposti perusteltavissa.
Esim. Avoinen osaaminen integraatioiden ja muiden extranet-palveluissa relevanttien juttujen osalta ei varmasti ole mitenkään vanhentumassa. Se, että ProcessWirella tässä maassa vain kannattaisi tehdä laajemmin niitä julkisia saitteja, niin se on minusta vähän asiakkaan näkökulmasta katsoen vaikea perusteltava – niin kauan kuin se on Suomessa lähinnä Avoinen käyttämä järjestelmä.
Siinä mielessä olen täysin Mikon linjoilla, että fiksumpaa olisi asiakkaiden kannalta keskittyä vain niiden muutamien elinvoimaisimpien ekosysteemien/järjestelmien kehittämiseen ja paranteluun. Yleensä monet puutteet saadaan korjattua kyllä lisäosilla tai muuten fiksulla tekemisellä.
Jos aina vain odotetaan sitä täydellistä järjestelmää, niin enemmän tai vähemmän vain pakotetaan asiakkaat uudistusprojekteihin muutaman vuoden välein. Ja vaikka tämä olisi toimistojen kannalta fiksua bisnestä, niin onhan se asiakkaiden kannalta todella lyhytnäköistä ja huonoa palvelua.
Sitten jos todella ilmenee sellainen julkaisujärjestelmä, joka selkeästi laittaa WP:n ja Drupalin seinää vasten, niin kyllä markkina kääntyy.
Vesa Palmu
Toimittajan vaihtamisia näkyy varsin usein. Niissä menee turhan usein myös järjestelmä uusiksi joko siksi että toimittaja on pyrkinyt rakentamaan vendor-lockkia kotikutoisella teknologiavirityksellä, tai siksi että edellinen toimittaja ei ole osannut käytettyä teknologiaa kunnolla. Moni asiakas uskoo toimittajan teknologian syyttelyä ja vaihtaa molemmat vaikka tilanne oikeasti korjaantuisi jo pelkällä toimittajan vaihdolla. Järjestelmää on helpompi syyttää kuin toimintatapoja ja ihmisiä.
Itse pidän teknologiavalintaa asiakkaalle tärkeämpänä kuin toimittajavalintaa. Loppupeleissä toimittajaa on paljon helpompaa ja halvempaa vaihtaa kuin teknologiaa. Valitsemalla teknologian jolle löytyy riittävän paljon erinomaisia toimittajia turvaa asiakas investointinsa. Erityisesti isoille asiakkaille tämä on tärkeää suurimman osan digitoimijoista ollessa varsin pieniä, riittävän yleinen teknologia helpottaa monitoimittajaympäristön rakentamista merkittävästi.
Yhden toimittajan järjestelmään tai harvinaiseen teknologiaan lähtiessään asiakkaan on tiedostettava olevansa täysin toimittajan armoilla jatkossa. Tämä on riski josta voi olla paljon hyötyä jos teknologialla saadaan aidosti uniikkia kilpailuetua. Tämä tilanne on kuitenkin nähdäkseni melko harvinainen, suurimman osan verkkopalveluista voi rakentaa aivan yhtä hyvin myös yleisemmällä teknologialla. Ainakin olettaen että valittu toimittaja osaa valitun teknologian oikeasti, eikä valitse “oikeaa työkalua” kymmenien teknologioiden paletista joista mitään ei osata kunnolla.
Jani Tarvainen
“Ainakin olettaen että valittu toimittaja osaa valitun teknologian oikeasti, eikä valitse ”oikeaa työkalua” kymmenien teknologioiden paletista joista mitään ei osata kunnolla.”
Totta, mutta miten yhden tuotteen talot tekevät kun kohdalle tulee projekti jota taas ei kannata sillä omalla tehdä? Sorvataan silti, jotta ei mene projekti sivu suun?
Vesa Palmu
Asiansa osaavat yhden tuotteen talot kieltäytyvät projektista ellei se sovellu tuotteelle. Näin toimitaan ainakin meillä säännöllisesti. Sama pätee myös siihen ettei fixed-everything projekteihin suostuta laisinkaan vaan tehdään ainoastaan ketteriä projekteja.
Projekteja menee toki sivu suun joka vuosi reippaasti. Kolikon kääntöpuolena projektit saavuttavat tavoitteensa aikataulussa, asiakkaat ja työntekijät ovat erittäin tyytyväisiä.
On aika lyhytjänteistä liiketoimintaa monelta firmalta raapia sisään kaikki mahdolliset projektit riippumatta siitä pystyykö niissä onnistumaan. Meillä on aina tehty ennemmin vähemmän töitä onnistuneesti kuin oltu jatkuvasti ylibookattuja tehden töitä ilmaiseksi omien mokien paikkailuksi.
Perttu Tolvanen
Jani: Jos on pakko valita, niin viime aikaisten kokemusten perusteella olen jopa taipuvainen sanomaan, että todennäköisesti parempaan tulokseen päästään sen yhden tuotteen talon kanssa.
Moni julkaisujärjestelmä (sanotaan nyt vaikka WordPress, Drupal, EPiServer) on kuitenkin sen verta joustava, että kokeneissa käsissä ne taipuvat monenlaisiin juttuihin. Jopa esim. monikielisyysasioita saa tehtyä kovin eri tavoilla, jotka voivat olla ihan järkeviäkin lopulta. Ei lopputulos aina kaunis ole, ja esim. jatkokehityksen kanssa voi olla haasteita.
Mutta jos vaihtoehtona on tosiaan ottaa joku “yleisosaava” koodarijengi ja pistää se opettelemaan sitä sille melko tuntematonta julkaisujärjestelmää, joka ehkä sopisi täydellisesti caseen, niin lopputulos voi olla asiakkaan kannalta kalliimpi projekti ja hyvin suurella todennäköisyydellä lopputuloksessa on tehty monta juttua siten kuten ko. julkkarilla ei asioita kannattaisi tehdä. Tämä sama tuntuu pätevän verkkokauppa-alustoihin myös.
Vaikeahan tällaisia yleistyksiä on sanoa, mutta kyllä oma työhistoria on muutaman viime vuoden aikana tuottanut sellaisia kokemuksia, jotka ovat saaneet arvostamaan erikoistuneita osaajia. Hyvällä tuotteen/teknologian tuntemuksella syntyy kestävämpiä ratkaisuja ja järkevämmällä hinnalla – ainakin kun puhutaan verkkopalveluista.
Siten en esim. itse oikein ymmärrä tätä Suomessa monien talojen harrastamaa framework/räätälikoodaus-villitystä (esim. Futu, Reaktor, jne.). On niille paikkansa, mutta esim. verkkopalveluiden kohdalla hyvin julkaisujärjestelmänsä osaava tiimi tekee aivan toisenlaisia suorituksia samassa ajassa kuin joku Django/Ruby/jne -jengi.
Jani Tarvainen
Toki toimittajan pitää osata tarjottu teknologia ja uskon myös vahvasti tuotekohtaiseen osaamiseen.
Suomessa(kin) suurin osa toimittajista on kuitenkin pieniä ja “kaiken” osaaminen perinpohjin lienee harhaa. Mutta vaikkapa 50 hengen firmassa voidaan mielestäni uskottavasti hanskata useampi alusta.
Sisällönhallinnan puolelta ei varmaan kannata kahmia kuin vaikkapa WordPress ja Drupal, mutta tueksi jonkin valitun PHP frameworkin (ja vaikkapa Node.js:n) osaaminen antaa näkemystä ja mahdollisuuden valita tästä pakasta sopivin. Tai sopivin yhdistelmä.
Fiksusti rakennetulla Drupalilla pääsee ilman muuta todella pitkälle ja osaavissa käsissä tuottavuus on kovaa tasoa. Tällä hetkellä sitä kuitenkin helposti ajetaan alueille missä se ei välttämättä ole vahvimmillaan.
Kuten Perttu totesi vuonna 2011: “Julkaisujärjestelmiä EI ole tehty erittäin räätälöityjen verkkopalveluiden alustoiksi. Jos niitä sellaisten alustoina käytetään, niin ongelmiin kannattaa valmistautua.” – https://vierityspalkki.fi/2011/03/28/onko-julkaisujarjestelmien-aika-ohitse-vastaus-ei/
Toki tälläisten projektien määrä on rajattu ja yleisimpiin tarpeisiin jokin julkaisujärjestelmä on alustana paras. Monimutkaisiakin asioita saadaan tehtyä, mutta usein näin yleiskäyttöisten työkalujen käytettävyys saattaa kärsiä verrattuna erikoistuneempaan softaan.
Esimerkiksi verkkokauppojen alennukset, tuotevariaatiot, jne. tuppaavat olemaan hankalia hanskata yleiskäyttöisellä sisällönhallinnalla. Sama pätee varmaankin Avoinen järjestöasiakkaisiinkin.
Lisäksi ajan mittaan saattaa eteen tulla teknisiä umpikujia, joissa järjestelmästä on enemmän haittaa kuin hyötyä. En tiedä taustoja, mutta voin kuvitella että esimerkiksi Suomi24:n keskusteluissa siirrytään pois Drupalista jostain vastaavasta syystä. Voi syynä toki olla “kooditykittelykin”.
Itse en tunne EPiServeriä tarkemmin, mutta käsittääkseni tuoreet versiot on rakennettu Microsoftin ASP.NET MVC frameworkin päälle, jolloin samaan pakkaan pystynee heittämään osaavan toimittajan rakentamaan vaikkapa teleoperaattorin liittymien hallinnan. Olisi mielenkiintoista kuulla jostain tälläisestä casesta tarkemmin.
Perttu Tolvanen
Kiitos Jani hyvin ansiokkaasta kommentista. Isommat firmat varmasti pystyvätkin useita järjestelmiä hallitsemaan. Esim. Drupalilla ja WordPressillä tekeviä isompia digitoimistoja on aika paljon, Exoven lisäksi esim. Peytz & Co Tanskassa.
Ruotsissa EPiServer + WordPress -yhdistelmä on kohtuullisen yleinen.
Hankalimpia ovat juuri tilanteet, joissa ollaan tekemässä jotain sisältövetoista, mutta paljon räätälöityjä osa-alueita sisältävää kokonaisuutta. Näitä ovat juuri erilaiset asiointi-extranetit tänä päivänä. Esim. nyt vaikka teleoperaattoreiden itsepalvelukanavat asiakkaille, joissa on paljon sisältöjä (ja tarve esim. hallita samoja sisältöjä monella eri kielellä) sekä räätälöityjä lomakkeita, raporttinäkymiä ja piensovelluksia. Näissä ratkaisee yleensä se mihin suuntaan tulevaisuuden kehitys on menossa asiakkaan kohdalla. Jos räätälöityjen sovellusten ja toimintojen määrä on kasvamassa, niin extranet kannattaa ehkä tehdä räätälöitynä kokonaisuutena eikä julkaisujärjestelmän päälle. Sitten taas jos sisältöjen ja esim. “palvelukokemuksen personointi” ovat kasvussa tulevina vuosina, niin julkaisujärjestelmän päälle rakentaminen voi olla järkevintä. Myös analytiikka ja ylipäätään extranet-käyttäjien seuranta ja hallinta voivat puoltaa julkaisujärjestelmän käyttöä.
Esim. Microsoft-maailmassa juuri EPiServerin päälle extranet-osien rakentaminen voi olla fiksua pelkästään sen takia, että saadaan personointityövälineitä käyttöön ylläpitäjille. Näin voidaan eri asiakasryhmille kohdentaa extranetin etusivulla helposti erilaisia sisältöjä ja toimintoja – ilman, että tarvitaan koodareita tekemään asioita.
Mutta tässäkin on rajansa aina, kuten hyvin toteat. Mitä enemmän ollaan integraatioiden ja räätälöityjen sovellusten maailmassa, niin sitä enemmän siitä julkaisujärjestelmäkehyksestä voi syntyä “turhia” ongelmia. Esim. nyt vaikka järjestelmän päivityksien kohdalla.
Vesa Palmu
Selventäisin vähän tuota Janin jaottelua siitä mihin mikäkin ratkaisu sopii.
Itse näkisin frameworkin päälle koodaamisen järkeväksi lähinnä kun tehdään pitkälle erikoistunutta verkkosovellusta. Esimerkiksi vaikkapa verkkopankkia, projektinhallintasoftaa tai vastaavaa SaaS-palvelua. Näissä frameworkit loistavat eivätkä muut työkalut hommaan oikein taivu.
WP:n kaltaiset julkaisujärjestelmät sopivat kuin nenä päähän jos ne toimivat sellaisenaan ja on valmis hyväksymään myös niiden puutteet. Jos julkkaria joutuu muokkaamaan koodaamalla voi asiakas joutua nopeasti syvään suohon. Pienempi paha on koodata julkkarin kylkeen lisätoiminnallisuutta puhtaasti hyödyntäen sen tarjoamia rajapintoja. Tuntuvasti vähemmän teknisiä ongelmia, potentiaalisesti silti kallista.
Aika tarkalleen näiden välistä löytyy Drupal. Sitä ei ole tarkoitettu julkkariksi vaan alustaksi jolla voi rakentaa oman julkkarin valikoiden sen ominaisuudet. Vahvimmillaan Drupal on kun yhdistetään sisällönhallintaa, käyttäjien generoimaa sisältöä ja sähköistä kauppaa asiakkaan tarpeiden näköiseksi paketiksi. Esimerkiksi juuri mainitut tavanomaiset verkkokaupan toiminnallisuudet kokonaisvaltaisen verkkopalvelun osana ovat tyypillinen käyttötapaus.
Se mihin rajat eri ratkaisujen soveltuvuudesta vedetään on tietysti tapauskohtaista, mutta osaava toimittaja osaa kyllä tämän määritellä. Jokainen näistä käyttötapauksista on niin joka tapauksessa niin laaja ettei osaavilla toimittajilla pitäisi puutetta tekemisestä olla vaikka keskittyykin itselleen sopiviin ratkaisuihin. Asiakkaalle tämän määrittäminen on usein haastavampaa. Tästä syystä moni asiakas puhuu aluksi hyvinkin erityyppisille toimittajille ja toiset käyttävät myös Pertun kaltaisia konsultteja apuna.
Jani Tarvainen
Kiitos Vesa – tämä oli hyvä tiivistys siitä mitä tarkoitin.
Lainaus “Drupal may not always be the best solution, but it is almost always a solution” pitää myös mielestäni hyvin paikkansa.
Vastaavantyyppisiä väliinputoajia on muitakin (ainakin Processwire ja muut CMF:t), mutta Drupal on ylivoimaisesti suosituin ja turvallisin. Tämä pätee ainakin Suomen kaltaisilla pienillä markkinoilla, jossa eri toimijoita, projekteja – ja riittävän suosittuja teknologioita on vähän.
Startupeissa tosiaan usein lähdetään liikkeelle tekniikasta, vaikka se on usein toissijainen asia. Tehdään pitkään ja hartaasti fantsua suorituskykyistä systeemiä jolle ei lopulta ole käyttäjiä.
Näissä tilanteissa voisi aika usein lähteä liikkeelle nopeimman kehityksen mahdollistamalla järjestelmällä sen rajoitukset tuntien. Jos se lottovoitto sitten tulee ja käyttäjiä näyttää virtaavan niin lähdetään sitten ratkomaan pulmia puhtaalta pöydältä.
Antti Peisa
Vesa kirjoitti: “Toimittajan vaihtamisia näkyy varsin usein. Niissä menee turhan usein myös järjestelmä uusiksi joko siksi että toimittaja on pyrkinyt rakentamaan vendor-lockkia kotikutoisella teknologiavirityksellä, tai siksi että edellinen toimittaja ei ole osannut käytettyä teknologiaa kunnolla.”
Tämä oli tismalleen mun pointti! Toimittajia ilman muuta vaihdetaan, mutta hyvin usein vaikka teknologiakin pysyisi samana, niin uusi toimittaja (ja usein asiakaskin) haluaa tehdä homman uusiksi (syystä tai toisesta). Näin etenkin itselleni tutuimmassa 10 000€ – 60 000€ hintaluokassa.
Perttu Tolvanen
Oma kantani on se, että vaikka sitä uudelleenkoodausta joskus tapahtuukin, niin ei siihen nyt kannata tietoisesti itseään ajaa. Ja toisekseen, yhä vähemmän sitä totaalista uudelleenkoodausta tapahtuu tänä päivänä – ja myös pienemmissä caseissa näin.
Samassa järjestelmässä pysyminen kuitenkin mahdollistaa esim. sisältöjen migraatiot ihan toisella tapaa kuin järjestelmän vaihdon yhteydessä. Siksikin pyrkimys käyttää yleisesti käytettyä järjestelmää on yleensä vain järkevää.
Omasta mielestäni tämä pätee myös startuppeihin, koska moni startup tekee lopulta asioita, joiden rakentamiseen esim. Drupal olisi ihan hyvä järjestelmä. Mutta esim. Wauwaan kaltaisia esimerkkejä ei minulle ole tullut kovin paljon vastaan. Onko Drupalin vieroksuminen startuppien teknologia-alustana vain trendikkyys/not-invented-here -kysymys vai onko siinä kyse jostain muustakin?
Vesa Palmu
Drupal ja startupit eivät ole kovin suosittu yhdistelmä nähdäkseni kahdesta eri syystä:
1) Startupeissa mennään usein teknologia edellä tai vähintään liiketoiminnan rinnalla. Founderit pääsevät itse valitsemaan työkalunsa ja halutaan ottaa käyttöön uusin ja trendikkäin teknologia. Kehittäjän näkökulmasta tämän ymmärtää, uusimmilla leluilla on usein hauskempaa leikkiä riskeistä huolimatta. Tekninen riski ei myöskään paljoa paina kun liiketoimintariskin mittari näyttää jo muutenkin yhtätoista.
2) Jos liiketoiminta tekee täydellisiä pivotteja usein ei Drupalin refactorointi ole kovin kätevää. Drupalilla on erittäin nopea rakentaa verkkopalveluita parantaen niitä jatkuvasti, mutta jatkuvien isojen muutosten kohdalla ryhdytään menettämään tuottavudesta saatavaa merkittävästi. Vaikkapa Djangolla tehtäessä isompia osia jo tehdystä työstä saattaa pystyä helpommin pelastamaan. Varhaisen vaiheen startupeissa tämän kokoluokan muutos on arkipäivää, rahoitetuissa tai kypsemmissä ei niinkään.
Itse en yleensä suosittele Drupalia tyhjästä aloittaville startupeille jälkimmäisestä syystä. Drupal on merkittävästi parempi työkalu kypsemmälle liiketoiminnalle jossa kehitys on jatkuvaa liiketoiminnan pääsuunnan pysyessä samana. Poikkeuksia tähän löytyy lähinnä startupeista jotka työskentelevät sisältöjen julkaisun ja verkkokaupan ympärillä, näihin Drupalista löytyy niin hyvät valmiit työkalut että kehittämisen tuottavuus ratkaisee.
Samuli Hokkanen
Todella mielenkiintoinen kommenttiketju (ja toki artikkelikin). Oma kokemus on, että “Suuri Järjestelmäkeskustelu” käydään aina jossain kohtaa potentiaalisten asiakkaiden kanssa ja osatakseen esittää aidosti perusteltuja näkemyksiä ja ehdotuksia pitää kyllä tuntea kenttä aika laajalti.
Verkkopalveluiden osalta on (Stetson-menetelmällä) aistittavissa trendi aina vain monipuolisempiin ja integroidumpiin toteutuksiin – ainakin keskisuurten ja suurten yritysten ja organisaatioiden osalta. Tyypillisesti näihin liittyy vahva integraatio yrityksen tuotetietoon (ERP/PDM/PIM) tai Ecommerce -toteutuksissa verkkopalveluun sisäänrakennetut ostomahdollisuudet (erillisen verkkokaupan sijaan) ja tilaustietojen integrointi suoraan muihin taustajärjestelmiin. Tällaisiin tarpeisiin CMF-tyyppiset järjestelmät tuntuvat istuvan yleensä hyvin (Päiväduunissa nyt repertuaarissa Crasman Stage, kokemusta myös Drupal -maailmasta). Framework -tyyppisten järjestelmien vahvuus integroitavuuden lisäksi on mielestäni myös siinä että ylläpitokokemuksesta saadaan rakennettua järkevällä effortilla juuri asiakkaan tarpeisiin sopiva.
Drupal, EPiServer ja Sitecore näyttävät olevan myös tyypillisiä valintoja tällaisiin projekteihin, mutta mitenhän WP suoriutuu palveluissa joissa on esimerkiksi 8+ integraatiota? Olisi kiinnostavaa kuulla esimerkiksi case-tarina SAP-integraatiosta tai jostain muusta ison taustajärjestelmän kytkemisestä WordPressiin.