Tuesday, October 23, 2012

Open Overheid Congres

In 2011 stopte het programma Nederland Open in Verbinding (NOiV), het laatste initiatief van een serie die in 2006 begon naar aanleiding van de Tweede Kamer motie Vendrik om open source software vanuit de overheid te gaan promoten. Maar NoiV had wel een traditie opgebouwd van jaarlijks terugkerende voorjaarsconferenties. Die voorjaarsconferentie is nu overgenomen door ECP in samenwerking met een paar andere sponsors. Wel handig van ECP (electronic commerce platform) want volgens mij leiden die een zieltogend bestaan zonder aansprekende manifestaties; en ze moeten toch ergens hun budgetten spenderen. Maar nu dus het Open Overheid Congres, met absoluut interessante sprekers en weer een grote opkomst. Toch wel een paar honderd man in het congresgebouw van de Utrechtse jaarbeurs, op 31 mei 2012.
De directeur van KING (coƶrdineert e-overheidsprojecten voor de Nederlandse gemeenten) pleit als spreker uiteraard voor samenwerking tussen gemeenten. Zelf het wiel uitvinden is dom. Hij maakt een goede opmerking: Je moet als gemeente niet je eigen identiteit willen uitstralen door je eigen IT te bouwen, maar door je eigen maatbehandeling van je burgers. En gebruik daarvoor dan IT-hulpmiddelen die alle gemeenten gezamenlijk aanschaffen.
Voor de workshops heb ik gekozen voor de track 'grensverleggend'. Nederland is een handelsnatie en kan zijn positie versterken door de transactiekosten te verlagen. In de transactieketens sluiten de geautomatiseerde systemen niet altijd op elkaar aan. Verschillende sprekers geven daarin inzicht. Yao-Hua Tan, hoogleraar ICT aan de TU Delft, spreekt over Interoperabiliteit en Standaarden voor Internationale Handel.
Nu is het bekend, dat er internationaal al jarenlang wordt gesproken over standaard-interfaces. Edifact, voor manufacturing, voor accounting etc. Maar het verrassende in het verhaal van Tan vond ik, dat er veel Business Process Redesign inzit. Ik herinner me in de jaren tachtig de oproep van Hammer & Champy: “Don't automate, obliterate”. Dus niet de oude situatie klakkeloos van papieren processen overzetten naar digitale processen. Maak van de gelegenheid gebruik om onnodige processtappen te elimineren. Dan boek je pas echt grote winst. Hij noemt een voorbeeld van handelstransacties met China betreffende plantenuitvoer. Je kunt automatiseren door allerlei klassieke vrachtbrieven, schimmelcertificaten etc naar digitale formulieren om te zetten. Maar die papieren zijn vroeger alleen ingevoerd omdat de handelspartners voor verzending en na ontvangst van de goederen allerlei gegevens omtrent de goederen moesten bevestigen en controleren. De papieren bewijzen maakten dat mogelijk. Maar, zegt Tan, je kunt beter faciliteren, dat de handelspartners via de cloud rechtstreeks in elkaars bestanden kunnen kijken. En dat is pas innovatie! Het garanderen van echtheid en kwaliteit gebeurt dan niet door het achteraf nalopen van de papieren, maar moet aan de bron gebeuren door verificatie van de bronnen. Er zullen afspraken moeten zijn over de activiteiten van EDP-auditors. Afspraken die wereldwijd worden gemaakt en nageleefd. De spreker wordt gevraagd, of Nederland in deze internationale overlegverbanden wel een rol kan spelen. Hij antwoordt, dat het zelfs zo is, dat andere landen zoals Duitsland en Frankrijk dit graag aan Nederland overlaten. Zelf zijn ze met hun ambtelijke structuren niet in staat om over zulke vergaande verandering mee te praten. Blijkbaar kan Nederland daar toch een pioniersrol vervullen. Hetgeen ook winst oplevert voor ons internationale bedrijfsleven. Het forum Standaardisatie verstrekt daarvoor een handreiking (www.forumstandaardisatie.nl/themas/internationale-ontwikkelingen/).
Al jaren volg ik de programma's, die vanuit de overheid verdere automatisering en standaardisering stimuleren. En over een lange reeks van jaren zie je weldegelijk hoe het vooruit gaat. Blijven doen dus. De druppel holt de steen... De aanhouder wint...

Tuesday, October 9, 2012

Schuldenproblematiek bij softwareontwikkeling

Het vroegere Cibit gaat na een management buy-out nu door het leven als Inspearit. Zij profileren zich nog altijd als deskundigen als het gaat om beoordelen van softwareontwikkeling en softwarekwaliteit. Op 19 juni 2012 organiseerden zij een seminar over Technical Debt.
Amerikaanse onderzoekers hebben de term Technical Debt ingevoerd, om aan te geven, dat je bij de ontwikkeling van software gebreken kunt inbouwen, die je later gaan opbreken cq geld gaan kosten. De parallel met de schuldenproblematiek van landen vond ik zeer intrigerend.
De belangrijkste spreker was een vrouwelijke onderzoeker van het Software Engineering Institute van Carnegy Mellon University in Pittsburgh: Ipek Ozkaya. Zij werkt in de vakgroep Architecture Centered Engineering. Zij licht achtergronden van Technical Debt toe. De term is bedacht door Steve McConnell. Hij onderscheidt twee typen van deze schuld. De eerste is onbedoeld en wordt veroorzaakt doordat een systeem wordt opgeleverd met foute specs en met fouten in de programmatuur. Ozkaya gaat daar verder niet op in, want kwaliteitssystemen en testen vindt ze vanzelfsprekend. Om de analogie met 'schuld' uit te werken: Als je schulden maakt, moet je rente betalen. Als je een onvolkomen systeem invoert, zul je in de loop der tijd kosten maken voor allerlei correctief onderhoud. Deze kosten kun je zien als de rente, die je betaalt over de aangegane schuld.
Het tweede type schuld is interessant. Je kunt namelijk bewust een onvolkomen systeem invoeren. Bijvoorbeeld om je time-to-market te verkorten. Bewust neem je dan als consequentie, dat je na enige tijd het 'quick and dirty'-systeem overnieuw moet bouwen, of dat je fiks correctief onderhoud zult moeten plegen. Dit is dus een strategische keuze, die verantwoord is, als je door de kortere time-to-market extra inkomen genereert, dat ruimschoots de betaalde rente overtreft.
Harm Spoor van Inspearit introduceert een kwadrant met IT Alignment langs de verticale as en IT Effectiveness langs de horizontale as. Ik interpreteer IT Effectiveness daarbij als een goed geleide IT-organisatie die de operaties foutloos laat draaien en die storingen bliksemssnel signaleert en oplost. De klassieke uitdaging is weer om van linksonder (Maintenance Zone) te komen in het kwadrant rechsboven ( IT enabled growth). Ga je via linksboven (alignment trap) of via rechtsonder (well-oiled IT)? Het eerste pad wordt meestal gekozen vanwege martkdruk en de noodzaak tot snelle aanpassing. Maar hier loopt men risico om technical debt op te lopen. Iedereen kent wel de situatie, dat snel een pakket moet worden ingevoerd om een produkt te kunnen introduceren. Het tweede pad (eerst de IT geheel op orde brengen) is de koninklijke weg en die duurt natuurlijk weer te lang. Volgens Spoor wordt vaak een duale aanpak gekozen. Waarschijnlijk dan de quick-and-dirty route voor strategische innovaties en de meer solide route voor de ondersteunende, meer intern gerichte systemen.
Ipek Ozkaya waarschuwt, dat ook de koninklijke weg gevaren kent. Bijvoorbeeld het gevaar van over-architecting. Ik kan mij dat helemaal voorstellen. De intern gerichte mensen, die steeds maar hun plaatjes blijven verfijnen en niet de sense of urgency voelen voor wat er in de markt gebeurt.
Zij besluit met drie strategiƫn voor de aanpak van technical debt:
1. Do nothing. Things will get worse.
2. Replace. High cost and high risk.
3. Incremental refactoring. Commitment to invest.
Alle drie de opties (ook de eerste!) kunnen geboden zijn. De beslissing vereist een goed inzicht in de interne en externe situatie van het bedrijf.