Of Autodesk and the Freedom Tower

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. ®