Software Release Magazine Blog http://www.release.nl Software Release Magazine Blogs RSS (c) Array Publications <![CDATA[Requirements]]>
Thuis heb ik daar geen moeite mee. Vrouw noch dochters interesseren zich voor dit onderwerp en dat hoeft ook niet, gezien hun professionele bezigheden. Als zij dus zo’n vraag zouden stellen – en dat gebeurt uitsluitend om te doen voorkomen dat ze zich voor mijn werk interesseren – zou ik het als volgt formuleren: “Requirements zijn het boodschappenlijstje van een bedrijf, dat een computerprogramma nodig heeft.”

De reactie van de dames ken ik van soortgelijke situaties uit het verleden: Een zonder enig enthousisme uitgesproken “Oh. Leuk” als teken dat verdere uitleg ongewenst is. Maar met die collega ligt dat anders. Zij moet (en wil) er professioneel iets mee kunnen doen. Voor haar kon ik het boekje ‘Heldere wensen en eisen!’ van Mirjam van den Berg uit de kast trekken. Ik had het net uitgelezen om er een recensie van te maken en vindt dat dit in eenvoudige bewoordingen snel en redelijk accuraat uitlegt waar het bij requirements om gaat. Voor mijn collega is dat prima en dat is het ook voor degenen, die zich op beperkte schaal of voor kleinere projecten met requirements moeten bezighouden.

Voor hen, die het requirementsproces echt onder de knie moeten of willen krijgen, zijn ingrijpender maatregelen nodig. Voor hen is er om te beginnen het boek ‘Mastering the Requirements Process’ van James en Suzanne Robertson. Dit wordt wereldwijd gezien als hèt standaardwerk op dit gebied. Wie nog een stap verder wil gaan volgt een gelijknamige workshop van de Robertsons, die met enige regelmaat worden georganiseerd.

Dan wordt pas echt duidelijk hoe breed de problematiek rond het verkrijgen van de juiste wensen en eisen is. Er is veel mensenkennis, communicatie en enig psychologisch inzicht nodig om het proces tot een goed einde te brengen. De Robertsons weten dat ook nog heel helder uit de doeken te doen.

Sinds kort is er ook een vervolg op de workshops: Mastering the Requirements Process, deel II. Deze is er uitsluitend voor degenen, die de eerste workshop hebben gevolgd en daarna minstens een half jaar met de daar opgedane kennis hebben geoefend. Voor projectmanagers is deze workshop het neusje van de zalm. Op dit niveau met requirements omgaan is vaak de inleiding tot mooie, innovatieve projecten met een grote meerwaarde voor de business. En dat is toch waar we het allemaal voor doen. Meer informatie hierover op onze Release-website.]]> Tue, 05 Jul 2011 15:17:29 GMT <![CDATA[Nieuwe Wijn...]]> Ik heb een eenvoudige vuistregel die ik graag deze zomer ter overpeinzing meegeef: je zit al veel te lang in het IT-vakgebied als je begint te vinden dat alle vernieuwingen Oude Wijn in Nieuwe Zakken zijn. We kennen het type allemaal wel: geharde veteranen, hebben complete besturingssystemen zelf geschreven. Duizenden ponskaarten ingetikt en dan maar achter de ratelende teletype op de resultaten wachten. Liet iemand het hele pakket uit zijn handen vallen. Kon je weer helemaal opnieuw beginnen. Heldenwerk.
Als je dat hebt meegemaakt, kijk je nergens meer van op.
 
Oude Wijn, het woord valt in zulke kringen vaak en gretig. Momenteel vooral als het over de cloud gaat. En neemt u even van mij aan, dat gebeurt vaak. Het onderwerp is ondertussen zo populair, dat ze ook op de markt er al een mening over hebben. Je kan haast geen stronk broccoli meer kopen zonder een discussie over de cloud te moeten voeren. Zou iets met de televisie te maken kunnen hebben. Ik mocht kortgeleden twee keer meepraten in een programmareeks op RTL, warempel helemaal gewijd aan de cloud. Een interessante ervaring. In het tijdperk van YouTube denk je dat zoiets wel even snel met een handycam en een extra lichtspotje in elkaar wordt gedraaid. Komen er toch meerdere vrachtwagens en een middelgroot peloton aan technici, regiemedewerkers en visagisten aan te pas.
Het leidde bij de opnames niet al teveel af. Ik kwam in geanimeerde debatten terecht over ondertussen voor de hand liggende onderwerpen als beveiliging, wet- en regelgeving, stabiliteit en betrouwbaarheid. En ja hoor, je kon er op wachten. In beide afleveringen waren we nog geen tien minuten op weg, of de oude wijn en nieuwe zakken vlogen al over tafel. Het had goedbeschouwd allemaal veel weg van de grote mainframes en de teletypes van vroeger, zo claimde er een. Client/Server, daar leek het eigenlijk ook wel op, of gewoon hosting. Precies service-oriëntatie vond een ander. En Application Service Provisioning. Niks nieuws, opgeklopt marketingspul.
 
Gelukkig is er tegenwoordig Web 2.0: een beetje televisieprogramma heeft een eigen Twitter hashtag en Facebook-pagina. Zo ook hier. Er werd lustig tijdens de uitzending door kijkers op los getweet, wat onder andere tot het snedige “Nieuwe Wijn en Oude Zakken” leidde.
Een terechte vaststelling. Wat ook je leeftijd is, je bent een oude zak als je in dit vakgebied niet meer fascinatie voelt voor nieuwe ontwikkelingen. Zelfs als alles in feite nog steeds nulletjes en eentjes zijn die worden uitgewisseld. Het duidt op het type lusteloosheid dat tot carrièrewendingen zou moeten leiden. Wordt dan mental coach zou ik zeggen. Of begin een antiekwinkel.
En de cloud, die maakt de dingen wel degelijk heel anders. Misschien niet als we de infrastructurele bril opzetten. Dan verdwijnen gewoon die sympathieke jongens van het rekencentrum met hun rubberen zolen stapsgewijs uit het kantoorbeeld. We gaan een tikje anders programmeren, leren wat andere  libraries of zelfs een nieuwe programmeertaal te gebruiken. En we hoeven niet meer zo hard van tevoren na te denken over schaalbaarheid.
 
Maar de echte omslag komt met de enorme marktplaats van applicaties en services die straks in de publieke cloud ontstaat. De producten daar zijn zoveel simpeler, meer gestandaardiseerd en – vooral – goedkoper: daar kun je het zelf in de organisatie niet meer voor doen. Je hebt dan heel wat uit te leggen als je – net als vroeger – toch weer een compleet zelfbouwtraject aan het optuigen bent.. Bouwen met wat er te koop is, dat wordt het motto. Je zou dat oude wijn kunnen noemen (roept daar iemand ‘hergebruik van componenten’?) maar dan hebben we het wel over wijn die in de praktijk nog nooit is geschonken. Goed voor de rijping, zullen we maar zeggen.

De marktplaats maakt het verschil. In die zin alleen maar toepasselijk dat mijn groenteboer ondertussen ook een mening over de cloud heeft.
]]> Mon, 27 Jun 2011 13:22:49 GMT <![CDATA[Nut van Governance]]> Heren architecten, software ontwikkelaars en beheerders, ik gebruik hier het begrip Governance omdat in dit ene Engelse woord verscheidene Nederlandse begrippen zijn vervat en het gemakkelijker wordt een brug te slaan naar de subtitel van dit stuk: “De SOA gouvernante in actie”. Om misverstanden te voorkomen: daarmee bedoel ik: het zinvol en prudent besturen van een (deel) organisatie, een belangrijk kenmerk van een succesvolle manager (naast uiteraard inspireren, faciliteren, risico’s inschatten en méér).
 
De SOA gouvernante is ervoor verantwoordelijk, dat bijna àlles soepel en volgens de regels verloopt. Zij heeft de zorg over zowel de globale uitwerking van architectuur als over de belangen van de organisatie en de impact/stroomlijning van SOA initiatieven op de organisatie en vice versa.
 
De SOA gouvernante heeft een grote familie. Haar grote zuster heeft corporate governance in haar portefeuille. Deze dame heeft ook de bijnaam ‘Tante Compliance’. Het doel van haar tante is ervoor te zorgen dat alles dat wat in de onderneming gebeurt tot waardecreatie leidt en tot voordeel strekt. Haar oom, dhr. I.T. Governance is er natuurlijk ook en er lopen nog wat neven en nichten in het rond.
 
Onze gouvernante wordt natuurlijk niet betrokken in de dagelijkse gang van zaken of in de technische details maar zij zal strategieën en verantwoordelijkheden opstellen en constant de initiatieven controleren. Zij moet onder meer zeker stellen dat de begroting voor een SOA wordt besteed om de best mogelijke ‘return on investment’ (ROI) te bereiken én dat de te leveren diensten aan de klanten zo goed mogelijk door de gerealiseerde services worden ondersteund.
 
 “Maar wacht even”, denkt u: “Het management heeft toch de zorg over het SOA succes?” In theorie, ja hoor. Maar in de praktijk weten we dat managers soms een heel eigen agenda hebben die botst met de lange termijn doelstellingen van de organisatie. Een voorbeeld: Projectleiders leggen regelmatig meer nadruk op hun projecten of programma’s dan op de strategische ondernemingsdoelstellingen. Of glijden daarvan - in de waan van de dag - weg.
 
De SOA gouvernante vertegenwoordigt daarom een soort ‘über’ management dat slechts toegewijd is aan de organisatie zelf. Haar taak is de regels en richtlijnen in de gaten te houden en  niet om beleefd en aardig te zijn. Wenselijk gedrag moedigt zij aan en/of dwingt zij af. Met andere woorden: de SOA gouvernante heeft macht, in ieder geval op gebied van de SOA in de organisatie, en zij weet dat ondernemingen en organisaties twee schijnbaar tegensprekende zaken nodig hebben.
Ten eerste ‘orde en controle’: dus het hebben van wetten/principes en handhavers daarvan. Dat is de taak van het management.
Ten tweede ‘vrijheid, ruimte voor creativiteit en een positieve werkomgeving’, dat is vooral voor onze kenniswerkers.
Het eerste zult u als softwareontwikkelaar beslist niet of als architect vaak niet prettig vinden maar is absoluut nodig. De gehele Agile beweging is gericht op het verbeteren van het tweede aspect.
 
Vooral binnen IT organisaties, wordt het ‘orde & controle’ aspect vaak beschouwd als diagonaal staand op ons kenniswerk(ers/sters). De gouvernante ziet hierin geen tegenstelling: Zij probeert de controle zo te optimaliseren dat dit bijdraagt aan het behalen van resultaten voor de business (die IT’ers vaak beloven maar bijna even zo vaak niet bereiken) en wij IT mensen geven eigenlijk veel te weinig om de bedrijfsbehoeften of begrijpen ze niet. En daarnaast schijnen de mensen van de business, de IT mannen (wees eerlijk, het zijn voornamelijk mannen) te negeren.
 
Bedenk daarbij ook dat de Gouvernante als geen ander weet dat de Agile aanpak de grootst mogelijke controle op het behalen van de gewenste resultaten inhoudt.  Want, hoeveel concreter is opgeleverde software of een (elementaire) service dan een maandelijkse rapportage? Wat kun je beter toetsen aan de architectuurvisie dan iets dat werkend wordt afgeleverd?
 
Dus hoewel ze best wel streng is, is zij bijzonder rechtvaardig. Ik verdenk haar daarom ook (verre) familie van vrouwe Justitia te zijn.  Haar conclusie is:
 
Alleen de juiste hoeveelheid governance maakt ondernemingen succesvol.
Alleen door nauwe samenwerking kunnen we gezamenlijk ondernemingssucces garanderen.
Alleen met een Agile aanpak leveren wij regelmatig waardevolle services op die getoetst kunnen worden aan de doelarchitectuur. 
Alleen met respect voor elkaars vakmanschap en inzichten komen we verder.]]> Mon, 21 Mar 2011 17:06:44 GMT <![CDATA[Trein op hol]]>
Onlangs heb ik Leonardo di Caprio aan het palet toegevoegd. Of liever gezegd: zijn tolletje uit de kaskraker Inception. Voor die enkele, treurige niet-ingewijde: in deze film dringt de held door in de dromen van anderen teneinde geheimen te stelen of heel subtiel ideeën te planten die later tot ingrijpende beslissingen leiden. Omdat dit zich ook allemaal nog eens recursief afspeelt – een droom binnen een droom binnen een droom – wordt het een tikje lastig om vast te stellen wat echt is of niet. Vandaar het tolletje: als dat onverstoorbaar doordraait zitten we in een virtuele wereld, als het omvalt zitten we in de echte. Heel bruikbaar om een verhandeling op te baseren over virtueel en werkelijk, droom en daad, succes en nachtmerrie. Vooral als het over Cloud en Web 2.0 gaat.

In de film komt ook een andere sterke metafoor voor. Middenin de drukke stad komt opeens een dieseltrein door de straten denderen, alles op zijn weg verpletterend (je hebt dan overigens geen tolletje nodig om vast te stellen dat er sprake is van een droom). De schade is enorm. Dat krijg je ervan als je met zo’n groot, lomp ding probeert te doen alsof je een scooter bent.

Met applicaties is het vaak niet anders. Voortgedreven door de steeds sneller veranderende eisen van de bedrijfsvoering, willen we vanuit de IT lichtvoetiger mee kunnen bewegen. We streven naar Scooter-applicaties: toepassingen die we snel kunnen bouwen en aanpassen en die ons zo dicht als mogelijk bij de doelen van het bedrijf brengen. Al scrummend manoeuvreren we langs de specificaties om het resultaat precies op tijd bij de juiste voordeur af te leveren.

Jammer dat we het in echte leven heel vaak moeten doen met applicaties die niet voor zulke doeleinden gebouwd zijn: we moeten werken met grote, complexe legacy-toepassingen of standaard ERP oplossingen. Die toepassingen zijn gebouwd als Trein-applicaties: bedoeld voor misschien wel decennia van onverstoorbaar, repetitief gebruik; altijd hetzelfde, voorspelbare spoor volgend van A naar B; robuust en degelijk (geen grappen over ProRail graag); beschikbaar in precies eén smaak. Een trein kun je niet aanpassen aan je eigen smaak en voorkeuren. Je kunt er ook niet zomaar een andere route mee gaan volgen.

Toch is dat niet zelden wat we als applicatieontwikkelaars proberen te doen. We proberen uitbreidingen te bouwen in legacy-software en merken dat de minste aanpassing tot een kettingreactie aan risicovolle bijverschijnselen kan leiden. Regressietesten wordt de voornaamste, uiterst tijdrovende bezigheid. Als we met ERP-pakketten als SAP werken, zijn we niet te beroerd de modules zodanig te customizen dat ze niets meer weg hebben van de oorspronkelijke, standaard oplossing. Mocht de leverancier ooit met een upgrade komen, dan staan we voor een massief project om alle toeters en bellen binnen de nieuwe versie weer draaiend te krijgen.

Het is daarom zaak om beter te begrijpen dat er verschillende soorten applicaties zijn, elk met hun eigenaardigheden op het gebied van timing, frequentie, levensduur, aanpak en tools. Trein-applicaties moeten robuust , stabiel en standaard zijn. Alle code die daarbinnen naar scooter-gedrag neigt, kan er beter uitgeknipt worden en opnieuw ontwikkeld worden met veel geschiktere tools (BPM, portals, mashups, Ruby, Cocoa) en een lossere koppeling.

Niemand zit immers te wachten op een trein die op hol slaat. Kun je net zo goed gelijk op de voorplecht van de Titanic gaan staan en naar Celine Dion luisteren.]]> Mon, 21 Mar 2011 17:03:42 GMT <![CDATA[Integratie]]>  
“Ik had evengoed met mijn neefje in zee kunnen gaan; die is ook heel handig op de pc”, denkt de klant wellicht. En zo gek is dat niet, want het neefje mag zich ook business analist noemen. En de slager om de hoek. En de werkloze, die een jaar heeft besteed aan websites voor de familie bouwen en al twee html-boeken heeft gelezen. Want Business Analist is geen beschermd beroep.

Wat klopt hier nu niet? In de eerste plaats dat het beroep niet beschermd is, natuurlijk en dat iedere Hannes zich als zodanig mag presenteren. Daarvoor wordt momenteel een stokje gestoken. In Utrecht heeft medio november de oprichtingsbijeenkomst plaatsgevonden van de Dutch Chapter van het IIBA, het International Institute of Business Analysis (zie elders in dit nummer). Deze splinternieuwe beroepsvereniging gaat zorgdragen voor betere opleidings- en certificeringsmogelijkheden. Zodat de BA beter en duidelijker gekwalificeerd en daarmee van groter belang is voor de business.

Wie zijn dan nu die BA’s, als er geen geschikte opleiding is? Veelal analytische autodidacten met een opleiding c.q. achtergrond in (technische) bedrijfskunde, bedrijfseconomie of de IT (-architectuur). Tot zover is er met deze professionals niet eens zo heel veel mis. Maar ook hier is volgens mij iets niet in orde. Dat is de plek, waar de business analisten zich bevinden. In veel gevallen maken zij deel uit van de IT-staf en vallen onder de CIO. Dat vraagt om moeilijkheden.

CIO’s en alles wat daaronder hangt zijn veel te veel met IT bezig om ooit de business te kunnen begrijpen. Te wéten wat het bedrijf nodig heeft. Niet omdat de CEO of afdeling XYZ dat heeft gevraagd, maar omdat het bedrijf het nodig heeft. Dat is niet hetzelfde. Daarom is de Business Analist zo belangrijk. Die doet zijn of haar werk door alle lagen van het bedrijf heen, En daarbuiten, want ook daar zijn de nodige steakholders te vinden. Om zo’n situatie te realiseren is inderdaad een goede opleiding geen overbodige luxe. Een opleiding, waarin volledige integratie tussen business en IT centraal staat.]]> Tue, 21 Dec 2010 11:16:51 GMT <![CDATA[Lege Klerenkast]]> Mensen die me al wat langer kennen, weten dat ik graag mag koketteren met spirituele verwijzingen. Zo heb ik het de afgelopen jaren regelmatig over het zoeken naar de Zen in Technologie. Klinkt goed en het heeft niet zelden een verpletterend effect op de gespreksgenoot, vooral als je er peinzend bij kijkt. Alles verliep dus voorspoedig, tot ik er de laatste tijd steeds meer vragen over begon te krijgen. Wat ik er eigenlijk in hemelsnaam mee bedoelde, dat was de rode draad.
Welnu, ten eerste moet ik opmerken dat ik maar weinig verstand heb van Zen. Voor de paar ingewijden: ik heb nog niet eens glimp van de hoefafdruk van de Os opgevangen. Een beginner dus, en het zal ook nooit wat worden. Toch houd ik van de grote nadruk die Zen legt op de discipline van altijd maar weer oefenen, van het voortdurend verder poetsen aan de basis. Wax On, Wax Off, zoals een extreem verlichte denker het ooit noemde. Je kunt pas een worden met de kosmos en zo als je geest leeg en opgeruimd is.
Daar zit gelijk al een prachtige, extreem relevante boodschap voor de IT-wereld in: je hebt een schoon, overzichtelijk fundament nodig van infrastructuur en kernapplicaties. Pas dan kun je met succes gaan werken aan allerlei hippe, innovatieve toepassingen van technologie daarbovenop; applicaties die het verschil maken op de markt.
De echte Zen-leraren herken je aan een merkwaardig gevoel voor humor. Niet zelden is er ook de neiging tot extreem pragmatisme. Zo leerde ik ooit een eenvoudige les die me regelmatig van pas komt: als je een nieuw kledingstuk koopt, gooi er eerst twee weg. Zo behoud je het overzicht en geniet je optimaal van je nieuwe aanschaf. Iets toevoegen brengt daarmee steeds een welkome gelegenheid om op te ruimen.
Waarom dit principe ook niet toepassen op onze applicaties? We weten ondertussen maar al te goed dat de dichtgeslibde, verstikkende applicatielandschappen van vandaag de grootste belemmering zijn om vooruit te gaan. Ze voelen aan als volgestouwde klerenkasten waarvan je de deur niet eens durft open te maken. Bang voor wat er allemaal uit zou kunnen vallen. Wat zouden we graag meer werken aan een nieuwe generatie van toepassingen, gebaseerd op moderne technologie en veel dichter bij de behoeften van de organisatie. Maar om dat te kunnen doen moeten we eerst ruimte maken, door onze bestaande applicaties ingrijpend te rationaliseren.
Als je een nieuwe applicatie toevoegt, gooi er eerst twee weg.
Klinkt goed als vuistregel voor 2011, nietwaar? Heel handig als we bezig zijn met het opstellen van de applicatie- en projectenportfolio voor het nieuwe jaar. Of als er weer eens iemand het kantoor binnen komt rennen met een baanbrekend idee voor een nieuwe toepassing. Het zet het nobele ambacht van applicaties uitschakelen (ondertussen een stuk belangrijker dan het bouwen van applicaties; hallo universiteiten, curriculum?) eindelijk eens in de schijnwerpers. En het verbindt opruimen onlosmakelijk met construeren. Dus jij denkt dat je iets kunt bouwen? Maak er eerst maar eens ruimte voor.
Afscheid nemen van je eigen, ooit diepbeminde kindjes is een emotioneel proces. In de praktijk merk je dat het uitschakelen van applicaties niet alleen een kwestie is van het hebben van de juiste applicatie ‘intelligence’, een paar handige tools en een solide business case – hoewel dat alles wel behoorlijk helpt -. Het is vooral ook een kwestie van inlevingsgevoel: empathie voor de mate van veranderingsgezindheid en de persoonlijke drijfveren van degenen die betrokken zijn bij de applicaties.
Maar goed, er valt nog veel meer te zeggen over dit belangwekkende onderwerp. Misschien moeten we maar eens met een nieuwe blik naar de titel van dit blad gaan kijken: Release Magazine. Voelt u hem? 2011 wordt het jaar van het enthousiast uitzwaaien van applicaties. Leeg, die klerenkast.
]]> Tue, 30 Nov 2010 15:08:51 GMT <![CDATA[Bloed op je CV!]]> Dat je bloedgroep uitmaakt wanneer je een operatie moet ondergaan of een bloedtransfusie krijgt , is evident. Ook als je bloeddonor bent. Enige tijd geleden hoorde ik dat je op basis van je bloedgroep een specifiek dieet kunt volgen. Degenen die mij kennen, weten dat ik daar geen enkele affiniteit mee heb. Een collega vaart er wel bij.

Dit bloedgroependieet is bedacht door natuurarts Peter d’Adamo. Je hebt 4 bloedgroepen:  O, A, B en AB. Bepaalde voedingstoffen zouden beter passen bij de stofwisseling van de mens met een bepaalde bloedgroep.  Je kunt (in het kort) de volgende bloedgroepdieet types onderscheiden:

O:           de jager:                             eiwitrijk eten

A:           de vegetariër :                 granen, noten en groenten

B:            de nomade:                      gevarieerd (vis, vlees, groenten)

AB          de moderne mens:        specifiek gevarieerd ( forel, lamsvlees, etc.)

Dit zou komen door antigenen in voedingstoffen die de betreffende types beter kunnen verteren. De resusfactor (positief of negatief) is hier niet belangrijk. D’Adamo zal, toen hij dit bedacht, nog niet van programmeurs hebben gehoord, of hij is gewoon het dieettype cola-fastfood vergeten op te nemen.

Nu hoorde ik laatst dat het in Japan gebruikelijk is om je bloedgroep op te nemen in je CV. Werkgevers denken dat ze daar eigenschappen aan kunnen aflezen.  De Japanse psycholoog Furukawa Takeji probeerde  vanaf 1927 verbanden te leggen tussen persoonlijkheden en bloedgroepen. De onderzoeken resulteerden  in 1971 in het boek 'Ketsueki-gata de wakaru aisho' “Inzicht in affiniteit van bloedtypen” van de psycholoog Masahiko Nomi . In het kort komt het onderscheid in bloedgroepen en de daarbij behorende eigenschappen hierop neer:

O:           positief: trendsetter, vol zelfvertrouwen, loyaal, onafhankelijk, hartstochtelijk en ambitieus

               negatief: ijdel en jaloers

A:           positief: gevoelig, kalm, geduldig, verantwoordelijk , opofferend

               negatief: koppig, afhankelijk en niet in staat te relaxen

B:            positief: individualist, vrijdenker, optimistisch, sterk, creatief en flexibel

               negatief: wild en onvoorspelbaar

AB:         positief: logisch, rationeel, gebalanceerd, kritisch, sociaal

               negatief: weifelend, afstandelijk en aandachtvragend.

Lekker overzichtelijk, die 4 types. En ook heel voordelig voor de business, want hiermee kun je hele HR-afdelingen overboord kieperen. Eén mannetje of vrouwtje met het boek van Nomi in de hand en een goede functie-omschrijving, opgesteld door het afdelingshoofd, zijn voldoende om te recruteren.

Wij zoeken:

Een software-architect: Dat is natuurlijk een A. Ook iets voor een boekhouder, lijkt nauwgezet….
Een Agile ontwikkelaar: Dat moet een B zijn. Of met al die dominantie, een marketeer of verkoper.
Een tester: Duidelijk een AB. Dat lijdt geen twijfel.
Een manager: Als dat geen O is, breekt mijn klomp. Neem maar eens wat CTO’s in gedachten.

Goede dingen ontstaan uit een clash met de heersende tijdsgeest zoals het Agile manifest in reactie op de topdown en proceduregerichte wijze van leidinggeven . Uit het Oosten komen goede zaken zoals Lean, meditatietechnieken, mentale & fysieke balans en lekker eten (met veel vis-eiwit, dus vooral geschikt voor O’tjes).

In IT teams is innovatie erg belangrijk. We zijn het er allen over eens dat vooral variatie nodig is voor een 360 graden blik op echt waardevolle opleveringen. Dus naast verschillende vakbekwaamheden, ook variatie in persoonlijkheid (m/v), leerstijlen en enige klik tussen de teamleden. We hebben daarvoor ook andere – naar mijn mening even slecht gevalideerde - meetlatten zoals Belbin, MBTI en Kolb en de regelmatig krukkig uitgevoerde assessments. Nu kunt u de bloedgroeptest eraan toevoegen. Op naar een OABAB-team dat met motivatie, een hoge mate van zelfdiscipline en zo weinig mogelijk sturing prima kan functioneren!  

Ik hou het liever op een nuchtere Hollandse blik op de inhoudelijke CV. Op de uitkomsten van een prettig en open sollicitatiegesprek. Op criteria betreffende diversiteit in het team of in het bedrijf.

]]> Tue, 19 Oct 2010 16:48:43 GMT <![CDATA[Droom]]> Ik had kortgeleden een verschrikkelijke droom. Er werd gebeld. Rick van der Lans en Sander Hoogendoorn stonden voor de deur (nee wacht nou, het wordt nog veel erger). Of ik lid wilde zijn van een jury. Het zat zo, iedereen vond dat het tijd werd voor een doorbraak in programmeertalen. Al jaren en jaren hetzelfde, er zat geen pit meer in de industrie. Iemand had daarom het idee opgevat om er een talentenjacht aan te wijden.

Een beetje in de stijl van Idols en X Factor, waarin de programmeertalen zich zo goed mogelijk konden presenteren. Het leek me wel wat. Bovendien had ik weinig beters te doen. Ik zegde de paar directieafspraken van die dag af en ging mee met beide heren. Eenmaal aangekomen in de studio kwam ik erachter dat Patricia Paay ook deel uitmaakte van de jury. Een veelzijdig type, zoveel was duidelijk
 
We kregen een stortvloed van audities te verwerken. Veel vet coole types met afgezakte spijkerbroeken, tatoeages en petjes. We zagen Python, PHP en het uiterste hippe duo Ruby en Rails. Ook was er het 12-jarige tienersterretje Go, ondanks haar leeftijd en geringe ervaring al een behoorlijk kapsoneswijf. Slimme beats, veel jatwerk maar een beetje leeg: zo zagen we er veel voorbij komen.
 
Nu kwam er een sikkeneurige kerel het podium op. Hij keek ons misprijzend van achter zijn brillenglazen aan, alsof hij het onzin vond dat hij auditie moest doen. Zuchtend pakte hij een indrukwekkende instrumentarium uit. Hij begon de boel in te regelen. Van alles moest gestemd en met elkaar verbonden worden. Een complexe taak, dat kon je goed zien. Zo nu en dan kregen we een minachtende blik toegeworpen. Amateurs waren we, dat werd ons goed ingewreven. Na een kwartier was er nog steeds geen noot geproduceerd. De juryvoorzitter was al enige tijd geleden ingedommeld, maar schrok nu op en drukte op een bel. De tijd was verstreken. Java haalde zijn schouders op en liep hoofdschuddend de coulissen in.
 
Er werd ook nogal wat geïmproviseerd. Zo hadden we de broers VB, ASP en Javascript, allen met behoorlijk losbollige acts. Talent hadden ze wel, dat zal ik niet ontkennen. En ze hadden ook een vlijmscherp gevoel voor wat het publiek leuk vond. Desnoods gooiden ze halverwege hun optreden het roer totaal om als daar harder voor werd geklapt. Javascript sprong zonder aarzelen op schoot bij mevrouw Paay om er een gierende trompetsolo tegenaan te gooien. Ze moest ervan giechelen. Er ging van alles mis tijdens de optredens en er was weinig gerepeteerd. Maar op de tribunes braken ze de tent af.
 
Dan waren er de 4GL exoten. Onpeilbare Willie Wortels die zo te zien jaren thuis – in totale afzondering - aan hun voorstelling hadden gewerkt. Er was al menig lokale programmeerwedstrijd mee gewonnen. Er werd gedeclareerd en gegenereerd bij het leven. Indrukwekkende, beladen melodieën schalden door de zaal. Maar iedereen zong in een eigen, zelfverzonnen taal die door de rest niet werd begrepen. ‘Leuk voor in de provincie, maar in de grote stad gaat dat echt niet werken’ mompelde Patricia naast me.
 
Vlak voor het einde kwam er nog een grijzende kerel in smoking op. Er werd gegniffeld. De juryvoorzitter vroeg hem wat hij in het dagelijkse leven deed. “Ik werk al 40 jaar als assistent-klerk op administratiekantoor Voskuil” vertelde Cobol trots. Iemand op de tribune begon hysterisch te lachen. Toen begon Cobol te zingen: een moeilijke, gedragen aria die loepzuiver werd afgewerkt. Indrukwekkend, hoewel het hitpotentieel nogal onduidelijk was.
 
Nu moest er worden gejureerd. Een zooitje. Uiteindelijk staakten de stemmen en moest ik de beslissing nemen. Van alle kanten werd er geschreeuwd. Het zweet brak me uit. Paay fluisterde in mijn oor: “maak je geen zorgen, er kijkt toch niemand naar deze onzin”.
 
Ik schrok wakker. Er werd gebeld. Ook nog eens een recursieve droom, zul je altijd zien.
]]> Tue, 21 Sep 2010 11:05:39 GMT <![CDATA[BI X BT = 2BIT]]> Alles lijkt tegenwoordig te draaien om Business Intelligence. Business’ wil is wet. Maar over welke business hebben we het dan? Over banken, pensioenfondsen en verzekeraars die plotseling intelligent willen doen? Op zich lijkt me dat een goed idee, want gezien de ontwikkeling in de afgelopen jaren kunnen ze in deze branches wel wat intelligentie gebruiken. Of praten we over de IT als business, die eerst de andere business heeft volgestopt met – deels nutteloze – technologie en nu om het hardst roept dat dit niet slim was en meer rekening moet worden gehouden met de (andere) business. Om daarmee in de IT als business te kunnen overleven.

Business Technology is ook zo’n modewoord, dat je te pas en te onpas hoort vallen. Iedereen zit tegenwoordig ‘in de BT’. Althans, tot wij van Array de belangstelling peilden. Want dan blijkt plotseling lang niet iedereen op te hoogte te zijn van BT en zich af te vragen wat daar dan wel precies onder valt. Wie het weet mag het zeggen.
Ik denk dat ik het weet, maar dat zegt op zich niet zo veel. Op school zat ik vaak achterin de klas te tekenen, dus dan weet u het wel. Omdat ik veel ezelsbruggetjes nodig heb om dingen te kunnen onthouden (en dat geldt helemaal voor de IT-acronymen) heb ik voor mezelf maar deze formule bedacht. Hiermee hoop ik de IT van een kennelijk alom aanwezige frustratie af te helpen, gezien het aantal keren dat je IT-ers over het belang van ‘de business’ hoort spreken. De business mag nog steeds blij zijn met de technologie als compensatie voor de ontbrekende intelligentie om de economie weer op de rails te krijgen.
To Business Intelligent Technology dus. En liefst zo snel mogelijk. Bij het ter perse gaan van dit nummer was de verkiezingsuitslag nog niet bekend, maar ook zonder die uitslag kun je op je vingers natellen dat de business het niet makkelijk zal krijgen. Een beetje hulp van de technologie zal de komende jaren zeer welkom zijn.
Technologische hulp is in ruime mate aanwezig, zien wij bijna dagelijks. Vrijwel alle grote vendors zijn bezig met het vernieuwen van hun stacks, of hebben dat recent gedaan. Denk maar aan de BI(T)-platforms van Microsoft, Oracle, SAP, IBM en de vele aanbieders van modelleertechnieken en toolsets.
Zij hoeven zich als 25 jaar oude bedrijfstak niet te schamen voor het feit dat er wellicht nog te weinig spaken in het IT-wiel zitten. De business mag blij zijn dat het draait en dat ze daarmee de kans krijgt haar fouten uit het verleden te corrigeren.
Waarom dit hele verhaal? Om u als i-techneut een hart onder de riem te steken. Om u aan te sporen vooral door te gaan met technologisch ontwikkelen. En omdat wat mij betreft de scheidingslijn tussen business en IT mag verdwijnen.
U zult samen 2BIT moeten komen.
 

]]> Tue, 08 Jun 2010 14:59:10 GMT <![CDATA[A model says more...]]> De beslissing om een schip te bouwen werd echter niet gemaakt op basis van de bouwtekeningen, omdat deze veel te lastig te begrijpen waren. Naast de bouwtekeningen werd  ook een model gemaakt, een kleine versie van het te bouwen schip, maar wel volgens de bouwtekeningen. Dit model werd vervolgens gebruikt in de discussies over het te bouwen schip.  Men ging letterlijk rond de tafel staan waar het model op stond en besprak de details. Het model werd vervolgens ook gebruikt om zaken te testen. Het werd bijvoorbeeld in een waterbak gedaan om te testen hoe het zich gedragen zal bij bepaalde golfslag.
Dit lezende werd ik me bewust van een fout in het denken binnen de software wereld. Wat wij in software het model noemen is geen model! Het is niets meer dan een bouwtekening. Dat klopt als een bus, als je naar typische UML modellen kijkt hebben die ook dezelfde eigenschappen als de bouwtekeningen van een schip. Het is lastig om te begrijpen wat er precies de bedoeling is, en zeker voor eindgebruikers is het model onbegrijpelijk.  Wat in de scheepsbouw een model genoemd wordt bestaat in de software niet of nauwelijks. Wat het dichtst bij komt is een prototype, waarbij we een mockup maken van het te bouwen systeem. De essentie van een scheepsmodel is dat het realistisch is, dat wil zeggen dat het op een aantal cruciale aspecten voldoende lijkt op het echte schip. Dat is noodzakelijk omdat je uit model conclusies over het schip moet kunnen trekken.
In software is het daarvoor nodig om het prototype voldoende op het te bouwen systeem te laten lijken. Het aspect waar in prototypes meestal de focus op ligt is de user interface. De vraag is of dat voldoende is. Tevens is een user interface prototype vaak met andere technologie gebouwd dat het echte systeem, waardoor het prototype feitelijk niets meer zegt over het te bouwen systeem.
Mijn conclusie is dat realistische prototypes hard nodig zijn in de software wereld.  Iteratieve ontwikkeling en agile methodes gaan deze richting al in.  Er wordt zo snel mogelijk echte software opgeleverd, zodat gebruikers in een vroeg stadium al een realistisch idee bij het systeem kunnen krijgen. Belangrijk is dat we vooraf bepalen in welke aspecten een prototype op het echte systeem moet lijken, zodat we in staat zijn om op basis van het prototype kenmerken van het echte systeem te voorspellen. 
De enorme stapels met documenten met functionele modellen, UML modellen etc. die we vandaag de dag gebruiken om “gebruikerswensen” vast te leggen schieten hun doel volledig voorbij, er is geen gebruiker die deze “ modellen” begrijpt, het zijn immers slechts bouwtekeningen. Geef de gebruiker maar een “echt” model zodat hij met eigen ogen kan zien wat er gebouwd gaat worden.
]]> Tue, 08 Jun 2010 14:20:13 GMT