With the increasing digitisation of the AEC design process, more firms are either developing their own bespoke BIM software or paying for the creation of custom tools to refine their projects through computation. Martyn Day explores the planet of the apps
When we first moved from drawing boards to desktop PCs running CAD software, it wasn’t long before the creation of lines, circles and arcs failed to give us additional productivity benefits.
The beauty of being digitised in a computer meant that automation and higher levels of industry knowledge could be captured and used in vertical applications.
Software developers added support for programming languages (e.g. Autodesk with LISP) and created Application Programming Interfaces (APIs) for professional developers to build expert systems on top of their drawing tools.
This eventually led to industry-specific software firms, creating dedicated vertical applications, designed for very specific professions – architecture, structural, civil, CAFM etc.
Advanced users utilised the programming extensions to automate repetitive tasks and integrate with external programs such as spreadsheets. Some firms completely tailored their CAD systems to their usage.
The ability to adapt and augment has been a core part of our design tools for some time.
The move over the last 20 years to 3D modelling/BIM tools has further digitised the design process, pushing beyond pure symbology and ‘dumb’ drawings, capturing 3D geometry and detailed building information.
These systems, namely ArchiCAD, Revit, Vectorworks, BricsCAD BIM etc. still include programming languages for end-user extensibility as well as APIs, spawning a range of modern third-party developers, like Enscape, Testfit, Strucsoft etc. keen to add additional functionality.
For end users, computational design tools like Bentley Systems GenerativeComponents, McNeel Rhino Grasshopper and Autodesk Dynamo have provided deeper levels of automation, handling geometric definition complexity. The net result of this has been a generation of designers acquiring scripting and programming knowledge, together with a realisation that design requires data flow through multiple software packages.
With this current incarnation of AEC design tools and user skill sets, something is different. In the last few years, I’ve noticed an increasing number of AEC firms develop ambitious in-house applications, workflow connectors, AI, simulation and specific tools for project teams.
While investing in creating in-house tools might not be a new thing, the fact that many of the firms are branding and marketing their in-house code as a potential differentiator, indicates an increased level of programming competence.
The true scale of this trend hit me in the face when Gensler sent a press release last summer about ‘Blox’, an algorithm-powered design visualisation and computational tool.
It came with its own logo and branding and slick interface. It looked like something you could buy from a reseller and may well be a tool that many architects would like. However, it was a proprietary technology that was designed for its inhouse teams, as part of the firm’s inFORM suite of tools to boost internal design capability.
This was a new level of workflow productisation for Gensler, which was clearly making a statement to the market. AEC firms don’t just design and construct buildings; they also write their own code and build their own bespoke BIM software.
Gensler has invested in technology to join up its digital thread, starting from the client brief to concept, all the way through to completion. The firm has its own in-house programming resources, together with strategic investments in small application developers to augment its own product stack.
The trend for AEC firms to develop software is now becoming a lot more common. In addition to Gensler Blox, Bryden Wood has launched PRiSM for modular development, Lendlease has developed Podium, a ‘property lifecycle platform’ for planning, financial, performance management of buildings.
Similarly, Space Architects has developed TwinView for Digital Twin management and Ramboll has SiteSolve, a computational design tool for building analysis at the early-stage of the decision making process that is capable of iterative massing.
On top of all this we also have consultants and resellers developing and selling tools which they have created in the past for clients to solve specific problems. Proving Ground, Thornton Tomasetti, Oasys (Arup) to name but a few.
Bespoke BIM software – the origins
Of course, in-house development is nothing new. Having an expert technical team to help bring impossible architecture to reality has been done by a select number of firms.
Probably the most famous architect in this area is Frank Gehry. Before using CAD, Gehry had trouble winning projects because contractors could never fully understand his buildings from the drawings and so would quote extremely high prices.
He moved to deploying Dassault Systèmes Catia in-house, an advanced CAD tool traditionally used by automotive and aerospace firms, then built a team of experts who digitised all of his paper models and eventually got their own brand (Gehry Technologies – under Jim Glyph).
By sending 3D models to his contractors, quotes came down and his buildings became less financially onerous and risky to build. Eventually Gehry Technologies was sold to Trimble and to this day many instances where Catia can be found in AEC, have ex- Gehry Technologies employees involved.
In the UK in the 1980s, YRM and Richard Rogers were early into 3D modelling. They used products like Sonata and RUCAPS (Really Universal Computer Aided Production System) and were coding to complete designs. Similarly, ARUPs, which eventually set up Oasys specifically to develop applications for internal and external markets.
In 1998 Foster + Partners set up a Special Modelling Group (SMG) under Hugh Whitehead, which similarly took on the hard problems of geometry definition and created bespoke tools for the designers to experiment and play with complex geometry.
Foster + Partners has also set up the ARD – Applied Research + Development Group, headed up by Francis Aish. While most of the developments which the dedicated team creates remain in-house secrets, some do get an occasional airing, such as Sandbox I/O, a real-time conceptual design evaluation tool, written on top of Unity (see this AEC Magazine article to learn more).
Lego vs geometry definition
The examples of Fosters and Gehry could easily be seen as the exceptions to the rule vs the workflows and toolsets which most design firms use. The need for computational tools designed by aerospace engineers was certainly driven by the need to express the extreme geometric vocabulary for which these signature architecture firms are famous.
However, this isn’t the end of the story, as both practices reach out to work with contractors who are digitally fabricating building components, connecting their designs with fabrication machines. This is the future of our AEC world and digital fabrication will liberate us from the risks of non-rectilinear forms.
Today’s BIM tools mainly tend to be based on components; the Lego approach to modelling and the conventional approach to building. The software is also focused on the conventional method of collaboration – 2D drawings.
While useful in some circumstances, and targeted for documentation, they are not ideal for design exploration, especially conceptual. This appears to be a key area where we are seeing a lot of in-house development from AEC firms trying to fill their digital voids.
The other issue with BIM software is that as designs progress, the size of the models increases, and the performance of the system is impacted. While software vendors have typically wanted customers to stay within the BIM application for the whole workflow, this is not an ideal environment to run CPU-heavy design evaluation tools, such as analysis or BIM coordination, where federated data needs to be collated and shared to resolve issues.
Gameification
One of the biggest changes to the application development landscape has been the arrival of the game engine tools, Unreal and Unity. These mature, extensible engines are optimised for 3D performance and provide firms with powerful development platforms.
Data flows between BIM tools and these game engines have vastly improved in the last few years and are now proving popular for geometry-based design development.
Unreal, for instance, is capable of displaying an entire city in real time and the developer of the engine, Epic Games, has clients such as HOK, KPF, Foster + Partners, and ZHD all developing design and collaboration tools on top. Rumour has it that ZHD is developing a configuration tool for modular buildings.
Ramboll
Paul Jeffries is computational design lead at Ramboll and is responsible for the SiteSolve development.
I asked him how Ramboll came to develop its own generative conceptual tool. He replied, “A few years ago, Ramboll set up around this process called the ‘Innovation Accelerator’, for different teams across Ramboll to pitch for funding, to build a business case to get funding. Three different projects came out of that, one of those was SiteSolve. We had a budget to self-develop the application and it gave us enough resource for a dedicated full-time team.
“Primarily we are using SiteSolve as an internal facing tool, but we are also selling it externally as well to our client base. We’re working out what best fits each client. Some clients are knowledgeable enough to just take the software and run it themselves, while others want us to use the software and steer it for them.
“We’ve been using Unity for the visualisation aspects of it. The core itself is our own kind of custom C# engine which is doing all the calculations. We have a link into Grasshopper and Rhino.”
Traditionally, internally developed tools lack the finesse of a proper interface and documentation. This can be fine for internal use, where the developers are on call to assist anyone who runs into trouble. However, selling software commercially requires a whole new level of quality assurance, documentation, training and interface.
For SiteSolve Jeffries explained, “Interface wise, we’ve gone further than we would have ever gone if we weren’t going to sell it. However, I think we’ve also found that actually doing UI and documentation is quite important from an internal uptake point of view. You save time on training, if you’d just built a better interface in the first place.”
Billable hours
In my discussions on coding with IT directors in AEC firms, the one term that kept popping up like a bad penny was ‘billable hours’.
Only a handful of firms have dedicated programming resources, or an architect or engineer dedicated to developing software. The key problem was the mindset of managers, which strictly adhered to the concept of allocating project billable hours to employees.
Many firms could not see through this traditional resource allocation methodology when it came to hiring programmers to develop its own tools.
In truth, firms that cannot get past that old way of thinking are not really aware of how important digital workflows have become, or how new entrepreneurial business models and revenue streams can be associated to management and use of the data they create.
Talking with Nate Miller, CEO of Proving Ground, he commented, “It’s interesting to think about an architecture firm, trying to carve out that budget and time to develop their own solutions. Looking for billable hours amidst the kind of significant investment that would go into building a platform, or any kind of script that works reliably, is significant.
“The business model of architecture and engineers, the construction industry is, in some ways, incompatible with the business model of running a software company. And maybe there is a clue in there, that in terms of if an architecture company wants to get into this space, does it need to change how it’s going to do business?
“When you get into the cycle of project work, you’re talking about billable hours and the need to get the job out the door, to go onto the next job. Buildings are treated as one off service-oriented outputs but when you’re developing a piece of software, it’s all about how you reinvest into that product. You make it once and then figure out a way to make money, sell licences or, if internal, maybe charge it back to a project.”
Newcastle’s own BIM supremo, Rob Charlton of Space Group, is most certainly a man who can see opportunities and is willing to change business models.
While predominantly an architecture firm, Charlton clearly understood the potential for BIM and software development, diversifying Space Architecture into BIM component development (bimstore), BIM Technologies (consulting) and more recently TwinView).
This latter venture is a really smart play for those architects that want to provide Digital Twins to their clients. As an architecture firm, Charlton recognised the value of the BIM data to his clients, the ongoing lifecycle of that and the fact there was downstream income.
TwinView was developed to easily repurpose that data and hand it on as a post design service. It is still possible to be an architecture firm, while at the same time being a software developer and create tools that benefit your own business as well as productising and commercially marketing those tools to others.
Futures
I have previously stated, many times, that the AEC industry is currently at the end of one generation of BIM tools and awaiting the next. Listening to the software developers, it’s all going to be on the cloud.
It’s worth highlighting Autodesk’s approach to development with its Forge platform. Historically if you wanted to build an application, a developer would either have to write a plug-in for the desktop application, or license a version (called OEM) to build on top of, to sell a complete turnkey application.
Over the last five years, Autodesk has been creating cloud components of all its core functionality. This means that a developer could ‘call’ Autodesk’s DWG engine, 3D viewing tool, cost management or document management engine on the cloud and wire them into their own applications.
Autodesk doesn’t just see developers using Forge but also its customers to develop their own cloud-based solutions by mixing and matching applications with Forge functionality to make project desktops or bespoke solutions. The idea of what an ‘application’ is capable of, is going to get a lot more fluid.
Conclusion
There is undoubtedly a reassessment going on inside of mature AEC firms in their approach to digital tools. Those that want to fully digitise their processes from conceptual to life-cycle and can’t find off-the-shelf solutions, are undaunted at developing bespoke BIM software themselves.
The barrier to entry in software development in the AEC space has been dramatically lowered, with the availability of low-cost, feature rich, platforms like SketchUp, Unreal, Unity, Blender, Forge, Rhino.Inside and Nvidia Omniverse. All built for speed and the ability to display vast amounts of data.
This app could be using internal resources, external consultants, or making strategic investments in up-and-coming software developers. While predominantly for internal usage, some are exploring productisation and even selling. There’s even the possibility of teaming up with enterprise investment funds or venture capital to develop with a commercial mindset from the start.
The one thing worth pointing out, is that there is a lot of reinventing the wheel going on, especially in conceptual design. Blox and SiteSolve are all playing in the same area as Spacemaker. Al (Autodesk), Hypar, Digital Blue Foam etc.
Most firms face similar challenges. Those that are capable of developing inhouse solutions might not realise other firms have also done this. If the trend to embrace branding, marketing and productisation of internal developments continues, there may be greater clarity as to who has developed what. There would surely be a potential to swap and share tools and save a lot of duplicated effort.
My last thoughts on this, concern the attitudes of AEC firms to software developers. Many do not want to be beholden to software firms which are attempting to own the process and increase prices. As being both the client and the consumer of the software development, who better to derive the feature set than the customer?
Custom tools from AEC firms
Foster + Partners Sandbox I/O
Built on top of Unity, Foster + Partners developed a conceptual design environment, to model, explore, simulate and analyse designs against a range of environmental conditions on desktop, iPad and in VR (pictured left). Only available within Foster + Partners.
Gensler Blox
Blox develops massing designs based on programmatic designations at the master plan scale. It provides preliminary budget estimates for construction, parking, and other project elements. It checks the building envelope, allows infinite usage mixes, and can incorporate live data. This can all be compared against, or driven by, the client’s brief. It’s only available to Gensler’s own design team.
Ramboll SiteSolve
SiteSolve is an algorithmic tool which can be used to dynamically model, manipulate and explore development sites, allowing project teams to collaborate, explore and visualise iterative design options.
The software is used internally at Ramboll and is also available for purchase.
Twinview
Developed by Space Group, Twinview is a cloud-based digital twin platform, for computer aided facilities management, with a dashboard for live sensors. It was developed by architects for both their own use and as a commercial product.
Bryden Wood PRiSM
Funded by the Mayor of London, Bryden Wood designed a modular construction analysis tool for developers. Based on various configurations and layouts, the Unity-based software provides property developers with a guide as to the best modular construction methods. It is free to download.
