Object Arts | Future development of Dolphin discontinued.

(via http://www.object-arts.com)

This shocking announcement by Andy Bower, one of the founders of Dolphin Smalltalk, made me realise a grave mistake: I have taken the Open Source movement too much for granted.

It is a bit the same as with my opinions about the antiglobalism movement. I have always taken pride in my innate desire to ask questions, to move by my insatiable curiosity, only to realise that too often I, as many people I criticise, I am entertaining half formed opinions that never have been scrutinised. Only after reading the book by David Korten When Corporations Rule the World did I realise that there was too much about the issue of globalism I never investigated, that my opinions were manipulated by what Korzybsky would call "thalamic" thinking. Much of that influenced no doubt by careful public relations work by the pro-globalists.

Computable.nl | Archief | Column | Services en policies

(via Computable.nl)

Rick van der Lans heeft het vaak over Service Gerichte Architecturen of SOA’s, logisch, want het is een hype. Voor een gepokte en gemazelde OO expert is het echter soms vermakelijk om te zien welke problemen men in de praktijk heeft bij het implementeren van dit soort architecturen. Waar heeft Rick het over in dit artikel? Over het probleem dat een service die zich beschikbaar heeft gesteld, niet zonder regels lijkt te kunnen omtrent het gebruiken daarvan. Hij noemt het voorbeeld van wel of niet versleuteld aanroepen van die service. De eerste vraag die ik mij altijd stel als iemand iets beweert (ook al ben ik die persoon zelf) is: is dat wel waar? In dit geval: kan een service niet zonder policies omtrent zijn gebruik? En dan is mijn eerste reactie: dit is te gek voor woorden! Wat was nou het hele idee achter services? Weet u het nog?

• Services zijn fundamenteel autonoom
• Services ondersteunen composability
• Services zijn extensible
• Services ondersteunen federation

Ik heb een paar kenmerken gepakt die mijns inziens essentieel zijn in de context van policies. Services die policies definiëren omtrent hun aanroep: hoe autonoom zijn die services dan nog? Nu kan het heel goed zijn dat Rick niet bedoelt te zeggen dat iemand die een service aanroept deze policies allemaal dient te kennen. Dat is namelijk het grootste probleem in de constatering die hij doet. In los gekoppelde architecturen moeten we juist vermijden dat objecten allerlei kennis moeten hebben van elkaar om van elkaars diensten gebruik te maken. Of om het anders te formuleren: dienstenleveranciers moeten geen enkele assumptie hebben over de partijen die gebruik van hen willen maken. Dat Rick, en anderen die het probleem dat ze door een verkeerd architectuurontwerp hebben, vervolgens gaan haspelen met hoe en waar je dan die policies moet implementeren (binnen een service of er buiten in een extra service laag) doet mij echter niet meer twijfelen: hier wordt een essentieel aspect van services niet begrepen. We gaan weer regels en kennis los koppelen van de componenten die die kennis eigenlijk zouden moeten hebben, we scheiden gegevens en processen, en weer verzanden we in ononderhoudbare architecturen die niet in staat zijn toenemende complexiteit te ondersteunen. Voor mij is het evident dat services zélf de policies die eventueel betrekking hebben op hun gebruik moeten implementeren. Waarbij goed ontwerp garandeert dat die service componenten, wanneer ze hierdoor complexer zouden worden, dit door delegeren naar andere service componenten waar ze mee samenwerken (maar: waar de gebruiker van de oorspronkelijke service NIET mee lastig gevallen wordt). Maar wat we niet gaan doen is een aparte "laag" implementeren die de policies bevat. Lagenarchitecturen zijn hele slechte metaforen in deze context. Ik val dan eigenlijk een beetje van mijn stoel als hij dan vervolgens komt met het advies deze policie lagen niet zélf te gaan ontwikkelen maar hiervoor gebruik te maken van producten van leveranciers. Let wel: ik zeg hier helemaal niet dat producten die bijvoorbeeld authenticatie voor ons regelen slecht zouden zijn. Maar ik zeg wel dat ze totaal onbruikbaar zijn wanneer we die diensten inkapselen in een aparte "laag" in onze service gerichte architecturen. Als ik dit lees denk ik: goed werk leveranciers, jullie hebben zelfs Rick een flink rad voor de ogen kunnen draaien waardoor hij aan jullie handje mee loopt. Even kort: hoe dan wel? Dergelijke policy componenten kunnen wel degelijk een belangrijke en nuttige rol vervullen in onze architecturen. Maar dan wel in de vorm van services, binnen het netwerk van service componenten waarbinnen de juiste toepassing van bedrijfscentrische architectuur techniek en business op de juiste manier los van elkaar koppelt (maar niet in lagen!). Weg met de lagen. Er is niet veel verschil tussen spaghetti en lasagne: als we het te lang koken wordt het allebei pap.

Computable.nl | Strategie | Strategie | Outsourcing ondoordacht

In dit interview breekt Roel Pieper, of hij het bewust doet of niet, een lans voor Domain Driven Design. Het artikel koppelt zijn verhaal aan outsourcing, hoewel dat denk ik niet erg het hoofdthema was van zijn praatje op het Adobe congres waar het artikel over verslaat. "Zijn boodschap: stel de klant centraal. ... Want elk bedrijfsproces zou moeten beginnen met de klant en moeten eindigen met de klant.” In veel domeingedreven artikelen wordt hiervan gerept. Niet alleen in de business, waar dit idee goed geaccepteerd is, maar ook in de techniek moet de klant centraal staan. Men grijpt echter met de handen in het haar. Hoe moeten we dit in de techniek realiseren? In wanhoop (en wat mij betreft: vergeefs, maar daarover in dit artikel even niet) grijpt men naar vormen van business process management (BPM), vooral omdat er op een obscure manier een relatie wordt gelegd door de arme zielen die dit probleem op moeten lossen tussen bedrijfsprocessen en applicatielogica. Die twee hebben in de praktijk niets maar dan ook helemaal niets met elkaar te maken, waardoor de prins op het witte paard (BPM) een apocalyptische ruiter blijkt te zijn.

"Een dergelijke aanpak betekent dat een organisatie moet uitgaan van een bedrijfsgedreven architectuur in plaats van de huidige it-gestuurde architectuur."

Weliswaar niet de huidige term domain driven, maar zoals lezers van mijn andere artikelen misschien weten vind ik bedrijfsgedreven architectuur een term die de lading beter dekt, waarbij domain driven design een aspect daarvan is. Ik gebruik de term bedrijfscentrisch, omdat daarin ook de structuur van de architectuur (en niet alleen, zoals -gedreven suggereert, het proces van het totstandkomen van die architectuur) terug komt.

De relatie tussen de klant centraal stellen, en daardoor in staat zijn de complexe veelheid van bedrijfsprocessen veel eenvoudiger te kunnen modelleren wordt direct gesuggereerd in het artikel. Iets waar we veel meer de aandacht op zouden moeten vestigen.

In response to reading Alan’s blog » the power of sequential thinking, and especially the following citation: “Computers are sequential” he said, “brains are associative”.There is a common misconception about computers in that they are akin to machines. In a way this is not completely a misconception. Most people, not in the least software engineers, employ the sequential thinking mode in dealing with computers. This is the cause of much grief. But computers, and especially the essence of this invention, are anything but sequential. I would argue that the invention of the modern computer coincides with the end of the era of sequential thought. In fact this move to another thinking mode is one we should endeavor to utilise in order to move the area of computer science further. In another article I was struck by a discussion about “gifted” children. Increasingly children who are perceived as highly intelligent fail to do well on our schools: To teachers they often appear to be bright children who could do better if only they would concentrate more, focus more, not be so destructible and try harder. (Visual Thinking) Parents and others jump on this as a sign that their children are somehow “different” and of course they favour the opinion that their children are “super intelligent”. I beg to differ. I think it is important we start to recognise the problem as quite different, namely that these children are an example of a move from sequential thinking to non-sequential thinking. There may be a difference in intelligence, and it may very well be that more-than-average intelligent children are moving into this non-sequential thinking mode earlier, but the solution is not to create another elitist solution but to recognise that we are, as a society, making a fundamental move to different modes of thinking, or indeed, different modes of intelligence. The old ways to assess intelligence with people have always irritated me. IQ testing was so entwined within cultural biases as to be almost unusable outside these cultural boundaries. But the problem is quite acute with our educational institutions because there seems to be a growing discontent both with teachers and pupils, and not enough help or guidelines to make the move to a different schooling system. Our current educational system is problematic, the end of an era that started with the period of the Enlightenment requires a fundamental change.wing discontent both with teachers and pupils, and not enough help or guidelines to make the move to a different schooling system. Our current educational system is problematic, the end of an era that started with the period of the Enlightenment requires a fundamental change.

Computable.nl | Strategie | Strategie | SOA versnelt aanvraag uitkering

Dat Service Orientatie hét buzzword van het moment is, hebben we wel begrepen. Maar wat er telkens weer gebeurt wanneer er sprake is van een buzzword, is dat volstrekt niets met het onderwerp te maken hebbende ontwikkelingen onder de noemer van het buzzword worden geschaard. Dat is bij alle hypes van de afgelopen jaren gebeurd, en vanuit commercieel oogpunt ook wel te begrijpen al kan ik het niet goedkeuren. De zegspersoon van Everett, de IT club die bij CWI, UWV en gemeenten een "SOA architectuur" heeft neergelegd, maakt gebruik van alle politiek correcte statements over SOA:

1. een servicegeoriënteerde architectuur vooral handig als er nauw samengewerkt wordt met andere organisaties
2. De it en business moeten samen nadenken over de diensten die ze willen aanbieden. Dat vergt een bepaalde soort van levensstijl
3. Als een organisatie de voordelen van een servicegeoriënteerde architectuur goed wil benutten, is het verstandig om goed over de achterliggende architectuur na te denken.
4. Het opnieuw hergebruiken van diensten is immers een van de kenmerken van een servicegeoriënteerde architectuur.

Maar juist de context waarbinnen deze kreten worden geplaatst maakt duidelijk dat we het hier nog lang niet, en misschien zelfs helemaal niet, over een service gerichte architectuur hebben. Laten we opnieuw eens naar de kreten kijken. De eerste blijkt dan een probleem te detecteren waarvoor de Haarlemmerolie SOA een oplossing moet zijn, namelijk het ontsluiten via verschillende kanalen van gegevens. De tweede heeft vooral betrekking op een probleem waar Everett tegenaan gelopen zal zijn, namelijk dat een zogenaamde service toch wat minder herbruikbaar blijkt te zijn dan de belofte was, en dat een andere dienst of bedrijfsonderdeel die service niet kan gebruiken. Een service die door maar één onderdeel gebruikt wordt is niet wat we willen, hergebruik van diensten is immers één van de selling points. Dat er over nagedacht moet worden is evident, maar uit de context lijken toch vooral de verschillende kanalen een probleem te zijn. We bespeuren een dienstendefinitie die vooral gegevens moet uitwisselen, en niet of nauwelijks raakt aan bedrijfsprocessen. De derde constatering sluit hier eigenlijk bij aan. We hebben het over kanalen: “Je wilt dezelfde dienst snel kunnen ontsluiten in een ander kanaal.” Hoezo dienst? Het gaat hier over gegevens die via web, intranet, en misschien email of telefoon geleverd moeten worden. Punt 4 moet een gepokte en gemazelde verkoper van hypes altijd even noemen. We worden er ondertussen een beetje moe van want we roepen het bij elke hype weer, en telkens weer blijkt met name deze belofte het eerste te sneuvelen in de strijd in de loopgraven. Maar waarover heeft de goede man het eigenlijk? Over gegevensdefinities die in verschillende onderdelen van de organisatie niet op één lijn zitten! En: “Dat heeft wat historie. Daar zijn we tien jaar geleden mee begonnen om de gegevens te ontsluiten en daar plukken we nu nog de vruchten van”. Pardon? Al tien jaar bezig gegevensdefinities op één lijn te krijgen, en dat begint nu al wat op te leveren? De benadering die bij deze vorm van SOA wordt gevolgd is een hopeloze. Het zal nooit gebeuren dat er de vruchten van geplukt gaan worden. Het vanuit het gegevensperspectief proberen op te lossen is een eindeloze weg van consensus proberen te bereiken, grutten in databases, modderen met BI tools en eindeloze trajecten om management rapportages boven water te krijgen. SOA moet een andere benadering krijgen, die hier zeker niet toegepast lijkt. Vanuit de bedrijfsprocessen, dicht tegen en gesteund door het strategisch management, in een intiemere relatie tussen IT en business. Want bij de volgende hype twijfel ik er niet aan dat bij dit project de voordelen nog niet geoogst zijn, en men met een nieuwe hype en een nieuwe IT leverancier weer opnieuw aan het werk moet.

Vanaf de start van mijn huidige professionele carrière heb ik gewerkt voor organisaties die direct of indirect betrokken waren bij innovatie. Ik heb twaalf jaren gewerkt voor CIBIT, waarvan de naam een afkorting is van Centrum voor Innovatie van Bedrijfsprocessen door Informatie Technologie. Zelfs toen ik nog op de universiteit werkte was het cluster waartoe ik behoorde bij de Faculteit Bedrijfskunde van de Universiteit van Groningen het cluster Innovatie.

U kunt zich voorstellen dat ik heel wat gesproken heb over innovatie met allerlei klanten!