We kennen ze wel, de strategische adviezen, architecturen, governance-documenten en andere goedbedoelde stukken rond it-oplossingen die niet of maar deels opgeld vinden of zelfs in een la verdwijnen. En we blijven er geld aan uitgeven en ons afvragen waarom het niet goed werkt. Hoe kunnen we dit wél effectief maken?
In de it zijn we goed in het automatiseren van processen om het de beheerder of ontwikkelaar makkelijker te maken. Maar het geautomatiseerd controleren en afdwingen van beleid lijkt ons nog steeds niet zo goed te lukken. Waarin zit hem dat nou?
Zero-touchbeleid
In het cloudtijdperk is het grootste doel om zero-touch te werk te gaan. Alles wat met testen, uitrollen, beheren en monitoren te maken heeft, gebeurt op basis van scripts. Dit kan niet anders in een continuous integration and deployment (ci/cd)-omgeving waar time-to-market heilig is en cloud-ontwikkelingen steeds sneller op ons af komen. De ontwikkelaar en beheerder wordt het op deze manier gemakkelijk gemaakt. Maar of wat er ontwikkeld en in productie wordt genomen, voldoet aan de strategie, principes, architectuur en overig it-beleid wordt tot op de dag van vandaag grotendeels handmatig en steekproefsgewijs gecontroleerd – met in de ene hand het beleidsdocument en de andere hand met opgestoken wijsvinger.
Het wordt tijd dat ook het toepassen van beleidsregels verregaand geautomatiseerd wordt. Zodat de regels die ooit bedacht zijn zo volledig mogelijk automatisch worden gecontroleerd. Niet alleen steekproefsgewijs of ingebed in een proces, maar realtime en automatisch.
Smart governance
Beleid automatiseren kan niet door het in documenten te blijven beschrijven. Dit moet gebeuren in uit te voeren code (scripts) wat onder versiebeheer ontwikkeld is. Net als smart contracts die op blockchains draaien, moet er smart governance komen.
Hallo Gijs,
Interessant artikel en ons uit het hart gegrepen. In het kader van de verregaande digitalisering bij de overheid o.a. in de vorm van smart contracts passen wij de principes van Regelbeheersing toe: een gestructureerd, herhaalbaar en traceerbaar proces waarlangs beleid wordt vertaald naar eenduidige specificaties. Deze zijn direct om te zetten naar code.
Proeven met Smart Contracts zijn zeer veelbelovemd en in grote administratieve systemen zijn al veel toepassingen.
Dus we pakken de uitdaging graag op: http://www.iam4.com.
Bas Janssen
Vroeger schreeuwde alleen directeur dat alles met een druk op de knop moet gebeuren.
Nu ook ook de CTO’s.
“Strategie, principes, architectuur en overig it-beleid”, probeer dat maar eens automatisch te testen in je pipeline, zeker als die begrippen ook nog eens wendbaar ineens kunnen wijzigen. En hoe leggen we de gewenste sjoemelfactor vast, het belastingontduikbeleid, definition of bijna done, het oprekken van de sprints, het politieke spel..
Onweer is fout, zonnetje is goed.
Wordt ICT nu steeds makkelijker of moeilijker ?
Mijn eerste reactie: wij moeten eens iets gaan drinken samen, volgens mij kunnen we veel van elkaar leren 😉
Het “automatiseren van beleid” is iets waar ik ook al het nodige van gezien heb, maar de grootste uitdaging is de factor mens. Op het moment dat ontwikkelaars zich gehinderd voelen door het beleid, krijg je als je niet uitkijkt een kat en muis spel tussen de automatiseerder en de ontwikkelaar. De één probeert te controleren, de ander te omzeilen.
Nu kun je een boel energie gaan steken om te begrijpen waarom deze ontwikkelaar zo graag het beleid wil omzeilen, maar wellicht moet je als bedrijf op een gegeven moment ook afscheid durven nemen van deze mensen (zo zijn bijvoorbeeld sommige beleids-uitvoeringnen een must voor een bepaalde industrie, of je nu wilt of niet. Wil je hier niet aan voldoen, is die industrie/sector dan wel geschikt voor jou????)
We zijn doorgeslagen met onze regelgeving – lijkt een doel op zich te zijn geworden: beleid en beleidsregels.
Met in het verlengde allerhande controle-instrumenten en management rapportages om aan te tonen dat aan die regelgeving wordt voldaan.
Blijkbaar dan nu de volgende stap: hoe automatiseer je dat hele zootje?
Met als denk- en werkkader: “We moeten aan die beleidsregels voldoen maar zien het nut er eigenlijk niet van in. Hoe kan ik met zo weinig mogelijk inspanning/kosten aan die regels voldoen. Want dadelijk zit er weer een-of-andere GDPR-achtige jurist in mijn nek te hijgen vanwege het niet compliant zijn.”
Twee alternatieven (om mee te beginnen):
(1) – stuur die jurist naar huis en tjek eerst eens in hoeverre allemaal die beleidsdocumenten en dito regels nog houtsnijden. Misschien is het merendeel alweer achterhaald door de vele wijzigingen in de afgelopen 1-2 jaar; we zijn immers een hippe, agile organisatie.
(2) – in plaats van (opnieuw?) beleid en regels te maken met in het verlengde (geautomatiseerde?) handhaving lijkt het me handiger om eerst eens wat tijd en energie te steken in het automatiseren van systeem documentatie van de verschillende applicatieketens.
Want alle beleidsregels, handhaving en versienummers ten spijt:
Wie weet op enig moment nog wat er allemaal aan elkaar geknoopt is en waar allemaal die scripts op ingrijpen?
Met in het verlengde: stel er valt ergens iets om, hoe kom je er dan nog achter wat nou precies de oorzaak is?
Zodat je kunt werken aan een “echte” oplossing (versus de zoveelste workaround).
Immers, de ZZP-ers die het 1-2 jaar geleden allemaal bedacht en gebouwd hebben zijn er niet meer…
@PaVeKa (van achter naar voren – een paar vragen = stof tot nadenken):
Stel je neemt inderdaad afscheidt van iedereen die kritiek heeft op die beleidsregels en bijbehorende uitvoering (want past niet bij onze “cultuur”). Dan hou je uiteindelijk alleen maar ja-knikkers over. Gaat zo een organisatie daar dan echt beter van worden?
Zijn allemaal die wettelijke/juridische bepalingen dan een geldig excuus om niet meer na te denken en “domweg” uit te voeren?
Wat is in het kader van dit artikel het verschil tussen een (software?) ontwikkelaar en een automatiseerder?
🙂
@Will … ik gebruikte “industrie”, niet “cultuur”, en dat was een bewuste keuze.
Financiële transacties, medische diagnostiek, automotive … typische industrieën waar je aan veel regels gebonden bent. Daar hoef je je niet aan te houden, maar dan wordt het wel heel uitdagend je product in de markt te zetten.
Wat betreft je laatste vraag: in plaats dat de ontwikkelaar documenten moet gaan schrijven (om te voldoen aan de regels) kan een automatiseerder voorzien in een omgeving van tools en scripts waarbij documenten gegenereerd kunnen worden (bijvoorbeeld het genereren van releasenotes)
Wat betreft de juristen heb je wel een heikel punt te pakken. Nieuwe juristen, nieuwe interpretatie van wetten en regels en daarmee nieuwe manieren van werken. Echter, dit kan ook meer werk betekenen in plaats van minder.