I believe one needs to ask some deep "why" questions which will lay down the objectives of open source BIM. I subscribe to the thought explained by Simon Sinek in a TED presentation: http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
A lot of useful innovations have happened because leaders asked and answered the question "Why" first before answering questions such as "How" and "What"(Simon Sinek explains not only in the context of business but also in social movements, such as Martin Luther King's points...)
So first of all, I recommend we really get into the question "Why". This article is based on some discussions that is happening currently in a Google group in India, exploring open-source BIM.
Why do we need Building Information Modelers and why is it important to think of it once again ... not just take off from what is currently existing. (To be graceful to what is existing: We could do our exercise and later on realize that current standards are useful, but we need to carefully tick-off on each of the following points before doing that)
1. Because we need to support the entire spectrum from concept formation all the way to construction
Designing is a spectrum. It starts hazily from an architect's mind and proceeds towards final, crisp stage. Ideally, BIM should cover the entire spectrum. There has been some attempt from the West to computerize early stage designing. (e.g. SEED ) but those did not take off. Currently, it is taken as granted that BIM is done towards the final stage.
No doubt, there are companies that have tried to use BIM in earlier stages too ... and some commercial organizations confuse us further by claiming that things like massing, etc. can also be done using BIM for helping in the early stages. But the theories behind that approach need to be investigated. What we must realize is that information management is necessary at all stages of designing and all the way into construction. It is not just help in "visualizations of massing"
Earlier the information is handled; better it would be for design. Currently, it is assumed that all the messy, hazy stuff that happens during the initial design stage is best done by architects using their favorite methods ... and later it can be transferred to computers. One of the prime reasons why many architects ( especially experienced ones) do not take to computerization and BIM is because they see a disconnect between the early stage and the final stages of design. Currently the situation is: Early stage = NO computerization. Final stage = Computerization. Ideally, what I have been striving towards for last 20+ years is to look for computerization as a help, not just a thing to be used entirely, who can sit side-by-side with an architect and later on engineers and other consultants EVERY STEP OF THE WAY.
2. Because we need to record design intention, not just the design
Many think of architecture as the way it is finally seen out in the real world. That is just the tip of the ice-berg. But beneath the surface, there has been a lot of decisions that went to make the building what it is. What is also needed is to record all the intent, nebulous qualitative attributes, decisions that were forced due to management practices, etc. The reason this is important because architecture can be put to many unusual uses and situations. A building may get converted later on its lifetime. A warehouse can become a clubhouse. An award winning building may later on be found to have very serious problems later on and when the problems surfaced, there would be serious people wanting to investigate what went wrong so that the same causes do not surface in other buildings.
The most dramatic example of such a situation was what happened before the collapse of the World Trade Towers. The context was never experienced before, and so nobody could really predict how the buiding would perform in that crisis. Sadly, this was the SECOND project of the same architect which had seen dramatic failure. The first one, the Pruitt-Igoe housing complex, was equally dramatic but it was demolished not by terrorist attack but by the state who found that the award winning project of that architect was almost completely useless. Finally it was dynamited. As per Charles Jencks, architecture historian, it marked the day when "modern architecture died". Pruitt-Igoe is a famous study that is spoken among architecture researchers but not much outside. http://en.wikipedia.org/wiki/Pruitt%E2%80%93Igoe
This issue can be seen in earthquake relief, emergency situations, fires, etc. Sometimes one may need to model movement of people through the building. There has been many cases where people move en-masse towards the wrong exit in case of a fire. Recording design intentions can be very useful in such a case, because one can assess what kind of management directives and steps should be supported and what should not be. For e.g. An irritating client could insist on closing a window opening (it has happened with me) and later on it was found that for the lack of that window, the apartment did not perform correctly climatalogically
3. Because we need to save time
Saving time happens on multiple levels. One is saving the mechanical drudgery of making drawings, models, printing etc. That gets saved when there is a single BIM model to refer to. But more subtle is the saving of time when the management of the design process is properly supported. To give an analogy: Calculators did save time for calculations, but when the financial planner got a spreadsheet, he did not get just some calculator with additional capabilities but it opened up a lot of "what-if" calculations that the planner could now do and then use those creatively. Much, much more time gets saved. The approach to BIM therefore should NOT be just "okay, we need to have a very good way to put all the geometric information together, holistically" Yes, that is one goal. That has been somewhat achieved by current BIM but that is not sufficient
4. Because we need to respect the end user as contributors to the model
As per Stephen Covey: "Problems are solved twice. Once in the mind and once in the real world" Modeling is NOT the whole sole property of people like me and others developing BIM, the people who make the proposal. But a model should ideally be open to receiving inputs, sometimes even at the last moment, from the actual user. This trend can be seen in many other data standards too. For example; when Tim Berners Lee proposed the HTML standard it was a "hand-me-down" set of data constructs that the end user had no choice but to use. But that approach is changing. Today, HTML 5, XML allow for new elements to be inserted by the user as he deemed fit, that follows meta-rules.
If you look at BIM standards carefully, you will notice that much of it is still archaic data-structure approaches of yesteryear. (I can give references and my insights in this later) I suspect, much of the current BIM standard has been manipulated so that the commercial organizations that helped create them could ensure that their own proprietary software continue to get traction
5. Because we should respect the D-R-Y principle
DRY = "Don't Repeat Yourself" is a well established concept in computing. Any form of redundancy that comes into data structures can wreak havoc. DRY was a term I think invented by the Ruby-on-rails people which essentially mean the same thing. However what is "repetition"? There are obvious ones and unobvious ones. But opinions vary which is which. A piece of data which is repeated to me; to someone else it may look quite harmless and done just to get some specific job done and therefore can be accepted. For e.g. Using construction lines to draw other elements is a known practice among draftspersons. Often the construction lines are left behind quite harmlessly. It may be okay when we speak about drawings but when it comes to modeling, if some object was created only for creating some other objects (say a CSG model) and then if that is left behind it can confuse others using the data.
In architecture models, there is one major issues that many BIM and CAD programs do not think is very critical: That is repetition of "spatial volumes" For e.g. If I draw 4 walls that enclose a room to the visual eye, there is a space that is enclosed but then it is not measurable as the data-structure cannnot glean that out. So people are instructed to happily insert another volume that denotes the space -- and architects do that without knowing the implication --- that is very subtle redundancy there and that can lead to, and often does, very serious problems during automated objective analysis of the data. For e.g. If the data is to be queried for the area of the room inside, it may initially give the right figure ... but when, during some modifications, the walls are moved around (which also should imply that the object denoting the space of the room should also be modifed- -- but many time it may not get modified due to oversight) then we have a very serious problem because the room will still reveal the old area and not the new one after the walls were shifted
6. Because we should also respect all kinds of design processes and thinking
When designing, an architect often starts delineating the spaces in the early stage of design. Usually. But not always. For e.g. as an architect I often work in that way. But there are architects who may work on the built-forms earlier... or it could be a mix. Even with spaces, there is no really rigid rule which kind of space need to be represented first. I had adopted an unusual approach for a hill-resort I was designing in Munnar, Kerala in India. When I went to the site, I first located the various views that I wanted to capture -- so effectively, I was first working out the potential locations for the window openings rather than the rooms to which those openings would go. I had to have a modeling system that allowed me that -- lots of windows hanging around inside my early model; without knowing which rooms those windows would eventually belong to. Later on, when I figured out what are the rooms that resort needed, I arranged the rooms to take advantage of the previously located windows.'
Current BIM standards are extremely rigid on the way data is arranged. For e.g. In most BIM, I doubt whether one could create an opening without first creating the wall into which the opening is placed. That approach looks logical. People sometimes wonder, how can one construct an opening if there was no wall around it? That is right when construction is concerned; but when an architect wants to start thinking about a design he may want to first think of the openings and then the walls.
There is a much-bandied term called "ill-formed" objects in CAD and BIM (objects that geometrically could be constructed on the screen but cannot exist in the real world) There have been data-structure approaches such as the "split-edge" data structure proposed by Yehuda Kalay and others from Berkeley which tries to put all the data in a non-redundant manner into the computer. But then I found it too rigid and not respecting the need for architects to sometimes think non-linearly, or out of sequence. That is why I find that current BIM is more construction oriented instead of design oriented
7. Because we need to incorporate concepts that have found to work in other areas such as management, computer programming etc
Today, the "agile" process of software development is very well known and respected. Many programs are designed using those principles. I believe that approach (i.e. the spiral-development approach using Agile) is very useful in designing and the data standards should help achieve that. In an agile process, the design is quickly developed, criticized, tested and then dismantled if so required, so that the next design cycle can be quickly started. What happens in traditional CAD and BIM is that the process starts gathering a lot of complicated stuff as the representation proceeds. An architect finds it extremely difficult to dismantle something that he has modeled just so that he can re-examine the holistic again in another agile cycle. Conventional CAD/BIM is not very respectful of the agile process
Another concept that I would love to see in BIM is "just-in-time-designing" which is derived from "just-in-time manufacturing". In JIT manufacturing, there is a lot of advantages because inventory costs can be very low, and errors removed fast. Some JIT processes are now seen in computing too (JIT compilers, for example) I strongly believe that just-in-time techniques should be available to architects too : Often the decisions that go towards making a really good design come and "click" into place at the very last moment (i.e. "just-in-time") The data standard should be respecting such a need. Again, this means the data should be very light and should NOT pick up too many heaviness as the design representation progresses
