Onko julkaisujärjestelmien aika ohitse? Vastaus: Ei.
Otathan huomioon, että tämä artikkeli on yli 13 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreena lukemisena samasta kategoriasta: Valun Findkit-hakukone uskoo tuovansa lisää laskutusta digitoimistoille.
Tietokone-lehden helmikuun numerossa Kenneth Falck esittää kolumnissaan väitteen “CMS on historiaa”. Kolumnissaan Falck esittää väitteen, että yksikään sisällönhallintajärjestelmien varaan rakennettu projekti “ei ole koskaan onnistunut täysin odotusten mukaisesti”.
Falckin viitekehyksenä ovat isot verkkopalveluprojektit jotka vaativat paljon räätälöintiä. Tälläisissä tilanteissa CMS-järjestelmät ovat Falckin mukaan riittämättömiä toimintojensa osalta ja liian vaikeita sekä työläitä taivuttaa haluttuun lopputulokseen. Kolumnissa Falck kuvailee räätälöinnistä ja lisämoduulien asenteluista ja käyttöönotoista syntyvää suota. Falckin kuvailema maailma kirjavien moduulien ja räätälöintien kanssa taistelusta lienee tuttu ainakin kaikille avoimen lähdekoodin julkaisujärjestelmien kanssa työskennelleille. Suljettujen tuotteiden puolella haasteet ovat samankaltaisia, mutta liittyvät vähemmän lisämoduuleihin ja enemmän räätälöinnin haasteisiin.
Falck esittää ratkaisuksi siirtymistä hyödyntämään “matalampia web-kehitysalustoja, kuten Ruby on Railsia tai Djangoa“. Näiden avulla kun Falckin mukaan voi toteuttaa mieleisensä palvelun ja samalla koostaa palveluun sopivat sisällönhallintatoiminnot erilaisia cms-laajennuksia hyödyntäen. Isoimpana erona CMS-tuotteisiin Falck näkee näiden kehitysalustojen joustavuuden: “Ei tarvitse ottaa järkälemäistä cms:ää ja yrittää pakottaa sitä toimimaan halutulla tavalla.”
Falckin kolumnien provosoiva linja lienee harkittua joten tässä artikkelissa ei ole tarkoituksena puuttua kolumnin esittämiin kärjekkäisiin väitteisiin esimerkiksi sisällönhallintajärjestelmäprojektien epäonnistumisprosenteista. Sitä vastoin Falckin kolumnin perusargumenttien kanssa on suorastaan helppoa olla samaa mieltä: Isojen, räätälöintiä paljon vaativien verkkopalveluiden toteutuksessa ei todellakaan kannata yleensä käyttää tuotepohjaisia web-julkaisujärjestelmiä (joita englanninkielisessä maailmassa CMS-tuotteiksi kutsutaan). Mutta se, että Falck on nähnyt monen yrittävän käyttää web-julkaisujärjestelmiä tähän tarkoitukseen ei tee vielä julkaisujärjestelmistä mitenkään vanhentunutta tuotekategoriaa. Se lähinnä kertoo sen mitä Falckkikin kolumnissaan toteaa: julkaisujärjestelmätuotteita EI ole suunniteltu käyttötarkoituksiin joissa niitä pitää koko ajan olla pakottamassa toimimaan tietyllä, asiakkaan ehdottomasti haluamalla tavalla.
Lyhyesti: Julkaisujärjestelmiä EI ole tehty erittäin räätälöityjen verkkopalveluiden alustoiksi. Jos niitä sellaisten alustoina käytetään, niin ongelmiin kannattaa valmistautua.
Sama logiikkahan pätee moneen muuhunkin ohjelmistokategoriaan. Jos haluaa hyödyntää valmistuotteen tuomia hyötyjä, niin sitä kannattaa käyttää tarkoituksiin johon se on suunniteltu. Lisäksi kannattaa taivutella tuotetta mahdollisimman vähän omien erityisvaatimuksien mukaisesti – eli kannattaa yrittää tehdä asioita tuotteen tarjoamilla tavoilla. Jos taas haluaa ehdottomasti tehdä asioita kuten itse parhaaksi näkee, niin silloin kannattaa suhtautua projektiin alusta asti räätälöidyn tietojärjestelmän rakentamisena.
Falckin kolumni on itse asiassa erittäin hyvä kannanotto erilaisten web-kehitysalustojen (kuten Django, Ruby on Rails, jne.) puolesta. Nämä kehitysalustat ovat erittäin potentiaalisia vaihtoehtoja tilanteissa joissa ollaan toteuttamassa hyvin räätälöityä verkkopalvelua ja perinteiset sisällönhallinta- ja julkaisutoiminnot eivät ole vaatimuslistalla kärkipäässä. Julkaisujärjestelmätuotteiden vastaisena kannanottona kolumni on kuitenkin surkea esitys.
Julkaisujärjestelmäthän ovat vähän kuin farmarivolvoja: turvallisia, ehkä vähän kulmikkaita, mutta käyttötarkoituksessaan erittäin toimivia ja luotettavia työvälineitä. Web-kehitysalustat ovat taas lähempänä rata-autojen rakennussarjoja. Se, että herra Falck ei ole pärjännyt farmarivolvolla Ferraria vastaan radalla ei tee farmarivolvosta vielä mitenkään epäonnistunutta tuotekategoriaa.
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!
14 kommenttia on “Onko julkaisujärjestelmien aika ohitse? Vastaus: Ei.”
Kommentointi on suljettu.
Jaa
Aika köyhä artikkeli. Jotenkin nämä Sharepointista leivän saavat tyypit on täysin jämähtäneet omaan maailmaan. Tämä ohuesti ja lyhyesti perusteltu lause kertonee kaiken:
“Julkaisujärjestelmätuotteiden vastaisena kannanottona kolumni on kuitenkin surkea esitys.”
Viertityspalkki on kyllä menossa kovaa tahtia alaspäin, kun jokaisessa artikkelissa on oma leipä kyseessä. Jos joku uhkaa työnantajan asemaa, niin heti tartutaan kynään ja todetaan asia “surkeaksi esitykseksi”
Kenneth Falck
Mukava nähdä, että aihe herättää mielipiteitä. ;-) Omasta puolestani voin sanoa, että tuollaisten tiiviiden ja kärkevien kolumnien idea onkin tosiaan enemmän herättää ajatuksia kuin tarjota niitä valmiina. Tässä tapauksessa halusin muistuttaa, että jos jokainen projekti lähtee aina liikkeelle “sen oikean CMS:n” valitsemisesta, niin parempiakin vaihtoehtoja saattaa olla.
Perttu Tolvanen
Kiitos Kenneth vain hyvästä kolumnista. Kärjistin itsekin vastauksessa, niin saadaan keskustelua (vaikka tuo eka kommentti nyt ei kyllä vastausta ansaitsekaan). On aivan totta, että CMS-järjestelmiin suhtaudutaan liian usein annettuna paradigmana. Säännöllisesti itsekin totean asiakkaille, että “onkohan tämä ajatus tehdä tämä sharepointilla nyt ihan loppuun asti mietitty” (tai ainakin tämän suuntaisesti). Ei ole kenenkään etu tehdä järjestelmillä asioita joihin niitä ei ole suunniteltu. Etenkään tuotteisiin erikoistuneet integraattorit eivät sellaiseen edes kannusta. Enemmän kyse on siitä, että asiakkaat ovat jo ennen koko tarjouskilpailua tai projektin aloittamista tehneet jossain kabineteissa päätöksiä siitä, että “tämä projekti tehdään tämän CMS:n päälle”. Ja tätä ajattelua pitääkin kyseenalaistaa, koska kyllä ne työkalut pitää projektin mukaan pystyä valitsemaan silloin kun todella on tärkeätä saada laadukas lopputulos.
Toki on tilanteita joissa päädytään tekemään räätälöityjäkin kokonaisuuksia kankean julkaisujärjestelmän päälle, mutta silloin siihen pitää olla hyvät syyt. Joskus ne ovat turvallisuuteen liittyviä syitä, tai kumppanivalintoihin liittyviä, tai lisenssikustannuksiin, tai yksinkertaisesti tarpeeseen yhtenäistää hajanaista arkkitehtuuria – mutta mitä tahansa ne sitten ovatkin, niin sitten pitää tiedostaa se asia, että jotkut asiat voivat olla vaikeampia kuin tehtäessä jollain toisella tavalla. (Ja kunhan ymmärretään se tärkein asia: Sitten kun lelut on valittu ja projekti käynnissä, niin pidetään turpa kiinni ja tehdään palvelu niin hyväksi kuin mahdollista. :)
Ihan toinen asia on sitten se, että kuinka moni firma tekee tuollaisia “erittäin räätälöityjä verkkopalveluita”. Mediatalot kyllä, mutta eivät monet muut. Ja mediataloillakin on kovin erilaisia projekteja. Ei verkkolehteä kannata lähteä yleensä räätälinä tekemään – mutta jotain pelisaitin tekemistä tuskin kannattaa taas sitten julkaisujärjestelmän päälle toteuttaa.
Nuo web-kehykset hämärtävät jonkin verran rajaa tuotteiden ja räätälöityjen toteutuksien välistä, mutta eivät kyllä olennaisesti. Hyvin tehty tuotepohjainen toteutus nauttii päivitettävyyden eduista ja riippumattomuudesta yhdestä integraattorista/koodareista. Räätälöity toteutus joustaa ja mukautuu, mutta hintana on räätälöity, yksilöllinen kokonaisuus ja usein siitä seuraava riippuvaisuus yhdestä integraattorista/tiimistä.
Janne Jääskeläinen
“Sitten kun lelut on valittu ja projekti käynnissä, niin pidetään turpa kiinni ja tehdään palvelu niin hyväksi kuin mahdollista.”
Paras pointti koko jutusta. :)
Mitä tulee tuohon anonyymin raukan kommenttiin: olisiko fiksua laittaa artikkeleiden kainaloon joku kirjoittajan disclaimer/esittelyboksi, että satunnaisempikin lukija tietäisi missä olet töissä ja mitä teet? Meille sisälukutaitoisille se ei nyt ole välttämätöntä. ;)
Nih, ja työkalut valitaan tarpeen mukaan, eikä yritetä aina vääntää sitä kolmion muotoista palikkaa siihen pyöreään reikään.
Jani Hovila
Samoilla linjoilla kuin Janne. Jos lähdetään vasaralla ruuvaamaan ruuveja seinään, ei siitä kovin hyvä voi tulla. Ehkä toimiva, muttei hyvä.
Eli omasta mielestäni näkökulma pitäisi olla miksi tehdään, mitä tehdään ja sitten vasta että millä helevetillä tuo saadaan tehtyä.
Hans Vallden
Hyvien CMS-tuotteiden perusfilosofia lienee se että toistuvat tarpeet on pyritty ratkaisemaan vakioidulla tavalla. Hyvä CMS-tuote mahdollistaa mielestäni myös uniikkien tarpeiden ratkaisemisen tavalla jossa trade-off uniikin ominaisuuden rakentamisella vakioidun tuoteympäristön ehdoilla on mahdollista ja kannattavaa. Pareto-sääntönä väitän että 80% yritysten (ehkä muidenkin) verkkojulkaisemisen tarpeista on ratkaistu jo (enemmän tai vähemmän tuotteesta riippuen) optimaalisesti CMS-tuotteilla ja jäljelle jäävistä 80% voidaan ratkaista hyvällä CMS-tuotteella kannattavasti. Näin ollen muunlaiset tarpeet marginalisoituvat.
“Tuote vs. ei-tuote”/ “Geneerinen vs. räätälöity”/ “CMS vs. Framework” -problematiikkaa voi pohtia myös liiketoiminnan kannattavuuden ja jatkuvuuden näkökulmasta. Hyvällä julkaisujärjestelmällä tuotteen elinkaaren aikaisten palveluiden tuottaminen on mahdollista toteuttaa vakioidusti ja vakioiminen on laadun perusta. Vaikka en väitäkään etteikö kilpailevalla tuotantotavalla pystyttäisi vakiointiin tai korkeaan laatuun, on se epäilemättä haastavampaa. Miten rakennetaan vaikkapa korkealaatuinen käyttäjätuki- tai hosting-palvelu jos jokainen ratkaisu on asiakaskohtainen ja uniikki? Miten se tehdään kannattavasti ja kilpailukykyisesti? Miten laatua ylläpidetään liiketoiminnassa vuodesta toiseen työntekijöiden, yhteyshenkilöiden, koodaajien, vaihtuessa? Väitän että tämä on verkkojulkaisemisen haasteista ehkä olennaisin, koska evidenssi viittaa vahvasti siihen että elinkaaren aikaiset kustannukset ovat omistamisen kustannuksista se jäävuoren vedenalainen osa.
Jussi Sivonen
Kyyninen kannanotto. Voiko olla, että näitä ratkaisuja tarjoavat talot hyötyvät rahallisesti siitä, että toteutetaan asiakkaan haluamat jutut liikaa niitä korjaamatta niin saadaan korjata niitä ensikin vuonna päivitysten yms. yhteydessä..
Mutta joo, tuolla jo aiemmin mainittu asiakkaan käsitys siitä, että mitä halutaan tehdä ja etsitään siihen natsaava työkalu on ehdoton lähtökohta hyvän lopputuloksen kannalta. Jos oma osaaminen ei riitä, niin sitten pitää löytää asiaa tunteva kumppani auttamaan selvitystyössä.
Vesa Palmu
Lähtökohtaisesti jo termi CMS on niin laaja ja kuormitettu että se joutaisikin kuolemaan pois. Suppean käsityksen termistä CMS saa esimerkiksi Real Story Groupin kartasta: realstorygroup.com/vendormap/ – Suht helppoa nähdä miksi termi “CMS” pitäisi haudata.
Ohitetaan kuitenkin terminologian ongelmat hetkeksi. Olen “CMS-järjestelmien” kuolemasta eri mieltä useammasta syystä. Ensinnäkin Kennun kannanotto koskee vain isoja projekteja. Jos budjetissa on vähintään kuusi numeroa voi räätälöinti frameworkin päälle toisinaan olla järkevä vaihtoehto. Lukumäärällisesti ylivoimaisesti suurin osa verkkopalveluista tehdään kuitenkin merkittävästi pienemmillä budjeteilla ja näissä valmis CMS on oikeastaan ainoa ratkaisu. Kukkien istuttamiseksi parvekkeelle ei kannata tilata kaivuria.
Isommissa projekteissa valmiimpi alusta parantaa hurjasti sekä laatua että toteutuksen kustannustehokkuutta. Kennu on myös itse vähän harhautuu tälle puolelle puhuessaan Railsin ja Djangon CMS-laajennuksista. Missä menee CMS:n ja frameworkin välinen raja?
CMS-tuotteen (Fatwire, SDL Tridion, EZpublish, Navigo..) kanssa joutuu helposti kuvatunlaisiin ongelmiin jos valmis toiminnallisuus ei enää riitä. Oman kokemukseni mukaan CMS-tuotteet ovat loistavia kunhan niitä käytetään kuten niiden kehittäjä on tarkoittanut. Pyörää ei kuitenkaan tarvitse keksiä uusiksi jokaisessa isossakaan projektissa ja hyvällä projektinhallinnalla voi monimutkainenkin projekti onnistua CMS-tuotteellakin. Tämä sanottuna allekirjoitan kyllä Kennun mainitsemat ongelmat monessa isossa projektissa CMS-tuotteiden kanssa. Lisäisin vielä päälle riesaksi jopa kuusinumeroisiksi nousevat lisenssikulut (+vuosikulut) joiden hinnalla koodailee jo melkoisesti omalla tiimillä.
Ihan erillinen kategoriansa ovat mielestäni CMS-tuotteiden ja frameworkkien välissä olevat platformit. Esimerkkeinä tästä Drupal, Sharepoint ja Plone. Rajat ovat toki melko veteen piirrettyjä. Platformien ympärillä on usein massiivinen ekosysteemi ja sisäänpääsyn kynnys on merkittävästi korkeampi, puhumattakaan sitten koko ekosysteemin seuraamisesta. Itse katson tilannetta Drupal-lasit päässä: Drupal on tänään sama asia kuin reilusti yli 7000 projektia, kymmeniä tuhansia aktiivisia platformin kehittäjiä, miljoonia saitteja ja tuote joka kehittyy nopeasti sekä välillä ennalta-arvaamattomiin suuntiin.
Vaikka teemme Mearrassa lähes pelkästään Kennun mainitsemassa kokoluokassa olevia projekteja Drupalilla ei omissa projekteissamme ole ollut lainkaan Kennun mainitsemien kaltaisia ongelmia. Vastaavia ongelmia olemme toki Drupal-projekteissa nähneet ja paljon myös korjailleet. Toisaalta meidän osaamisemme ja toimintatapamme on kiedottu Drupalin ympärille ja pystymme toteuttamaan lähes minkä tahansa konseptin ongelmitta hienosäätämällä sitä miten asiat toteutetaan liiketoimintatavoitteet samalla saavuttaen.
Asettaisinkin rohkean vastaväitteen että teknologiariippumattomat toteutustiimit ovat historiaa.
Laaja ja tehokas platform ekosysteemeineen vaatii hurjasti työtä organisaation osaamisen ylläpitämiseksi. Lisäksi frameworkillä, platformilla tai CMS-tuotteella kaikilla vaaditaan myös erilaista toteutusprosessia jotta homma todella pysyisi hanskassa. Pidän epärealistisena sitä että yksi tiimi voisi hyppiä teknologiasta ja toimintatavasta toiseen jatkuvasti projektien välillä. Ainoa tapa enää pärjätä teknologiariippumattomana toteuttajana on keskittyä “helpompiin” (ei toki teknisessä mielessä) vähemmän valmiisiin ratkaisuihin laskemalla samalla tuottavuutta.
Joko provosoin teknologiaorientoituneemman lukijakunnan voimakkaan vastareaktion? :-)
Pasi Valkeila
Komppaan Hansia hänen kommentissaan. Haasteita on nimenomaan siinä että tehdään kustannustehokkaalla tavalla verkkopalveluita, joilla käyttötuki voidaan toteuttaa järkevästi. Lyhyen elinkaaren suppeammat verkkopalvelut ovat tietenkin eri asia ja näihin Framework-ratkaisut ovat toimivia, päivitys/muutostyöhön vain menee aikaa ja sitä ei kovinkaan usein tiedosteta siinä vaiheessa kun verkkopalvelun alustaa suunnitellaan.
Loistava artikkeli.
Mika Tähtinen
Mielenkiintoista mainita ensin viitatun kirjoittajan provosoivasta linjasta ja kärjekkäistä väitteistä, ja sen jälkeen lopettaa kirjoitus lauseeseen: “Se, että herra Falck ei ole pärjännyt farmarivolvolla Ferraria vastaan radalla ei tee farmarivolvosta vielä mitenkään epäonnistunutta tuotekategoriaa.”
Oh Lord, joskus lisätessäni tämän blogin seurattavien listalle kuvittelin löytäneeni ensimmäisen laadukkaan suomenkielisen IT-alan blogin, mutta alashan tämänkin laatu on vajonnut.
Janne Kalliola
Käytän tässä puolikaupallisen puheenvuoron. Meillä Exovella on ensi viikolla torstaina (14.4.) aamiaisseminaari liiketoimintavetoisten sivustojen suunnittelusta ja toteutuksesta. L
Seminaari on tällä kertaa eZ Publish -vetoinen, joten puhutaan pitkälti CMS:n kyvyistä ratkoa erilaisia vastaan tulevia haasteita. Paikalla on myös eZ Systemsin Bertrand Maugain.
Me Exovella teemme töitä pääsääntöisesti eZ Publishin lisäksi Drupalilla ja CodeIgniterille, tosin myös Symfony, Joomla! ja CMS Made Simple ovat tuttuja projektityöstä. Teknologia valitaan asiakkaan tarpeen mukaan ja valintaan vaikuttaa teknologian sopivuuden lisäksi myös asiakkaan osaamistaso ja mahdolliset muut järjestelmät.
Emme näe mitään ongelmia useiden järjestelmien hallinnasta, ellei firma ole kovin pieni. Meillä jokainen koodaaja osaa (tai tulee aikanaan osaamaan) käyttää vähintään paria eri järjestelmää hyvin tai erinomaisesti. Syvä perehtyminen hoidetaan erikoistumalla eri osa-alueisiin, joista osa koskee kaikkia projekteja ja siten myös kaikkia järjestelmiä — vaikkapa tietoturva — ja osa on järjestelmäkohtaisia — esimerkiksi Drupalin suorituskyky.
Perttu Tolvanen
Vesan kommentti on kyllä poikkeuksellisen ansiokas tässä ketjussa. On hyvä erotella kolme eri mallia web-projektien tekemisessä: 1) Tuotteen päälle tehtävät projektit, 2) Platformien päälle tehtävät projektit, 3) Räätälöintiprojektit. On myös erittäin hyvä väite, että samat toteutustiimit eivät kovin helposti vaihda eri mallien välillä. Tästä olen erittäin samaa mieltä. Hyvää räätälöintijengiä ei kannata ärsyttää laittamalla se koodaamaan saittia jonkun CMS-tuotteen päälle (tai laajemmin projektia ei kannata mokata tekemällä niin koska se tiimi todennäköisesti “räätälöi tuotteen pilalle”). Myöskään kompaktin julkaisujärjestelmätuotteen kanssa touhunnut tiimi ei ota kovin helposti haltuun platformia jossa samat asian voikin tehdä 12 eri tavalla ja jokainen tapa vaatisi viikon perehtymistä.
Platformien päälle tehtävissä projekteissa on tärkeätä hakea tasapainoa tuoteosaamisen ja räätälöintiosaamisen välillä. Tuotteen kyvykkyys pitäisi aina katsoa loppuun asti ja vasta sen todella loppuessa pitäisi lähteä miettimään räätälöintiä – ja tällöin se räätälöinti pitäisi sitten osata tehdä sen platformin tarjoamien välineiden ja menetelmien avulla (ei siis oikeasti räätälöimällä puhtaalta pöydältä). Tässä kohtaa vaikkapa Drupal ja SharePoint ovat samantyyppisiä tuotteita. Niiden räätälöinti on tehtävä linjassa platformin filosofian ja valmistoimintojen kanssa. Haasteena on se, että tällainen oikeanlainen räätälöinti edellyttää syvää ja leveätä tuotetuntemusta. On siis tunnettava valmistoiminnot ja laajentamiseen tarkoitetut rajapinnat, apuvälineet ja periaatteet. Itse olen nähnyt sekä Drupalilla että SharePointilla tehtyjä projekteja ja täytyy kyllä sanoa, että SharePointilla olen nähnyt tehtävän paljon pahempaa jälkeä (kertoo myös platformin laajuudesta toki). Ja mitä pahempaa jälkeä tehdään, niin sitä lähempänä ollaan räätälöityä toteutusta jossa tuotteesta on enemmän haittaa kuin hyötyä. Täten olenkin täysin samaa mieltä siitä, että etenkin platformien kanssa on todella tärkeätä hyödyntää erikoistuneita tiimejä – ja laajemminkin olen samaa mieltä siitä että tulevaisuudessa yhä enemmän tiimit erikoistuvat osaamaan tiettyjä platformeja ja tuotteita. Tämä huippuosaamisen tarve korostuu etenkin kun käytetään platformia johonkin käyttötarkoitukseen joka ei ole ollut sen suunnittelijoiden fokuksessa platformin toimintoja suunniteltaessa (esim. kun käytetään SharePointtia vaativissa web-julkaisuskenaarioissa, tai kun yritetään tehdä Drupalista intranet-alustaa).
Pidemmälle paketoitujen tuotteiden kanssa haltuunottokynnys on selkeästi matalampi tiimin osaamisen kannalta, mutta se vaatii sitten myös asiakkaalta toisenlaista asennoitumista tekemiseen. Tuotteiden kanssa pitää mennä tuotteiden ehdoilla – eli myös sitä omaa, hienoa konseptia ja mainostoimiston tekemää upeaa leiskaa pitää taivuttaa mukautumaan tuotteen tarjoamiin toimintoihin. Tämä ei sitten vaadikaan siltä tuotetiimiltä ihan samankaltaista osaamistasoa kuin platformien kohdalla. Erona on mielestäni se, että tuotetiimillä on aina demo käytössään ja tuotetiimi voi näyttää että “miten homma toimii” ja sitten voidaan miettiä että pärjätäänkö sillä vai ei (vai jätetäänkö koko ominaisuus pois esim.). Platformien kohdalla vaihtoehtoja toteutukseen on aina useita ja asiakkaan kannalta eteneminen on paljon haasteellisempaa – mutta tarjoaa toki enemmän mahdollisuuksia saada tehtyä homma platformin päälle ja hyödyntäen sen tarjoamia palveluita.
Esim. Exoven kohdalla sanoisin, että talossa voi olla useita tuotteita kyllä – ja ne voivat olla hallinnassakin – mutta enemmän kuin yksi ei voi olla platform-tyyppinen megatuote. Yksikin platform-tyyppinen tuote (Drupal, SharePoint, Plone, LifeRay, jne.) on helposti niin laaja ja monimutkainen, että siihen pitää todella erikoistua jos haluaa tehdä siedettävää toteutusjälkeä sen avulla. Tämän platformin rinnalla voi olla 1-2 kompaktimpaa tuotetta sitten joilla voidaan tehdä projekteja tilanteissa joissa platform olisi liian raskas tai platformin valmistoiminnot eivät tarjoa riittävästi valmista asiakkaan tarpeisiin. Täten esim. Drupalin rinnalla voisi kuvitella tarjottavan eZ Publishia, SilverStripeä tai jotain muuta kompaktimpaa julkaisujärjestelmätuotetta. SharePointin rinnalla nähdään jo nyt erittäin monella toimijalla olevan oma julkaisujärjestelmätuote ja/tai esim. EPiServer/Sitecore/Umbraco. Myös moni LifeRay-toimittaja käyttää edelleen omaa web-julkaisujärjestelmää.
Disclaimer: Kommentin kirjoittaja työskentelee teknologiavalintoihin ja sisällönhallinnan tiekarttoihin erikoistuneena konsulttina Sinisen Meteoriitin konsultointiyksikössä. Sininen Meteoriitti on johtavia Microsoft SharePoint-integraattoreita Suomessa.
Janne Jääskeläinen
Hyviä kommentteja, Vesa ja Perttu.
Kuten Perttu tuossa arvelikin, järeämmän platform-tuotteen rinnalla on järkevää pitää myös hieman erilaista julkkaria, joka soveltuu paremmin esimerkiksi pienempien ja notkeampien kokonaisuuksien leipomiseen. Meillä Aucorissa on käytössä Drupal ja SilverStripe, ja tuotteet täydentävät toisiaan varsin hyvin.
(P.S. hyvä disclaimer ;)
Julkaisujärjestelmät Suomessa vuonna 2011 – Vierityspalkki.fi
[…] 2011 julkaisujärjestelmistä riitti puhetta varsin kiitettävästi. Kenneth Falck povasi julkaisujärjestelmien kuolemaa Tietokone-lehden kolumnissaan, mutta käytännössä asiakkaat tuntuivat olevan vain entistäkin innokkaampia ostamaan […]