Architectuur+Engineering, Model-Based Systems Engineering

Peter Bakker, dinsdag 05 mei 2009

Op 3 april 2009 deed Daan Rijsenbrij een oproep op Via Nova Architectura dat begon met de volgende tekst “Er is behoefte aan een breder denkkader voor ‘architectuur + engineering’ ” Hij deed dit tijdens een verhitte discussie naar aanleiding van zijn artikel TOGAF: het universele wondermiddel? Later in de discussie gaf hij nog een toelichting op dit verzoek met daarin de volgende alinea: “Als oprichter van de Landelijke Architectuur Congressen (vanaf 1999) en als initiator van dit E-Magazine ’Via Nova Architectura’ heeft mij altijd voor ogen gestaan platformen in het leven te roepen waar niet alleen architecten met elkaar kunnen communiceren, maar ook architecten met engineers en engineers onderling, allen op voet van gelijkwaardigheid. Immers de discussie tussen architecten en engineers is de strijd tussen esthetische vormgeving (liefst met de mens centraal) en technische haalbaarheid: zie mijn presentatieset op het tiende Landelijk ArchitectuurCongres. Dus Peter, ik zie graag een publicatie van jouw hand over de engineer in dit E-Magazine.”.

Met dit artikel hoop ik het door Daan gevraagde steentje bij te dragen aan het bredere denkkader voor Architectuur+Engineering.

Inleiding

Dit artikel is een visiestuk, of eigenlijk meer een soort schets, hoe ik de toekomst zie van het ontwerpen in een digitale wereld. Hierin probeer ik te laten zien dat wij, architecten en engineers in de digitale wereld, onze werkwijze moeten aanpassen aan de toenemende complexiteit en chaos om ons heen.

Ik ben ervan overtuigd dat een steeds intensievere samenwerking tussen architecten en engineers nodig zal zijn om zo de steeds complexer wordende systemen en hun gedrag te kunnen begrijpen. En dat gezamenlijke begrip is noodzakelijk om weloverwogen beslissingen met betrekking tot die systemen en hun omgeving te kunnen nemen. En zowel architecten als engineers moeten het toch hebben van weloverwogen beslissingen?

Leeswijzer

Ik probeer niet om opnieuw de discussie aan te wakkeren omtrent de definities van wat of wie een architect of engineer is. Zelf zie ik architecten en engineers als respectievelijk de rechteren linkerhelft van de hersenen die samen verantwoordelijk zijn voor het ontwerpen van systemen. Soms zal de ene helft dominant zijn en soms de andere helft maar altijd zullen ze elkaar nodig hebben om tot het beste resultaat te komen.

In die lijn hanteer ik de volgende definities voor de rest van dit stuk:

  • De architectis verantwoordelijk voor “getting the right design/doing better things”. Kenmerken die in het algemeen worden toegeschreven aan een architect zijn:
    • Creatief (rechter hersenhelft)
    • Kijkt naar het geheel in relatie tot de context
  • De engineeris verantwoordelijk voor “getting the design right/doing things better”. Kenmerken die in het algemeen worden toegeschreven aan een engineer zijn:
    • Rationeel en logisch denkend (linker hersenhelft)
    • Let op de details

Ik hoop wel op een stevige discussie rond mijn definitie van een systeem:

  • Een kunstmatig open systeem of kortweg systeem is een door mensen ontworpen netwerk van dingen, waarbij het netwerk als geheel eigenschappen heeft of zou moeten hebben die tegemoetkomen aan de belangen van de legitieme belanghebbenden1. Open wil zeggen dat het kunstmatige systeem beïnvloedt wordt door de omgeving waarin het zich in bevind en waarbij dezelfde omgeving wordt beïnvloedt door de aanwezigheid van het kunstmatige systeem.

In het volgende hoofdstuk beschrijf ik, als technische leek maar wel als ervaren gebruiker, een luchtverwarmingssysteem om allereerst mijn definitie van een systeem te illustreren. Tegelijkertijd zal ik kort de rollen van de engineer en architect toe lichten. Daarna zal ik het luchtverwarmingsysteem als voorbeeld gebruiken hoe systemen zich aanpassen aan de omstandigheden, via evolutie en revolutie, en hoe een systeem chaotisch wordt.

Vervolgens zal ik kort schetsen dat we bij het nadenken over architecten, engineers en het ontwerpen van systemen veel kunnen leren van andere vakgebieden. Dit alles ter ondersteuning van de onderstaande oproep (die ik onderaan het artikel nog eens herhaal):

Aan de engineers:

wordt geen architect maar een Systems Engineer gespecialiseerd in het modelleren

Aan de opdrachtgevers:

stel contractueel verplicht dat er binnen projecten met één logisch informatie model wordt gewerkt, accepteer geen informatie silo’s en verspilling van kosten

Aan alle architecten:

Maak geen modellen maar gebruik ze! Vraag om ondersteuning van system engineers om je kunnen helpen bij het modelleren, simuleren en analyseren van het dynamische gedrag van je ontwerpen

Voorbeeld van een systeem: luchtverwarming

Een voorbeeld van een systeem is een luchtverwarmingssysteem zoals die in mijn huis zit. Dit systeem bestaat vanuit mijn (gebruikers) perspectief uit onder andere:

  • Unit met o.a. brander, ventilatoren, sensoren, regelunit (inhoud weet ik globaal omdat ik bij het verhelpen van een storing heb meegekeken en met de monteur heb gepraat)
  • WarmteTerugWin-unit
  • Luchtkanalen
  • Gasleiding/koppelingen
  • Netsnoer
  • Regelbare warmteroosters in de vertrekken
  • Klokthermostaat (vervanging van de oorspronkelijke conventionele thermostaat)
  • Onderhoudscontract/storingsdienst
  • Handleiding
  • Kanalen door dak voor invoer verse lucht en afvoer rookgassen.
  • Verbinding met afzuigkap in keuken en regelknop in keuken voor capaciteit afzuiging
  • Filters

Al deze dingenzorgen ervoor dat ik kan genieten van een verwarmd huis, met voldoende verse lucht (zelfs als ik alle ramen dicht houdt) en dat “vervuilde” lucht wordt afgevoerd. Een aantal componenten moeten daarvoor continu goed werken, andere componenten worden pas belangrijk in geval van storingen.

Ik denk dat iedereen het erover eens zal zijn dat er hoogst waarschijnlijk geen architect betrokken is geweest bij het ontwerp van dit systeem. De meeste componenten in dit systeem zullen ontworpen zijn door verschillende engineers met ieder hun eigen vakgebied en specifieke kennis. En waarschijnlijk is de essentiële set van componenten in één waarschijnlijk fysiek model of prototype samengebracht waarna het geheel met behulp van simulaties en analyses is getoetst op realiseerbaarheid en correct gedrag onder verschillende belastingen. De engineers zullen ook in meer of mindere mate betrokken zijn geweest het controleren van de correctheid van de handleiding en het opstellen van installatie- en onderhoudsvoorschriften.

En hoe zit het dan met de rol van de architect? Mijn huis is begin jaren tachtig, vlak na de tweede oliecrisis, ontworpen en gebouwd toen energiebesparing in opkomst was. Luchtverwarming, via een alles-in-één unit, inclusief geiser en warmteterugwinning en een gescheiden regeling voor 3 zones, was toen mijn huis ontworpen werd voor Nederland een nieuwe, zelfs experimentele, techniek. Het werd door de engineer van de unit gezien als dé toekomst op verwarmingsgebied. De architect heeft waarschijnlijk in overleg met of in opdracht van de opdrachtgever2er voor gekozen om het type huis waar ik in woon te voorzien van dit type luchtverwarming. En dat is medebepalend geworden voor hoe mijn huis er uit is gaan zien. Zo hebben we geen schoorsteen, geen radiatoren die ruimte innemen, maar wel overal ruimtes voor de leidingen waar de hete lucht door heen moet. Plus een enorme installatie op zolder.

Gezien het experimentele karakter van het huis en van de verwarming mag ik aannemen dat er tijdens het ontwerp van het huis contact is geweest tussen de architect en de engineer van de unit om te bespreken hoe onder andere de leidingen moesten lopen, waar thermostaten3en ventilatie- en verwarmingsroosters moesten komen, wat de gevolgen waren voor de dakconstructie en de indeling van de zolder. Voor de engineer was het van belang om te weten hoe groot het huis zou worden, hoe de zoneverdeling zou zijn en hoe groot de te verwarmen en te ventileren ruimtes zouden zijn zodat hij de juiste benodigde capaciteit kon bepalen. De architect en engineer hebben dus gezamenlijk allerlei weloverwogen beslissingen genomen op zowel architectuur als engineering gebied waardoor ik nu de eigenaar ben van een huis met een effectief luchtverwarmingssysteem.

Maar zelfs met dit relatief eenvoudige systeem is al aan te tonen dat onze wereld steeds complexer blijft worden. En dat het nemen van weloverwogen beslissingen steeds moeilijker zal worden om nog maar te zwijgen van het afdwingen en realiseren van die beslissingen.

De ontwikkeling van systemen

Evolutie

Een luchtverwarmingssysteem is een systeem dat is gebaseerd op hele simpele principes. Je verwarmt met behulp van een gasbrander direct de lucht en die leidt je vervolgens naar de juiste ruimtes. Rookgassen die ontstaan voer je af naar buiten.

De volgende stap in de evolutie van dit simpele systeem is dat je dit systeem gaat koppelen met een ventilatiesysteem met direct daarop de volgende evolutie, warmteterugwinning en balansventilatie. De daarop volgende stap is de combinatie met luchtkoeling. Door deze evoluties kun je kiezen tussen verschillende luchtverwarmingssystemen met verschillende mogelijkheden4.

Kenmerk van een evolutionaire ontwikkeling is dat er steeds een beetje complexiteit wordt toegevoegd aan het systeem.

Evolutie werkt het beste als je pas complexiteit toevoegt wanneer je precies weet hoe het al bestaande systeem werkt en wat het kan, dus hoe het zich gedraagt onder verschillende belastingen. Evolutie is ook gebonden aan bepaalde economische en technische grenzen, je kan niet onbeperkt complexiteit toevoegen. Ons experimentele luchtverwarmingssysteem was bijvoorbeeld door alle toegevoegde complexiteit zo duur geworden, zowel om te maken als in onderhoud, dat het niet meer kon concurreren met de eenvoudigere luchtverwarmingssystemen en met de normale centrale verwarmingssystemen. Zeker niet toen de olieprijs weer ging zakken. Het systeem stierf toen een natuurlijke dood.

Stelling 1: Evolutie in de digitale wereld wordt idealiter bepaald door architectuur, de levenscyclus door engineering en economie.

Revolutie

Revolutie is wanneer de aard van het systeem abrupt verandert. De overgang van het stoken op kolen naar het stoken op gas was bijvoorbeeld een duidelijke revolutie. Maar er zijn ook minder zichtbare revoluties. Een voorbeeld is de komst van de slimme meters. Tot nu toe worden analoge meters gebruikt om ons energieverbruik te meten. Regelmatig moeten de meterstanden worden doorgeven aan de energieleverancier. Deze gebruikt de meterstanden voor facturering, inkoop en eventuele capaciteitsaanpassingen aan het netwerk. Slimme meters zijn meters die bijna continue het verbruik doorgeven via een communicatienetwerk. Daarmee kan een energieleverancier veel directer inspelen op lokale pieken en dalen in het verbruik, De energieleverancier heeft op afstand controle over de slimme meters en kan bijvoorbeeld op afstand ervoor zorgen dat een gebruiker of groepen gebruikers worden afgesloten van de energievoorziening.

Stelling 2: Revolutionaire veranderingen in de digitale wereld ontstaan door engineering.

Chaos

Als ik een slimme meter in huis krijg wordt ik opeens onderdeel van een extreem groot systeem, ik zit opeens in het netwerk van alle slimme meters en de energieleverancier. Wie kan het gedrag van zo’n netwerk voorspellen? Wat gebeurt er als hackers toegang krijgen tot de gegevens, of nog erger tot de systemen bij de energieleverancier die de slimme meters aansturen? Of als die systemen zelfstandig beslissingen gaan nemen die we vooraf niet hebben kunnen inschatten. Uit ervaring met complexe systemen zoals grids in de energiesector weten we dat het gedrag van dergelijke systemen soms heel onvoorspelbaar wordt door kleine oorzaken met grote gevolgen.

Als niet meer duidelijk is wie de controle heeft over een systeem spreken we van chaos. Op kleine schaal is mijn luchtverwarmingssysteem al chaotisch. Want wie voert de centrale regie over mijn systeem? Wie heeft direct toegang tot alle kennis van mijn systeem? Als het systeem niet meer werkt moet ik als gebruiker een hele procedure doorlopen om te achterhalen of ik de storingsdienst moet laten komen zonder dat me dat onnodig geld gaat kosten5. En een storingsmonteur heeft ook nog maar beperkt inzicht in het systeem, want van de interne werking van de elektronica begrijpt hij ook niets. En ik moet er niet aan denken wat er straks gebeurd als ik storingen krijg die te maken hebben met die gehackte ‘slimme’ meter….

Een andere vorm van chaos is dat door de beschikbaarheid van informatie iedereen veel mondiger wordt en dat beslissingen van bovenaf niet meer zonder meer worden geaccepteerd. En dergelijke chaos kan opeens betrekking hebben op mijn luchtverwarmingssysteem. Zo ontstond na een uitzending op 30 maart 2008 door Zembla rumoer over balansventilatie. Mijn huis was een spaarwoning en al in 1983 voorzien van een vergelijkbaar systeem. Het letterlijke advies bij balansventilatie is om je ramen zoveel mogelijk dicht te houden omdat het balansventilatiesysteem alles regelt, dus ook de frisse lucht in huis. Door verkeerde manieren van installeren en/of het niet goed reinigen van filters ontstaan vaak gezondheidsproblemen. Dat blijkt zulke vormen aan te nemen dat er nu een brede discussie is ontstaan of dergelijke systemen nog wel moeten worden geïnstalleerd. Thuis houden we nu gewoon ’s nachts de ramen open en we merken dat de onderhoudsmonteur alerter is op het vernieuwen van de filters. Door het openhouden van de ramen is de warmteterugwinning minder efficiënt geworden en misschien wel onrendabel. Maar onze gezondheid vinden we toch iets belangrijker…

Een andere chaos is ontstaan rond de slimme meters. Door twijfel over de beveiliging van het systeem en mogelijke problemen met de privacy is ook rond de slimme meters een brede discussie ontstaan waardoor de wettelijke invoering wordt vertraagd. Dus de chaos kan zo groot worden dat zelfs de wetgever niet meer “in control” is.

Stelling 3: Chaos ontstaat door toenemende openheid en complexiteit en in chaotische systemen kunnen kleine, vaak onvoorziene, oorzaken enorme gevolgen hebben.

We zijn niet uniek!

Door de miniaturisatie van chips en het toenemende gebruik van open standaarden wordt het steeds makkelijker om alles met alles te verbinden. Alles wordt voorzien van goedkope chips en overal ontstaan nieuwe informatiestromen. Voorbeelden zijn onder andere RFID, de OV chip, betalen met de mobiel telefoon en natuurlijk die slimme meters. Netwerken worden steeds groter, met steeds meer knooppunten en verbindingen. En netwerken worden op hun beurt weer verbonden met andere netwerken. Daarmee worden allerlei tot dan toe onbekende invloeden van buitenaf geïntroduceerd waarvan het effect vaak niet direct zichtbaar zal zijn. Systemen zullen steeds meer gaan lijken op biologische systemen met een vergelijkbaar gedrag [Kelly, 1994].

Kortom we zullen moeten leren leven met chaos! Het is onmogelijk om dit soort systemen nog te blijven beschrijven en te controleren en aan te passen met behulp van statische documenten. Een chaotisch systeem evolutionair aanpassen wordt onmogelijk zonder simulaties en analyses6. Gelukkig kunnen we heel veel leren van andere disciplines als het gaat om het omgaan met dergelijke complexe systemen. Voorbeelden van dergelijke disciplines zijn:

  • meteorologen;
  • seismologen;
  • macro-economen;
  • biologen;
  • vliegtuigbouwers.

Al deze beroepsgroepen hebben in één ding gemeen: ze werken met dynamische modellen! En allemaal weten ze dat ze nooit dingen met 100% zekerheid kunnen voorspellen omdat ze te maken hebben met chaotische systemen. Zelfs de vliegtuigbouwers weten dat ze nooit een 100% veilig en voorspelbaar vliegtuig zullen kunnen maken. Want bij chaotische systemen, zoals het weer, de natuur, een vliegtuig, ben je altijd afhankelijk van invloeden van buitenaf.

Hoewel we in hoog tempo alles in de digitale wereld met elkaar verbinden en blootstellen aan invloeden van buitenaf blijven wij onze systemen ontwerpen en documenteren alsof het gecontroleerde gesloten systemen zijn die we evolutionair kunnen blijven aanpassen. Als er al modellen gebruikt worden dan zijn die net als de rest van de documentatie vaak inconsistent, opgeslagen in informatie silo’s en gericht op het beschrijven en voorschrijven van delen van de structuur en zeker niet gericht op het voorspellen van het dynamische gedrag van een systeem.

Zeg nu zelf: Wie zou er in een modern passagiersvliegtuig durven te stappen wanneer dieontworpen en gebouwd is zoals het gemiddelde systeem in de digitale wereld, zelfs als dat onder architectuur is gebeurd?Ik in ieder geval niet…

Model-Based Systems Engineering (MBSE)

In de digitale wereld is systems engineering (SE)het vakgebied dat zich het meeste bezighoudt met het modelleren, simuleren en analyseren van zowel de dynamische kant van systemen als de statische structuur. INCOSE is een non-profit organisatie, vergelijkbaar met The Open Group, die zich bezig houdt met het ontwikkelen van het vakgebied systems engineering. Belangrijke leden zijn onder andere het MIT, NASA en Boeing (de laatste twee zijn ook lid van The Open Group). Het aardige is dat INCOSE in 2007 een visiedocument [INCOSE, 2007] heeft uitgegeven hoe SE er in 2020 uit zou moeten zien. In dat document staat in de inleiding:

There is a growing realization that systems engineering is essential to successfully design, develop and sustain the highly complex systems of the 21st century. Yet, the profession suffers from the lack of a set of unified principles, models that support a wide range of domains, and consistent terminology and definitions. Furthermore, there is a prevailing perception that systems engineering is overly cumbersome and not readily applicable to small projects or small businesses.

One can expect a shift away from a “one size fits all” definition and application of systems engineering to a more specifically defined and precise application of systems engineering in diverse domains. The future systems engineering environment will fully support life cycle perspectives such as supply chains and system sustainment. New costmodels will begin to quantify the bottom-line contributions of systems engineering practices. Technology innovations are the primary drivers that influence the capabilities of system products, as well as the practice of systems engineering. Chief among these is the continuing evolution of information technology, with associated applications toboth system implementations (both large and small, including micro-systems) and tomodel-based techniques for systems engineering. Emerging conceptual and technological areas, such as complexity theory, nano-technology and genetic engineering already stretch the validity of present systems engineering processes.

In many respects, the future of systems engineering can be said to be “modelbased.” A key driver will be the continued evolution of complex, intelligent, global systems that exceed the ability of the humans who design them to comprehend and control all aspects of the systems they are creating. The role of modeling will mature to respond to this need. Virtual development environments will minimize the need for physical prototypes and accelerate the development time for new products while providing realistic verification against customer requirements. These environments will support a seamless flow of product information across all phases of the system life cycle, including design, engineering, implementation, test and evaluation, and operationalf support. Workflow management tools will support the globally distributed, collaborative teams that will utilize these virtual development environments. Management of product data throughout the lifecycle will be enhanced by improved support in the logistics and operations and maintenance phases using design data retained in common repositories governed by data exchange standards.”

De door mij vet-gemaakte tekst in de quote geeft aan dat SE zich bewust is van de problematiek met betrekking tot complexe systemen die op ons afkomt. En SE ziet ook de noodzaak van samenwerking met andere disciplines om die problematiek het hoofd te kunnen bieden, zoals is te zien in het volgende figuur uit hetzelfde document:

Hetzelfde visiestuk bevat ook het volgende plaatje dat weergeeft dat er een transitie nodig is van het werken met allerlei losse documenten naar het werken met een model:

Een succesvol voorbeeld van MBSE: Building Information Modeling

Model-Based System Engineering maakt de afgelopen 10 jaar furore in de fysieke architectuurwereld onder de naam Building Information Modeling(BIM) waarbij alle informatie die te maken heeft met het ontwerpen en bouwen van een gebouw in één logisch model wordt gestopt. Het model wordt onder andere gebruikt voor risico- en impactanalyses, voor simulaties hoe en in welke volgorde dingen in elkaar gezet moeten worden, voor het opgeven nauwkeurige specificaties aan fabrikanten van onderdelen en het automatisch genereren van tekeningen en documenten. Het model is meestal eigendom van de opdrachtgever en alle partijen (architecten, engineers en bouwers) zijn dan contractueel verplicht om het model gebruiken op basis van gelijkwaardigheid. Voordeel als iemand wat wijzigt dat de andere partijen de wijziging plus de impact direct zien. Deze methode is zo’n groot succes dat toeleveranciers vaak op vrijwillige basis meewerken om het model te voorzien van specifieke informatie. Daarnaast zijn er initiatieven gestart om open standaarden te creëren die ervoor zorgen dat de gebruikers niet afhankelijk worden van bepaalde tools en/of leveranciers [NBIS, 2007].

Voor de opdrachtgever is het grootste voordeel dat er een enorme besparing is op de projectkosten doordat er veel efficiënter wordt omgegaan met informatie. Geen inconsistente informatie meer verspreid in allerlei informatie silo’s zoals in verschillende modellen, tekeningen, losse documenten en mailboxen! Daarnaast beschikt de opdrachtgever zo na realisatie over een complete en consistente set aan informatie, in de vorm van het model, dat bruikbaar is voor de rest van de levenscyclus van het gebouw. Onderzoeken spreken van een ROI van 67% tot bijna 40000% op de BIM kosten, waarbij de tendens is dat de ROI groter wordt naarmate het om grotere en complexere projecten gaat. Een dergelijke ROI is ongekend hoog vergeleken met andere ICT-hulpmiddelen!

Dat BIM zoveel draagvlak heeft gekregen komt mede doordat het Guggenheim Museum in Bilbao, ontworpen door Frank Owen Gehry, met behulp van BIM technieken(al bestond de term destijds nog niet) binnen budget en op tijd is opgeleverd. Dat terwijl het ontwerp bestond uit nooit vertoonde vormen en er gebruik werd gemaakt van nieuwe, voor de bouwwereld onbekende materialen. Zo is het gebouw bekleed met 33000 titanium platen, ieder met een unieke vorm! Dat betekende dat er ook hele nieuwe fabricage en constructie technieken ontworpen moesten worden. Hiervoor is gebruik gemaakt van kennis uit de vliegtuigindustrie.

De architecten en engineers in de fysieke bouwwereld hebben de visie gehad om gezamenlijk ICT in te zetten om creatiever enefficiënter te kunnen werken. Dan kunnen de architecten en engineers in de digitale wereld toch niet achterblijven?

Hoe nu verder?

Afhankelijk van de reacties wil ik in een vervolgartikel concreter in gaan op welke wijze en met welke middelen begonnen kan worden om kennis op te doen rond het werken met dynamische modellen. En daarin zal ik ook aangeven hoe ik zelf de toekomst zie rond het dynamisch modelleren van complexe systemen.

Aan The Open Group en alle leveranciers van architectuur raamwerken geef ik het advies om samen met INCOSE te werken aan een duidelijke visie over Model-Based Architectuur+Engineering.

Tot slot wil ik nogmaals de oproep doen aan de belangrijkste betrokken partijen om allemaal te helpen om model-based systems engineering te promoten door het genereren van vraag, want alleen vraag creëert aanbod:

Oproep!

Aan de engineers:

wordt geen architect maar een Systems Engineer gespecialiseerd in het modelleren

Aan de opdrachtgevers:

stel contractueel verplicht dat er binnen projecten met één logisch informatie model wordt gewerkt, accepteer geen informatie silo’s en verspilling van kosten

Aan alle architecten:

Maak geen modellen maar gebruik ze! Vraag om ondersteuning van system engineers om je kunnen helpen bij het modelleren, simuleren en analyseren van het dynamische gedrag van je ontwerpen

Bibliografie

[INCOSE, 2007] INCOSE: INCOSE Systems Engineering Vision 2020, 2007
[NIBS, 2007] National Institute of Building Sciences: National Building Information, Modeling Standard, 2007
[Kelly, 1994] Kevin Kelly: Out of Control: The New Biology of Machines, Social Systems, & the Economic World.

1Er zijn ook niet-legitieme belanghebbenden, bijvoorbeeld een bankrover is een niet-legitieme belanghebbende bij (met name het beveiligingssysteem van) een bank

2De opdrachtgever heeft ons huizenblok laten bouwen als een soort modelspaarwoningen waarin een aantal voor onze regio vernieuwende technieken werden toegepast, zoals de toepassing van houtskeletbouw en de beschreven toen nog experimentele luchtverwarming die later in uiteindelijk zo’n 6000 woningen is toegepast.

3Het oorspronkelijke systeem werkte met 3 verschillende zones die afzonderlijk via eigen thermostaten te regelen waren. Het vervangende systeem werkt nog maar met 1 zone, dat wil zeggen dat de verwarming voor hele huis via 1 thermostaat wordt geregeld. Per ruimte kan je de temperatuur beïnvloeden door de luchttoevoer te beïnvloeden door de roosters meer open of dicht te zetten.

4En mijn systeem bestaat nu netjes uit loosely-coupled systemen die samenwerken, het oorspronkelijke systeem was een niet te onderhouden alles-in-één systeem.

5Bijvoorbeeld: als ik de storingsdienst laat komen en het probleem ligt aan de batterijen van de klokthermostaat dan valt dat niet onder het onderhoudscontract en moet ik de voorrijkosten zelf betalen.

6 Je ziet nu al dit soort problematiek bij grote bedrijven waarbij het heel moeilijk is om goed lifecycle en capacity management te doen op generieke componenten in de ICT infrastructuur!

Peter Bakker, Sogeti Nederland B.V.

[PDF]

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.55

Geschreven door Marc Lankhorst op 05-05-2009 13:58

Aardig discussiestuk, al ben ik het er op één punt mee oneens. Waarom zou een goede architect niet zowel de creatieve als de rationele kant kunnen invullen? Dat is wat nu precies ook de taak van een 'echte' architect in de bouw is: vernieuwende oplossingen voor ruimtelijke problemen bedenken die constructief goed in elkaar zitten, bouwbaar zijn binnen tijd en budget, etc. Zo'n echte architect maakt zowel houtskoolschetsen als precieze bouwtekeningen, rekent bestekken door, etc. Ik ken mensen uit die branche en die combinatie van twee hersenhelften is nu precies waarin ze zijn opgeleid. Ik vind dan ook dat een goede architect in ons vak zelf in elk geval de essentiële beschrijvingen, modellen en berekeningen moet kunnen maken en gebruiken en dat niet aan een "engineer" kan overlaten (overigens een functienaam die ook al erg overloaded is).
Je ziet overigens in de bouw ook het gebruik van steeds geavanceerdere modelleertools voor het creatief en constructief ontwerpen van complexe vormen. Denk bijv. aan het werk van Frank Gehry (zoals het Guggenheim in Bilbao), die een CAD-programma uit de vliegtuigbouw (Catia) gebruikt.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.54

Geschreven door Marc Lankhorst op 05-05-2009 14:07

In aanvulling op mijn vorige reactie: ik bedoelde te zeggen dat het werk van Gehry waaraan je refereert juist een voorbeeld is van die combinatie van creativiteit en constructief ontwerpen, gefaciliteerd door geavanceerde modelleertools. Bij uitstek dus een combinatie van die twee hersenhelften.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.54

Geschreven door Peter Bakker op 05-05-2009 14:49

Beste Marc (5/5 12:58),

Ik denk dat mijn oproep aan de architecten enige toelichting behoeft (en een kleine taalkundige verbetering). Het "Maak geen modellen maar gebruik ze! Vraag om ondersteuning van system engineers om je te helpen bij het modelleren, simuleren en analyseren van het dynamische gedrag van je ontwerpen" is geïnspireerd door de werkwijze van Frank Gehry. Die maakt zelf alleen maar schetsen. Zijn modellen, of het nu houten, papieren of digitale modellen zijn, laat hij maken door specialisten. Die specialisten noem ik “systems engineers” om zo de link te leggen naar INCOSE en omdat ik zo gauw geen goed alternatief wist (ik had nog wel even gedacht aan de titel modelbouwer…).
Het idee is dat de architecten en "gewone"engineers zich kunnen richten op hun core business, het ontwerpen zelf.

De systems engineer is een ander soort engineer dan bijv. de engineer van de luchtverwarming. Systems engineers zijn de mensen die zorgen dat de modelleersoftware en het model goed werken en dat het model consistent is, en ze zijn gespecialiseerd in het maken van bijv. update scripts en queries. Een rol die je zou kunnen vergelijken met DBA’s bij database systemen, zeker in de tijd dat database systemen net nieuw waren. De inhoud van het model moet komen van de architecten en engineers en beide gebruiken ze de resultaten van simulaties en queries.

In de fysieke bouwwereld zie je dat kleinere bureaus die met BIM software werken geen aparte systems engineer/modelbouwer rol hebben, maar die werken vaak ook met minder krachtige modelleersoftware. Ook zie je de constructie dat het hele informatiemodel onder verantwoordelijkheid van de opdrachtgever door een gespecialiseerd bureau wordt opgezet en onderhouden. Zo’n bureau zou in mijn verhaal een systems engineering bureau zijn. Er zijn dus allerlei constructies mogelijk.

Belangrijkste is dat architecten en engineers met één gezamenlijk informatiemodel werken.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.54

Geschreven door Marc Lankhorst op 05-05-2009 21:32

Ik ben het met je eens dat architecten en engineers met een gezamenlijk model zouden moeten werken, of liever een onderling samenhangende verzameling modellen (wat conceptueel min of meer hetzelfde is). Denk ook aan de Model-Driven Architecture ideeen. Door verschillende aspectmodellen voor verschillende stakeholders (waaronder de architecten en engineers, maar ook andere betrokkenen bij het ontwerp- en realisatieproces, van projectmanagers tot IT-auditors) met transformaties aan elkaar te koppelen krijg je een gezamenlijke en samenhangende informatieruimte voor het ontwerpen en realiseren van architecturen.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.54

Geschreven door Daan Rijsenbrij op 06-05-2009 09:29

Marc,

In theorie kan een goede architect ook een goede engineer zijn. Maar het vakgebied is tegenwoordig zo groot(s), dat dergelijke personen nauwelijks aanwezig zijn. Ik denk ook dat architecten en engineers, hoewel ze elkaar broodnodig hebben, totaal verschillende interesses hebben. De architect kijkt onder andere naar schoonheid, beleving, ordening vanuit het standpunt van de gebruiker (ordening van functionaliteiten), een conceptueel gevoel hoe het gedrag van het onderhavige object zal zijn. Een engineer kijkt naar efficiency, ordening van componenten, de technische adaptiviteit van de constructie, om maar een paar zaken te noemen.
Ik zou hierover wel eens wat meningen willen horen:
waar streeft een architect naar?
waar streeft een engineer naar?
en hoe verhouden dergelijk zaken zich tot elkaar?

Hoewel ik al meer dan 14 jaar bezig ben met architectuur (en wellicht ben ik volgens sommige maar een middelmatige architect) en ruim 40 jaar intensief bezig ben in de IT, ben ik een relatieve leek in engineering. Dit vakgebied is zo moeilijk dat het vele jaren intensieve studie kost om echte efficiënte systemen te kunnen bouwen, met de juiste technische adaptiviteit, de gevraagde performance, om nog maar te zwijgen over security.

Zoals ik al in de discussie over TOGAF weergaf is er volgens mij een groter tekort aan goede engineers dan aan goede architecten, hoewel er van laatst genoemden ook te weinig zijn.

Vriendelijke groet,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.54

Geschreven door Peter Bakker op 06-05-2009 15:33

Daan,

Wat er in mijn optiek totaal ontbreekt in de IT zijn de mensen die kunnen bewijzen dat een ontwerp voldoet aan de gestelde eisen:

- de systems engineers noem, de mensen die gedurende het ontwerp kunnen bewijzen dat de oplossing als geheel werkt, ook onder verschillende soorten belasting, en kunnen aantonen wat er met het geheel gebeurd in verschillende worse-case scenario's (bijv. simuleren van disasters).

- engineers, de mensen die tijdens het ontwerp kunnen bewijzen dat een deeloplossing werkt onder verschillende belastingen en moeten kunnen aantonen wat er gebeurd bij worse-case scenario's met de deeloplossing

Momenteel hebben we geen van beide type engineers, alleen maar specialisten, mensen die ontwerpen zonder dat ze werkelijk kunnen bewijzen wat het dynamische gedrag is van hun ontwerp.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.54

Geschreven door Marc Lankhorst op 06-05-2009 17:11

Inderdaad, daaraan is zeker gebrek, m.n. als het gaat om grotere systemen. En daar komt dan nog de expertise bij van het goed kunnen begroten wat e.e.a. gaat kosten.

Wat dat betreft zien we in de overigens IT hetzelfde als bij grootschalige fysieke infrastructuur zoals de Noord-Zuidlijn. Er is nog onvoldoende ervaring met vergelijkbare projecten en systemen om goede inschattingen te kunnen maken, er wordt consequent te optimistisch begroot en de technische risico's worden onderschat, zodat er straks een paar mooie pandjes in de gracht donderen...

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.54

Geschreven door Daan Rijsenbrij op 08-05-2009 09:55

Mark,

Het grote probleem met het vakgebied van de engineers ligt in de weerzin om daadwerkelijk te investeren en in de te lage uurtarieven.

Om een engineer op te leiden die zaken ook daadwerkelijk kan doorrekenen, tunen en met creatieve constructies kan komen is veel tijd en geld nodig. Veel meer dan een boekje over SOA uit je hoofd leren. Het lijkt wel of de universiteiten en HBO’s geen zin hebben in het opleiden van werkelijke vakmensen en de commerciële ondernemingen het geld niet willen investeren.

Het uurtarief van een topengineer dient hoog te zijn. Een externe engineer zal na een intensieve opleiding niet meer dan 800 facturabele uren per jaar maken (een interne engineer zal niet meer dan hetzelfde aantal uren aan direct productieve werkzaamheden besteden). De rest van de uren gaat op aan het bijhouden van de vaklectuur, aan experimenten met nieuwe constructieconcepten en aan ‘snijverlies’ door de tamelijk korte opdrachten.
Het zou mij trouwens niet verbazen als een topengineer een hoger uurtarief zal hebben dan een toparchitect omdat de laatste een wat hogere utilisatie kan halen. Maar ook een architect moet naast feitelijk werk veel studeren en uitproberen om te voorkomen dat hij de boekjes van anderen staat voor te lezen.

Vriendelijke groet,
Daan.

PS: Topengineers heb je trouwens zo weinig nodig dat het voor ondernemingen en overheidsinstellingen voordeliger is om er een in te huren van een extern engineersbureau dan de persoon zelf op de loonlijst te hebben.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.54

Geschreven door Marc Lankhorst op 08-05-2009 11:31

Opleiding is zeker een deel van het probleem, maar volgens mij zit het nog dieper. We missen voor een groot deel nog de methoden en technieken om die engineering goed uit te voeren. Zo zijn formele methoden voor het garanderen van de correctheid van software nog steeds niet goed op te schalen naar de omvang van real-life systemen die je bijv. bij banken of overheidsorganisaties tegenkomt. In de bouw kun je 'eenvoudig' overdimensioneren, omdat de sterkte van een constructie min of meer lineair afhangt van de dikte van de balken. In de software kan een enkel bitje verkeerd de hele zaak platleggen, m.a.w. een niet-lineair verband.
Dat betekent dat de simulaties die Peter voorstelt niet voldoende zijn voor het garanderen van de kwaliteit van een systeem. Ze zeggen wel iets over het gedrag onder belasting, maar niet over dit type niet-lineair foutgedrag. Volgens mij maakt dat dit probleem fundamenteel moeilijker dan engineering in de fysieke wereld.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.53

Geschreven door Daan Rijsenbrij op 08-05-2009 13:37

Mark,

Ik heb het gevoel dat wij, wat betreft de rol van engineering, ongeveer op dezelfde golflengte zitten.
Heb jij een lijst van onafhankelijke engineers dan wel engineeringbureaus die werkelijk kwaliteit leveren?

Andere lezers,

Hebben jullie ervaring met onafhankelijke engineeringbureaus die een architect daadwerkelijk kunnen ondersteunen, dan wel tegenspel kunnen bieden aan de creatieve vormgeving van hun ideeën?

Groet,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 13.53

Geschreven door Peter Bakker op 09-05-2009 08:06

Beste Marc (10:31),

In je reactie zeg je "Dat betekent dat de simulaties die Peter voorstelt niet voldoende zijn voor het garanderen van de kwaliteit van een systeem." En dat ben ik helemaal met je eens want mijn doel is het kunnen garanderen van de kwaliteit van het ontwerp. En daarmee zou je veel nauwkeurigere specificaties moeten kunnen opleveren aan de bouwers zodat die veel minder op basis van eigen interpretaties hoeven te werken.

BIM heeft er ook 20 jaar over gedaan om geaccepteerd te worden en is ook met kleine stappen begonnen. Dus misschien zijn niet alle tools en technieken er om alles te kunnen wat we uiteindelijk zouden willen maar dat zou ons niet moeten weerhouden om:

- een duidelijke visie te bepalen (net als of het liefst met INCOSE, waar willen we zijn in 2020)
- beginnen met de tools/technieken die er nu al zijn om ervaring op te doen met eenvoudige dynamische simulatie en analyse technieken (dan kan je ook beter bepalen welke dingen er echt missen om het uiteindelijke doel te bereiken)

Software is inderdaad de meest complexe component omdat je te maken hebt met veel COTS-componenten en bij zelfbouw is het lastig om te bepalen of software schrijven nu ontwerpen is of bouwen (ik denk allebei tegelijk). Dus in mijn optiek kan je beter top-down (business) en bottom-up (infrastructuur) beginnen met relatief kleinschalige modellen en simulaties/analyses en voor de software aansluiten bij de al bestaande model-driven initiatieven. En als je tot die tijd software componenten modelleert als black-boxjes waar iets ingaat en waar iets anders uitkomt kan je die met de huidige technieken al opnemen in simulatie modellen zonder dat je je zorgen hoeft te maken over de uiteindelijke implementatie.

Technieken om mee te beginnen zijn er, bijv. SysML (straks onderdeel van UPDM) heeft een flow component en ondersteunt flow modelling of je kunt starten met stock&flow (system dynamics) tools zoals Vensim om ervaring op te doen.

Een Boeing 777 die compleet model-based is ontworpen bevat tenslotte ook enorm veel software componenten dus als het daar kan waarom niet in de digitale wereld?

Sponsoren

Sessies

15-02: GIA sessie over digitale transformatiespel meer...

19-03: NAF Insight met Jeanne Ross meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden