Mat 2.0: SaaSaaS

Dat is makkelijk....

2011-02-25T18:08:00.001+01:00

Amazon maakt het opzetten van een cloud service belachelijk makkelijk, als dit waar is. Ik zal eens gaan proberen of het inderdaad zo simpel is.

Ricardo, Tyler Cowen en de ideeen

2010-10-15T16:19:00.002+02:00

Dit is een erg leuke gedachte van Tyler Cowen. Heb zelf ook wel eens in die richting zitten denken.

Hierarchische modellen

2010-10-08T17:10:00.001+02:00

Models 2010, ik kreeg het binnen via Markus Voelter. Die keynote van Edward Lee, daar was ik graag bijgeweest, om maar eens wat te noemen.

REST en WS*, het gaat maar door

2010-06-25T14:41:00.003+02:00

Steve Jones breekt de staf over REST. Volgens hem niet geschikt voor de "enterprise". Lees vooral ook de comments.

Kern van de zaak is, denk ik, dat hij REST benadert als 1-op-1 alternatief voor WS-*. Dat is het niet. Als je probeert REST te gebruiken op precies dezelfde manier als WS-*, dan kom je van een koude kermis thuis.

Veel grote systemen hebben message-georienteerde interfaces die makkelijk te "vertalen" zijn naar WS-*, maar veel moeilijker naar REST. Rest evreist eigenlijk dat je je interne model publiceert. Doe je dat, dan werkt het vrijwel naadloos. Maar als dat niet kan, moet je een soort pseudo-model maken, dat publiceren en via REST benaderbaar maken, en vervolgens die in termen van het model geformuleerde boodschappen vertalen naar het echte systeem daarachter.

Het kan allemaal wel, maar het is niet simpel.

Cloud development en MDD

2010-04-27T22:52:00.003+02:00

Johan den Haan heeft een aantal goede stukken, vooral over het punt waarom de cloud en MDD (of MDSD of hoe je het ook noemt) een goede combinatie is. Lezenswaard.

Deed me vaag denken aan een eerdere discussie met Johan, en inderdaad: op 21 augustus 2008 schreef ik in een reactie op Johan:

" 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."

Wat mij betreft is een belangrijk voordeel van MDD voor de cloud dat het een manier is (waarschijnlijk de beste) om functionaliteit portable te maken tussen verschillende clouds, en daarmee lock-in te vermijden.

Hoe dan ook, ik neem me voor nog op Johans verhaal terug te komen.

De Turingtest

2010-04-23T15:06:00.002+02:00

Nick Carr in een lezenswaardige blogpost: "I take this as another indication that I am correct in my suspicion that when computers finally pass the Turing test it won't be because computers have become smarter; it will be because humans have become dumber.

lol"

Inderdaad, lol.

Fowler over REST

2010-03-25T15:17:00.001+01:00

Goed, basaal stuk van Martin Fowler over REST.

Apple vs. HTC/Google

2010-03-04T08:56:00.001+01:00

Tis weer raak: Apple spant allerhande procedures aan tegen HTC, en dan gaat het vooral om Android, dus eigenlijk tegen Google.

Heb wat van die dingen zitten lezen, en het is treurigmakend. Groot deel zijn obviositeiten.

En bovendien: door dit gezeur ondermijn je innovatie.

Het is te hopen dat de zaak snel wordt geregeld (bv door dat Google inspringt, en dreigt met een patentoorlog tegen Apple. HTC heeft daar zelf de patentportefeuille niet voor.) want anders hangt er jarenlang een wolk over Android. En dat is niet goed.

Ondertussen zijn Microsoft, RIM en Symbian/Nokia de lachende derde, vierde en vijfde. Want zij hebben waarschijnlijk wel de portefeuille om Apple af te schrikken.

Men wordt er niet vrolijk van. En voor wat het waard is: het is niet goed voor de naam van Apple.

Cloud development: inleiding

2010-02-16T10:29:00.002+01:00

Een aardig inleidend stuk van Iam Wilkes over cloud development op Ars Technica.

Conclusie: het beweegt, maar de grote klapper zit er nog niet bij. En dat is ook mijn beeld. GAE is veelbelovend, maar wel onhandig en hier en daar wel erg proprietary. Dat laatste geldt ook voor Salesforce Apex.

Alternatief is natuurlijk zelf ontwikkelen en dan deployen op bv Amazon AWS, maar dat is niet echt cloud development.

Dan zijn er een aantal kleinere partijen die gebruik maken van een groot cloudplatform om daar bovenop een ontwikkelplatform te bieden. Voorbeeld is Heroku, dat op AWS draait. Helemaal enthousiast werd ik daar ook niet van.

De vraag is: welke eisen moeten aan een ontwikkelomgeving in de cloud worden gesteld? Moet het alles bieden wat bv Eclipse biedt? Minder? Wat mag er dan af? Meer? Wat moet er bij? Enzovoort.

Wordt ongetwijfeld vervolgd.

Ondergang van MS

2010-02-04T22:00:00.001+01:00

Interessant stuk in NYT over waarom MS naar de filistijnen ging.

Open of gesloten?

2010-01-27T13:30:00.001+01:00

Goed stuk van Nick Carr, over de opkomst van "walled gardens" voor applicaties, zoals de iPhone App Store.

Google en China

2010-01-19T13:28:00.002+01:00

Gideon Rachman heeft een erg goed stuk in de FT. Hij plaatst de Google-kwestie in een breder kader.

In het westen, en in het bijzonder in de VS, is men er vanuit gegaan dat meer handel, meer internet, China zou doen liberaliseren. Dat lijkt toch niet het geval, en tezamen met een toenemende neiging tot protectionisme, zou dat wel eens tot een conflict tussen de VS en China kunnen leiden, zowe op handels- als op politiek gebied.

Google uit China: waarom?

2010-01-16T13:01:00.008+01:00

In veel commentaren (o.m. Nick Carr) werd de nadruk gelegd op het feit (idd, een feit) dat de cloud erg veel belang heeft bij veiligheid, en dat cloud bedrijven, en al helemaal een als Google, dus moeten laten zien dat ze daarmee niet marchanderen. Op zichzelf een juiste constatering.

Maar als reden voor het terugtrekken uit China (want daar zal Google's actie toch wel op neer gaan komen) is het niet voldoende. Want waarom zouden hackers uit china (of de chinese overheid) ophouden Google lastig te vallen als google.cn niet meer bestaat?

Als China nu wil inbreken in de mail accounts van dissidenten, dan willen ze dat na het verdwijnen van Google uit China nog steeds.

Dus lijkt het erg waarschijnlijk dat principes een rol hebben gespeeld. In veel commentaren (o.m. Jessica Vescellaro in de WSJ) wordt daarbij een grote rol toegeschreven aan Sergey Brin. Zo gek is dat niet. Men voelde zich bij Google toch al niet zo lekker bij die censuur op Google.cn. Als er verder vanuit China geen enkel probleem was geweest, was het zo gebleven. Maar als die hackersaanval er dan bij komt, is het een "optelsom", zoals voetbalscheidsrechters dat noemen.

China, Google en de cloud

2010-01-13T16:01:00.003+01:00

Larry Dignan heeft een interessante kijk op de Google-China kwestie. Hij wijst erop dat voor Google vertrouwen van de klant essentieel is. Google beheert tenslotte allerlei vaak zeer vertrouwelijke gegevens van de klant.

De situatie in China was wat dat betreft natuurlijk altijd al wat lastig voor Google, en de recente aanvallen op Google's gegevens (en daarmee de gegevens van de klant) waren ook om die reden voor Google erg slecht te verteren.

Enterprise IT als Noord-Zuid-lin

2010-01-13T11:24:00.004+01:00

We bakken er niks van, als het om "Enterprise systems" gaat, in ieder geval volgens Tim Bray. De werkwijze op het Web biedt meer mogelijkheden dan de grootschalige geldverspilling bij het bouwen van grote IT-systemen.

En in zijn reactie ziet Dion Hinchcliffe de oplossing in Web 2.0 en de cloud. Maar hij ziet daar altijd de oplossing.

Ik ben het wel met beide heren eens. Zeker grootschalige IT voelt wel eens aan als een Betuwe- of Noord-Zuid-lijn: erg duur, en gaande het traject steeds duurder. Misschien kon het vroeger niet anders, en moesten er inderdaad dit soort systemen gebeouwd worden. Maar voor bijna alle gevallen is die tijd achter ons. Pakketten lossen al veel op, en de cloud maakt het nog goedkoper en makkelijker herbruikbaar.

Alleen: je moet wel bereid zijn IT niet meer als een strategisch voordeel te zien. In de praktijk is dat toch al vrijwel nooit zo, en als het al wel zo is, wordt het snel gekopieerd.

Phil Wainewright luidt het jaar uit

2009-12-29T14:53:00.004+01:00

Met het stellen van een paat stevige opvattingen: Cloud delusions, oftewel: misvattingen over cloud computing en SaaS.

Ik ben het vrijwel van A tot Z met hem eens. Een beetje cloud computing heeft weinig zin.

Productiviteit van programmeurs

2009-12-24T17:07:00.003+01:00

Er zit een groot verschil in productiviteit van programmeurs. Maar vreemd genoeg zie je dat over het algemeen niet erg terug in de beloning. Dit verhaal van John Cook gaat daarover.

Stof tot nadenken.

Dood paard

2009-12-17T12:44:00.001+01:00

SOA als dood paard bij Geek and poke. Erg leuk.

(Hat tip Jan L.)

Spot market bij AWS

2009-12-16T14:35:00.002+01:00

AWS verkoopt nu EC2 capaciteit op een soort spot market: je geeft aan hoeveel je wilt en tegen welke maximum prijs. AWS bepaalt de prijs op basis van de vraag en de beschikbare capaciteit.

Schitterend: Amazon kan zo nog beter de capaciteit optimaliseren, en dus goedkoper maken (of winstgevender), en de klant krijgt capaciteit voor een lagere prijs, als ie genoegen neemt met een lagere prioriteit.

Dit soort innovaties maakt de cloud goedkoper. En dat is wellicht de belangrijkste drijfveer om over te stappen.

SPDY, Google en HTTP

2009-11-18T14:56:00.002+01:00

SPDY is een soort uitbreiding van HTTP, voorgesteld door Google om het Internet sneller te maken. Het gaat dan met name om de latencies die door HTTP worden veroorzaakt.

SPDY draait gewoon bovenop TCP, en is niet zozeer een vervanging van als wel een aanvulling op HTTP. GET en POST, en ik denk ook PUT en DELETE, blijven gewoon bestaan.

Whitepaper is zeer goed leesbaar en begrijpelijk.

We zullen zien wat er van komt.

Event-based programming de nieuwe GOTO?

2009-11-10T13:35:00.001+01:00

Kreet klinkt goed. Of het ook ergens op slaat weet ik niet, moet ik even over nadenken.

Maar de template "a is nieuwe b" ben ik iha nogal een voorstander van. "Java is het nieuwe Cobol". :) Iedereen in de gordijnen.

15 jaar Design Patterns

2009-11-09T20:41:00.002+01:00

Naast de Val van de Muur nog een verjaardag: 15 jaar Design Patterns. Hier paar aardige stukken daarover.

Was het inderdaad (ook) een revolutie? Mwah, nee. Het was een erg goed idee, een stap in De Juiste Richting, etc, etc, maar een revolutie? Nee. Eigenlijk bestonden design patterns al, ook in de softwarebouw, maar we noemden ze anders.

Een sorteeralgoritme of een Balance-Line constructie uit de Jackson hoek zijn niets anders dan design patterns. En in beide gevallen ook keurig beschreven, met indicaties, contra-indicaties, voorbeelden, en wat niet al.

Dus nee, geen revolutie.

Waarom het toen zo'n enorme ophef teweeg bracht heb ik toen niet begrepen, en naderhand eigenlijk ook niet.

Maar dat neemt niet weg dat het een mijlpaal was.

RDBMS bij Amazon

2009-10-27T09:47:00.003+01:00

Amazon AWS brengt nu naast de al bestaande key-value database ook een RDBMS (My SQL) in de cloud. Ik ben er wel blij mee.

Uit de email aan de klanten:

"We are excited to announce the public beta of Amazon Relational Database Service
(Amazon RDS), a new web service that makes it easy to set up, operate, and scale
relational databases in the cloud. Amazon RDS gives you all the features and
capabilities of a MySQL database, while managing time-consuming database
administration tasks and providing the cost-efficiency of running in the AWS cloud.
We're also excited to announce lower prices for Amazon Elastic Compute Cloud (Amazon
EC2) instances and a new family of Amazon EC2 High-Memory Instances, tailored for
customers wanting to run their own large databases and other memory intensive
applications. To get started using Amazon RDS, High-Memory Instances for Amazon EC2,
and other Amazon Web Services, visit http://aws.amazon.com

Amazon RDS provides a fully featured MySQL database, so the code, applications, and
tools that you use today with your existing MySQL databases work in Amazon RDS
without modification. The service automatically handles common database
administration tasks, such as setup and provisioning, patch management, and backup.
You also have the flexibility to scale the compute and storage resources associated
with your database instance through a simple API call. "

MDSD en DSLs

2009-10-20T20:00:00.000+02:00

Goed stuk van Markus Voelter.

Amateur cloud

2009-10-19T15:14:00.001+02:00

Goed stuk van de voortreffelijke Phil Wainewright. Bestaande datacenter oplossingen zomaar in the cloud zetten werkt niet.

Rik in de cloud

2009-09-29T23:21:00.002+02:00

Rik Laurens meent: SOA en WOA komen elkaar tegen in de cloud, en hebben elkaar nodig. het is moeilijk het hiermee oneens te zijn, maar ik ga het denk ik toch proberen.

Maar eens een nachtje over slapen.

Appstore voor cloud applicaties?

2009-09-16T10:42:00.002+02:00

Dit gaat richting een AppStore voor cloud applicaties. Interessante ontwikkeling.

Micropayments bij Google

2009-09-11T17:46:00.001+02:00

Dat zat er natuurlijk een keer aan te komen. Maar waarom het nou zo verschillend is van Amazon's FPS weet ik niet.

Wel een interessante move, echter.

REST als enterprise architectuur (2)

2009-09-05T20:33:00.004+02:00

Donderdag schreef ik er al kort over. Nu deze aardige aanvulling van de voortreffelijke Stefan Tilkov. Gelijk heeft ie.

Koren op mijn MDD-molen

2009-09-05T17:26:00.001+02:00

Als voorstander van MDD is dit (ook van InfoQ) natuurlijk koren op mijn molen.

REST als enterprise architectuur

2009-09-03T19:49:00.002+02:00

Het onvolprezen InfoQ heeft deze aardige samenvatting van de discussie of je REST ipv klassieke SOA binnen bedrijven kunt gebruiken.

Mijn mening is natuurlijk bekend, dus laat ik het er nu even bij. Morgen misschien meer.

Virtual private clouds

2009-08-29T10:42:00.002+02:00

Een logische ontwikkeling. Zie Amazon en ook OpSource. Je eigen afgeschermde spullen, maar wel op de cloud van resp. AWS en OpSource, met de voordelen van dien.

Het zal koudwatervrees wegnemen, maar ik heb toch de neiging om het als een tussenstadium te zien. Want ik verwacht dat in de meeste gevallen de "echte" cloud toch beter past bij de systemen van de toekomst.

We zullen zien.

IT volwassen?

2009-08-09T10:40:00.003+02:00

Volgens Thomas Siebel wel. En dus zijn de tijden van de waanzinngie winsten volgens hem afgelopen. Koren op de molen van Nick Carr (van IT doesn't matter) en de zijnen, waar ik mezelf ook maar toe reken.

Maar wat mij betreft wel een paar opmerkingen:
1. Business-IT is redelijk "volwassen". Dat wordt steeds meer een commodity. Maar ook in commodities is geld te verdienen, soms zelfs veel. Juist hier zal de beweging naar de cloud zorgen voor een grote kostenbesparing voor de gebruikers, maar ook voor veel beweging aan de aanbod-kant. Of dat zal leiden tot enorme winsten is inderdaad de vraag.
2. Er is meer IT dan alleen business-IT. Iedereen roept dan gelijk games en zo, en terecht, maar er zitten nog veel meer dingen aan te komen: semantic web, de mobiele revolutie, etc, etc. Er gebeurt genoeg.

Maar de gouden tijd van de klassieke bedrijfs-IT als moneyspinner zou inderdaad wel eens voorbij kunnen zijn.

Archetype georienteerde kennismodellering

2009-07-07T10:56:00.003+02:00

Al weer enige tijd geleden schreef ik over archetypes en de mogelijkheden om met een archetype-georiënteerde aanpak kennisdomeinen te modelleren, van daaruit software te genereren en bestaande legacy te "harvesten".

Vragen die toen nog niet speelden:
1. is het mogelijk om in plaats van de gangbare OO-modelleringstalen (bv UML) meer SW-achtige talen te gebruiken, zoals OWL of RDF?
(Voorlopig antwoord: ja. Een klein proefje met colors en RDF lijkt goede resultaten te geven.)
2. Hoe makkelijk is het om dergelijke modellen in een ROA of WOA te gieten?
(Voorlopig antwoord: uitstekend! Maar jury is still out.)

Affijn, heerlijke materie, en ik houd u op de hoogte.

Functionele talen, Java en het Web, en het Stockholm-syndroom

2009-06-08T10:45:00.003+02:00

Een erg interessant verhaal van de voortreffelijke Steve Vinoski over functionele talen en de manier waarop Java langzaam achter de horizon gaat verdwijnen.

Vooral deze passage:

"Imperative languages such as Java and C++ have come to be known as “high ceremony” languages because of the often mind-numbing amount of syntactic boilerplate and complex object interaction patterns they impose just to get relatively simple applications up and running. Many developers turn to interactive development environments (IDEs) to help them manage this verbosity and complexity, but, in my opinion, this just works around the real problem rather than solves it."

en:

"Using the wrong languages like this can impose a much larger tax on development efficiency than you might realize. Like the proverbial frog in the pot of water on the stove, eventually boiling to its demise as the water temperature slowly increases because it can’t sense the changes until it’s too late, developers who primarily use popular imperative languages like Java and C++ can become so accustomed to the boilerplate, verbosity, and ceremony these

languages require that they simply don’t realize just how inefficient their development efforts really are. Given how defensive such languages’ users can often be, perhaps this form

of programming language loyalty is a less sinister variant of Stockholm syndrome, where captives counterintuitively develop a sense of devotion and emotional attachment to

their captors."

Prachtig! En eerlijk gezegd herkenbaar.

Maar waar het echt om gaat is natuurlijk: zijn die FPs echt beter? Hoe belangrijk is de relatie met REST in dit verband?

Mijn (voorlopig slechts) intuïtie is: ja. Maar hoe verhoudt OO zich tot dit verhaal?

Ja, Java is (min of meer) imperatief, maar dat hoeft niet. Vinoski zelf noemt Ruby, en diezelfde mechanismen ken ik nog van SmallTalk (waar Ruby sterk aan doet denken, uiteraard).

De terugkeer van eiland-automatisering

2009-06-01T14:42:00.001+02:00

Dit is een leuk stuk (van Jimmy Nilsson). Goed verhaal, ik zal proberen er op terug te komen.

Essentie: eiland-automatisering, domain-driven, gekoppeld op een slimme manier. Een lied wat ik al lang zing...

Stapelwolken

2009-05-29T15:17:00.003+02:00

Volgens dit verhaal kun je binnenkort de GoogleAppsEngine en Salesforce.com aan elkaar koppelen, en bijvoorbeeld gegevens van Salesforce gebruiken in een op GAE gebouwde en draaiende applicatie.

Dat kon natuurlijk eigenlijk al, maar dan moest je op vaak erg ingewikkelde manier die platforms zelf koppelen, en dat deed dus niemand. Want cloud-computing doe je (vooral) om het simpel en goedkoop te houden, en zoiets is allesbehalve simpel en goedkoop.

Voor Google is het natuurlijk heel belangrijk, omdat Google zo beter toegang krijgt tot de zakelijke markt. En voor Salesforce betekent het waarschijnlijk een toevloed van ontwikkelaars, die liever op het veel flexibeler en krachtiger GAE ontwikkelen.

Verstandige woorden over REST?

2009-05-21T09:38:00.003+02:00

Van Boris Lublinsky. En dat is weer gebaseerd op deze post van Arnon Rotem-Gal-Oz (jazeker).

De laatste zegt:
"Let's look at message exchange patterns for instance. REST over HTTP support the request/reply pattern.
This works extremely well in many business situation. For instance is we have an Order service (or resource for that matter) and we need to calculate the discount for a specific customer we can go to the Customer service and get her current status and check if she a VIP customer, senior citizen etc.
There are, however, places where it doesn't work as smoothly. Returning to our Order, lets consider what happen once the order is finalized and we need to both start handle it (notify the warehouse?) and Invoice it
The order service does not care about these notifications it isn't its business.
My favorite way to solve this is to introduce business events (incorporate Event Driven Architecture) so that the interested parties will get notified. Another common way to solve this is to introduce some external entity to choreograph or orchestrate it (BPM etc.) both options have different constraints and needs compared with REST. In my organization we have a lot of processes that lend themselves to event processing much better than they do REST over HTTP (though the implementation might end up aligned with the REST architectural style - I am not sure yet)"

Hmmm. Waarom is die Order niet geinteresseerd in bijv. de handling in het warehouse of de invoicing?

Ik snap wel dat er situaties zijn waarin REST niet lekker werkt, maar dit is een onzinvoorbeeld.

WOA Governance?

2009-05-14T10:42:00.003+02:00

Ik kwam (via het onvolprezen InfoQ) dit verhaal tegen van Dan Foody.

Hij pleit voor een soort WOA Governance. Hmmmm, ik weet het niet. Misschien zijn er wel wat dingen nodig en nuttig die hij noemt (bijvoorbeeld versioning), maar om dat "governance" te noemen, is wat misleidend.

Want "governance" heeft de bijsmaak (Dan Foody suggereert dat ook, trouwens) van uitoefening van macht of gezag door "architecten". En dat kan in de WOA-omgevng (want dat is gewoon het Web) niet.

Neemt niet weg dat hij een interessant punt heeft. En daar gaan we over nadenken.

Verstandige taal van Phil Wainewright

2009-05-08T16:13:00.001+02:00

zoals gebruikelijk.

"A constantly recurring theme in the evolution of SOA, cloud and the Web has been the misplaced imposition of trusted, existing structures onto emergent patterns of interaction. This applies with special emphasis to hybrid clouds — build them to fit with your existing, unchanged infrastructure and you’ll get little-to-no benefit. Change your enterprise to really leverage the cloud and nine times out of ten, you won’t have any further use for a hybrid model."

Wolfram Alpha

2009-04-26T11:16:00.001+02:00

Een nieuwe search engine, maar geen Google-imitator. Klinkt goed, lijkt het soort vragen te beantwoorden die ik graag stel.

E-books en de toekomst

2009-04-21T11:18:00.001+02:00

Steven Johnson in de WSJ over hoe de komst van e-books veranderingen teweeg zal brengen. Volgens mij zit ie behoorlijk goed.

Oracle koopt Sun

2009-04-21T09:55:00.001+02:00

Een paar punten uit de losse pols:

1. de aankoop van Sun door Oracle is volgens mij op de eerste plaats
defensief. Oracle drijft of dreef op licenties voor on-site software
(mn de Oracle DB en het ERP systeem). Door de komst van SaaS en cloud
computing staat dat onder zware druk. Door de aankoop van Sun
diversificeert Oracle.

2. Sun heeft een goed cloud aanbod, de Sun Cloud. Dat kan Oracle
kansen bieden in de cloud computing markt. en daarmee het verlies van
de licentie-inkomsten enigszins compenseren.

3. Sun heeft de ws. gevaarlijkste concurrent van het Oracle
DB-systeem: MySQL. Ik ben benieuwd wat Oracle daarmee gaat doen.
Afsplitsen?

4. Sun is de eigenaar van Java. Zal Oracle ook dat gaan afsplitsen?

5. Met de aankoop van Sun koopt Oracle de mogelijkheid om het bedrijf
een andere richting (cloud computing, hardware, OS-produkten) in te
laten slaan. Maar of dat gaat lukken, betwijfel ik. Er zijn niet veel
voorbeelden van bedrijven die zichzelf met succes zo fundamenteel
heruitvinden.

DSLs

2009-04-13T18:33:00.001+02:00

Aardig stuk van Vaughn Vernon over DSLs. Legt o.a. verschil tussen interne en externe DSLs uit.

Twitter revolutie in Moldavië

2009-04-12T13:35:00.001+02:00

Hoe de revolutie of wat het ook is in Moldavië ondersteund wordt door Twitter. (via Nick Carr).

einde gratis Web in zicht?

2009-04-12T04:50:00.003+02:00

Dit stuk is wel een beetje paniekerig, maar logisch is de ontwikkeling wel: tot nog toe kon het Web parasiteren op de content van media als kranten en TV-stations, die op hun beurt die informatie van persbureaus als AP haalden, en daarvoor betaalden.

Maar die kranten vallen om, en de TV-stations krijgen het ook moeilijker door het teruglopen van de advertentie-inkomsten. En dus lopen de inkomsten voor AP c.s. terug, en dus gaan ze proberen geld te verdienen aan publicatie op het Web.

Groot gelijk, wat mij betreft, al weet ik niet of het zal lukken.

Internet in een zeecontainer

2009-03-28T10:05:00.003+01:00

Laat ze gaan, gaan, gaan,
geef die jongens toch ruim baan
al gaan
ze soms ook niet zo snel
douw een op je rem
denk af en toe aan hem
de containers, ze moeten erdoor!

(Henk Wijngaard, uit mijn hoofd)

Mooie plaatjes: de SUN containers.

Zon schijnt door de wolken

2009-03-28T08:33:00.003+01:00

Sun's cloud. Ze bieden voor storage (o.a.) de S3 API aan.

O ja, en dan dit gedoe over dat Cloud Computing Manifesto. Moet ik nog een post aan wijden.

Betalen op het Internet

2009-03-24T12:41:00.002+01:00

De laatste tijd is er erg veel discussie over hoe informatie op het Web betaald moet worden. Door de crisis komt er sneller een einde aan de VC-pot dan (waarschijnlijk) gedacht, en de advertentie-inkomsten lijken ook terug te lopen. Deels door de crisis, maar ook door autonome oorzaken. (Ik heb daarover eerder geschreven, oa hier.)

En in dit stuk betoogt Eric Clemons vanuit een andere invalshoek dat advertenties op het Internet niet een blijvende bron van inkomsten voor content kunnen zijn. Kern van zijn redenering: advertenties vervelen en irriteren, en consumenten hebben andere, betere manieren om te vinden wat ze nodig hebben. Dus werken advertenties niet (meer).

Clemons ziet wel wat in micropayment (hoewel hij wel erg makkelijk over de bezwaren heenstapt), en vooral in paid access.

Interne "clouds"

2009-03-21T11:07:00.002+01:00

Rik zegt:
"Wat is er 'cloud' aan een enterprise cloud? Behalve mogelijk een stuk virtualisatie dat we al jaren kennen.

De crux van cloud is (mede) multitenancy. En dat zie ik een enterprise cloud niet gebeuren."

Ik ben het wel met Rik eens, al kun je een betoog ophangen dat je binnen zeer grote systemen ook een soort van multitenancy zou kunnen hebben. Bedoeld wordt dat je dezelfde technieken, misschien zelfs dezelfde protocollen, gaat gebruiken. En dat zal inderdaad leiden tot gebruik van een externe cloud, dat ligt in de lijn der verwachtingen.

Enterprise clouds

2009-03-20T13:32:00.003+01:00

Over interne clouds voor ondernemingen.

Er wordt ook gezegd dat het waarschijnlijk een tussenfase is in het proces naar het uitbesteden van de IT aan de "echte" cloud.

Ik vraag me af of het vanuit kostenoogpunt te rechtvaardigen stap is; misschien voor grote ondernemingen wel.

Java applets en JavaScript

2009-03-12T12:43:00.002+01:00

Ik heb me wel eens afgevraagd: waarom zijn de Java applets (de oorspronkelijke claim to fame van Java) niet de standaard geworden voor code-on-demand?

Dit is het antwoord van Roy Fielding op die vraag.

Niet gratis

2009-03-10T08:42:00.002+01:00

Dit is mij uit het hart gegrepen. David van 37signals die vindt dat het eigenlijk heel gewoon zou moeten zijn als een gebruiker betaalt voor dingen die hij doet via het Web.

Server oligopolie

2009-03-09T12:21:00.003+01:00

Opmerkelijk: volgens dit verhaal in de FT wordt zo'n 20% van de server computers gekocht door een handjevol cloudleveranciers (Rashid van MS noemt met name Amazon, Google, Microsoft en Yahoo). Die enorme infrastructuur is zich aan het vormen zonder dat we het echt zien.

(via Nick Carr).

Opera schaft de stack af

2009-03-01T09:55:00.002+01:00

Volgens dit verhaal gaat Opera om de browser te versnellen met registers ipv de stack werken. Keren oude tijden terug?

RDBMS vs. key/value

2009-02-20T16:57:00.001+01:00

Tony Bain over RDBMS vs key/value-bases. Goed stuk.

Wainewright over platforms

2009-02-15T10:18:00.001+01:00

Interessant verhaal van Phil Wainewright.

Vooral: "I suspect the root of the problem in Sage’s case was an unthinking assumption that Aqualogic was such an established Web platform that basic security would just be built in as standard. This is typical of the blind-leading-the-blind nature of the on-premise software model, in which customers blithely believe that vendors have built everything they’ll need into the platform, while vendors naively assume that anything they’ve missed will be easily spotted and corrected by customers during the implementation process. It’s bad enough when it results in catastrophic roll-outs at just a single company, but when the application is being deployed as a service to multiple downstream customers, a far higher duty-of-care is required, because the risk exposure is massively amplified."

SOA is dood, deel 4

2009-01-19T17:14:00.002+01:00

De Stem der Rede zei:

"Ironick zegt: "It is services thinking, as conventionally understood, that led to the mess in which we find ourselves: fragmentation caused by entity-specific (service) interfaces".

Een mooie volzin, maar ik denk dat maar weinigen snappen wat hier wordt bedoeld. Dat het in de de IT moet gaan over "services", dat snappen we. Dat deze services WOA compliant in plaats van SOA compliant moeten zijn, dat kunnen software architecten - behalve elkaar - maar moeilijk uitleggen."

En vervolgens wordt mij om een uitleg gevraagd.

Het probleem zit m hier in het begrip "services". Moet het in de IT om de "services" gaan? Sja, dat hangt af wat er mee bedoeld wordt. In SOA in ieder geval wel: daar zijn de services doorgaans het uitgangspunt voor het ontwerp.

Je wordt verondersteld na te denken over welke services er zouden moeten zijn, en als je die eenmaal hebt bedacht, ze volgens de regelen der kunst(autonomie, stateless, etc, etc) te ontwerpen. Maar hoe bedenk je eigenlijk die services? Dat blijft schimmig. De beste manier is om dat te doen vanuit een objectmodel, waarbij de interfaces tussen de objecten worden getransformeerd naar services. Dit kan, en het werkt, alleen doet bijna niemand het.

In plaats daarvan zit men services uit de duim te zuigen, of ze te ontwerpen op basis van wat op dat moment nodig lijkt vanuit een of ander proces, of (nog erger) op basis van wat een bestaande legacy-component biedt. Het gevolg zijn services die ontworpen zijn vanuit de huidige behoefte of zelfs de behoefte (en de architectuur) van het verleden. De kans dat dit in de toekomst andersoortig gebruik vergemakkelijkt (de belofte van SOA tenslotte) is nihil.

Als dit klinkt als een slecht verhaal: dat kan kloppen, want het is een slecht verhaal.

Bij de WOA (of de ROA, dat is wat mij betreft hetzelfde) ontwerp je vanuit resources, zeg maar de gegevensstructuur. Ook als er geen expliciet object- of datamodel wordt gemaakt, moet je als je RESTful werkt een resource-structuur hebben. En het aardige is dat je daarbij weliswaar heel veel fout kunt doen, maar dat er vrijwel altijd toch een bruikbare structuur ontstaat, waarop de resource-oriented services makkelijk te ontwerpen zijn.

En die resource-oriented services zijn veel makkelijker te gebruiken op een manier die niet is voorzien, juist omdat ze zo simpel zijn: een resource kan op een aantal manieren informatie ter beschikking stellen, je kunt nieuwe informatie erin stoppen, je kunt een nieuwe resource van een bepaald type maken en vullen, en je kunt een resource verwijderen. Dat is het wel zo'n beetje.

Makkelijk te begrijpen, en makkelijk te hergebruiken, aangenomen dat de resource-definitie en -structuur ergens op slaat.

Korte samenvatting: de SOA route vereist teveel kennis en strategie van de IT-experts. Als je een goed model maakt en dat model op de geode manier vertaald in services, gaat het goed. Maar dat doet men dus niet.

De WOA-route is veel meer fool-proof. Daar moet men echt heel erg zijn best doen om er helemaal onbruikbare services uit te laten rollen.

Er zijn nog een paar andere voordelen van WOA/ROA, maar het door Ironick genoemde argument komt op het bovenstaande neer.

SOA is dood, deel 3

2009-01-16T15:14:00.002+01:00

De Stem der Rede zegt:
"Het denken in eilanden/domeinen in plaats van enterprise wide is overigens een idee dat ook door de WS-* adepten worden aangehangen. Er lopen dus twee discussies door elkaar: 1) het moet domein gewijs in plaats van enterprise wide; 2) het moet RESTful in plaats van WS-*."

Ja, dat is zo. Maar die twee discussies hangen wel nauw met elkaar samen, in ieder geval volgens de restafari's.

Stel: je wilt "eilandgewijs" ontwikkelen, en je doet dat volgens WS-*. Hoe moeten die interfaces van die eilanden er dan uitzien? Hier zijn 2 mogelijke antwoorden op:
1. je gaat uit van het nu voorziene gebruik van het eiland, en op basis daarvan maak je een interface. Zoals bekend zal je dan niet een interface krijgen wat voor andere doeleinden bruikbaar is dan het oorspronkelijk voorziene doel. Dit zal de bruikbaarheid dus nadelig beïnvloeden.
2. je maakt een of ander model, waarmee je de betekenis voor het te ontwikkelen eiland voor de omgeving beschrijft. Met andere woorden: je brengt de omgeving van het eiland, en daarmee ook de plaatsen voor de zinvolle bruggen, in kaart. Dit is een veel beter idee, maar het nadeel is wel dat je niet alleen het eiland, maar ook de omgeving aan het ontwerpen bent. Dit tendeert dus al snel naar een enterprise-wide ontwerp, zeker als het in het detail moet wat nodig is voor het ontwerpen van WS-* interfaces.

Maakt de introductie van REST dit veel beter? Ja, om een paar redenen.

a. REST dwingt je (min of meer) om een resource-structuur te ontwerpen. Zelfs als je geen idee hebt van de omgeving, krijg je zo toch een ieder geval voor de basale handelingen herbruikbaar interface, ook als dat hergebruik niet plaatsvindt op de voorziene manier.

Anders gezegd: WS-* tendeert naar een functioneel interface, en moet dus ontworpen worden vanuit het nu bekende of voorziene gebruik. REST tendeert naar een interface ontworpen vanuit de resource-structuur (dat komt in de praktijk neer op de logische datastructuur), en dat is veel meer onafhankelijk van het nu bekende of voorziene gebruik.

Natuurlijk is het mogelijk die resource-gerichte aanpak ook in WS-* te gebruiken, maar dan komt het tweede voordeel van REST:

b. REST-interfaces maken gebruik van URI's en de bekende HTTP-methods. Dat is makkelijker te gebruiken dan WS-* interfaces.

Ook dit voordeel is natuurlijk te bereiken in WS-*, alleen: dan heb je REST nagebouwd in WS-*. Waarom zou je dat doen? Dan kun je beter gelijk REST gebruiken, want de voordelen van WS-* boven REST gebruik je toch niet meer.

Dus: WS-* is eigenlijk alleen goed te doen als je een enterprise wide aanpak gebruikt. Als je dat niet doet, zal de herbruikbaarheid zwaar lijden. Bij REST is dat niet nodig. RESTful eilandautomatisering leidt nog steeds tot behoorlijk herbruikbare ontwerpen.

Cobol op de cloud

2009-01-16T13:44:00.001+01:00

MicroFocus zorgt ervoor dat je op Amazon EC2 Cobol kunt draaien.

SOA is dood, deel 2

2009-01-10T10:12:00.003+01:00

Stefan Tilkov geeft zijn mening.

Samenvatting: SOA bevatte veel goede ideeën, maar het idee dat het allemaal in enterprisewide moest is verkeerd. Hij wil SOA als eilandautomatisering, maar dan wel met bruggen: stukje bij beetje, met standaardinterfaces. RESTful dus.

En ik ben het met hem eens, maar dat zal geen verrassing zijn.

SOA is dood

2009-01-08T15:16:00.003+01:00

per 1 januari j.l., volgens Anne Thomas Manes. Ik ben het er wel zo'n beetje mee eens, maar die slotconclusie: het gaat om "services" is mij veel te vaag. Daar schieten we niks mee op.

En ik vind haar ook te mild over de claims dat SOA vooral door de organisatie moet worden gedragen, etc. Dat is niet de oplossing, dat is juist het probleem. Organisaties moeten geen IT-architecturen dragen. Als dat nodig is, deugen die architecturen niet.

Aanvulling (via InfoQ): Ironick verwoordt vrij precies hoe het echt zit. SOA wordt ingehaald door het Web, of de WOA, zo u wilt.

Links als objecten

2008-12-29T12:57:00.003+01:00

En dan dit pleidooi (via Tim O'Reilly) voor links als first class object. Van Ian Bicking.

Doet denken aan de "smart pointers" indertijd om de persistency laag in OO min of meer transparant te maken.

REST en linking

2008-12-19T17:29:00.001+01:00

Subbu Allamaraju op InfoQ over REST en het belang van links daarin. Zeer lezenswaard, zeker ook de achterliggende blog entries (hier en hier).

Een kritische noot

2008-12-12T20:03:00.002+01:00

Een zekere Jeffrey Lindsay van een onderzoeksbedrijf Bernstein heeft een rapport geschreven waarin hij een paar kritische noten over SaaS en cloud computing maakt. Ik heb het rapport zelf niet gelezen, wel de samenvatting van Larry Dignan op ZDnet.

Kritiek is natuurlijk altijd welkom, maar dit is toch wel een beetje een raar verhaal. Als ik het goed begrijp, komt zijn kritiek op het volgende neer:
1. bedrijven doen het (cloud computing) nog niet of nauwelijks, want eigen machinerie is sneller, ze hebben geen zin om applicaties en documenten om te zetten, enz.
2. de leveranciers verdienen er ook weinig geld aan, zie Amazon dat (nog) niet erg veel geld genereert uit AWS. (Lindsay vermoedt dat Amazon het ook niet doet voor de revenuen, maar voor het imago, waardoor ze betere developers kunnen aantrekken, etc).

En de conclusie is dat het allemaal wel meevalt, en dat cloud computing wel gebruikt zal worden, maar beperkt en in een hybride model. Hij zeg bv dat Google Apps niet meer dan 10% van de MS office licenties af zal snoepen. (Dat is natuurlijk flauw, want naast Google Apps zijn er meer leveranciers van cloud-offices: ZoHo bijvoorbeeld, en ook MS zelf.)

Ik vind het een vreemd verhaal, want het lijkt alsof Lindsay de clou niet heeft begrepen. Inderdaad, cloud leveranciers verdienen niet ontzettend veel geld. En dat is niet alleen een aanloopverschijnsel, dat blijft zo. Gezien vanuit IT-leveranciers is dat natuurlijk raar, want waarom zou je er dan aan beginnen? Maar gezien vanuit de klanten betekent het dat de prijzen laag zijn en blijven, en dat cloud computing dus veel goedkoper is dan "eigen IT". En ja, het zal hier en daar wat minder makkelijk zzijn, en je moet documenten converteren, maar als je het niet doet, verlies je van de concurrent die wel overstapt op de cloud. Want het kostenvoordeel is gigantisch.

Dus op korte termijn zal hij wel gelijk hebben: bijna niemand stapt in één keer over, en vrijwel iedereen blijft voorlopig gedeeltelijk "eigen IT" gebruiken. Maar op wat langere termijn is de impact (waarschijnlijk, want ik heb d wijsheid ook niet in pacht) zeer groot. Niet alleen voor het goedkoper maken van bestaande produkten en diensten, maar vooral ook doordat hierdoor nieuwe produkten en diensten mogelijk worden, en ongetwijfeld, zoals dat gaat oude verdringen.

En wat betreft Amazon: ik ben ervan overtuigd dat AWS niet zomaar een aardigheidje is. Drie redenen:
1. Amazon kan hierdoor de voor het "oude bedrijf" benodigde capaciteit extra benutten en dus goedkoper maken.
2. Amazon leverde in feite voor derde partijen (tweede hands verkopers e.d.) eigenlijk al een click-in business model: niet alleen de catalogus, ook de betaalservice, soms delivery, enzovoort. AWS is een logische uitbreiding daarop.
3. Amazon zit voor wat betreft het "oude bedrijf" in de levering van content: boeken, muziek, enzovoort. Amazon ziet dat dat digitaliseert en via het net zal gaan. Vandaar de verkoop van MP3s, vandaar de Kindle. Maar daarvoor is een Web-infrastructuur nodig, en die is Amazon dan ook aan het opbouwen. Als je die ook door derden laat gebruiken, heb je AWS.

Allemaal logisch dus.

Leonard Richardson over RESTful

2008-12-08T13:42:00.002+01:00

Leuk stukje van Leonard Richradson (via Stefan Tilkov) over REST en de soorten of stadia van RESTful. Maakt op simpele wijze eea duidelijk.

Ik ben ook geneigd te denken dat het belangrijkste van REST die URIs zijn.

Java en persistence frameworks

2008-12-04T17:28:00.003+01:00

Ibrahim Levent schrijft over de problemen met Java persistence frameworks. Wel aardig, al ben ik het niet altijd met hem eens. Hij lijkt de geschiedenis van deze tools niet goed te kennen (hij denkt dat het allemaal is begonnen met EOF), en er zijn nog wat dingen waarmee ik het niet eens ben (bv punt 14, over die OIDs).

Commentaar is ook aardig, ookop de Serverside.

Creatieve vernietiging

2008-11-28T16:17:00.000+01:00

Voorpublicatie:

De Oostenrijks-Amerikaanse econoom Joseph Schumpeter heeft het begrip "creative destruction" geïntroduceerd. Dat hield in dat in een goed functionerende markteconomie steeds aan kapitaalvernietiging wordt gedaan, doordat bestaande bedrijven ter ziele gaan. Maar ze worden vervangen door nieuwe bedrijven die beter, sneller, efficiënter, goedkoper kunnen werken. Voor de bedrijven die verdwijnen is dat natuurlijk rampzalig, maar voor de samenleving als geheel is het juist goed: er treedt innovatie op, de productiviteit stijgt, en de welvaart neemt toe.

De neiging om bestaande bedrijven overeind te houden is dan ook weliswaar begrijpelijk, en voor de direct betrokkenen (eigenaars, werknemers, leveranciers) voordelig, maar op de wat langere duur desastreus. Immers, middelen die gestoken hadden kunnen worden in nieuwe welvaartsverhogende technieken en bedrijven, vloeien nu naar oude bedrijven die op den duur toch het loodje zullen leggen, en hoe dan ook minder produktief zijn dan de nieuwe bedrijven zouden zijn geweest.

Ik moet wel eens aan die "creative destruction" denken als ik deelneem aan de discussies over Service Oriented Architectures (SOA) en legacy integratie. Vaak wordt gezegd dat het mogelijk is om de investeringen in bestaande IT-systemen (de zogenaamde "legacy") te behouden, en toch die systemen op een flexibele wijze en via het web te kunnen gebruiken. Om dat te kunnen bereiken moet men dan een SOA inrichten, en daarbij een Enterprise Service Bus inrichten.

In de praktijk komt hier meestal weinig van terecht. Die SOA en ESB blijken erg ingewikkeld, en bovendien duur. En de voordelen van die "ontsluiting" van de legacy vallen vaak ook tegen, omdat die legacy zich helemaal niet goed als service laat ontsluiten, tenzij nog grotere investeringen worden gedaan.

En nu komen SaaS en cloud computing (ik zal het hierna op één hoop gooien onder de term "SaaS") om de hoek kijken. SaaS zet het business-model zoals dat tot nog toe in de IT opgeld deed op zijn kop. Je betaalt niet meer van te voren (voor een licentie of voor de bouw van maatwerk), maar voor het gebruik: per transactie, per gebruiker per maand, per opgeslagen MB. Standaardfunctionaliteit, afgerekend op gebruik. “Functionaliteit uit de muur”, zogezegd.

De voordelen zijn gigantisch: minder risico (want geen voorinvesteringen), meer mogelijkheden om van systeem of leverancier te veranderen, en vooral: lagere kosten.

Om deze voordelen te boeken moet je wel wat gangbare ideeën over IT overboord zetten. De kracht van SaaS zit in de standaardisatie. Je gaat dezelfde functionaliteit gebruiken als de buurman of concurrent die hetzelfde SaaS-systeem gebruikt. Voor gebruikers die nog leven met de illusie dat hun IT-systeem uniek is en een “strategisch voordeel” oplevert, is dat een forse stap. Aanpassen en customizen van SaaS kan meestal wel, maar is onverstandig. Het is toch weer een voorinvestering.

Ik hoor wel eens de tegenwerping: “Dan ben ik de greep op mijn IT kwijt!” Ja, dat is zo. Als je een blok aan je been kwijt bent, ben je de greep op dat blok kwijt.

Het is wel verstandig om te zorgen dat je niet met huid en haar aan de SaaS-leverancier bent overgeleverd. Dat kan door het maken van een model (een goed object- of datamodel is meestal voldoende) van de informatie die “uitbesteed” wordt. Dat model wordt geprojecteerd op het model van de leverancier, en door zo te werken is het mogelijk om betrekkelijk makkelijk gegevens te converteren, te up- en te downloaden, en dus ook van leverancier te wisselen.

En wat je vooral ook niet moet gaan proberen is de “integratie” van legacy “integreren” met SaaS. Natuurlijk, dat kan wel eens nodig zijn, maar je steeds moet heel goed kijken naar de alternatieven: gewoon niet integreren en los naast elkaar laten staan, of het legacy-systeem zelf ook vervangen door een SaaS-toepassing.

Want SaaS zal, denk ik, leiden tot de “creative destruction” van veel van de bestaande IT-systemen. Ze zullen worden vervangen door het gebruik van SaaS, wat veel goedkoper is, geen risico vormt, nauwelijks investeringen vergt, en de bedrijven niet meer vastklinkt aan enorme IT-systemen en de bijbehorende staf. Dat zal niet in één klap gaan. Sommige systemen zijn nog niet te vervangen, en sommige systemen misschien wel nooit.

Maar je moet wel bereid zijn om die “creative destruction” te laten gebeuren, en niet water in de wijn te doen door bestaande systemen nodeloos en tegen hoge kosten te integreren, en daarmee hun leven te verlengen. Want de concurrent die de radicale keuze maakt, heeft een groot kostenvoordeel, en dat zal op de markt te merken zijn.

SOA humor van Gartner

2008-11-21T16:10:00.001+01:00

Lachen met Gartner. In ieder geval Frank Kenney heeft blijkbaar ook zijn vraagtekens bij de gangbare SOA.

Gartner, REST en WOA

2008-11-21T13:53:00.002+01:00

Stefan Tilkov meldt dat Gartner de WOA (dat is ongeveer het zelfde als wat ik de ROA noem, geloof ik) omarmt. Hoera!

Is dus bij deze mainstream....

Flex ipv Java?

2008-11-14T12:45:00.002+01:00

Er is discussie over de vraag of Flex een goed alternatief is voor Java, voor programmering op de client (in RIA-omgevingen). Het zat er natuurlijk aan te komen....

Asynchrone REST

2008-11-12T16:28:00.001+01:00

Op zoek naar asynchrone REST kwam ik dit tegen. Aardig stuk.

Consumentenmarkt en "zakelijke markt"

2008-11-11T21:23:00.002+01:00

Phil Wainewright:

a. zakelijke markt en consumentenmarkt zijn niet (meer) van elkaar te scheiden

b. de consumentenmarkt is tegenwoordig meestal leidend als eht gaat om nieuwe applicaties, en wel hierom:

"So-called consumer applications are advancing faster because individuals have so much more compute resource available for their personal use, he pointed out, with high-spec multimedia PCs at home, iPhones in their pockets and so on. It struck me that this is an illuminating contrast to the previous generation of computing innovation, when it was enterprise professionals who had the budget freedom to purchase PCs and software packages like Lotus 1-2-3 and Microsoft Office, and who therefore led all the experimentation in the client-server software era.

Enterprise professionals in most corporations today are constrained by corporate purchasing policies and IT standardization (less so at Google, by the way, where employees can choose pretty much any personal compute device). But as individuals, those same people are not constrained by corporate risk assessment and compliance rules, while a decade or more of falling prices have brought today’s game-changing technologies into a consumer price bracket. "

Interessante observatie, al vraag ik me wel af of ie helemaal juist is. De Blackberry bijvoorbeeld is volgens mij een vrijwel alleen zakelijk verkocht apparaat, in ieder geval in Nederland.

Maar in het algemeen klopt het wel, denk ik.

2008-11-03T20:12:00.001+01:00

Dit is een test vanuit Ping.fm. Eens kijken waar dit terecht komt.

REST 2

2008-10-31T09:09:00.003+01:00

(Dit is ook een test om te kijken of de twitterfeed werkt).

Wat betreft die duistere passage in die post van mark Littke waarover ik gisteren schreef: ik denk dat hij bedoelt dat de te navigeren paden in de resource structuur duidelijk moeten zijn in de representatie die de client terugkrijgt. Een domeinspecifiek object- of datamodel is prima, maar mag niet impliciet zijn, dat wil zeggen: het moet niet nodig zijn dat de client developer a priori weet hoe het "model" in mekaar zit.

REST

2008-10-30T22:15:00.002+01:00

Stuk van Mark Little op InfoQ, waarin de hele tijd Roy Fileding wordt aangehaald.

Hmmmm....

Wat bv te denken van:

A REST API must not define fixed resource names or hierarchies. Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling]."

Vooral dat stuk tussen die haken, over die resource structuur: ik weet niet zeker of ik he daar wel mee eens ben. Ik ben wel voor die resource structures.

Microsoft Azure

2008-10-28T08:51:00.003+01:00

Microsoft heeft Azure aangekondigd. Azure is de cloud van Microsoft. Ziet er interessant uit, vooral ook omdat MS nogal inzet op Model-Driven approaches, met name het Oslo-verhaal.

Dat is potentieel een zeer interessante combinatie: Oslo + Azure. Daar zit in ieder geval ik wel op te wachten,

AWS gaat nu echt los, geloof ik

2008-10-23T18:34:00.002+02:00

AWS (Amazon Web Services) gaan nu echt los. Er is nu een SLA (99.95% of zo uptime), EC2 is uit beta, er is een Windows image, er komen allerlei consoles, load balancing is verbeterd, en Vogels deelt mede dat Amazon nu ook grote bedrijven als doelgroep heeft.

Tot nog toe zat er wat hobbyistisch aan, maar dat gaat er af.

Ik zit zelf ook met interesse te kijken naar de ElasticFox plug in voor FireFox, die het mogelijk maakt de EC2 image te sturen vanuit de browser.

Silver Bullit revisited

2008-10-21T20:22:00.003+02:00

Ik vond deze samenvatting van een panel op OOPSLA. Panels zijn meestal geouwehoer, maar dit is wel aardig, en stipt nogal wat vragen aan waarmee ik mij ook bezighoudt. Bijvoorbeeld Dave Thomas:

"1. People have a “very natural tendency to look for easy answers to hard questions, designing software is hard and it will always be hard.”
2. New technologies are often over-hyped: “they have to kind of paint it as a silver bullet because otherwise people won’t listen.”
3. Desire for people to seek better tools rather than “actually learning the trade.” Dave used the metaphor: “there is an old saying: ‘the poor
workman blames his tools’ - people are poor wfor silver bullets to avoid learning the trade. "

REST modellering

2008-10-16T10:08:00.004+02:00

Hoe kun je een RESTful architectuur modelleren? Met andere woorden: hoe modelleer je resources?

Het belangrijkste punt is dat men zich realiseert dat een resource iets wezenlijk anders is dan een component in de gebruikelijke zin van het woord, en in zeker opzicht ook dan een object. Want componenten worden ontworpen vanuit het beginsel van "information-hiding", en bij objecten zijn we oo kgewend dat te doen. Componenten en objecten stellen aan de buitenkant alleen een interface ter beschikking. De interne gegevens zijn verborgen, evenals de methods. En zowel componenten als objecten schermen het woud van componenten resp. objecten "achter zich" af. In feite zijn ze allemaal Facades (het GoF-pattern). De Law of Demeter schreef voor dat een object niet zomaar referenties naar "achterliggende" objecten mag verschaffen.

Met resources ligt dat iets anders. Ja, je kunt resources zo ontwerpen dat het in feite ook facades zijn, en zo dat ze hun interne informatie volledig verbergen. (Al zal dat leiden tot nogal overladen POST-methods.) Maar resources zijn (ook) "knopen" op het web, en zijn juist bedoeld om navigatie naar achterliggende "knopen" (resources dus) mogelijk te maken.

Bij een (goed ontworpen) object-model is dat trouwens ook zo. Dat is wel degelijk bedoeld om transparant te zijn. En dat is dus een goed begin voor een resource-model.

Dit leidt tot de volgende werkwijze:

1. maak een object-model voor het domein, bij voorkeur met standaard-analysepatronen, bijvoorbeeld door de colors-aanpak te gebruiken.

2. onderzoek welke objecten die in het model worden beschreven resources gaan worden. (In de praktijk zullen ze dat allemaal worden.)

3. maak een pad-onafhankelijke identificatie van die objecten. Bijvoorbeeld: .../{Class}/{object-id}, dus: http://JansenBV.nl/Order/id=12345

4. Onderzoek welke "paden" in het object-model navigeerbaar moeten zijn, en welk deel van het model "publiek" is. Hierop wordt de GET-URI-structuur ontworpen.
(In de praktijk zullen associaties en aggregaties in het model vrijwel altijd "publiek" zijn. Met composities ligt het iets ingewikkelder. Die kunnen "verborgen" zijn. Het is een optie om voor het resource-model een speciale modelvorm (UML Profile?) te maken waarbij de betekenis van de object-relaties (associatie, aggregatie, compositie) op die manier is gedefinieerd.)

5. Onderzoek welke messages (maw: methods aangeroepen door een bepaald object) creatie of deletie (zal wel geen nederlands zijn; bij deze) van een object of wijziging van een attribuut tot gevolg heeft. Hierop moet de PUT/DELETE-structuur worden gedefinieerd.

6. Onderzoek wat er overblijft aan "gedrag" in het model wat niet wordt gedekt doro de GETs, PUTs en DELETEs. Daarvoor worden POSTs ontworpen.

Dit is een begin.

Elbot en de Turing-test

2008-10-15T10:35:00.001+02:00

http://www.elbot.com/

Dat is Elbot, een robot die er dit jaar heel dicht bij kwam om de Turing test te breken.

Je kunt met Elbot praten, en het lijkt heel erg op een conversatie met mijn broer Kees.

Microsoft in Amazon's cloud

2008-10-01T20:17:00.003+02:00

AWS gaat EC2 met Windows serveren. Linux was al mogelijk, maar nu kunnen dus ook Windows applicaties op AWS draaien. Overigens komt Oracle ook op AWS.

Microsoft schijnt zelf ook met een "cloud windows" te komen, wat dat ook mag betekenen.

SOA: hoe in te voeren? (2)

2008-09-29T13:39:00.003+02:00

Rik schrijft:
"ESB gedreven SOA". Bestaat er dan ook zoiets als "niet ESB gedreven SOA"? Volgens mij niet. Zelfs in een volledig geharmoniseerde en gestandardiseerde wereld zul je altijd berichten moeten routeren, gegarandeerd moeten transporteren en moeten orkesteren. Of zie jij een alternatief?

Ja, ik zie wel een alternatief.

Natuurlijk, dat routeren, transporteren, enzovoort is nodig. Maar is het nodig dat allemaal te integreren in één tool, namelijk de ESB? Die is duur om aan te schaffen, duur om te implementeren, en bovendien proprietary, wat in feite betekent dat het bedrijf in kwestie zich min of meer uitlevert aan de vendor.

Bovendien zijn heel veel van die "luxe" functionaliteiten van een ESB helemaal niet zo hard nodig, en worden ze zelden gebruikt.

Door dit alles worden die ESB-implementaties noodzakelijkerwijs company-brede projecten, en zoals we allemaal weten: die mislukken, zeker als ze niet 100% nodig zijn. En dat zijn die ESB-projecten niet, omdat er altijd een plan B is: een beetje halfwas invoeren, en de rest naar de toekomst schuiven. En plan C is: installeren, roepen dat je het gebruikt, maar in werkelijkheid gewoon de ouwe trouwe messagebroker blijven gebruiken.

Ik zie zeker twee alternatieven.
1. gebruik een mean&lean "ESB" voor de routering etc van het berichtenverkeer, en gebruik daarvan de functionaliteit op een dusdanige wijze dat je kunt switchen naar een ander tool. Een manier om dat te doen, is het gebruik van meer dan één ESB, maar dat stuit uiteraard nog wel eens op investeringsgrenzen.
2. gebruik een REST-route, en ga naar een ROA-architectuur. Dat kan ook, daar is nauwelijks extra tooling voor nodig, en kan incrementeel worden gedaan. Maar het sluit (in ieder geval op het eerste gezicht) veel minder goed aan bij de bestaande architectuur, en bovendien weten systeemarchitecten e.d. nit hoe ze dit moeten aanpakken.

Een extra argument voor deze alternatieve routes is dat de ver-SaaS-ing of ver-cloud-ing van de functionaliteit eraan komt, en dan zit een zware proprietary ESB ontzettend in de weg, zowel technisch als budgettair.

Niet doen dus, het zijn dinosaurussen.

SOA: hoe in te voeren?

2008-09-26T17:23:00.005+02:00

Jonathan Mack op InfoQ, over hoe moeilijk het is om SOA in te voeren.

"When it comes to the SOA roadmap, the two most popular approaches to SOA implementation have emerged lately:

Enterprise (top-down) SOA approach, which is an extremely high - risk approach with an initial price tag of a several million dollars. In addition, based on the size and complexity, such project can virtually never be accurately estimated.
Grassroots (bottom-up) SOA approach - implementing elements of SOA (both services and infrastructure) as parts of existing business-driven IT undertaking. This approach typically does not succeed. On one hand, the scope of resulting services is limited to the specific business problem and might not be applicable (or even wrong) for the rest of enterprise. On another hand, the time and expense required to build the SOA layer can detract from other business needs of a project."

OK, dat lukt dus niet. Mack gaat dan verder met constateren dat een incrementele aanpak beter is:
"...to build SOA incrementally. Most vendors have come around to recognizing that this is the most reasonable approach. Nevertheless, it’s not simple to accomplish. The key elements of an Enterprise Server Bus (ESB) - the ability to translate and transform information from one system to another and the ability to route messages - as well as the messaging infrastructure to transmit the information must be in place from the beginning. Common (shared) services such as logging, monitoring, and exception handling also should be Day 1 implementations."

Ja, zo ken ik er ook nog wel een paar. Dit is dus ook een moeizaam verhaal.

Conclusie: SOA, althans ESB gedreven SOA, werkt niet.

Misschien wat kort door de bocht, maar eigenlijk komt het daar wel op neer. Zie ook dit en dit.

O'Reilly gelooft ook niet in het advertentie-model

2008-09-19T17:52:00.002+02:00

Ik loop nu al enige tijd te schoppen tegen het advertentiemodel als dè inkomstenbron voor het Web te schoppen. En O'Reilly vindt dat ook.

Content delivery door Amazon AWS

2008-09-18T22:20:00.002+02:00

Kijk, dit zat er in: content delevery via één API door AWS. Koppeling met het betaalsysteem FPS ligt natuurlijk vreselijk voor de hand.

Zie AWS blog en Werner Vogels.

Google op zee

2008-09-15T17:55:00.001+02:00

Google wil datacenters op zee. Om de golfenergie te gebruiken. En om minder belastingen te betalen. En misschien ook wel om minder last van wetten en regels en juridisch gezeur te hebben.

Onzin over cloud computing

2008-09-15T14:45:00.002+02:00

De laatste tijd lees ik nogal eens van die verhalen waarin wordt gezegd da cloud computing er niet is of komt, omdat er nog steeds on-premise computing is en blijft. Staat op mijn lijstje om eens op te reageren, maar Anshu Sharma heeft het al gedaan. Hij heeft groot gelijk.

SaaS lock-in: een risico?

2008-09-04T15:49:00.003+02:00

Vendor lock-in bij SaaS-oplossingen wordt de laatste tijd nogal eens als risico van SaaS geschetst. Terecht, want lock-in is altijd een probleem, bij een pakket, bij SaaS, en ook bij zelfgebouwde oplossingen.

Maar het lock-in risico bij SaaS wordt overdreven. Wel gelden vier regels:

1. Kies alleen SaaS-oplossingen waarbij je ondubbelzinnig eigenaar van de data bent en blijft.

2. Zorg voor een model (bijvoorbeeld een objectmodel) waarin de business beschreven is, en projecteer dat op het model van de leverancier. Dit is nodig voor conversies, voor koppelingen en voor de exit-strategie.

3. Kies alleen SaaS-oplossingen met goede interfaces. Niet alleen user-interfaces, maar ook APIs voor data-verkeer en integratie.

4. Gebruik die APIs vervolgens zo min mogelijk. De kracht van SaaS zit vooral in de lage kosten en investeringen. Gooi dat voordeel niet weg door niet echt noodzakelijke integratie zelf te bouwen, want daarmee lockt u uzelf in.

Kortom: lock-in is een beheersbaar risico. En de Pavlov-reactie van IT-ers om dan maar zelf iets te gaan bouwen, maakt het erger. Misschien wordt de vendor lock-in iets minder, maar de maatwerk lock-in wordt des te groter.

Cloud browser

2008-09-03T10:17:00.003+02:00

Google heeft Chrome uitgebracht, in beta. Chrome is een webbrowser, op het eerste gezicht een concurrent van Firefox, IE, Safari, Opera, etc. Maar er is een verschil: Chrome is vooral gericht op het ondersteunen van het runnen van webapplicaties.

En ik denk dat het Google niet zozeer gaat om het van de markt drukken van IE of zo, maar om het versnellen van het gebruik van webapps.

voor de restliefhebbers

2008-08-28T17:17:00.002+02:00

Dit verhaal van Bill de hÒra (daar heb ik dus het character palette bij nodig). En ook deze.

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.

UML + DSL

2008-08-28T15:32:00.002+02:00

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)

MDE en de silver bullit

2008-08-21T18:49:00.003+02:00

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?

Waarom MDE zal falen volgens Johan den Haan

2008-08-14T17:38:00.004+02:00

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. :)

model driven engineering: waar gaat het om?

2008-08-08T12:18:00.003+02:00

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.

Applicaties in de cloud

2008-08-07T15:54:00.003+02:00

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....

Computable

2008-08-01T11:22:00.002+02:00

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.....

Boter bij de vis

2008-07-29T13:23:00.001+02:00

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.

For whom the bell tolls...., part 3

2008-07-25T16:02:00.004+02:00

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.

Investeringen in cloud-computing

2008-07-22T04:54:00.003+02:00

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.