Tag: 11.2 Architect in the Community

Can CAD Be Saved? Preserving Digital Designs

by .
in: arcCA 11.2 / 1 Comment

ENIAC, the first general-purpose electronic computer, 1946 - Photography courtesy of the US Army. U.S.

is Harder Than You Think

In 1963, the very first interactive CAD software—SKETCHPAD—emerged from MIT and enthralled designers across a wide range of industries, quickly reaching architecture and now established as the default tool for modern building design. AutoCAD, Revit, Digital Project, Microstation, Rhino, Maya: the list of software products that architects depend on is long and growing. In particular, 3D CAD parametric modeling was the enabling technology behind a wave of creativity. From Gehry’s Guggenheim Museum to Jeanne Gang’s Aqua Tower, any complex shape imaginable could be attempted with the help of software that encodes the laws of physics. But while using 3D CAD may have sparked a revolution in building design and a new era of creativity, it has a down side. Writing CAD software is not something an architect learns to do in school; it requires incredibly sophisticated programming. In fact, there are only a handful of geometric modeling kernels underlying all the hundreds of available 3-D CAD software systems. So CAD is an incredibly powerful tool for architects but creates a new dependency on the companies that create and sell that software. CAD is a highly competitive industry, and therefore highly secretive and proprietary. Having a better, faster technique for translating shapes on a screen into geometric formulas is what sells one software product over another.

An even more insidious side effect of CAD use in architecture is found in the world of architecture libraries and archives. Architectural practice aspires to constant innovation, but begins by understanding the past. Libraries and archives have always stood guard over the collective history of architecture and design, stewarding millions of drawings, plans, elevations, blueprints, images, correspondence, project records, and so on. These archives are used to train each new generation of architects and document the history of the profession. Architectural historians and researchers from a wide range of disciplines depend on these archives. While the need for these libraries and archives is unchanged, their ability to steward the records of the digital era is under enormous pressure.

AIACC, arcCA 11.2, CAD, arcCA Journal,

top, U.S. Institute of Peace, Safdie Architects, photo by Timothy Hursley / bottom, Ray and Maria Stata Center, MIT, Ghery Partners, photo in the public domain

When records are digital, preserving them involves saving bits rather than atoms. But successfully saving bits isn’t enough, because every digital document depends on software to make use of it. Looking at a twenty-year-old digital article or image is often frustrating, since the software needed to open it is long gone—remember WordStar or VisiCalc? How would you study a SKETCHPAD design if you happened to find one? The challenges of preserving digital documents are as complex as those of creating the software in the first place, especially complex software like CAD.

For many firms, a typical building project archive now consists of a hard drive containing tens of thousands of digital files: 3D models, 2D drawing sets, emails, spreadsheets, images, videos, RFIs, ASIs, and more, all in their original formats and lacking any tags or metadata to help identify the files or relate them to each other. One 3D CAD model might consist of a dozen interrelated files, named by whatever convention the 3D software product happened to use. Figuring out which files belong together and how to open them takes insider knowledge that usually stops with the project architect.

And since the software products are usually upgraded every few years, a CAD model created just a few years ago may not open with the current version of the same software. Even software that provides tools to migrate a model from an older to a newer version may unintentionally introduce changes to the design object. To illustrate what can go wrong with CAD software versions, in 2006 the Airbus A380 airplane was delayed by a year at a cost of $2.5 billion due to use of different versions of CATIA in the design process by different divisions of the company. The versions were incompatible, so that designs for the wiring system done by one group couldn’t be integrated into the 3-D model produced by the other group.

As architecture libraries and archives have begun to get digital records for building projects, they are starting to work on strategies to cope with some of these challenges. At MIT, we conducted a two-year project called FACADE (Future-proofing Architectural Computer-Aided Design) to study the problem of what to keep from the project hard drives, how to tag them for future discoverability, and how to preserve the 2D drawings and 3D models for posterity. With the help and inspiration of the late Bill Mitchell at the School of Architecture and Planning, we collected records for three notable buildings that had made heavy use of CAD as our research collection. The oldest was Morphosis’s Caltrans District 7 Headquarters in LA (Bentley), followed by Frank Gehry’s Stata Center at MIT (CATIA), and finally Moshe Safdie’s U.S. Institute of Peace in Washington D.C. (Revit). These project records collectively provided excellent examples of the digital preservation problems, and with them we were able to work through a number of possible approaches to saving digital archives for posterity.

While the strategies we developed weren’t simple, we found that there are things that can be done to improve the chances of survival of these records, and that they’re worth saving.

First, keep everything in its original format, and the software used to create it. While it’s likely possible to find a copy of Microsoft Word 2007 in 2017, copies of specialized 3-D modeling software will be harder to come by. Keep in mind, though, that a lot of CAD software runs on desktop computers and requires a license key to open. Those keys normally expire when you stop renewing your license or when the company publishes a new version and deprecates the old one. So keeping the software is a good idea, but you may have difficultly using that software when you need to open the file.

AIACC, arcCA 11.2, CAD, arcCA Journal,

Screenshots from the FACADE Project

Next, for really important documents from the project, like the key design files, save copies of them in a standard format. For CAD, the best options are IFC or STEP, depending on which CAD program was used and what export formats it supports. Making these standard-format copies is a manual process, requiring knowledge of both the CAD software and the particular model being exported. The FACADE project employed graduate students from the School of Architecture and Planning for this work, but many firms have CAD experts who could do this. And while the CAD files are probably the most at-risk and problematic type of files you’ll want to archive, don’t overlook key files in other proprietary formats. For example, key documents created in Microsoft Office tools like Word, Excel, and PowerPoint can be saved in the Adobe PDF/A (an archival version of PDF) or as plain text files, which are much more likely to last than the undocumented formats that Microsoft uses internal to their products.

Third, put pressure on software vendors to do a better job of supporting long-term archives. CAD companies should help create good standards for archiving CAD models and support those standards in their products, especially companies that specialize in tools for the AEC industry. They should be open to escrowing copies of their software with trusted organizations (e.g. the Library of Congress, National Archives, or AIA). And they should also do a better job of documenting their internal data formats so that new software could be written in the future to read those files.

An interesting twist to this story is BIM. The vision for BIM is that it’s a living document, never “finished” and evolving over time alongside the physical building. That’s a great vision for the IPD and ongoing maintenance process, but poses the question of what the “design of record” should be for the future architecture student or historian. BIM is, in a way, a database that changes all the time, and in the field of digital preservation dynamic data of that sort is a big problem: what should be kept for the historical record, and how to do that. Should we make snapshots of the model at key points? Will there be standard file formats for those snapshots as reliable as those we’ve developed for other formats over the years? What if the library or archive doesn’t even get the BIM until twenty years after construction? BIM professionals are aware of these questions, but what we have here is a collision of interests: the best technology to preserve the actual building competes with the best technology to preserve the building’s history.

A last consideration is the growing use of project information management systems like Newforma. These products conveniently collect together all those project documents we now get on the hard drives, including the models and drawings, but they aren’t designed as long-term archives, nor do they typically provide support for exporting project records to digital archives. What was formerly a tedious manual process of combing through files on a disk is now a much harder process of extracting information from a proprietary tool that itself changes every couple of years. So, again, the potential for improved efficiency in building projects may lead to decreased efficiency (or complete inability) in saving the records of those projects for future use.

Why is digital preservation relevant for practicing architects and their firms? Mainly enlightened self-interest. If there’s ever a need to refer to an old design, consult a change order or ASI from a completed project, or consider an addition to an old building, you need usable digital archives. The best time to prepare digital records for archiving is while they’re young and healthy, not decades later when the firm is closing down. And while libraries and archives will do what they can to save the records they get, developing better tools and processes for the designers themselves to do this may mean the difference between having a historical record of architecture or not.

 

Architecture and Enterprise: Potential and Pitfalls

by .
in: arcCA 11.2 / 1 Comment

AIACC, arcCA, AIA California Council, arcCA Journal, arcCA 11.2, Crissy Field

Crissy Field Center, San Francisco - Photograph courtesy of Project FROG

Lessons and Opportunities from the Experience of Project Frog

The Entrepreneurial Accident
Our great architect-as-entrepreneur experiment started out by accident. The genesis of Project FROG, arguably the nation’s leading clean modular building technology company, arose from a desire for a bit of PR.

In 2005, we met with the publishers at Metropolis magazine regarding the suitability of our firm’s work for a high profile issue on education. The increasingly glazed look of the editor indicated that my pitch (for a story about what I thought were the most exciting architectural projects the world needed to know about) was not working. With the tone of her “Got anything else?” I knew I was running low on options. I ventured, “There is a more confidential assignment that we are working on…but it has never been shared.” The editor looked up and leaned forward. “We have been working on the problem of 300,000 classrooms in the US, and we have a prototype that looks like this (sketched furiously on a hotel stationery pad).” She was in, granting us good coverage if we published with them first. The only problem: we had no images, only basic research, and a bit of brainstorming by the office over beers on a Friday. We had thirty days before the reporter with a deadline was to visit our office.

The resulting article brought attention and inquiry from around the world. We were excited. We dodged, bought time, researched, and sketched more. The New York 2012 Olympic Committee called, we sketched a bit more. Then came the tsunami in Indonesia followed a few months later by Katrina, and we realized that we were in the center of a global problem with no viable solution.

AIACC, arcCA, AIA California Council, arcCA Journal, arcCA 11.2

Ilima Elementary School, Oahu - Photograph courtesy of Project Frog



Transforming Concept into Company
In 2006, we realized that we were well out of our safe range. Fortunately, we reached out for technological and business advice. On the technology front, our saving grace was the connection with two brilliant Silicon Valley talents: Manley Tantuico, an industrial designer, and Bekir Begovic, a metal fabricator. After they recovered from their amusement at our overly complex architectural approach, they patiently explained the obvious benefits of an industrial design approach: strive for a clean, simple, and repeatable solution made of as few distinct parts as possible, then organize the product into pieces, parts, components, and assemblies. Though obvious to an industrial designer, this was revolutionary to us. Soon to follow was the introduction to relevant software tools that support this methodology.

Financially, we were in even more foreign territory. The “problem” (i.e. the Market) we were addressing was large. We had a mission supported by the passion of some very talented creative minds. But we had the financial capabilities of a modest-sized, first generation architecture firm. So we did what came naturally to us: we sold units. Within a few weeks, we had two big contracts to build two campuses using our system. The problem was that we had quite a few product elements to finish, very tight project schedules, and understanding yet demanding clients.

We were able to capitalize a new company through a seed funding round of investment capital from a close network of friends, family, and associates. We recruited a very small business team and survived the completion of the first round of contracts. We hung on and were able to raise a large round of funding from Rockport Capital Partners, a Boston and Sand Hill venture capital firm, just as the fall of Lehman Bros marked the country’s decent into recession. I awoke to find myself the CEO of a venture-capital-backed company. The real estate market was collapsing, and we needed to get down to the business of creating project confidence and acting like a proper, growth-oriented, commercial enterprise. My vocabulary had to expand quickly beyond the realm of building to include “liquidation preferences,” “option pools,” “exit strategies,” “pipeline,” “venture debt,” and “optics.” I had to take a Myers-Briggs test, have “key-man” insurance, and see legal fees approach 10% of our annual spending.

We were in a brave new world, but the achievements were compelling, and the enthusiasm of the staff was motivating. Our belief was that we could change the way buildings were built. Energy consumption would drop 40%. Projects could be completed in weeks and months, not years. Schools would be healthier, providing environments that would support and stimulate the brain’s ability to retain and process knowledge. Crissy Field Center (San Francisco), the Watkinson School (Hartford, Conn), and Jacoby Creek (Arcadia, CA) exemplified this vision though the first generation of post VC funding solutions.

AIACC, arcCA, AIA California Council, arcCA Journal, arcCA 11.2

Photo left: Crissy Field Center, San Francisco, CA / Photo right: Center Watkinson School, Hartford, Conn Photograph courtesy of Project Frog

The company was growing, as were the issues. The investors determined that a professionally trained business team could best manage growth and expand funding, so a new CEO was brought in. I began a transition out of operating Project FROG and returned to the leadership team at MKThink.

Strengths of Architects for Innovation
That I am contributing this article, having come full circle from being a consulting architect and dabbling inventor as CEO of MKThink, to serving at the helm of Project FROG, and back again, reflects both the architect’s limitations and potential for driving the entrepreneurial experience. First, the potential: consider this outline of key factors of successful innovation, which are shared with architectural training and practice:

  • Industry ripe for innovation: It starts with our industry, which remains unnecessarily rooted in traditional methodologies. Also, the issues of our era—global connectivity, sustainably economic practices and environmental management— are non-traditional problems that benefit from prescient application of technology combined with social commitment. Other industries have made these connections for huge societal advancement. Broad and deep opportunities exist for industry advancement by applying these lessons to our methods: problem-definition, design process, systems integration, and ultimately architectural product development.
  • The ability to innovate: Solving problems thoughtfully, effectively, and efficiently through creative means is the basis for architecture and also the basis for innovation. Architects commonly focus these skills on a one-off solution that addresses an individual project and then start again for the next assignment. This same sense of investigation, systematically applied to repeating problems, could transform the building industry.
  • Integration of knowledge: Successful architectural practice requires skills in integration of broad fields of knowledge into a coherent and useful result. Applying these skills and knowledge creatively for each commission requires innovation on a daily basis. Taking the step to apply these traits to solve problems that are repetitive, rather than individual, is the main shift that distinguishes a good inventor from a good architect.
  • Problem-solving-through-collaboration skills: Successful contemporary businesses thrive on the collaboration of individuals with solid team-building skills. Leading business schools establish very expensive curricula, and recruiters treasure-hunt for talent with these attributes. Innovation requires a team of dedicated, forward thinking, creative people to work together to achieve a superior outcome.
    This is how architects already practice. The successful integration of designers, engineers, and policymakers into a financially responsible result is at the heart of what we do.
  • Small business skills: Successful innovation is an essential primary ingredient for small business enterprise. Tight budgets, managing vision and risk, an ability to be creative and effective on financial fumes, and motivating teammates with non- financial incentives typify successful innovative ventures. Successfully managing a similar recipe also defines the majority of architectural practices.

Limitations of Architects for Innovation
On the other hand, rather than an automatic gateway to new ventures, our training and wiring as architects give us tendencies—and deficiencies—that must be managed to ensure innovative and entrepreneurial success. Many of the major impediments derive from the business facets of such ventures:

  • Limited experience with investment business practices: Taking the ideas of others and transforming them into commercial success is a profession unto itself. Seldom can innovators, especially new innovators, manage the development of technologies into viable new businesses. There are requirements for capital, intellectual property issues, and legal and corporate procedures different from a service enterprise. The venture capital industry offers high profile and potentially appropriate means to propel innovation to commercial success. Yet, experience and caution are critical, as this road has a unique set of procedures, tendencies, and patterns, refined to serve the investment partners first and foremost. The VC portfolio approach will sacrifice an individual company for the hard realities of the portfolio as a whole.
  • Credibility and partnership with financial backers: Our professional world is not one that has established supporters in the financial communities. The recent history of innovation and entrepreneurial success has been in technology fields, particularly those that are low on capital intensity and high on consumer appeal. The long cycles of building and the lack of consistent investment precedent lack the appeal of software technology or social networks. Also, the independent lateral thinking and confident nature that comes from the experience of an architect (which suit creativity and innovation so well) may be at odds with the control and consistency favored by the equally strong willed investment community. They are fond of claiming that for each successful business venture there are a hundred great ideas, and that the difference between a hit and a failure is in business proficiency. These conflicts commonly characterize involvement with the venture capital process, and may be why so few company founders remain through the growth stages of the companies they found.
  • Financial success becomes the metric for professional success: There is some validity to the contradictions noted in the last point. Architects tend towards broad definitions of success. Investors have one metric of success: financial return. Having worked with investors who present themselves as socially minded, environmentally minded, or otherwise motivated by ideals, I have found that professional investors do not confuse investment with philanthropy. The presentation of “socially-inspired” investors in practice is more a means to organize investments and knowledge around industries of interest. Perhaps some socially minded investors will accept some degree of the “social return” measured in a few percentage point of flexibility, but the similarities to traditional methods are closer than the differences. Architects do not often calculate this way. If we did, we would be in another field entirely. Thus, success in this area requires an artful balance of your priorities with an open-eyed recognition of your investor’s goals.
  • Entrepreneurship takes focus and commitment: The investment community is correct to value not just the innovation, but also the roles that bring those ideas to market. Thus, innovative pursuits by an architect would be difficult if positioned as either the diversification of an architectural practice or a sideline activity. Success through the various obstacles requires total commitment to the end goal while maintaining a willingness to cooperate with very different types of professionals who expect that commitment.

Conclusion
It makes tremendous sense for practicing and trained architects to consider innovation as a structured professional pursuit. There is a need, there is a market, and there is precedent for success. Architects have valuable training and skills. There is an investment and partnership structure available to support certain ideas. If the creative professional has the will and ability to participate with the financial community, there is a reasonable opportunity for success.

As another point of reference: my first initiative upon my full-time return to the leadership of MKThink has been to create a dedicated Innovation Studio, focused on developing next generation building system ideas and technologies into new commercially viable enterprises.

 

Architect as Developer: The San Diego Story

by .
in: arcCA 11.2 / 1 Comment

The Q - Jonathan Segal Architect - Photograph courtesy of Jeff Durken

arcCA asked three architect-developers in San Diego, where the species seems to flourish, to tell us about their motivations and experiences. Here, Lloyd Russell and Jonathan Segal join in a dialogue; Ted Smith’s narrative follows.

What prompted you to undertake your first development project?

Lloyd Russell: There was no work happening at the time, so we used to joke that the only way to get hired was to hire ourselves. At a time when architects are getting marginalized in the building industry, it is empowering to be in the middle of things bringing a project to realization. And, if you do it well, you get to own it. It’s also putting your money where your mouth is. Architects promote the profession with the argument that we add value. Well, why not realize that value?

Jonathan Segal: I never wanted to have a client after working at two firms and seeing the lack of respect the clients give to the architects and the compromises they were forced to make. Just as significant was the pittance they were paid in comparison to the contractor.

Did you have training or experience that specifically prepared you to do development?
LR: I used to believe what my teachers at San Luis Obispo were telling me, namely that architecture would save the world. Problem was, I had to drive thru LA to get to school from San Diego, and I could not rationalize what I was seeing from the freeway through that paradigm. So I got interested not just in how buildings were built but why. And who made those decisions.

JS: I’m Jewish. But all architects have the tools required to do development.

arcCA 11.2, AIACC, arcCA Journal












Centre Street Lofts, Lloyd Russell Architect
Photo by Harrison Photographic		 arcCA 11.2, AIACC, arcCA Journal
    Richman/Poorman
    Smith & Others
Are you also the general contractor for your projects?

LR: Owner-builder, technically.

JS: Not in the beginning, but after building a few projects and seeing the generals take no responsibility for the work I paid them to do, I finally woke up and vowed never to hire another contractor again. They add no value and only subtract from the process, and now we always build our own work and have never looked back.

Did you have training or experience that prepared you to act as G.C.?

LR: I worked construction trades through school and after graduation without telling anyone I was a graduate. I got an earful on what contractors think about architects.

JS: Yes: the same experience that all architects have. Contractors don’t have any better skills than we do, and they have zero passion in our process. Passion is at the heart of every project.

What is your approach to risk management?

LR: I prefer to develop multifamily for rent instead of for sale. Ironically, when you take on all the responsibilities/liabilities of multiple roles, you get to a tipping point where the risk becomes less, because you won’t sue yourself.

JS: Build your own stuff; get the subcontractors to indemnify you, not the other way around; build apartments, never condos.

What do you most enjoy about your mode of practice?

LR: It’s more a lifestyle than a practice. You make different decisions on when, where, and why to take on a project when you have a stable
cash flow from prior projects.

JS: Multi-tasking and seeing our sculptures take shape. Most importantly, we have a sustainable practice that has rental income and creates long term balance sheet growth. It’s time to help all other architects do what we do.

Ted Smith: I first developed a house for my family. I’m not sure you call that development, but I guess it is. That was in 1975. Five years later, the economy was crashing, no one was hiring architects, and I couldn’t make my mortgage payment, so I borrowed one last $20,000 from a hard money lender and builtmy first real development, where I was counting on renting space to pay the bills. That was the first of a series of shared houses with six suites in each, with private exterior entrances, that I called GoHomes. These turned out to be popular, and I built five such houses over as many years, each with six to eight suites, providing very affordable ownership in pricy Del Mar Terrace.

Over this same period, the demographic of the neighborhood changed from surfers and academics at UCSD to yuppies, with property values as their main interest. The new people didn’t like affordable housing, so I left the Terrace and joined my good friend Rob Quigley downtown, where he and Kathleen Hallahan had built their new home and office in Little Italy. Kathy McCormick, my collaborator and by the way girlfriend, was looking at the Sunday paper, and she saw a lot that cost about the same as the lots in Del Mar Terrace, but you could build a big building there, and there were no Nimbys. So we moved our practice downtown and built San Diego’s first (as far as we knew) townhouses, something Kathy was championing, along with a bunch of GoHomes. We called the building the Richman/Poorman building, since it combined high-end row houses with tiny apartments in one building.

We found these experiences extremely rewarding, being able to invent the building type, which seemed much more substantial than decorating some developer’s bad idea. We could serve a population that we understood and direct the development to places that were more friendly to the environment than, say, the big custom homes we had been designing in Fairbanks Ranch. This ability to control the project remains the overriding motivation behind deciding to be an architect/developer. Of course, we also had learned that it was easier to borrow money from banks than to collect it from clients, and the income from apartments was recession proof, freeing up the anxiety that comes with the cyclical traditional practice of architecture.

I was untrained when I began, and that naiveté is probably the only reason I would have tried development. Certainly, a project like the GoHomes would not have come from someone with wisdom. If I had understood the complexities, I probably would have shied away.

I’ve always built the projects I have developed. I had built my first house, and I always understood that the construction is where the money is. I also learned that it was less trouble to be the contractor than argue with one. I learned to build on the job, and any mistakes I made were well worth the substantial savings.

My staff has always been young architects, whom I would partner with to accomplish the projects. This is expensive, because you end up giving away a lot more than you might if you had the money to hire, but a group is more powerful than an individual, and I have always been a bit of a socialist when it comes to being fair and providing opportunities. When one develops, profits are way down the road, so it is good to have all the staff on board, agreeing to show up and work for some common goal way off in the future, and a group helps establish a discipline that working alone does not. Everyone agrees to show up first thing in the morning and work until dark. Also, many jobs just require a number of people to accomplish, like framing or building a foundation or placing the windows. We always do about half the subcontracts, as well as act as the GC. I have had many young, talented architects help make the projects, and they have nearly all been partners. Only on very large projects have they been joined by paid staff.

As soon as projects become larger than, say, four units, a rich man is required to cosign the loans. So these projects are not for beginners without wealth. Small projects are also the projects that need to get built, infill. Normal developers don’t want to build small, because the effort is the same no matter the scale. I prefer a street of individual ownerships, an expression of community, over a full-block building that seems more to express a developer’s big money dreams. The big (and mostly bad) projects get built anyway. It’s the fine-grained projects that require a very large amount of work for their size. The purpose of the Master in Real Estate Development program at Woodbury University is to teach these skills to young architects, who are the ones schooled enough in what is good urbanism to take these infill projects on. The big guys can go ahead building the full blocks, tracts, and industrial parks.

I manage my risks by doing as much as I can by myself and by careful choice of partners. That way, when something goes wrong, it is our fault. I can get a screwdriver and fix it, rather than hire a lawyer. I also build for a market of young, artistic people, the kind who see the world in a good way. I am less comfortable building for people with money. If they have money, they are probably not my market; and, besides, they are probably the kind of people who will sue me, rather than be reasonable. This has worked well for me. I haven’t been sued as a developer, except once almost by a disgruntled partner. I figured out how to buy the unhappy partner out, and it all was OK. That is one instance in what has been thirty years of development at this point. So, risk management has more to do with picking partners than buying insurance.

I enjoy development, because it builds wealth, and it builds those projects that would not be built by the normal industry. I love being in control, and I am always advising young architects to stop traditional practice as soon as possible. It seems to me that the normal practice of architecture is a foolish endeavor, where wonder is promised in school only to run up against the sad reality that is normal practice or services for hire. Traditional practitioners, except in extremely rare cases, make way less money and have way less control, so the architecture is worse and the income intermittent. Of course, there are exceptions to anything one says. Certainly there are many good architects, who, with savvy political skills, navigate the treachery of traditional practice and even make great buildings, but I’ve never been too good at trying to sell an idea; I’d rather just decide to do it. It’s enough trouble just to sell an idea to myself.