aec

Maandag 2 juni was er een debat georganiseerd om te kijken of de bouw nu voor of achter loopt qua ICT. Onder andere georganiseerd door de nieuwbouw, waarvan ik ook twee eerdere samenvattingen heb gemaakt.

De discussie werd geleid door Anton Schippers van Kraan bouwcomputing . Hij had drie stellingen voorbereid waar een panel en de zaal op konden reageren

• Standaardisatie moet afgedwongen worden. Dat is de enige manier om ict toepassingen massaal doorgang te laten vinden in de bouw.
• Over twee jaar kan niemand in de sector meer om het BIM (bouw informatie model) heen.
• Veel bouwondernemingen hebben korte termijn strategiën. Er zijn dus geen noodzakelijke lange termijn investeringen in ict. Dat is funest voor innovatie door middel van ict.

Stelling 1: afdwingen standaardisatie

Ik maakte een opmerking over het ophakken in kleine stukken. Bestaande standaardisatieinitiatieven zijn eigenlijk allemaal groot en bouw-overkoepelend. De terminologie van de hele bouw moet erin gevangen worden. Dat krijg je toch nooit van de grond? Begin liever met kleine losse deelgebieden van de bouw en probeer het later aan elkaar te knopen. (Voordat ik het te lang maak: zie m'n proefschrift ).

Een andere probleem dat werd genoemd was wantrouwen. In de bouw wordt veel geregeld en gesjacherd: transparantie is dan niet gewenst. En als je je collega-bedrijven wantrouwt wil je ook niet dat ze bij "jouw" informatie kunnen. De informatie loopt op deze manier nooit de hele keten door.

Financiering is ook een probleem. "Maar er is toch genoeg geld in Bouwend Nederland?" "Tja, we zijn al zolang bezig... enige mogelijk is gewoon beginnen en proberen."

Er is een BIM case week geweest waar met 90 personen met BIM is gewerkt. Er ontstond vertrouwen en men begon beetje bij beetje samen te werken: ook qua ict communicatie.

ETIM is, refererende aan het ophakken in kleine stukjes, klein begonnen: met inkoopinformatie. Dat werkte en had success omdat het aantrekkelijk was. Omdat er geld mee verdiend kon worden. Belangrijk voor BIM: het moet ook gemakkelijk zijn, bijvoorbeeld voor de loodgieter. Bij Oranjewoud merkten ze dat het in de praktijk al lastig was om een website met wachtwoord voor de meest recente tekeningen gebruikt te krijgen.

Een ander probleem is dat men geen verdienmodel in de nieuwigheden ziet. De staandaard verdienpunten (uitknijpen, afdingen, enz) gaan weg zodra het transparant wordt. Eng.

Iemand kwam terecht met een bedrijfskundige kijk op de zaak: OF de ict toepassing is gewoon niet goed OF je krijgt van het goede product niet verkocht dat het goed is. In die redenatie hoor je geen enkele keer het woord standaardisatie: heeft dat er dan wel mee te maken? We keren in onszelf en komen met een oplossign waar geen behoefte aan is.

De samenvatting van Anton:

• Op deelprojecten kan je succes boeken. Goed punt om mee te beginnen.
• Vertrouwen is een belangrijke factor.
• De behoefte is er kennelijk niet direct.

Stelling 2: BIM over twee jaar onomkoombaar

Eigenlijk iedereen: nee. Voor wie is het het belangrijkste? Eigenlijk de hele bouw. Veel partijen hopen op goede data van het deel van de bouwketen dat voor hen zit (en hebben geen zin om zelf goede data aan de keten na hen te leven). Het enige dat lijkt te zorgen voor marktacceptatie is dwang van bijvoorbeeld de overheid (BIM door de USA overheid, STABU bestek door de NL overheid) of het verkopen van bouwmateriaal (zoals bij de succesvolle ETIM standaard).

Er zijn bedrijven die het nu, met bouwpartners, lekker BIM-achtig geïntegreerd doen en er 40% rendementsvoordeel uit krijgen. En langzaam wordt dat gekopieerd. Maar uiteindelijk heb je het nodig dat een grote partij het doet, niet een paar kleinere bedrijven die die 40% pakken. Concurrentie is iets waar je wakker van wordt. Ikea bouwt goedkope woningen in het Verenigd Koninkrijk: dan gaan UK aannemers echt wel even opletten.

Qua architecten moet je ze eerst allemaal van 2D naar 3D krijgen. Veel bureaus doen het trouwens al of zijn ermee bezig. Iemand uit de aannemerij zei trouwens dat hij graag standaardisatie en afspraken wilde: "steeds weer mooie paketten, maar ze sluiten niet op elkaar aan".

Anton: vroeger wilden automatiseerders niet samenwerken. Nu is het anders. Maar het zit ook op mensen vast: de wil moet er zijn.

Stelling 3: korte termijn visie, dus geen lange termijn ict investeringen

Voor veel bouwondernemers is het inderdaad zo. Veel kleine bedrijven zijn "gewoon aan het werk". Geen innovatie, zowel vakinhoudelijk als qua ict. Investeringen zijn vaak anti-cyclisch. Pas als het slecht gaat proberen ze te innoveren. Ze zijn er trouwens wel, de kleine bedrijven die innoveren. Een van de panelleden had er laatst 80 langs voor workshops.

Het zijn ook veelal juist de kleinere bedrijven die innoveren. Ze zijn van nature veel slagvaardiger.

De markt begint aan de leveranciers te zeggen dat ze het beter kunnen doen. De Rotterdamse havendienst die zaken aan de markt oplegt enzo. Er begint begrip te ontstaan dat er een mismatch is.

Het is een feit dat je tegenwoordig wat kan met BIM. Dat was 10 jaar geleden niet zo, daar moest je niet mee aankomen. Nu werkt het deels tenmiste! Onontkoombaar in twee jaar? Da's te snel, maar er begint wat te komen.

Slotopmerkingen

• Successen vieren zodat het niet te ontkennen is.
• BIM gaat er komen, maar het zullen meerdere BIMs zijn. Je kiest een leuke uit voor je project!
• BIM: leuke nieuwe uitdaging voor software bouwers.
• BIM kan sneller gaan dan we denken. Luister wel goed naar elkaar.
• Een BIM, da's gewoon de toekomst. Maar het is nog best lastig.

Maak het tastbaar, dan kan het groeien. En COMMUNICEER het.

I've been quite distracted today by a fire at my former university (technical university Delft, the Netherlands). I studied there at the civil engineering faculty. My building was next to the architecture department's ("bouwkunde"). This morning that building caught fire. No casualties, but the building is a complete write-off. (Photo by praeseodymium )

In that picture there's one spot of visible fire. Three meters to the side and one floor down (approximately, I don't remember the very exact floor) was where I had the meeting with the chairman of my PhD committee. And another floor down was the office of one of my supervisors. Yuck. And the office next to hers and the one next to that: both PhD colleagues that I met quite often. Yuck. It comes pretty close that way.

It was only little more than a year ago that I was inside the building for some small conference...

Update: ok, those rooms that I mentioned: that part of the building just collapsed. You can see the dangling floorplates in this photo . Update 2: and there's a video of the collapse (after 40 seconds).

Tags: bouwkunde, tudelft

Dit is de tweede bijeenkomst van de nieuwbouw waar ik bij aanwezig ben. De eerste was ook daadwerkelijk het eerste congres van "de nieuwbouw" (waar ik ook een samenvatting van heb ). De bijeenkomst van donderdag bestond uit drie delen: een inleidende presentatie door professor Hennes de Ridder, een discussie in 4 deelgroepen en een afsluitende algemene discussie.

Presentatie Hennes de Ridder

De bouw heeft toch wel aardig wat invloed op Nederland. 25% van het wegverkeer is bijvoorbeeld bouwgerelateerd. Bouw weg, files weg. 35% van het afval. Enz. Dus als je de bouw kan verbeteren kan je aardig wat invloed hebben op Nederland als geheel.

Veranderingen

Veranderingen. Ergens is het raar dat gebouwen voor 200 jaar worden neergezet als de wereld (en de eisen aan gebouwen) zo rap veranderd. Het klimaat verandert. De economische situatie verandert. Technologie veranderd enorm. De stormvloedkering in de Nieuwe Waterweg zou bijvoorbeeld nu 20% lichter zijn: hij is overgedimensioneerd. Hij is bijvoorbeeld eigenlijk anderhalve meter te hoog. Oh, en er is voor 25 miljoen een software systeem gebouwd om te zorgen dat er geen foutgevoelige mensen de uiteindelijke sluitbeslissing nemen. Tja, maar er zit natuurlijk in niets zoveel zekerheid van menselijke fouten als in een groot softwaresysteem. Zal nooit goed lukken.

En sinds wanneer weten we dat fijnstof de beperkende factor is bij het ontwerpen van de infrastructuur? Sinds een paar jaar. Dat gooit alles overhoop. Fijnstof is de beperkende factor bij veel infrastructuurprojecten die nu beginnen.

Huizen worden voor 60 jaar levensjaar ontworpen. "Moet al die rommel 60 jaar blijven staan?"

Eisen en wensen

Eigenlijk zou de de bouw een normale industrie moeten worden. Wat is het verschil? In de bouw heb je bijvoorbeeld alleen eisen. Normaliter heb je veel meer een wat algemene oplossingruimte. Ik wil een spijkerbroeek van max 80 Euro, met steekzakken, dat is het wel ongeveer. Keuze van een partner: het moet een meisje/jongen zijn, da's de enige echte eis. De rest is wensen ("liefst rijk en dik").

Eisen zijn lastig. Precies op een eis terecht komen als ontwerper? Onmogelijk. Hoe kan je met ontwerpen precies zeker weten dat je exact op "1m60 onder het gemiddelde hoogwater" terecht komt?

Wensen zijn veel leuker. Daar kan je op scoren. Daar kan je leuke dingen mee doen.

Aanbodgestuurd

Je stapt niet naar Nokia toe voor een eigen individueel mobieltje, maar je kiest uit het bestaande aanbod. In de bouw is alles een prototype. Bos en Lommer dondert ongeveer in elkaar omdat er fouten bij de kolommen zijn gemaakt. Hoeveel kolommen worden er uitgerekend, getekend, bekist, enz. per jaar? Anderhalf miljoen in Nederland. Stommer kan het niet. Wat is de lol ervan om dat steeds weer opnieuw te doen?

En het gaat in de bouw de hele keten door. Meneer boven eist en verrast de toeleverancier ermee. Die verrast zijn onderaanmemer weer, enz. In plaats dat de klant verrast wordt door het beschikbare aanbod vanuit de markt.

De scheepsbouw werkt al geruime tijd met veel vastere basiseenheden in plaats van steeds weer een prototypeboot in mekaar te klussen.

Sommige zaken kan je niet met het Living Building Concept bouwen. Een apart concertgebouw of de noord-zuid lijn. Dat zijn unieke zaken. Dat moet je ook niet op die manier willen.

En al die nieuwe contracten? Met lange looptijden? En inclusief onderhoud? Idioot. Hoe kan je voorspellen hoeveel grafitti er over 10 jaar gespoten wordt? En waarom leg je je voor je schoolkantine voor 40 jaar vast op 1 cateraar, geintegreerd in het bouwcontract? Dan mag je voor je personeelsfeestje over 10 jaar geen wijntje zelf meer meenemen van de cateraar. Wat heeft dat met je bouwcontract te maken? Opsluiten die hap. Heropvoeden. TBS misschien?

Relaties

De bouw is zo gestoord dat ze geen normale relaties aan kan gaan. Wat normaal is: eerst een begin maken met een relatie, dan wat dingen samen doen en dan nog eens wat netjes regelen. In de bouw heerst het angelsaksische systeem in al z'n ellende: je struikelt gelijk in het begin over de juristen.

Er wordt veel met schijnzekerheid gewerkt. Kansrekening om het aannemelijk te maken hoe lang iets kan/moet blijven staan. Maak toch liever een eenvoudige lichte stormvloedkering en kiep hem na 20 jaar in de hoogovens en bouw een nieuwe. Scheelt ook schilderwerk. De oosterscheldekering wordt in mijn leven nog gesloopt, denkt Hennes. Kustverlenging is nu de trend.

Denk meer dynamisch. De wereld veranderd. En de lifecycle van componenten is afhankelijk van de veranderingen in de wereld. Kijk ook nooit terug (naar de "sunk costs"). Maar optimaliseer op ieder moment de kosten en de waarde t.o.v. de verwachte levensduur van de losse componenten. En wat voor invloed heeft dat op het gebouw als geheel?

PPS, publiek-private samenwerking? Vaak verkeerd gebruikt. De klant en de leverancier zijn niet gelijkwaardig. Het schoolbestuur en de aannemer die het schoolgebouw neerzet worden vaak als gelijkwaardig samenwerkende partners gezien. Onzin. Het schoolbestuur is de baas over de school en de aannemer levert gewoon.

Standaardisatie

Traditioneel is het standaardisatieniveau laag. Individuele onderdeeltjes waarop de aannemers zo goedkoop in moeten kopen. Het contractniveau zit daar maar net boven. Het contract is top-down, de eisen (duizenden) zitten heel laag.

Bottom-up, aanbod-gebaseerd werken is dat je vanuit het aanbod standaard-oplossingen aanbiedt. Dan ligt het standaardisatieniveau veel hoger en kan ook het contract veel eenvoudiger en kleiner.

Gebruik het niet voor een exclusief concertgebouw, maar stadions voor AZ en een rijtje wolkenkrabbers aan de Amsterdamse zuidas: gewoon standaarspullen met aanpassingen.

Discussie na afloop van Hennes' verhaal.

Na Hennes' praatje hadden we een discussieronde. We werden in 4 groepen verdeeld. Niet iedereen hoorde precies bij een van de groepen, maar goed.

• Architecten
• Aannemers
• Opdrachtgevers publieke sector (daar was ik bij geplaatst).
• Opdrachtgevers private sector

Er waren drie stellingen om over te discussiëren. Zo'n discussie is lastig op te schrijven, dus dit wordt geen compleet overzicht.

• De verschuiving naar aanbodgericht sturen is zowel voor opdrachtgevers als aannemers en architecten wenselijk.

  Ja. Voor iedereen moet er veel te winnen zijn. Aan de andere kant betekent het verandering en dat zal voor een deel van elke doelgroep pijnlijk zijn.

  De architecten eisten wel esthetische vrijheid.

  De aannemers dachten dat het vooral voor de grote aannemers zou gelden, die kunnen efficienter bouwen. Zelf vond ik dat juist ook kleinere aannemers deelconcepten goed via het living building concept zouden kunnen aanbieden. Hennes denkt dat het inderdaad misschien wel wat meer bij de grotere aannemers kan komen te liggen omdat die meer mogelijkheid hebben voor onderzoek en ontwerp.

• Indien de verschuiving nu op zou treden, zijn we er klaar voor. Welke stappen moeten er nog genomen worden om mee te doen aan de aanbodgerichte markt?

  Zelf vind ik van niet. De opdrachtgevers zeggen dat ze klaar zijn en de aannemers zullen dat ook wel zeggen. Maar allebei wachten ze op de andere partij. "Kom nou met die impuls, dan ben ik er gelijk klaar voor".

  Het is essentieel dat de geleverde objecten van gegarandeerde, gecertificeerde kwaliteit zijn. Je moet erop kunnen vertrouwen.

  Het groepje van de private opdrachtgevers vond dat ze er niet klaar voor waren. De houding moet om. En een omslag in denken van prijs naar waarde.

• Mijn rol in de bouwketen verandert ten goede t.o.v. de andere groepen door deze verschuiving.

  Als opdrachtgever moet je meer betrokken raken bij het proces. Je moet erg goed op de hoogte zijn van je eigen kernprocessen. De aannemer moet weer veel beter en veel meer over de objecten die hij aanbiedt. Meer research en ontwikkeling, bijv. En dat moet dan in het proces bij elkaar komen.

Er was een vraag naar praktijkvoorbeelden. Er is nog niet veel. Er is wat in de woningbouw qua standaardwoningen. In de utiliteitsbouw is er helemaal niet veel. Wel een voorbeeld: BAM heeft twee stadions aan Zuid-Afrika verkocht omdat ze de stadions al in de computer hebben. Verschillende varianten, 3d visualisatie, bestaande kennis, enz. BAM was de enige die met een stadion in z'n laptop naar die lui toe kwam. Ook is er een bedrijf dat standaardbruggen verkoopt (met composietmaterialen) en die verkoopt zich helemaal scheel.

Het is raar dat de bouw zo ambachtelijk is. De heipalen onder het gebouw zijn 100% gegarandeerd en daar kan je op vertrouwen. Maar de kolommen er bovenop worden met de hand geklust. Hoe kan je daar de veiligheid en kwaliteit van garanderen?

Conclusie

En de uiteindelijke prikkel dan? Volgens Hennes kan dat alleen maar geld zijn. Als we er in slagen om met onze voorbeeldprojecten aan te tonen dat er goed geld mee te verdienen en te besparen is...

Overigens: alle 5 foto's .

For photos, see flickr.com.

The informatics section is investigating itself in a self-study. For this, they have the help of three external peers:

• Prof. Robert Woodbury, Vancouver
• Prof. Imre Horvath
• Dr. Joop Paul

For that, they organised a colloquium in which the researchers of the program present their work so that the external peers get a good overview of the work that's going on.

Michael Bitterman - intelligent design objects (IDO)

Architecture design is challenging because it involves multiple conflicting objectives and a load of possible solutions. Also you have to deal with human visual perception, which is not well understood because of its soft nature.

His concept is an intelligent design object that pro-actively adjusts its attributes (size, shape, material) to satisfy some given design criteria. For this, there's some reasoning going on behind the scenes.

The result is more of a computed design than a drawing tool. The optimisation method is inspired by natural evolution. A number of random combinations are tried out. The best ones have the "evolutionary" best chance of being carried over to the next iteration. The best ones cross-pollute each other a little bit every iteration. This turns out to be quite a good way of arriving at an optimal solution.

Human vision is different from a photographic process as you don't see only with your eye, but also with your mind. He asked us to look at the right side of the room, followed by the question whether there were one or two plants in the left corner of the room. I didn't know. I must have seen them with my eye, but my mind didn't register it.

There's actually a pretty good "visual attention" formula that can predict the perception. Perception is "seeing" with uncertainty. it expresses the "degree of seeing". It results in a bell curve. Big objects in the center of vision have a good chance of being perceived. Smaller objects to the side have a lower chance.

You can use such a perception calculation for calculation of the value of certain locations in a shopping center perception-wise. Or the perception value (which translates into monetary value) from seats in a theater. He showed some visual examples which explained the theory well. Looks very, very nice.

Also interesting: knowledge-driven measurement of design performance. How can you say which of the three hotel lobby designs that you made is best? One day, you like number one best, the next day number three. With neural trees and fuzzy logic you can make the measurement explicit. You have to create a tree with a number of input nodes for specific aspects of the design ("openness", "color"). These aspects are combined in the tree by computational nodes that are combined again and again until a final spatial performance is the result.

This us useful for design, for it also shows the aspects where small improvements bring great returns. This way, the architect can concentrate where it matters.

Of course, this neural tree can be combined with aforementioned intelligent design objects... Wow, pretty interesting!

All info can be found at http://www.computationaldesign.bk.tudelft.nl/

Questions for Michael by the external peers

How can you deal with subjectivity in an objective way? Different people like things that other people dislike. Answer: you cannot make a detailed copy of a specific individual's preferences. On the one hand, you can make a pretty good computation model of the perception. This part is unbiased. On the other hand, you use the neural tree to quantify an architect's knowledge and, partially, preferences. Both parts are to be treated differently.

(The rest of the questions were a bit too quick to write down).

Hurray, after 6 years of work I got my PhD on 15 January 2007. Finally I'm done! There was a nice formal ceremony in which I had one hour to defend my thesis against 7 official opponents. Actually pretty funny to do, but very intensive. You've got to keep all your wits about you for one full hour.

That's also exactly one full hour, for after one hour you get a loud bang on the floor of the beadle (Dutch: pedel). That means you've got to keep talking while she looks at her watch as it is appreciated if you have to stop mid-sentence. I even had to stop mid-word, so that went OK :-)

There's a lot more to say, but I'll just link to the photos for now. A switch on the photo camera that was in the wrong position ruined about 80% of the photos, but there are enough left to give a good impression, luckily.

Loads of people have asked me "what I'm going to do now", mostly meaning whether I'm going to continue research or whether I'm going to look for a job now. Well, I'm simply continuing the work I've done for the last 1.5 years: Zest software . Building pretty elaborate websites and intranets (like milieudefensie , triple p , two philips intranets, etc.). For that, I'm working with the content management system Plone that I also used for many of the prototypes in my PhD thesis .

I've got permission (and encouragement) to continue to keep my eye out for opportunities in the building&construction industry. There's still a bit of prototype software lying around that I want to resurrect again as people found it useful and want to use it again. So I'll continue to dabble a bit in it, as it is a really interesting problem :-)

As Sean Mc Grath says, you'd better keep your URLs working, especially when other webapplication depend on your webapplication...

I started to do this quite soon for my bcoWeb website (just a research prototype, mind you). There were some domain name changes (first objects.bcxml.net, then futsweb.org, then bcoweb.org, then nl.bcoweb.org (don't ask)). But, quite early, there was already a small java app of a fellow scientist that used the exported xml data. So I took care to do some URL redirection right from the beginning so that the most important things kept working without him needing to change his code.

It pays off both early on and late in your webapp's life imho.

Donderdag (20 januari) heb ik het eerste congres van de nieuwbouw bezocht. Er waren 150 jonge mensen uit de bouw; ik kreeg het idee dat het voornamelijk HBO/universiteits-niveau was. Wat "de nieuwbouw" is wordt verderop wel duidelijk.

Opening

Het doel van de dag was om iets nieuws mee te nemen, daarom gaf de dagvoorzitster (Babette Leertouwer, PRC) de tip om vooral niet bevestiging te zoeken voor je eigen ideeën, maar om open te staan voor nieuwe dingen. Hans van Rossum - De nieuwbouw

Hans is de voorzitter van de nieuwbouw en had de dag voor het congres een presentatie voor de Regieraad ("de grijze hoofden") gehouden, waarin hij zei dat "de Nieuwbouw zorgt dat het doel van de Regieraad gehaald wordt". Beetje provocerend, in de trend van "de Regieraad denkt rustig en netjes na, wij gaan echt wat doen". A/h eind van de vergadering zei de Regieraad dat de Nieuwbouw een cruciale factor is in de vernieuwing van de bouw.

Hans deed duidelijk z'n best om enthousiasmerend te zijn en legde uit waar de Nieuwbouw voor staat. Het is opinievormend: kom met opinies, de Nieuwbouw biedt een platform om ze te uiten. Projecten bieden de kans om van opinie tot concrete actie te komen. Verder organiseert de Nieuwbouw trefpuntbijeenkomsten zoals dit congres.

Filosofie is om belangeloos te zijn: iedereen neemt deel op persoonlijke titel, men vertegenwoordigd dus geen bedrijf. Ook sectorbreed: alles bij elkaar. En vraaggestuurd: bottom-up, niet bijvoorbeeld kreten zoals "we hebben meer ICT nodig" in het algemeen rondslingeren.

Een vraag uit de zaal naar de aanwezigheid van enkele "grijze koppen" op het congres werd door een grijze kop beantwoord met "we sponsoren dit, want we willen het stimuleren".

Mark van Twist - De bouwsector in perspectief

Vergeleken met Hans, de vorige spreker, was dit een afkoelend praatje. Het thema van het congres was "De Cock en de moord op het vertrouwen", daar haakte Mark bij aan. Wie heeft de moord gepleegd? De politiek? De bouwsector? De gevestigde orde?

Aanleiding voor de moord is de angst voor innovatie en vernieuwing. Achteraf gezien is iets nieuws vaak logisch, maar als je het voor het eerst tegenkomt is het onverwacht. Je krijgt bij innovatie ook een probleem met de berichtgeving. Goed nieuws is geen nieuws, dus de aandacht van de media gaat naar de 5% incidenten; het is lastig om bij innovatie de geslaagde 95% belicht te krijgen...

Innovatie. We zijn nu de Homo Zappens met erg weinig geduld om op de positieve effecten van een innovatie te wachten. Waarbij ook al niet ver in de toekomst wordt gekeken: het toekennen van subsidies gebeurt bijvoorbeeld vooral op basis van past performance.

Dictatuur van het jubeljargon ("transparantie", "open communicatie"). Mooie kretologie, maar je laat de moeilijke afwegingen die erachter liggen weg. En je krijgt alsnog confrontatie bij concretisering van het jubeljargon. "Waren we vroeger niet professioneel dan?" "Wegspoelen van kennis!"

Voor Mark was het mechanisme van de moord het loopje van "problemen van alledag" naar "mooi papieren oplossingsmodel" naar "onbedoelde en ongewenste effecten" naar "gemopper" en terug naar "problemen van alledag". En zo door en zo door. Steeds weer verniewing. Steeds weer vernieuwing. Het steeds weer vernieuwen pleegt de moord. De Nieuwbouw pleegt dus de moord op het vertrouwen (of dat risico bestaat).

Waarom? Innovatie, verantwoordelijkheid en vertrouwen horen bij elkaar. Als innovatie met verantwoordelijkheid gekoppeld wordt, dan blijft vertrouwen ook bewaard. Hoe moord op vertrouwen te voorkomen en toch te innoveren?

• Vernieuwend zijn en vertrouwd overkomen (niet te schoppend zijn).
• Enthousiast en zelfbeheerst.
• Innovatief en herkenning.
• Succes hebben, maar niet te luidruchtig vieren (anders heb je een aanleiding voor een volgende moord).
• Onzichtbaar zichtbaar zijn.

Persoonlijke opmerking: voor mij was dit een punt waarin het zich uitbetaalde om open te staan voor nieuwe dingen. In m'n (a.i.o.) onderzoek ben ik toch bezig met vernieuwende dingen die potentieel veranderende invloed op de bouw kunnen hebben. Dit praatje stimuleert me om minder te schoppen tegen de bestaande praktijk, maar om er duidelijker bij aan te sluiten. Niet dat ik nu stukken proefschrift moet herschrijven, maar de herinnering was nuttig!

Vraag uit de zaal: "Als vernieuwing het vertrouwen vermoord, houdt dat innovatie dan niet tegen? Hoe kan je dan nog innoveren?"

Mark antwoordde dat je moorden krijgt als je alleen verandering wilt. Je moet de vermoorde onschuld voorbij zijn en verantwoordelijkheid nemen/hebben. Wat nodig is voor innovatie is dat innovatie gekoppeld wordt met vasthoudendheid en volharding om de vernieuwing aan te laten sluiten aan de bestaande bouw.

In antwoord op een andere vraag: Mark ziet weinig verschil in innovatie(wens) tussen overheid, bedrijfsleven en ingenieursbureau's.

Paul Spierings - Interne motivatie als bron van energie

Heerlijk praatje vanuit een psychologisch oogpunt, ik heb in ieder geval genoten. Twee filmpjes die hij wilde laten zien werden door powerpoint danwel de laptop danwel de beamer opgegeten, dus hij moest vertellen wat het resultaat van het vertonen was geweest. In het eerste filmpje gebeurde iets onverwachts: gemiddeld ziet 50% het. Tel hoe vaak het witte team de bal overgooit en overstuiterd. Opletten, want je mist snel wat! (link naar filmpje) In het tweede filmpje zit een hele geleidelijke verandering: slechts ongeveer 5% ziet het.

Dus: we handelen naar beste eer en geweten, maar de absolute waarheid weten of zien we niet. Laat een schaker en een niet-schaker allebei naar een stelling op een schaakbord kijken en er daarna met elkaar over praten....

Communicatie bestaat uit twee dingen: de boodschap overbrengen en de boodschap verinnerlijken. Als je langs elkaar heenpraat, grijpt de machtigste de macht:

Excommunicatie

Je bent irrelevant of je mag niet meer praten. Hooguit mag je de dorpsgek uithangen.

Colonisatie

De bovenliggende partij dringt zijn wil op. Vanaf nu denk en zeg je dit!

De menselijke behoefte bestaat ten eerste uit je natje en je droogje, ten tweede uit eigenwaarde. (Paul is het niet eens met economen die zeggen dat de mens economisch handelt: je vernielt soms liever dingen dan dat een ander ze heeft, bijvoorbeeld). Pas bij innovatie dus op voor de behoefte aan eigenwaarde van mensen.

Nog een complicerende factor: de mens is evolutionair er op ingesteld om zich op veranderingen te richten. Als holbewoner bij een meer staande valt de plotselinge rimpeling op; de rest van het meer zie je gewoon niet meer. De rimpeling kan een lekker visje voor je buik zijn of de aankondiging van op jou gerichte snack-neigingen van een krokodil. Je weet het niet, dus meestal ben je voorzichtig.

Trek dit door naar veranderingen. Langzame evoluties doen ons niets (zie tweede filmpje); revoluties doen ons veel. Dingen langzamerhand anders doen is OK; dingen nieuw doen, daarbij hebben we een begrijpelijke terughoudendheid.

Voor revoluties heb je een paradigm shift nodig, zoals bijvoorbeeld in de Verlichting, o.a. Newton met z'n wetenschappelijke houding van voorspelbaarheid/uitrekenbaarheid. Tegenwoordig heb je bijvoorbeeld Heisenberg met zijn onzekerheidsprincipe die daar tegen ingaat.

Revoluties gepland? Onderschat toeval niet, De uitvinding van penicilline is te danken aan een fout van een lab-assistent en het feit dat de proefdier-cavia's "op" waren.

Cruciaal bij veranderingen is het om medestanders te zoeken. Cruciaal is niet het hebben van gelijk, maar het krijgen van gelijk. Columbus zag een oplossing en hing aan bij de macht van zijn tijd. Hij zocht en kreeg een alliantie (in plaats van een rol als dorpsgek). Aansluiten bij het bestaande en ont-dekken. Overtollige steen weghalen: als ingenieurs is het soms moeilijk om met toeval om te gaan, kunstenaars hebben dat veel minder. "Het beeld zit al in de steen, ik hoef alleen de overtollige stukken steen weg te halen".

Wout Korving - Prikkels voor prestatie

(Ah, eindelijk iemand die goed op het internet te vinden is).

Zijn hoofdidee: je kan wat met prikkels.

Over welke prikkels gaat het?

Financiële prikkels. Bijvoorbeeld beloning afhankelijk van prestatie. Langzamerhand komen er steeds meer variabele beloningen in de arbeidsmarkt. In de bouw heb je het ook. Boete als iets te laat af is of vergoeding afhankelijk van opleverdatum. Echt geavanceerd: aandelen in joint-ventures.

Wout's stelling: er zal veel meer variabilisering plaatsvinden van de beloning in bouwprojecten. (Variabilisering = parallel trekken van belangen).

Visie op toekomst van prikkels

Je hebt veel mogelijkheden voor het vertalen van beleidsdoelstellingen in financiële prikkels. Overheden moeten beleidsdoelstellingen beter benoemen en koppelen aan helder meetbare performance doelstellingen.

Er is een trend naar steeds complexer contractvormen, met steeds meer prikkels. Hoe complexer het project zelf, hoe aantrekkelijker een complex contract is.

Waar liggen de kansen?

Je kan creativiteit genereren: je maakt innovatieve oplossingen aantrekkelijk. Met prikkels, dus.

Vragenronde

Vraag: "hoe stel je de variatie vast? Wat is het verschil tussen 96% beschikbaarheid van infrastructuur en 97%?"

Wout antwoordde dat je begint met het uitrekenen van het effect van dat verschil. Fileschade, economische schade, enz. Als tweede moet je oppassen voor het verschil tussen tickle-kill-hurt, oftewel, je moet bepalen wat het effect van de beloning is. Als een opdrachtgever alleen gekieteld wordt houdt hij er geen rekening mee. Is het een draconische maatregel dan boeit het ook niet: dood is dood, dus een beetje doder kan dan ook geen kwaad meer. Een negatieve prikkel moet pijn doen, maar niet doden. Voor een kind is het inleveren van een jaar zakgeld hetzelfde als een boete van 4 miljoen euro...

Paul Spierings: een prikkel kan een eigen leven gaan leiden, pas daarvoor op. In de USSR was een graanoogst geslaagd als het USSR-bureau-voor-de-graanoogst zei dat 'ie geslaagd was.

Vraag: "innovatie zit in mensen, niet in prikkelsystemen".

Reactie iemand anders: "je wordt er heel calculerend van". (Mijn gedachte: dat is deels de bedoeling, maar het levert alleen het goede resultaat als de prikkel goed is vormgegeven: de calculatie moet naar het goede optimum gaan.)

Wout antwoordde dat je het ook moet relativeren: denk aan Enron.

Wout's mening is dat er in de bouw een Delfts denkmodel is: binaire oplossingen. Het is OF goed OF fout. Zijn toevoeging als econoom is om het vloeiend te maken in plaats van binair.

Het uur van de waarheid

Ik geloof dat ik heel weinig televisie kijk, of in ieder geval erg gericht, want ik herkende niet naar welk televisieprogramma dit onderdeel was gemodelleerd. Ik kijk alleen het acht uur journaal en af en toe wat op discovery: daar zat het niet bij :-)

Het was leuk gedaan en leverde aantrekkelijke discussie op, maar ik kreeg het idee dat de organisatie er teveel moeite in had gestopt: de rest van het programma draaide keurig op tijd, maar dit stuk liep opeens ruim een half uur uit. Hier mocht alles voor wijken. Op zich leuk, maar ik had graag nog iemand bij de borrel gesproken (wat nu moest wijken voor een trein terug naar moeders de vrouw en de kinderen). Het spreekt voor de organisatie van dit congres dat dit het enige minpuntje was :-)

De kern van het uur van de waarheid was de discussie met de drie aanwezige "grijze koppen". Nico de Vries van BAM civiel voor de aannemerij, Leendert Bouter van de Bouwdienst/RWS voor de overheid en Bertrand van Ee van DHV voor de ingenieursbureau's.

(Opmerking 1.: Ze zaten er op eigen titel, niet officieel "namens de overheid" of "namens de aannemers", zoals Leendert later terecht zei.) (Opmerking 2: de onderlinge discussie was steeds "Nico" en "Bertrand", vragenstellers uit de zaal hadden het later vaak over "meneer De Vries"... Ergens grappig dat je je daar even over achter de oren krabt. Ik hou het hier op de voornamen, zo had ik m'n aantekeningen gemaakt.)

Nico: We innoveren best wel wat. Grotendeels automatische bouw van de Westerscheldetunnel enzo. Wat verbetert moet worden is samenwerken. Topprioriteit is het sturen op output. Leg de verantwoordelijkheid bij de partij die het integraal kan aanpakken. Hij (aannemer) wil professioneel opdrachtgeverschap.

Leendert: De overheid heeft een flinke deuk in z'n vertrouwen in de bouwindustrie opgelopen. Dat kan ook niet in 1 klap hersteld worden. Het geeft wel ruimte voor innovatie in de relatie.

Betrand: Meer doen met minder regels: nodig voor samenwerking met overheid en aannemers. Zijn inspiratie is mooie dingen bouwen. 't Blijft een ingenieur!

Vraag: hoe kan je zorgen voor vertrouwen bij de opdrachtgevers die een deel van het ontwerpwerk (wat traditioneel "hun" ontwerpwerk was) aan de aannemers moeten overlaten?

Nico (aannemer): altijd goed je werk doen en erover nadenken. Ook zoeken waar het wel en waar het niet werkt.

Leendert (bouwdienst): dit is lastig voor rijkswaterstaat, we "maken" sinds 200 jaar alles zelf; dat is lastig af te leren.

Bertrand (ir-bureau): niet te hard op je kennis gaan zitten, deel je kennis.

Bertrand op andere vraag: je kan niet alles van tevoren weten en dichttimmeren. Weet wat je niet weet.

Vraag: we zijn als bouw niet goed in staat om om te gaan met goede ideeën. Een ingenieursbureau wil uurtjes schrijven, de overheid wil intellectueel eigendom inpikken en aannemers kunnen het niet beoordelen.

Bertrand bracht er tegenin dat er juist wel veel innovatie is.

Leendert: Nederland is al 400 jaar innovatieland, we pronken er alleen niet mee. Frankrijk pronkt wel, maar Nederland doet meer.

Vooral richting het eind kreeg ik het idee dat het ge-wijs "het probleem ligt bij de ander" toch aardig de kop opstak. Aannemers willen professioneel opdrachtgeverschap. De overheid wil omgekeerd weer vertrouwen in aannemers kunnen hebben. De "jonge honden" willen dat de "grijze koppen" wat doen. (Ok, sommigen vroegen om steun voor expliciete initiatieven - wat ook gegeven werd - maar er was ook "ongericht geschop"). Je komt er ook niet 1-2-3 uit op zo'n dag en dat geeft ook niets. Zelf lijkt het me belangrijk de praatjes van Paul Spierings en Mark van Twist in gedachte te houden.

Found the link on slashdot: the US army made their heavyweight BRL-CAD available as open source, for an idea of the possibilities, see this screenshot .

BRL-CAD is a CSG (constructive solid geometry) package, as they really wanted to work with solids: so that they could model penetration of ballistic objects into tanks and so...

What I'm totally not in a position to judge: could this be used for IFC ("information for construction", an building/construction/architecture building model standard with a big CAD background)?

Check out their logo :-)

Ben Hyde has a nice thing to say about committee-developed ontologies versus massively volunteer-developed folksonomies.

Folksonomies is a pretty new term for stuff like del.icio.us, where everybody can tag all sorts of information with tags of their own devising. Yeah, that's chaos - but pretty chaos. I watch what people add to the tag startup and despite the occasional page about starting MS windows, I've gleaned a couple of useful pages for starting up a company from there.

Chaos! Nobody in control! This can't be right!

Ben is right: Folksonomies - nobody in control? What! that's silly, the site designers are in control. If the ontologists wish to remain in control they had best start building sites, and fast.

I'm working in the building and construction industry: there are a couple of committee-based ontology efforts there. Any extra project won't add anything major. So: add a folksonomy-like project! Let the committee try to keep up with the unwashed masses. (Or laugh at the stinking pool of utter chaos in which the masses slowly drown themselves :-) Note: the bcoWeb building-construction ontology we've started at Delft University of Technology is intended for the unwashed masses.

I've attached part of chapter four of my upcoming PhD thesis ("New instruments for dynamic Building-Construction"). The part about "lightweight development" is the most relevant here. Development and open source

The key question then seems to be: how to develop a standard that is semantically rich, can be useful and even commercial attractive within a short period of time (less than one year) and allows the owners of the information and knowledge to keep control and ownership.

The suggestion put forward in this research is fourfold. The cost for use should be minimal; there should be as much application support as possible; development should be lightweight; the development should be supply/demand-oriented.

Low cost of use

All other things being equal, a lower price increases demand. The suggestion for this concept solution is to make the usage free of charge. Free of charge does not equate to low quality, as is exemplified by the free, online encyclopedia wikipedia .

Much application support

Application support will depend on individual economic decisions on the part of the software vendors. What can be done, though, is to do away with all barriers for the software vendors. So: no mandatory membership of an organisation, no fees payable before you're allowed to access the object library, no risk by tying yourself to one platform vendor. This all can be achieved by making the object library open source. This makes the object library free in the sense of `gratis' and free in the sense of freedom to use, freedom to change, freedom to redistribute. One restriction that might be a good idea is to demand that the redistributed or changed object library contents be freely available under the same conditions, this as a safeguard against an embrace-and-extend attack by one market party. A different position is possible on this point, though.

Lightweight development

Heavyweight committee-based development is slow. Some of this work is rightfully hard and should take a long time. The solution concept, though, suggests to develop the object library as multiple small pieces that can be made by just a few interested individuals, without having to resort to formal organisations and meetings. The next generation internet possibilities allow you to tie the various independently developed parts together in a web-based network.

Supply/demand oriented

To achieve immediate relevance and interest in the building and construction industry, a new development has to attach itself directly to the money-making process. If an ontology can be build on basis of a supply/demand distinction, it can start lubricating the market mechanism in the building and construction industry. At the least it can provide a few innovating new ways to connect supply and demand.

Concluding, the proposal is for an open source web-based object library as a very interesting new effort at creating a useful basis for web-based communication in the Building-Construction.

Martin Fowler has a worthwile short piece about using analogies with other professions. The software industry is often compared to the construction industry. (Which I, as programming civil engineer, find funny, by the way, as the construction industry is just as bad on some points).

His advise: Comparing to another activity is useful if it helps you formulate questions, it's dangerous when you use it to justify answers.

Good point.

Noor Hellemans finishes her MSc graduation tomorrow. Since she doesn't have her own website, I'm putting her thesis online here.

Warning, it's written in Dutch. But that means that it's a good introduction for the Dutch construction industry on the work we did regarding bcoWeb

Bedankt, Noor! Lekker leesbaar verslag en veel werk verzet voor de bcoWeb objectenbibliotheek.

2005's w78 conference will be held in Dresden in july. They just put the conference website online. Normally it are friendly conferences with a lot of interesting Building-Construction related ICT and product modeling research. Lots of PhDs, always. Recommended.

To get a taste of the kind of papers and presentations you'll get you can visit the collection of conference notes I've got online here, there are two w78 ones in there (2003 and 2004).

I'd like to attend, it would be an ideal place to present my final PhD results (as I hope to finish in april). It's just that I don't know my job situation then. Dresden 's not too far out, though, so I'll most probably hop over to attend.

(If interested: my current job ideas )

I've collected pointers to all the LexiCon-related information that's stashed away somewhere on this website. From now on there's a overview page summing it all up.

Phil Windley says it's all about integration, with a point that's good to keep in mind:

Companies like the one I was talking to need to pay attention to just two things (at least on the technology side): (a) their core competency and (b) great integration points that are based on standards and easy to use. Otherwise, rather than selling your product's features, you'll constantly find yourself justifying its deficiencies.

Looking at building and construction ict, this point emphasises the need for integration possibilities. If your core competence is cost estimation, what is the integration point you can use? 2D drawings: no. Text-based specifications: no. In-company pricelists in some in-company database format: no. Ouch.

There are some efforts, though. The idea of a building information model for instance. Storing all/most/a_lot information for a building project in one big model/database. See the latest AECbytes newsletter for some more info. IFC is a standard that's getting pretty much all the attention in that area. However, I'm missing something there.

What I am missing is that it sounds so much like "big database" instead of "integration point". Let's say my core competence is, how can I get the data I need to work on out of that building information model? Probably by residing on the same computer as where that model is, calling an API. What if I'm a web-based costing application? Can I get at the data then? Why isn't there a great integration point I can access? Something like a web-based application I can query and that gives me back standard-based IFCxml files?

The other side of the coin: there are probably decent standard file formats for costing applications. So, I need to make my information available in that format in an easy-to-get-to manner. Did I mention the internet yet?

Personally, I'm experimenting with this at the moment. Tying together the object library at objects.bcxml.net and some client-oriented applications (acatalog, a simple specification, a project description, that sort of stuff). Back to programming.

I've written two times on a comparison between the construction industry and the software industry: Construction industry not so bad? and Software industry vs. construction industry, this will be the third time.

If you're interested in contracts, read scope limbering about "fixed price, fixed scope" contracts, by Martin Fowler. In his case in the software industry, but the same is true on the construction side. Read the following quote and you could use it for both industries:

A tripling of actuals over initial estimates isn't unusual in our industry. Mostly I believe this isn't because we are so bad at estimating (although we aren't exactly stellar at it), but it's mainly because it's so hard to get a decent set of requirements. Many delivery companies take advantage of that by low-balling the initial bid and making profit on scope changes. But this approach sours the ongoing relationship with the client - which leads to the whole industry gaining a bad reputation.

Today I got an email by Celson Lima about Funsiec (see also two previous postings). They have collected information on a couple of existing semantic resources. "Semantic resources" is their term for ontologies, taxonomies, etcetera. A term designed to be less fear-inspiring and difficult-sounding. I'm slowly getting used to the term and might even come to like it. For the moment I'll stick to ontology .

Their new semantic experience centre lists the ontologies, taxonomies and classifications that they found. You can test out three of them, look for the "play with semantic resources" link. Only problem: two out of the three examples need you to login, but they don't provide a test user to login with. I've send them a mail about it, though.

Jasper Feenstra is a graduate student at Twente University in the Netherlands, graduating on the subject of the marketability of the LexiCon as made by STABU . Yesterday he organised an interesting expert panel to discuss some theses he cooked up. As it provides a good view on the current status of the LexiCon, I'm including this summary here for the benefit of others in building&construction ict research.

The people present were Maarten van Hezik, Johan Veenbaas and Dirk Teitsma from STABU, Kees Woestenenk (creator of the LexiCon), Sieger Looijenga from forum systeemhuizen (a Dutch association of software vendors for the construction industry), Peter Bonsma from TNO bouw and myself, Reinout van Rees.

Note that this is not a full transcript, it's my summary. So any errors are mine :-) Thesis one

When asking around, the industry says they want new stuff to connect to their current way of working. Thesis one is: First make something new; adapt it to the current way of working afterwards.

Maarten agreed with the thesis. If you adapt to the current way of working from the start you'll have a very slow progress. Siebe added that the LexiCon is something that is not restricted to one single part of the construction process. Every part of the process has to be supported before it really works. This is a typical chicken/egg problem. So you need a separate standard that's fixed, followed by the roll-out of that standard coupled with a convincing of the market. For this to happen, you have to be able to earn money when you start working with this.

Dirk thinks the standard has to be developed separately, this gives you the most "clean" results.

Reinout proposed to first try it out in the low end of the market, starting of with something simple and internet-based. That 'd give you a good starting point that, if succesful, could give you the monetary means to develop the standard further. This was deemed an altogether different thesis, so we didn't get into it any further.

Peter didn't agree with the thesis. You work in a context and you need to take that into account a lot.

Siebe provided an example of a succesful standard: their CUF calculation exchange format. They made it public domain last year. They intended it for a "horizontal" usage, as an exchange mechanism between calculation applications, but it is now also used a lot for "vertical" applications. Spontaneously.

Kees agreed with the thesis, provided you take care of a migration path.

Siebe stressed that it was important to say what the LexiCon really is. If it is a pure technical exchange standard, then it is something that can be hidden under the hood of the various applications. You're not bothered by it in that way: you don't have any "standard-means-change fear".

Thesis two

"STABU shouldn't focus on specific phases and sub-markets, but on the part of the information that is common."

Maarten stressed that the LexiCon isn't a pure STABU business. It goes beyond STABU's goal. STABU is the initiator and current maintainer of the LexiCon, but they definitively want it to be more generic and want other parties to be involved.

Reinout wanted to know if Jasper meant "object definitions" when he said "information"? Yes. Kees added the specification part as being really important.

After a bit of discussion, it seemed like most wanted the LexiCon to include a complete "superset" of all information, instead of a more compact "subset" with only the common information from the various phases etc.

Thesis three

Jasper: when you ask around for the desired properties of a new application, the answer you get most from the construction companies is "it must do the same as the ones we have now, only better". So the third thesis is "developing the lexicon means you have to cooperate with the software vendors that are making the current applications".

Maarten found cooperation to be self-evident, that was why STABU started the BAS foundation (Dutch link) for the LexiCon and why they invited everyone that had anything to do with it to join. Everyone within BAS accepts the LexiCon and the upcoming iso-12006-3 standard.

When you look at financing, Maarten mentioned a couple of problems. The ministry of economic affairs doesn't provide subsidies for foundations, but the construction industry grouped most of it's research into foundations... Another big subsidising entity, the PSIB project, explicitly said they weren't going to fund standards... And there are also no dominant software vendors that can pull off the development of a standard like the LexiCon on their own. The few that tried are licking their wounds at the moment.

Kees: the LexiCon is a library-support, it is a basis upon which you can build libraries. On the LexiCon basis, software vendors could make their own libraries. That basis immediately give you a basis for information exchange.

Thesis four

"The construction industry is conservative, so the lexiCon will only be accepted if it is made mandatory by the government or a powerful client."

Maarten didn't agree with the basic conservatism in the construction industry. When they see a direct profit into something, it only takes three months before everybody does it. Faxes, mobile phones, they all spread like wildfire. "Where do I sign? Can I have it yesterday?"

Siebe: They're doing an test with electonic procurement for building materials. If you order your materials electronically you get another 1% rebate on top of the rest of the rebates you might have. And they give you some subsidy to boot. And install the software on-site. And provide one-on-one training. And still you almost have to drag them over to do it...

After some more discussion, a partial conclusion was that it helps to have it made mandatory (of course), but only if you have a readily filled library and applications that actually work with it.

(Maarten had to go at this point, btw).

Thesis five

"Having ICT pushed through the door by means of law doesn't work, but clients making it mandatory does."

Siebe: There are all sorts of law-inforced financial rules. That makes creating software pretty easy.

The generic agreement was that it works if clients make some ICT development mandatory (it worked with the current STABU specification system, after all). It also enlarges the scale.

Reinout remarked that this sounds terribly defeatist. The technology doesn't seem good enough or attractive enough to do it under its own steam this way. Siebe agreed.

Kees said that first the object library needs to be filled to 80%.

To Reinout, this sounded like you first need some 80% content in the object libary. Next you need some 80% of the applications to support it... Next you need... That is hard. Siebe agreed again.

(Remark afterwards while writing this down: why do I think this is so hard? Well, see it not as completion percentages, but calculate with the chance that you get it to work. If you need 80% completeness, what is the chance you get that? Say 70%. Then you need to convince 80% of the software vendors. Another 70%. That's just 49% total chance when multiplied. I do not like this kind of calculation. A lot of succesful technologies have hit the 80/20 point, where with 20% of content they provided already 80% of the functionality. Hard to do, too, but in my opinion a safer bet. Just my comments).

Thesis six

"STABU is a foundation. creating your own software is difficult as a foundation is percieved to by a bit stuffy".

Reinout thought it no problem at all to build software as a foundation, it might even be a good idea.

Kees didn't want all LexiCon-powered software to be build by STABU. You're not going to build a new CAD package! Perhaps just the LexiCon management application.

Peter would look at some supporting (probably free) software.

Siebe: "Forum systeemhuizen" was started because STABU threathened to build their own software. Thrown in as a historical perspective :-) If a standard is good, it will be used.

Reinout floated the idea of open source software to nail down the standard.

Kees didn't see much difference between open source software and a closed source API you can get gratis. You need a exchange format, though.

Kees and Peter both advertised IFC, mainly to Siebe, as being a very good data standard. Siebe replied that that was more something used by the top 1% of the construction companies. They have their own solutions, Siebe and the other software vendors are delivering to the other 99% percent of the market...

Thesis seven

"Construction companies are not aimed at innovation, software vendors are. So the LexiCon marketing should be aimed at the software vendors"

Siebe: with the Visi project (Dutch link) there are software vendors external to the project that deliver solutions, so if there's something good, they'll come.

Reinout asked Siebe whether anyone actually tried building software for the LexiCon. Siebe answered that they for years had reserved money for test implementations, but the LexiCon took too long to deliver something implementable, so they had to spend the money on something else. There wasn't enough content. (So: no implementations).

Reinout supported the thesis: the LexiCon is a platform, not an application, so it has to be an attractive platform for software vendors to build their applications upon. Siebe mentioned Microsoft's developers' toolbox as a shining example

Reinout to Siebe: what's needed in addition to a reasonably complete content when looking at adoption by the software vendors? Siebe:

• An exchange format (handy if STABU specifies it themselves). In XML. Preferably with a stylesheet so that you can show it directly in word or IE.
• Good electronic documentation. Preferably documentation that you can pass on to your clients.

Siebe also advertised the loading of external information (like that inside the LexiCon) via the Internet. Otherwise the data files you have to bundle with your application are so huge. He mentioned the Visi project as a good example.

Reinout wanted to know whether internet access was common right now. Siebe replied that most companies have it right now. There are only a few companies which restrict access to only one PC in some corner

That concluded the two-hour session.

Local LexiCon information overview page

Hmmm. I'm actually a bit in doubt where to post this. I've added some news items to object.bmxl.net itself, but I'm the only one reading that, probably. So I'm taking the risk of scaring everybody away by posting it here. Python/plone programmers will find some code near the end :-)

objects.bcxml.net is a experimental site where a graduate student (Noor Hellemans), my professor (Frits Tolman) and myself are creating an functional_unit/technical_solution-based ontology, FU (functional unit) meaning objects on the demand side ("you want something functional, with functional requirements") and TS (technical solution) meaning objects on the supply side (a real, technical solution for your functional demand). A FU can be fulfilled my multiple TS, a TS consists of a couple of follow-up FU details. And so on. It's a pretty easy and elegant system when you think about it for a while.

Ok, now the news :-) I've made some improvements last evening/this night.

• Couple of visual improvements, like displaying identifying icons in front of items (question mark for FU, exclamation mark for TS, etc.).
• I added a detection mechanism for duplicate objects, with the possibility to merge them.
• I added "collections", just a grouping mechanism for (demand-side) functional units. You might call it a power type, but that is something I'm intending to write about a bit later as I'm still trying to get my head around it. Effectively, when you're busy adding FU/TS, there are some things that are neither. When those things are more like a collection of FUs than FUs themselves, now you've got a place to put them.
• Silly-sounding, but listings of folder contents is now alphabetical...

Read on for a couple of pieces of python/plone code. Sorting folder listings in plone 2.0

After a bit of googling I went to /portal_skins/plone_scripts/batchedFolderContents and customised that. I added the following after the first try..except clause:

  contents.sort(lambda a,b: cmp(a.Title().lower(), b.Title().lower()))

Adding objects programmatically

I'm adding some objects to plone from my program code instead of using the normal plone web interface. What bit me there was that those objects didn't get included in the catalog. Which meant that you couldn't search for them, etc. So if you're doing something similar: don't forget to call something like this:

  object.indexObject()

Content type icons

When you're using archetypes' reference mechanism, the newest versions constantly put icons in front of your objects. I mean, on this weblog external links have a globe icon in front of them; that globe is a link's content type icon. I kinda like that behaviour, so I've sprinkled code like the following throughout my page templates:

  {a href="#" 
     tal:attributes="href some_object/absolute_url"
     }{img tal:attributes="src some_object/getIcon"/}
     {span tal:content="some_object/title"/}
  {/a}
  {span tal:condition="some_object/description"}
    ({span tal:content="some_object/description"/})
  {/span}

Note that I've replaced the html angle backets with braces as I had some cut/paste problems.

Well, in my ongoing search for building and construction weblogs, I've found two sites that not really fit the bill (as they have no rss-feed), they are email lists. Trusty bloglines allows me to generate emailadresses that allow me to receive those emaillist messages in my rss reader, so I don't mind that much.

• The first is AECbytes, found through the ConstrucTIC weblog, thanks guys. It is written by USA-based Indian PhD Lachmi Khemlani. As an example, check out her not-too-long introduction to the IFC model which I'm tempted to use as my generic link to IFC when I'm using the term.
• Second is Jerry Laiserin's LaiserinLetter, I found him because one of his newsletters showed up in a google query for ecppm. He showed up at the recent ecppm 2004 conference alright, as I quoted a question of him at the end of thursday's notes, so I know :-) Didn't get around to talk with him, though.

On 17 april I talked about the internet operating system for the building industry, I'd like to follow up with a posting by Adam Bosworth

The platform of this decade isn't going to be around controlling hardware resources and rich UI. Nor do I think you're going to be able to charge for the platform per se. Instead, it is going to be around access to community, collaboration, and content.

My vision for the building and construction industry is that a platform like this emerges. That it will be possible to collaborate because you have access to content: specification text, drawings, regulations. In human- and in computer-readable form. Internet-accessible.

And community? Well, there is a place for company secrets, of course. But if your competitors cannot access any of your information, neither can your customers. At least not in a generic internet-like sense. Example? I dislike having my ecppm papers locked away in a not-widely-distributed book with my copyright signed away and not a google-findable copy anywhere on the internet. I might just as well have thrown it away. Perhaps a bit harsh, but still. I'm much more appreciative of the w78 series of conferences: they put the whole lot online

.... this will, by definition, be an open platform because the main value it has is in delivering information and communication. Notice that the big players, Amazon, eBay, and Google have already opened up their information through Web API's. It is Open Data coupled with Open Communication built on top of Open Source that will drive the future, ...

No, no, no. The kind of internet-based collaboration and communication and community platform will be very open. There won't be an individual commercial entity to control it all by itself. It will probably level the playing field a bit.

Leveling the playing field? Yes. Just take a look at current construction IT research. I get the impression that a lot of the tools coming out of the research are building on top of existing big expensive programs. IFC lowers the playing field already a bit, as you can load IFC files to play with, instead of writing extension modules for archicad. Working with specification systems normally requires you to have a license, this limits the demo-possibilities as you can't re-distribute your tool. And about data: how many IFC files of real projects are available online? What if you could download 500 IFC files as a researcher in order to map out the usage of various object classes?

At the moment it's not normal to hook research results up to the internet. Where is that fire exit calculation tool I saw two years ago? Might be handy if there would be a web service interface for it ("web service" as "http+xml" not "soap", you heathen!). Wouldn't it be great if there was a platform to hook these tools up to?