Publiseringsløsninger for nettet. Kommersielle rammeverk, egne leverandørsystemer eller åpen kildekode
I denne artikkelen vil jeg prøve å sette søkelyset på valg av publiseringsløsning for nettet. Bør man velge kommersielle rammeverk, leverandørers egenutviklede løsninger eller åpen kildekode. Svaret er ikke gitt, og man bør ta slike valg etter nøye vurdering av flere faktorer. Derfor vil jeg gi en oversikt over hva jeg mener er viktig, og hvordan valget best kan tas.
Noen definisjoner og begrepsavklaringer
For det første vil jeg poengtere at publiseringsløsning ikke er det samme som Content Managment System (CMS). En publiseringsløsning kan være dette, men det er mange som langt fra kan sies å være noe i nærheten av et riktig CMS. Ellers vil man finne alt fra enkle systemer til omfattende rammeverk.
Med kommersielle rammeverk eller Content Managment Framework menes systemer som gir et rammeverk for å bygge all den funksjonalitet som er nødvendig, eller systemer som modulmessig er mer eller mindre komplette. Dvs løsninger som håndterer alt fra nettbutikk, nettavis, forum etc. Typiske løsninger her er Interwoven, RedDot CMS, Vignette og MS Content Server, BEA portals. Men krever betydelig konfigurering og programmering. Lisenspolitikk er ulik. Prisklasse som oftes over kr 250 000,- !break!
Egenutviklede leverandørløsninger er pakkeløsninger som mindre leverandører (også større) har pakket sammen på bakgrunn av f.eks. PHP, Java eller .Net basert teknologi. Typisk er disse grunnpakker med mulighet til å utvide funksjonalitet gjennom tilleggsmoduler. Som oftest er disse løsningen primært rettet mot publisering, men løsninger for netthandel med mer finnes. Løsninger på det norske markedet er CoreTrek, EasyPublish, EpiServer, Gloria og utrolig mange flere. Grensen mellom disse og rammeverk kan være vanskelig å trekke. Men typisk er de raskere å konfigurere til et fungerende nettsted. Pris fra 10 000,- til langt over 100 000,-. Vanlig er også årlig vedlikeholdsavgift. !break!
Åpen kildekode er systemer uten lisenskostnader samt rettighet til å gjøre endringer i kildekode. Med visse betingelser. Systemene her spenner over hele spekteret fra enkle løsninger til løsninger i klasse med kommersielle rammeverk. Mulige systemer er TYPO3, Mambo, Joomla, Drupal, EZpublish, Plone, PostNuke og flere.
TCO eller total kostnad for eierskap, er et begrep som brukes for å angi den totale kostanden for et datasystem. For nettløsninger er dette typisk lisenskostnader, maskinvare, kostnader til implementering og tilpassing, samt løpende kostnader til drift og innholdsadministrasjon.
Web standards omhandler i realiteten alle de standarder som W3C administrerer. BÃ¥de HTML, XML, SOAP, WCAG med flere. Standardene er ikke statiske, men utvikler seg klart i takt med den teknologiske utviklingen. !break!
<break>
De sentrale spørmålene
Det første spørsmålet å stille seg er hvor viktige nettsidene vil være for bedriften/organisasjonen. Er nettsidene sentrale for å oppnå bedriftens strategier og mål. En nettbutikk eller organisasjoner der nettet vil være den sentrale kommunikasjonskanalen må stille andre krav en dagligvaren på hjørnet. Men man bør være klar over at flere og flere bruker nettet som viktig informasjonskilde uansett hvilke varer og tjenester man er ute etter.
Det andre spørsmålet er i hvilken grad man sitter på nødvendig kompetanse i egen bedrift/organisasjon. Her tenker jeg ikke på kompetanse til å lage nettsider eller drifte en webserver, men kompetanse til å lage et godt nok grunnlag for å kunne velge tekniske løsninger og rett funksjonalitet. Faktisk bør man vite nøyaktig hva man er ute etter før man i det hele tatt kontakter noen som helst leverandør av systemer, og tankene bør gå mer enn 1 år fram i tid. Først når man har en kravspesifikasjon på plass kan man be leverandører om tilbud. Og her er det ikke nødvendigvis nok å ha teknisk kompetanse, men også kompetanse knyttet til internett, kommunikasjon og forretningsprosesser. !break!
Kan ikke leverandørene hjelpe oss med dette da! Ikke etter min mening. Leverandørene lever av å selge løsninger og vil primært være opptatt av å selge sin løsning. Noe forskjell vil det være mellom leverandører som primært selger integrasjon og implementering og de som selger sine egenutviklede løsninger. Det betyr at man fort vekk kan velge en løsning som er dobbelt så dyr som nødvendig, eller like ille, velge en løsning som er lite skalerbar og er vanskelig å tilpasse nye krav etter tid. !break!
Et tredje spørmål er om man selv skal drifte ferdig løsning teknisk eller sette dette bort til andre.
Krav til løsningen
Hvilke krav bør man sette til en løsning. I korte trekk mener jeg følgende generelle krav kan settes. !break!
- Den skal kunne produsere sider som følger W3C sine standarder, primært XHTML samt WCAG 1.0
- Ikke bruke javascript eller andre script til å lage sentrale element som for eksempel menyer, eller ha alternativer.
- Ikke bruke ugyldige HTML koder og attributter
- Primært legge layout på sider ved div-tag og ikke tabeller.
- Det skal være forholdsiv enkelt å adminstrere nettstedet, dvs opprette og gi tilgang til brukere som skal legge inn innhold, samt justere funksjonalitet. Tilgang skal kunne tilpasses behov.
- Det skal være lett for de som legger inn innhold og gjøre dette. Gjerne mulighet å gjøre dette direkte fra redigeringsikon i selve nettsidene (for brukere som er innlogget med slike rettigheter).
- De må støtte teknologier/protokoller som LDAP (brukerhåndtering), XML, SOAP og andre former for web standards. Også nødvendige sikkerhetsprotokoller.
- Sidene skal fungere godt i forhold til søkemotorer. Store mengder css og script før relevant innhold er her lite hensiktsmessig. Rett og god bruk av metatagger er til god hjelp
- Vedlikehold, oppdatering av system samt implementering av tilleggsfunksjonalitet skal kunne gjøres på en enkel måte.
- Nettstedets design må kunne endres/justeres uten at innhold må oppdateres - dvs innhold og design skal ha optimal separasjon.
- Løsningen må være skalerbar.
!break!
Det er sikkert andre forhold som bør vektlegges, men jeg mener dette er noen av de sentrale.
<break>
Om de ulike typer løsninger
Her vil jeg komme med en del generelle for og mot betraktninger rundt de ulike løsningstypene. Nå sitter jeg ikke med detaljert kunnskap, og bygger derfor mine betraktninger på ulike kilder. Da systemene innen hver gruppe varierer vil dette også måtte være på svært grovt plan. !break!
Kommersielle rammeverk
For:
- Stor installert base, stor overlevelsesevne hos produsent.
- Kompetanse vil finnes hos mange andre enn den som utfører implementeringen.
- Stor fleksibilitet (hos de fleste løsningene).
- Følger jevnt over nødvendige standarder bra, men endelig resultat er svært avhengig av implementeringen, dvs kunnskap hos den som utfører denne.
- Svært skalerbare.
Mot:
- Høye lisenskostnader.
- Høye implementeringskostnader.
- Krever betydelig kompetanse dersom de skal driftes internt.
Tolig er det først ved svært store eller svært funksjonsrike installasjoner bruk av disse rammeverksløsningene er hensiktsmessige.
Egenutviklede leverandørsystemer
For disse systemene er det vanskelig å gi generelle karakteristikker. Til det varierer løsningene alt for mye i størrelse og funksjonalitet. Allikevel er mange preget av de samme problemer og begrensinger. !break!
For:
- Som oftest betydelig enklere implementering enn rammeverk.
- Lisenskostnader på et fornuftig nivå.
- Mange er enkle å bruke for de med ansvar for innlegging av innhold.
Mot:
- Mange løsninger har problemer med nyere standarder.
- All tilleggsfunksjonalitet koster penger.
- Tildels lite skalerbare.
- Små utviklermiljø og få som kjenner systemet innvendig. Skulle leverandørene få problemer og forsvinne fra markedet er som oftest eneste løsningen å velge nytt system.
- Funksjonalitet utover det systemet egentlig ble laget for kan være svært vanskelig å implementere.
Selv om startkostnadene på slike systemer ofte er begrenset, kan TCO bli betydelig dersom man vokser ut av løsningen.
Ã…pen kildekode CMS-systemer
Også her er det vanskelig å komme med klare fellestrekk. Igjen er årsaken variasjon i systemene når det gjelder oppbyggingsmåte, funksjonalitet og modenhet. Systemer som primært er laget for weblog, arbeidsgrupper, e-læring er svært ulike med mer komplette løsninger som TYPO3, Plone, Drupal, Mambo med flere. Til og med disse er ikke nødvendigvis i samme klasse. !break!
For:
- Ingen lisenskostnader.
- Full tilgang til kildekoden for systemene.
- Bygger på gode og annerkjente script-/programmeringsspråk.
- Med tilleggsmoduler (gratis) kan omtrent hver eneste mulig funksjonalitet gis systemet. Tilleggsmoduler er ofte enkle å utvikle.
- Følger jevnt over godt standarder, men mange mangler protokoller knyttet til LDAP, SOAP med mer.
- Kan fritt tilpasses for å løse egne behov optimalt.
- Som oftest store utvikler og brukermiljøet, noe som gjør det enkelt å finne tak i kompetanse. Om det lokale fimaet som opprinnelig implementerte skulle være borte om to år, er det kurant å finne andre som kan løsningen.
- Stor installert brukerbase. Systemene er ofte oppe å går på tusen til hunderetusenvis av servere.
- De gode systemene er svært skalerbare både i funksjonalitet og størrelse/antall sidebesøk pr dag. TYPO3 f.eks finnes på webhotell med 200 - 500 besøkende pr mnd, til nettsteder som går på 5 - 10 servere, med 1000-vis av sider og kanskje flere millioner besøkende pr mnd. Antall tilleggsmoduler er omkring 1 000.
!break!
Mot:
- Ingen offisiell brukerstøtte/support.
- Utvikling skjer på frivillig basis i stor grad. Kan medføre stopp i utviklingen. Nå har de største systemene bygd opp mer formelle organisasjoner for å ivareta framdrift i utvikling av det sentrale i systemene.
- Uenighet i utviklermiljø kan medføre at et system blir til to system som utvikler seg hver sin retning (dette har skjedd i Mambo miljøet).
- Implementering kan ha høyere kostnad enn leverandørutvikla systemer, men jevnt over betydelig lavere enn for rammeverk.
- Brukervennlighet varierer (de beste er svært brukervennlige)
!break!
Den største ulempen med åpen kildekode ligger nok i usikkerhet om hvordan systemet vil utvikle seg, og om det vil bli utviklet. I bruk i kommersielle sammenhenger og i organisasjoner bør man derfor velge åpen kildekode der utviklermiljø er godt organisert, og/eller har god støtte fra kommersielle aktører.
<break>
Konklusjoner
Enhver etablering av eller endring av leverandør/system for nettsider bør gjøres etter en grundig vurdering av flere forhold. Selv om nettsidene ikke er strategisk viktig for organisasjonen bør man både være klar over at dette endrer seg over tid. Så selv for mindre organisasjoner/bedrifter bør man koste på seg å gjøre en skikkelig behovsanalyse samt lage en kravspesifikasjon. Selv om man trenger ekstern hjelp, vil en kostnad på 10 - 20 000,- kr fort spares inn senere. Leverandører av spesifikke system bør aldri engasjeres til å gjøre denne jobben. !break!
Valg av system gjøres på bakgrunn av kravspesifikasjon. Og man bør velge det systemet som har lavest TCO over en femårsperiode og som tilfredstiller kravspesifikasjonen, dvs de generelle krav samt organisasjonens behov. Og etter min mening bør man alltid vurdere om det finnes løsninger bygd på åpen kildekode som er gode nok (i 98 % av tilfellene gjør de det). Men det bør finnes leverandører som implementerer slike løsninger tilgjengelig. !break!
Systemer som ikke produsere sider som tilfredstiller W3C standarder bør uansett ikke velges. Det samme gjelder systemer med historie for mange sikkerhetsproblem.
Og gjør en kvalitetsjekk av aktuelle leverandører. Viser det seg at leverandørens egne sider har lav kvalitet, eller det gjelder referanser, bør man stille spørsmål om leverandørens evne til å levere et godt produkt.
- Linker:
- CMS Matrix
