Challenges and opportunities in design technology

In the state of Kerala, at the southern tip of the sub-continent of India there exists an ancient form of martial-arts called "kalaripayattu" or kalari for short. Some even consider it as one of the oldest forms of martial-arts: As Kerala was on the trade routes with China, this martial art could have been transported across and deposited in other regions of the world in various mutated forms. One interesting aspect of this martial-arts form is the way it recognized the importance of crucial spots on the human body. They are known as 'murmas' (singular: murmum). A kalari expert can easily disable, maim or even kill a person by hitting or otherwise manipulating a murmum. Murmas can be of use too: In Ayurveda, an ancient medical practice system; again from the same region, they treat patients of some ailments using the knowledge of the location and significance of these murmas.

The crucial take-home lesson on murmas is that a complex organism such as a human being can be brought to its knees (or indeed cured of some of its ills) by clever use of these murmas. I will build an argument in my blog posts that a complex body of information could have crucial spots and/or methods that can be used to simplify it. Indeed, without such murmas it would be impossible for humans to make use of complex information. That will come later (may not be in this particular post itself).

Over the years there has been many approaches to represent complex information when solving problems. One area where this is particularly relevant for us is in architectural design representation. By architectural design I include all scale of architecture... so even product-design fits in here. When designing any kind of architecture a huge complex information body has to be modeled.

Some approaches simply start with certain axioms and therefore tend to assume certain starting points. If those assumptions themselves come into question at some point then such an approach tend to be faulty. Some generative designing systems such as shape-grammars fall into this area. Designing systems using traditional folklore or even designing using the designer's own biases fall into this area. Designs built purely on CAD models also fall into this category as in a CAD model only geometric information is captured and everything else is assumed to be elsewhere or irrelevant.

Some approaches try to grip complexity head-on and they insist on modeling everything that is out there in the real world. They don't make any assumption and if you thought something was important they would say "Go right ahead and put it into your model" As luck would have it you may end up populating your model with irrelevant information first and by the time you came to the real meaty bits; your model was so full of information clutter that the relevant gets lost in the background noise. The new crop of BIM systems fall into this area. This can be a contentious point to some because it is often believed that whatever that is the "latest" has "obviously" gone around such mundane problems. For e.g. Some could indicate that there is some technology that is available in these BIM software that would allow the sifting the wheat from the chaff.

Unfortunately if you dig deeper you will find that it is not the case. One serious indication of why this is so, can be obtained by looking at the ways by which various BIM software exchanges data with each other. After all, if a BIM software is to be built on an accurate representation of architecture; it should be logical that the software should be able to exchange its data with one another. They invented the IFC (Industry Foundation Classes) and expected all BIM software to adopt it as its core data structure. Contrary to expectations, I am yet to see any real world examples of applications that directly took IFC data without any problems and was completely agnostic to the software that generated the IFC data. One supposedly simple example on how to transfer information regarding one wall calls for all this work (click here)

I suspect part of the reason is that the commercial enterprises (Autodesk, Bentley, etc) who are behind the setting up of IFC are paradoxically also not in favour of a common standard because complete interoperability could mean loss of customers too. It is a well known practice in the CAD industry to corral customers using the data the software produces. Much of the data structures are deliberately made intractable and anyone attempting to unwrap them will get one into legal tangles. So all these exercise in interoperability is probably not going to get top level management support of these very companies developing these standards.

I have possibly digressed too much into the commercial reasons why BIM software data structures are not exactly interoperable; and why such software is unable to give what you really want when you ask for it.. Coming back to the original point; which is, is there any real technique in BIM software that simplifies architectural representations to such an extent that it will be able to separate the relevant from the irrelevant? I have yet to read any documentation that they have discovered this capability.

Till such time the design technology developers find a way to discover the murmas in the body of architectural representation which can be used to quickly fillet the complex information by us human architects; we would really be given superficial software technology tricks with no long lasting value. The downside of this is quite bad: We'll end up with a lot of data in these new formats and when we really need to plumb that data we'll find that we cannot get the information we seek.

In the lineage of various tools available to aid architects and designers go about doing their tasks; BIM is the latest area that many are talking about. The central premise of BIM which is to have one cohesive body of information to represent architecture is correct. One body of information means the potential to conduct cross-checks before the design is created is very exciting. However I feel that many of the questions that I have been asking since 1989 when I entered this field of software designing have not yet been fully answered. (Oh; by the way, I did not enter the field voluntarily; but did so kicking and screaming, as a frustrated architect who refused to be pulled into the spiel woven by poorly trained software developers, unrealistic researchers and vendors. The last 20 years of work was fascinating to say the least... and a small blog post will not be sufficient to capture what transpired)

I believe many are entering the field of BIM assuming that others (namely the BIM developers and theoreticians in BIM) have answered all the right questions. They are all excited to see what kind of checks can be carried out from BIM information. BIM is still a very nascent field and many of the theories inside this area are untested. The key one that is still unanswered is how does it really handle complex information internally? If I am able to model and check the heat loads of a one-room building; will I be able to do it as easily (and more importantly; as accurately) with a 1000 bed hospital? Who will bell this logistics cat? The answer I am often given is very naive ("Oh, just upgrade your processor and the RAM ... ") and extremely worrying.

When I entered this area, I drafted out what I assumed should be the objectives of my search for a replacement to CAD. ( I did not invent the word "BIM" but whatever it is that I invented surely fitted into that category) I noted down the following challenges for this new design tool:

A) It should help designers repeat their performance
B) It should archive information
C) It should promote accountability among designers
D) It should help others learn about a design even if the original designer was not around to explain it

Repeatability, accountability, archivability and capability of transfer of knowledge are the required attributes of any professional. I noted then (1989) and sadly even now, that we designers live in our own private islands containing our design information. Many of us do not really end up repeating the quality of design that we produce. Most don't want to be accountable and therefore are happy explaining their design using a lot of obtuse mumbo-jumbo. I am yet to see designers carefully archiving their knowledge so that design intent can be grasped by others who may be interested in their designs. Unfortunately, most software developers don't seem to start with the recognition of these objectives. I am unable to understand how any useful software can really be created if these deep core objectives are not acknowledged.

So we do have a lot of challenges indeed that need to be overcome. As the Chinese saying; every challenge is actually an opportunity in disguise. Today is as good a time as any to overcome those challenges and recognize the opportunities lurking in them. For the last twenty years, I have been nibbling at discovering data structures and algorithms that can successfully and completely overcome the logistics problem in design information. The approaches taken in my software does seem promising (of course I am biased here) but I will not say that the work is completed. There will be others who will get inspired by the story of the murmas of Kalari and develop ways to simplify (without being simplistic about it) the complex information in design.