Tag Archives: TCO

Presentatie: Zarafa, van closed naar open

De onderstaande presentatie is gegeven als inleiding voor een workshop Zarafa. Hoewel de workshop “hands-on” was, is het belangrijk dat de deelnemers begrijpen wat nu precies de verschillen zijn tussen proprietary software en open source software. Deze presentatie gaat daarom in op de 5 wetmatigheden van de “digitale wereld”. Deze wetmatigheden zijn kort gezegd:

  1. Digitaal delen is vermenigvuldigen,
  2. Geen afnemend nut van kopieën,
  3. Kopiëren (of delen) tegen verwaarloosbare tijd en kosten,
  4. De economie van het delen en,
  5. Geen monopolie op de productiecapaciteit.

Daarnaast wordt ingegaan op de effecten hiervan op de muziek- en film industrie. Ook wordt uitgelegd wat het verschil is tussen producten maken, of diensten leveren en de gevolgen hiervan op de organisatie.

Deze presentatie is gehouden in september 2012, tijdens een Zarafa workshop die door Zarafa en Stone-IT is georganiseerd.

 

Business case: Zarafa vs. Microsoft Exchange

In de ict is het gebruikelijk om voor productkeuzes een business case op te stellen. Dit belicht de bedrijfsmatige en vaak financiële kant van de verschillende alternatieven. Zo kan een afgewogen en verstandige keuze gemaakt worden voor bijvoorbeeld een nieuwe applicatie.

In een business case worden zo veel mogelijk aspecten meegenomen die de kosten beïnvloeden. Hierbij kan gedacht worden aan kosten voor hardware, stroom, rackspace en licentiekosten. Ook minder voor de hand liggende aspecten zoals kosten voor implementatie, migratie en beheer moeten in de berekening worden meegenomen. Deze berekening wordt total cost of ownership (tco) genoemd. In de tco zitten alle kosten die het gebruik van een toepassing met zich meebrengt.

Veel organisaties willen financieel profiteren van de mogelijkheden die open source software hen biedt. Een van de mogelijkheden is Microsoft Exchange te vervangen door Zarafa Collaboration Platform. Beiden betreffen mail/groupware-software en kunnen naadloos met Microsoft Outlook werken. De vraag die velen bezighoudt is natuurlijk: hoeveel kan er bespaard worden? Dit artikel beschrijft de business case van Zarafa versus Microsoft Exchange. Voor beide producten is een tco-berekening gemaakt waarbij (nagenoeg) alle denkbare kosten zijn meegenomen.

Soms is het erg lastig om een goede tco-berekening te maken. Op verschillende punten zijn applicaties niet vergelijkbaar, bijvoorbeeld omdat de licentiestructuur verschillend is. Bovendien zijn er altijd aspecten die je niet kan kwantificeren. Een voorbeeld hiervan zijn de kosten van incidenten. De eerste vraag die daarvoor beantwoord moet worden, is het gemiddeld aantal incidenten van een applicatie. Hoe is dat objectief vast te stellen? Hoe kan bovendien de schade die een organisatie oploopt door downtime vastgesteld worden? Dit wordt sterk beïnvloed door het belang van de applicatie voor de betreffende organisatie.

Voor de lastig te bepalen aspecten worden aannames gedaan. Alle aannames in deze tco-berekeningen zijn aangegeven. Hierdoor kan de lezer zelf bepalen wat de invloed is als deze aannames gewijzigd worden of komen te vervallen.

De business case

In deze case wordt een fictief bedrijf met vijfhonderd medewerkers gebruikt. Deze organisatie heeft noch kennis en ervaring met Exchange, noch met Zarafa. Men wil het zelf hosten op een enkele fysieke server. De overige aannames zijn:

– De tco-berekeningen zijn gemaakt over een periode van drie jaar en zes jaar.
– Voor de licentiekosten van Exchange is met opzet niet gekozen voor de Software Assurance, dit zou de licentiekosten voor Exchange substantieel hoger maken (50 tot 75 procent hoger). In de berekening van zes jaar worden in jaar vier de licenties nogmaals gekocht omdat er dan net als bij Zarafa niet alleen updates, maar ook upgrades beschikbaar zijn. Zo zijn de alternatieven beter vergelijkbaar.
– Vijfhonderd gebruikers kunnen op een enkele server draaien.
– Voor alle softwareproducten is een versie met support genomen.
– De kosten van incidenten en schade door downtime zijn buiten de tco-berekening gehouden omdat deze niet op voorhand zijn vast te stellen.
– De implementatiekosten voor Zarafa zijn inclusief een testmigratie en fixed price.
– In de tco-berekening is ervoor gekozen de licentiekosten en subscriptiekosten in een keer te voldoen (in plaat van over drie jaar af te schrijven). Dit zal de meest voorkomende situatie zijn.
– Speciale (branche)kortingen en surfcontracten zijn buiten beschouwing gelaten.
– De prijzen voor het Microsoft Exchange-alternatief zijn door een Microsoft-partner aangeleverd.
– Er is geen sprake van een voorkeur voor één van de alternatieven, functioneel acht ik beide producten gelijk.

In de tco-berekening zijn meegenomen:

– Hardware (stelpost voor beiden gelijk gehouden).
– Spare parts (stelpost voor beiden gelijk gehouden).
– Hardware support (stelpost voor beiden gelijk gehouden).
– Stroom (stelpost voor beiden gelijk gehouden).
– Rackspace (stelpost voor beiden gelijk gehouden).
– Licenties en/of subscripties.
– Implementatiekosten (installatie en inrichting).
– Ten behoeve van de berekening van migratiekosten wordt uitgegaan van een migratie van Exchange naar een nieuwe versie van Exchange of van Exchange naar Zarafa).
– Beheerkosten (in beide gevallen kan beheer in vier uur per maand uitgevoerd worden, echter vanwege een lager beheertarief in het Microsoft Exchange-alternatief, vallen de beheerkosten daar lager uit).
– Opleidingskosten (in beide gevallen is gekozen voor certificering van zowel operating systeem als de groupware software).

Natuurlijk kunnen in een specifieke situatie of organisatie de uitgangspunten verschillen. Deze business case is zo generiek mogelijk gehouden om de significante verschillen aan het licht te brengen.

Resultaten

Zarafa vs. Microsoft Exchange

Het eerste vergelijk is over een periode van drie jaar. In dit kostenoverzicht is te zien dat het Zarafa-alternatief goedkoper is over een periode van drie jaar. Ook is te zien dat in beide gevallen de meeste investeringen in het eerste jaar vallen. Dit heeft te maken met de aanschaf van hardware, licenties/subscripties, implementatie en migratiekosten. De subscripties van Zarafa geven recht op updates en upgrades. De licenties van Microsoft geven alleen recht op updates. In deze berekening zien we een besparing van ruim 28 procent in het voordeel van Zarafa.

Zarafa vs. Microsoft Exchange

 

 

In een grafiek is een en ander als volgt voor te stellen.

 

 

 

Zarafa vs. Microsoft Exchange

Het tweede vergelijk betreft een periode van zes jaar. In dit tweede vergelijk is het verschil tussen Microsoft Exchange en Zarafa groter geworden, zowel absoluut als procentueel. Ook hier geeft de Zarafa-subscriptie recht op zowel updates als upgrades. De gekozen licenties van Microsoft geven alleen recht op updates. Om toch een eerlijk vergelijk te maken worden daarom in jaar vier de Microsoft-licenties opnieuw gekocht zodat ook een upgrade kan worden uitgevoerd. Dit verklaart de extra kosten bij Exchange in jaar vier. Indien deze strategie niet wordt gevolgd, zou na zes of zeven jaar een break even-punt bereikt kunnen worden. De consequentie is dan dat dezelfde versie zes of zeven jaar te gebruiken is, zonder te (kunnen) upgraden. In deze berekening is de besparing van het Zarafa-alternatief ruim 36 procent.

Zarafa vs. Microsoft Exchange

 

 

In een grafiek is een en ander weer als volgt af te beelden.

 

 

 

Conclusies

De tco-berekening laat zien dat deze business case aantoont dat met Zarafa kosten kunnen worden bespaard in vergelijk met Microsoft Exchange (25 procent over drie jaar en 36 procent over zes jaar). Hoewel deze verschillen procentueel klein lijken, gaat het om ruim 24.000 euro over drie jaar en ruim 53.000 euro over zes jaar. Dit zijn bedragen waarmee zinvolle dingen te doen zijn, zoals betere apparatuur aanschaffen, extra support inkopen of opleidingen volgen.

Naast de bovenstaande conclusie zijn er enkele relevante kanttekeningen te maken:

– Los van de kosten van licenties en subscripties zijn er veel open source softwaretools te vinden die het operationeel houden van Zarafa kunnen vereenvoudigen en verbeteren. Bijvoorbeeld monitoring tools (zoals Nagios of OpenNMS), deployment tools (Cobbler, Coan) of ten aanzien van configuratiemanagement (Puppet).
– Als een organisatie per se gebruik wenst te maken van een van de alternatieven, dan is een financieel vergelijk zinloos. Een duidelijke voorkeur zal bepalend zijn voor de keuze.
– In de tco-berekening is uitgegaan van gelijke (fysieke) hardware. Microsoft Exchange-experts houden als ‘vuistregel’ een maximum van vijfhonderd gebruikers per fysieke server aan. Zarafa doet met IBM samen op dit moment onderzoek naar duizend gebruikers per fysieke server.
– Verwacht wordt dat de verschillen bij een multi-servers set-up (bijvoorbeeld wanneer er meer dan vijfhonderd gebruikers zijn of wanneer er maatregelen getroffen worden voor een hoge beschikbaarheid) groter worden in het voordeel van Zarafa.
– De Zarafa-subscripties geven recht op support van Zarafa zelf. Het aantal supportverzoeken is gekoppeld aan het aantal subscripties dat wordt afgenomen. Een dergelijke support is niet standaard bij Microsoft Exchange inbegrepen.
– De kwaliteit van de alternatieven (als in het aantal incidenten, gemiddelde incidentduur en bedrijfsschade als gevolg van downtime) zijn in deze tco-berekening, zoals gezegd, buiten beschouwing gelaten. Van deze gegevens was geen data beschikbaar. Uit mijn ervaringen van weet ik dat Zarafa ook op dat punt zeker niet achterblijft.

Een goed vergelijk op basis van een tco-berekening blijft erg moeilijk. Er zijn altijd wel verschillen te benoemen die aanleiding kunnen zijn tot een discussie. In deze business case is geprobeerd een zo zuiver mogelijk vergelijk te maken en de aannames te verwoorden. In antwoord op de vraag uit de inleiding kan gesteld worden dat er aanzienlijk bespaard kan worden door over te stappen van Microsoft Exchange naar Zarafa.

Dit artikel is verschenen op de site van Computable op 22-02-2011

Open source wordt commercieel, is dat wel goed?

Iedere ict’er weet inmiddels wat open source-software is. Zelfs wanneer er geen specifieke interesse is, heeft men van Linux gehoord. Regelmatig is open source-software één van de keuzes die men maakt bij het oplossen van ict-vraagstukken. Bij een groeiend aantal bedrijven en organisaties is deze software in gebruik. Het lijkt wel alsof het gebruik van open source software ‘normaal’ is geworden. Voor een deel is dat ook zo, naast een andere manier van ontwikkelen en een bijzondere licentievorm is het natuurlijk ook ‘gewoon software’. Hiervoor gelden veelal dezelfde ‘best practices’. ITIL speelt daarom ook bij open source-software een rol in het beheer. Het toepassen van OTAP (ontwikkel-, test-, acceptatie- en productieomgeving) is eveneens verstandig bij open source.

Toch is er één aspect dat open source-software uniek maakt; de community. De groep van enthousiaste programmeurs die gezamenlijk de software schrijven. Dit vermeende ‘hobbymatige karakter’ is in de ogen van tegenstanders van open source-software dikwijls de reden om de kwaliteit in twijfel te trekken. De community zou niet professioneel zijn en niet gecoördineerd kunnen werken. In de praktijk blijkt dat de kwaliteit van de software erg goed is en dat het leiderschap binnen de groep geregeld wordt (zoals Linus Torvalds de natuurlijke leider is van alle Linux kernel development).

Het bedrijfsleven is wakker geworden. Bedrijven tonen zich in stijgende mate geïnteresseerd in het toepassen van open source-software in bedrijfskritische toepassingen. Inmiddels heeft (in Nederland) ook de overheid het belang van open source-software ingezien. De motie Vendrik en het actieplan Heemskerk zijn daar sprekende voorbeelden van. Het gebruik van open source-software is niet langer bijzonder.

Het maken van open source-software is wel bijzonder en actueel. Voor leveranciers van software is open source een belangrijke keuze geworden waar men niet om heen kan. De voordelen zijn een community die helpt bij de ontwikkeling van (delen van) de software of de mogelijkheid om een extra marktaandeel te verwerven. Maar hoe kunnen deze leveranciers ervoor zorgen dat er voldoende geld blijft binnen komen? Wie garandeert het voortbestaan als de software te downloaden is? Hoe vormen zij een community rond de software en kunnen zij voldoende invloed uitoefenen op de development ervan?

Er is prima geld te verdienen aan open source-software. Een goed voorbeeld hiervan is Red Hat. Het bedrijf heeft een grote community om zich heen verzameld (de Fedora-community). De software is te downloaden (bijvoorbeeld als CentOS of de ontwikkelversie Fedora). Red Hat verkoopt daarnaast subscripties. Deze subscripties geven recht op updates en bugfixes via het Red Hat-netwerk en men heeft recht op support. Voor het bedrijfsmatig toepassen van open source-software vervult dit blijkbaar een behoefte, getuige het succes van Red Hat. Het voordeel is dat de software te downloaden is wanneer er geen behoefte is aan support. Hetzelfde geldt voor Bacula Backup. Deze software is volledig vrij te gebruiken, maar indien gewenst zijn er subscripties te verkrijgen. Bacula is echter nog niet zo succesvol als Red Hat. Het is blijkbaar moeilijk het goede verdienmodel te kiezen.

In toenemende mate zie ik bedrijven die twee versies van de software creëren. Enerzijds is er een communityversie (een echte open source-softwareversie) en anderzijds is er een bedrijfsmatige versie (closed source-software, of met beperkende licentie) te verkrijgen. De communityversie is vaak de ontwikkelversie van de software (zoals Fedora van Red Hat de ontwikkelversie is). Om toch voldoende geld te kunnen verdienen, wordt de betaalde versie van extra’s voorzien die bedrijven niet willen missen. Of er worden restricties gesteld aan partners om de communityversie te mogen aanbieden. Ik begrijp waarom dit gebeurt, het is niet eenvoudig succesvol geld te verdienen aan open source-software. Ik ben wel bang voor een nieuwe vendor lock-in. Opnieuw zijn er beperkingen van keuzevrijheid en de noodzaak om licentiecodes in te voeren. Daar waren we net van verlost, dacht ik.

Bedrijfsmatige interesse is goed voor open source-software. Het is ook goed voor de bedrijven die daar producten en diensten voor aanbieden. Ik hoop wel dat voorkomen kan worden dat er een tussenvorm gaat ontstaan. Software die open source lijkt, maar het eigenlijk niet is.

Dit artikel is verschenen op de site van de Computable op 16-9-2009