Security is in een aantal opzichten precies als andere functionaliteiten. De opdrachtgever wil iets, als professional rekenen wij de gevolgen door, en vervolgens vallen die toch wat tegen qua tijd en kosten. En wij IT-ers gaan in de herkansing, en gaan (hopelijk samen met de opdrachtgever) aan de slag met zaken als priorisering, quick-wins en de beroemde 80-20 regel. Zeker wanneer er sprake is van standaardprodukten is het ‘de laatste 20% aan mooie dingen’ die voor 80% van de kosten en doorlooptijd kan zorgen, en het zou mooi zijn als men voor een goed-genoeg oplossing zou kunnen kiezen. Ook mogen wij als IT-ers aangeven waar business-wensen min of meer botsen, en helpen om een uitweg te zoeken.

Bij een opdrachtgever overkwam me zoiets met een identiteitsbeheer-platform. Twee jaar terug was versie 3 ‘bijna gereed’ en zelfs in proef-produktie, toen er weer een stortbak aan nieuwe wensen opdook – deels veroorzaakt door een nieuwe generatie managers, en soms akelig dicht bij de bovengenoemde gevaarlijke 20%. Gevolg: men trok de stekker er uit, en de identiteitsbeheer-aansluiters ‘moesten nog maar een jaartje langer met versie 2 doorploeteren’. Dat was dus twee jaar terug :-)
De wereld staat echter niet stil, en één der aansluiters wil zelf fors verbouwen en tekent daarvoor een miljoenencontract met een middlewareleverancier. En ah propos, er is een dependency met identiteitsbeheer versie 3. Gevolg: de niet al te goed plannende nieuwe generatie managers mag nu op directieniveau een planning opleveren, en de eerder teruggetrokken versie komt alsnog live en dán pas mogen de nieuwe wensen aan bod komen…

Vergelijkbare processen zien we elders terug. Bij een andere opdrachtgever bijvoorbeeld een Intranet-applicatie voor produktvoorstellen. Oerdegelijk en tot de komma nauwkeurig, maar soms een zandlopertje op het scherm van 20 seconden vanwege alle rekenscenario’s. De publieke website-beheerder wil best ook de produktvoorstellen erbij maar dan alleen als herontworpen wordt zodat per schermwisseling maximaal 2 seconden gewacht wordt; niet onlogisch gezien de heel andere doelgroep. Er wordt dus een roadmap gemaakt met eerst een betere Intranet-struktuur, daarna een rekenscenario-herontwerp (10+ manjaar) en tot slot Internet. Oekaze van topmanagement 3 maanden later: ‘release 2, Intranet, moet maximaal 6 maanden later gevolgd worden door de Internet-release op basis van alleen onderhoudsbudget’.
Ook deze wens om ‘ijzer met handen te breken’, of anders gezegd Keulen en Aken binnen een dag te bouwen, heeft veel hoofdbrekens gekost om de communicatie recht te breien. En dat brengt ons, net als de identiteitsbeheer-case, tot een paar wat bredere conclusies:

· Laat de opdrachtgever de keuze maken, voorzien van alle argumenten. Probeer niet zelf als IT-er de keuzen af te dwingen. Ook dit hoort bij gedragsregel 6, ‘toetsbaar handelen’.
· En waar diverse opdrachtgevende partijen het oneens zijn, is het de taak van de RI om de overkoepelende opdrachtgever te bereiken en dáár de knoop te laten doorhakken.
· Maar ook dan op basis van zuivere gegevens en afwegingen. De boven genoemde identiteitsbeheer-beslissing om het projekt te stoppen was duidelijk zonder voldoende informatie en op te laag management-niveau genomen. En de onmogelijke Internet-release eist keuzen: óf aan alle wensen voldoen óf snel opleveren en tijdelijk sommige wensen (zoals de 2 seconden respons) negeren.

En zo zien we weer dat de gedragsregels universeel inzetbaar zijn; beveiliging of websites of pakweg RfID of portals zijn allemaal nuttige specialismen maar uiteindelijk gelden overal dezelfde projektprincipes. Irreël en emotioneel gedrag kan overal voorkomen, en onze professionaliteit als RI weet daar op gepaste wijze mee om te gaan…

<Erik>