Original URL: http://www.theregister.co.uk/2005/09/27/autodesk_freedom_tower/

Of Autodesk and the Freedom Tower

Lessons for software developers?

By David Norfolk

Posted in Developer, 27th September 2005 09:05 GMT

Autodesk is famous for Autocad and it is the market leader in computer-assisted design, with some 2500-plus third-party developers producing complementary products.

Developers might like to think about this – developing for a specialist platform - if you're good, might cut down on competition and give you a measure of career security.

Skidmore, Owings and Merrill LLP (SOM), the architect firm, for example, used the AutoLISP programming environment in AutoCAD to create new tools for modelling, analysis and documentation, just for the Freedom Tower project - rebuilding the World Trade Centre site post-9/11 - although they will doubtless have wider application.

However, Autodesk claims to be an ideas company, not just a specialist 2d and 3d design automation company (in support of this, it was one of the sponsors of Ted Nelson's ground-breaking Xanadu project). The results of the collaboration of SOM with Autodesk Consulting (and also with Jaros Baum & Bolles, JB&B, the M/E/P engineers on the project, and WSP/Cantor Sinuk Group, CSG, the structural engineers), also appear to bear this out.

The Freedom Tower is an extremely visible project, politically, and consequently high risk. SOM has used a range of Autodesk products including Revit, an architectural design and documentation system, and Buzzsaw, (a collaboration management tool, to produce a “virtual project environment”, to help to minimise this risk.

This environment enables engineers and architects to visualise the emerging design in 3d, animate the design as, for example, the sun passes overhead and shadows change, and identify and mitigate any issues before they are committed to concrete. However, the project and information management tools behind this make it more than just a cosmetic picture.

Although it is early days yet and the functionality of the building simulation is pretty basic, it has the potential to transform the building process, according to Phillip Bernstein, VP building solutions division at Autodesk and lecturer in Professional Practice, Yale University School of Architecture. The essence of this approach, perhaps, is the avoidance of process waste by using automation to avoid "information backflow".

In the conventional process, at the end of every stage in design and construction, information is rationalised and committed to paper for handover to the next stage and whatever doesn't reach paper is lost; it is then laboriously built up again before the next stage can really get underway. In contrast, automation allows the outputs of one stage to be transformed into the inputs for the next, without loss.

Paul Sefetsky, digital design director, SOM NY, gives a fascinating picture of this new process in action. He shows that by modelling construction itself you can promote collaboration and deliver what has to be an iconic building – which can be seen (in simulation) to be iconic, a symbol of the recovery of NY post 9/11, long before the project completes in 2010.

Sefetsky emphasises that SOM didn't just jump into this; it did a proper evaluation of Revit first, although perhaps the real test is the pleasures people apparently take in using Revit. But the new process does deliver, it gives SOM rapid design realisation and confidence both in the final delivery and in its ability to make radical changes in a controlled and cost-effective way. The design of the Freedom Tower above ground has already changed significantly, for instance, to accommodate the need of the NY police department for more space around the tower).

According to Sefetsky the collaboration with Autodesk Consulting has delivered “competitive advantage without being at the bleeding edge”.

So far so good, then, but so not particularly IT. However, we could have taken these presentations, changed the names of the technology vendors and replaced “building” with “computer application” – and we might have been listening to a presentation on the benefits of the OMG's Model Driven Architecture!

Of course, this isn't so surprising when you remember that the “patterns movement” behind much modern software development was based on an architectural movement - check out this interview with Erich Gamma. Gamma's seminal book Design Patterns (Gamma, E. R. Helm, R. Johnson and J. Vlissides. Addison-Wesley, 1995) was based on Christopher Alexander's work on what he sometimes called "a timeless way of building".

However, it gives one pause for thought when you hear Autodesk's Bernstein talking about his architecture students and their reaction to this new way of working and realise that they are raising issues awfully like those raised by hands-on programmers when they meet automated systems development. People don't like change and automation brings change. Nevertheless, it seems highly unlikely that our systems development process should be immune from automation, considering that we can automate business process successfully - admittedly with all the disruption that entails for business workers.

Perhaps we need to examine the automation process and its consequences dispassionately, before we decide that Model Driven Architecture (for example) can't work for us. And perhaps considering the automation of building design processes is a good way to isolate ourselves from the personal impact of automation, so we can make a neutral assessment.

Of course, a formal model-driven architectural approach isn't the only way forward. Kent Beck's eXtreme Programming (XP) approach, for example, achieves similar ends to those achieved by SOM's simulation of the Freedom Tower design, by actually building pieces of business function and constantly testing them against prebuilt test cases.

An XP approach probably isn't appropriate to building the Freedom Tower, but XP does respect architecture and can deliver notable successes. Something similar was probably used, more or less, to build a lot of wonderful European cathedrals, although looking at the noble edifices we see today, shouldn't blind us to the fact that quite a lot of cathedrals fell down early on – perhaps some builders skimped the test cases.

But, XP is appropriate to programming, and we should consider using it – just as we should also consider using the more formal modelling approaches represented by MDA, say, which correspond to the modelling/simulation processes used by SOM. There may be several paths to a goal and sometimes looking at another discipline (such as buildings architecture) can help us appreciate some of these alternatives. ®