One Modeler to Rule Them All

Strange thought - is it possible to have one modular modelling application, that is streamlined for basic users, and modular, web-based variations for different trades? 

Thinking about this, when I am working in an architectural application, I am just layering a level of attributes around my geometry to define how it should behave and schedule. If I am doing product design, similarily I can tag my geometry for material definitions, strengths, etc. If I am engineering for fabrication, I want to be able to plug my analytics into the geometry definitions. If I am just modeling for rendering or 3D printing, I am just streamlining to material properties and parametrics.

If I am hitting an online model, could this not entail a similar d/base back-end, but the flexible front-end based upon the tasks needed? Equally perplexing, but could the export flow be similar, and get us to a world where we do not need to worry about file translations but a universal, open source (real open source, not this IFC crap) format that is designed around flexibility and power processing, or even moving away from total file migration into file captures that can be pulled into various applications?

Hmmm......

Tap the Data Stream

Ok, this whole database dilly-o is interesting. Thinking about the amount of product material that is incorporated, including quantities, manufacturer, spec information, etc., you have to wonder how this information cannot be tapped,  similarily to what Google is doing with Google Docs and Gmail?

Look at the comparisons:

1. Marketing Information - Every piece of equipment, finish, manufacturer will eventually, if not already, be specified in the model, and therefore in the database. Market usage, advance information, and advertising for new, relative products could be pushed exactly as Gmail is scanning and tracking our emails.
2. Specifications Attributing - Specifications are a pain in the ass. This information, however, could reside and be searched the same as Google Scholar or any of the other online, spidered indexes, and automatically be streamed into the database. Revenue could be generated from product suppliers enlisting into this service.
3. New Product Information - We currently wait for the major conferences or search through outdated architectural publications to find out about new products? Why can't their advertising dollars go directly to the company hosting and streaming our model, along with the model families for their new launches, and we can always stay up to date with the newest or most used/popular products??
4. Construction Tracking - Metrics on quantity, location, typologies, etc. for new and upcoming construction could be captured and sold. Real-time updates on new construction can be sourced to Google Earth and Google maps, supplementing satellite data w/more current information.
5. Web-Based Tools (the Gateway Drug!) - If my model is being hosted through Google, and my 100 person + team is using a Google tool, it would introduce me into the rest of the Google suite of products. Spreadsheets, Word docs, email, presentations, calendars? My IT department would need to come to terms with the externally hosted environment, and once that boundary is overcome these tools could become more legitimate, and migrate us from a Microsoft, firewalled world. It would also give Sketchup some street cred in an architect's world, word up.

Ok, now that I've vented this, time for some bbq with the family. Happy 2009!

Lessons Learned

Happy Holidays! This time of reflection (aka a vacation!) and I've had a chance to absorb the lessons and observations of a project team migrating from a traditional, multi-model environment over to a more centralized, 'single' database model environment over a full design phase. Now, take into account that this is for a 500K SF healthcare project, and that brings additional insight:

• Teamwork - This is a massive cultural transformation for any team - learning that anything you do within a model and how it overlaps with a half dozen other team members, and the learned communication is difficult to train. Overlay this with the traditional bell curve of varied skillsets and technical acclimation, and it becomes something that your BIM leads will need to focus on as a top priority.
• Component Development - Outsourcing is a good thing. 400+ medical equipment families that want to be developed as early as possible, plus casework, furniture, annotation, etc. is a huge volume of work that if you can offload it from your team, you will save a fair amount of additional work. Managing this resource library is a topic for a future rant... ;)
• Network - Current file management in the existing BIM apps is pretty sucky (technical term, involving a vacuum-like sound). To their credit, they are not networking companies, and to expect them to handle this much data to 20-40+ users at this point is probably pushing reality (sorry guys!).  
• Generation Gap - He who holds the pen controls the outcomes. Unfortunately, your users that are not in the model become increasingly separated from the content and output of the model/drawings/design/decision-making. Learning how to incorporate and educate these users on the processes and what the expectations of all team-members are will make your life much, much easier. Also, making sure they understand that Autocad methodologies are not the ultimate answer to architectural design and production is essential.
• Technical Balance - BIM requires that your team knows how to put a building together, not just 'draft'. Having the right balance of technical expertise, both in and out of the model, will produce a better entry point and model status before entering CD's.
• Sub-Contractors - A solid selection of design assist partners and engagement of them early in the process, and not just in an advisory but in a model-development role, will only help. They are worth their weight in pulling down costs and improving documentation/construction.
• Engineers - a) Get them on the same software platform, if possible. You will piss through file translation costs like nobody's business otherwise. b) Make sure they are producing models, and early. We don't work in a 2D world, everything has an X, Y, and Z dimension, and without their models you are leaving serious coordination and decision-making in shops or, worse, to be found in the field. $$$, enough said.
• Put your PA's to work - BIM enables your Project Architects to get to work early, establishing drawing standards, systematic design, and other projectwide standards as soon as you start the model. Nothing is wasted, and these standards can evolve as the project moves forward, but a good foundation is worth its weight by the time you hit construction documents.
• Communicate, communicate, communicate. Refer to my last post :)

As we move into the next phase, we will be looking at tighter construction integration, fast and heavy documentation, and probably a new batch of challenges. Stay tuned!