Intentional is aan de gang

Dit had ik gemist; Charles Simonyi kondigt aan dat Intentionals produkt gebruikt wordt. Zie ook Capgemini.

Amazon blijft bezig

En nu dan DevPay, een dienst voor programmeurs die webservices willen laten betalen. Ik vermoed dat het in feite bovenop FPS werkt.

(via Jan): deze link. Overigens zit er in dat verhaal van Emerce wel een storende vaagheid: er staat dat de kosten $0.30 per transactie zijn (en 3%). Dat is natuurlijk krankzinnig veel als met "transactie" daadwerkelijk een individueel gebruik van een service wordt bedoeld. Maar dat is niet zo: het gaat om $0.30 per gegenereerde rekening. Dat is een heel groot verschil, uiteraard.

REST of toch SOAP?

Ganesh Prasad vindt REST helemaal niet beter dan de "lean"-SOAP-oplossing (SOAP+WS-Addressing+WS-RM+WS-Security).

Ik denk dat hij op protocol niveau helemaal gelijk heeft, maar dat is niet waar het in de REST/SOA-discussie over gaat. De echte kern van de discussie is: wat hangt hoe aan elkaar?

In de SOA/SOAP-route zijn het doorgaans "services", dat wil zeggen; componenten. In de REST-route zijn het "resources". Dat kunnen ook componenten zijn, en dan maakt het niks uit, sterker: dan is er veel voor SOA/SOAP te zeggen. Maar als die resources niet de omvattende componenten, maar de eigenlijke "objecten" zijn, is REST een fundamenteel andere architectuur.

Die past meer bij REST dan bij SOA/SOAP, al kan dat met SOA/SOAP ook wel, denk ik.

Maar het is waar dat voor REST vaak zwakke of zelfs oneigenlijke argumenten worden aangevoerd.

Data 2.0

Ja, lachen, die Hype 2.0 kreten. Maar toch is dit wel een aardig stuk over Amazon's SimpleDB.

Amazon in Databases

Ik krijg het volgende mailtje van Amazon. Goed nieuws lijkt me.

Dear AWS Developers,

This is a short note to let a subset of our most active developers know about an
upcoming limited beta of our newest web service: Amazon SimpleDB, which is a web
service for running queries on structured data in real time. This service works in
close conjunction with Amazon Simple Storage Service (Amazon S3) and Amazon Elastic
Compute Cloud (Amazon EC2), collectively providing the ability to store, process and
query data sets in the cloud.

Traditionally, this type of functionality has been accomplished with a clustered
relational database that requires a sizable upfront investment, brings more
complexity than is typically needed, and often requires a DBA to maintain and
administer. In contrast, Amazon SimpleDB is easy to use and provides the core
functionality of a database - real-time lookup and simple querying of structured
data - without the operational complexity. 

Were excited about this upcoming service and wanted to let you know about it as soon
as possible. We anticipate beginning the limited beta in the next few weeks. In the
meantime, you can read more about the service, and sign up to be notified when the
limited beta program opens and a spot becomes available for you.  To do so, simply
click the "Sign Up For This Web Service" button on the web site below and we will
record your contact information. 

Learn more:
http://www.amazon.com/gp/redirect.html/ref=aws_smpldb_txtDp?location=http%3A//aws.amazon.com/simpledb&token=884CBD83286A3F3592BD77F9E0AD29091A93E245

Sincerely,
The Amazon Web Services Team

We hope you enjoyed receiving this message. If you don't want to receive future
program updates, please update your communication preferences on the Amazon Web
Services web site:
http://www.amazon.com/gp/redirect.html/ref=aws_sdb_txtUnsub?location=http%3A//aws-portal.amazon.com/gp/aws/developer/account/index.html%3Faction%3Dedit-communication-preferences&token=2066D370FC0E7D9303AA112DF226BF26F7CD77A4

Please do not reply directly to this e-mail.  If you have any questions or comments
regarding this notification, please contact us at webservices@amazon.com.

Amazon Web Services LLC is a subsidiary of Amazon.com, Inc. Amazon.com, Amazon
SimpleDB, Amazon Simple Storage Service, Amazon S3, Amazon Elastic Compute Cloud,
and Amazon EC2 are registered trademarks of Amazon.com, Inc. or its affiliates in
the United States and/or other countries.  This message produced and distributed by
Amazon Web Services, LLC, 1200 12th Ave South, Seattle, WA 98144.

Vijf spelers

Sun's Greg Papadopoulos over de toekomst van de IT. Hij ziet 5 grote "hypercomputers" overblijven op de aardbol, en noemt er vervolgens zeven: Microsoft, eBay, Yahoo!, Salesforce.com, Amazon, Google, en de "Great Computer of China". En in dit stuk noemt Prabhakar Raghavan van Yahoo! (het stuk gaat overigens vooral over Google) er precies vijf: weer Google, Yahoo!, Amazon en Microsoft, en voorts IBM.

Die lijstjes zijn natuurlijk een leuk spelletje, maar een beetje onzinnig. "Great Computer of China"? Waarom niet ook India? Of Japan? En zouden bv Oracle of SAP niet ook wel eens een rol kunnen spelen?

Maar de essentie van vooral Papadopoulos' verhaal staat wel, wat mij betreft.

"It's called software as a service. It really is the running of what we think of as IT through the network. You don't buy software, you buy the consequence of the software. That starts with the small and medium enterprises."

Inderdaad, en het is al begonnen.

Toevoeging (15 dec.): nu ik erover nadenk heeft die Papadopoulos misschien toch meer gelijk met zijn Great Computer of China dan ik in eerste instantie dacht. Want: die anderen zijn allemaal amerikaans, en als SAP een rol speelt, iig westers.

De indiers of de japanners zullen daarvan waarschijnlijk niet wakker liggen, maar de chinese overheid mogelijk wel. Zij hebben ook de omvang en de organisatie om zoiets te realiseren. Dus wie weet....

Amazon FPS met een menselijk gezicht

Het voortreffelijke Amazon FPS (zie ook deze posting) krijgt dankzij SimplifyThis een makkelijker bruikbaar gezicht.

Mooie ontwikkeling, en een voorbeeld hoe in de SaaS-markt de consumenten-markt wel eens de B2B-markt zou kunnen leiden.

REST

Dit is een erg goede introductie voor REST van Stefan Tilkov. Volgens mij slaat hij de spijker op de kop. (Met dank aan Ferrie.)

SOA en EDA

Een erg aardig stuk over de toepassing van een SOA in EDA-vorm (Event Driven Architecture). Het gaat om een netwerk waarbij elektrische apparaten e.d. steeds op de hoogte worden gehouden van de prijs van elektriciteit, en op basis daarvan "besluiten" of ze wel of niet aangaan, op een spaarstand gaan, of iets dergelijks. Stroomgebruik werd daardoor aanzienlijk beperkt.

Concept-orientatie

Aleksandr Savinov heeft iets bedacht dat hij "concept-orientation" heeft genoemd. Het is in feite een abstractie van object-orientatie, waarbij de twee zaken in een object (identiteit en de instance van een class) worden losgekoppeld. (Ik baseer dit op een zeer snelle scan van dit verhaal, en ik heb het nog niet volledig doorschouwd. Maar ik ben er wel enthousiast over, en ik kan het dus niet laten om het even te posten.)

Dit lijkt op "uitbreidingen" van het OO-paradigma die ik zelf ooit heb gemaakt (vooral in relatie tot het abstraheren van multiple inheritance en het toevoegen van crosscutting concerns). En ik vind dit dus erg leuk.

Wat zijn de voordelen, zo op het eerste gezicht?
1. een betere implementatie van inheritance dan nu gangbaar is. We hebben nu de ouderwetse, op de OO-talen gebaseerde interpretatie van inheritance. Die is weliswaar vrij scherp beschreven, maar te beperkt en soms lastig te hanteren in de modellering.
Daarnaast zijn er allerhande uitbreidingen van het begrip inheritance, bv het begrip "specialisatie" in UML. Het nadeel is dat de definitie daar veel te vaag is, en voor werkelijke toepassingen gepreciseerd moet worden.
2. een mogelijke koppeling met AOP, ongeveer langs de lijnen van de "composition filters" uit Twente (Aksit, Bergmans c.s). 

En ik heb bovendien een hunch dat dit prettig mapt op het model van het Semantic Web met de URI's.

Maar ik moet erin duiken (en dat ga ik ook doen) om te kijken of dat allemaal klopt.

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.

Google

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.

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.

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.

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.

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.

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.

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.

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.

Google en de commoditisering

En Google gaat door met de commoditisering van Internet-platforms: nu voor handheld devices. Ik ben benieuwd.

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.

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.

Is dit interessant?

Dit op de wegblog van Marc Andreessen.

Zou wel eens een boeiende ontwikkeling kunnen zijn. Ontwikkelen voor platforms als Salesforce.com, of Amazon, of wat dan ook is natuurlijk mooi, maar je zit niet te wachten op weer een nieuwe platform-lock-in.

Ik zie in ieder geval een model-driven aanpak als remedie, maar een universele API helpt natuurlijk ook.

Affijn, ik ga erin duiken.

ESB: wat moet je ermee? nogmaals

Rik vraagt zich af;
"Niet helemaal duidelijk wordt of 1) ESB's in zijn geheel niet nodig zijn in een applicatie landschap, of 2) ESB's wel nodig zijn maar dat je deze niet zelf in huis hoeft te halen (SaaS) of 3) je ze wel nodig hebt maar dat de standaarden die ze aanhangen op dit moment te complex zijn.

Ik denk dat je ESB's nodig hebt. Om de reden dat - indien applicatie landschappen straks zijn opgebouwd uit een veelheid aan inwisselbare services - je een "makelaar" achtige functie moet hebben om de vraag naar en het aanbod van services bij elkaar te brengen. Of je de ESB dan in-house of bij een provider neer moet zetten, vind ik een andere discussie."

3 vragen dus:

1. zijn ESB's nodig?
Ja. Althans: er is een message broker nodig die berichten rondstuurt, de aankomst van berichten bewaakt, etc. In hoeverre adapters, Business Rule Engines, etc daarvan deel moeten uitmaken, is een andere vraag.
2. moet je ze in huis halen?
Nee, dat hoeft niet, behalve wellicht in het geval van integratie van legacy-applicaties. (Hoewel ook in dat geval goede adapters al een heel stuk helpen.)
Voor de goede orde: op dit moment is het in huis halen van een ESB moeilijk te vermijden, maar in de toekomst zal, zeker bij gebruik van SaaS-oplossingen, de implementatie van een eigen ESB niet nodig zijn.
Bovendien kun je de functionaliteit van een ESB zelf ook als service inhuren (Amazon biedt dit al aan.)
3. zijn de standaarden te complex?
Ja, dat denk ik eigenlijk wel. Ik verwacht dat hierin nog veel verandering zal komen, en dat in veel gevallen een simpeler, meer REST-achtige benadering de overhand zal krijgen.

Hoe dan ook: ik denk dat Rik en ik het wel met elkaar eens zijn.

UIs van Enterprise Software

Khoi Vinh (een web designer) klaagt in de NYTimes over de gebrekkige kwaliteit van de User Interfaces van Enterprise Software. Hij wijt dat aan het feite dat ze niet echt blootstaan aan concurrentie.

De nadelen van SaaS

Op SaaSblogs dit stuk over de nadelen van SaaS. Vanuit de klant en vanuit de leverancier.

Het interessantst is, lijkt mij, het veronderstelde risico dat als de leverancier kopje onder gaat, de klant zijn gegevens kwijt is.

Mij lijkt dat niet nodig. De klant moet een copie van zijn gegevens krijgen wanneer hij dat wil. Dat is op zichzelf niet voldoende, want hij moet ook nog iets aankunnen met die gegevens. Daarom moeten ze voldoen aan een beschrijving die de gegevens begrijpelijk maakt, en liefst ook portable naar een andere omgeving.

Dit is één van de punten waar SaaS een model-gedreven benadering (MDA, MDD, MDE, MDSD, of hoe je het ook noemt) nodig heeft.

Leuk

Dit is een leuk stuk over SOA van Pete Lacey. De conclusie:
No matter which definition works for you, though, SOA is misnamed. So I’ll leave you with some updates to your lexicon:

Network Oriented Computing (NOC): An approach to computing that makes business logic available over the network in a standardized and interoperable manner.
Service Oriented Architecture (SOA): A technical approach to NOC that has a non-uniform service interface as its principle abstraction. Today, SOAP/WS-* is the chief implementation approach.
Resource Oriented Architecture (ROA): A technical approach to NOC that has an addressable, stateful resource as its principle abstraction. Today, REST/HTTP is the chief implementation approach.
Business Service Architecture (BSA): An unnecessary term (also not an architecture) that tries to make the obvious something special. Aka, business analysis. Aka, requirements gathering.


=======

Zo is het maar net.

Coupa en Amazon

Amazon is een heel interessante aanbieder van een SaaS-platform. Als gebruiker van de S3 webservice zi ik af en toe te kijken wat er mee gedaan wordt, en ik kwam Coupa tegen, een SaaS-procurement-applicatie.

Ziet er goed uit, en niet duur. Mooie olifant ook. :)

Carlota Perez over de Web 2.0 bubble

Carlota Perez in de NYT. Interessant verhaal, bevat een toelichting op de huidige overspannen aankopen door Google, Yahoo c.s. van allerhande kleinere bedrijven.

ESB uit de muur

In deze posting voorspelde ik dat het mogelijk en zinvol is om ESB-achtige diensten te "huren" bij een externe provider. Voordeel: dan hoef je niet zelf een ESB te implementeren, met alle gevolgen en kosten van dien.

Ik kom er net achter dat Amazon deze dienst al aanbiedt, in de vorm van Amazon Simple Queue Service. Nou ja, nog geen complete ESB, maar een queue vergelijkbaar met de JMS-definitie, als ik het goed zie.

Maar ik vind het toch erg leuk.

ESB: wat moet je ermee?

Een paar weken geleden zei ik dat ik niet geloof dat de ESB's zoals we die nu kennen zo nodig moeten worden geimplementeerd door "gewone" bedrijven. Immers, als je SaaS gebruikt, heb je die ESB niet nodig. Bovendien zijn die ïmplementatie-trajecten complex en duur, en ik kwam dus tot de conclusie: niet aan beginnen. Uitzondering was wellicht de situatie waarin legacy-applicaties en services gecombineerd moeten worden.

Steve Vinoski is (zie hier, hier en hier) tot dezelfde conclusie gekomen. Hij is zijn geloof in de ESB verloren, zoals hij zelf zegt, en denkt dat ze beter niet gebruikt kunnen worden. Ook hij maakt een uitzondering voor legacy-integratie.

Zijn argumentatie is echter anders. Hij heeft bezwaren tegen de complexiteit van de SOAP/WS-* "standaard", en ziet daarin teken van de behoefte van veel IT-ers om met één taal te werken. Vinosky vindt dat onzin, en ziet meer in het gebruik van REST in combinatie met dynamische talen om problemen ad hoc op te lossen.

Ik ben niet zo voor een wildgroei van talen en taaltjes, niet omdat ik vind dat alles in één taal moet, maar omdat op den duur maintenance een probleem zal worden. Maar als MDA gebruikt wordt om het noodzakelijke te genereren, is dat bezwaar eigenlijk weg.

Vinoski wijst er voorts terecht op dat de zogenaamde standaarden (hij bedoelt WS-* etc) enorm ingewikkeld zijn, en dat men bij toepassing al heel snel door de bomen het bos niet meer ziet.

Inderdaad. Hoe dan ook, de conclusie is hetzelfde: de ESB en de daaraan verbonden protocollen gaan een twijfelachtige toekomst tegemoet.

PS: Interessant is trouwens ook de reactie van Dan Hatfield:
" Honestly, I see the ESB as primarily a political thing. It allows for a greater degree of control on delivered solutions.
In large companies, we don’t often do architecture - we do politecture…The politics drive the architecture.
Not the way it should be…but that’s the way it is."

Politecture.... Inderdaad. Maar dat is een ander onderwerp.

Kunnen SAP, MS, c.s. de draai maken?

Phil Wainewright vraagt zich (hier en hier) af of software-verkopers die het nu moeten hebben van licenties (hij noemt in dat verband SAP, Microsoft, Adobe en Oracle0 de draai naar SaaS wel zullen kunnen maken. Zie ook dit interview met Steve Singh. Overigens heeft Nick Carr daarbij zijn twijfels: hij denkt dat Microsoft wel zal slagen, in ieder geval op korte termijn.

Ik heb me dat ook meermalen afgevraagd. Bedrijven als SAP kunnen technisch die draai natuurlijk uitstekend maken. Sterker: SAP heeft dat ook gedaan. En ook als het gaat om kennis van het domein (ERP bv), dan zijn ze beter dan wie ook.

SAP ByDesign (de SaaS-SAP) is waarschijnlijk een uitstekend product. SAP richt zich met ByDesign op het MKB, maar als het goed is, waarom zouden dan grotere bedrijven er niet mee aan de gang gaan? En als dat gebeurt, droogt de licentie-geldstroom op voor SAP.

Maar de geldstroom die een SaaS-oplossing brengt is anders gespreid in de tijd, en waarschijnlijk in totaal veel kleiner. En als het al lukt om licenties te blijven verkopen, dan zijn het er waarschijnlijk minder, en ook nog eens tegen een lagere prijs agv de concurrentie van SaaS en wellicht ook OSS. En die mindere geldstroom is een probleem voor grote bedrijven, omdat ze gewend zijn aan het "makkelijke geld". Hun hele bedrijfsvoering, salarisstructuur, etc is daarop ingericht.

En als ze dan ook nog eens beursgenoteerd zijn, is het extra moeilijk te investeren in de lange termijn ten koste van korte termijn winsten.

Ik denk dat de SaaS-revolutie (of wat het ook is) wel eens een soortgelijk effect kan hebben als de komt van kleinere computers voor de oude mainframe-producenten: ze verdwijnen.

Jackson over Software Engineering

Michael Jackson vindt (of vond in 1998) dat Software Engineering als discipline niet kan bestaan. Want de echt engineering-disciplines binnen de informatica zijn verder gespecialiseerd: database engineering, of compilerbouw.

En verder een aantal scherpe, en geestig verwoorde, observaties.

Waar begin je een domeinmodel?

Gisteravond een aantal oud-collega's gesproken, waaronder John S., die nog aan de wieg van VSP heeft gestaan. En met hem een interessante gedachtenwisseling, onder meer over de vraag: wat is een goed domein-model?

John is nogal een voorstander van zaken als use-cases, sequence-diagrams, etc. Zoals bekend: ik ben daar niet zo'n fan van. John wees mij erop dat dat ook te maken heeft met de manier waarop ik denk. Dat wil zeggen: vanuit de concepten die in een domein een rol spelen: wat zijn de concepten, hoe zijn ze aan elkaar gerelateerd, wat "doen" ze? En dan kom je uit op een class-model, eventueel aangevuld met statecharts. Inderdaad: daar ben ik heel blij mee.

John denkt veel meer vanuit het "programma": hoe wordt het programma (als je daarvan nog kunt spreken) uitgevoerd? Wat is de flow? En dan zijn bv sequence-diagrams, activity diagrams en event-traces erg boeiend.

Het heeft inderdaad te maken met de manier waarop je tegen een systeem aankijkt: vanuit de dynamiek, of "ontologisch".

HumanWave en Cordys

Gisteren op het event van Cordys geweest. Hoogtepunt voor mij was het verhaal van Bart Aarsen over de realistaie van een SaaS-HRM systeem: HumanWave. Als ik het goed het begrepen is het deze week live gegaan.

Eigenlijk zijn dit soort toepassing van een "ESB", zeker van Cordys, logischer dan de implementatie bij "eindklanten". Het zou heel goed kunnen dat de onafhankelijkheid van Cordys, dwz: het feit dat men niet te maken heeft met een te integreren stack van bestaande software bij de "installed base" (zoals bij bv IBM en Oracle wel het geval is), bij zo'n SaaS-toepassing voor Cordys werkt.

BPM en de architectureluur

Een vraag:

"Hoe "bijzonder" is de BPM laag en in hoeverre leent deze zich voor hergebruik, SaaS, etc. ? We nemen dan even aan dat de BPM laag vrij is van zaken die er niet thuishoren. Volgens de filosofie van service orientatie is de BPM laag toch de plek waar de applicatie wordt gevormd (op basis van componentent die we al hebben). Er van uitgaande dat we geen twee applicaties ontwikkelen die hetzelfde kunstje doen, zou je zeggen dat 1) herbruikbaarheid binnen de BPM laag minimaal is en 2) de BPM content bij uitstek content is die bedrijven bij zich willen houden - zowel qua ontwikkeling als qua beheer.

De rest van de applicatie architectuur en de onderdelen die jij noemt kunnen al snel als infrastructuur worden betiteld en als zodanig worden behandeld. Maar die BPM laag... hmmm... ik weet het niet."

Technsich gezien kan de BPM-laag zelf ook in de infrastructuur. Je ziet dat nu al gebeuren: ESB's hebben vaak nogal wat mogelijkheden om business-processen uti te voeren, althans voorzover het de executie van BPEL of zoiets betreft. Dat opent dus ook de mogelijkheid om dat bij een SaaS-provider te laten doen, en daarmee is het in zekere zin infrastructuur geworden.

Ik denk dat we het daarover wel eens zijn, maar dat is jouw punt niet, geloof ik.

Jouw punt is (denk ik): de BP-logica is uniek voor een bedrijf f zelfs voor een proces binnen een bedrijf, en leent zich dus niet voor hergebruik.

Ik vraag me af of dat waar is. Is het nou echt zo dat een fulfillment-proces zo vreselijk uniek is? Volgens mij zijn die processen in de meeste bedrijven juist tot op grote hoogte hetzelfde. En dat deel dat inderdaad hetzellfde is, kun je dus hergebruiken.

Maar er is nog iets, en dat heeft te maken met de achtergrond van BPM. De BPM-ers komen in het algemeen (voorzover ze een IT-achtergrond hebben) uit de data-oriented/4GL-hoek. Hun beeld is: je hebt een database, en daarbovenop draaien applicaties, die de business-processen uitvoeren. Het is dan ook duidelijk dat er geen goede plaats is voor de zogeheten business-rules., en dus komt er een ingewikkeld verhaal over business-rule-engines of zoiets bij.

Echter, een goed ontworpen SOA lijkt meer op een component-based systeem, en de design-aanpak voor een SOA lijkt dan ook veel meer op een object-oriented aanpak dan op een data-oriented aanpak.

In een OO/SOA-aanpak zijn er veel meer manieren om "gedrag" (dus business-rules, proces-logica en zo) te beschrijven dan de meeste BPM-ers zich realiseren. Als je en SOA goed ontwerpt, dan zit er veel minder in die BPM-laag dan wordt aangenomen in een "conventionele" BPM-aanpak.

Met andere woorden: ik vraag me af of die BPM-laag wel zo interessant is voor bedrijven om "bij zich te houden". Niet alleen omdat er veel generieks in zit, maar ook omdat ie goed beschouwd nogal dun is.

Ik denk wel dat bedrijven hun domeinmodellen "bij zich" moeten houden. Maar dat geldt dan niet alleen voor de processen, maar wel degelijk ook voor een groot deel de achterliggende business-logica. Niet zozeer omdat die domeinmodellen uniek zijn (dat zijn ze geodbeschouwd maar voor een klein deel), maar vooral omdat men lock-in wil voorkomen.

Als je je domeinmodel laat implementeren door SaaS.com, en je besteedt in feite ook het bouwen en het beheer van dat domeinmodel daaraan uit, dan zit je met handen en voeten aan SaaS.com vast. Terwijl juist dat model weergeeft hoe je tegen je gegevens aankijkt, wat je processen zijn, welke vrijheidsgraden je hebt, enzovoort. Gezien vanuit een IT-standpunt IS dat model je bedrijf. Dat besteed je niet uit.

Wat is architectureluur?

Een lezer vraagt zich af:

"Wat is in je verhaal precies de scope van "architectuurlogica"?

In welk begrip zit alles wat met BPM te maken heeft? BPM omvat in legacy applicatie veel code en is m.i. niet herbruikbaar."

De bedoelde post ging over Asterix en de business-logica.

1. architectuurlogica: daarmee bedoelde ik dat dele van de code dat ontstaat omdat een bepaalde architectuur wordt toegepast. Dus bv database-benadering, schermopbouw, in juiste formaat gieten van parameters voor een RPC, vertalen van EDI-berichten, code nodig om een EJB goed te laten werken, enzovoort, enzovoort. In de praktijk is dit een heel groot deel van de code. De eigenlijke business-logica zelf is zo gecodeerd, en de rest is "het laten werken". Dat is "architectuurlogica".

BPM-logica in de strikte zin des woords is business-logica. En dat is niet zo'n groot deel van de code, alleen lijkt het veel omdat daar de verknoping met architectuur-logica nog sterker is.

2. is BPM-logica niet herbruikbaar? Dat weet ik nog zo net niet. Het probleem van veel systemen waarin BPM-logica expliciet is opgenomen, is dat er allerlei zaken in zitten die daar helemaal niet horen. En omdat de BPM-laag van het gemiddelde systeem niet is ingericht op hergerbuik en vermijding van redundantie, is het gevolg dus; redundantie.

Het begint er al mee dat de "business-rules" vaak in de BPM-laag worden geevalueerd. Dat is in verreweg de meeste gevallen helemaal niet nodig, sterker: onhandig, maar het gebeurt toch. In dat soort systemen is de laag onder de BPM-laag meestal niet veel meer dan een veredelde database. Naar mijn idee zijn dat gewoon slechte architecturen.

Als een systeem goed wordt ontworpen, met het "gedrag" (in de zin van object behavior) op de juiste plaats (dwz in de meeste gevallen; bij de data), dan blijkt de BPM-laag helemaal niet zo ingwikkeld en dik te zijn.

Daar komt bij dat ook binnen een BPM-laag doorgaans meer hergebruik mogelijk is dan doorgaans wordt ontworpen.

Samenvattend: ik denk dat er wel degelijk veel hergebruik mogelijk is in het BPM-deel, voor een groot deel door logica in ddat BPM-deel daaruit te halen.

Details

Nick Carr is normaliter een SaaS-evangelist, en een goeie ook. Deze keer wat zinnige kanttekeningen. Vooral zijn tweede punt, tav de lock-in van Office-formaten e.d., is van belang.

Functionaliteit uit de muur: vervolg

In een reactie op de post "functionaliteit uit de muur" wordt gevraagd:

"Ik begrijp uit je verhaal dat je voor de traditionele IT-afdeling vooral een rol weggelegd ziet in het vertalen van de business naar de IT. De IT komt dan vervolgens "uit de muur".

Wat komt er volgens jou precies "uit de muur"? De services in de zin van webservices of ook de proceslaag (executie) die - tijdens executie - van deze webservices een werkbare applicatie maken (BPM), de UI laag, etc.?"

Er zijn 2 betekenissen van "uit de muur" die hier door elkaar dreigen te lopen:

1. "technisch uit de muur": de software wordt geserveerd op een remote host, en wordt door de gebruiker via een client met een browser oid benaderd.
In die zin komen inderdaad de webservices in de zin van business-webservices uit de muur, dat is duidelijk.
Maar er is geen reden waarom dat met de proces-laag niet ook zou kunnen. Het lijkt mij erg handig om ook de BPM-engine remote te hosten, en ik zie geen reden waarom dat niet zou kunnen. De voordelen zijn evident: makkelijker integratie met de business webservices, geen noodzaak meer van extern bereikbare lokale servers, geen aanschaf en onderhoud van een of andere BPM-engine of ESB. (zie ook deze post).
En zelfs voor het UI geldt hetzelfde. Tot voor kort was dat technisch lastig voor elkaar te krijgen, maar met een Ajax-oplossing wordt in feite het UI geladen vanuit de server. Met een Flex-oplossing gebeurt in wezen hetzelfde.

Dus als het om deze betekenis van de term "uit de muur" is het antwoord: ja.

2. de andere betekenis van "uit de muur" is: als standaard, als een commodity. Inderdaad bedoel ik deze betekenis ook.

Voor de business webservices geldt zeker dat dit "commodities" zullen worden. Misschien zijn er kleine wijzigingen en toevoegingen zinvol voor specifieke klanten, maar in de praktijk zal de commodisering hier toeslaan.

Voor de business-processen geldt dat minder. Juist deze zullen min of meer uniek zijn voor bedrijven. Dus hoewel ze technisch uit de muur komen, zijn ze geen standaard commodities.

Ik denk echter wel dat het mogelijk is van veel processen een of enkele standaard-varianten klaar te zetten, en ik denk dat ook hier meer gestandaardiseerd kan worden dan men nu denkt.

Voor UIs geldt (uiteraard) min of meer hetzelfde.

Dus als het om deze betekenis van "uit de muur" gaat is het antwoord: voor business-webservices: ja, voor processen en UIs: nee, maar het zou wel eens naar "ja" kunnen toegroeien.

Databases

Eerder heeft nav een post van mij Rik gevraagd:
"SaaS maakt het mogelijk (web)services buiten de deur te beheren. Ik neem aan dat de bijbehorende data (stam- en transactiedata) meegaat. Hoe wordt deze data aan de SaaS provider-kant beheerd? Slaat de provider de data van bijvoorbeeld het object "inkooporder" van alle bedrijven die dit object bij deze provider hebben "Ge-SaaS-d" fysiek bij hetzelfde object op? M.a.w. heeft zo'n provider een grote data-bak met alle inkooporders van een hele sector bij elkaar geplaatst? of ontstaat er een explosie van allerlei tabellen/databases?"

Volgens mij zijn dit 2 vragen:

1. hoe wordt eea technisch opgeslagen?
2. waar? Bij de SaaS-provider? Bij de klant? Beide?

Ad 1. Voorzover ik weet worden doorgaans "gewone" RDBMSen (MySQL, Oracle, etc) gebruikt, maar omdat je bij SaaS-systemen vaak met klantspecifieke uitbreidingen op het datamodel werkt, is het interessant om wat minder gebruikelijke systemen te gebruiken: row-oriented systemen, objectbases al of niet op XML-basis, etc.

Ad 2. In principe worden de gegevens bij de SaaS-provider opgeslagen, en ik denk dat meestal gegevens van verscheidene klanten in één "fysieke" database worden opgeslagen. Echter, de meeste SaaS-providers hebben serverparken op verscheidene locaties, dus het zal wel niet allemaal in één heel grote database worden opgeslagen.

Er is nogal wat discussie over de vraag of de klanten een "eigen" kopie van de database willen hebben, om security-redenen (achter de firewall) of als backup.
Oracle bv beweert dat dat het geval is, maar de logica van SaaS wijst naar mijn idee de andere kant uit. ik verwacht dan ook dat een dergelijke proliferatie van databases niet de norm wordt.

Vastberaden, maar soepel en met mate

Vorige week vrijdag ben ik naar het BEA-symposium over de BEA-ESB, SOA, etc geweest. Uitstekend georganiseerd, goede presentaties, en een hoge opkomst.

En toch, en toch.... Ik liep er rond, luisterde naar de verhalen, en vroeg me af: wat zouden we hiervan over vijf jaar denken? En over drie jaar?

Dat begon gelijk met het betoog van Massimo Pezzini, Gartner-expert op het gebied van SOA. Hij schetste het bekende beeld voor wat betreft de beloftes van de SOA, maar hij liet ook zien hoe ingewikkeld eea wel niet is: het kiezen en implementeren van een ESB, de organisatorische vereisten, en dan al die dingen waarmee je rekening moet gaan houden. Security! Choreography!! Orchestration!!! En vooral: GOVERNANCE!!!!

Hij eindigde met een reeks zeer ingewikkelde plaatjes, gevolgd door de mededeling dat het mogelijk was om succes te hebben met al dit moois, maar dat je dan wel aan de ene kant doelgericht en zeer gedisciplineerd moet zijn, en aan de andere kant realistisch en pragmatisch.

Wat zou een klant (dat wil zeggen: een niet IT-er) hier nou van denken? Het zal wel voordelen hebben, en misschien moet ik er aan geloven, maar het is allemaal wel erg ingewikkeld, ik heb er natuurlijk weer dure externe jongens voor nodig, en vooral: dit dus gaat klauwen met geld kosten. En het korte-termijn resultaat is onzeker, om niet te zeggen: vaag.

Maar stel dat SaaS zometeen werkelijkheid wordt, en we de functionaliteit "uit de muur" laten komen, is dan die ESB en al dat gedoe nog nodig? Komt die BPM-laag dan niet ook bij een SaaS-provider te liggen? Zit dat wat ik nodig heb dan niet gewoon in de browser, of in het OS? (Als er tussen die twee dan nog een verschil waarneembaar is.) Er zal dan natuurlijk een SOA zijn, en ook zoiets als een ESB, maar de vraag is in hoeverre een "gewoon bedrijf" dat zelf moet regelen en zelf moet aanschaffen.

Zullen al die SOA-trajecten achteraf goede investeringen blijken te zijn? Ik denk het niet, al is het is natuurlijk mogelijk om "toekomstvast" te investeren, dat wil zeggen: een scherp oog gericht te houden op de SaaS-ontwikkelingen. En soms zijn de SOA-investeringen nu onmiddellijk de moeite waard omdat ze een concreet en urgent probleem oplossen met de bestaande systemen, en dan vooral de integratie daarvan.

Een goed voorbeeld van een succesvol project werd geboden in het uitstekende verhaal van de CTO van Nuon, Jeroen Scheer. Maar hij benadrukte ook dat een groot deel van het werk daar in de organisatie zat, en dat de systeemintegratie daar een weliswaar noodzakelijk, maar toch niet al te groot deel van uitmaakte.

Ik denk dat zelfs bij legacy-integratie projecten het pragmatisme en het gezonde verstand zal leiden tot beperkte investeringen in de technische architectuur, omdat juist dat deel waarschijnlijk in de SaaS-infrastructuur zal "verdwijnen", en dientengevolge veel goedkoper zal worden.

Want dat is uiteindelijk de belofte: standaard IT wordt als service geleverd, tegen lage prijzen op gebruiksbasis. Voor standaardzaken hoeven dus geen grote investeringen meer te worden gedaan. Maar als dat waar is voor functionaliteit, dwz: voor de systemen zelf, waarom dan niet ook voor de ondersteunende infrastrcutuur, zoals een ESB?

Cap en GAPE: aanvulling

Ik sprak vandaag iemand van Capgemini, en die wist te melden dat (voorzover hij wist0 de samenwerking tussen Cap en Google gaat over het hosten van Googel Apps, en eigenlijk niet veel meer dan dat.

Ik blogde daarover eerder.

is Bokito eindelijk los?

SAP introduceert de langverwachte SaaS-versie van het SAP-ERP systeem. Gericht op de middelgrote bedrijven, etc, etc.

Ik ben benieuwd hoe zich dit verhoudt tot "nieuwe" SaaS-oplossingen zoals WorkDay.

3 soorten Internet platforms

Een interessant stuk van Marc Andreessen over de soorten platform die op het Internet bestaan. Andreessen gelooft in SaaS, zoveel is duidelijk.

Toevoeging: Andreessen noemt 5 leveranciers die level 3 leveren: Ning (dat is ie zelf), Second Life, Salesforce.com, Amazon en Akamai. Ik vermoed dat het interessante WorkDay ook tot dat rijtje behoort (al is me bij WorkDay nog niet helemaal duidelijk waar de klantcode wordt geexecuteerd). Hoe dan ook: WorkDay schreeuwt om MDA (zie ook eerdere post).

Logische ontwikkeling

Salesforce.com maakt het mogelijk om het ontwikkelplatform te gebruiken zonder Salesforce logo's e.d.

Dat is een mooie en logische ontwikkeling.

Asterix en de business-logica

In een Asterix-verhaal (ik geloof Asterix en het 1ste legioen) komt een scene voor waarin een aantal "barbaren" dienst neemt in het romeinse leger. Ze moeten gekeurd worden, en ontdoen zich dus van hun diverse kledij. Er is ook een Goth bij, die een ontzettend martiaal berevel draagt, en er deswege zeer indrukwekkend uitziet. Bij die keuring echter blijkt uit dat berevel een buitengewoon schriel mannetje te stappen. Zonder berevel blaas je 'm zo om.

Ik moet aan dat beeld nogal eens denken als het gaat om de extractie van business-logica uit legacy. In legacy-systemen is erg veel geld, soms tientallen miljoenen, gestoken. En we hebben dus ook het idee dat die business-logica dus ook wel een forse omvang zal hebben. En menig bedrijf vleit zich ook met de gedachte dat dit "unieke" business-logica is, en daarom van nog grotere waarde.

Echter, als we die business-logica uit het legacy-systeem halen, en ontdaan van redundantie, code die nodig is voor de gekozen architectuur (database-benadering, scherm-afhandeling, transactieonele integriteit, enz) eruit halen, dan blijft er doorgaans een mooi en overzichtelijk business-model over. Een systeem van 600.000 regels code blijkt dan samen te vatten in een model van 27 classes. En een zeer groot deel van die 27 classes blijkt ook nog eens uiterst generiek te zijn: ze zijn vrijwel helemaal ook van toepassing op een willekeurig ander bedrijf.

Met andere woorden: de echte business-logica is slechts een zeer klein deel van een systeem (althans gemeten in regels code), en ook nog eens voor een klein deel uniek.

Nou gaat dit alleen om de business-logica, en die andere code is ook nodig. De database moet benaderd worden, de schermen moeten worden afgehandeld, enzovoort. Het berevel was wel nodig. Maar die architectuur-logica geldt voor alle systemen, en vrijwel al die code zou, mits goed gescheiden van de business-logica, kunnen worden hergebruikt. En met MDA/D/E kan dat.

Dus: als we in staat zijn om:
- generieke business-logica te hergebruiken
en
- software benodigd om de business-logica in de gewenste architectuur te hergebruiken
dan kunnen we bestaande systemen vervangen voor een fractie van de investeringen in het legacy-systeem.

En als we dan ook nog eens de voordelen die SaaS in dit verband biedt (centraal beheer, delen van kosten over vele gebruikers) in acht nemen, dan leidt dat tot een onrustbarende maar waarschijnlijk onontkoombare conclusie: de vervangingswaarde (en daarmee de economische waarde) van veel bestaande software ligt ver, ver beneden de waarde waarvoor de software in de boeken staat, laat staan de som van de investeringen.

Oeps. Betekent dat nou dat we al die jaren niks nuttigs hebben bereikt? Nee, natuurlijk niet. Er waren toen geen betere mogelijkheden. Maar dat is geen reden om onze kop in het zand te steken. Het kan nu wel anders.

Moet dat dan onmiddellijk gebeuren? Nee. Als een legacy-systeem goed werkt, dan zijn meestal de operationele kosten laag. Vervanging is dan lang niet altijd economisch zinvol.

Maar dat laat onverlet dat de consequenties van "functionaliteit uit de muur" verbijsterend zijn.

GAPE en Cap

Phil Wainewright gelooft niet erg in Capgemini die Google Apps gaat ondersteunen. Volgens hem zitten klanten die Google Apps willen, niet te wachten op een hoop consultants.

Daar zal ie wel gelijk in hebben, maar ik denk dat Capgemini op deze manier bij echte SaaS-klanten wil binnenkomen. En dus wellicht in eerste instantie helemaal niet zoveel consultancy wil leveren.

Cap weet aan welke kant de boterham gesmeerd is

Capgemini gaat Google Apps bij klanten introduceren en ondersteunen, volgens dit bericht. Een logische ontwikkeling, maar toch ook opmerkelijk, omdat Cap hiermee afstand neemt van de traditionele standpunten van de IT-ers over de toepasbaarheid van dit soort diensten ook in grotere bedrijven.

De honden blaffen, maar de karavaan gaat verder.

IT afdelingen en Web 2.0

In dit en in dit verhaal worden voorbeelden gegeven van organisaties die Web 2.0 oepassingen willen implementeren, maar daarin niet worden geholpen, of zelfs worden tegengewerkt door de eigen IT-afdeling.

Ik geloof het allemaal onmiddelijk. In deze voorbeelden gaat het vooral om "social web" achtige toepassingen. Het zou dan nog kunnen dat eea buiten de expertise zit van de bestaande IT afdelingen.

Maar ik denk dat het probleem verder gaat, en dat IT afdelingen vaak ook core-business toepassingen tegenhouden. Gedeeltelijk omdat ze er geen verstand van hebben, gedeeltelijk omdat ze het onzin vinden, en gedeeltelijk omdat ze door bv SaaS in hun bestaan worden bedreigd.

De organisatie van IT, software ontwikkeling, etc is een groot obstakel geworden, vrees ik. We komen hierop terug.

Het risico van SaaS

Ik ben deze week nog niet actief geweest op deze blog. En waarom niet? Omdat "op de zaak" het Internet "het niet deed". Wat was er gebeurd? Kennelijk was op het LAN, dat verbonden is met het netwerk van de provider een zwaar geinfecteerde computer gehangen. Die begon direct allerhande rotzooi te verspreiden. Hierop sluit de provider de verbinding af, dat wil zeggen: email via de provider was nog wel mogelijk, maar verder niets. Geen FTP, geen HTTP, niets.

Daarna begon het grote gehannes. Want het oorspronkelijke probleem (de geinfecteerde laptop) was snel opgespoord en opgelost, maar toen moest de verbinding weer herstart worden. En door een hoop administratief gedoe, misverstanden, een niet te bereiken helpdesk, enzovoort duurde dat erg lang.

Sterker: nu, bijna vier dagen verder, werkt het nog steeds niet. Inmiddels is er een noodverband, die op dit moment door mij wordt gebruikt.

Maar ik ben blij dat wij als bedrijf niet van SaaS afhankelijk zijn, want dan hadden we nu een Heel Groot Probleem gehad.

SaaS staat en valt bij de betrouwbaarheid van de infrastructuur. En daarin zitten, zeker voor kleinere bedrijven, erg veel schakels, en vooral erg veel schakels waarop je geen invloed hebt. Als je eenmaal op de backbone zit, zal het allemaal wel erg robuust zijn. En als er een probleem is, dan heeft iedereen het probleem. Dat is een troost, en het betekent ook dat het waarschijnlijk snel wordt opgelost.

Maar de verbinding naar de backbone is het zwakke punt. Je bent afhankelijk van 1 provider, en bij problemen van de snelheid van diens reactie, de kwaliteit van de helpdesk, etc. Dat zijn stuk voor stuk risico's. En makkelijk switchen van provider is er niet bij. Dat levert een onbeschrijflijke heisa op.

Misschien is het een idee om twee verbindingen via twee infrastructuren te hebben: 1 ADSL, en 1 via de kabel. Maar dan moet er wel kabel zijn, en die ligt hier niet in dit kantorenpark.

Conclusie: tobben.

Wainewright en Smalltalk

Phil Wainewright zingt de lof van Workday.

Hij zegt oa:

"At the core of those new technologies is an object-oriented approach that severs the dependence on SQL database tables at the heart of much of the brittleness of current ERP software. Back in the early 1990s, I worked for a small business owner that wanted to harness the new-found power of SQL query language and 4GL programming languages to build his company’s business systems. The company was a PC reseller, so it wanted to manage customers, orders, sales commissions, suppliers. The first step was to decide in advance how to structure the data: there had to be a table called ‘orgs’ that identified each business the company deal with; and then various tables of the different kinds of business could be joined to the ‘orgs’ table — suppliers, customers and so on.

At the time, this was a breathtakingly elegant and powerful way to map a business’s data. Yet I couldn’t help wondering what would happen if some business need came along that required a table you hadn’t defined into the original SQL database structure. Surely you were building in a significant hostage to fortune?"

En verderop:

"The breakthrough that Workday achieves is to move away from a fixed database structure. The SQL database in a traditional business management application defines the meaning of data into the table structure, and that is its achilles’ heel. Workday’s database tables reflect the needs of the object-oriented application architecture — there are just three tables, for ‘instances’, attributes’ and ‘references’ — and the data and definitions stored in the table are instantiated only when the application runs. The definitions are therefore as easy to change as the data.

When I use terms like ‘instantiated’ I’m slipping into the language of object management. At the heart of Workday is an object management server (OMS) — 30,000 lines of Java code that runs as an Apache Tomcat process, entirely in memory. When the Workday application runs, it scoops up all the data and definitions stored in that three-table database and turns them into meaningful data that can be accessed and manipulated. Changing the business logic — even at a very fundamental level — is simply a matter of changing a few definitions and re-running the application. Workday’s favorite demonstration of this capability is showing how it’s possible to reorganize the structure of your business on the fly, without recoding. In fact, Workday’s application developers never write code. They simply work with the 40 or so object types that have been built into the application, and define and instantiate them as required."

Hmmm, ik weet niet of ik hier zo weg van ben.

Om te beginnen: Phil maakt geen onderscheid tussen twee verschillende rigiditeiten:
1. de rigiditeit die voortvloeit uit de problematische wijzigbaarheid van het model in een 4GL-omgeving. Die was er inderdaad, en voor een deel hing die samen met het feit dat er eigenlijk alleen een datamodel was, waaraan de rest hing.
Het gebruik van oject-modellering lost dat probleem op.
Maar een deel van de moeilijke wijzigbaarheid van een business-model wordt niet veroorzaakt door de modelleertechniek, maar door de aard van het model zelf.
In dit geval ben ik bang dat de Workday-modellen ook niet zo makkelijk te wijzigen zijn. O ja, technisch wel, maar de (semantische) consistentie moet ook verzekerd zijn.
2. de rigiditeit die voortvloeit uit het feit dat tussen het model en de werkende code een compilatie oid. zit. Als dat het probleem is, dan is de oplossing om alles te maken, zoals Workday heeft gedaan, de juiste. Maar is dat het probleem? En is het dan nodig te volstaan met een bare-bones-metamodel met alleen classes, attriuten en relaties?

Zo te horen heeft Workday Smalltalk weer eens uitgevonden. Dat was en is een fantastische taal en omgeving, maar schaalbaarheid was altijd een probleem. En of dat nu zoveel anders is?

Belangrijker: het is niet nodig. Een implementatie bv op basis van de color-modellen zou mooier, minder riskant, en handiger voor het modelleren zijn geweest.

Solow en de functionaliteit uit de muur

Gisteren schreef ik dit. Dat leverde wat reacties op, en daarin werd o.m. door R. gevraagd of dit iets te maken had met de "Solow-paradox": het veronderstelde verschijnsel dat investeringen in IT niet terug te vinden zijn in een verhoging van de (arbeids)productiviteit.

Ik denk niet dat dat het geval is. Ik heb R. het volgende geantwoord:

"Productiviteit, in dit geval arbeidsproductiviteit AP): = Toegevoegde Waarde (TW) / input (bv eenheden arbeid, dwz: uren of zo).

Kort door de bocht: (opbrengst verkoop - kosten inkoop) / aantal uren.

Je kunt dat voor een bedrijf doen, voor een bedrijfstak, voor een land, in principe voor alles waarvan je gegevens hebt.

Productiviteitsgroei kan ontstaan door de volgende zaken:

1. kapitaalinvesteringen. je zet een machine neer, en daardoor kan iemand 100 flessen cola maken in een uur, ipv 100. Arbeidsproduktiviteit neemt toe met factor 10, maar wel agv kapitaalinvestering.

2. beter opgeleide en/of ervaren medewerkers. Idem.

3. total-factor-productiviteit. het blijkt dat las je hieraan gaat rekenen er vaak ook een groei van de produltiviteit is die niet eenduidig valt toe te schrijven aan een van de bovenstaande factoren, maar kennelijk uit de combinatie komt rollen.

Als je het gevoel hebt dat eea vaag wordt in de mist van relativiteit: ja, dat is zo. Toerekening van produktiviteit is lastig, en vaak zeer omstreden (vandaar ook die jarenlange discussie over die Solow-paradox.)

Een van de lastige zaken is het tijdseffect.

Voorbeeld; stel we werken allemaal 1600 uur per jaar, en we produceren met stoommachines. Nu gaan we allemaal tegelijk over op elektra, en we produceren 2x zoveel. Prijzen blijven gelijk, lonen verdubbelen (want dubbele produktie) (kosten elektra enzo laten we buiten beschouwing).

Dus: TW neemt toe met factor 2, aantal uren blijft gelijk, geen inflatie, dus verdubbeling arbeidsprodukiviteit.

Maar stel nu dat het omgekeerde gebeurt: lonen blijven gelijk, maar prijzen halveren. TW blijft gelijk (verdubbelde prod, gehalveerde prijzen), aantal uren blijft gelijk, conclusie: geen stijging
arbeidsprod?!

Nee, zo simpel is het neit, want je moet corrigeren voor inflatie. In dit geval is er agv die prijsdaling een deflatie van 50%. En als je de TW daarvoor corrigeert, blijkt er keurig weer een produktiviteitsstijging in te zitten van 100%, zoals verwacht.

Wat dit laat zien is dat dit soort arbeidsprod. cijfers heel moeilijk goed te berekenen zijn, o.m. agv die inflatie-effecten. Want bij de inflatie is bv toename van kwaliteit en substitutie van produkten (allebei te verwachten gevolgen van technologiesche veranderingen) heel moeilijk mee te nemen, zeker over een langere periode.

Solow: je zou verwachten dat je een sterk toegenomen investering in IT zich laat zien in een stijging van de arbeidsprod. S. beweerde die niet te zien.

Ik weet niet precies hoe dit zit, maar ik heb het idee dat het voor een deel geklets is.

1. tot ong 1975 steeg de arb.prod. fors. Ik vermoed dat een groot deel daarvan aan automatisering is toe te schrijven. Als dat niet te zien is, verdenk ik de cijfers die daaraan ten grondslag liggen.

2. tussen 1975 en pakweg 1990 of zo is de stijging van de a.p. inderdaad veel lager. En er is wel in IT geinvesteerd. Maar er zijn natuurlijk veel meer variabelen, en het zou kunnen (denk ik)
dat zonder IT die a.p.stijging nog lager was geweest. Misschien zit ik er naast, maar ik wantrouw die makkelijke stelling van Solow nogal.

3. Een deel van de investeringen uitte zich vooral in hogere kwaliteit van produkten, en in betere besturing van de produktie-processen. Die hogere kwaliteit is berucht moeilijk mee te nemen in inflatiecijfers, en daarmee in AP-cijfers, en die betere bedrijfsvoering zou terug moeten komen in betere resultaten en tenslotte daardoor lagere prijzen (lagere kosten
voorraad bv door JIT-logistiek, lager risico door beter zicht op risico's, etc), maar dat kan best even duren. Het zou mij ook niet verbazen dat een deel van de stijging van de AP in de jaren 90 het gevolg is van uitgestelde effecten in de prijzen uit de jaren 80.

Dat neemt niet weg dat er zeker veel investeringen in de IT niet bijdroegen. Om te beginnen al die projecten die tot niets leiden, en daarnaast zijn er natuurlijk ook veel "business-toepassingen' waarvan ik niet zie hoe die ergens toe bijdragen. En tenslotte veel geneuzel met PC's zonder veel nut.

Voorbeeld: er is natuurlijk een kostenverlaging doordat tegenwoordig iedereen snel zijn rapporten en zo kan maken. Geen drukker, geen typistes, etc. Prachtig.

Maar een deel van die winst gaat natuurlijk even zo hard weer zitten in eindeloos geneuzel over fonts en plaatjes (Powerpoint!), productie van zinloze documenten, etc."

Tot zover het verhaal over de productiviteits-paradox.

Met de "functionaliteit uit de muur" heeft dit allemaal echter weinig te maken.

Functionaliteit uit de muur

Wat is de consequentie van SaaS?

Goed beschouwd dit: IT, althans de gangbare business-functionaliteit, komt "uit de muur". Binnenkort dankzij SaaS zowat letterlijk, maar nu al figuurlijk. Je kunt voor een zeer lage prijs de "standaard" (wat is die standaard?) business functionaliteit kopen. SaaS, Internet, outsourcing, standaardpakketten, open source, en ook zaken als virtualisatie en grid computing werken wat dat betreft allemaal dezelfde richting uit. En het spoort ook met de neiging van bedrijven om alleen te investeren in hun echte core. IT, zelfs business functionaliteit hoort daar goed beschouwd zelden bij.

Maw: IT, althans dat deel ervan, wordt of is een "commodity", en dat betekent dat er nauwelijks een concurrentie-voordeel mee te behalen valt, in ieder geval niet op langere termijn. Dus doen bedrijven er verstandig aan om IT zoveel mogelijk als een kostenpost, een soort infrastructuur, te zien. Wellicht ten overvloede: het gaat dan niet alleen om de hardware (computers, kabels, routers, etc) en de systeem-software, maar ook om de business-software zelf.

Er valt natuurlijk met een nieuwe business-toepassing (meestal een herschikking van bestaande functies, of een beter UI op die functies) wel degelijk voordeel te behalen, maar dat zal in de praktijk heel snel worden nagemaakt door de concurrenten. (Ik heb een keer vernomen dat in de financiele wereld een nieuw produkt hooguit anderhalf jaar voorsprong geeft, meestal veel korter.)

De consequenties voor de IT-industrie zijn natuurlijk groot. De fictie van het bedrijfsspeciefieke maatwerk kan aan het gas (eindelijk, eindelijk. Altijd al kletskoek geweest), en de eigen IT-ontwikkeling van bedrijven is alleen maar een duur blok aan het been. Dus outsourcen die handel, en weg met die licenties!

Maar dat uitdijende heelal van services, geoutsourcede systemen, etc moet natuurlijk wel geprojecteerd worden op de business-functionaliteit van een bedrijf. Dat goed (dus: betrouwbaar, en dusdanig dat de wijze van implementatie echt irrelevant is) en goedkoop doen is ook een taak van IT.

En daarvoor is een forse omschakeling nodig. Want waar we eerst ons richtten op de code als referentiepunt en plaats van wijziging, kan dat nu niet meer. De code ligt in India, of is niet eens bekend omdat je een verscheidene service-leveranciers gebruikt, en hoe die eea gecodeerd hebben weet je niet, laat staan dt je bij die code kunt.

Maar hoe dan wel? Modellen. Die maken het mogelijk om volledig, exact en platform- en implementatie-onafhankelijk de business te beschrijven en bovendien (de functionaliteit van) de software te beschrijven, zelfs te genereren. Ze zijn dus een noodzakelijke koppeling tussen enerzijds de business en anderzijds de services en andere software die gebruikt worden
of kunnen worden.

Kan dat? Ja. We zijn inmiddels goed genoeg in het modelleren van domeinen dat we de business volledig en exact kunnen beschrijven. En het mooie van MDA/MDE is dat we de garantie hebben dat die modellen ook platformonafhankelijk kunnen worden gerealiseerd. We hoeven niet altijd gebruik te maken van die route (bij outsourcing bv kunnen de modellen als een "gewone" (maar wel volledige) specificatie dienen), maar het kan wel.

En die domein-modellen worden dus het "interface" tussen de gerealiseerde functionaliteit waar dan ook, en de business. Het stopcontact aan de muur, zogezegd.

Wainewright neemt Oracle te pakken

Phil Wainewright gaat hier helemaal uit zijn dak in een tirade tegen een betoog van een knakker van Oracle over SaaS.

Phil's belangrijkste punten, afgezet tegen de beweringen van die Oracle-vogel:
1. Klanten willen, als ze SaaS gebruiken, geen eigen database.
2. Klanten willen best een database sharen met andere SaaS-gebruikers.
3. Klanten willen helemaal geen software "in bezit" hebben
4. SaaS is niet alleen maar hosting van applicaties.

Phil heeft natuurlijk helemaal gelijk, al zullen veel van die punten van die Oracle-jongen ook wel als "bezwaar" tegen SaaS geopperd worden. En dus spelen ze wel een rol.

Maar ik ben het helemaal met Phil eens dat het geblaf is tegen een karavaan die toch gewoon verder gaat.

Meta data en Carr

Hierop ga ik terugkomen.

BPM en agility

Goed stuk van Richard Veryard in CBDI Journal (link naar samenvatting). Veryard vestigt de aandacht op het feit dat toepassing van BPM en SOA zonder meer zeker niet de voordelen op het gebied van agility gaat opleveren die men er van verwacht.

Inderdaad. Zie ook SaaSaaS.

David Hay en de DNC

Ik heb inmiddels David Hay's Data Model Patterns in mijn vingers gekregen. Het is duidelijk dit dit een van de bouwstenen was voor de colors-aanpak van Peter Coad c.s. Ik was benieuwd of dit boek vol met data model patronen ook een equivalent van de DNC (de Domain Neutral Component) bevat.

En zowaar: daar is het Universal Data Model! Maar helaas, nadere bestudering leert hier dat het inderdaad een metamodel betreft, maar dan een in een andere abstractie-richting. Wat het UDM van Hay in feite doet is het begrippen-paar class-instance in een datamodel weergeven, attributen en attribuutwaarden als entiteiten weergeven, en relaties expliciet benoemen.

Dat is dus vergelijkbaar mer de MOF Layer 2 beschrijving van UML. Nuttig (en ook wel logisch gezien het gemis aan een dergelijk metamodel in data modeling), maar iets anders dan het color-metamodel. Toch wel raar dat Hay, als ie toch aan het metamodelleren was, die voor de hand liggende stap heeft gemist: het universele domein model.

Affijn, ik heb het boek nog niet helemaal doorgewerkt, dus misschien zie ik iets over het hoofd.

Literate modeling

Een zijspoor van het onderzoek naar archetypes: literate modeling. Het is een techniek waarbij modellen worden "uitgelegd" voor "stakeholders" die ze anders niet begrijpen.

Arlow en Neustadt introduceren dit begrip in hun boek, en op codegeneration vat Jim Arlow de voordelen als volgt samen:

1. The UML model tends to be more correct. It’s amazing how often we have taken a "correct" UML model and discovered semantic errors in it when we came to explain it to ourselves by writing the narrative.
2. You get an improvement in quality. This arises because the non-technical stakeholders gain the ability to assess and critique the model.
3. You get better requirements traceability. High-level requirements often become lost in UML models. We call this the "trivialization of requirements" in our paper. The narrative must highlight key requirements and illustrate how the UML model realizes these.
4. You increase the business benefit of your UML models by making these models accessible to a much wider audience.

Duidelijk verhaal, prima verhaal. Ik geloof dat ik zelf iets dergelijks ook al doe. Dus dan is get goed. :)

De voordelen die Arlow noemt zijn er ook inderdaad, en het zijn echte voordelen.

Maar heb ik een twijfel.

De suggestie is dat dit soort modellen (het gaat om modellen voor de analyse) bedoeld zijn voor afstemming met "stakeholders", of zelfs dat die modellen eerst moeten zijn goedgekeurd door de "stakeholders".

Volgens mij is dat allebei niet waar. Het doel van modellen is het specificeren van een systeem, en de uiteindelijke toets voor de correctheid is of er een goed werkend systeem, met de juiste vrijheidsgraden, etc mee tot stand komt.

Of de "stakeholders" de modellen "herkennen" of begrijpen, is eigenlijk niet relevant. Natuurlijk, als de domeinanalist het domein probeert te begrijpen, is het handig om de modellen die hij heeft gemaakt af te stemmen, en in dat kader is literate modeling zeker nuttig.

Maar de uiteindelijk verantwoordelijke is de analist, en de mening van de "business" over die modellen op zichzelf is strikt genomen niet relevant.

Archetypes (vv)

Ruim twee weken geleden kondigde ik aan te gaan onderzoeken wat het nut is van archetypes, en die te gaan beoordelen op de volgende criteria:
1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
2. is de aanpak bruikbaar in een MDE-traject?
3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?
4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?
5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?
En daar kwam later bij:
6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?

De onderzochte aanpakken zijn:
- de REA aanpak (Resources, Events, Agents), in de variant van Pavel Hruby c.s.
- de "colors" aanpak van Peter Coad c.s.
- de Archetype-aanpak (pleomorphs) van (o.m.) Arlow en Neustadt.

Ik ben nog lang niet klaar, maar dit is de eerste inventarisatie.

Ad 1. is de aanpak bruikbaar voor het maken van een analyse van een business-domein?
- REA: ja. Daar is de aanpak bij uitstek voor bedoeld. Het gehanteerde metamodel (REA, duality, conversion process, etc) is ook expliciet uit de abstractie van business-domeinen ontleend (mn uit accounting). De aanpak is compleet: elk business-domein wordt in principe volledig bestreken, zij het dat soms wat kunstgrepen nodig zijn. REA is ook alleen maar voor business-domeinen geschikt.

- colors: ja. De Domain Neutral Component (PPT, Role, Description, Moment/Interval) is een zeer abstract model, en eigenlijk een metamodel dat overal (niet alleen voor business-analyse) kan worden toegepast. Maar er zijn specialisaties mogelijk voor business-analyse, en Coad c.s. geven daarvan ook voorbeelden. De aanpak is compleet: elk business-domein wordt volledig bestreken.

- pleomorphs: ja. De aanpak biedt een set aan (samenhangende) analyse-patronen, die uitstekend geschikt zijn om een business-analyse te doen. Of elk business-domein compleet wordt afgedekt, betwijfel ik.

Ad 2. is de aanpak bruikbaar in een MDE-traject?

- REA: ja, mits verder uitgewerkt. Er zijn iig aanzetten voor MDA/MDE-achtige zaken, maar er zal wel nog het nodige meoten worden gedaan om eea te laten werken. Nadeel is wel dat de REA-aanpak niet uit de hoek van de software-ontwikkeling komt, waardoor de mapping van REA-concepten op bv componenten of classes nog wel eens lastig kan zijn (zie bijvoorbeeld het ontbreken van een Role).

- colors: ja, mits doorontwikkeld. Deze aanpak stamt van voor de MDA-hype, en dus zitten er geen expliciete aangrijpingspunten voor MDA of MDE in. Echter, de aanpak zit zo strak in elkaar als het gaat om de afleiding van modellen dat dit geen groot probleem zal zijn. (opvallend in dit verband is dat Coad c.s. de term "metamodel" niet gebruiken voor hun abstracte patronen, hoewel ze wel bij uitstek zo te gebruiken zijn).

- pleomorphs: ja. Is expliciet opgenomen, en er worden zelfs voorbeelden gegeven met ArcStyler als tool.

Ad 3. is de aanpak bruikbaar in een Service-oriented of SaaS-omgeving?

- REA: waarschijnlijk wel. Echter, de mapping van analyse concepten naar services is nog niet triviaal, mede omdat een REA-model puur op het punt van bv object-orientatie (cohesie interfaces, etc) nog niet helemaal klaar is.

- colors: ja. Weliswaar zitten services etc. niet in de aanpak, maar dankzij de strak uitgewerkte interfaces, de keurig aansluitende domein-concepten en vooral de roles die al in het model als koppeling optreden, is een mapping op een SOA niet moeilijk.

- pleomorhs: waarschijnlijk wel. Deze aanpak resulteert in goede OO-modellen, waaruit services normaliter makkelijk af te leiden zijn.

Ad 4. is de aanpak ingepast of inpasbaar in standaarden zoals UML, MDA, e.d.?

- REA: ja. Ik voorzie geen problemen.

- colors: ja.

- pleomorphs: ja, is er zelfs specifiek op gericht (compleet met voorwoord van de onvermijdelijke Richard Mark Soley, Ph.D.)

Ad 5. is de aanpak bruikbaar als heuristiek voor de analyse van bestaande softare (legacy)?

- REA: zeer twijfelachtig. REA is goed in het adhv de business analyseren van die business, maar is niet gericht op software. Ik betwijfel of dit werkt, al zullen proeven dat moeten uitwijzen.

- colors: ja, uitstekend. De top-down benadering helpt ook bij zeer rommelig in elkaar zittende legacy-software. Colors is eigenlijk een soort patroon-taal, en dat is hier een groot voordeel.

- pleomorphs: ja. Het opzoeken van de patronen is goed mogelijk, maar ze moeten wel al zichtbaar zijn.

Ad 6. leent de aanpak zich voor een koppeling met aspect-orientatie (tbv symmetrische en asymmetrische aspecten of deelmodellen)?

- REA: redelijk. REA gebruikt expliciet AO voor bepaalde vormen van gedrag (asymmetrische aspecten vooral). Om het echt in een MDE-aanpak te laten werken is nog wel wat werk nodig, maar het begin is er.

- colors: redelijk. Aspecten zitten er niet expliciet in, maar de aanpak (weer dankzij de roles) leent zich er goed voor. Om het in een MDE-aanpak te laten werken is nog wel werk nodig.

- pleomorphs: matig. Voorzover ik kan overzien is er geen rekening mee gehouden. Aan de andere kant; het zijn wel OO-modellen, dus het is er in te breien. Maar er zal meer werk voor nodig zijn dan bij colors.

Zo, dit is de eerste inventarisatie. Het is duidelijk: er is nog veel uit te zoeken. En er is ook nog veel meer te zeggen van deze aanpakken, de voor- en nadelen, enzovoort. Dat zal allemaal gebeuren.

De europese software-industrie

Gisteren schreef ik dit.

De stelling dat Europa achterblijft op het gebied van de software, komt vandaan bij Michiel van Genuchten. Ik denk dat hij in zijn constatering gelijk heeft, en ik vermoed dat een van de factoren daarbij de rigiditeit van de europese arbeidsmarkt is. Immers, ontwikkeling van software is (als hoofdactiviteit van een bedrijf) een riskante bezigheid, waarbij bovendien de arbeidskosten een zeer groot deel van de totale kosten uitmaken.

Het probleem met zo'n rigide arbeidsmarkt is dat het heel snel een "kop-ik-win, kruis-jij-verliest" markt wordt. Als het slecht gaat, blijft men schuilen onder de paraplu van de ontslagbescherming, gaat het beter, dan laat men zich wegkopen of gaat men freelancen. En de software-industrie is een erg volatiele bedrijfstak, met hoge toppen en diepe dalen.

Dat is een probleem voor alle bedrijven die aan software-ontwikkeling doen, maar in het bijzonder voor bedrijven die een software-rodukt ontwikkelen. Immers:
1. die ontwikkeling zelf is heel riskant. Het kan heel goed gaan, maar de kans is ook groot dat het heel slecht gaat. In het laatste geval is het moeilijk om tijdig werknemers te ontslaan, en dus is het riskanter om een produkte te ontwikkelen in Europa dan in de VS.
2. de investering bij software-ontwikkeling zit niet alleen in de ontwikkelde software zelf, maar ook (waarschijnlijk meer dan in de meeste andere takken, waar investeringen in machinerie e.d. een grotere rol spelen) in de kennis van de mensen. Die wil je graag houden, en hoge beloningen e.d. liggen dan voor de hand. Maar dan gaat die ontslagbescherming weer extra knellen....

Comparative advantage

Ik vond dit artikel van Alejandro Cunat en Marc Melitz. Voornaamste strekking: het overige gelijkblijvend, hebben landen met een flexibele arbeidsmarkt een comparative advantage. Dat is geen verrassing natuurlijk, maar zij voegen er aan toe dat landen met een rigide arbeidsmarkt van die rigiditeit minder last hebben in weinig volatiele bedrijven en bedrijfstakken. En kapitaalintensivieit vermindert het voordeel van flexibiliteit ook.

Maw: landen met een rigide arbeidsmarkt hebben een comparative advantage in statische en kapitaalintensieve bedrijfstakken. (Voor de duidelijkheid: in absolute termen hebben ze waarschijnlijk nog steeds een nadeel tov flexibele landen.)

En dat verklaart wellicht waarom continentaal Europa zo zwak is op het gebied van software-ontwikkeling. Want dat is bij uitstek een volatiele bedrijfstak. Je kunt natuurlijk wel weer SW-ontwikkeling devolatiliseren door het onder te brengen bij Grote Automatiseringsafdeingen, en bij detacheringshuizen. En dat is ook precies wat er (vooral) Europa is gebeurd. Maar dat brengt weer zijn eigen problemen met zich mede.

Aspecten en archetypes

Het onderzoek naar Archetype-benaderingen vordert (zie ook hier). Wat wel duidelijk is: een koppeling van archetypes met aspecten (in de zin van Aspect-orientatie) is nodig. Immers: archetypes moeten aan elkaar gekoppeld kunnen worden. Als dat binnen hetzelfde "domein" is, is dat niet erg, al krijg je al snel een explosie van de mogelijke analyse-patronen.

Maar als de archetypes niet in hetzelfde domein liggen (en dat is bij asymmetriche aspecten al snel het geval: wie zit er te wachten op logging als je een business-model aan het bestuderen bent? Toch is logging nodig) dan is AO een geld middel.

Ik zal de aanpakken dus ook op dit aspect (grijns) beoordelen.

SaaSaaS (2)

SaaS is dus heel mooi, maar er zijn een aantal problemen en obstakels. Ik heb hiervoor een aantal genoemd (zie hier):
- er zijn standaards nodig, zowel op technisch als op "semantisch" (dwz: vwb het probleemdomein) gebied
- er is een manier van beschrijven van systemen nodig die het uitbesteden van systeemontwikkeling en -beheer, bv via outsourcing of offshoring makkelijker maakt
- de wijze van specificeren moet ervoor zorgen dat de problemen voortvloeiende uit "glue code" zoveel mogelijk worden vermeden
- er moet een manier zijn om bestaande software (legacy) in de SaaS-opzet te betrekken.

Is dat mogelijk? Ja, ik denk het wel.

We zijn al een heel stuk verder als we een (abstracte) taal hebben, die het mogelijk maakt een probleem domein (bijvoorbeeld een business-domein) te beschrijven to the point en zonder redundantie. Voorts moeten we in staat zijn een beschrijving in die taal te gebruiken voor een implementatie, zonder dat nadere informatie nodig is. Je kunt een specificatie dan gebruiken voor een automatische implementatie, maar ook voor de specificatie van een extern (bv via outsourcing) te realiseren systeem. De taal moet dus onafhankelijk zijn van de wijze van implementatie, maar ook van het platform van implementatie. Zo wordt lock-in vermeden. En de taal moet geschikt zijn om bestaande legacy-software in te beschrijven, alsmede "semantische" standaarden bevatten of in ieder geval mogelijk maken.

Zo, dat is nogal wat. Maar het kan wel. We zijn er in ieder geval vlak bij.

Voor de domeinbeschrijving is het mogelijk om met OO en UML een heel eind te komen. Inderdaad, UML is niet helemaal niet compleet: de beschrijving van gedrag is moeilijk, en UML bevat ook veel overbodige onzin (use cases!), maar die hoef je natuurlijk niet te gebruiken. Maar de basis is er, en met goed gekozen aanvullingen is OO-UML bruikbaar.

Die aanvullingen liggen op de volgende gebieden:
- beschrijving gedrag. UML is hiervoor onvoldoende. Er is een Action Language (een soort pseudo-code) nodig om gedragsbeschrijvingen bruikbaar te maken. Een subset van een gewone programmeertaal (bv Java of Ruby) is afdoende.
- een standaard voor het koppelen van de domeinmodellen. Een aspect van een domein wordt apart beschreven (later daarover meer), maar om een domein compleet te beschrijven is in feite een soort "meta-taal" nodig die beschrijft hoe modellen met elkaar samen (kunnen) hangen. Aspect-orientatie, MDSM, MDE en ook technieken als UML with color bieden bieden hiervoor mogelijkheden.
- een standaard semantiek die de gebruikte concepten beschrijft op een dusdanige wijze dat ze over de (deel)domeinen hetzelfde zijn. Voor SaaS is dat utieraard cruciaal. Hiervoor zijn verscheidene aanzetten, waarvan sommige varen onder de prachtige vlag van de "web ontology". Schitterend buzzword. Het is verstandig om een schuin oog op deze ontwikkelingen gericht te houden, maar het is niet nodig om erop te wachten. In de prakiek zijn allen OO-standaardmodellen voor business-domeinen ongeveer hetzelfde, en iig makkelijk naar elkaar te transformeren.
- eventueel kunnen naast UML DSLs gebruikt worden voor specfieke deelterreinen, zolang de koppeling met UML maar te maken is. Een voorbeeld hiervan is BPMN voor het modelleren van processen.

Wat wel van belang is; als uitbreidingen worden gemaakt, dan is het wijs om daarbij binnen de grenzen van de MOF te blijven. Dan is de koppeling naar MDE en MDA betrekkelijk makkelijk te maken. En er moet voor gezorgd worden dat de gebruikte modelleertalen en -technieken open zijn, zodat de resulterende artefacten (de modellen dus) hun waarde behouden, en niet geboden zijn aan een of andere esoterische aanpak, die niemand meer snapt na het vertrek van de goeroe van dienst.

Datzelfde (vermijding van lock-in) is nog belangrijker als het gaat om de verwerking van die modellen. Dat kan grofweg op twee manieren; handmatig, of geautomatiseerd via de MDA/MDE-route. Of een combinatie.

Eigenlijk maakt het niet zoveel uit of hoe het gebeurt. Want in beide gevallen moet de specificatie precies en volledig zijn. Bij een automatsiche realisatie is dat evident, maar bij een handmatige is het ook essentieel, omdat die steeds meer elders (in India of waar dan ook) plaatsvindt. De dagen van de halfzachte analyse, waarbij een groot deel van de specificatie in de bouwfase werd gemaakt (met alle problemen van dien) zijn over. Dat stelt duidelijk andere eisen aan de wijze van specificeren en analyseren dan we gewend zijn.

Bij een automatische realisatie is het cruciaal dat de modellen NIET op het MDA-traject zijn toegesneden. Zijn ze dat wel, dan zijn ze in feite tool-afhankelijk geworden, waarmee toch lock-in het resultaat zou zijn. En dat mag niet. Het MDA/MDE-proces dient dus zo te zijn opgezet, dat de platform- en toolonafhankelijkheid van de domeinmodellen verzekerd is, terwijl ze wel compleet zijn. (Dit sluit in de praktijk en aantal MDA-tools uit, omdat daar de PSM gebruikt wordt zowel voor platformspecifieke zaken als voor detaillering van het business-domein. Dat is belachelijk, en die tools dienen vermeden te worden.)

In de praktijk zal de realisatie in een aantal transformatie-stappen plaatsvinden, volgens het DAI-principe (Domein, Architectuur, Implementatie). De MDSD-aanpak voldoet min of meer hieraan, en er zijn inmiddels ook verscheidene tools die een voldoende flexibele M2M transformatie bieden (Borland, OAW, MIA, ArcStyler nb lijken alle bruikbaar). Een van de lastige dingen is ongetwijfeld het noodzakelijke "weaven" van deel-modellen. In de meeste MDA-aanpakken zit dat (nog) niet verwerkt, maar het is wel nodig. Gelukkig biedt hier Aspect-Orientatie (AOP, AOSD) oplossingen, en AOSD moet ook in de MDE-techniek geintegreerd worden. (MDSD doet dat trouwens ook.)

De werkwijze en inrichting van het transformatieproces moet natuurlijk flexibel maar ook open zijn, dit laatste om portabiliteit van het ene naar het andere tool mogelijk te maken. Als een transformatieproces een balck box is, is dat natuurlijk heel lastig, maar als duidelijk is hoe het werkt, is een overzetting naar een ander tool wel haalbaar. Sterker: als de trnasformaties zijn beschreven in de QVT-standaard (als dat inderdaad de standaard wordt), zijn ze waarschijnlijk herbruikbaar.

Het doel is hier: zoveel mogelijk abstractie van de concrete tooling. De MDA-standaard zou dit mogelijk moeten maken, maar het zal nog wl even duren eer die MDA-transformaties echt een "commodity" zijn geworden, en de tooling er niet meer toe doet.

We zijn eruit: dit is de oplossing. :)

De volgende keer over de IT-organisatie, SaaS en SaaSaaS. En ik zal ook een aantal thema's die hierboven zijn aangeroerd, uitdiepen.
Bijvoorbeeld:
- hoe moet je domeinmodelleren om dit alles mogelijk te maken?
- wat zijn de mogelijkheden en onmogelijkheden van UML?
- wat moeten we met DSLs?
- past legacy hier wel in, en zo ja, hoe dan?

Dat komt dus nog.