Een autofabrikant heeft vandaag de dag vele uitdagingen, van de noodzaak tot mass customization, veranderingen in mobiliteitspatronen, tot de opkomst van de elektrische auto en de veiligheidsrisico’s van connectivity. Het is een wereld waarin Sebastian Kister, bij Audi de promotor van agile werken en verantwoordelijk voor Kubernetes en public cloud, prima gedijt. Als het aan hem ligt, treedt iedereen regelmatig buiten zijn comfort zone. Een gesprek over de relatie tussen softwareontwikkeling en security in de aanloop naar een rondetafel georganiseerd onder het highly secure organisations-programma.

Wat zijn de uitdagingen op digitaal gebied voor Audi in de huidige markt?
“Digitalisering speelt in al onze inspanningen. We moeten ons sneller aanpassen en bewegen. Fail fast, en een kortere time-to-market realiseren. We hebben nieuwe metrics nodig om snel conclusies te kunnen trekken. Daarom moeten we uitgaan van de software lifecyle en niet van de veel langere hardware lifecycle. Wat we trouwens nu al doen in onze auto’s: function on demand.”

“Stel je voor: je bent onderweg, komt in de file en wilt graag een file-assistent in je auto. Hoe handig is het dat je nu die functionaliteit direct kunt kopen, gewoon in de file. Het reduceert bovendien de prijzen van de hardware. De functies worden immers door de software geboden.”

“Wij moeten bij Audi dus een softwarebedrijf zijn, met software development centers als belangrijkste afdelingen. Een van de grootste IT-uitdagingen daarbij is wel security. Een auto bevat veel simcards en is een connected en hackable device. Het is een rijdende mobiele telefoon, waarvan zowel de hardware als de software security nodig heeft. Geen wonder dat er inmiddels car ransomware bestaat!”

Wat was je eerste initiatief toen je bij Audi aan de slag ging?
“Het Kubernetes-team samenstellen, uit mensen verspreid over het bedrijf. Zij kwamen direct al met een geweldig idee: inner sourcing, oftewel samen aan nieuwe functionaliteit werken en die vervolgens binnen de organisatie delen. Toen dat team ‘stond’, ging ik op zoek naar mensen die ervaring met open source software hadden. Ik vond een dochterbedrijf van Audi, waar ze er een moderne kijk op hadden. Ik bracht hun ervaring onder de aandacht bij de juridische mensen van Audi, zodat zij de werkwijzen konden aanpassen voor het moederbedrijf. Zo gingen we doen wat we predikten met ons motto ‘Vorsprung durch Technik’!”

Op welke manier geeft open source software je een ‘voorsprong door techniek’?
“Alle bedrijven komen de zelfde uitdagingen in IT-infra en security. Hier vind je geen toegevoegde waarde voor een autofabrikant. Als we code kopiëren (forken), moeten we die aanpassen aan onze regels en onze governance. Soms maken we daarvoor tools of verbeteren de software daarvoor. Vervolgens verbeteren duizenden enthousiastelingen in de open source community de software en delen die weer. Waarom zou je dit niet zo doen? In elk geval krijg je dan geen free updates! Dit werd binnen Audi een algemene regel voor het werken met open source software: commentaar leveren, meewerken of delen binnen de open source community.”

Je hebt ook het agile werken geïntroduceerd. Een hele schok voor Audi?
“Zeker, dat is mijn rol ook: ik shockeer mensen! Maar serieus, je kunt niet 96.000 mensen veranderen. Sommigen gaan met pensioen, anderen doen direct mee, weer anderen hebben motivatie nodig. Vooral In de softwarewereld moet je steeds veranderen. Doe je één jaar hetzelfde, ben je al legacy. Het moet een sport voor je zijn om buiten je comfort zone te gaan.”

“Terugkomend op je vraag: de invloed van onze manier van werken is nog beperkt, want de traditie van het bedrijf is heel lang ‘plan-build-run’ geweest. De cycli worden korter, maar zijn ze agile? Nee, nog niet.”

“Het moet een sport voor je zijn om buiten je comfort zone te gaan”

“Als je grote projecten plant, die goed zijn voor de carrière van degenen die ze plannen, en als je een cultuur hebt van macht die door de illusie van synergie, van centralisering wordt gevestigd, verbrand je enorme hoeveelheden geld. In moderne softwareontwikkeling werk je niet meer zo. Daar gaan de ontwikkelingen te snel voor. We gebruiken programmeertalen die nog niet eens vijf jaar oud zijn! Hoe kunnen we zelfs maar twee jaar vooruitkijken? We moeten onze processen herzien om de ontwikkelingen bij te houden of voor te zijn. Adapt or out…!”

Vindt de manier van werken al wel wat navolging?
“Audi is een zeer groot bedrijf. Zoals ik al aangaf, werken er 96.000 mensen. Veel mensen bij Audi weten nog niet wat centrale IT doet. Bij het uitbreken van corona was het bijvoorbeeld de afdeling die de VPN-verbindingen voor thuiswerken regelt. Ook voor de buitenwereld is het niet altijd duidelijk. Mensen denken al snel aan de embedded software in de auto’s als ze de naam Audi horen. Maar we hebben zo veel andere softwareprojecten, ook voor intern gebruik. En er is fabrieks-IT, sales-IT, analytics, support voor werkplekken, netwerk-IT, zo veel verschillende afdelingen…”

Hoe communiceer je dan je vorderingen met de business? Ze zullen niet altijd makkelijk te begrijpen zijn voor collega’s die geen affiniteit met IT hebben…
“Ik moet ze behoeden voor te veel details. Ik ben de coach voor het businessmanagement, onze ontwikkelaars praten uitsluitend met andere ontwikkelaars, niet met de business. Vroeger werden ontwikkelaars vaak van hun werk gehouden, maar nu is hun agenda leeg, behoudens de stand-ups.”

“De tegenstelling tussen time-to-market en security berust op een misverstand”

“Ik probeer in mijn communicatie altijd concreet te worden. Vaak wordt bijvoorbeeld een term als ‘synergie’ gebruikt, die schijnbaar veelbetekenend is, maar in feite niets betekent. Synergie – met welk doel? Kostenreductie, een kortere time-to-market, een betere spreiding van risico’s, dat zijn concrete doelen. Het is daarom goed om vaak naar de reden van iets te vragen, zoals een zesjarig meisje, dat telkens ‘waarom?’ vraagt. Zo achterhaal je de echte doelen.”

Je spreekt kritisch over centralisering en synergie. Wat zegt dat over jouw principes als het om digitale architectuur gaat?
“Ik streef naar minder afhankelijkheden. Ook is het goed om risico’s te verdelen. Dit is allemaal tegengesteld aan de traditionele, gelaagde architectuur. Als er in zo’n architectuur iets gebeurt in de onderste laag, worden alle bovenliggende lagen getroffen. Ik ben voorstander van een modulaire architectuur. Daar ga je van lagen naar een 3D-model met deeltjes, zoals bouwen met Lego. Daarin kun je dan functionaliteit van buiten integreren. Eén oplossing en één platform hebben is niet nodig. Je kunt wel twintig platforms hebben. Voldoet een platform niet meer, dan faseer je het uit. Met de huidige technologie en de standaard componenten die beschikbaar zijn, is het eenvoudig een nieuw platform op te tuigen.”

“Monolitische IT komt voort uit de gedachte dat centraliseren goed is. Laten we open zijn over bedrijfspolitiek: zeker in grote organisaties draait het erom hoeveel verantwoordelijkheden, budget en mensen een manager heeft. Als dit de incentive is, is centraliseren het motto en het werken in netwerken niet interessant. Decentraliseren en empowering van teams is beter – we huren mensen immers in om hun deskundigheid, om ons te vertellen wat we moeten doen!”

Hoe borg je de security in zo’n uiterst agile omgeving? Er lijkt bijvoorbeeld een tegenstelling te zijn tussen time-to-market en security.
“Dat is een misverstand uit de wereld van plan-build-run. Doe je geen security first, dan doe je het niet goed. Security moet in elke cyclus, in elke sprint vooropstaan. In grote projecten moet security iteratief worden bekeken. Security aan het einde van de rit is geen goed idee, want hoe later je een fout ontdekt, hoe duurder die blijkt te zijn. Als een ontwikkelaar tijdig een eigen fout ontdekt en oplost, kost dat misschien 10 euro. Als dit in de testfase gebeurt, kan het al om 10.000 euro gaan. En als de klant een fout vindt, reken dan maar op 100.000 euro. In dit voorbeeld is security het equivalent van testen.”

Hoe bevorder je het securitybewustzijn binnen de agile teams? Houden ontwikkelaars net zo van security als software development?
“Er is iets dat niet schaalt en dat is vaardigheid. Er is iets anders dat wel schaalt en dat zijn processen. Je hebt beide nodig. Vaardigheden delen moet je organiseren. Wij doen dat bijvoorbeeld door één dag in de week vrij te houden om andere dingen te doen, bijvoorbeeld in de vorm van ‘Friday, break the code day ‘. Ontwikkelaars proberen dan door collega’s ontwikkelde software te hacken. Dat is leuk om te doen en creëert ook nog eens bewustzijn van het belang van security. Je wilt immers niet dat jouw software telkens gehackt wordt! Het is dus ook een kwestie van leiderschap: de vrijheid geven aan je ontwikkelaars, voor reviewen, trainen, zichzelf opleiden…”

“Ook de procesmatige kant moet je goed regelen. Hoe kun je aan een nieuw project gaan werken als security daar niets van weet? Dat is trouwens een goede reden waarom security-mensen in de teams zouden moeten zitten, niet in aparte afdelingen. Ontwikkelaars kunnen zichzelf uitdagen door een project over de bühne te brengen bij de collega’s van security. Ook hier geldt: ga uit je comfort zone…”

Wie is…?

Sebastian Kister is Platform Owner voor Kubernetes en public clouds bij autofabrikant Audi in het Beierse Ingolstadt. Hij is een kritische geest, maar wel iemand die naar eigen zeggen streeft naar harmonie en oplossingen. Ooit begonnen als gitaarleraar die software inzette om zijn leerlingen beter les te kunnen geven, begon hij de leveranciers van zijn software van feedback te voorzien. Het bracht hem er ook toe een staatsdiploma in onderwijswetenschappen te behalen. Een studie in geschiedenis, met name op het gebied van amerikanistiek en anglistiek, bracht hem vervolgens een levendige belangstelling voor het thema privacy op internet, met name de bescherming van burgers tegen totalitaire regimes.

Dit alles kwam bij elkaar bij zijn eerste baan, bij een startup die privacy by design hoog in het vaandel had staan. Later verhuisde hij naar de mediawereld en ging aan de slag als product owner bij een producent van internet-tv. Na een aantal jaren ging het gezwoeg in de mediawereld, van deadline naar deadline, hem tegenstaan. Dat was het moment dat Audi iemand zocht die vanuit de ontwikkelfunctie de cultuur bij het bedrijf zou kunnen veranderen.

Over het highly secure organisations-programma

De perfect storm die is opgestoken rond cybersecurity, brengt menige bestuurder en manager ertoe zich af te vragen hoe het hiermee in de eigen organisatie gesteld is. De dreigingen zijn reëel, de gevolgen soms ingrijpend. De behoefte aan discussie over dit onderwerp met peers is groot onder CIO’s en CISO’s die op zoek zijn naar good practices. ‘Hoe doet de buurman het?’

Tegelijk zien we een bredere discussie rond security, risk en aansprakelijkheid in de context van digitale transformatie. Het is een discussie die zeker ook op RvB- en RvC-niveau speelt. Dat ‘dwingt’ CIO’s en CISO’s om te kijken naar een holistische aanpak, breder dan technologie. Om aan deze behoefte tegemoet te komen, heeft ICT Media het kennisprogramma HSO – Highly Secure Organisations gelanceerd. Het programma is opgezet in samenwerking met een wetenschappelijke instelling en de marktpartijen F5, KPMG, Okta en Orange Cyberdefense.

Enkele malen per jaar zullen belangstellende CIO’s, CISO’s en andere CxO’s bijeenkomen om naar aanleiding van een of meer presentaties in discussie te gaan. Dit met als doel gericht good practices te benoemen. Een à twee maal per jaar zal een paper met alle bevindingen worden geschreven.

Arnoud van Gemeren is hoofdredacteur van CIO Magazine, Boardroom IT en voormalig hoofdredacteur van TITM (Tijdschrift IT Management) en Outsource Magazine. Hij heeft een lange staat van dienst in de Nederlandse IT-mediawereld. Na een start bij een redactiebureau, was hij als hoofdredacteur van 1996 tot 2001 bij uitgeverij Array Publications verantwoordelijk voor diverse IT-vakbladen. In 2001 sloot hij zich aan bij een adviesbureau op het gebied van marketingcommunicatie, Beatrijs Media Group. Vanuit dit bureau bleef hij als hoofdredacteur actief, onder meer voor Sdu Uitgevers.

REAGEREN

Plaats je reactie
Je naam