At our inaugural NXT DEV conference, one of the keynote talks, given by Aaron Perry of the Open Letters Group, announced a free to all Future AEC Software Specification backed by global firms such as BIG, HOK, Herzog & de Meuron, KPF, Woods Bagot and ZHA. What should next generation tools be able to do? Martyn Day gives the back story
In London on 21 June, at AEC Magazine’s NXT DEV event, Aaron Perry, head of digital design at AHMM, gave a masterful presentation on the ‘Future AEC Software Specification’, a document that looks destined to have major influence on the future of AEC software.
Perry spoke on behalf of a peer group of leading architectural practices, which have been discussing the future of design tools and how to drive development across the entire design software community.
The specification originated with the UK Open Letter Group (OLG), who wrote that infamous letter to Autodesk CEO, Andrew Anagnost in 2020, but it is a much wider global effort.
It is currently being shared amongst the Nordic OLG firms (authors of a second open letter), and the highly influential AIA Large Firm Roundtable (LFRT) for approval and revisions.
The specification addresses the whole software development community, including those that invest in technology, and provides a level of customer insight that, quite frankly, is not available anywhere else. It asks, what is the future of our industry from a digital design point of view? It is a truly unique offering.
In his talk, Perry first points out that the specification is not a definition for a single monolithic product. The industry needs an ecosystem of best-in-class tools that can work together and are applicable to large firms all the way down to single users. There are ten pillars to the specification (see below). We’ll look at some of the key ones below.
Data framework
Fundamental to the specification is the data framework. When trying to deliver complicated projects, firms use many software tools. Every time data is exported between the various siloed tools, data is lost. As a result, most firms accept the status quo and try not to move their data between various file formats, choosing to use suites of average tools.
But many firms still try and use the best tool for the right problem, but they are paying for it through translators, complexity, plug-ins, specialist software. This is the biggest drain on time and energy in the industry. A solution would be something like USD, (Universal Scene Description) which is open source and solved most of the data transmission problems in the CGI world. It’s a common standard, transmits geometry, lighting, materials to pretty much any media and entertainment application, whoever developed it.
The AEC industry faces a similar problem. With USD the common data structure sits outside the host products. This also means different teams, with different specialisms can open the USD file and work on their part of the scene. This creates a level playing field for software developers.
Read the Mission Statement of the Future AEC Software Specification
According to Perry, USD has some challenges. It’s a file format, as opposed to a database, there are variants as it’s not a perfect specification, and it is not the right format for BIM data.
Perry explained how different participants in projects need to access different levels of detail of data – specific data sets for structural engineers, cost consultants, sub-contractors who don’t need the whole model, energy simulation experts.
“The concept of the data framework being outside of these file formats, enabling different people to access author modified geometry and parameters, concurrently. This is by entity or component, not requiring the opening of the full model to review a single string of data,” he said.
“At this entity level, collaborators can concurrently commit changes and coauthor packages of information with a full audit trail. Moving away from file formats and having a centralised data framework enables local data to be committed to a centralised data framework and allow entire supply chains to access different aspects of the whole project without the loss of geometry.”
As an industry, we are currently locked into proprietary file formats. In the next generation, Perry clearly makes a case for shared and distributed ownership without the vendor lock-ins that the industry has suffered from.
Moving away from file formats and having a centralised data framework enables local data to be committed to a centralised data framework and allow entire supply chains to access different aspects of the whole project without the loss of geometry
Context and scale were others aspects of data that Perry commented on – with the need for detail, such as an individual sprinkler, in relation to the whole building. Game engines like Unreal with Nanite technology can model dust particles and sand, while scaling up geometry to the size of countries. Models are being rebuilt and remade for this level of detail. We need modern performant software from concept to construction levels of detail, he said.
Find this article plus many more in the July / August 2023 Edition of AEC Magazine
👉 Subscribe FREE here 👈
Responsible design
Projects are increasingly becoming centred on retrofit. With sustainability at the core, the focus is on reinventing the buildings we already have. Time is spent analysing the fabric of existing buildings but there are no tools available to help this. Perry explained that we need software that understands construction and embodied carbon – every major design firm has written their own. We also need more tools for operational energy, water use, climate design, occupant health, community – we are not seeing any tools with this on their agenda, he said.
MMC and DfMA
Modern methods of Construction, DfMA and Off-site are increasing and firms are looking for more certainty in construction. There are design constraints for shipping volumetric buildings to site, yet Perry explained that 95% of software currently available will not allow design to create design constraints when conceptually massing studies.
Most of the massing studies software, and there have been many that have come to market, is not fit for purpose. In fact, design tools do not allow architects to go down to the fabrication level of detail required. There is no modular intelligence.
Modelling capabilities
Moving from drawing board to CAD was pretty straightforward. Moving to object-based modelling was more challenging. Perry calls for more flexible tools, smarter tools that have construction intelligence, “We have either flexible tools without structure, or structured tools with no flexibility. Neither of which understand how buildings come together”.
Automation and intelligence
The industry is highly repetitive, yet across all firms, despite there being experience and knowledge in abundance, that knowledge gets applied from first principles each time, without learning anything from previous projects. Can we have tools that capture that knowledge?
The core size is manually calculated for every single building, over and over again, as the building envelope changes. When talking about repetitive tasks, like creating fire plans for multi-floored buildings, Perry asks ‘Where’s Clippy? We have no automation from past projects”.
Deliverables
The industry is spending far longer creating drawings than designing. “Why are we still generating drawings on A1 and A3 sized templates but these are never printed by anyone?” asked Perry.
“The drawing production process is about the release and exchange and acceptance between multiple parties and it’s sticking around for the time being because it’s our sole method, as an industry, to transact between different parties but what is the lifespan during production?” Using a centralised data framework with automation might become an alternative. Drawing production might become more incidental in the future.
Access data and licensing
As subscription has changed the way customers pay for tools, there have been far too many experiments with business models. Floating licences have been expunged for individual named user licences. Firms end up restricting access to those products. “Commercial limits are commercial limits.” said Perry. Token based systems expect the customer to gamble on future usage needs.
“We are seeing a trend in some vendors by charging a percentage of construction value. The reality is that by doing that you are pushing the decision making process of what design software to use to the person paying the bills and setting the total values for projects, so we’re effectively walking into a situation where we’re saying ‘the commercial decision for purchasing software now sits with the pension investment fund that owns the budget.” Needless to say Perry is not a fan.
In his hour-long presentation, Perry outlined just a few of the topics dealt with in the Future AEC Software Specification, which can be seen in full here.
To watch Perry’s excellent presentation and the panel discussion that followed, click here
Conclusion
We are at an interesting point in AEC software development. Mature customers are ahead of the software developers, wanting more, and demanding higher productivity benefits. The leading software developer, Autodesk, has just started replacing its tyre at 90mph, working out how to migrate Revit data to its new unified database, while figuring out what design tools Autodesk Forma will offer.
At the same time, new start-up firms are listening to mature customers and pondering what they do for the mass market play. The Future AEC Software Specification is the generic guide to all developers in the industry, to think about the kinds of tools that large firms would like to see, beyond what is currently available.
From watching Perry’s crystal clear talk at NXT DEV, and dropping into the conversations on the various panel sessions, it’s clear that there is plenty of opportunity for the industry to work together to develop the kind of capabilities which many would love to have right now.
AEC Magazine hopes to put on a yearly event where we continue to directly connect innovative practices with software developers and VCs. It’s reassuring to hear from the OLG that large construction firms have been inspired by Perry’s talk and the release of the software specification and are already looking to join the initiative and contribute to the specification to make it broader and pan-discipline applicable.
Mission statement
Future AEC Software Specification
“Our aim is to set out an open-source specification for future design tools that facilitate good design and construction, by enabling creative practice and supporting the production of construction-ready data.
“This specification envisages an ecosystem of tools, for use by large firms and single practitioners alike, with a choice of modular applications each with specific functions, overlaid on a unifying “data framework” to enable efficient collaboration with design, construction and supply chain partners.
“As architects, engineers and contractors, we do not profess to have all the expertise needed to enable this ecosystem, but we do know what we need to do our work, and so we are looking to engage with the software community to deliver the best solution.”
A Q & A with Aaron Perry (AHMM) and Andy Watts (Grimshaws) |
| We caught up with Aaron Perry (AHMM) and Andy Watts (Grimshaws), after NXT DEV to show to find out what kind of response they had to the Future AEC Software Specification.
AEC Magazine: What was the immediate reaction at NXT DEV after you came off stage? What did people say to you? Aaron Perry: When I came off stage, I couldn’t move two metres without another group of the audience wishing to speak with me. I was surprised how many people really ‘got’ the spec’s intentions. To some extent, I expected many to ask, ‘What about IFC?’ and most people got that we aren’t talking about file formats but web-enabled data exchanges. Andy Watts: It was also surprising the range of interest we got – from engineers, developers, contractors, even the likes of KPMG. The way Aaron pitched the presentation made sure there was resonation with everyone, regardless of discipline.” Aaron Perry: Online, it’s been overwhelmingly positive, I expected trolls to express alternative opinions for the sake of it, but the feedback so far has been very positive and complimentary of the initiative. I’ve spoken with vendors and designers, and it’s been encouraging. Andy Watts: After a few weeks to digest, we’ve started to see some more mature engagement as well, readers wanting to know how this will work. AEC Magazine: You have HOK and BIG signed up. What’s happening with the the AIA LFRT and the Nordic Open Letter Group. Are they in the process of approving it? Aaron Perry: The website has been updated with supporters, and there are many that we haven’t even managed to get around to adding. We received confirmation from the Architectural Associations of Finland, Norway, Iceland and Denmark on the morning of NXT DEV. Since this, we’ve also had Central European associations and firms express interest. Andy Watts: I’ve met with HOK and Woods Bagot whilst in the US the past couple of weeks. There has been conversation happening informally amongst the US firms – a healthy debate was how that was framed to me. But since then, a number of US firms have also started reaching out – nbbj, Perkins & Will, etc. Greg (HOK) and Shane [Burger] Woods Bagot are also laying the groundwork for a presentation to the LFRT by Aaron and I later in the year. Beyond that, we’ve started to see Australia get on board in the last few weeks – Cox, Architectus, Aurecon have all started reaching out. And it has recently had some publicity at some AUS events. AEC Magazine: Construction firms were also interested. Will there be signatories from the construction space? Aaron Perry: One of the most surprising conversations I had straight after the presentation was from a Tier 1 Main Contractor who said something along the lines of ‘we’re very in bed with Autodesk. We’re actually working with them to build out custom tools for us, but you raise a really valid point that we should challenge vendors too, can we speak more…’ So yes, this is not limited to just designers. ICE and others have asked us to report to their strategy groups to help them understand where they can contribute. AEC Magazine: Now that you have delivered the specification what comes next? Aaron Perry: We’re working on it. We have a solid plan of what steps to take, but I’d be talking out of turn to share that without having received a broader sign-off. Andy Watts: Agreed. Generally our approach was to put this out in the public to see if it resonated, and then plan from there. We’ve got the resonation – now we’re working on the plan. AEC Magazine: How can firms contributes to the specification? Aaron Perry: The spec is live and has started to receive feedback/input. We’re pointing people to that and to add their thoughts and adaptations. Andy Watts: Also, we’ve seen a lot of engagement through word of mouth, so we’d encourage people to share. |
How we arrived at the Future AEC Software Specification
Over the past five years, the majority of investment in the AEC industry, including venture capital, acquisition and development, has focused on construction. This happened at a time when architects and users of the number one design modelling tool, Autodesk Revit, were getting frustrated at the lack of meaningful updates, but seeing increased software subscription costs.
Meanwhile, Autodesk was in full acquisition mode, buying up cloud-based applications to fill out its Construction Cloud service. While there had been long-term rumours of a new generation of solutions from Autodesk based on the cloud, originally called Quantum, there was no set date or anything to show.
This frustration led to the formulation and delivery of an open letter to the CEO of Autodesk, Andrew Anagnost, from 25 UK and Australian firms, highlighting a wide range of complaints, from lack of updates to the stuffing of ‘Collections’ with products they don’t ever install, let alone use.
The net result was a series of meetings with Autodesk management and product development staff, exploring what kinds of features these firms would like to see in Revit.
In 2022, Anagnost made it clear that there was not going to be a second generation of Revit as we know it – a desktop application. In an interview with Architosh, he said, “If you want a faster horse, you might not want to work with us because we will not make a faster horse. But we can be that partner and tool provider that supports professionals into the new era of architecture.”
That new era was a future version of Autodesk Forma, the cloud-based platform which softlaunched this year with an initial focus on conceptual design.
Around this time, the Open Letter Group (OLG) were engaged with the Revit development team, providing wish lists for Revit. Meanwhile, a group of signature architects had also approached Autodesk with similar complaints, just without a public letter, and went through the same engagement process, requesting new features.
The Revit team had its own part-published roadmap and there were attempts to see where they could align. But herein lies a problem. When asking for feature wish lists the many will always drown out the few.
Autodesk has sold somewhere between 1.2 and 2 million seats of Revit and the majority of users have fairly rudimentary needs. Meanwhile, many of the firms that were complaining were the mature BIM users, a minority that are really pushing the boundaries and are frustrated at being held back with Revit’s lack of development velocity.
Any boundary-pushing technology or new development was more likely to appear as a cloud service or as part of Autodesk Forma – and this transition could take years
This led to a second open letter, the Nordic Letter which is now signed by 324 firms, including BIG with Danish, Norwegian and Icelandic Architectural Associations, representing some of the firms who had approached Autodesk privately.
The OLG had little faith that Autodesk would build into Revit the advanced features its members need. Any boundary pushing technology or new development was more likely to appear as a cloud service or as part of Autodesk Forma – and this transition could take years.
The OLG decided to work on a specification, a shopping list of the kinds of technologies they would like to see in a next generation product.
By this time, late 2022, the OLG had been approached by nearly every large software company with an interest in either entering the BIM market or tailoring their current offerings to meet the BIM needs of the members – Hexagon, Nemetschek , Dassault Systèmes, Trimble, Graphisoft, BricsCAD, Qonic and others.
The decision was made to collate the specification and just ‘put it out there’ for the benefit of all / any developers looking to create next generation design tools. And there are many, including Snaptrude, Qonic, Arcol, Blue Ocean and Swapp, with more waiting in the wings.
As we move towards a second generation of design tools, one of the key challenges for these software developers is to what extent should they respond to the needs of the firms that have complained? Autodesk is not alone in feeling it needs to cater to the masses.
As one developer told us, “We’re in the volume market and developing for the signature architects and large firms does not make commercial sense for us.”
The problem is, artificial intelligence and machine learning is coming very quickly to this market, and people that use BIM to make simple rectangles and unexciting geometry, are going to be the first to face automation.
In an AI world, those who create complex geometry and more unique designs will be the ones that will still require more software products. AI probably means more Rhino.
Databases over files
Greg Schleusner of HOK has been on a similar tack, looking at next generation tools, specifically concentrating on the change from proprietary to open data formats and from files to data lakes.
The industry wants data sovereignty and independence. It does not want to be trapped in proprietary file formats again. We’ve already been DWGd and RVTd; we need to move beyond the silos and it’s time for open databases, offering freedom to share at a granular level, without the need to write ‘through’ a vendor’s application to gain access to your own or other’s project data, held in proprietary repositories. Schleusner has managed to bring together a consortium of 39 firms to pursue the creation of this open data lake.
To really understand the scope of this, we recommend watching his past three presentations from NXT BLD.
2021 – Creating Balance
2022 – Road to Nowhere
2023 – Assemble
