Zijn punt: REST is niet makkelijk, maar het kan in ieder geval de vereiste complexiteit aan. Dit in tegenstelling tot SOAP etc.
Dat laatste punt is wel waar: SOAP is inderdaad heel erg simpel, maar het lsot ook vrijwel niets op.
donderdag 28 augustus 2008
voor de restliefhebbers
Dit verhaal van Bill de hÒra (daar heb ik dus het character palette bij nodig). En ook deze.
UML + DSL
Dit is een interessante ontwikkeling. Microsoft gaat toch iets met UML doen, en zelfs op een hoger abstractie-nivo dan de DSLs.
Ik kan me daar wel iets bij voorstellen (itt Steven Kelly), maar ik moet toch eerst even zien hoe dit werkt.
(via Jacob den Haan)
donderdag 21 augustus 2008
MDE en de silver bullit
Johan den Haan heeft de moeite genomen op mijn vorige post te reageren, en daar ben ik blij mee.
Hij schrijft:
"Ik denk zeker dat MDE de toekomst is. Waar ik voor pleit, wat ook in het InfoQ artikel naar voren komt, is een bredere aanpak dan alleen MDA of alleen DSLs. MDE , met DSLs als basis, heeft meer potentie. "
Ik ben het met hem eens. Wellicht zie ik meer in archtype domein modellen dan Johan, en Johan weer wat meer in "echte" DSLs, maar dat zijn minieme verschillen van inzicht. Dat gaat vooral over welke vorm een DSL moet of kan hebben, en hoe een DSL in MDE kan worden gebruikt.
Johan verder:
"Waar ik sceptisch over ben is alles wat model-driven in de naam heeft te zien als 'silver bullet'. Daarnaast denk ik dat het opzetten van een model gedreven ontwikkelstraat om enorm veel expertise vraagt, zowel op het gebied van software engineering als op het gebied van language engineering."
Inderdaad, silver bullets bestaan niet. En wat betreft die model driven ontwikkelstraat (ik ben wat minder scrupuleus als het gaat om het mengen van nederlands en engels, geloof ik :) ): inderdaad, dat is een probleem. Misschien is het zelfs wel een onmogelijke opgave.
Want om MDE (in ieder geval zoals ik dat zie) goed aan de praat te krijgen, moet aan een aantal voorwaarden zijn voldaan:
1. de generatie van executables (al of niet met leesbare code als tussenstation) moet 100% zijn. Zodra een aspect van een domein of architectuur op twee plaatsen in de stroom (bijvoorbeeld in een model en in programmacode) moet worden bewerkt, zal na verloop van tijd de bewerking alleen nog op de tweede plaats (stroomafwaarts dus) worden onderhouden. Het model wordt waardeloos en de model driven straat ook.
2. de MDE straat moet complexe domeinen aankunnen, en ook voldoende vrijheidsgraden bieden om hybride architcturen, verscheidene platforms, etc, etc aan te kunnen.
Deze twee punten vereisen dus een grote en ingewikkelde ontwikkelstraat, hoogstwaarschijnlijk slechts te bedienen door lieden die buitengewoon goed weten hoe het werkt, hoet zou moeten werken, enzovoort. Experts dus.
Maar om een aanpak als MDE (of welke nieuwe aanpak of tool voor software-ontwikkeling dan ook) met succes geïntroduceerd en geaccepteerd te krijgen, zijn er nog een paar voorwaarden:
3. de aanpak en de tooling moet redelijk bestand zijn tegen onoordeelkundig gebruik. Met andere woorden: een "foute" aanpak moet òf onmogelijk zijn, òf niet tot desastreuze resultaten leiden.
4. aanpak en werkwijze moeten te leren zijn door "gewone" software-ontwikkelaars. Liefst in een training van maximaal 5 dagen.
Vernieuwingen die een enorme expertise, training en discipline vereisen hebben de neiging te mislukken, zeker als de betrokkenen menen een simpeler alternatief (i.c. de conventionele werkwijze) te hebben. Dat laat de geschiedenis van de software-ontwikkeling volgens mij zien.
Het is duidelijk: voorwaarde 1 en 2 staan op zeer gespannen voet met 3 en 4. Ze zijn nauwelijks te combineren.
De conclusie:
MDE is alleen goed te gebruiken in situaties waarin de complexiteit van de opdracht, de vereiste snelheid van ontwikkeling, etc een aanpak als MDE noodzakelijk maakt. En de organisatie moet de consequenties (kosten tooling, eisen aan de experts, etc) dan voor lief nemen en niet toch een ogenschijnlijk goedkopere combinatie met een conventionele aanpak na te streven (met kletspraat over win-win-situaties enzo).
"Gewone" systeemontwikkeling voldoet hier maar zelden aan, dat is duidelijk. Grootschalige systeemontwikkeling, speciaal bij produktontwikkeling (product line engineering), daarentegen bieden wel mogelijkheden. En een van de effecten van SaaS en cloud computing zal zijn dat meer software op die manier gemaakt en onderhouden zal worden. Maar in de gewone systeemontwikkeling zie ik niet veel ruimte voor MDE.
Ben ik nou te cynisch?
Hij schrijft:
"Ik denk zeker dat MDE de toekomst is. Waar ik voor pleit, wat ook in het InfoQ artikel naar voren komt, is een bredere aanpak dan alleen MDA of alleen DSLs. MDE , met DSLs als basis, heeft meer potentie. "
Ik ben het met hem eens. Wellicht zie ik meer in archtype domein modellen dan Johan, en Johan weer wat meer in "echte" DSLs, maar dat zijn minieme verschillen van inzicht. Dat gaat vooral over welke vorm een DSL moet of kan hebben, en hoe een DSL in MDE kan worden gebruikt.
Johan verder:
"Waar ik sceptisch over ben is alles wat model-driven in de naam heeft te zien als 'silver bullet'. Daarnaast denk ik dat het opzetten van een model gedreven ontwikkelstraat om enorm veel expertise vraagt, zowel op het gebied van software engineering als op het gebied van language engineering."
Inderdaad, silver bullets bestaan niet. En wat betreft die model driven ontwikkelstraat (ik ben wat minder scrupuleus als het gaat om het mengen van nederlands en engels, geloof ik :) ): inderdaad, dat is een probleem. Misschien is het zelfs wel een onmogelijke opgave.
Want om MDE (in ieder geval zoals ik dat zie) goed aan de praat te krijgen, moet aan een aantal voorwaarden zijn voldaan:
1. de generatie van executables (al of niet met leesbare code als tussenstation) moet 100% zijn. Zodra een aspect van een domein of architectuur op twee plaatsen in de stroom (bijvoorbeeld in een model en in programmacode) moet worden bewerkt, zal na verloop van tijd de bewerking alleen nog op de tweede plaats (stroomafwaarts dus) worden onderhouden. Het model wordt waardeloos en de model driven straat ook.
2. de MDE straat moet complexe domeinen aankunnen, en ook voldoende vrijheidsgraden bieden om hybride architcturen, verscheidene platforms, etc, etc aan te kunnen.
Deze twee punten vereisen dus een grote en ingewikkelde ontwikkelstraat, hoogstwaarschijnlijk slechts te bedienen door lieden die buitengewoon goed weten hoe het werkt, hoet zou moeten werken, enzovoort. Experts dus.
Maar om een aanpak als MDE (of welke nieuwe aanpak of tool voor software-ontwikkeling dan ook) met succes geïntroduceerd en geaccepteerd te krijgen, zijn er nog een paar voorwaarden:
3. de aanpak en de tooling moet redelijk bestand zijn tegen onoordeelkundig gebruik. Met andere woorden: een "foute" aanpak moet òf onmogelijk zijn, òf niet tot desastreuze resultaten leiden.
4. aanpak en werkwijze moeten te leren zijn door "gewone" software-ontwikkelaars. Liefst in een training van maximaal 5 dagen.
Vernieuwingen die een enorme expertise, training en discipline vereisen hebben de neiging te mislukken, zeker als de betrokkenen menen een simpeler alternatief (i.c. de conventionele werkwijze) te hebben. Dat laat de geschiedenis van de software-ontwikkeling volgens mij zien.
Het is duidelijk: voorwaarde 1 en 2 staan op zeer gespannen voet met 3 en 4. Ze zijn nauwelijks te combineren.
De conclusie:
MDE is alleen goed te gebruiken in situaties waarin de complexiteit van de opdracht, de vereiste snelheid van ontwikkeling, etc een aanpak als MDE noodzakelijk maakt. En de organisatie moet de consequenties (kosten tooling, eisen aan de experts, etc) dan voor lief nemen en niet toch een ogenschijnlijk goedkopere combinatie met een conventionele aanpak na te streven (met kletspraat over win-win-situaties enzo).
"Gewone" systeemontwikkeling voldoet hier maar zelden aan, dat is duidelijk. Grootschalige systeemontwikkeling, speciaal bij produktontwikkeling (product line engineering), daarentegen bieden wel mogelijkheden. En een van de effecten van SaaS en cloud computing zal zijn dat meer software op die manier gemaakt en onderhouden zal worden. Maar in de gewone systeemontwikkeling zie ik niet veel ruimte voor MDE.
Ben ik nou te cynisch?
donderdag 14 augustus 2008
Waarom MDE zal falen volgens Johan den Haan
Op InfoQ trof ik dit artikel aan: 8 redenen waarom MDE zal falen. MDE falen? 8 redenen maar liefst?! Hoog te paard ging ik het stuk lezen, maar het is eigenlijk een vrij goed verhaal. De schrijver, Johan den Haan, weet waarover hij praat, en zijn opmerkingen zijn blijkbaar (mede) ingegeven door praktische ervaring.
De 8 redenen zijn ook meer 8 grote risico's, en in zijn schets daarvan heeft hij wel gelijk. Ik zal ze even nalopen.
1. De gangbare MDE-aanpakken en -tools zijn vrijwel uitsluitend gericht op het korte termijn doel van verhoging van produktiviteit voor developers: meer functiepunten per uur, en verder niks.
Ja, dat is zo, en dat is inderdaad een van de grote tekortkomingen van de gebruikelijke aanpakken. Links laten liggen dus, en richten op waar het in MDE echt over gaat (vorige week blogde ik daarover ook al).
2. in MDE concentreert men zich meestal op slechts één modelleringsdimensie. Architectuur bijvoorbeeld wordt er bij de MDA aanpak een beetje bijgefrommeld in de PSM.
Inderdaad, dat lijkt nergens op. Den Haan is hier nog veel te voorzichtig: je hebt zowel binnen het domein als binnen de weergave van de technische architectuur en implementatie verscheidene modelleringsdimensies nodig.
Naar mijn idee is dat te doen met een goede modeltransformatieaanpak, maar simpel is het niet. Bovendien: hoeveel modeldimensies moeten we aankunnen?
3. de gangbare tools richten zich op het maken van nieuwe artefacten (stukken code, getransformeerde modellen, etc) en laten de problemen van aanpassing van bestaande artefacten links liggen.
Den Haan heeft hier ongetwijfeld gelijk, maar ik denk dat hij hier de zaak wat complexer maakt dan strikt nodig is. Immers, als je afgeleide artefacten 100% kunt genereren, kun je ook zelfs voor een kleine wijziging de hele zwik van (tussen)modellen, code, enzovoort gewoon opnieuw maken. Daar zitten nadelen en beperkingen aan (zoals de veteranen uit de CBD-hoek weten), maar je komt er wel een eind mee.
4. MDE richt zich teveel op General Purpose Languages zoals UML. Dat is niet voldoende: je hebt voor deelterreinen specifieke talen nodig. Het bekende DSL-lied.
Ja, dat is zo, maar ik denk wel dat in ieder geval als het gaat om business domeinen de combinatie van "gewoon" UML, analyse patronen (archetypes) en een abstractiemechanisme waarmee specifieke modellen van meer generieke patronen kunnen worden afgeleid heel veel helpt. Je kunt dan natuurlijk zo'n analyse-patroon of een bepaalde afleiding als een DSL zien.
Zie ook hier en hier en hier.
5. Zelf ontworpen DSL's zullen een chaos creëren.
Ja, dat ben ik helemaal met Den Haan eens. Voor mij is dat ook een reden om meer van archetypes gebruik te maken. Die zijn geschreven in UML, en dus veel makkelijker te begrijpen en te integreren.
6. Niet volledig executeerbare modeltransformaties zijn een bedreiging. Ja, dat is zeker zo. He treurige gehannes met PIM en PSM in veel MDA tools is daarvan trouwens een voorbeeld (Den Haan noemt het niet).
7. Modellen kunnen meestal neit of slechts zeer moeizaam op modelnivo worden getest. Dat is natuurlijk een probleem, want de enige manier om te testen is dan; eerst alles uitgenereren (aangenomen dat dat kan), en dan testen. Maar dat maakt het natuurlijk erg onhandig om zo fouten en onvolledigheden in het model op te sporen.
8. Tooling is onvoldoende. Den Haan geeft als voorbeeld de debugger die in de modelleeromgeving meestal afwezig is. En ook hier heeft hij natuurlijk helemaal gelijk.
Den Haan's conclusie is slap:
"We’ve seen eight reasons why model-driven approaches can fail to make their promises come true. It’s not my goal to discourage you from starting with model-driven software development. I just wanted to show you the complexity of it and wanted to share some thoughts hopefully pointing you at directions helping you to overcome the complexity of MDE."
De hamvraag is natuurlijk: als die 8 risico's er inderdaad zijn (en ik denk dat Den Haan daarin ruwweg wel gelijk heeft), heeft MDE dan eigenlijk wel kans van slagen? De titel van zijn artikel suggereert dat Den Haan daarover sceptisch is, maar hij geeft zelf geen antwoord op de vraag.
En ik doe dat ook even niet, want ik kom erop terug. :)
De 8 redenen zijn ook meer 8 grote risico's, en in zijn schets daarvan heeft hij wel gelijk. Ik zal ze even nalopen.
1. De gangbare MDE-aanpakken en -tools zijn vrijwel uitsluitend gericht op het korte termijn doel van verhoging van produktiviteit voor developers: meer functiepunten per uur, en verder niks.
Ja, dat is zo, en dat is inderdaad een van de grote tekortkomingen van de gebruikelijke aanpakken. Links laten liggen dus, en richten op waar het in MDE echt over gaat (vorige week blogde ik daarover ook al).
2. in MDE concentreert men zich meestal op slechts één modelleringsdimensie. Architectuur bijvoorbeeld wordt er bij de MDA aanpak een beetje bijgefrommeld in de PSM.
Inderdaad, dat lijkt nergens op. Den Haan is hier nog veel te voorzichtig: je hebt zowel binnen het domein als binnen de weergave van de technische architectuur en implementatie verscheidene modelleringsdimensies nodig.
Naar mijn idee is dat te doen met een goede modeltransformatieaanpak, maar simpel is het niet. Bovendien: hoeveel modeldimensies moeten we aankunnen?
3. de gangbare tools richten zich op het maken van nieuwe artefacten (stukken code, getransformeerde modellen, etc) en laten de problemen van aanpassing van bestaande artefacten links liggen.
Den Haan heeft hier ongetwijfeld gelijk, maar ik denk dat hij hier de zaak wat complexer maakt dan strikt nodig is. Immers, als je afgeleide artefacten 100% kunt genereren, kun je ook zelfs voor een kleine wijziging de hele zwik van (tussen)modellen, code, enzovoort gewoon opnieuw maken. Daar zitten nadelen en beperkingen aan (zoals de veteranen uit de CBD-hoek weten), maar je komt er wel een eind mee.
4. MDE richt zich teveel op General Purpose Languages zoals UML. Dat is niet voldoende: je hebt voor deelterreinen specifieke talen nodig. Het bekende DSL-lied.
Ja, dat is zo, maar ik denk wel dat in ieder geval als het gaat om business domeinen de combinatie van "gewoon" UML, analyse patronen (archetypes) en een abstractiemechanisme waarmee specifieke modellen van meer generieke patronen kunnen worden afgeleid heel veel helpt. Je kunt dan natuurlijk zo'n analyse-patroon of een bepaalde afleiding als een DSL zien.
Zie ook hier en hier en hier.
5. Zelf ontworpen DSL's zullen een chaos creëren.
Ja, dat ben ik helemaal met Den Haan eens. Voor mij is dat ook een reden om meer van archetypes gebruik te maken. Die zijn geschreven in UML, en dus veel makkelijker te begrijpen en te integreren.
6. Niet volledig executeerbare modeltransformaties zijn een bedreiging. Ja, dat is zeker zo. He treurige gehannes met PIM en PSM in veel MDA tools is daarvan trouwens een voorbeeld (Den Haan noemt het niet).
7. Modellen kunnen meestal neit of slechts zeer moeizaam op modelnivo worden getest. Dat is natuurlijk een probleem, want de enige manier om te testen is dan; eerst alles uitgenereren (aangenomen dat dat kan), en dan testen. Maar dat maakt het natuurlijk erg onhandig om zo fouten en onvolledigheden in het model op te sporen.
8. Tooling is onvoldoende. Den Haan geeft als voorbeeld de debugger die in de modelleeromgeving meestal afwezig is. En ook hier heeft hij natuurlijk helemaal gelijk.
Den Haan's conclusie is slap:
"We’ve seen eight reasons why model-driven approaches can fail to make their promises come true. It’s not my goal to discourage you from starting with model-driven software development. I just wanted to show you the complexity of it and wanted to share some thoughts hopefully pointing you at directions helping you to overcome the complexity of MDE."
De hamvraag is natuurlijk: als die 8 risico's er inderdaad zijn (en ik denk dat Den Haan daarin ruwweg wel gelijk heeft), heeft MDE dan eigenlijk wel kans van slagen? De titel van zijn artikel suggereert dat Den Haan daarover sceptisch is, maar hij geeft zelf geen antwoord op de vraag.
En ik doe dat ook even niet, want ik kom erop terug. :)
vrijdag 8 augustus 2008
model driven engineering: waar gaat het om?
Waarom zou je model driven engineering (MDE) willen?
Volgens mij komt het in de kern neer op 2 dingen.
1. de Model-kant: "aspecten" (of eigenschappen, of gegevens, of "business-rules", of welk interessant kenmerk van een systeem dan ook) worden op slechts één plaats beschreven, en dus ook op slechts één plaats aangepast of toegevoegd. Onderhoudbaarheid, flexibiliteit etc zijn vervolgens uw deel.
Dit klinkt makkelijk, maar is het niet. Het gaat dan om het handig toepassen van een aantal "abstractie dimensies".
Horizontale abstractie: loskoppeling "separate concerns" in aparte modellen. Dus: loskoppeling verscheidene domeinapsecten, loskoppeling verscheidene architectuuraspecten, op een hoger nivo: loskoppeling domein en architectuur, enzovoort.
2. de Driven-kant: een aanpassing van een Model-aspect wordt op slechts één plaats in het ontwikkelproces gedaan. Dus in een model, of in de code, maar niet allebei. Als het op meer plaatsen gebeurt, zal al heel snel het laatste punt waar het moet in het proces (meestal de aanpassing in de code) ook de enige zijn waar het gebeurt. En dan wordt het zo goed bedachte model heel snel waardeloos.
Overigens betekent dit niet dat het aanpassingen altijd op dezelfde plaats in het proces dienen te gebeuren. Het is wat mij betreft acceptabel als een aanpassing van een business aspect in een domein model plaatsvindt, terwijl een bepaald architectonisch aspect in een stuk code (dat is dan blijkbaar het model) moet gebeuren.
Het probleem met heel veel model driven aanpakken en tools is dat men zich concentreert op punt 2, de Driven-kant van Model Driven, en dat daarbij ook nog eens wordt gedaan alsof beschrijving in een grafisch model veel beter is dan in code. Dat hoeft lang niet altijd het geval te zijn.
Hoe dan ook: als men de Model-kant niet goed voor elkaar heeft, wordt het niks. Je moet weten wat in welke modellen wordt beschreven, hoe die samenhangen, enzovoort. In de gangbare MDA-aanpakken wordt kennelijk nog steeds gedacht dat er slechts één domeinmodel nodig is, en dat de architectuur niet apart behoeft te worden gemodelleerd. Dat is onzin, en het leidt tot mislukte projecten.
Volgens mij komt het in de kern neer op 2 dingen.
1. de Model-kant: "aspecten" (of eigenschappen, of gegevens, of "business-rules", of welk interessant kenmerk van een systeem dan ook) worden op slechts één plaats beschreven, en dus ook op slechts één plaats aangepast of toegevoegd. Onderhoudbaarheid, flexibiliteit etc zijn vervolgens uw deel.
Dit klinkt makkelijk, maar is het niet. Het gaat dan om het handig toepassen van een aantal "abstractie dimensies".
Horizontale abstractie: loskoppeling "separate concerns" in aparte modellen. Dus: loskoppeling verscheidene domeinapsecten, loskoppeling verscheidene architectuuraspecten, op een hoger nivo: loskoppeling domein en architectuur, enzovoort.
2. de Driven-kant: een aanpassing van een Model-aspect wordt op slechts één plaats in het ontwikkelproces gedaan. Dus in een model, of in de code, maar niet allebei. Als het op meer plaatsen gebeurt, zal al heel snel het laatste punt waar het moet in het proces (meestal de aanpassing in de code) ook de enige zijn waar het gebeurt. En dan wordt het zo goed bedachte model heel snel waardeloos.
Overigens betekent dit niet dat het aanpassingen altijd op dezelfde plaats in het proces dienen te gebeuren. Het is wat mij betreft acceptabel als een aanpassing van een business aspect in een domein model plaatsvindt, terwijl een bepaald architectonisch aspect in een stuk code (dat is dan blijkbaar het model) moet gebeuren.
Het probleem met heel veel model driven aanpakken en tools is dat men zich concentreert op punt 2, de Driven-kant van Model Driven, en dat daarbij ook nog eens wordt gedaan alsof beschrijving in een grafisch model veel beter is dan in code. Dat hoeft lang niet altijd het geval te zijn.
Hoe dan ook: als men de Model-kant niet goed voor elkaar heeft, wordt het niks. Je moet weten wat in welke modellen wordt beschreven, hoe die samenhangen, enzovoort. In de gangbare MDA-aanpakken wordt kennelijk nog steeds gedacht dat er slechts één domeinmodel nodig is, en dat de architectuur niet apart behoeft te worden gemodelleerd. Dat is onzin, en het leidt tot mislukte projecten.
donderdag 7 augustus 2008
Applicaties in de cloud
Ars Technica heeft een verslag van een presentatie van Jeffrey Birnbaum, CTO van Merril Lynch. Hij denkt dat niet alleen data, maar ook de applicaties als zodanig in de cloud kunnen verdwijnen. Met andere woorden; ze runnen op een machine waar op dat moment ruimte is, en hoeven niet meer aan een server te worden toegewezen, laat staan dat ze op de client hoeven te draaien.
Klinkt als een goed plan, en ik denk dat je nog verder kunt gaan, door de "applicaties" op te knippen in kleinere componenten, met data en functionaliteit bij elkaar. En dan hebben we reizende objecten....
Klinkt als een goed plan, en ik denk dat je nog verder kunt gaan, door de "applicaties" op te knippen in kleinere componenten, met data en functionaliteit bij elkaar. En dan hebben we reizende objecten....
vrijdag 1 augustus 2008
Computable
Sommige van mijn stukjes zullen verschijnen in het expert-panel (over SaaS) van de Computable.
Het "Boter bij de vis"-verhaal (de vorige post op deze blog) is in iets gewijzigde vorm daar verschenen.
Compleet met foto.....
Het "Boter bij de vis"-verhaal (de vorige post op deze blog) is in iets gewijzigde vorm daar verschenen.
Compleet met foto.....
dinsdag 29 juli 2008
Boter bij de vis
Een aantal Web 2.0 bedrijven, zoals Facebook en Google, hebben ietwat tegenvallende resultaten bekendgemaakt. Als belangrijskte oorzaak wordt opgegeven dat het moeilijk blijkt de groei van de inkomsten uit advertenties vast te houden. Ik vind dat niet verbazingwekkend, en in zekere zin zelfs goed nieuws, zeker voor SaaS.
Waarom is het niet verbazingwekkend? Bij de problemen in de advertentiemarkt wordt natuurlijk gewezen naar de economie. Dat is ongetwijfeld terecht, maar er is ook een meer fundamentele oorzaak: advertenties als primaire inkomstenbron voor "Web 2.0" is eenvoudigweg op langere termijn niet vol te houden.
Oorspronkelijk waren sites als Google, Yahoo, allerhande blogs, social networks zoals Facebook een dun schilletje om de appel van de "echte" economie waarin echt geld omging. En die "echte' economie wilde maar al te graag die dunne schil gebruiken als middel om te verkopen.
Maar inmiddels is de schil veel dikker geworden, onder andere doordat veel producten die eerst in de "echte" economie zaten, en echt geld opbrachten, inmiddels digitaal en virtueel zijn geworden. Helaas voor de producenten zijn de betalingen ook virtueel geworden. Een voorbeeld is natuurlijk de muziek-industrie. Die is hard bezig uit de "echte" economie (betalade CDs) te schuiven naar de virtuele Web 2.0-economie (gratis downloads of streams).
Met andere woorden: de schil wordt dikker, en de appel wordt kleiner. En ook nog eens minder relevant, want de produkten die in de oude "echte" economie blijven, zijn veelal niet zo geschikt voor channeling via het Web. Zijn advertenties voor huizen of auto's echt zinvol op een blog over SaaS? De conclusie is onontkoombaar: de Web-economie kan voor de inkomsten niet langer leunen op de "echte" economie, maar zal op eigen benen moeten gaan staan, en zelf tot de "echte" economie moeten gaan behoren.
De consument moet dus gaan betalen voor de diensten en informatie die hij via het Web gebruikt of krijgt. Op dit moment is daarvoor de gangbare oplossing een of andere vorm van abonnement. Ik betaal een bedrag per maand, en krijg daarvoor het recht om een bepaalde dienst of informatiebron te gebruiken. Tot nog toe is dit slechts matig succevol geweest. Daarvoor zijn veel redenen, maar de belangrijkste is dat je je zo als consument te vast verbindt aan een leverancier. Immers, hoeveel abonnementen op bijvoorbeeld een nieuwssite ga je afsluiten? Eén? Twee misschien? Meer niet. Maar dat is nogal een beperking, en bovendien maakt dit het leven voor kleinere of nieuwe aanbeiders veel moeilijker. En het afsluiten van zo'n abonnement is toch een Beslissing. En Beslissingen nemen we liever niet in de vloeibare wereld van het Web.
Veel interessanter is een vorm van microbetaling, waarbij je een klein bedrag betaalt per actie (ophalen bepaalde informatie, gebruik van een dienst). Echt pay-as-you-go dus. Maar er zijn twee hinderpalen.
De eerste hinderpaal is de onwennigheid van de klant. Hoe werkt het? Is het safe? Waarom zou ik betalen als het ook gratis kan? Enzovoort. Ik denk dat als de tweede hinderpaal uit de weg is geruimd, en de aanbieders steeds meer gaan naar betaalde diensten eenvoudig omdat het anders niet meer te doen is, deze onwennigheid vanzelf verdwijnt.
De tweede hinderpaal is het betaalsysteem. De gangbare vorm van betaling op het Web is door middel van de credit card. Die gebruikt men liever niet voor betalingen aan onbekende partijen, en bovendien: het is veel te duur. Er moet dus een systeem komen waarbij je betaalt via een vertrouwde partij, die ook de mogelijkheid geeft je betalingen in te zien of te maximeren, en die voor gegroepeerde betalingen in één keer afrekent met de credit card maatschappij en zodoende de kosten laag houdt. PayPal gaat in deze richting, en het voortreffelijke Flexible Payment System (FPS) van Amazon is een nog beter voorbeeld. En ongetwijfeld komen er alternatieven (een doorontwikkeling van Google Checkout bijvoorbeeld).
Het voordeel voor SaaS wordt zo duidelijk. Het grote voordeel van SaaS is het kostenmodel. Geen grote investering meer vantevoren, kosten die min of meer gelijk op gaan met het gebruik. Maar (over het algemeen) nog wel een abonnement, en daardoor toch een Beslissing, zij het een veel kleinere dan de BESLISSING om een ERP-pekket te kopen en te implementeren. En echt pay-as-you-go is een abonnement ook niet. Als je het nauwelijks gebruikt is het nog steeds duur, en opzeggen is ook weer een Beslissing. (Hoeveel tijdschriften die u niet leest krijgt u elke maand in de brievenbus?)
Deze stand van zaken hindert de verbreiding van SaaS. De beslissing om een bepaalde SaaS-toepassing te gaan gebruiken, wordt moeilijker gemaakt door het feit dat er toch een zekere mate van (economische) lockin is, en dat daardoor alternatieven geen optie meer zijn. (Er zijn daarnaast natuurlijk ook allerhande organisatorische en technische obstakels, maar die laat ik hier buiten beschouwing.) De salescycles voor SaaS-leveranciers zijn (mede) daardoor langer en zwaarder dan men aanvankelijk verwachtte, en in ieder geval duurder dan voor het SaaS-model gewenst is.
Als onder druk van het door de hoeven zakkende advertentiemodel er inderdaad een goed werkend en goedkoop systeem voor microbetalingen tot stand komt, heeft niet alleen de consumentenmarkt daarvan voordeel, maar ook B2B SaaS. Want het wordt zo mogelijk om SaaS niet alleen via het abonnementsmodel ook via een alternatief model aan te bieden. Dat zal de verkoop van meer fijn-granulaire services te mogelijk maken. En ook guerilla-marketing wordt daardoor makkelijker, en dat drukt weer de kosten van de verkoop.
Op dit moment zit SaaS nog tussen tafellaken en servet: SaaS is goedkoper en meer "pay-as-you-go" dan pakketsoftware, maar economisch eigenlijk niet flexibel genoeg om de beloften volledig waar te kunnen maken. Voor een deel heeft dat te maken met het betaalmodel. De komst van een echt pay-as-you-go-systeem in de consumentenmarkt gaat daarin verandering brengen, en daarom zijn de tegenvallende advertentie-inkomsten van Google, Facebook, c.s. goed nieuws.
Waarom is het niet verbazingwekkend? Bij de problemen in de advertentiemarkt wordt natuurlijk gewezen naar de economie. Dat is ongetwijfeld terecht, maar er is ook een meer fundamentele oorzaak: advertenties als primaire inkomstenbron voor "Web 2.0" is eenvoudigweg op langere termijn niet vol te houden.
Oorspronkelijk waren sites als Google, Yahoo, allerhande blogs, social networks zoals Facebook een dun schilletje om de appel van de "echte" economie waarin echt geld omging. En die "echte' economie wilde maar al te graag die dunne schil gebruiken als middel om te verkopen.
Maar inmiddels is de schil veel dikker geworden, onder andere doordat veel producten die eerst in de "echte" economie zaten, en echt geld opbrachten, inmiddels digitaal en virtueel zijn geworden. Helaas voor de producenten zijn de betalingen ook virtueel geworden. Een voorbeeld is natuurlijk de muziek-industrie. Die is hard bezig uit de "echte" economie (betalade CDs) te schuiven naar de virtuele Web 2.0-economie (gratis downloads of streams).
Met andere woorden: de schil wordt dikker, en de appel wordt kleiner. En ook nog eens minder relevant, want de produkten die in de oude "echte" economie blijven, zijn veelal niet zo geschikt voor channeling via het Web. Zijn advertenties voor huizen of auto's echt zinvol op een blog over SaaS? De conclusie is onontkoombaar: de Web-economie kan voor de inkomsten niet langer leunen op de "echte" economie, maar zal op eigen benen moeten gaan staan, en zelf tot de "echte" economie moeten gaan behoren.
De consument moet dus gaan betalen voor de diensten en informatie die hij via het Web gebruikt of krijgt. Op dit moment is daarvoor de gangbare oplossing een of andere vorm van abonnement. Ik betaal een bedrag per maand, en krijg daarvoor het recht om een bepaalde dienst of informatiebron te gebruiken. Tot nog toe is dit slechts matig succevol geweest. Daarvoor zijn veel redenen, maar de belangrijkste is dat je je zo als consument te vast verbindt aan een leverancier. Immers, hoeveel abonnementen op bijvoorbeeld een nieuwssite ga je afsluiten? Eén? Twee misschien? Meer niet. Maar dat is nogal een beperking, en bovendien maakt dit het leven voor kleinere of nieuwe aanbeiders veel moeilijker. En het afsluiten van zo'n abonnement is toch een Beslissing. En Beslissingen nemen we liever niet in de vloeibare wereld van het Web.
Veel interessanter is een vorm van microbetaling, waarbij je een klein bedrag betaalt per actie (ophalen bepaalde informatie, gebruik van een dienst). Echt pay-as-you-go dus. Maar er zijn twee hinderpalen.
De eerste hinderpaal is de onwennigheid van de klant. Hoe werkt het? Is het safe? Waarom zou ik betalen als het ook gratis kan? Enzovoort. Ik denk dat als de tweede hinderpaal uit de weg is geruimd, en de aanbieders steeds meer gaan naar betaalde diensten eenvoudig omdat het anders niet meer te doen is, deze onwennigheid vanzelf verdwijnt.
De tweede hinderpaal is het betaalsysteem. De gangbare vorm van betaling op het Web is door middel van de credit card. Die gebruikt men liever niet voor betalingen aan onbekende partijen, en bovendien: het is veel te duur. Er moet dus een systeem komen waarbij je betaalt via een vertrouwde partij, die ook de mogelijkheid geeft je betalingen in te zien of te maximeren, en die voor gegroepeerde betalingen in één keer afrekent met de credit card maatschappij en zodoende de kosten laag houdt. PayPal gaat in deze richting, en het voortreffelijke Flexible Payment System (FPS) van Amazon is een nog beter voorbeeld. En ongetwijfeld komen er alternatieven (een doorontwikkeling van Google Checkout bijvoorbeeld).
Het voordeel voor SaaS wordt zo duidelijk. Het grote voordeel van SaaS is het kostenmodel. Geen grote investering meer vantevoren, kosten die min of meer gelijk op gaan met het gebruik. Maar (over het algemeen) nog wel een abonnement, en daardoor toch een Beslissing, zij het een veel kleinere dan de BESLISSING om een ERP-pekket te kopen en te implementeren. En echt pay-as-you-go is een abonnement ook niet. Als je het nauwelijks gebruikt is het nog steeds duur, en opzeggen is ook weer een Beslissing. (Hoeveel tijdschriften die u niet leest krijgt u elke maand in de brievenbus?)
Deze stand van zaken hindert de verbreiding van SaaS. De beslissing om een bepaalde SaaS-toepassing te gaan gebruiken, wordt moeilijker gemaakt door het feit dat er toch een zekere mate van (economische) lockin is, en dat daardoor alternatieven geen optie meer zijn. (Er zijn daarnaast natuurlijk ook allerhande organisatorische en technische obstakels, maar die laat ik hier buiten beschouwing.) De salescycles voor SaaS-leveranciers zijn (mede) daardoor langer en zwaarder dan men aanvankelijk verwachtte, en in ieder geval duurder dan voor het SaaS-model gewenst is.
Als onder druk van het door de hoeven zakkende advertentiemodel er inderdaad een goed werkend en goedkoop systeem voor microbetalingen tot stand komt, heeft niet alleen de consumentenmarkt daarvan voordeel, maar ook B2B SaaS. Want het wordt zo mogelijk om SaaS niet alleen via het abonnementsmodel ook via een alternatief model aan te bieden. Dat zal de verkoop van meer fijn-granulaire services te mogelijk maken. En ook guerilla-marketing wordt daardoor makkelijker, en dat drukt weer de kosten van de verkoop.
Op dit moment zit SaaS nog tussen tafellaken en servet: SaaS is goedkoper en meer "pay-as-you-go" dan pakketsoftware, maar economisch eigenlijk niet flexibel genoeg om de beloften volledig waar te kunnen maken. Voor een deel heeft dat te maken met het betaalmodel. De komst van een echt pay-as-you-go-systeem in de consumentenmarkt gaat daarin verandering brengen, en daarom zijn de tegenvallende advertentie-inkomsten van Google, Facebook, c.s. goed nieuws.
vrijdag 25 juli 2008
For whom the bell tolls...., part 3
Eerder schreef ik (hier en hier) over de problemen die leveranciers van "oude" pakket-software gaan krijgen als ze de (prijs)concurrentie van SaaS-leveranciers gaan voelen.
SAP heeft kennelijk besloten naar voren te vluchten, en bestaande klanten vanaf 1 januari 2009 meer te laten betalen voor lopende contracten. Die zijn daar natuurlijk niet blij mee, en SAP zal dat ook best hebben voorzien. Maar die klanten kunnen voorlopig geen kant uit, dus: kassa.
Alleen: het zal de overstap naar goedkopere SaaS-alternatieven (misschien wel van SAP zelf) op iets langere termijn alleen maar versnellen, maar wie dan leeft, die dan zorgt. Denken ze blijkbaar in Walldorf.
SAP heeft kennelijk besloten naar voren te vluchten, en bestaande klanten vanaf 1 januari 2009 meer te laten betalen voor lopende contracten. Die zijn daar natuurlijk niet blij mee, en SAP zal dat ook best hebben voorzien. Maar die klanten kunnen voorlopig geen kant uit, dus: kassa.
Alleen: het zal de overstap naar goedkopere SaaS-alternatieven (misschien wel van SAP zelf) op iets langere termijn alleen maar versnellen, maar wie dan leeft, die dan zorgt. Denken ze blijkbaar in Walldorf.
dinsdag 22 juli 2008
Investeringen in cloud-computing
Volgens een rapport van Goldman Sachs, waarover ComputerWorld heeft gepubliceerd, zal de werkgelegenheid in de IT dalen. Althans, volgens de geinterviewde CIO's en business executives, want daarop is het verhaal gebaseerd. Bedrijven gaan minder besteden outsourcing en aan contractwerk, en kostenbesparing dmv virtualisatie e.d. krijgt veel aandacht.
Het is allemaal niet vreemd, en perfect logisch, zeker als het economisch wat minder gaat, al vloeit uit het mindere werk in de bedrijven van de "top CIOs" niet voort dat er elders niet werk kan bijkomen.
Interessanter is de opmerking aan het eind dat de interviewees geen grote investeringen in cloud-computing, SaaS, e.d. verwachten. Men vindt dat verrassend, maar in het stuk wordt opgemerkt dat hier wel eens sprake kan zijn van een "pointy-haired boss" probleem:
"One reason for the low priorities of grid computing, open-source software and cloud computing may be that CIOs and business executives don't understand their value. "They require a technical understanding to get to their importance. I don't think C-level executives and managers have that understanding," King said."
[King is Charles King, een aangehaalde analyst.]
Inderdaad, het zou heel goed kunnen. Dit soort toplieden loopt vaak wat achter de feiten aan.
Maar er zijn nog twee andere redenen denkbaar waarom ze cloudcomputing en SaaS niet erg zien, en het dus neit als prioriteit noemen.
1. de impact van SaaS en cloudcomputing vindt (nu nog) grotendeels buiten invloedssfeer van CIOs e.d. plaats. Het gaat hier om CIO's e.d. van grote bedrijven, terwijl voor SaaS en cloudcomputing geldt dat de winst juist voor kleinere bedrijven veel groter is. Binnen grote bedrijven wordt SaaS vooral toegepast bij afdelingen en voor systemen die nou net niet bediend worden door de IT-afdeling van de CIO.
Als dit waar is, dan zijn SaaS en cloudcomputing voor die CIOs topjes van ijsbergen waarvan zij denken dat ze nog ver weg zijn.
2. SaaS en cloudcomputing vergen gezien vanuit de klant domweg niet zoveel investeringen, en daarom wordt het niet als prioriteit genoemd.
Want dat blijft natuurlijk wel waar: SaaS en cloudcomputing kunnen de kosten van "corporate IT" aanzienlijk verlagen, en dat is ook hun belangrijkste voordeel. En inderdaad, voro de werkgelegenheid in de "corporate IT" heeft dat grote gevolgen.
Voor de IT als geheel kan dat best heel anders liggen.
Het is allemaal niet vreemd, en perfect logisch, zeker als het economisch wat minder gaat, al vloeit uit het mindere werk in de bedrijven van de "top CIOs" niet voort dat er elders niet werk kan bijkomen.
Interessanter is de opmerking aan het eind dat de interviewees geen grote investeringen in cloud-computing, SaaS, e.d. verwachten. Men vindt dat verrassend, maar in het stuk wordt opgemerkt dat hier wel eens sprake kan zijn van een "pointy-haired boss" probleem:
"One reason for the low priorities of grid computing, open-source software and cloud computing may be that CIOs and business executives don't understand their value. "They require a technical understanding to get to their importance. I don't think C-level executives and managers have that understanding," King said."
[King is Charles King, een aangehaalde analyst.]
Inderdaad, het zou heel goed kunnen. Dit soort toplieden loopt vaak wat achter de feiten aan.
Maar er zijn nog twee andere redenen denkbaar waarom ze cloudcomputing en SaaS niet erg zien, en het dus neit als prioriteit noemen.
1. de impact van SaaS en cloudcomputing vindt (nu nog) grotendeels buiten invloedssfeer van CIOs e.d. plaats. Het gaat hier om CIO's e.d. van grote bedrijven, terwijl voor SaaS en cloudcomputing geldt dat de winst juist voor kleinere bedrijven veel groter is. Binnen grote bedrijven wordt SaaS vooral toegepast bij afdelingen en voor systemen die nou net niet bediend worden door de IT-afdeling van de CIO.
Als dit waar is, dan zijn SaaS en cloudcomputing voor die CIOs topjes van ijsbergen waarvan zij denken dat ze nog ver weg zijn.
2. SaaS en cloudcomputing vergen gezien vanuit de klant domweg niet zoveel investeringen, en daarom wordt het niet als prioriteit genoemd.
Want dat blijft natuurlijk wel waar: SaaS en cloudcomputing kunnen de kosten van "corporate IT" aanzienlijk verlagen, en dat is ook hun belangrijkste voordeel. En inderdaad, voro de werkgelegenheid in de "corporate IT" heeft dat grote gevolgen.
Voor de IT als geheel kan dat best heel anders liggen.
vrijdag 18 juli 2008
For whom the bell tolls.... part 2
Aardig stuk van Sarah Lacy in BusinessWeek. Strekking: de grote mastodonten van de "oude" software, zoals SAP en Microsoft, hebben grote moeite om zich een plaats te verwerven in de SaaS/cloud-wereld. En zij schrijft dat (terecht denk ik) vooral toe aan het feit dat in SaaS nu eenmaal veel minder verdiend wordt dan wat de mastodonten gewend zijn.
Oracle volgt volgens haar een andere koers: nu zoveel mogelijk het oude model uitmelken, en dan later de succesvolle SaaS=-leveranciers "cherry-picken". Ongetwijfeld zal dit het plan van Oracle zijn, maar dan nog steeds: ook dan zal Oracle merken dat de marges in SaaS en in de cloud veel smaller zijn. En ik zie niet waarom Oracle daar zoveel beter tegen zou kunnen dan SAP of Microsoft.
Twee maanden geleden postte ik:
"Dat vereist een andere manier van verkopen, een andere benadering van de klanten, en vooral ook een veel goedkopere bedrijfsvoering. En juist daar hebben bedrijven die zeer succesvol waren in het licentie-pradigma, zoals SAP en Microsoft, een probleem. Want ze verdienden geld als water, en hebben de kostenstructuur daarop afgestemd. Die kostenstructuur (salarissen, bonussen, hoofdkantoren, enzovoort, enzovoort) veranderen is heel moeilijk, ook al weet je dat het nodig is."
Dat is het probleem van SAP en Microsoft, en het wordt het probleem van Oracle.
Oracle volgt volgens haar een andere koers: nu zoveel mogelijk het oude model uitmelken, en dan later de succesvolle SaaS=-leveranciers "cherry-picken". Ongetwijfeld zal dit het plan van Oracle zijn, maar dan nog steeds: ook dan zal Oracle merken dat de marges in SaaS en in de cloud veel smaller zijn. En ik zie niet waarom Oracle daar zoveel beter tegen zou kunnen dan SAP of Microsoft.
Twee maanden geleden postte ik:
"Dat vereist een andere manier van verkopen, een andere benadering van de klanten, en vooral ook een veel goedkopere bedrijfsvoering. En juist daar hebben bedrijven die zeer succesvol waren in het licentie-pradigma, zoals SAP en Microsoft, een probleem. Want ze verdienden geld als water, en hebben de kostenstructuur daarop afgestemd. Die kostenstructuur (salarissen, bonussen, hoofdkantoren, enzovoort, enzovoort) veranderen is heel moeilijk, ook al weet je dat het nodig is."
Dat is het probleem van SAP en Microsoft, en het wordt het probleem van Oracle.
woensdag 16 juli 2008
Mark van den Brand
Dit is zo te zien een samenvatting van de inaugurale rede die Mark van den Brand gaf op 3 juli j.l. in Eindhoven.
Abonneren op:
Posts (Atom)