Het architectenspel

De ontwikkeling van hightech machines is zo complex geworden dat niemand het hele systeem nog kan overzien. Hoe kan een systeemarchitect dan toch de juiste ontwerpkeuzes maken? Samen met industriële partners ontwikkelde TNO-Esi een methodiek die houvast biedt.

Richard Doornbos, Bas Huijbrechts en Wouter Tabingh Suermondt zijn alle drie research fellow bij TNO-Esi. Dit artikel sluit aan op ‘Jongleren met specs’ naar aanleiding van de keynote van Lars Idema (Océ) op High-Tech Systems 2017.

26 oktober 2017

Als we terugkijken naar de laatste decennia in de machinebouw is er een duidelijke kentering zichtbaar. Machines zijn over de tijd geëvolueerd in complexe, multidisciplinaire totaaloplossingen die volledig zijn geïntegreerd in de klantomgeving en excelleren op diverse veeleisende totaalaspecten. We zien meerdere trends: systemen zijn nooit af, maar vragen om continue verbetering, klanten vragen om specifieke aanpassingen zodat er geen twee dezelfde systemen meer zijn, systemen opereren steeds meer op autonome basis, systemen worden geïntegreerd in complexe omgevingen, de orde van het aantal systeemparameters stijgt explosief, en niet het systeem zelf, maar de services eromheen vormen de basis voor het verdienmodel.

Deze trends brengen enorme ontwikkeluitdagingen met zich mee. Meer en meer engineers – met diverse achtergronden en afkomstig uit verschillende bedrijfsonderdelen – worden in het ontwikkelproces betrokken. Elk van deze disciplines en bedrijfsonderdelen wordt aan de ene kant gekenmerkt door een grote hang naar precisie in en focus op zijn eigen expertise, en aan de andere kant door een eigen ontwikkelmethodiek en ‘ontwikkeltaal’. Dit alles leidt tot meer verwarring en onzekerheid: één brein kan het allemaal allang niet meer overzien, laat staan bevatten. Hoe ga je deze uitdaging aan? Hoe zorg je ervoor dat al deze disciplines toch op de juiste manier bijdragen aan het grote geheel?

Ontwikkelaars beginnen typisch met een discussie over vage concepten, gevolgd door uitleg op whiteboards of papier. Soms mondt dit uit in architectuuroverzichten.

Het is duidelijk dat er een grote behoefte bij de systeemarchitecten is aan een goed overzicht en een gedeeld begrip van het probleemgebied en de gebruikte systeemconcepten. Dit legt onherroepelijk de aandacht op communicatie binnen het team en kwaliteit van ontwerpdocumenten. Beide zijn van cruciaal belang voor het maken van afwegingen (trade-offs) in de vroege fase en het maken van goed gefundeerde architectuurbeslissingen. Met name de heldere architectuur- en ontwerpmodellen zijn van groot belang voor de ontwikkeling van toekomstige producten en systemen en kunnen dus worden gezien als core assets van de organisatie.

Verkeerslichten

De meest verdragende beslissingen in het ontwikkelproces worden al vroeg genomen. Daarom is het extra belangrijk dat er gestructureerde methodes zijn die de systeemarchitectuurteams vanaf het eerste begin ondersteunen. Een mogelijk aanpak is model-based system architecting (mbsa). Die behelst een combinatie van een aantal cruciale elementen: het vroegtijdig ontwikkelen van simpele modellen, zelfs als de onzekerheid in afhankelijkheden of parameterwaarden hoog is, een gemeenschappelijke taal die ontstaat bij het ontwikkelen en bediscussiëren in het team, en een focus op kwantitatieve modellen waardoor systeemconcepten en typische waarden van parameters snel duidelijk worden.

In de praktijk zien we vaak een ontwikkeling in fases. De engineers starten typisch met een discussie over vage concepten, gevolgd door uitleg op whiteboards of papier. Soms mondt dit uit in A3-architectuuroverzichten. In deze fases worden standaard architectuurmethodes zoals Cafcr of 4+1 gebruikt.

De laatste stap van het semiformele A3 naar formele modellen is cruciaal. De belangrijkste elementen hierin zijn: het definiëren van de verschillende domeinen die het verantwoordelijkheidsgebied van de betrokkenen omvatten, het ontdekken en weergeven van de afhankelijkheden tussen de domeinen (aangegeven door ‘verkeerslichten’, die meervoudig gebruikte parameters vergelijken), het vertalen van kwalitatieve relaties tussen systeemconcepten naar simpele kwantitatieve modellen (indien noodzakelijk voor de architectuurbeslissingen) en het expliciet maken en beschikbaar stellen van de modellen middels een multi-user webtool zoals TNO-Esi Design Framework.

Ontkoppelen

De visuele structuur van de (mogelijk grote) set van modellen is ook erg belangrijk om een duidelijk overzicht te krijgen. We stellen ons een sterk vereenvoudigd project voor waarin een windturbinepark zal worden gerealiseerd. De organisatiestructuur van dit project is weergegeven in Figuur 2. Alle domeinen hebben een verantwoordelijke domeinexpert, die is gepersonaliseerd door een foto. Bovenaan zijn de belanghebbenden (stakeholders) van het project te vinden. In dit geval de ondernemer (entrepreneur), de planner van het elektriciteitsnet (grid capacity planner) en de vertegenwoordiger van de omwonenden (representative of citizens). Onderaan zijn de concrete realisaties (building blocks) geplaatst. In dit voorbeeld zijn dat het windturbinepark en de daaruit opgebouwde windturbines.

De organisatiestructuur van een windturbineparkproject bestaat uit belanghebbenden, systeemparameters, architecturale perspectieven en bouwblokken.

De twee lagen ertussenin verbinden de behoeften en doelstellingen met de realisaties. Direct boven de realisaties bevinden zich de meest kritieke domeinen, de architectural views. In dit geval zijn dat er drie. Ten eerste de kosten (de levelized cost of electricity). Dit is een gestandaardiseerde maat om de prijs van een afgeleverde megawattuur, gemeten over de totale levensduur van de installatie, te berekenen. Ten tweede het te verwachten piekvermogen dat het lokale elektriciteitsnet moet kunnen absorberen. En ten derde de geluidsproductie van het gerealiseerde windpark.

Als laatste vinden we de kritieke systeemeigenschappen (system parameters) die de verbindende schakel vormen tussen de architectural views en de stakeholders. Deze parameters worden door de systeemarchitect bewaakt en gekozen.

Verder zijn alle domeinen volledig van elkaar ontkoppeld, waardoor iedere verantwoordelijke zijn eigen afwegingen kan maken. Hierdoor ontstaan veel parameterduplicaties. Verkeerslichten bewaken de consistentie tussen deze duplicaties. Elk stoplicht kan drie kleuren aannemen. Groen betekent dat een oplossing is gevonden, terwijl rood wil zeggen dat het verschil onoverbrugbaar groot is en er geen oplossing beschikbaar is. Oranje is een mengvorm en houdt in dat de verschillen dusdanig beperkt zijn dat een oplossing onderhandelbaar zou moeten zijn.

Compromis

Het architectenspel zou op de volgende wijze kunnen worden gespeeld. Stel, we starten met een beginsituatie waar alle stoplichten op groen staan. Het lijkt er nu op dat er een totaaloplossing is. Het blijkt echter dat de omwonenden na beraad tot de conclusie zijn gekomen dat het te verwachten geluidsniveau onacceptabel hoog is. Zij maken dit kenbaar door in het blok ‘representative of citizens’ het acceptabele geluidsniveau naar beneden bij te stellen. Het gevolg hiervan is dat het bijbehorende stoplicht met de systeemarchitect op rood springt.

De systeemarchitect begrijpt dat er een serieus probleem is en het turbinepark in de huidige vorm niet kan worden gerealiseerd. Hij evalueert de eisen en argumenten van de omwonenden en besluit uiteindelijk om de systeemeis voor het geluidsniveau gedeeltelijk naar beneden bij te stellen. Het gevolg hiervan is dat het betrokken stoplicht tussen de omwonenden en de systeemarchitect op oranje springt terwijl het stoplicht tussen de systeemarchitect en de geluidsoverlastexpert op rood komt te staan.

De geluidsexpert is nu ingekoppeld en krijgt het verzoek om de nieuwe situatie te bekijken. Hij kan het geluidsniveau beïnvloeden door een ander type windturbine te kiezen, het aantal windturbines te heroverwegen of te gaan voor een andere locatie. Elke oplossing heeft zo zijn eigen voor- en nadelen. Na heel veel onderzoek en afwegingen komt de geluidsexpert tot de conclusie dat de gekozen locatie niet houdbaar is en hij stelt een andere locatie voor. Hij doet dit door zijn eigen locatieparameter te wijzigen. Ook deze parameter heeft weer een stoplicht met de systeemarchitect dat nu op rood springt. Het stoplicht dat het geluidsniveau voor omwonenden aangeeft, staat echter weer op groen.

Het gevolg is nu dat voor de systeemarchitect het probleem is verschoven. Had hij eerst een geluidsoverlastvraagstuk, nu heeft hij een locatievraagstuk. Dit maakt de zaak een stuk ingewikkelder omdat de locatie – net zoals de kosten – een invasieve parameter is die overal invloed op heeft. Na langdurig overleg komt ook de systeemarchitect tot de conclusie dat er geen andere keuze is dan de locatie aan te passen. Hij doet dit door ook de systeemparameter ‘locatie’ bij te stellen. Het locatiestoplicht tussen het geluidsoverlastdomein en de systeemarchitect springt weer op groen, maar alle andere locatiestoplichten springen op rood.

Nu is een lokaal probleem op gecontroleerde wijze een globaal probleem geworden. Alle andere domeinexperts zullen op zoek moeten gaan naar de beste afweging op basis van de nieuwe situatie. Het is heel goed mogelijk dat een nieuwe toestand waarin alle stoplichten groen zijn niet kan worden gevonden. Waarschijnlijk komt er een compromis uit waarbij zo min mogelijk concessies hoeven te worden gedaan. Dit is dan zichtbaar gemaakt door de kleur van alle stoplichten.

Expliciet

Dit simpele voorbeeld blijkt bij nader inzien toch al behoorlijk ingewikkeld. Een realistisch systeem kan zelfs wel een orde groter zijn waarbij elk domein een tot twee ordes complexer is. Het is nu dan ook direct duidelijk dat niemand een dergelijk systeem volledig of zelfs maar gedeeltelijk kan bevatten.

Het voorgaande voorbeeld is uitgewerkt in het TNO-Esi Design Framework. Deze webgebaseerde tool is in staat om architecturen te beschrijven die vele ordes meer detail bevatten. Daarmee is het mogelijk om architecturen van een realistische industriële schaal te hanteren.

De mbsa-methodologie ondersteunt de systeemarchitectuurteams op een natuurlijke manier. Onze ervaringen laten zien dat duidelijkheid over systeemconcepten en het expliciet maken van verantwoordelijkheidsgebieden van de betrokkenen erg belangrijk zijn. Dit expliciet maken kan politiek lastig zijn en emoties los maken, maar is essentieel. De belangrijkste voordelen die wij observeren zijn: sneller resultaat, duidelijkere communicatie (met name richting management), beter onderbouwde architectuurbeslissingen en betere, consistente systeemarchitectuurrepresentaties (beschrijvingen, modellen).