vrijdag 30 november 2007
MS en Web 2.0
Marco Iansiti (bekend van The Keystone Advantage) vindt dat MicroSoft niet meer hoeft te worden gereguleerd, omdat de Web 2.0 en SaaS-revoluties de macht van MS als monopolist zwaar ondergraven hebben. Zit wat in denk ik.
vertrouwen in de SaaS leverancier
Een optimistische, maar wat mij betreft ook rake posting van Phil Waninewright. Hij zegt dat SaaS-leveranciers een vergelijkbare houding ten aanzien van de hen toevertrouwde data moeten aannemen als banken dat al sinds jaar en dag doen met het toevertrouwde geld. Dit om vertrouwen te scheppen en te behouden.
Hij somt een ljst van "ongelukjes" op dit vlak van recente datum op, en citeert enkele opinionisten die hieruit de conclusie trekken dat SaaS er nog lang niet is. Wainewright snapt dat, maar trekt een andere conclusie:
"Personally, I draw quite different conclusions than these. I think the frequency of these stories over the past couple of months underlines that the on-demand model of consuming applications and services from Web-based providers has now become so prevalent that it’s simply an accepted mode of behavior for mainstream computer users, whether for work or for leisure, for business or for personal consumption."
Ik denk dat hij gelijk heeft.
Hij somt een ljst van "ongelukjes" op dit vlak van recente datum op, en citeert enkele opinionisten die hieruit de conclusie trekken dat SaaS er nog lang niet is. Wainewright snapt dat, maar trekt een andere conclusie:
"Personally, I draw quite different conclusions than these. I think the frequency of these stories over the past couple of months underlines that the on-demand model of consuming applications and services from Web-based providers has now become so prevalent that it’s simply an accepted mode of behavior for mainstream computer users, whether for work or for leisure, for business or for personal consumption."
Ik denk dat hij gelijk heeft.
woensdag 28 november 2007
Een erg aardig stuk van Nick Carr over het business-model en de strategie van Google. Hij betoogt dat de business van Google in essentie is: verkoop van advertenties. En daarvoor is het gunstig als het verkeer over het Internet toeneemt. Dat genereert namelijk voor Google de mogelijkheid om meer advertenties te kopen.
En dan zegt hij:
"There’s one more twist. Because the marginal cost of producing and distributing a new copy of a purely digital product is close to zero, Google not only has the desire to give away informational products; it has the economic leeway to actually do it. Those two facts — the vast breadth of Google’s complements, and the company’s ability to push the price of those complements toward zero — set the company apart from other firms. Google faces far less risk in product development than the usual business does. It routinely introduces half-finished products and services as online “betas” because it knows that, even if the offerings fail to win a big share of the market, they will still tend to produce attractive returns by generating advertising revenue and producing valuable data on customer behavior. For most companies, a failed launch of a new product is very costly. For Google, in general, it’s not. Failure is cheap."
Toch: in bv dit stuk in de Wall Street Journal wordt bericht dat Google op korte termjn met betaalde opslag voor consumenten komt. Zou Google dat alleen doen om meer Internet-verkeer te genereren? Ik denk het niet. Ik denk dat Google zich realiseert dat de advertentie-markt, hoe interessant en lucratief ook, eindig is. Er is op het Internet nog heel veel nieuws te doen, maar dat zal voor een groot deel betaald zijn. En dus zit er (ook) heel veel geld in betaalde services zoals opslag, Office-achtige functionaliteit, etc. En Google heeft al een infrastructuur en erg veel ervaring met grootschalige datacenters.
En dus beweegt Google zich ook in deze merkte, net als bijvoorbeeld IBM met z'n BlueCloud, Amazon.com en Microsoft, dat om te kunnen besparen op de koeling in Siberie gaat zitten.
Bedrijven die de mogelijkheden hebben om te investeren en die de naamsbekendheid hebben om te kunnen fungeren als betrouwbare broker voor betalingen en informatie te kunnen fungeren, hebben hier een voorsprong. Google behoort daar zeker toe, evenals de drie andere genoemde mastodonten. En verder wellicht ook Salesforce.com, Oracle, misschien SAP, en in de consumentenmarkt Yahoo!
Natuurlijk, als je alleen naar online backup kijkt (zoals Robin Harris hier doet), dan zijn er ook nog gespecialiseerde bedrijven die dat soort diensten leveren, zoals Mozy en Carbonite, en in Nederland ook KPN. Maar die hebben niet de mogelijkheid om uit te groeien tot broker, en kunnen ook niet goed hun online storage aanbieding combineren met standaard functionaliteit zoals Microsoft en Google dat doen, of op een heel andere manier Salesforc.com, Oracle en bijvoorbeeld SAP.
Google zit niet om "complementaire" redenen in die datacenters, Google zit erin omdat het geld gaat opleveren.
En dan zegt hij:
"There’s one more twist. Because the marginal cost of producing and distributing a new copy of a purely digital product is close to zero, Google not only has the desire to give away informational products; it has the economic leeway to actually do it. Those two facts — the vast breadth of Google’s complements, and the company’s ability to push the price of those complements toward zero — set the company apart from other firms. Google faces far less risk in product development than the usual business does. It routinely introduces half-finished products and services as online “betas” because it knows that, even if the offerings fail to win a big share of the market, they will still tend to produce attractive returns by generating advertising revenue and producing valuable data on customer behavior. For most companies, a failed launch of a new product is very costly. For Google, in general, it’s not. Failure is cheap."
Toch: in bv dit stuk in de Wall Street Journal wordt bericht dat Google op korte termjn met betaalde opslag voor consumenten komt. Zou Google dat alleen doen om meer Internet-verkeer te genereren? Ik denk het niet. Ik denk dat Google zich realiseert dat de advertentie-markt, hoe interessant en lucratief ook, eindig is. Er is op het Internet nog heel veel nieuws te doen, maar dat zal voor een groot deel betaald zijn. En dus zit er (ook) heel veel geld in betaalde services zoals opslag, Office-achtige functionaliteit, etc. En Google heeft al een infrastructuur en erg veel ervaring met grootschalige datacenters.
En dus beweegt Google zich ook in deze merkte, net als bijvoorbeeld IBM met z'n BlueCloud, Amazon.com en Microsoft, dat om te kunnen besparen op de koeling in Siberie gaat zitten.
Bedrijven die de mogelijkheden hebben om te investeren en die de naamsbekendheid hebben om te kunnen fungeren als betrouwbare broker voor betalingen en informatie te kunnen fungeren, hebben hier een voorsprong. Google behoort daar zeker toe, evenals de drie andere genoemde mastodonten. En verder wellicht ook Salesforce.com, Oracle, misschien SAP, en in de consumentenmarkt Yahoo!
Natuurlijk, als je alleen naar online backup kijkt (zoals Robin Harris hier doet), dan zijn er ook nog gespecialiseerde bedrijven die dat soort diensten leveren, zoals Mozy en Carbonite, en in Nederland ook KPN. Maar die hebben niet de mogelijkheid om uit te groeien tot broker, en kunnen ook niet goed hun online storage aanbieding combineren met standaard functionaliteit zoals Microsoft en Google dat doen, of op een heel andere manier Salesforc.com, Oracle en bijvoorbeeld SAP.
Google zit niet om "complementaire" redenen in die datacenters, Google zit erin omdat het geld gaat opleveren.
donderdag 22 november 2007
Web 3.0
Een aardig verhaal van Tim Berners-Lee over Web 3.0, het Semantische Web. Het lijkt allemaal nogal vergezocht, abstract en theoretisch, maar ik denk dat het in veel opzichten veel dichterbij en ook veel relevanter is dan doorgaans wordt gedacht.
Want de steeds verdergaande ontkoppeling tussen het ding of concept waarover we praten, en de weerspiegeling daarvan in bits, maakt het nodig om in termen van een abstract model (dat wil zeggen: los van de "implementatie") over de dingen te kunnen spreken, en ze ook in termen van dat model te kunnen manipuleren. SaaS maakt dat, omdat je bij SaaS vaak eigenlijk geen idee meer hebt hoe een en ander is geimplementeerd in datamodellen en in software, laat staan waar het op welk platform draait, des te meer nodig.
Maar gelukkig hebben we daarvoor ook de middelen, in ieder geval waar het business zaken betreft. UML, MOF, MDA, etc bieden een toolbox die iig een goed startpunt is.
Want de steeds verdergaande ontkoppeling tussen het ding of concept waarover we praten, en de weerspiegeling daarvan in bits, maakt het nodig om in termen van een abstract model (dat wil zeggen: los van de "implementatie") over de dingen te kunnen spreken, en ze ook in termen van dat model te kunnen manipuleren. SaaS maakt dat, omdat je bij SaaS vaak eigenlijk geen idee meer hebt hoe een en ander is geimplementeerd in datamodellen en in software, laat staan waar het op welk platform draait, des te meer nodig.
Maar gelukkig hebben we daarvoor ook de middelen, in ieder geval waar het business zaken betreft. UML, MOF, MDA, etc bieden een toolbox die iig een goed startpunt is.
dinsdag 20 november 2007
Kindle
Dit is leuk: de e-reader van Amazon.
Opmerkelijk: als ik het goed zie, kun je alleen via het mobiele telefoonnet met dit ding communiceren, en de reden is duidelijk: DRM. Deze constructie maakt het makkelijk mogelijk om ver buiten het bereik van hackers te blijven. En geeft content-verkopers (kranten, uitgevers, bloggers) de mogelijkheid om op een zinnige wijze aan geld te komen via het Internet. Zonder gelazer met advertenties.
Kun je je eigen documenten opladen? Niet direct, maar je kunt ze wel aan Amazon mailen, die converteert ze, en zet ze vervolgens automatisch op je Kindle. 10 ct per document, dat rijmt.
Gaat dit werken? Dat DRM is op het eerste gezicht een probleem. Maar ik denk dat door de
lage kosten dat wel los loopt. Als je veel betaalt voor iets, dan wil je ook dat je volledige vrijheid hebt, maar als de kosten laag zijn, en het bovendien vaak om tijdgebonden info gaat (kranten, tijdschrijften, blogs) dan is het geen probleem als je het alleen op dat apparaat kunt gebruiken. (Dat betekent ook dat ik het bij die boeken nog moet zien. Ongeveer $10 per boek is teveel, volgens mij.)
Ik denk dat het gaat werken. Ik zou het doen, denk ik, als ik een amerikaan was.
Opmerkelijk: als ik het goed zie, kun je alleen via het mobiele telefoonnet met dit ding communiceren, en de reden is duidelijk: DRM. Deze constructie maakt het makkelijk mogelijk om ver buiten het bereik van hackers te blijven. En geeft content-verkopers (kranten, uitgevers, bloggers) de mogelijkheid om op een zinnige wijze aan geld te komen via het Internet. Zonder gelazer met advertenties.
Kun je je eigen documenten opladen? Niet direct, maar je kunt ze wel aan Amazon mailen, die converteert ze, en zet ze vervolgens automatisch op je Kindle. 10 ct per document, dat rijmt.
Gaat dit werken? Dat DRM is op het eerste gezicht een probleem. Maar ik denk dat door de
lage kosten dat wel los loopt. Als je veel betaalt voor iets, dan wil je ook dat je volledige vrijheid hebt, maar als de kosten laag zijn, en het bovendien vaak om tijdgebonden info gaat (kranten, tijdschrijften, blogs) dan is het geen probleem als je het alleen op dat apparaat kunt gebruiken. (Dat betekent ook dat ik het bij die boeken nog moet zien. Ongeveer $10 per boek is teveel, volgens mij.)
Ik denk dat het gaat werken. Ik zou het doen, denk ik, als ik een amerikaan was.
donderdag 15 november 2007
Talenfragmentatie
Indertijd was één van de gedachten achter Java dat het een echt universele taal zou moeten zijn. Niet alleen dat Java (dankzij de JVM) op alle soorten machines kon draaien, maar ook dat je er alle soorten problemen mee te lijf kon. En daarom dus de introductie van aan Java verbonden standaarden als J2EE etc.
Echt gelukt is het niet, en de vraag is bovendien of het een goed idee is. Een paar dagen geleden schreef ik dat bv Ruby beter is voor het scripten van service aanroepen e.d. dan Java.
Microsoft vond het natuurlijk, om Microsoft moverende redenen, nooit een goed idee. Maar ik moet toegeven: MS heeft wat dit betreft hun money geput waar hun mouth is. MS en meer bepaald het Software Factories verhaal hebben een grote rol gespeeld in het op gang brengen van de DSL's (Domain Specific Language). En nu komt MS binnen de ontwikkelomgeving Visual Studio met een echte functionele programmeertaal: F#.
Interessante ontwikkeling. Ik weet niet of die hele fragmentatie van talen in alle opzichten zo'n goed idee is, maar boeiend is het wel.
Ik kom er op terug.
Echt gelukt is het niet, en de vraag is bovendien of het een goed idee is. Een paar dagen geleden schreef ik dat bv Ruby beter is voor het scripten van service aanroepen e.d. dan Java.
Microsoft vond het natuurlijk, om Microsoft moverende redenen, nooit een goed idee. Maar ik moet toegeven: MS heeft wat dit betreft hun money geput waar hun mouth is. MS en meer bepaald het Software Factories verhaal hebben een grote rol gespeeld in het op gang brengen van de DSL's (Domain Specific Language). En nu komt MS binnen de ontwikkelomgeving Visual Studio met een echte functionele programmeertaal: F#.
Interessante ontwikkeling. Ik weet niet of die hele fragmentatie van talen in alle opzichten zo'n goed idee is, maar boeiend is het wel.
Ik kom er op terug.
SOA als kathedraal
Keith Harrison-Broninksi (ja, zo heet ie echt) maakt een leuke vergelijking tussen een SOA (althans de middleware van een SOA) en een kathedraal uit de middeleeuwen. En zijn punt is: de vergelijking gaat mank.
Natuurlijk. Maar daarna wordt het interessant, want zijn punt is eigenlijk: als we een SOA bouwen, en de bijbehorende middleware installeren, dan trekken we een wissel op de toekomst. Want dat gaat alleen werken met een zekere mate van kost-effectiviteit als men zich houdt aan de ontwerp-principes en -richtlijnen, en er adequate tooling is om dat alles te beheren. En dat gaat niet gebeuren. Die tooling is er niet, en voor wat betreft die ontwerp-principes: we weten neit hoe zo'n SOA zich zal moeten ontwikkelen, en dat is ook niet te voorspellen, omdat er per definitie allerlei nu nog onbekende partijen bij zijn betrokken, etc, etc.
Inderdaad. En ik voeg daar aan toe: we weten eigenlijk niet eens wat die ontwerp-principes dan wel zijn, laat staan dat we ze toepassen.
Ik weet niet of Keith H-B het met me eens is, maar ik trek hieruit de conclusie: het is (in het algemeen) onverstandig nu zwaar te investeren in een SOA of in een ESB, tenzij die investeringen op zeer korte termijn al worden terugverdiend. Als dat niet zo is, moet een aanpak worden gekozen waarbij wel zo goed mogelijk services worden ontworpen en geimplementeerd, en waarbij een zo eenvoudig mogelijke ESB wordt geïmplementeerd, als zoiets al nodig is.
Zowel in het design als in de tooling moet rekening gehouden worden met het feit dat de wereld er morgen wel eens fors anders uit kan zien.
Een goede aanpak is om te nu al te onderzoeken hoeveel eigenlijk via een SaaS-oplossing buiten de deur kan worden gelegd. Vaak zal dat nu al de beste en goedkoopste oplossing blijken, maar zelfs als dat niet zo is, is het toch verstandig om daarop te anticiperen. Het maakt een latere overgang naar SaaS makkelijker, en vooral: je blijft zo dicht bij de ontwikkerichting van de standaarden. Want die zullen uiteraard vooral door de SaaS-oplossingen worden bepaald, omdat daar interoperabiliteit het hoogste is.
Natuurlijk. Maar daarna wordt het interessant, want zijn punt is eigenlijk: als we een SOA bouwen, en de bijbehorende middleware installeren, dan trekken we een wissel op de toekomst. Want dat gaat alleen werken met een zekere mate van kost-effectiviteit als men zich houdt aan de ontwerp-principes en -richtlijnen, en er adequate tooling is om dat alles te beheren. En dat gaat niet gebeuren. Die tooling is er niet, en voor wat betreft die ontwerp-principes: we weten neit hoe zo'n SOA zich zal moeten ontwikkelen, en dat is ook niet te voorspellen, omdat er per definitie allerlei nu nog onbekende partijen bij zijn betrokken, etc, etc.
Inderdaad. En ik voeg daar aan toe: we weten eigenlijk niet eens wat die ontwerp-principes dan wel zijn, laat staan dat we ze toepassen.
Ik weet niet of Keith H-B het met me eens is, maar ik trek hieruit de conclusie: het is (in het algemeen) onverstandig nu zwaar te investeren in een SOA of in een ESB, tenzij die investeringen op zeer korte termijn al worden terugverdiend. Als dat niet zo is, moet een aanpak worden gekozen waarbij wel zo goed mogelijk services worden ontworpen en geimplementeerd, en waarbij een zo eenvoudig mogelijke ESB wordt geïmplementeerd, als zoiets al nodig is.
Zowel in het design als in de tooling moet rekening gehouden worden met het feit dat de wereld er morgen wel eens fors anders uit kan zien.
Een goede aanpak is om te nu al te onderzoeken hoeveel eigenlijk via een SaaS-oplossing buiten de deur kan worden gelegd. Vaak zal dat nu al de beste en goedkoopste oplossing blijken, maar zelfs als dat niet zo is, is het toch verstandig om daarop te anticiperen. Het maakt een latere overgang naar SaaS makkelijker, en vooral: je blijft zo dicht bij de ontwikkerichting van de standaarden. Want die zullen uiteraard vooral door de SaaS-oplossingen worden bepaald, omdat daar interoperabiliteit het hoogste is.
woensdag 14 november 2007
SmoothSpan over Cognos, IBM en Oracle
Verstandige woorden op SmoothSpan. Inderdaad, het veld verandert. En ook Oracle zal proberen mee te gaan, zeker nu SAP het SaaS-pad heeft gekozen met ByDesign.
maandag 12 november 2007
Talen
Ik zit te werken met coding voor de aanroep van Webservices via SOAP en via REST, en één ding is duidelijk: een taal als Java is hiervoor niet geschikt. Java is wellicht OK voor de binnenkant, maar voor de buitenkant is Ruby verre te prefereren.
Ministerie van Waarheid en Betekenis
Tim O'Reilly is kritisch over OpenSocial. Zijn punt: OpenSocial is een API, terwijl wat je nodig hebt juist uitwisselbaarheid van data is. O'Reilly's kritiek in deze op OpenSocial is niet helemaal terecht, en daarop wordt hij in de reacties ook gewezen. En O'Reilly erkent dat ook.
Maar wat breder bezien (afgezien dus van OpenSocial) heeft O'Reilly wel een punt. Het gaat inderdaad om de gegevens, en de uitwisseling daarvan. Of wat preciezer gezegd: om de objecten, dat wil zeggen: groepen gegevens met een beschreven duidelijke betekenis, en een bekende samenhang met andere (groepen) gegevens. Hiervoor is natuurlijk een soort betekenis-standaardisatie nodig. En hier komen ongetwijfeld begrippen als (web) ontology, metamodeling, etc om de hoek kijken. Dat is duidelijk.
Hoe gaan die standaarden er komen? Zal er een soort wereldwijd Ministerie van Waarheid en Betekenis komen, ongetwijfeld onder auspiciën van de OMG, of zal Microsoft weer eens wat roepen?
Geen van beide natuurlijk. Dat Ministerie zal er niet komen, OMG of niet, en Microsoft is als het om de wereld van services enzo gaat, snel bezig een also-ran te worden. Maar er zijn legio andere bedrijven die graag de dominante positie van Microsoft willen overnemen. Om te beginnen natuurlijk het alomtegenwoordige Google. En voor wat betreft deelgebieden is er bijvoorbeeld SAP als het om ERP-services gaat, en bijvoorbeeld Amazon als het gaat om platform-services zoals Payments (het elegante Amazon FPS).
Maar de kans dat een dergelijke industriestandaard snel een echte 100% standaard zal zijn is klein. Is dat erg? Ik denk het niet, zolang maar duidelijk is waar de standaarden op een bepaald gebied zich van elkaar onderscheiden. Het is niet erg dat er bv een Payment standaard van Amazon is, en een andere van bv PayPal, zolang maar duidelijk is wat de verschillen zijn, en hoe die eventueel overbrugd kunnen worden.
Daarvoor zijn abstracte modellen (vaak ten onrechte metamodellen genoemd) nodig. In dergelijke modellen zal een bedrijf zijn business modelleren, en vervolgens mappen op de modellen van de Googles, Amazons, SAPs, Oracles, SalesForces, en ook Microsofts van deze wereld. Die modellen zullen "vanzelf" ontstaan als best practices voor een bepaald soort domein, en snel worden verspreid in de IT-industrie, zoals dat altijd is gegaan.
Maar wat breder bezien (afgezien dus van OpenSocial) heeft O'Reilly wel een punt. Het gaat inderdaad om de gegevens, en de uitwisseling daarvan. Of wat preciezer gezegd: om de objecten, dat wil zeggen: groepen gegevens met een beschreven duidelijke betekenis, en een bekende samenhang met andere (groepen) gegevens. Hiervoor is natuurlijk een soort betekenis-standaardisatie nodig. En hier komen ongetwijfeld begrippen als (web) ontology, metamodeling, etc om de hoek kijken. Dat is duidelijk.
Hoe gaan die standaarden er komen? Zal er een soort wereldwijd Ministerie van Waarheid en Betekenis komen, ongetwijfeld onder auspiciën van de OMG, of zal Microsoft weer eens wat roepen?
Geen van beide natuurlijk. Dat Ministerie zal er niet komen, OMG of niet, en Microsoft is als het om de wereld van services enzo gaat, snel bezig een also-ran te worden. Maar er zijn legio andere bedrijven die graag de dominante positie van Microsoft willen overnemen. Om te beginnen natuurlijk het alomtegenwoordige Google. En voor wat betreft deelgebieden is er bijvoorbeeld SAP als het om ERP-services gaat, en bijvoorbeeld Amazon als het gaat om platform-services zoals Payments (het elegante Amazon FPS).
Maar de kans dat een dergelijke industriestandaard snel een echte 100% standaard zal zijn is klein. Is dat erg? Ik denk het niet, zolang maar duidelijk is waar de standaarden op een bepaald gebied zich van elkaar onderscheiden. Het is niet erg dat er bv een Payment standaard van Amazon is, en een andere van bv PayPal, zolang maar duidelijk is wat de verschillen zijn, en hoe die eventueel overbrugd kunnen worden.
Daarvoor zijn abstracte modellen (vaak ten onrechte metamodellen genoemd) nodig. In dergelijke modellen zal een bedrijf zijn business modelleren, en vervolgens mappen op de modellen van de Googles, Amazons, SAPs, Oracles, SalesForces, en ook Microsofts van deze wereld. Die modellen zullen "vanzelf" ontstaan als best practices voor een bepaald soort domein, en snel worden verspreid in de IT-industrie, zoals dat altijd is gegaan.
donderdag 8 november 2007
RedHat Linux op Amazon's EC2
Waar het in de SaaS-ontwikkelingen (ook) over gaat is: de ontwikkeling van een remote service naar een compleet platform, waarop leveranciers van services hun systemen kunnen ontwikkelen en laten draaien.
OpenSocial (waarover eerdere postings hier, hier en hier) is een stap daarin, vooral omdat het een standaard schept die door vele leveranciers wordt ondersteund.
En aangezien het herfst is, vallen de platforms als bladeren uit de boom: RedHat gaat hun Linux als een service aanbieden op het EC2 (Elastic Computing Cloud) van Amazon.com. Als ik het goed zie, houdt dat in dat je een "linux-machine" (in feite een virtuele machine natuurlijk) kunt huren, en daar de spullen op kunt zetten die je wilt.
Hoe het met ontwikkeling zit, weet ik nog niet. Ik veronderstel dat dat vooralsnog lokaal (dwz: via een "eigen" ontwikkelstraat moet. Al kan dat misschien ook wel op de EC2.
OpenSocial (waarover eerdere postings hier, hier en hier) is een stap daarin, vooral omdat het een standaard schept die door vele leveranciers wordt ondersteund.
En aangezien het herfst is, vallen de platforms als bladeren uit de boom: RedHat gaat hun Linux als een service aanbieden op het EC2 (Elastic Computing Cloud) van Amazon.com. Als ik het goed zie, houdt dat in dat je een "linux-machine" (in feite een virtuele machine natuurlijk) kunt huren, en daar de spullen op kunt zetten die je wilt.
Hoe het met ontwikkeling zit, weet ik nog niet. Ik veronderstel dat dat vooralsnog lokaal (dwz: via een "eigen" ontwikkelstraat moet. Al kan dat misschien ook wel op de EC2.
dinsdag 6 november 2007
Google en de commoditisering
En Google gaat door met de commoditisering van Internet-platforms: nu voor handheld devices. Ik ben benieuwd.
vrijdag 2 november 2007
Nog meer OpenSocial
Google heeft de specificatie van OpenSocial gepubliceerd.
Ik heb er een snelle blik op geworpen, en inderdaad: OpenSocial is gericht op sociale sites en zo, maar er is geen fundamentele reden waarom het niet ook voor bedrijfsapplicaties kan worden gebruikt. Al is het wel wat onhandig.
Maar daar zou je met bv een model-driven benadering of een additionele ontwikkelomgeving wel "omheen" kunnen.
Ik heb er een snelle blik op geworpen, en inderdaad: OpenSocial is gericht op sociale sites en zo, maar er is geen fundamentele reden waarom het niet ook voor bedrijfsapplicaties kan worden gebruikt. Al is het wel wat onhandig.
Maar daar zou je met bv een model-driven benadering of een additionele ontwikkelomgeving wel "omheen" kunnen.
donderdag 1 november 2007
OpenSocial vervolg
Gisteren postte ik nav de introductie van OpenSocial, een door Google geïnstigeerde standaard API voor applicaties op sociale netwerken, zoals Ning of Orkut. En het wordt allerwegen geïnterpreteerd als een aanval op FaceBook.
De standaard is op zo te zien gebaseerd op een REST-achtige benadering (HTTP, Ajax, Flex, etc).
Wat opvalt in de groep "launching partners" is de aanwezigheid, naast voor de hand liggende partijen als Friendster en Ning, de aanwezigheid van Salesforce.com en Oracle. Want die zitten niet speciaal in de sociale netwerken, zou je zeggen.
Maar toch is het niet zo gek. Want ook voor "business software" geldt hetzelfde probleem: je wilt wel software ontwikkelen voor bijvoorbeeld Force.com (van Salesforce.com), maar lock-in is een groot risico, en zelfs een risico wat veel potentiële klanten zal tegenhouden.
Een standaard als OpenSocial gaat wellicht dat risico kleiner maken.
Update: zie onder andere dit in de NYT van gisteren, en dit op TechCrunch.
De standaard is op zo te zien gebaseerd op een REST-achtige benadering (HTTP, Ajax, Flex, etc).
Wat opvalt in de groep "launching partners" is de aanwezigheid, naast voor de hand liggende partijen als Friendster en Ning, de aanwezigheid van Salesforce.com en Oracle. Want die zitten niet speciaal in de sociale netwerken, zou je zeggen.
Maar toch is het niet zo gek. Want ook voor "business software" geldt hetzelfde probleem: je wilt wel software ontwikkelen voor bijvoorbeeld Force.com (van Salesforce.com), maar lock-in is een groot risico, en zelfs een risico wat veel potentiële klanten zal tegenhouden.
Een standaard als OpenSocial gaat wellicht dat risico kleiner maken.
Update: zie onder andere dit in de NYT van gisteren, en dit op TechCrunch.
Abonneren op:
Posts (Atom)