De systeemarchitect ontmoet de softwarebeeldhouwer
In een virtuele rondetafel bespreken Canon Production Printing, NXP, Philips, Thales, Thermo Fisher Scientific en Vanderlande hoe de toenemende systeemcomplexiteit de rol van de systeemengineer beïnvloedt. De consensus: software heeft de boel stevig opgeschud.
Digitalisering heeft het werk van de hightech-systeemengineer ingrijpend veranderd. ‘Onze producten beperken zich niet langer tot de dozen waarin ze worden verscheept’, constateert Klaas Wijbrans, fellow architect bij het Chief Architect Office van Philips. ‘Ze zijn onderdeel geworden van een netwerk, een ecosysteem, een systeem van systemen, dat interacteert met de cloud en andere it-infrastructuren. Onze architecten moeten nu nadenken over een systeem met componenten op verschillende locaties en een businesscase die draait om continue waardecreatie, gedurende de hele levenscyclus van het product.’
Met nieuwe technologieën zoals kunstmatige intelligentie en digital twins hebben systemen steeds meer interactie met de echte wereld. ‘Ze maken op meer manieren verbinding, verzamelen meer gegevens en genereren ook meer data’, zegt Clara Otero, senior director systeeminnovatie bij NXP Semiconductors. ‘Als gevolg daarvan is onze businessfocus verschoven van alleen de chip naar de hele edge, en is de scope van onze architecten uitgebreid met de databehoeftes van onze klanten. We leveren producten met meer digitale functionaliteit en meer software.’
‘Digitalisering brengt een overvloed aan nieuwe functionaliteiten die we aan onze klanten kunnen aanbieden. Tegelijkertijd opereren onze klanten in een steeds digitalere omgeving die ze willen koppelen aan onze producten’, merkt Henk Thomassen, afdelingshoofd platformontwikkeling en planning bij Canon Production Printing. ‘Dit heeft een aanzienlijke impact op onze systemen, die veel flexibeler moeten zijn om te kunnen omgaan met de steeds veranderende omgeving waar ze een integraal onderdeel van zijn geworden. Dat vraagt om een slimme architectuur die die flexibiliteit biedt en bijbehorende manieren van werken zoals Agile en Scaled Agile.’
Maarten Verhoeven, executive director architectuur en integratie bij Vanderlande, ziet een soortgelijke spillover van de softwaremindset. ‘In het verleden moesten systeemengineers extreem voorzichtig zijn omdat de hele toeleverketen op hen rekende om een foutloos ontwerp af te leveren. Software heeft dat volledig veranderd. De Agile-mentaliteit van fail fast moedigt hen juist aan om snel van hun fouten te leren en een verbeterde versie uit te rollen. Dat is echt een aardverschuiving.’
Software is de dominante discipline geworden en dat heeft de verhoudingen op systeemniveau flink opgeschud. ‘Vroeger gooiden systeemengineers hun werk over de schutting, bij wijze van spreken, vertrouwend op de hardware- en softwarespecialisten’, zegt Roel Aalbers, technisch directeur systemen bij Thales in Nederland. ‘Nu moeten ze begrijpen wat daar gebeurt. Ze moeten weten wat hun aandeel is in de digitale transformatie en de uitdagingen die die transformatie met zich meebrengt, bijvoorbeeld op het gebied van cybersecurity en de cloud.’
Meer betrokkenheid
Bij Thales zorgt de Agile-mentaliteit voor een botsing van culturen. ‘Onze systeemengineers hebben te maken met strenge eisen, onder meer op juridisch vlak en wat betreft veiligheid en beveiliging. Die moeten eerst worden vastgesteld, wat vraagt om een meer traditionele watervalaanpak. Dat staat haaks op de agility die sommige software-engineeringmethodes voorstaan’, legt Aalbers uit.
Zijn collega en systeemarchitectuurexpert Jacek Skowronek wijst erop dat het door de korte cycli in softwareontwikkeling steeds moeilijker wordt voor systeemengineers om bij te blijven. ‘Software is al erg vloeibaar, maar zaken als Agile en DevOps maken het nog vloeibaarder. Systeemengineers willen precies weten wanneer componenten klaar zijn en welke functies ze zullen hebben. Agile softwareteams zijn meestal niet in staat om die vragen te beantwoorden. Dat kan voelen als een disconnect.’
‘In systeemengineering gaat het erom het totaaloverzicht te houden’, zegt Verhoeven van Vanderlande. ‘Dat zie ik minder in de agile-softwarecommunity, waar de focus meer ligt op het snel leveren van kleine verbeteringen. De uitdaging is om het systeem werkend te houden in deze continue stroom van updates. Soms slaat de balans te ver door. We zijn nog steeds aan het leren om het evenwicht te bewaren.’
De mannen van Thales zouden graag meer interactie zien tussen de systeem- en softwarekant. ‘Beide ingenieursdisciplines zouden meer moeten nadenken over de implicaties van hun werk op elkaars niveau’, vindt Aalbers. Skowronek is het daarmee eens. ‘In een cloudgebaseerde omgeving hebben ze toegang tot vrijwel onbeperkte resources’, geeft hij als voorbeeld. ‘In onze systemen spelen echter ook hardwarebeperkingen een rol.’
Wijbrans onderschrijft het sentiment. ‘In het verleden moesten softwaremensen goed nadenken om hun code op de hardware te passen. Met de onbeperkte resources in de cloud hebben ze die zorg niet meer. Maar ze realiseren zich onvoldoende dat daar een prijskaartje aan hangt. Ik heb genoeg slecht ontworpen systemen gezien die klanten opzadelen met enorme rekeningen van hun cloudproviders, vooral als het dataverkeer groeit.’
Bewustzijnskloof
Bij Thermo Fisher Scientific hebben ze ervoor gekozen om de kloof gedeeltelijk te overbruggen door de twee werelden alleen op de kernfunctionaliteit met elkaar te verbinden. ‘We hebben elke 2 à 3 jaar een hardware-update maar elke drie maanden een nieuwe softwarerelease’, illustreert Olivier Rainaut, manager systeemarchitectuur-r&d bij de Eindhovense vestiging van het bedrijf. ‘We koppelen die twee aan het zogeheten minimum viable product van het systeem of de module en zoeken daar de overeenstemming over de interfaces en vereisten.’ Deze aanpak heeft zijn prijs, geeft Rainaut toe. ‘Met frequente software-updates wordt lifecyclemanagement een uitdaging.’
‘We doen ons uiterste best om beide partijen bij elkaar te brengen’, vult zijn collega en systeemarchitect Jamie McCormack aan. ‘In een systeemreferentiearchitectuur maken we bijvoorbeeld expliciet dat elk onderdeel van de functionele systeemdecompositie een gezamenlijke exercitie is van hardware en software. Ik ben de referentiearchitect voor onze transmissie-elektronenmicroscopen en ik heb een softwarearchitect naast me werken aan die referentiearchitectuur.’
Wijbrans is het er helemaal mee eens dat om de ‘enorme bewustzijnskloof’, zoals hij het noemt, te overbruggen, beide partijen elkaar beter moeten leren begrijpen. ‘Moderne systeemarchitecten moeten voldoende kennis hebben van software. Ze hoeven niet zelf te kunnen programmeren, maar ze moeten wel weten hoe het het product ten goede kan komen. Die achtergrond komt deels uit opleiding en deels uit coaching. Bij Philips zetten we mensen die zich bewust zijn van deze kloof samen met mensen die zich daar nog niet zo bewust van zijn, bijvoorbeeld als sparringpartner of peer-reviewer in projecten.’
De sleutel, meent Skowronek, ligt in nauwe samenwerking. ‘Ik heb ooit als architect deelgenomen aan een softwarescrumteam. Nu heb ik behoorlijk wat ervaring, maar ik had aanvankelijk moeite om hun wereld te doorgronden. Langzaamaan begon ik hen echter beter te begrijpen. Ook software-experts kunnen er baat bij hebben om meer betrokken te zijn bij systeemvraagstukken. Door dit aan beide kanten te stimuleren, kunnen we de kloof tussen waterval en Agile overbruggen. Ik ben ervan overtuigd dat de oplossing ergens in het midden ligt.’
Lichtgewicht modellen
Ook modellering kan heel behulpzaam zijn bij het overbruggen van de kloof. ‘In de afgelopen drie jaar hebben we de referentiearchitectuur van ons systeem volledig in Visio getekend’, legt Rainaut uit. ‘De resulterende modellen tonen alle samenstellende delen en hun interfaces. We zien dat nieuwe systeemengineers zo snel een overzicht krijgen en dat softwaremensen graag in de Visio-bestanden duiken om het systeem te leren kennen, hoe het werkt en hoe alles met elkaar verbonden is.’
‘Het werkt twee kanten op’, vult McCormack aan. ‘De softwarejongens hebben ook Visio-tekeningen gemaakt en toen ze die aan mij lieten zien, ging ik hun wereld beter begrijpen, op dezelfde manier als zij onze wereld beter zijn gaan begrijpen door naar onze modellen te kijken. Naarmate ons wederzijds begrip groeit, verandert ook onze manier van tekenen ten goede. In onze nieuwste modellen liggen onze decomposities en interfacebeschrijvingen al veel dichter bij elkaar.’
Skowronek vindt dat dergelijke ‘lichtgewicht’ modellen onvoldoende op waarde worden geschat. ‘Als mensen het tegenwoordig over modelleren hebben, denken ze vaak aan uitgebreide tools met allerlei toeters en bellen, zoals codegeneratie en validatie. Maar het gaat niet om tooling; modelleren is een basistechniek die ik vind dat iedereen zou moeten beheersen zonder tool. Iedere engineer – systeem en software – zou met alleen pen en papier een plaatje moeten kunnen tekenen van een module en zijn interfaces.’
‘Of het nu in Visio, Powerpoint of op een stuk papier is, eenvoudige diagrammen kunnen heel krachtig zijn, heel veelzeggend, naast modelgebaseerde systeemengineering’, stelt Aalbers. ‘Je kunt ze aan de muur hangen en er met een team naar kijken om direct een overzicht te krijgen van het systeem of delen daarvan. Dit soort eenvoudige modellen zijn erg handig om kennis te delen met nieuwe mensen of in een nieuw project. Bij een paar grote nieuwe ontwikkelingen gebruiken we zulke diagrammen bijvoorbeeld om inzichtelijk te maken wat de stakeholders willen.’
De bekende A3-methode, genoemd naar de grootte van het papier waar de diagrammen op worden gezet, is gebaseerd op precies deze principes. De aanpak helpt bij het vastleggen van relevante architectuuraspecten voor een specifiek doel, zoals een refactoring of de overdracht van verantwoordelijkheden. De methode is ontwikkeld door de Universiteit Twente, Philips en ESI’s Gerrit Muller en wordt inmiddels binnen veel bedrijven toegepast.
Mbse
Voor Rainaut van Thermo Fisher Scientific was het lichtgewicht modelleren in Visio een mooie opstap naar volwaardige modelgebaseerde systeemontwikkeling (model-based systems engineering, mbse). Zijn mensen gebruiken nu de open-source tool Capella, via het cloudgebaseerde platform van Obeo, voor systeemdecompositie op een SysML-achtige manier – voor hardware en software, tot en met interfacemapping. Rainaut ziet dit snel aanslaan. ‘Vooral bij onze architecten die al enige achtergrond hebben in andere soorten modellering, zoals eindige-elementenanalyse of scripting, bijvoorbeeld in Matlab.’
Mbse is ook Vanderlandes antwoord op de uitdaging om de kloof tussen systeem- en software-engineering te overbruggen. ‘Onze systeemarchitecten gebruiken modellen om het complete systeemgedrag vast te leggen. Onze software-engineers dragen vanuit hun expertisegebied bij aan deze modellen’, schetst Verhoeven. ‘Door het systeemmodel als het ware modulair uit te breiden, houden ze het overzicht en kunnen ze samen blijven bouwen.’
Bij Philips is mbse van groeiend belang. ‘Het levert wel een spanningsveld op’, plaatst Wijbrans een kanttekening. ‘Een systeemengineeringmodel moet compleet zijn omdat het het hele ontwerp specificeert, terwijl het bij architectuur gaat om het creëren van een abstractie van de belangrijkste zaken. De uitdaging waar we nu naar kijken, is hoe we die twee consistent kunnen houden.’
Canon Production Printing maakt steeds meer gebruik van modellering om de disciplines samen te brengen in virtuele prototypes. ‘We zetten onze systeemarchitectuur en de daaruit voortvloeiende ontwerpen in wat we digitale labmodellen noemen’, legt Thomassen uit. ‘Dit zijn vrij complexe, multidisciplinaire modellen waarmee we onze software kunnen testen voordat de hardware beschikbaar is. Virtual prototyping helpt ons zo om onze producten sneller en tegen lagere kosten op de markt te brengen.’
Samen met partners als ESI zetten de bedrijven stappen om mbse echt van de grond te krijgen in hun organisatie. Ze nemen deel aan meerdere projecten die gericht zijn op de invoering van methodologieën en hulpmiddelen ter ondersteuning van het modelleerproces zelf en het onderhoud van de resulterende modellen. Door middel van trainingsprogramma’s en workshops zijn hun architecten hun mbse-vaardigheden aan het opkrikken.
Ecosysteem
Nu mbse meer en meer ingeburgerd raakt, creëert dit een geheel nieuwe uitdaging in het ecosysteem. ‘Middels gezamenlijke ontwikkeling, insourcing en outsourcing werken we samen met een groot aantal leveranciers en andere bedrijven’, verklaart Rainaut. ‘Hoe zorgen we ervoor dat zij onze modellen kunnen gebruiken? Dat wordt steeds moeilijker omdat we met steeds meer partners samenwerken, die allemaal hun eigen tooling hebben. Op een bepaald moment gaat dat onze efficiëntie beïnvloeden. Als we volledig draaien op modellen die we niet met hen kunnen delen, blokkeert de keten.’
De oplossing ligt in de ogen van Rainaut in de interface tussen de partners. ‘De ideale situatie zou zijn als iedereen opensource modellen zou gebruiken die eenvoudig geëxporteerd en geïmporteerd kunnen worden. Ik zie dat alleen niet gebeuren omdat we onze keuze van tooling simpelweg niet kunnen opleggen aan onze partners. De enige manier om een onbelemmerde uitwisseling van modellen te garanderen, is beide zijden met elkaar te verbinden via standaard interfaces. Anders zit er niets anders op dan Word- en Excel-documenten heen en weer te sturen.’
Soms is dat ook echt de enige optie. ‘In ons deel van de industrie is het heel moeilijk om organisaties te vinden die mbse al hebben omarmd, vooral aan de klantzijde’, merkt Skowronek van Thales op. ‘Onze klanten hebben bijna allemaal hun eigen omgeving. Ik zie ze nog niet snel overstappen op onze tooling, laat staan op een opensource alternatief. Natuurlijk zouden we graag een allesomvattende modelgebaseerde omgeving hebben voor de hele waardeketen, maar het zou vele, vele jaren duren om dat voor elkaar te krijgen. Voorlopig communiceren we vooral via Word en Excel. Dat is misschien niet heel erg modieus, maar het werkt wel.’
Aalbers ziet wel enige vooruitgang. ‘Met name bij de hardwareontwikkeling. Systeemengineering lijkt een beetje achter te blijven. Daar moet wat mij betreft nog wat overbruggingswerk worden verricht. Het zou al een stap in de goede richting zijn als we een collaboratief digitaal platform zouden hebben waar we architectuur- en ontwerpinformatie kunnen delen met partners en klanten.’
Platformisering
Digitalisering heeft ook bijgedragen aan de groeiende complexiteit van systemen. Om de ontwikkeling beheersbaar te houden, hebben bedrijven hun vizier gericht op platformisering en modularisatie. ‘De technologische vooruitgang gaat zo snel dat het heel moeilijk is geworden om innovaties voor losse producten te gelde te maken. Daarom zijn we overgestapt op een aanpak waarbij we meerdere producten op hetzelfde platform baseren’, legt Thomassen uit. ‘In feite knippen we onze monolithische softwarearchitectuur op in functionele blokken met gestandaardiseerde interfaces en interacties. Deze blokken kunnen worden ontwikkeld door kleinere teams, relatief onafhankelijk van elkaar. Als legosteentjes kunnen ze worden gecombineerd tot complete systemen door iteratief grotere eenheden te bouwen, die elk op zich testbaar moeten zijn.’
Bij Vanderlande hebben ze een soortgelijke overstap gemaakt van klantspecifieke projecten naar meer generieke ontwikkelingen. ‘We maken modulaire bouwstenen, zo klein en zo beperkt mogelijk’, vertelt Verhoeven. ‘Deze aanpak stelt ons in staat om meerdere teams tegelijkertijd aan hetzelfde systeem te laten werken zonder dat de complexiteit uit de hand loopt. De grote uitdaging is om de interfaces op elkaar af te stemmen en te ontkoppelen, en daar komt het ambacht van de architect weer om de hoek kijken.’
Een platformgebaseerde architectuur, stelt Thomassen, creëert synergie op twee manieren: door het hergebruik van bestaande functies en componenten en door flexibiliteit te bieden voor de toekomst. ‘We moeten meer vooruitkijken, naar productmogelijkheden die nog niet erg tastbaar zijn maar wel potentie hebben. Met een flexibele platformarchitectuur kunnen we gemakkelijk op die mogelijkheden inspelen zodra ze zich aandienen.’
Vanderlande heeft een speciale groep specialisten de opdracht gegeven om ervoor te zorgen dat de platformontwikkelingen in lijn zijn met de algemene inspanningen op het gebied van systeemengineering. ‘Ons architectengilde bewaakt deze afstemming actief’, zegt Verhoeven. Canon Production Printing heeft platformreferentieprojecten opgezet om hiervoor te zorgen, geeft Thomassen aan. ‘Naast de traditionele productprojecten hebben we speciale teams van architecten die een technologieplatform bewaken en er een referentiearchitectuur voor definiëren.’
Kennisoverdracht
Alle nieuwe methodologieën en tools zijn zeer nuttig om systeemengineers inzicht en overzicht te geven, maar ze zijn geen vervanging voor ‘ouderwetse’ kennisdeling. Niet voor niets hebben opleidingsaanbieders zoals ESI hun onderwijsfocus verlegd van het geven van individuele cursussen naar het aanbieden van (in-company) programma’s waarbij meerdere belanghebbenden op meerdere niveaus betrokken zijn, soms zelfs van meerdere bedrijven. Deze programma’s, die uitgaan van een real-life businesscase in een learning-by-doing-benadering, hebben expliciet tot doel de kruisbestuiving te stimuleren.
‘Met Agile alleen red je het niet. Dat geldt ook voor uitgebreide tooling’, stelt Aalbers. ‘Zonder een gedegen achtergrond in systeemengineering kom je niet echt verder. Dat is deels opleiding, maar vooral training on the job. Van ervaren collega’s leer je het meest. Ook het delen van kennis met andere hightechbedrijven, bijvoorbeeld via het ESI-netwerk, is heel belangrijk. Om vooruit te komen in deze complexe wereld kunnen we veel van elkaar leren.’
Ook bij Philips is er veel aandacht voor kennisoverdracht. ‘Ik geef leiding aan onze architectencommunity’, verduidelijkt Wijbrans. ‘Deze community telt momenteel zo’n 900 mensen – systeem-, software- en solution-architecten. We verbinden hen door coaching en een uitgebreid intern programma van cross-training. Onze systeemengineers kunnen hun ‘digitale’ kant versterken met cursussen over bijvoorbeeld cloud, connectiviteit en data. Zo’n netwerk is zeer waardevol, want in mijn ogen kunnen mensen alleen ervaring opdoen door te doen en te delen.’
Met de toenemende digitalisering moeten de systeemengineers van NXP hun kennisniveau verhogen om ook de klanttoepassing mee te nemen. ‘In het verleden hoefden ze ‘alleen maar’ kennis te hebben van onze componenten. Nu moeten ze ook begrijpen hoe onze klanten ze gebruiken, welke systemen ze ermee maken’, zegt Otero. ‘Dat is een grote stap – voor sommigen een worsteling – maar noodzakelijk om toekomstige behoeftes te kunnen identificeren. Voor onze klanten kan het delen van die kennis met ons net zo’n grote stap zijn.’
Te veel klant- of productfocus kan ook lokale helden creëren – systeemengineers die alles weten over een heel specifieke ontwikkeling. De oudere generatie, die lange tijd in een dergelijke cultuur heeft gewerkt, wil daar nog weleens in vervallen. Maar in een wereld waarin architecten steeds meer multidisciplinair samenwerken om de toenemende systeemcomplexiteit aan te pakken door modellen en platforms te delen, werkt lokaal heldendom niet meer. Bij Canon Production Printing voelt Thomassen al een nieuwe wind waaien. ‘In onze architectengemeenschap merk ik dat de jongere generatie er geen moeite mee heeft om elkaar op te zoeken en modellen te delen.’
Dit artikel is tot stand gekomen in nauwe samenwerking met ESI (TNO).
