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".
"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.
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.
"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).
"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).
"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...
"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:
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.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):
