Merry Christmas and Happy New Year

I'm off for the rest of 2011. Here's to a great 2012! Everyone stay safe and enjoy the break!

The Architect Geek

These last few years have taught me many things about the profession I have dreamed about since the 3rd grade. I have seen more massive changes (or at least, potentially massive) in the last 3 years than all of my previous 11 combined. One thing has stuck out the most in my mind, and that is, what are we turning into? The subtitle of my blog here is "BIM is changing us into something different". I really mean that. I wonder what the future holds for the hold-outs. Can those of us early adopters push hard enough without marginalizing the cause? I recently asked a question of my team to see what they thought. I have since asked the same question to those in my office who would listen.

"Is the future architect a geek?"

Not pictured: Horn-rimmed glasses, vests, or fedoras.

Not surprisingly, I didn't get an answer. It's not so easy to say yet. Will the technology one day become so easy that anyone can and will understand it? AutoCAD has been around for more than 20 years, yet companies still need support. It pains me to hear someone talk about technology like it is a burden. I realize that I may be in the minority here, but the problems posed currently by our industry are most easily solved with technology. Do you want to house your own energy modeling database internally? Can you adequately describe the best solution for your building skin without tangible metrics? Metrics give us something to prop ourselves up against when everyone wants to throw us under the bus. Using scripting languages to better optimize our design, sending a model into the cloud to render or for analysis to free up resources so we can continue to work, or simply bending a particular tool to our will is our future, isn't it?

So I ask again, does understanding those concepts make me a geek? Is the merging of IT and AE such a bad thing? Are we the future for the industry, or are we the back of house sweaty programmer types that keeps everyone's shared parameter files and Revit warnings in order? 

Please make sure you check your worksets! Gah!

Enjoy your weekend.

Vasari Love

I love Project Vasari. I love that it's free (for now). I love all what it stands for. I love what it means for designers who love technology. I am excited for the future (scripting anyone?) and the power that comes with it. My hope is that tools like Vasari become so ingrained in our design process, that we cannot image life before it.

Also, I love Monkey Island

I was toying around with Google Earth the other day and remembered something useful. You can actually download all of those wonderful models directly into Sketchup for your very own use; for free, no less! You can head right over to Google's 3D Warehouse from within Sketchup and choose your building(s) to download. Armed now with some simplistic model, the sky is the limit in terms of what I can do next.

Pro Tip: If you want faces analyzed, they have to be native Vasari; the other buildings are imports only

For starters, all of that great context our high performing buildings so desperately need are right there, perfectly scaled and located, ready for anything. The perfect integration of Vasari's Location and Google Maps & Earth make for some fantastic sun / shadow studies. Wind analysis through the spaces are also useful for figuring out where not to put the picnic tables.

Or, to analyze one's capabilities to make a Kessel Run (Thanks, David)

Ultimately, this post is just to bring to your attention some really cool, yet simple things to do with Vasari. Enjoy and remain motivated.

Family Counseling

When I open Revit files, I am usually part humored and part frustrated at the amount of 'rogue' data I find. Room Tag 2 - small 2, EQ-1234 - clay, etc. These families are frustrating usually because the intelligence exists in the the family to create new types on the fly or exist already in type catalogs, but not in the user. That's not to say they are not intelligent at all, it's really a reflection on need and comfort with the tool. In the AutoCAD days, a quick explode, edit, wblock was all you needed to accomplish the task at hand sometimes, and the 'requirement' of Revit is a bit different. Take for instance: doors.

The new Project Architect. 

Doors always seem to start simply enough; "We only have 10 types on any given project, those should be our standard" really means, "I can only think of 10 right now, but I'm sure we'll need 37 by the time we're done". This dilemma exists in most families, so replace 'door' with whatever rfa you can think of, and we're on the same page.

The problem occurs when that 11th door needs to be inserted, and the basic info known at that time is probably limited to its width and maybe some instance info like hardware (hardware is not a type parameter here). So what is a user to do other than revert and grab the 3'-0" door, edit, save as, rename, reload? That's not to say that you have to know everything about the door before you can place it. Our doors are built in such a way that all you need is to know one thing about it, then swap out for new types (from a catalog) as you discover more about it. Not everyone uses them that way; that's why I am writing this.

My door. Seriously, it does everything!

Before, all that extra data is covered in a tag sitting on a block (maybe that block even had attributes) filled out by a PA whose main job it was to manage and coordinate the drawings. Now it's embedded into the family itself and that nice door schedule that's running in the background looks all wrong, and it's Revit's fault.

The big picture is how BIM is changing us as architects into something different. DWOB (Drafting WithOut Brains) was a phrase that I heard a lot going way back into the AutcCAD days, but was more easily managed by our team leads who simply 'fixed' it in CDs. Now that management of the information starts at the beginning (honestly, where it should have been already) and our youngest architects are affecting our workflows in ways most aren't comfortable with.

My take is that, rather than preventing them, we should be enabling them. Communication and education (mentoring) is key.

Week one, down

Three articles down (2 really) and I still have a few ideas left! Thanks to all for showing any interest at all in this site. Before the weekend officially kicks off, I'd like to leave you with this question.

How can you know if your company is truly committed to change?

Split the file, are you crazy?!

I was in an interesting AU Unconference discussion regarding 'Mega-Projects' in Revit. The question started as you would think:

What makes a project MEGA?

I know what makes a man mega, though. Hint, arm canon.

The answer is not so simple. Is it square footage, file size, campus size, density, or something else? I honed in on the file size debate because this is something I have railed against for some time, that is, file size is not the best indicator for how models should be broken up. In fact, the fear of big files drives many to inflict upon themselves wounds that aren't easily rectified. Let me explain.

Years ago, in my Revit noobness, I was taught the concept of 'Lazy Parsing' (thanks Phil). It sounded like a bunch of database mumbo and jumbo, and paid it no heed. That was easy then. Revit pilot projects tended to be small, easy, and predictable so we could focus on the tool itself rather than a unique challenge of the project. As my Revit prowess grew, the concept of splitting and linking to maintain smaller files cropped up. Lazy parsing, I remembered...

Pictured: Mr. Parsing

The truth is that no matter how many times you break up a big file into multiple small files, the actual size of the Database (notice the big D) never changes, or worse, gets bigger! By that I mean, the total size of your project doesn't make it any easier on your hardware. One 400mb file or four 100mb files just means you have more files to keep track of. The Database hasn't changed, and ultimately, let's say for the sake of printing, all 400mb will be loaded into you computer's memory, and you are right where you started now with all the baggage that comes with trying to maintain multiple Revit files; a net loss in my opinion. Ever tried to tag a linked room or link an elevation view into your 'composite' file? Sure, these problems can be accounted for and solutions found, but that takes planning and care up front when file sizes aren't a concern. Gotcha!

Back to lazy parsing. The concept is simple. Revit loads what it needs to show you what you want. A 400mb file with four 100mb worksets is better than four 100mb files any day. The problem with that concept is it requires the team to take care to place things on the right workset (novel, I know) so they can be loaded/unloaded at will. Problem solved, right?

That sounds harsh; let's just say incorrect from now on.

Only through careful model management can true large file zen be attained. This coming from a guy whose last several projects were in stable single files, all north of the 500mb mark (just architecture, mind you). Sure it's work and your team has to change how they work in the file (specify worksets, anyone?), but for the greater good of the process, it can be done. I'm not for keeping all the data in one place just to say we did, however. Break files up based on the needs of the project, like separate buildings, DIs, discipline, or team location.

Just promise to not break your file up by floors.

Plan to Fail

BIM Execution Planning. Sometimes it feels a lot like BIM Execution, that is, "Death by BIM". It doesn't have to be that way, but what the BIMEP requires, more than anything, is this:

Internal, Contemplative Self-reflection (aka, what do we do and why?)

What are life safety plans?

Architecture is a nebulous of thoughts, ideas, sketches, graphics, and personality. Trying to convey exactly what we do in a single, albeit large, document is difficult. When the execution of BIM pulls back the veil on what happens behind the scenes, our first reaction is that of defense. We seize up and explain the difficulties of implementing this plan based on our our standard of care, contractual obligations, historical egotism, or flat out misunderstanding of what owners really want and how to bend our process to their will.

None of this changes the all out necessity of up front planning, however. All parties involved will benefit from some planning. The AIA has taken a good shot at standardizing Level of Detail (LOD) with their E202 document and Penn State (and others) have great guides on getting your plan, um, planned.

Right here is where we'll put the shared parameters.

Right now, owners are center stage (let's be honest with ourselves, they kind of always have been) and those owners have expectations out the wazzu. We can only effectively manage those expectations if we are armed with a solid understanding of our own 'standard of care' (as well as the requisite philosophy for that standard, ie Why don't we model floor slab openings smaller than X?). Architects that have adopted Revit to any capacity are seeing internal gains, no doubt and a full 'BIM capable' AE team is a force to be reckoned with, but, truth be told, the adoption of Revit isn't adoption of BIM. You are probably using Revit to deliver the same old paper goods with a bit more efficiency, perhaps, but that's not BIM.

BIM Execution Planning will change your process and push your comfort envelope. Fail to plan, plan to fail.

AU 2011 Recap

I've just returned from fabulous Las Vegas armed with the knowledge of my 6th AU and this year's goes down in my book as one of the best. Some great classes I want to cover here include Seven Technology Trends, Revit Graphics that POP, Mega Projects in Revit, BIM for Owners, FM BIM, and many more.

100% Revit Goodness

To kick things off right, I'd like to thank Jason Grant and David Light for getting my truly inspired with their phenomenal lecture on leveraging the most out of Revit with regard to presentation graphics Check out Jason's post here to really appreciate what he's done.