Mijn voorspellingen voor 2010

Voorspellingen zijn vooral leuk om achteraf terug te lezen. Wat hield ons een jaar geleden bezig? Hoe dachten we toen over 2009? Is daarin veel veranderd?

Als ik mijn voorspellingen voor 2009 nu herlees, dan waren die eigenlijk zo gek nog niet. Drie van de vijf spot on, twee van de vijf hebben nog wat meer tijd nodig. In deze post geef ik een actualisatie van alle vijf voorspellingen.

Voorspelling 1: Google Chrome komt langzaam op stoom
Vorig jaar voorspelde ik: “Google komt in 2009 met een eigen web-OS”. Google heeft in 2009 inderdaad een eigen OS aangekondigd, inderdaad voor webapplicaties. Volgens de berichten start Google's Chrome OS op een goedkope netbook al in 7 seconden op. Dat mag je toch best snel noemen!

Er is op dit moment nog geen release datum bekend gemaakt. Toch verwacht ik in 2010 al de eerste berichten van bedrijven die duizenden dollars per werkplek besparen door de dure Windows PC's te vervangen door goedkope webtops. Wees eerlijk. De gemiddelde medewerker kan inmiddels prima uit de voeten met webapplicaties. Met HTML 5 worden de mogelijkheden om rijke webclients te maken alleen maar groter. Er gaat op het web al een gerucht rond dat zelfs iTunes binnenkort een webapplicatie gaat worden. Als je nu voor je bedrijf met een schone lei zou kunnen beginnen, dan zou dat toch een erg aanlokkelijk perspectief zijn?

Naast de berichten over besparingen met webtops kunnen we ons ook opmaken voor de nodige horror-stories over de migratie naar Windows 7. Natuurlijk gaat dat veel bedrijven veel meer kosten dan geraamd en veel minder opleveren dan gehoopt. Ga maar na hoe lastig het nu voor veel bedrijven al is om afscheid te nemen van IE6. En het oplossen van de migratieproblemen is tot op zekere hoogte alleen maar symptoombestrijding. Over een paar jaar kunnen we het volgende migratieprobleem al weer op de agenda zetten. Er is immers niets fundamenteel veranderd aan het besturingsmodel van Microsoft! Dat kan zo maar een extra impuls zijn om serieus na te denken over een alternatief dat radicaal breekt met het verleden. Een alternatief dat optimaal gebruik maakt van de technologie van de 21ste eeuw. Een alternatief dat flexibiliteit en beheerbaarheid heeft ingebouwd in de architectuur. Een alternatief dat de inrichting en het beheer van werkplekken zo simpel maakt dat er gewoonweg niets meer out te sourcen valt. Welke CIO zou daar niet serieus over na willen denken?

Natuurlijk, veel bedrijven zullen niet 1-2-3 in staat zijn om al hun Windows applicaties te vervangen door webapplicaties. Maar het zou kunnen dat er voor het eerst sinds de teloorgang van OS/2 een reëel alternatief komt voor het inrichten van werkplekken. Het wordt spannend wat de strategische reactie van Microsoft wordt. Ze zullen toch íets moeten doen om te voorkomen dat alle Windows desktopapplicaties als legacy bestempeld gaan worden?

Voorspelling 2: Het web wordt in 2010 geleidelijk persoonlijker

Mijn voorspelling van vorig jaar was: Het web wordt in 2009 alweer opnieuw uitgevonden. Daar ben ik toch duidelijk wat te optimistisch geweest. Het heruitvinden van het web, met de gebruiker in plaats van de website als centrum, loopt nog niet zo'n vaart. Natuurlijk, je kunt je Tweets automatisch publiceren op je LinkedIn account, net zoals je met een paar klikken een YouTube filmpje aan je Facebook pagina kunt toevoegen. Erg handig voor producenten van webcontent. Maar de consument van al die informatie komt er vooralsnog bekaaid af. Het slim filteren en (her)structureren van feeds uit verschillende bronnen op basis van de voorkeuren van de consument kan technisch toch niet zo'n opgave zijn? Het zal mij benieuwen of die “persoonlijke digitale werkruimte”, zoals Daan Rijsenbrij dat zo beeldend noemt, er in 2010 wel gaat komen, of dat daar nog wat meer tijd voor nodig zal zijn.

Mijn tip: als je nog op zoek bent naar een goed idee voor een killer-applicatie bij de introductie van Chrome OS, die vast wel een eigen appstore krijgt, denk dan eens in deze richting.

Voorspelling 3: Architecten maken school

De voorspelling dat we “ook in 2009 vrolijk door [blijven] discussiëren over de rol van architecten” was een makkelijke. Op het afgelopen LAC heeft Ron Tolido ons vakgebied uitgeroepen tot het meest introspectieve ter wereld. Een twijfelachtige eer.

Meer en meer vakbroeders zijn het discussiëren zat. De toegevoegde waarde van het vak moet zich tenslotte in de praktijk bewijzen. Dat kan op heel verschillende manieren. Bijvoorbeeld door een architectencollectief te vormen rond een gezamenlijke methodiek – zeg TOGAF. Dat biedt een gemeenschappelijk kader en geeft daardoor de nodige houvast. De TOGAF certificering biedt al een basis om de krachten te gaan bundelen.

Het zou ook kunnen door de krachten te bundelen rondom een gemeenschappelijke archITectuurstijl. Bij SOA zie je dat in het buitenland al gebeuren.Kijk bijvoorbeeld maar eens naar Zapthink. Handig als er archITecten zijn die alles weten van de verschillende SOA platformen en weten hoe je ontwerpproblemen moet tackelen. Toch?

Een andere mogelijkheid is het specialiseren op een technologiedomein. Zoiets als Oracle Fusion architecten, voor al uw ERP implementaties. ArchITecten zonder gedegen materiaalkennis hebben tenslotte een handicap. Een moderne variant vinden we in de cloud. Die is niet speciaal voor archITecten met hun hoofd in de wolken, in tegendeel. De cloud biedt meer en meer instant oplossingen voor deelproblemen. Door als archITect de passende uit te kiezen er daarop voort te bouwen kan een slimme middenweg tussen pakketoplossingen en maatwerk worden gevonden. Denk maar eens hoeveel een gemiddeld bedrijf kan besparen door zijn test- en uitwijkomgevingen over te brengen naar EC2. Of hoeveel de time-to-market verkort kan worden door Siebel on Demand in te zetten. Liever open Source? Geen probleem! Nog meer ideeën? Bedien je eens van een StrijkIJzer of breng een bezoek aan SaaS Plaza voor een vliegende start van je projecten.

Oh ja, je hebt ook nog de archITecten die zich specialiseren op het gebied van business preventie. Vakgenoten die het als hun missie zien om alle vernieuwing tegen te houden die niet past bij de archITectuurprincipes en technologiekeuzes die ooit zijn gemaakt. Architecten die compliance als doel op zich zijn gaan zien. ArchITecten met een politiepet op die hun toegevoegde waarde terugzien in zelfbedachte KPI's. In het gunstigste geval, tenminste.

De diversiteit van de beroepsgroep staat er borg voor dat die verschillende manieren zich voorlopig naast elkaar ontwikkelen. En het zou mij niets verbazen als de meest succesvolle groepen met hun eigen manier van werken op basis van hun prestaties al in 2010 school gaan maken. Of zou de wens de enige vader van die gedachte zijn?

Voorspelling 4: De opkomst van Infofluence

Aan de opkomst van Infofluence die ik vorig jaar voorspelde, heb ik eigenlijk niet zoveel toe te voegen. Ik zie het in Nederland nog niet zo gebeuren. De gevestigde kabelmaatschappijen lijken er nog steeds alles aan te doen om hun imago van incompetente, klantonvriendelijke geldkloppers te bevestigen (persoonlijke ervaring). Kassa en Radar hebben het er maar druk mee. En de imagoverbetering van verzekeraars en banken is in 2009 ook nog niet echt succesvol te noemen.

Toch waren er in 2009 wel de nodige lichtpuntjes. Zo was er bijvoorbeeld CommOnline 2009, het ‘eerste grote event op het gebied van online communicatie voor communicatieprofessionals’. En kent u de
afkorting WWGD al? Jeff Jarvis geeft in zijn boek “What would Google Do?” perfect aan wat ik bedoel met infofluence. Het stemt mij optimistisch dat sommigen dat afdoen als oud nieuws. Bedrijven zoals Zilveren Kruis hebben inmiddels ontdekt dat het slim is om zo snel mogelijk te reageren als iemand een klacht uit via Twitter. Zoiets haalt de massamedia niet onmiddellijk, maar dat geldt net zo goed voor de sluimerende onvrede bij klanten. En beiden vertalen zich ondertussen wel in klantloyaliteit.

Misschien is het probleem wel dat we in Nederland nog geen Dell-affaire hebben gehad. Een bedrijf dat niet alleen langdurig in de vuurlinie van de negatieve publiciteit lag, zoals bijvoorbeeld UPC ook is overkomen, maar dit ook keihard merkte in snel krimpend marktaandeel. Zoiets zou het bedrijfsimago in de digitale wereld bij veel meer bedrijven op de managementagenda kunnen zetten. Blijf ondertussen vooral veel klagen, want dat geeft bedrijven tenminste een eerlijke kans om heel klantgericht te reageren.

Voorspelling 5: Context is king

Ik weet niet hoe het met u is, maar voor mij geldt in elk geval dat ik me in 2009 suf gewerkt heb om alle interessante artikelen, boeken en podcasts een beetje te volgen. Zozeer dat ik nauwelijks meer toekom aan het bouwen aan mijn eigen merk. De voorspelling “het netwerk is de professional”, met de trend van personal branding als belangrijkste exponent, zet duidelijk door. Het is ook steevast één van de adviezen die professionals in een outplacement traject of bij een sollicitatietraining meekrijgen. Tegenwoordig is de eerste indruk die je maakt op een nieuwe werk- of opdrachtgever immers bijna altijd in de virtuele wereld. Zou je zelf een onbekende sollicitant of ZZP-er oproepen voor een kennismakingsgesprek als hij of zij geen gekwalificeerde indruk weet te wekken op het web? Als je profiel op LinkedIn niet is bijgewerkt, gaten vertoont, een foto van een huisdier laat zien, wrevel opwekt, dan krijg je dus normaal gesproken geen kans om een tweede indruk te maken. Dat zal in het komende decennium alleen maar sterker worden.

Mijn eigen merk, ContextAware, is in 2009 gelanceerd. Het is een echt opbouwjaar geweest. Zo langzamerhand begint de boodschap al een beetje door te dringen. Context was op het afgelopen LAC één van de sleutelbegrippen. Bijdetijdse data-architecten waren daarvanal langer doordrongen, denk maar aan de opkomst van het semantische web, maar het dringt nu ook door in de wereld van software architectuur. De professionele toekomstvoorspellers van Gartner kondigden onlangs aan dat we aan de vooravond staan van het CoDA tijdperk. En daar sluit ik mij natuurlijk van harte bij aan.

De Wave

We waren al enkele jaren bekend met de Google Dance. Nu heeft Google ook de Wave ingezet. De dienst is nog volop in ontwikkeling, maar werd desondanks op 29 mei 2009 alvast ten doop gehouden op de Google I/O conferentie in San Francisco. Tijdens en vlak na deze conferentie werd de aankondiging alvast met bijzonder veel enthousiasme ontvangen. Is dat terecht?

Convergentie

Google Wave is nieuwe benadering van informatie management. Het is lastig om in woorden uit te leggen waar het precies om draait. Wat dat betreft doet het mij denken aan de begindagen van Lotus Notes, waarbij het erg lastig bleek om aan mensen die het systeem niet gebruikten uit te leggen wat de kracht was van “Collaboration, Cooperation and Communication” met behulp van een computer. Het is vaker gezegd dat Ray Ozzie zijn tijd toen al ver vooruit was. Het lijkt mij dat de ontwerpers van Google Wave wel heel goed begrepen hebben wat hij destijds propageerde.

Google Wave draait allemaal om “projecten” waarin één of meerdere mensen werken aan een centraal beheerd “document”. Dit document is voor alle participanten in het project online toegankelijk via een browser. Daarbij kan iedereen aan een verschillend onderdeel werken, maar het is ook mogelijk om elkaar aan te vullen, te corrigeren of te becommentariëren. Op die manier zijn de documenten ook geschikt voor het voeren van discussies.

De bedenkers Jens en zijn broer Lars Rasmussen, de meesterbreinen achter het nu al legendarische Google Maps, noemen 'hun' Google Wave "hoe email zou zijn als het vandaag zou worden uitgevonden.". Dat is ook precies het startpunt van Wave geweest. Email wordt vandaag de dag veelvuldig gebruikt voor het voeren van discussies, maar de interessante discussies hebben de natuurlijke neiging om ondoorzichtig te worden. Niet iedereen krijgt alle bijdragen aan de discussie te zien, vaak lopen er meerdere onderwerpen door elkaar heen en het de mogelijkheden om teksten te redigeren nadat ze eenmaal zijn verzonden zijn hoogstens erg beperkt. Als je erover nadenkt is het best verbazingwekkend dat email als communicatiemiddel al zo lang zo populair is...

De broertjes Rasmussen hebben er heel diep over nagedacht en hebben een oplossing bedacht die aan alle bezwaren tegemoet komt. Een nieuw concept voor elektronische communicatie. En al doende hebben ze mogelijkheden gecreëerd die veel verder gaan dan het vervangen van email alleen. In de presentatie geven ze als voorbeeld het plannen van een teamuitje. Dat begint natuurlijk met het vaststellen van een datum, het bepalen van een activiteit en het discussiëren over de lijst met genodigden. Daar heeft iedereen zo zijn ideeën over. In Wave is het gemakkelijk om met z'n allen een discussie te voeren die eigenlijk over drie thema's tegelijk gaat. En als kers op de cake kun je na afloop ook nog je foto's toevoegen – en niet te vergeten elkaars foto's van commentaar voorzien. Het geheel is wat in wave termen een project is.

Je hebt er niet zo heel veel fantasie voor nodig om te bedenken dat je ook een wave-project zou kunnen maken van een vergadering, of een beleidsvoorstel; een architectuurprincipe of een project-start architectuur. En nog veel meer. Op die manier zou wave wel eens veel meer kunnen vervangen dan email alleen, bijvoorbeeld Instant Messaging, Blogs, Wiki's en dergelijke. Zeker als je binnenkort met iedere zakelijke telefoon gewoon mee kunt waven (dat werkwoord zal dan ook wel ingang vinden).

Google presenteert Wave als een product, een platform en een protocol. Met een vette knipoog hebben ze het over de drie P's. De Rasmussens weten als geen ander hoe belangrijk het is voor een brede acceptatie om zo veel mogelijk ontwikkelaars bij het concept te betrekken. Daarom hebben ze aangekondigd dat het hele product als open source gepubliceerd zal worden en dat iedereen zijn eigen toepassingen erop kan ontwikkelen. As from now. Ze hopen er natuurlijk op dat als het systeem over een poosje gelanceerd zal worden, dat er van meet af aan een rijk aanbod aan gewilde applicaties zal zijn. Misschien moeten we naar analogie van de Apple AppStore wel denken aan een Google AppStore.

Wave biedt nog een paar opmerkelijke features. Zo is het niet alleen mogelijk om met meerdere mensen aan een document te werken, je kunt ook gelijktijdig in hetzelfde document werken. Tijdens de demo werd getoond dat vier mensen tegelijkertijd op dezelfde pagina aan het werk waren. En alle wijzigingen werden op het oog zonder enige vertraging uitgewisseld, zodat iedereen op ieder moment dezelfde informatie op zijn scherm zag. Daarbij zou het mogelijk zijn dat verschillende deelnemers bij een verschillende organisatie werkzaam zijn en via hun eigen Google Wave server werken. Het maakte zelfs niet uit dat de ene werkte met Google's eigen Chrome, terwijl anderen met Mozilla Firefox en Apple Safari meededen. Merk op dat er in deze lijst één grote partij afwezig is. Hoe zat het ook alweer met MSIE en de ondersteuning van nieuwe webstandaarden?

Overigens werd er binnen het ontwikkelteam nog volop gediscussieerd over de wenselijkheid van het zonder enige vertraging mee kunnen kijken met het typewerk van collega's. Je kunt namelijk iedere toetsaanslag, dus ook iedere correctie, volgen. En wie heeft er van tijd tot tijd geen behoefte aan het bijschaven van een impulsief geschreven emailtje alvorens het te versturen? Om ons bij voorbaat gerust te stellen is er alvast een optie opgenomen om deze real-time functionaliteit uit te schakelen (maar deze optie is nog niet geïmplementeerd).

Wat trouwens ook indruk maakt is de ingebouwde spelling- en grammaticacontrole. Zo rijk heb ik dat in een webapplicatie nog niet eerder gezien. En wat ook niet onvermeld mag blijven is dat je in je wave bibliotheek kunt zoeken – pardon: googelen. Tada!

Een andere mooie feature is de history trail. Er gaat bij wijzigingen namelijk geen informatie verloren. Je kunt met de ingebouwde playback functie te allen tijde reproduceren hoe en door wie een tekstfragment in de loop van de tijd tot stand is gekomen. Zonder dat je er ook maar iets speciaals voor hoeft te doen. Wie heeft er dan nog behoefte aan een aparte omgeving voor versiebeheer?

Wat de demo vooral ook laat zien is dat Rich User Interfaces met de nieuwe versie 5.0 van HTML prima in een browser kunnen draaien. En dat online gegevens uitwisselen tussen verschillende browsersessies ook bloedsnel kan zijn. Volgens de demo blijft die snelheid zelfs in stand bij het gebruik van automatische simultaan vertaling, een hele coole feature die het mogelijk moet maken dat verschillende gebruikers dwars door de taalbarrière gewoon samenwerken. Ik moet hierbij wel aantekenen dat één strak georchestreerde demo mijn scepsis over deze functie nog niet helemaal heeft weggenomen. Aan de andere kant moet ik meteen ook bekennen dat Google in het verleden wel vaker mijn aanvankelijke scepsis glorieus heeft weten te overwinnen.

De potentie

Dat Google Waves de potentie heeft om de wereld van de software ontwikkeling flink op te schudden leidt geen twijfel. Denk maar eens mee wat er allemaal verwaved zou kunnen worden.

1. Office.wave. Die is bijna triviaal. Documenten bestaan uit stukken tekst, plaatjes, tabellen, grafieken en nog zo wat bouwstenen. Misschien in de toekomst wel beeld en geluid. Samenwerken aan documenten is een lang gekoesterde wens, zeker als het plaats en tijdonafhankelijk kan. Het zou mij niets verbazen als er bij Google nu al wordt gewerkt aan een variant van OpenOffice op het Waves platform. Dat lijkt mij in elk geval een typsiche killer-wave.

2. Wave zou ook heel goed kunnen dienen als fundament voor een ontwikkelomgeving voor software. Waarom niet? Goed beschouwd zijn dit ook allemaal verschillende bouwstenen die samen de bron vormen voor een applicatie. Samenwerken en versiebeheer zijn typische kernfuncties. En dat wordt alleen maar sterker naarmate we systemen krijgen met flexibiliteit die dicht bij de eindgebruiker gewijzigd kan worden – denk aan business rules, business processen, productmodellen enzo. In zekere zin hebben we dan een in tijd en plaats gedistribueerd ontwikkelteam.

3. Met Wave kunnen we ook op een hele nieuwe manier gaan nadenken over Workflow Management. Samenwerken hoeven we niet meer als een estafette van taken te ontwerpen, nee, we kunnen tegelijkertijd samen aan hetzelfde dossier werken. Business Process Improvement 2.0?

4. Misschien wat verder gezocht, maar wat zou er mogelijk worden als je een zou nadenken over een Electronisch Patienten Dossier (EPD) op basis van Wave? Natuurlijk moet je goed nadenken over wie eigenaar is van welke wave in het dossier en dus kan beslissen wie er toegang toe heeft en wie niet. Maar het idee dat het EPD leeft in de cloud, voor iedereen met toegang altijd en overal beschikbaar kan zijn, dat je er snel dingen in terug kunt vinden; het idee dat het platform een wereldstandaard is, dat moet toch een golf aan innovatie op kunnen leveren?

5. Nog iets generieker geformuleerd, Google Wave lijkt ideaal voor het ontwikkelen van dossierapplicaties, waarbij verschillende mensen toegang hebben en bijdragen leveren aan een informatiebron – zeker als die mensen niet per definitie binnen eenzelfde organisatie werken. Dit soort applicaties heeft nog niet de grote vlucht genomen die door denkers als Don Tapscott al lang geleden is voorspeld. Wellicht is de tijd nu wel rijp.

Om over te peinzen

In de blogosfeer heet Google Wave vooral een bedreiging voor de dominante positie van Microsoft Sharepoint te zijn. Daar kan ik me veel bij voorstellen. Maar voor mij is het meer dan dat. Google Wave volgt een heel ander paradigma dan Sharepoint. Samenwerken in Wave is geen additionele feature op een document dat door iemand is geschreven, het document is het resultaat van een real-time samenwerking tussen mensen. Het zal wel even duren voordat de potentie van dat nieuwe paradigma doordringt tot de mainstream gebruikers.

Ik heb op mijn radarscherm een prominente plaats gereserveerd voor de Wave. Het zou mij niets verbazen als Google – ondanks dat het niet enterprisefaehig heet te zijn – hiermee voor de komende jaren de toon voor de ontwikkelingen in de wereld van softwarearchitectuur heeft gezet. Het is maar de vraag of de reus uit Redmond hierop een passend antwoord heeft. En van wie anders valt er een tegenzet te verwachten?

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 12^de in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

Wining & dining

Van tijd tot tijd laait het debat op over de superioriteit van legacy software. Recentelijk heeft Wouter Keller deze discussie weer eens aangesneden op Via Nova Architectura. In zijn bijdrage stelt hij “politiekcorrecte technologie” tegenover “bestaande oplossingen die zich bewezen hebben in de praktijk”. En, het laat zich raden, hij stelt dat techniek “een van de belangrijkste faalfactoren is bij ICT-trajecten”. Mijn bijdrage aan dit debat beoogt dit beeld enigszins te nuanceren.

De Kwestie

De discussie over de zin en onzin van het gebruik van nieuwe technologie is zo oud als de IT-sector zelf. Er zijn vast nog schrijvers te vinden die de voorkeur geven aan het gebruik van een typemachine boven een PC. Toch is het een hele poos geleden dat ik voor het laatst over een typekamer liep. Het moet ongeveer in dezelfde tijd geweest zijn dat er een hevige discussie werd gevoerd over het gebruik van compilers voor tijdkritische processen. Er ging tenslotte niets boven ambachtelijke assemblercode.

Sindsdien heb ik opmerkelijk soortgelijke argumenten pro en contra nog diverse malen horen langskomen. Bijvoorbeeld bij de overgang van tekstgeoriënteerde schermen naar GUI's, de migratie naar relationele databases, bij de invoering van Client/Server technologie, bij de adoptie van webgebaseerde user interfaces en – last but not least – bij het gebruik van CBD en SOA. Telkens als het tegenzit, zoals bij organisaties die momenteel worstelen met opschaling van SOA, dan zijn de doodgewaande dino's er als de kippen bij om te betogen dat al die moderniteit in de praktijk alleen maar problemen oplevert en dat het vroeger allemaal beter was. Legacy is voor de één een haast onuitroeibaar onkruid, terwijl de ander trots is op het stoere, robuuste karakter ervan. Herkenbaar?

Er is een keur aan wijnen op de markt. Van jong tot oud, van soepel tot geraffineerd. Belegen wijn is jarenlang vertroeteld, de besten op nieuw eikenhout, voor een smaakvol en complex resultaat. Wie van zulke wijnen houdt, en dat zijn er velen, hecht aan oude tradities en is bereid om een stevige prijs te betalen. De pleitbezorgers van legacy software kunnen hier zeker moed uit putten.

Iedere levensgenieter weet dat wijn de kroon is op een goede maaltijd. Echter, niet iedere wijn past bij elk gerecht. Het echte succes zit in de combinatie. Zoals een witlofschotel baat heeft bij een Chileense Carmenère, een Australische Syrah heel goed past bij een Hongaarse goulash en een Kaapse Riesling een betoverend oesterwatertje is. En omgekeerd moet ik niet denken aan een mooie Sancerre met Hollandse Nieuwe, of een onvolprezen Barolo met erwtensoep. Yeck.

Een goede wijn kan een goede maaltijd tot een belevenis maken – mits goed gecombineerd. Een slechte wijn, of een slecht gecombineerde wijn kan een prima maaltijd behoorlijk bederven. En, jammer maar helaas, een goede wijn kan een slecht maal niet redden – tenzij je er misschien heel veel van drinkt (maar ook daar krijg je later spijt van).

Iets soortgelijks geldt voor archITectuurkeuzes. Er zijn boeken volgeschreven over succesvolle combinaties, patterns, maar hoed u voor het toepassen van goede technologie die niet past bij het probleem dat opgelost moet worden. Verwacht ook niet dat goede architectuur een slecht project kan redden. Dat levert hoogstens een kater op.

Weerwoord

ArchITecten worden verantwoordelijk gehouden voor architectuurkeuzes. Dat is een complexere en verantwoordelijkere taak dan sommigen zich lijken te realiseren. Zij hebben de neiging om slaafs de voorgeschreven referentiearchitectuur te volgen, of om juist vast te houden aan de vertrouwde keuzes uit het verleden. Beide vormen van jumping to solutions miskennen de echte waarde van (werken onder) archITectuur. Goede archITectuurkeuzes zijn geen sinecure! Het is een vak, dat veel studie vereist – al is het maar om de ontwikkelingen in de technologie en de ervaringen ermee nauwgezet te volgen. Een sommelier moet tenslotte ook blijven bijleren over de nieuwe jaargangen en de opkomende wijngebieden om bij te blijven in zijn vak.

Als projecten niet lukken, dan is de gebruikte technologie een dankbare zondebok. Het projectteam treft dan tenminste geen blaam, want de leverancier heeft de feiten anders voorgespiegeld, zo redeneert men. In de realiteit mislukken er maar weinig projecten door slechte technologie. Als je achteraf eerlijk analyseert wat er is misgegaan, dan blijkt het veel vaker te liggen aan verkeerde technologiekeuzes (erwtensoep met Barolo). En daarbij is het zeker niet zo dat het altijd ligt aan het kiezen van eigentijdse architectuur voor ouderwetse problemen; het kiezen van bewezen architectuur voor moderne problemen is een minstens even grote valkuil.

Een minder vaak belicht aspect is de neiging tot het schromelijk onderschatten van de consequenties van modernisering. Het is één ding om een – laten we zeggen – Progress ontwikkelaar naar een .Net cursus te sturen om te leren om webapplicaties te bouwen. Maar daarmee heb je nog niet de competentie in huis om self-service applicaties te kunnen ontwerpen of om websites professioneel te hosten. Net zo min levert het ontwikkelen van herbruikbare services een bijdrage aan het oplossen van het governance probleem. Gert Florijn heeft daarover laatst een behartenswaardig interview gegeven in het blad “service oriented architecture” [1]. Het zou archITecten naar mijn mening sieren als zij de verantwoordelijkheid zouden nemen om dit soort zaken vroegtijdig te signaleren

En ja, ook ik kom in mijn adviespraktijk projecten tegen die gewoon gefaald zijn door een slechte besturing. Eigenlijk is het onderschatten van de consequenties van veranderingen daar ook een vorm van. Want die consequenties hadden doorgaans best vooraf voorspeld kunnen worden. Het is en blijft kennelijk verschrikkelijk moeilijk om te leren van fouten van anderen. Jammer is dat.

Er moet mij nog één ding van het hart. Er wordt soms met wat dedain geschreven over het gebruik van moderne technologie als uit de hand gelopen hobby van de nerds uit de pizzakelder. Ik vind het volkomen legitiem om het ontwikkelen van nieuwe competenties als prominent nevendoel voor een project op te voeren, zo lang die nieuwe competenties maar stevig zijn ingebed in de strategie van de organisatie. Daarom is het juist zo belangrijk dat archITecten zijn aangehaakt bij de strategische dialoog.

Om nog één keer terug te grijpen op de metafoor van de wijn: ook hier geldt dat een wijn, hoe goed hij ook is opgevoed, na verloop van jaren over zijn hoogtepunt heen is. Dan gaat hij onverbiddelijk alleen nog maar achteruit. Zo is het ook met technologie. Eerst groeit het gebruik minder hard dan de markt, dan groeit het helemaal niet meer en daarna krimpt het marktaandeel alleen nog maar. Voor leveranciers is dat het signaal om de investeringen anders in te gaan zetten. Medewerkers die nog een carrière voor zich hebben, raken ook minder bereid om hun tijd en energie te investeren in oude technologie. En tegen de tijd dat zoiets zich aan het voltrekken is, dan kun je maar beter een alternatief achter de hand hebben.

Als je als organisatie het lef niet hebt om te investeren in de toekomst, dan moet je ook niet gek opkijken als het slecht met je afloopt. Daar kunnen de vele geoutsourcede IT-afdelingen inmiddels over meepraten.

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 17de in een reeks die op dit weblog gepubliceerd zal worden.

[1] Dré de Man: “Struikelend hardlopen”. Service oriented architecture, mei 2009, p. 6.

Het hoogst haalbare

Er zijn architecten die zich nadrukkelijk weten te onderscheiden van het gemiddelde. Opvallende persoonlijkheden die ‘anders-dan-anderen’ zijn. Zo iemand is Richard Meier – in Nederland vooral bekend als architect van het Haagse gemeentehuis. Eén van zijn handelswijzen die bij mij altijd is blijven hangen is zijn haast koppige doorzettingsvermogen.

De Kwestie

Het oorspronkelijke ontwerp voor het Haagse gemeentehuis was volgens vriend en vijand baanbrekend. De meeslepende manier waarop hij het plan presenteerde! Iedereen die erover mocht beslissen was er vrijwel meteen laaiend enthousiast over. Hij had als geen ander aangevoeld wat er op die plek in de stad mogelijk was. Een gebouw dat de ambtenaren en ook de burgers een warm thuisgevoel zou bieden. Er was maar één probleem. Het was volgens de overheidsnormen te duur. Veel te duur. Niet haalbaar. Het moest wel versoberd worden.

Er zou ofwel bezuinigd moeten worden op de omvang van het complex, ofwel op de kwaliteit van de uitvoering. Dat kon niet anders. Dat zou tenminste de logische reactie zijn geweest van bijna iedere architect. En anders zou de gemiddelde opdrachtgever hem die les wel leren. De opdrachtgever bepaalt het budget, en de architect accepteert dat als randvoorwaarde waarbinnen hij moet werken. Samen met zijn opdrachtgever bepaalt hij het maximum haalbare binnen het toegestane budget. Zo gaat dat.

Bij de charismatische Richard Meier ging dat toch anders. Want hij geloofde heilig in zijn ontwerp. Het was het beste gemeentehuis dat Den Haag zich kon wensen. En als Den Haag het zich niet kon veroorloven, dan zou je de oplossing wel kleiner kunnen maken, maar hij koos ervoor om in plaats daarvan het probleem een stuk groter te maken. Dus werd er extra functionaliteit gezocht om de kosten van het gebouw te kunnen dragen. Zo ontstond het idee om de centrale bibliotheek in het complex onder te brengen. Op die manier kon hij vasthouden aan zijn ideale ontwerp en het toch betaalbaar maken voor zijn aan de strikte overheidsnormen gebonden opdrachtgever.

Kijk, dat is nou een houding die mogelijk maakt wat vele anderen voor onmogelijk hadden gehouden. Niet alleen maar luisteren naar wat een opdrachtgever zegt te willen, maar aanvoelen wat een opdrachtgever eigenlijk zou willen. Forget the requirements, focus on the true needs instead.

Zou iemand zich op dat moment afgevraagd hebben wat het belang was van Richard Meier zélf bij de uitbreiding van de scope? Het is immers gebruikelijk dat architecten een afgesproken percentage van de aanneemsom kunnen declareren. Hoe hoger de bouwkosten, hoe meer een architect dus kan verdienen.

Het lijkt mij niet erg waarschijnlijk dat dit een rol heeft gespeeld. Een architect met de reputatie van Richard Meier kan zich makkelijk veroorloven om alleen die projecten aan te nemen die passen in zijn filosofie. Een gebouw van de allure van het Haagse gemeentehuis is tenslotte een prestigeproject dat op wereldwijde aandacht van vakgenoten kan rekenen. Vanuit het perspectief van een architect is zoiets een gouden kans om zijn visitekaartje af te geven. Met zulke kansen moet je goed om weten te gaan.

Om over te peinzen.

Haalbaarheid – zeker ook in financiële zin – is keer op keer een argument om inferieure architectuurkeuzes te rechtvaardigen. Er lijkt zich zelden of nooit een goede gelegenheid voor te doen om een hoogwaardige oplossing te realiseren. Dan weer is het de knellende legacyproblematiek, een andere keer is het een gebrek aan ervaring en anders is het wel de korte time-to-market die roet in het eten gooit. En keer op keer krijgt de opdrachtgever niet wat hij eigenlijk zou willen. Keer op keer worden de echte noden niet gehonoreerd.

Natuurlijk zijn opdrachtgevers daarbij een deel van het probleem. Projecten worden altijd te laat gestart, projecten krijgen eng afgebakende doelstellingen mee en opdrachtgevers staan lang niet altijd open voor goede ideeën van anderen. Dat gold allemaal ook voor het gemeenthuis van Richard Meier. En toch, tóch was hij in staat om ruimte te creëren. Against all odds. Je krijgt succes zelden in de schoot geworpen. Het vereist passie, hard zwoegen, oefening, focus, gedrevenheid, dienstbaarheid, ideeën en volharding. Kijk daar de wijze lessen van Richard St. John maar eens op na.

Als je als architect je liever niet leidzaam neerlegt bij het gegevene, als je een passie hebt om het hoogst haalbare mogelijk te maken, dan zoek je net als Richard Meier naar wegen die anderen niet begaanbaar achten. Anders dan anderen heb je de neiging om niet slaafs binnen de kaders te blijven die je worden gesteld, maar in plaats daarvan het belang van je opdrachtgever te dienen door juist buiten de gestelde kaders te treden. Je hebt het lef om de uitgangspunten principieel ter discussie te stellen. Alleen dán zul je in staat zijn om écht een verschil te maken. Om de organisatie tot écht baanbrekende prestaties aan te zetten. En uiteindelijk is dat hetgene waar een opdrachtgever werkelijk op uit is. Gewoon het ongewone durven en doen. Zonder dat, geen vooruitgang.

Tegelijkertijd is het natuurlijk verstandig om te waken voor overdrijving. Niet ieder probleem vraagt om een onconventionele oplossing. Niet iedere onconventionele oplossing is geloofwaardig. Niet iedere archITect heeft een reputatie die bijdraagt aan zijn overtuigingskracht. Niet ieder moment is even geschikt voor structurele veranderingen. Houd dus de realiteit scherp in de gaten en kom altijd goed getimed met doordachte voorstellen. Laat geen onnozele proefballonnetjes op, die worden toch maar doorgeprikt. En bouw ondertussen doelbewust aan een sterke reputatie. Want de successen uit je verleden zijn nou eenmaal de beste basis voor je toekomstige succes. 

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 16de in een reeks die op dit weblog gepubliceerd zal worden.

Methodologica

De komst van de alweer negende versie van het architectuurraamwerk van de Open Group – TOGAF – heeft een verhit debat in de architectencommunity veroorzaakt. Daan Rijsenbrij stelde in zijn column in de Automatiseringgids dat TOGAF een regelrechte bedreiging voor de creativiteit van architecten vormt en pleitte voor een bijsluiter met die strekking. Op de site van Via Nova leverde dit niet minder dan 38 reacties op – de één nog gepeperder dan de andere. Is de Open Group doorgeschoten in haar ambitie om een wereldstandaard voor architectuur neer te zetten, of hebben ze alleen misgeschoten?

Het debat

Als je nuchter kijkt naar de bedrijfsprocessen in IT-afdelingen, dan zijn het er eigenlijk niet zo heel veel. Het onderstaande rijtje zal in de meeste gevallen al behoorlijk dekkend zijn.

1. Het ontwikkelen van nieuwe applicaties / systemen / functies / oplossingen

2. Het implementeren van op de markt verkrijgbare applicaties / systemen / functies / oplossingen

3. Het verbeteren van bestaande applicaties / systemen / functies / oplossingen

4. Het in stand houden van applicaties / systemen / functies / oplossingen

5. Het ontwikkelen en bewaken van beleid voor (een specifiek domein van) applicaties / systemen / functies / oplossingen

Het organiseren van een handvol bedrijfsprocessen zou dus moeten volstaan om IT-afdelingen in te richten. Hoeveel standaard processen, methodieken en raamwerken zouden er moeten zijn om deze 5 bedrijfsprocessen professioneel in te vullen...?

Denk dan eens aan de keuzerijkdom van instrumenten zoals ASL, BiSL, CMMI, COBIT,Cocomo, Demo, DSDM, DYA, EUP, FPA, IAF, IEEE-1471, ITIL, ITSMI, JBF, MArch, MSP, Pino, PMBOK, Prince2, RUP, SEBOK, Scrum, SDM, TMap, TOGAF, XP, Zachman en vele, vele anderen. Het is natuurlijk goed om iets te kiezen te hebben, maar is het allemaal niet een beetje veel en onoverzichtelijk geworden? Begrijpen we wel goed hoe de verschillende methodieken op elkaar aansluiten? Wie doorziet de methodologica nog?

Als je goed kijkt naar de verschillende methodieken, dan valt op dat de meeste zich niet richten op een proces, maar op een subdiscipline. Ze gaan over testen, project management, governance of beheer. Nog preciezer: ze beschrijven de bedrijfsprocessen vanuit het perspectief van de tester, de project manager, de IT manager of de beheerder. De makke van de huidige methodiekenstrijd is dat deze vooral binnen subdisciplines woedt. Testers debatteren over de beste aanpak om te testen, functioneel beheerders zijn vooral met hun eigen best practices bezig en voor project managers, ontwikkelaars en architecten geldt al niet veel anders. Ieder specialisme zijn eigen manier van werken.

Dit geldt net zo goed voor TOGAF. De Architecture Development Methodology, het beeldmerk van TOGAF, is architect-centric. Het beschouwt de wereld vanuit de bril van de IT-architect en de discussie daarover woedt louter in het architectenwereldje. Deze discussie vertroebelt tot mijn verdriet het zicht op de bal. Wat was ook al weer het verheven doel van werken onder architectuur? Waar doen we het voor? Om architectuur te produceren? Ter meerdere eer en glorie van architecten? Of om de informatievoorziening van bedrijven te stroomlijnen? Om de chaos van werken zonder architectuur te bestrijden?

Als we dát willen, dan zullen we toch de samenwerking moeten zoeken met de professionals uit die andere subdisciplines. Dan hebben we weinig aan een methodiek voor architecten. Dan hebben we nood aan een methodiek die multi-disciplinaire samenwerking ondersteunt en bevordert.

Unified view

De vijf geschetste bedrijfsprocessen vragen elk voor zich om een multidisciplinaire aanpak, waarbij dezelfde subdisciplines in meerdere processen een rol spelen. Die bedrijfsprocessen verschillen van bedrijf tot bedrijf niet wezenlijk van elkaar. Dat schreeuwt om een standaard aanpak, om een overkoepelende methodiek. Maar het debat over de samenhang tussen de verschillende methodieken binnen één voortbrengingssproces is merkwaardigerwijs nog nauwelijks van de grond gekomen. Zouden IT-ers te betrokken zijn bij hun eigen werk om hun eigen manier van werken goed te kunnen analyseren en structureren?

Als je nog iets verder denkt, dan is het niet persé handig als een professional die een rol speelt in meer dan één soort bedrijfsproces telkens zou moeten overschakelen op een andere methodiek. Maar waarom is er dan niet één methodiek die de vijf genoemde bedrijfsprocessen in hun onderlinge samenhang beschrijft? Zo moeilijk kan dat toch niet zijn? Zouden we dáár als architectuurcommunity eigenlijk onze energie niet in moeten steken?

Zo'n integraal procesmodel hoeft heus geen one-size-fits-all te zijn. Er mogen best een stuk of drie scholen zijn, die elk een principieel andere weg kiezen voor de invulling van de bedrijfsprocessen in de informatievoorziening. Laten we zeggen, de Engelse school – gebouwd op ITIL en DSDM – de Rationele school – gebouwd op de unified processes – en de Rode school waaraan Oracle ongetwijfeld naarstig werkt. Dan blijft er iets te kiezen en zou zo'n keuze te baseren zijn op de mate van synergie met de eigen bedrijfsprincipes.

Er zijn wat hoopvolle tekenen dat er meer mensen in deze richting denken. Wim Hoving en Jan van Bon pleiten in een artikel in de Automatiseringgids bijvoorbeeld voor een fusie van ITIL, ASL en BiSL. Eén methodiek voor het in stand houden van applicaties / systemen / functies / oplossingen. Ook het unified process is van nature multidisciplinair. Het kán dus wel degelijk.

Oproep

Als architectencommunity zouden we een bijdrage moeten leveren aan de verbetering van de organisatie van de bedrijfsprocessen in de informatievoorziening. Het concept “Ontwikkelen onder Architectuur” is alvast een goed begin, zij het dat het dan wel als een volwaardig ontwikkelproces uitgewerkt zou moeten worden (ik heb het altijd een merkwaardig fenomeen gevonden dat iets wat we betitelen als “Ontwikkelen” als een primair architectuurproces wordt gepositioneerd, maar dat terzijde). Zo zouden we ook voor “Implementeren onder Architectuur”; “Evolueren onder Architectuur”; “Beheren onder Architectuur” en “Beleidsontwikkeling onder Architectuur” modelprocessen kunnen ontwerpen. Uiteraard zouden die processen zoveel mogelijk voort moeten bouwen op de de-facto standaarden die al in gebruik zijn, waarbij het een behoorlijke uitdaging wordt om die qua terminologie en qua systematiek goed op elkaar te mappen. En uiteraard moeten deze modelprocessen inzicht bieden in de plaats van architectuur binnen die bedrijfsprocessen.

Zou dat nou niet een interessant thema zijn voor een workshop tijdens het komende LAC als opmaat naar een nieuw NAF-boek?

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 15de in een reeks die op dit weblog gepubliceerd zal worden.

Intensieve computerhouderij

Nicholas Carr heeft het weer voor elkaar. Zijn laatste boek “The Big Switch” heeft de tongen en pennen wereldwijd weer hevig in beroering gebracht. Het blad “Computable” stelt naar aanleiding van het oplaaiende debat weer eens openlijk de vraag “Wordt it een nutsmiddel net als de elektriciteitsvoorziening?”

Zelf was ik eigenlijk niet van plan om opnieuw aan dit debat mee te doen. Ik heb er hier al een keer over geschreven en toen was mijn boodschap al dat “IT” veel meer is dan alleen maar het opwekken van een betrouwbare informatiestroom. Wat dat betreft vind ik de argumenten van autoriteiten als Don Tapscott of Chris Verhoef veel overtuigender. Ik ben niet van mening veranderd. Toch heb ik er opnieuw over zitten peinzen.

Het debat

Nicolas Carr predikt de revolutie. Wat in een grijs verleden met stroom is gebeurd – van lokaal opgewekte stroom naar nutsvoorziening – zou nu met 'IT' gaan gebeuren. Gebruikersorganisaties zouden massaal tot het inzicht komen dat het “opwekken van IT” geen core business is en veel beter door een gespecialiseerd bedrijf zou kunnen gebeuren. Zo'n – wat ik noem – intensieve computerhouderij zou belangrijke schaalvoordelen met zich mee brengen, met een hogere betrouwbaarheid en een lagere prijs als onvermijdelijk resultaat. En wie zou dat nou niet willen? Het is niets nieuws. Het rijtje is even bekend als afgezaagd: Internet Service Providers, Application Service Providers, Outsourcing, trusted Business Service Providers, Software-as-a-service, Platform-as-a-service, the Cloud. En dan zie ik vast nog wel wat incarnaties van in essentie hetzelfde concept over het hoofd. Maar om nou te spreken over een revolutionaire verandering?

Tapscott heeft er al uitgebreid op gewezen dat IT niet alleen een “T”-gezicht heeft, maar ook een “I”-gezicht (“Why You Can't Take the "I" Out of IT”). Wanneer heeft u voor het laatst gelezen over een mislukt project vanwege een tekort aan computercapaciteit? Of vanwege een fout van een beheerder? Zet dat eens af tegen de projecten die op de klippen zijn gelopen door tekortschietend opdrachtgeverschap, mismanagement of fundamentele ontwerpfouten? Carr wil ons toch niet werkelijk laten geloven dat iedere SAP-implementatie alleen nog maar glansrijk kan slagen, alleen maar omdat SAP “uit de muur komt”? Of dat je voortaan probleemloos zou kunnen overschakelen van SAP op Oracle Fusion, omdat het toch uit dezelfde muur komt? Of zelfs dat je de verantwoordelijkheid voor zo'n operatie bij een externe provider zou willen beleggen? Dat valt toch in de verste verten niet te vergelijken met de switch van NUON naar Eneco?

Misschien is een vergelijking met de telecomindustrie wel veel meer op z'n plaats. Ook deze industrie is ontstaan als een nutsvoorziening. Telefoon komt gewoon uit de muur, of beter nog, uit de lucht, toch? Maar dat betekent nog níet automatisch dat geen enkel bedrijf zou hoeven te investeren in een éígen telefooncentrale! Als de telefoon een cruciaal bedrijfsmiddel is om je call-center te runnen, dan is het toch ook in economische zin volkomen gerechtvaardigd om daarin zelf te investeren? En zelfs als het zo zou zijn dat alle functionaliteit die je voor je call center nodig hebt “uit de muur” beschikbaar zou zijn, zou het dan ook maar een greintje minder ingewikkeld zijn om het voice-respons systeem goed in te richten, om de binnenkomende gesprekken goed te routeren en om de benodigde operator capaciteit goed in te plannen? Zou het voor zo'n grootschalige nutsvoorziening wel eenvoudiger zijn om nieuwe, concurrerende call-center technologie te implementeren? Of zouden zulke innovaties al snel smoren in complexiteit?

Om over te peinzen

Het lijkt mij dat er een reden moet zijn waarom veel computerintensieve bedrijven niet enthousiast inhaken op het idee van “IT uit de muur”. Zou het misschien zo kunnen zijn dat dit het simpele feit is dat “IT uit de muur” voor veel van die bedrijven geen reëel probleem oplost? Dat hun rekencentra grosso modo tenminste voor de bedrijfskritische systemen de huishouding behoorlijk op orde hebben? Immers, zou dit structureel niet het geval zijn, dan had men dit probleem immers al veel eerder op kunnen lossen; al was het maar via outsourcing.

En als je een goed lopend rekencentrum hebt, dan kan Carr wel voorrekenen dat dezelfde service goedkoper elders betrokken kan worden, maar dan houdt hij waarschijnlijk geen rekening met de desinvesteringen die daarmee gepaard gaan. Als je daar wel rekening mee houdt dan krijg je een business case niet zo makkelijk rond. Over hoeveel jaar is 'het rekencentrum' bij u afgeschreven?

Maar moet je eigenlijk wel rekencentra willen verplaatsen en concentreren, enkel en alleen om van schaalvoordelen gebruik te kunnen maken? Heeft u daar wel eens over nagedacht? Ik kom de laatste tijd niet meer zo vaak op een computervloer, dat geef ik grif toe, maar de keren dat ik er eens kom, dan valt het me iedere keer weer op dat het rekencentrum zo goed als uitgestorven is. Er is zelden iemand te bekennen. Waarom zou je ook? De systemen zijn prima op afstand te besturen en iets handmatigs als het verwisselen van tapes is al lang geleden gerobotiseerd.

Automatisch up- en downscalen kan met moderne virtualisatietechnologie best over de fysieke grenzen van rekencentra heen. Wat vroeger “uitwijk” werd genoemd, kan met moderne technologie geautomatiseerd worden door meerdere rekencentra met elkaar te verbinden. En op die manier kan onvoorzien onderhoud aan computersystemen best planbaar worden: er gaat iets stuk, je herrouteert de informatiestroom en je kunt een reparatie rustig uitvoeren terwijl het vliegtuig gewoon in de lucht blijft. En de overcapaciteit in het rekencentrum van het ene bedrijf kan – tegen een passende betaling, dat spreekt! – eenvoudigweg benut worden voor de capaciteitsbehoefte van een ander bedrijf. Met andere woorden: een virtuele cloud kan in principe net zo effectief zijn als een fysieke cloud. Maar het is wel veel makkelijker van de grond te krijgen! Bestaande capaciteit koppelen in plaats van afbreken en elders nieuw opbouwen. Dat is toch veel slimmer?

Daarom zou ik Carr willen vragen, is zo'n intensieve computerhouderij geen verstokt 20^ste eeuws denken? Zou je nou juist de computertechnologie van de 21^ste eeuw niet heel goed kunnen gebruiken om fysieke barrières te overwinnen? Om capaciteit te distribueren en alleen de activiteit te centraliseren? Is het niet de verdienste van het internet dat we tegenwoordig locatie-onafhankelijk kunnen werken, ook – of misschien wel juist – als IT-ers? Zou daar dan het debat niet over moeten gaan?

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 11^de in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

Darwin Day

Vandaag, donderdag 12 februari 2009, is uitgeroepen tot world Darwin day. Het is namelijk 200 jaar geleden dat deze wetenschapper is geboren. Ter ere daarvan heeft Google vandaag zelfs haar logo hierop afgestemd.

Het nieuws

Darwin, die zoals bekend aan de basis van de evolutietheorie heeft gestaan, wordt alom gezien als een van de grootste wetenschappers die ooit heeft geleefd. Zoals het blad Nature het deze week verwoordde: “Als hedendaagse wetenschappers zouden mogen beslissen wiens afbeelding er op het papiergeld afgebeeld zou moeten worden, dan zou Charles Darwin daar zeker bij zitten”.

De meeste Nederlanders accepteren tegenwoordig dat evolutie 'van nature' plaatsvindt. Anders dan in sommige andere landen is het onderwijzen van de evolutietheorie op scholen in Nederland nauwelijks omstreden. Andries Knevel, van wie je toch een creationistische grondhouding zou verwachten, veroorzaakte onlangs een relletje toen uitgerekend hij liet weten ook voor orthodoxe christenen ruimte te zien om niet te geloven in een schepping van 6 dagen van 24 uur.

Wat heeft dit alles te met het bedrijven van archITectuur? Nou, dat zit zo. Ik heb sterk de indruk dat IT-organisaties in Nederland massaal zo zijn georganiseerd alsof ze nog steeds geloven in het scheppingsverhaal van de digitale wereld. Er zijn programma's en projecten, die worden verantwoordelijk gehouden voor de creatie van telkens een stukje van de digitale wereld. Als dat eenmaal is gelukt, of tenminste enigszins is gelukt, dan wordt het resultaat 'overgedragen' aan 'beheer'. De voornaamste verantwoordelijkheid van 'beheer' is om er voor te zorgen dat de digitale wereld blijft zoals die door de scheppers is gecreëerd. Deze twee verantwoordelijkheden zijn meestal op afstand van elkaar georganiseerd – soms zelfs bij totaal verschillende organisaties belegd.

Naar mijn overtuiging is deze scheiding gebaseerd op een schijnwerkelijkheid. Namelijk de schijnwerkelijkheid dat evolutie in de digitale wereld niet bestaat, of dat je er in elk geval in je organisatie geen rekening mee hoeft te houden. Dat de zaken in de digitale wereld alleen gecontroleerd en gepland veranderen. En dat is nou naar mijn idee een tragisch voorbeeld van bedenkelijke

Flauwekul!

Wie een beetje oplet, die ziet de evolutie in de digitale wereld overal aan het werk. Systemen worden voortdurend aangepast aan wijzigende omstandigheden; gebruikers gaan de systemen in de loop van de tijd op een andere manier gebruiken en dan heb ik het nog niet het effect van de technologische infrastructuur, die voortdurend in ontwikkeling is. De digitale wereld wordt ook steeds groter: meer en meer systemen worden gekoppeld; meer en meer domeinen worden gedigitaliseerd.

Allerlei technologische ontwikkelingen van de laatste jaren vergroten de mogelijkheden van evolutie. Webapplicaties worden steeds minder in omvangrijke releases met lange intervallen uitgegeven, maar in plaats daarvan in korte cycli permanent verbeterd. Enterprise software is dankzij de inzet van business process en business rules engines geschikt gemaakt om at runtime aangepast te worden aan wijzigende behoeften en omstandigheden. En het concept van «Event Stream Processing» is zelfs gelanceerd met het idee dat het zich in combinatie met «Enterprise Decisioning» heel goed dynamisch aan wijzigende omstandigheden zou kunnen aanpassen. «Continuous Business Improvement» noemen ze dat bij IBM.

En toch, toch werken wij nog steeds met processen als DYA, TOGAF, Prince2, RUP en SCRUM om systemen te ontwikkelen en BiSL, ASL en ITIL om diezelfde systemen vervolgens te beheren. De verbinding tussen die gescheiden werelden is min of meer bewust zo beperkt mogelijk gemaakt. Er wordt gesproken in de metafoor van een “slagboom” of een “sluis” om aan te geven dat de verbinding meestal dicht is en alleen in bijzondere omstandigheden kan worden geopend – en dan nog slechts heel tijdelijk. Die scheiding is ook te merken aan de tools en technieken die worden ingezet om te helpen de processen uit te voeren – iets waarover ik al eens eerder heb geblogd.

In de rol van archITect ervaar je de effecten van die scheiding in twee digitale werelden. Het slechten van de muur tussen ontwikkeling en beheer is voor een archITect een uitdaging die vooral veel tijd en energie kost en voor de overkoepelende organisatie betrekkelijk weinig rendement oplevert. En dat heeft er alles mee te maken dat deze organisatie bewust of onbewust een conflict heeft ingebouwd door belangen te scheiden langs de lijn «vernieuwen» tegenover «in stand houden». Het valt betrekkelijk eenvoudig in te zien dat deze belangentegenstelling geen reflectie is van de belangen van de gebruikers waarvoor de digitale wereld is gecreëerd. Immers, die gebruikers willen vooral graag dat hun digitale wereld geleidelijk met hen meegroeit. Die gebruikers hebben vooral behoefte aan een permanente evolutie – iets waarvan we trouwens sinds het werk vanCharles Walcott vermoeden dat het gedurende lange periodes betrekkelijk langzaam verloopt en tijdens korte periodes plotseling heel snel kan verlopen. Herkenbaar?

Dus mijn revolutionaire archITectuuridee van vandaag is betrekkelijk simpel: laat je eens inspireren door het concept van een permanente digitale evolutie om archITectuur en archITectuurprocessen vorm te geven. Verfrissend!

Deze flauwekul ontzenuwt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 8^ste in een reeks flauwekul die op dit weblog gepubliceerd zal worden.

Moord met voorbedachten rade

Het jaar 2009 is in de archITectuurblogosfeer met vuurwerk begonnen. Anne Thomas Manes van de Burton Group heeft veel stof doen opwaaien met haar posting “SOA is Dead”. Zelfs de Automatiseringgids wijdt er een artikel aan. Sommige reacties waren instemmend, zoals die van David Linthicum, die in zijn podcast droogjes constateerde dat SOA al lang dood was en Anne Thomas alleen maar het tijdstip van overlijden heeft bepaald op 1 januari 2009. Anderen waren minder positief. De leukste titel was wat mij betreft SOA: Wanted Dead or Alive.

Het debat

Ik dacht Anne Thomas te kennen als een bedachtzame, vrij ingetogen persoonlijkheid. En ze is bepaald niet dom. Dat zij zoveel gedoe kon veroorzaken deed mij in eerste instantie de wenkbrauwen fronsen. Waar was de nuance gebleven? Een citaat:

"It's time to accept reality. SOA fatigue has turned into SOA disillusionment. Business people no longer believe that SOA will deliver spectacular benefits. 'SOA' has become a bad word. It must be removed from our vocabulary."

Niet zo gek dat mensen daarop geprikkeld reageren. Zeker de professionals die uit het SOA gedachtegoed hun inspiratie putten, dagelijks hun stinkende best doen en de laatste jaren aanzienlijke vooruitgang weten te boeken – met hier en daar zelfs spectaculaire resultaten.

Als je de hele posting leest en probeert te begrijpen wat Manes werkelijk bedoelt, dan wordt het beeld wat subtieler.

"SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”."

Anne Thomas probeert dus juist vooruit te kijken naar de nieuwe trends. Al die trends bouwen voort op de principes van een service-geörienteerde architectuur. In die zin is SOA springlevend. Het verkoopt alleen niet meer als doel op zich, het is – hè hè, eindelijk! – een middel geworden om andere doelen, samen te vatten onder het motto 'beter, sneller én goedkoper', te bereiken.

Mijn idee

Ik ben een verklaard aanhanger van de stelling “een SOA kun je niet kopen”. In een eerdere posting heb ik mij al eens afkeurend uitgelaten over “vendor driven architecture”. Architectuur kan naar mijn mening pas duurzaam succesvol zijn als het hecht verbonden is met de strategie en de cultuur van de (extended) enterprise. Daarmee is iedere organisatie in zekere zin uniek. Het is dus goed dat leveranciers stoppen met het verkopen off-the-shelf 'architectuur'. Dat kan alleen maar teleurstellingen opleveren.

Het adopteren van SOA is een langjarig traject. Uit eigen ervaring weet ik dat een transitietijd van 7 jaar haalbaar is, in een niet al te complexe omgeving met goede en standvastige sturing. Dat was wel in een tijd dat er nog veel minder ervaring met het toepassen van SOA was en er nog veel minder technologische hulpmiddelen beschikbaar waren. De Enterprise Service Bus was nog niet eens beschreven. Wellicht dat het anno 2009 dus een tandje sneller zou kunnen. Aan de andere kant, als ik er nu op terugkijk, dan waren de lastigste veranderingen organisatorisch van aard. Het opbouwen en vasthouden van het vertrouwen dat het “in de toekomst” – na de nodige bloed, zweet en tranen – echt veel beter kan en zal gaan, is begrijpelijkerwijs moeilijk. Het vergt het soort missiewerk dat onvermijdelijk met een gezonde portie scepsis wordt ontvangen. Een sterke visie en een krachtig doorzettingsvermogen zijn even onmisbaar als de nodige tegenslagen voorspelbaar zijn. En veel meer praktisch advies dan de tegeltjeswijsheid dat het vieren van successen kan helpen om de moed erin te houden is er jammer genoeg niet voorhanden.

Waar het om draait is dat SOA een architectuurstijl is die daadwerkelijk kan helpen bij het beter beheersen van complexiteit in moderne, IT-intensieve organisaties. Ik ben nog steeds van mening dat het op de weg van de verklaarde tegenstanders van SOA ligt om een reëel alternatief te schetsen. Terug naar vroeger is daarbij wat mij betreft geen serieuze optie. Want de ervaringen uit het verleden hebben toch afdoende aangetoond dat de kachelpijparchitectuur, de archipelarchitectuur en de data-geörienteerde architectuur uiteindelijk tot een haast onontwarbare kluwen aan onderlinge afhankelijkheden leiden – met alle verstorende en verstarrende effecten van dien.

Een complexe enterprise architectuur is complex om te besturen – en in de overgangsfase van de bestaande naar de nieuwe architectuur geldt dit des te sterker. Daarbij moet echter bedacht worden dat SOA de beste kans is om het enterprise niveau überhaupt bestuurbaar te maken. Het falen van SOA initiatieven is imho vaak een indicatie van een gebrekkige besturing – en veel minder van gebrekkige technologie. Architecten hebben primair de taak om het ontwerp van een SOA in goede banen te leiden – moeilijk zat. Het kan echter geen kwaad om ook vanuit de verantwoordelijkheid van de architect de bestuurders op hun cruciale rol te wijzen en ze waar mogelijk met raad en daad bij te staan bij het invullen van hun verantwoordelijkheid.

Blijf dus ook in 2009 werken aan het flexibiliseren en rationaliseren van uw business- en IT-landschap en blijf vooral ook pleiten voor een slimmere besturing van de evolutie van die landschappen.

De leveranciers zullen de boodschap van Anne Thomas vast vertalen in een nieuwe stortvloed van overgehypte instant-oplossingen. Laten we hopen dat daar nou eens met de gepaste scepsis naar gekeken wordt...  

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 14de in een reeks die op dit weblog gepubliceerd zal worden.