maandag 30 juni 2008
Digitale Darjeeling
Beetje OT, maar wel een erg leuk verhaal over de eerste computer in een bedrijf.
donderdag 26 juni 2008
Hier is het weerbericht
Cloudstatus meet de status van cloud-services. Op dit moment alleen Amozon services, maar als ik het goed begrijp heeft men ook het plan andere cloud-services toe te voegen.
Eigenlijk wel handig.
Eigenlijk wel handig.
maandag 23 juni 2008
Te optimistisch?
Het kantoor wordt verbouwd, en er moet dus worden opgeruimd. Daarbij loop ik door een stapel oude nummers van Software Release. En in het nummer van december 1996 tref ik een artikel van mezelf aan, waarin wordt voorspeld dat we componenten niet meer gaan kopen of bouwen, maar als component via het internet gebruiken, en daarvoor huur (zouden we nu noemen: pay-as-you-go) betalen. Het stuk gaat over componenten, en niet over services, maar dat is natuurlijk hetzelfde: SaaS dus.
Verder wordt ook het punt gemaakt dat door pay-as-you-go hergebruik een groot deel van de copyright en intellectueel -eigendom-problematiek wordt vermeden.
De laatste zin is echter in zekere zin het meest interessant: "Ben ik te optimistisch?"
Het is natuurlijk leuk om achteraf gelijk te krijgen, maar het heeft wel een tijd geduurd. Als in 1996 die logica al zo onontkoombaar was, waarom is SaaS dan niet eerder doorgebroken? of was die logica toch niet zo onontkoombaar?
Gedachten hierover?
Verder wordt ook het punt gemaakt dat door pay-as-you-go hergebruik een groot deel van de copyright en intellectueel -eigendom-problematiek wordt vermeden.
De laatste zin is echter in zekere zin het meest interessant: "Ben ik te optimistisch?"
Het is natuurlijk leuk om achteraf gelijk te krijgen, maar het heeft wel een tijd geduurd. Als in 1996 die logica al zo onontkoombaar was, waarom is SaaS dan niet eerder doorgebroken? of was die logica toch niet zo onontkoombaar?
Gedachten hierover?
maandag 16 juni 2008
Ecosystemen, integratie en softwarehouses
Afgelopen week heb ik de SIIA On Demand conferentie in Amsterdam bezocht.
Twee kreten kwamen vaak terug: "ecosystem" en "integration". Die hebben met elkaar te maken, maar laten we beginnen met integratie.
Bij integratie op het gebied van SaaS gaat het eigenlijk om drie soorten integratie:
1. integratie van SaaS-services onderling in het user-interface. Een vorm daarvan is de bekende mashup, waarbij in het user-interface enkele services (bijvoorbeeld een routeplanner en Buienradar) worden samengevoegd.
2. integratie van SaaS-services met eigen (legacy-)software (zoals ooit ontwikkelde maatwerksystemen) of met gekochte pakketten (zoals SAP of Office).
3. integratie van SaaS-services "aan de achterkant", bijvoorbeeld een factureringservice van Salesforce.com, de betaalservice FPS van Amazon en een boekhoudservice van Business ByDesign (de uitgestelde SaaS-variant van SAP).
Door IT-ers wordt de eerste vorm (user-interface mashups) niet erg interessant gevonden. Immers, business-processen spelen geen rol bij Buienradar, dus dit is leuk voor fröbelende webdesigners en andere dameskappers, maar voor serieuze IT-ers is het niet van belang. (Ik denk dat dit een misvatting is, maar dat doet er nu niet zoveel toe.)
De tweede en derde vorm van integratie lijken vanuit het perspectief van de softwareontwikkeling en de IT-sector erg op elkaar. In beide gevallen moet data geconverteerd worden, moeten services worden aangeroepen, enzovoort. En inderdaad: tussen de koppeling van als service beschikbare legacy software en een SaaS-service enerzijds en tussen twee SaaS-services anderzijds bestaat geen verschil. Tenminste: vanuit technisch perspectief.
En dus hebben de softwarehouses zichzelf weer eens opnieuw uitgevonden, en proclameert men dat men voortaan SaaS-services gaat integreren, dat de klanten daar erg veel behoefte aan hebben, en dat dit in feite vrijwel net zo veel werk met zich meebrengt als traditionele systeemontwikkeling.
Op korte termijn hebben ze hierin ongetwijfeld gelijk. Maar op wat langere termijn geloof ik er niks van. Waarom niet?
1. het grote voordeel van SaaS is het "functionaliteit-uit-de-muur"-effect. Standaardfucntionaliteit wordt gebruikt in de aangeboden vorm, en daardoor zijn de kosten van een fractie van die van zelf ontwikkelde en beheerde software. Bovendien hoeft er geen voorinvestering in de vorm van ontwikkelkosten, de aanschaf van een licentie of de aanschaf van servers betaald te worden.
Maar als je ten behoeve van die spotgoedkope SaaS-functionaliteit weer een hoop integratie-scripts en dergelijke moet gaan maken en onderhouden omdat anders de legacy niet meer werkt, schiet je jezelf in de voet. Want dat is weer gewoon maatwerk: hoge kosten, en in feite lock-in. Dit is niet een argument tegen SaaS, maar tegen legacy.
De tweede vorm van integratie (SaaS-legacy) moet dus tot een minimum worden beperkt: zo weinig mogelijk, zo simpel mogelijk. Ja, de softwarehouses hebben gelijk: integratie van SaaS met legacy is duur. Maar nee: dat zal (op iets langere termijn tenminste) niet leiden tot meer werk, maar tot vervroegde uitfasering van legacy-software.
2.voor de integratie van SaaS-services met elkaar zijn drie varianten waarneembaar.
a. ad hoc integratie van SaaS-services. De gebruiker van de klant integreert de SaaS-services met elkaar, op de manier zoals hij ze nodig heeft. Deze aanpak heeft uiteraard dezelfde nadelen als legacy-SaaS-integratie, en zal dan ook een kort leven beschoren zijn, en worden verdrongen door de volgende twee ontwikkelingen.
b. de "ecosystems" (het tweede buzzword van de conferentie): op de "grote platformen" zoals Salesforce.com en Amazon's AWS ontstaan een reeks van applicaties die gebruik maken van het platform en van elkaar om allerlei geïntegreerde functionaliteit aan de klant aan te bieden. Salesforce doet dat expliciet via Force.com, Amazon doet het impliciet door stapje voor stapje de voorwaarden voor het ontstaan van zo'n ecosysteem te scheppen. En Google doet iets dergelijks, en biedt via de AppEngine ook de mogelijkheid om het platform als ontwikkelplatform te gebruiken.
c. de integratie-services. Dat zijn in feite SaaS-toepassingen die SaaS-services van diverse pluimage en diverse platforms combineren en integreren. SaaSaaS dus. Een voorbeeld hiervan is RunMyProcess, en een ander DreamFactory (hoewel dat strikt genomen geen SaaS-service is, maar een te downloaden applicatie). Er wordt dan een soort virtueel ecosysteem gecreëerd. (Maar dat ecosysteem was toch al virtueel? Hmmmm.......)
Ik denk dat de varianten b en c van de SaaS-integratie in elkaar over zullen lopen. Vanuit de consument zal het niet veel uitmaken, zolang hij zijn doelen maar haalt: lage kosten, laag risico, geen lock-in. Variant a moet vermeden worden.
Vanuit het gezichtspunt van een softwarehouse zijn legacy-SaaS-integratie en SaaS-SaaS-integratie vrijwel hetzelfde. Maar vanuit het gezichtspunt van de klant, het SaaS-consumerende bedrijf, zijn het dus twee totaal verschillende zaken. De eerste vorm van integratie hangt al snel als een molensteen om de nek van de klant, omdat ie de nadelen van SaaS met de nadelen van een eigen IT-functie combineert. De tweede vorm van integratie maakt SaaS makkelijker en goedkoper bruikbaar.
Het zou kunnen dat bij de SaaS-SaaS-integratie een kans ligt voor de softwarehouses, zeker als het om de ad hoc integratie gaat. Maar die zal snel worden verdrongen door de ecosystemen en de integratieservices. En die zijn moeilijker te leveren door de softwarehouses. Ik denk dat, voorzover de softwarehouses nu leven van het verhuren van capaciteit, ze hiertoe niet in staat zullen zijn. O, technisch kunnen ze het wel. Maar het business-model is totaal anders, en daarnaar toe overschakelen is waarschijnlijk net zo'n probleem als het overschakelen naar SaaS is voor bedrijven als SAP en Oracle.
Maar hoe zit het dan met de befaamde semantische mismatch? Gaat al dat geïntegreer wel zo makkelijk? "Begrijpen" die services elkaar dan zonder meer? Nee. Die semantische mismatch is er inderdaad nog steeds. Maar er zijn enkele ontwikkelingen die er wellicht voor zorgen dat dit probleem kleiner wordt. (Hierover binnenkort.)
Is er dan niks meer te doen voor de softwarehouses? Zeker wel. Om van SaaS gebruik te kunnen maken moeten ze weten hoe hun bedrijfsmodel mapt op de modellen van de SaaS-aanbieders. Ze moeten weten hoe en waar in hun business-processen gebruik gemaakt kan worden van welke SaaS-services. En ook de aanbieders van SaaS zullen IT-kennis nodig hebben. En er zij natuurlijk ook toepassingen die (nog) niet als SaaS beschikbaar of bruikbaar zijn.
Het idee dat dat er voor de functionaliteit die door SaaS-aanbieders goed wordt afgedekt, een krachtige IT-functie bij de klanten blijft, is een illusie. En ook integratie zal niet het werkterrein van de softwarehouses blijken, tenzij ze kans zien zich om te vormen tot SaaS-aanbieder. Maar dat is heel moeilijk.
Twee kreten kwamen vaak terug: "ecosystem" en "integration". Die hebben met elkaar te maken, maar laten we beginnen met integratie.
Bij integratie op het gebied van SaaS gaat het eigenlijk om drie soorten integratie:
1. integratie van SaaS-services onderling in het user-interface. Een vorm daarvan is de bekende mashup, waarbij in het user-interface enkele services (bijvoorbeeld een routeplanner en Buienradar) worden samengevoegd.
2. integratie van SaaS-services met eigen (legacy-)software (zoals ooit ontwikkelde maatwerksystemen) of met gekochte pakketten (zoals SAP of Office).
3. integratie van SaaS-services "aan de achterkant", bijvoorbeeld een factureringservice van Salesforce.com, de betaalservice FPS van Amazon en een boekhoudservice van Business ByDesign (de uitgestelde SaaS-variant van SAP).
Door IT-ers wordt de eerste vorm (user-interface mashups) niet erg interessant gevonden. Immers, business-processen spelen geen rol bij Buienradar, dus dit is leuk voor fröbelende webdesigners en andere dameskappers, maar voor serieuze IT-ers is het niet van belang. (Ik denk dat dit een misvatting is, maar dat doet er nu niet zoveel toe.)
De tweede en derde vorm van integratie lijken vanuit het perspectief van de softwareontwikkeling en de IT-sector erg op elkaar. In beide gevallen moet data geconverteerd worden, moeten services worden aangeroepen, enzovoort. En inderdaad: tussen de koppeling van als service beschikbare legacy software en een SaaS-service enerzijds en tussen twee SaaS-services anderzijds bestaat geen verschil. Tenminste: vanuit technisch perspectief.
En dus hebben de softwarehouses zichzelf weer eens opnieuw uitgevonden, en proclameert men dat men voortaan SaaS-services gaat integreren, dat de klanten daar erg veel behoefte aan hebben, en dat dit in feite vrijwel net zo veel werk met zich meebrengt als traditionele systeemontwikkeling.
Op korte termijn hebben ze hierin ongetwijfeld gelijk. Maar op wat langere termijn geloof ik er niks van. Waarom niet?
1. het grote voordeel van SaaS is het "functionaliteit-uit-de-muur"-effect. Standaardfucntionaliteit wordt gebruikt in de aangeboden vorm, en daardoor zijn de kosten van een fractie van die van zelf ontwikkelde en beheerde software. Bovendien hoeft er geen voorinvestering in de vorm van ontwikkelkosten, de aanschaf van een licentie of de aanschaf van servers betaald te worden.
Maar als je ten behoeve van die spotgoedkope SaaS-functionaliteit weer een hoop integratie-scripts en dergelijke moet gaan maken en onderhouden omdat anders de legacy niet meer werkt, schiet je jezelf in de voet. Want dat is weer gewoon maatwerk: hoge kosten, en in feite lock-in. Dit is niet een argument tegen SaaS, maar tegen legacy.
De tweede vorm van integratie (SaaS-legacy) moet dus tot een minimum worden beperkt: zo weinig mogelijk, zo simpel mogelijk. Ja, de softwarehouses hebben gelijk: integratie van SaaS met legacy is duur. Maar nee: dat zal (op iets langere termijn tenminste) niet leiden tot meer werk, maar tot vervroegde uitfasering van legacy-software.
2.voor de integratie van SaaS-services met elkaar zijn drie varianten waarneembaar.
a. ad hoc integratie van SaaS-services. De gebruiker van de klant integreert de SaaS-services met elkaar, op de manier zoals hij ze nodig heeft. Deze aanpak heeft uiteraard dezelfde nadelen als legacy-SaaS-integratie, en zal dan ook een kort leven beschoren zijn, en worden verdrongen door de volgende twee ontwikkelingen.
b. de "ecosystems" (het tweede buzzword van de conferentie): op de "grote platformen" zoals Salesforce.com en Amazon's AWS ontstaan een reeks van applicaties die gebruik maken van het platform en van elkaar om allerlei geïntegreerde functionaliteit aan de klant aan te bieden. Salesforce doet dat expliciet via Force.com, Amazon doet het impliciet door stapje voor stapje de voorwaarden voor het ontstaan van zo'n ecosysteem te scheppen. En Google doet iets dergelijks, en biedt via de AppEngine ook de mogelijkheid om het platform als ontwikkelplatform te gebruiken.
c. de integratie-services. Dat zijn in feite SaaS-toepassingen die SaaS-services van diverse pluimage en diverse platforms combineren en integreren. SaaSaaS dus. Een voorbeeld hiervan is RunMyProcess, en een ander DreamFactory (hoewel dat strikt genomen geen SaaS-service is, maar een te downloaden applicatie). Er wordt dan een soort virtueel ecosysteem gecreëerd. (Maar dat ecosysteem was toch al virtueel? Hmmmm.......)
Ik denk dat de varianten b en c van de SaaS-integratie in elkaar over zullen lopen. Vanuit de consument zal het niet veel uitmaken, zolang hij zijn doelen maar haalt: lage kosten, laag risico, geen lock-in. Variant a moet vermeden worden.
Vanuit het gezichtspunt van een softwarehouse zijn legacy-SaaS-integratie en SaaS-SaaS-integratie vrijwel hetzelfde. Maar vanuit het gezichtspunt van de klant, het SaaS-consumerende bedrijf, zijn het dus twee totaal verschillende zaken. De eerste vorm van integratie hangt al snel als een molensteen om de nek van de klant, omdat ie de nadelen van SaaS met de nadelen van een eigen IT-functie combineert. De tweede vorm van integratie maakt SaaS makkelijker en goedkoper bruikbaar.
Het zou kunnen dat bij de SaaS-SaaS-integratie een kans ligt voor de softwarehouses, zeker als het om de ad hoc integratie gaat. Maar die zal snel worden verdrongen door de ecosystemen en de integratieservices. En die zijn moeilijker te leveren door de softwarehouses. Ik denk dat, voorzover de softwarehouses nu leven van het verhuren van capaciteit, ze hiertoe niet in staat zullen zijn. O, technisch kunnen ze het wel. Maar het business-model is totaal anders, en daarnaar toe overschakelen is waarschijnlijk net zo'n probleem als het overschakelen naar SaaS is voor bedrijven als SAP en Oracle.
Maar hoe zit het dan met de befaamde semantische mismatch? Gaat al dat geïntegreer wel zo makkelijk? "Begrijpen" die services elkaar dan zonder meer? Nee. Die semantische mismatch is er inderdaad nog steeds. Maar er zijn enkele ontwikkelingen die er wellicht voor zorgen dat dit probleem kleiner wordt. (Hierover binnenkort.)
Is er dan niks meer te doen voor de softwarehouses? Zeker wel. Om van SaaS gebruik te kunnen maken moeten ze weten hoe hun bedrijfsmodel mapt op de modellen van de SaaS-aanbieders. Ze moeten weten hoe en waar in hun business-processen gebruik gemaakt kan worden van welke SaaS-services. En ook de aanbieders van SaaS zullen IT-kennis nodig hebben. En er zij natuurlijk ook toepassingen die (nog) niet als SaaS beschikbaar of bruikbaar zijn.
Het idee dat dat er voor de functionaliteit die door SaaS-aanbieders goed wordt afgedekt, een krachtige IT-functie bij de klanten blijft, is een illusie. En ook integratie zal niet het werkterrein van de softwarehouses blijken, tenzij ze kans zien zich om te vormen tot SaaS-aanbieder. Maar dat is heel moeilijk.
vrijdag 6 juni 2008
Krugman zegt iets zinnigs
Paul Krugman schrijft voor de eerste keer sinds jaren een column waarin de Republikeinen in het algemeen en Bush in het bijzonder niet de schuld krijgen, en het is gelijk een goed stuk.
Over de consequenties van digitalisering, de briljantie van de Amazon Kindle.
Over de consequenties van digitalisering, de briljantie van de Amazon Kindle.
Abonneren op:
Posts (Atom)