The Future of AEC Software, Part 2

Access Across Use Cases, Personas and Locations

In part 2 of his series, Aaron Perry lays out why AEC demands a different, modern framework for design collaboration to deliver increasingly complex projects.

After setting the stage by providing a brief history of how professionals have accomplished their work over the past few decades, he writes:

In 2024, every design studio, engineering firm, and construction company will operate with a hybrid workforce between various offices, at their homes and increasingly with a global footprint. We're not going to revert back to office-only working.

Yet, with the software we need to use to deliver the scale and complexity of projects, we're tied back to our office desktop computing and the infrastructure connecting them. I often reflect on an interaction with a young architect from a couple of years ago, whose puzzled face still troubles me today, as I still don't have a great answer to his conundrum: They have first-hand experience of the challenge in collaborating with colleagues, on the same spec hardware next to each other, with struggling performance. Yet outside of work, their benchmark is effortlessly engaging with a global group of 150+ strangers in a dataset the size of a city, with the intricate details of a window, across a mix of hardware specifications, in a game.. and confusingly returning to the office the next day for a significantly worse experience.

The gaming angle is a perfect example of how an adjacent industry has accomplished exactly what’s being asked for: a massively complex, multi-player, hardware and location agnostic, data-rich visual environment.

And then AEC re-enters the chat:

Today, our data and energy are locked into inaccessible proprietary file formats, accessed only by expensive hardware, complex desktop software, and traditional ways of working collaboratively.

Again, the entire short article is worth the read. In it Aaron continues to lay out expectations for the tools needed to get the job done today, while I can’t help but feel like it will take years for a mature, cohesive solution to come to fruition. Current software developers and startups are tackling different parts of the puzzle, but aren’t addressing many of the core issues being discussed here.

For the most part, architects simply choose their software from the shelves of available titles and their features put on offer. More often, they are beholden to whatever platforms they’ve used in the past because of serious investments in training, content, third party integrations, and more. Of course, they’ve been participating in software development cycles and have given feedback along the way, but flipping the script entirely to create the scope for developers to follow is a different tact than has ever been used before. I’m hoping it works, but it may only be an option for new companies who have not yet begun creating solutions. Turning a ship that’s already set sail can be challenging.

My questions at this point: Are any of the software vendors answering in the affirmative? Have the incumbents done anything to acknowledge they are planning to implement what’s being asked for? And are any startups changing course to follow this path? Many large firms have signed on to this movement and have the wallets at the ready to pay handsomely for a job well done, but I can't tell if anyone is listening.

This is part 2 in a 10-part series from Aaron of which I intend to continue to share here as the series progresses. Read the article, learn about the challenges and the proposed solution, and get involved here.

For more conversations around these topics with the author and others, check out these related TRXL podcast episodes:

• 143: ‘The Future AEC Software Specification’, with Andy Watts and Aaron Perry
• 134: ‘The (Chaotic) State of the AEC Tech Industry, Part 2’, with Martyn Day
• 133: ‘The (Chaotic) State of the AEC Tech Industry, Part 1’, with Martyn Day
• 079: ‘Changing the Relationship’, with Greg Schleusner