Over goede, betrouwbare ICT systemen. Regulering door Law, Norms, Architecture and Market.

2. Vertrouwen & IDM

3. Wanneer is een systeem goed
en betrouwbaar?
Wat is goed? Wat is betrouwbaar?
Compliant?
Gebruiksvriendelijk?
Innovatief?
Geld verdienen?
Geld besparen?
Veilig?

4. ICT-Systemen: het
krachtenveld

5. Reguleren> het sturen van
gedrag
“...the sustained and focussed attempt to alter
the behaviour of others according to
standards or goals with the intention of
producing a broadly identified outcome or
outcomes, which may involve mechanisms of
standard-setting, information-gathering and
behaviour-modification.”
– Julia Black (2005)

6. Wat is juridische regulering?
Wetten,
grondwetten,
verdragen,
beleidsregels,
contracten,
rechtspraak,
algemene
voorwaarden

7. Wat is sociale regulering?
Geldende normen en
waarden (maatschappij,
maar ook kleiner),
educatie & awareness,
individueel gedrag

8. Wat is regulering van/door de
markt?
Stimuleren van
gunstige voorwaarden
(overheid),
concurrentie,
zelfregulering

9. Wat is technologische
regulering?
Juridische, sociale en marktnormen inbouwen in
de technologie

10. Systemen en hun werking - de
vier krachten
Gedrag wordt nooit door alleen 1 kracht gestuurd
Een vraagstuk of probleem is slecht op te lossen door
maar naar 1 kracht te kijken (of vanuit maar 1 kracht
te kijken)
Altijd spelen er meerdere belangen (compliant zijn, geld
verdienen, gebruiksgemak, de gemakkelijke
gebruiker, geld besparen, etc)

11. Dus als je een systeem bekijkt
(of wilt gaan ontwerpen)
Dan hou je rekening met alle vier de krachten
en onderzoek je het liefst van tevoren welke
eisen (requirements) deze stellen aan een
goed (betrouwbaar) systeem
Goed kan dan zijn: Compliant, Gebruiksvriendelijk, Winstgevend of
besparend,Veilig, Etc.

12. Hoe vertaalt zich dat?
Juridische vereisten:
- Voldoen aan de wetten en regelgeving (en evt.
interne of externe gedragscodes), welke zijn
relevant?
- Dus: welke wetten gelden er en die nalopen, maar
ook: hoe integreer ik dat in het systeem op een
correcte manier?
- En idealiter: vooraf definiëren, gaandeweg monitoren,
aan het einde testen, in de toekomst blijven
monitoren (testen)

13. Sociale vereisten
- Inventariseren van de sociale normen die van
toepassing zijn in het onderhavige geval
- Denk aan: Wat verwachten gebruikers? Hoe zitten
die in elkaar? Hoe gaat de mens om met systemen?
- Maar ook: Values built into the design by the
designers (onbedoeld)

14. Economische vereisten
- Kan ik er geld mee verdienen?
- Kan ik er geld mee besparen?
- Wat is een werkend businessplan?
- Dus: inventariseer de risico’s, opbrengsten en de
investeringen

15. Technische vereisten
- Hoe vertaal je de normen naar de technologie?
- Hoe ontwerpen we een veilig systeem?
- Is het technisch gezien mogelijk om alle requirements
in te bouwen?
- En: als aan alles gedacht is> werkt het dan nog steeds
zoals we aan het begin wilden dat het zou gaan
werken?

16. En waar loop je in de praktijk
dan tegenaan?
Een paar
kleine
voorbeeldjes

17. Wij spreken
elkaars taal
niet

18. We zijn ook maar mensen

19. Met onze vooronderstellingen

20. En, nog zoveel meer...
Compliant zijn, maar toch slechte pers krijgen.
Imagoschade. Wettelijke eis slecht (of erg duur)
technisch te vertalen. Concurrentiestrijd.
Businessmodel en compliancy verhouden zich
moeilijk. Wetswijzigingen. Gevallen kabinet, nieuwe
verkiezingen, nieuwe prioriteiten. Nieuw personeel.
Alles werkt, nu de mensen nog opleiden. Weer een
nieuwe wettelijke eis. Internationale verhoudingen,
verdragen. Technologische vooruitgang: sluit het nog
aan bij de andere vereisten? Cross border data
transfer issues. Breach notification. Het systeem
heeft onvoorziene werking. Etc, etc, etc..