Managed hosting door True

Grote websites bouwen met high-end gereedschappen

Toe aan een 'tool'

Veel grote Nederlandse bedrijven hebben al meerdere generaties websites achter de rug. Het maken en uitbreiden ervan is vaak zelfs een continu proces. De eerste generatie bestond uit statische pagina's. De tweede was al dynamischer door bijvoorbeeld een koppeling aan een content-database. De derde generatie netplekken is gekoppeld aan de bestaande systemen van de organisatie. Erik Harmoen, Technisch Directeur, vindt dat het Nederlandse bedrijfsleven toe is aan een 'tool'.

Een eerste generatie site kon nog door een aantal slimme hobbyisten van de it-afdeling gemaakt worden. Met een derde generatie lukt dat niet meer. De organisatie legt nu ambitieuze functionele wensen op tafel zoals de ontsluiting van bestaande systemen, personalisatie en het kunnen beheren van grote hoeveelheden content. De it-afdeling kan dat niet meer alleen aan en de marketingafdeling ziet de vele mogelijkheden die softwareleveranciers kunnen bieden. 'Tools' doen hun intrede.
Wat is er te koop. De keuze aan gereedschappen is overweldigend. Het makkelijkst zijn ze in te delen in twee prijscategorieën: de 'low-end' gereedschappen van enkele duizenden guldens voor de onderkant van de markt en de 'high-end' van meer dan 100.000 gulden voor de bovenkant van de markt. Onder low-end vallen producten als Active Server Pages (ASP) van Microsoft en PHP voor Linux. In de tweede, dure categorie zitten bijvoorbeeld Vignette, Broadvision, Interwoven en ATG. Producten uit de eerste categorie zijn meestal niet veel meer dan een programmeertaal aangevuld met zaken als bijvoorbeeld 'database connection pooling'. De tweede categorie biedt naast een programmeertaal ook allerlei kant-en-klaar functionaliteit zoals bijvoorbeeld 'caching', 'staging', personalisatie, werkstroom- en 'release-management'-functies. Eén ding hebben de gereedschappen uit de twee categorieën gemeen: geen van beide biedt een eindproduct. In beide gevallen moeten programmeurs nog aan de slag om de site te ontwikkelen. De high-end gereedschappen bieden wel meer dan de goedkopere, maar zijn toch niet meer dan halffabrikaten. Hiermee krijgen de ontwikkelaars wel een vliegende start maar zijn ze nog zeker niet bij de finish.

Leveranciers

De high-end gereedschappen zijn zó duur, dat er goede redenen moeten zijn om er voor te kiezen. Voor dat geld kan er namelijk ook een hoop maatwerk worden ontwikkeld en dat is dan ook waar veel bedrijven nog steeds voor kiezen. Een eerste vuistregel is dat zo'n stuk gereedschap alleen nuttig is voor een website die (a) groot is, (b) veel bezoek zal trekken en (c) veel aangepast zal worden. Websites die niet in dat profiel passen kunnen meestal toe met low-end gereedschap. Als de website wel in dit profiel past en er is budget voor high-end gereedschap, komt vaak de 'gereedschap paradox' om de hoek kijken: als er geld genoeg is voor high-end gereedschap, dan zijn er meestal ook meer wensen dan het gereedschap ooit kan bieden. In dat geval komt het er meestal op neer dat meerdere 'tools' worden gecombineerd, en ze worden deels aangevuld maatwerk.
De keuze van een leverancier hangt nauw samen met de gewenste functionaliteit, de technische kennis en voorkeuren binnen de organisatie, en met de mogelijkheid om het gereedschap uit te breiden met eigen maatwerk of andere gereedschappen. ASP is bijvoorbeeld een goede low-end technologie binnen een Microsoft-omgeving. ATG Dynamo en de producten van Interwoven zijn een goede combinatie van respectievelijk een applicatieserver en 'deployment'- en release-management-gereedschap. Bij de producten van Broadvision ligt de nadruk iets meer op personalisatie en profilering van de gebruiker. Vignette biedt met zijn V/5 een sterk en robuust publicatie-gereedschap. Ook niet-technische argumenten zullen een rol moeten spelen bij de keuze. Met name het 'track-record' en support van de leverancier zijn cruciaal. Dit laatste is met name belangrijk omdat bugs vaak worden verholpen in een nieuwe release die niet makkelijk te installeren is halverwege het ontwikkelproces. Het is handig om specifieke afspraken hierover te maken met de leverancier. Zeker voor een grote klant zal hij bereid zijn de ondersteuningstermijn voor oude versies te verlengen.

Programmeren

Zijn gereedschap en leverancier eenmaal gekozen, dan stuiten de meeste organisaties op een volgend probleem: wie kan het bouwen? Bij de meeste grote organisaties is informatie-technologie niet de 'core business' en als er een goede it-afdeling is, dan zal die eerder gericht zijn op 'ouderwetse' it zoals mainframe en werkstationbeheer. Als de it-afdeling naast beheers- ook over ontwikkelcapaciteit beschikt, dan is die vaak gericht op mainframe- en 'klassieke' database-applicaties. Bovendien zal het meestal een cultuur zijn van lange it-trajecten die niet goed past bij de korte 'time-to-market' die noodzakelijk is bij het ontwikkelen van websites. De organisatie helemaal zelf de website laten ontwikkelen kan dus vaak niet. Het volledig uitbesteden van de website aan een externe ontwikkelaar is echter een te groot risico. Met name de onzekere toekomst van veel van deze bedrijven maakt het moeilijk een lange-termijnrelatie met ze aan te gaan. Meestal wordt er dan ook voor gekozen om een externe partij de ontwikkeling te laten doen en intern een aantal mensen bij te scholen of een aantal nieuwe mensen te werven die het applicatieve onderhoud van het systeem voor hun rekening kunnen nemen. Deze interne mensen kunnen dan 'meelopen' met de externe partij om al tijdens het ontwikkelproces ervaring op te doen met de code en het gereedschap.
Eenmaal aan de slag kunnen de ontwikkelaars snel gaan lijden onder het 'not invented here' syndroom. Met name bestaat dit gevaar als de interne it-afdeling de site ontwikkelt. Het gereedschap is immers nieuw voor hen en men heeft nog niet de internet-ervaring om te achtergronden ervan te begrijpen en te waarderen. Daarnaast kunnen de ontwikkelaars ook nog eens last krijgen van het 'not chosen here' syndroom, als niet zij maar de directie of de marketingafdeling de keuze heeft gemaakt. In het ergste geval gaat de it-afdeling een hele applicatielaag 'boven op' het gereedschap ontwikkelen, zodat het zich alsnog gedraagt als het gereedschap dat zij eigenlijk hadden willen hebben. Vaak lijkt de uitbreiding erg nuttig omdat de it-afdeling de wensen van de eigen organisatie als geen ander kent en meestal kan betogen dat het gereedschap hierdoor verbeterd is.
Toch is het onverstandig om aan deze verleiding toe te geven. Het geeft een soort 'interne vendor lock-in', een probleem als de architecten van deze uitbreiding overgeplaatst worden of ontslag nemen. Het ontkracht vaak de features van het gereedschap zelf. Het kan betekenen dat toekomstige features van het gereedschap niet goed meer bruikbaar zijn. Tot slot kan het ook nog betekenen dat de 'hosting' partij er een probleem bij heeft: gastheer spelen voor weer een extra module of uitbreiding. Met name als een stuk gereedschap voor het eerst wordt gebruikt in een organisatie kan daarom het beste de leverancier om hulp worden gevraagd. Er kan bijvoorbeeld voor gekozen worden om gedurende het gehele proces een consultant van de leverancier of één van zijn partners mee te laten lopen. Deze consultant heeft dan als taak het juiste gebruik van het gereedschap te bewaken. Deze consultant kan ook technische vragen beantwoorden en hij kan de 'liaison officer' zijn tussen klant en leverancier voor het oplossen van kritieke bugs.

Nachtmerrie

Een eerste generatie website kon nog worden uitbesteed aan een 'host'. Bij sites van de derde generatie zullen met name grote organisaties daar grote bezwaren tegen hebben. Dit zijn namelijk de sites die koppelingen hebben met interne systemen voor zaken als klantgegevens en transactieverwerking. Deze sites buiten de deur laten 'hosten' betekent dus dat derden toegang moeten krijgen tot de interne 'core'-systemen van de organisatie. Voor de meeste grote organisaties is dat onbespreekbaar. Er zit dus niets anders op dan de interne beheersafdeling hiervoor in te schakelen. Ook hier duiken weer twee bekende problemen op: gebrek aan kennis en een cultuur waarbinnen niet 'snel geschakeld' wordt. Er duikt hier echter nog een nieuw probleem op: de traditioneel gebrekkige contacten tussen de ontwikkelgroep en de beheersgroep. In de meer klassieke it-projecten wordt dit probleem afgedekt door lange en uitgebreide procedures van onderlinge overdracht, maar daar is bij het ontwikkelen van een website geen tijd voor. De 'time-to-market' is hier cruciaal. Als klap op de vuurpijl zijn internetsystemen vaak complex en instabiel en dus niet bepaald eenvoudig te 'hosten'. Ze zijn complex omdat ze bestaan uit veel componenten: webserver, contentmanagementsysteem, contentdatabase, site-statistieksysteem, 'webvertisement'-systeem en dan ook nog de koppelingen naar reeds bestaande systemen in de organisatie. Ze zijn instabiel omdat ook voor de gereedschapleverancier geldt dat de 'time-to-market' heilig is. Hun motto is: eerst marktaandeel veroveren en dan pas het product uitontwikkelen.
Voor een goed gastheerschap is het cruciaal de 'hostende' partij, of die nu intern of extern is, er zo snel mogelijk bij te betrekken. Bij voorkeur zullen ze mee moeten lopen in het ontwikkelproces en betrokken moeten zijn bij het opzetten van de architectuur, net als de mensen die het applicatieve beheer gaan doen. Dat is in grote organisaties ongebruikelijk, maar het is cruciaal voor het welslagen van het gastheerschap. Daarnaast zal de 'hosting' partij gelijk moeten gaan nadenken over de manier waarop zij de site 'in de lucht' kunnen houden. Dit zal de uitbreiding of introductie van 'monitoring'-software betekenen. Mogelijkerwijs zullen er zelfs kleine stukken maatwerk voor deze monitoring moeten worden ontwikkeld. Sites waarbij dit niet goed geregeld is zijn snel te herkennen: dat zijn de sites die in de loop van de vrijdagavond langzaam afsterven en maandagochtend weer beschikbaar komen als de 'host' weer op kantoor is. Bepaald geen acceptabele situatie als je internet als volwaardig verkoopkanaal beschouwt.

Rol projectmanager

Het programmeren van een website lijkt op een gewone it-klus. Er is echter één belangrijk verschil: de doorlooptijd. Bij gewone it-projecten is er tijd voor analyse, specificatie, ontwikkeling, documentatie, acceptatie, het testen, in productie name, beheer, enzovoorts. De 'time-to-market' is voor een webproject zo belangrijk dat deze zaken niet na elkaar maar gelijktijdig moeten worden uitgevoerd. Tegelijk met het programmeren wordt er gedocumenteerd, wordt de 'hosting' omgeving in gereedheid gebracht en vinden de eerste tests al plaats. Dit vergt een flexibele instelling van de organisatie en bovenal veel planning. De projectmanager zal voortdurend het kritieke pad in de gaten moeten houden. Het is namelijk vrijwel zeker dat dit kritieke pad verschuift gedurende het project. Bij extreem korte doorlooptijden kunnen hele triviale zaken als de levering van de licentie van een compiler of het beschikbaar zijn van de externe consultant ineens de bottle-neck gaan vormen. Daarnaast zal de projectmanager heel dicht op zijn project moeten zitten en betrokkenheid van alle betreffende afdelingen moeten hebben. Hij moet zich hiervoor voortdurend dagelijks informeren over de voortgang en genoeg macht hebben om lange procedures over te mogen slaan.
De eerste en tweede generatie websites werden slechts aan een bescheiden test-traject onderworpen. De derde generatie website is gekoppeld aan 'back-end' systemen van de klant en is daarmee veel bedrijfskritischer. Dit betekent meestal dat het test-traject een veelvoud is van het ontwikkeltraject. Deze verhouding komt meestal zo te liggen, omdat de bouw aan een snel werkende externe partij wordt overgelaten en het testen alleen door een langzaam werkende interne partij mag worden verricht. De eerste versie van de derde generatie site wordt meestal eerst 'intern' in productie genomen. Dit betekent dat alleen gebruikers van binnen de organisatie de site kunnen gebruiken voor het bekijken van hun klantgegevens en het verwerken van hun transacties. Om de verschillende tests goed uit te kunnen voeren moeten er meestal aparte 'teststraten' worden ingericht. Dit betekent niet alleen een oplopende hardwarerekening, maar ook een forse rekening van gereedschapleverancier, omdat er aparte licenties nodig zijn voor die straten.

Publiekelijk in productie

Zoals gezegd is het cruciaal dat de 'hosting' partij zeer vroeg betrokken is bij het ontwikkelen van de website. Dit mag echter niet betekenen dat de overdracht een informeel karakter krijgt. Zo moeten bijvoorbeeld installatiescripts tot in de laatste details worden beschreven. De korte doorlooptijd mag het ontwikkelproces een geïmproviseerd karakter geven, maar hij moet wel goed worden afgesloten. Is de site eenmaal in productie dan zal heel snel de vraag rijzen of er een 'upgrade' moet plaatsvinden van de gebruikte gereedschappen en producten. Immers, tussen het moment van versiekeuze en het in productie gaan van de website zit minstens zes tot negen maanden. Het is vrij zeker dat er in de tussentijd een versie is uitgekomen die diverse bugs oplost. Daar komt bij dat de meeste 'tool'-leveranciers drie maanden na het verdwijnen van een versie stoppen met de ondersteuning er van. Het upgraden naar een nieuwe versie is daarmee een pijnlijk maar noodzakelijk proces. Leveranciers claimen meestal dat de upgrade geruisloos kan gebeuren. Meestal is dit niet zo en is het verstandig de leverancier te vragen een consultant te sturen ter ondersteuning van die zogenaamde geruisloze actie.
 

Erik Hamoen Technisch Directeur Mirabeau
Tien tips

  1. Voor het bouwen van een grote site met veel verkeer en veel content-beheer bouwen is high-end gereedschap een optie. Zo niet, dan is low-end gereedschap goed genoeg.
  2. Leg vanaf het begin contact tussen de ontwikkelpartij en de 'hosting' partij.
  3. Betrek een consultant van de leverancier bij het opzetten van de architectuur en als technisch 'geweten' van het project.
  4. Bouw zo min mogelijk zelf, maar zo veel mogelijk met 'kant-en-klaar' functies van het gereedschap.
  5. Gebruik het gereedschap zoals bedoeld en bouw dus zeker geen applicatielaag bovenop het gereedschap zelf.
  6. Bewaak het voortdurend verschuivende kritieke pad.
  7. Test alleen uitgebreid (maanden) als het een applicatie-website betreft met koppeling naar 'back-end' systemen.
  8. Bouw en/of selecteer tegelijk met de site een 'monitoring' systeem.
  9. Bind gereedschapleverancier aan een (verlengde) ondersteuningstermijn.
  10. Probeer met de ontwikkelende partij tot afspraken te komen voor de lange termijn.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.