143: ‘The Future AEC Software Specification’, with Andy Watts and Aaron Perry

A conversation with Andy Watts and Aaron Perry.

143: ‘The Future AEC Software Specification’, with Andy Watts and Aaron Perry

About this Episode:

Andy Watts of Grimshaw and Aaron Perry of Allford Hall Monaghan Morris (AHMM) join the podcast to talk about the need for a next-generation data framework in the AEC industry. Together they are leading the charge, along with many others, in developing the Future AEC Software Specification. The goal is an industry-wide dialogue to create a modern technology foundation that fosters competition in the AEC software market. Not a small task by any means.

We chat about the journey that led to the creation of the specification, the context in which the specification was developed, how architectural practices have reevaluated their processes during and after the COVID-19 lockdown, the Autodesk Open Letters and the media attention they garnered, the changes being made by Autodesk as a result, what the specification is, Aaron’s presentation of the specification at NXTBLD (for which a link to watch can be found in the show notes), the reception of the presentation and other feedback since, how one can get involved with the development of the specification, and more.

Overall, this conversation emphasizes the importance of industry engagement, collaboration, and the long-term process of implementing the specification to drive positive change in the AEC industry.

Connect with Evan:

Watch this episode on YouTube:

143: The Future AEC Software Specification’, with Andy Watts and Aaron Perry
Andy Watts of Grimshaw and Aaron Perry of Allford Hall Monaghan Morris (AHMM) join the podcast to talk about the need for a next-generation data framework in…

Episode Transcript:

143: ‘The Future AEC Software Specification’, with Andy Watts and Aaron Perry

Evan Troxel: [00:00:00] Welcome to the TRXL podcast. I'm Evan Troxel. And before we jump in, I need you to subscribe both on YouTube and to the audio version of the podcast, wherever you listen. It really does further what I'm doing here. This podcast takes a lot of resources and time to put together each week. And I hope you see the value in it and to be completely upfront about it. The higher, the subscriber count, the better the sponsors and partners I can attract.

And for you, the higher profile guests are attracted to a larger audience, which means I need you all to be accounted for 70% of the people watching this on YouTube right now are not subscribed. I can see it right here in the analytics. So, if you're not subscribed, please hit the button in both places on YouTube and in your audio podcast, app of choice, it is completely free to do so, and it will help the show be sustainable.

In this episode, I welcome [00:01:00] Andy Watts and Aaron Perry. Andy is the director of design technology at Grimshaw and leads the practice's global design technology team, overseeing digital disciplines, such as computational design, BIM, extended reality, urban computation, applications development, and environmental performance. He is also actively involved in academia.

He has taught at the Architectural Association and the University of Westminster, and has also lectured and critiqued at the Pratt Institute, Melbourne University, Dundee University, RCA, UCL, and others.

We are joined by Aaron Perry, who has been the head of digital design at AHMM since 2015.

With a passion for leveraging technology to elevate architectural projects he leads a group of digital and strategic specialists within AHMM's Digital Design Group.

In this episode, we discuss the need for a next generation data [00:02:00] framework for the AEC industry. Together, they are leading the charge along with many others in developing the Future AEC Software Specification. The goal is an industry-wide dialogue to create a modern technology foundation that fosters competition in the AEC software market.

Not a small task by any means.

Today, we chat about the journey that led to the creation of the specification, the context in which the specification was developed, how architectural practices have re-evaluated their processes during and after the COVID-19 lockdown, the Autodesk Open Letters and the media attention they garnered, the changes being made by Autodesk as a result, what the specification is, Aaron's presentation of the specification at the NXTBLD conference. And you can find the link to watch that in the show notes. The reception of the presentation and other feedback since, how one could get involved with the development of the specification, [00:03:00] and more. Overall this conversation emphasizes the importance of industry engagement, collaboration. And the longterm process of implementing the specification to drive positive change in the AEC industry.

This was a fantastic conversation with Andy and Aaron in person. And I hope you'll not only find value in it for yourself, but that you'll help add value to the profession by sharing it with your network. We have a lot of work to do so please help spread this one far and wide. And without further ado. I bring you Andy Watts and Aaron Perry.

welcome. Yeah, thanks for having us. Great to have you. Thank you. And we've just met, we've spent some quality time together here at the conference so far at the SPHERE, which has been an incredible, venue. but, the reason we're here talking about this today, and we are under a little bit of a time schedule, so let's just [00:04:00] get right to it, uh, to talk about the software specification and maybe before we jump into.

What and why, I'm way more interested in why, um, is, is how did it get there, maybe you both can just, a short, where you're working and what led up to this new part of the timeline. Yeah. With, with this, with the written specification, the presentation at NXTBLD So I guess I can probably start by saying, um, I was one of, uh, a number of architectural practices that probably at the beginning of the kind of lockdown process in COVID, we were very much kind of, uh, you know, looking at all different parts of kind of what we do, why are we doing it as, as practices.

And I think, um, there was probably just a moment in time in which some announcements were made about access to tools and costs and things of that nature, which, um, this, this peer group tended to meet. pretty often anyway to kind of share and collaborate what [00:05:00] was going on. And, uh, yeah, just the right moment in time with everybody having a bit more of a kind of an opportunity or maybe the energy to, um, acknowledge or recognize the kind of challenges that we were facing.

That group put together the Autodesk Open Letter. And this is the European Open Letter, then followed later by a Nordic country's Open Letter, right? Yeah. Okay. Uh, it had, uh, I think at the time, we didn't quite expect, um, anything to necessarily come of it. Um, but it did. And, uh, you know, we had some, some conversations with Autodesk in a forum.

And, uh, you know, some plans were laid out and some, some genuine changes were made on, from Autodesk's perspective. Was that based on? I've heard, and maybe this is wrong, so was there some surprise when they received that letter? Like, there were things that they were hearing maybe for the first time, or at least that was how it was presented back, or?

Well, I [00:06:00] think what was quite interesting is, you know, it was put out there, but then You know, some of the architectural media picked it up. So it was on, uh, like Dezeen, it was on, in the Architects Journal. And that I think was surprising in itself. Um, I mean, I, I didn't expect to be having conversations with Wall Street analysts.

Yeah. And that's two days later. Yeah. That was the other point is that, yeah, suddenly investors were saying, actually, could we have a chat about this? Is this something that we should be worried about? Um, and I think, you know, actually with, with the open letters and even with the specification, I think we've been somewhat.

We've, we've put it out there not knowing what to expect. And so actually to then be contacted by, you know, all these various people. And then actually there were some interesting conversations with Autodesk, which, you know, Aaron, you led on. So, you guys, you guys are just, you're architects, right? And we're used to putting stuff up on the wall and not knowing what to get back from it.

And I think there's. Large corporations where every single thing is [00:07:00] vetted, wordsmithed, and it's talking points. And so what I'm hearing from you is like, this is kind of natural for architects to do that. Yeah. And, and people who think differently than that don't expect architects to do that. Like they, they kind of expect it to go through a similar process and you would, you would very quietly and you would, you would do these things a certain way.

And it's like, well, we actually just put stuff on the wall. I, I, I think I heard something to that. Um, uh, I don't, you know, I think the gut reaction from Autodesk was we wish you had gone about this in a slightly different way. And our experience has always been relatively collaborative with Autodesk, but as individuals.

And I think what was different that time is that this was collective thought. And so, um, The parties involved, actually, not all of them publicly signed the open letter. So there were some really, really large firms who were involved in the entire process, but didn't necessarily want to put their name. To [00:08:00] it in the kind of first round.

It's, it's, um, I think sometimes the larger your business, the more your, your kind of PR marketing communication teams are kind of thinking a little bit about like, sure, do we want, do we want this? Yeah. Um, and so, uh, that went its path, I guess is probably the easiest way to describe it. And about two years afterwards, there was a, a question about, you know, do we want to reapproach it and kind of say, well, what's changed in two years?

Because two years is long enough for changes to licensing models, license, compliancy, um, enthusiasm, uh, right the way through to kind of maybe looking at differences in product roadmaps. And I think we kind of started that conversation and. Myself and Andy were having a bit of a separate conversation to that to that forum and I'd actually done a little bit of work to really set out what we wanted to see.[00:09:00]

And I actually, if you're interested in the anecdote, I, I, I wrote that on my phone. on the way to the airport. Um, it was, it was just, uh, it was just thought and it was just kind of the, you know, this is what I think we would want. This is where we are today. But you've been thinking about this a long time.

These gears have been turning and for you to just start to formalize it is now like, Yeah. So I think maybe as far out as 18 months prior to the presentation at NextEth, there was, there was a, there was a thing that existed and it was something I remember sharing with Andy at one point and It, I think it changed our minds about how we would take it forward.

You know, it wouldn't be us talking directly to Autodesk anymore. It would be about us kind of saying, well, look, Autodesk is a player to this game. And we want to make sure that we're setting this out to the industry. Um, and we benchmarked it with some of the people who had created and organized the open letter.[00:10:00]

We benchmarked it with some European kind of counterparts and some, some people in the Nordics. We spoke to the American Institute of Architects, large firm Roundtable and the big practices there and kind of say, you know, are we missing something? Does this make sense? Would you add something to this? Or, um, and interestingly, I think a lot of the reaction we got was we completely agree with this.

This is, this is what we've been thinking about, but never really. Put together. I can't, I can't tell you how many times having sat in on that group, um, for a couple of years, how many times we've come in with kind of this, the way we think about something and we don't expect others to have the same feelings or think the same way about it.

And we are often surprised when there is total group. Like, yep, we're all in agreement. We all feel like this and everyone's, it's kind of like this. Yeah. Sigh of relief. Like, okay, I'm not the only one or, or I'm not crazy. Right. Um, and, and it, I think that it, it, that keeps happening. I think that's really interesting too.

And it [00:11:00] takes that vulnerability of putting it out there of a designer, right, to put something on the wall and say like, what do you guys think? Yeah. And, and maybe you have to defend it and maybe you have to justify it and maybe it can speak for itself, but it's like it again, I think this is a very architectural.

And I just, I don't think there's anything really, really special about that, but I, but I do think it falls in line with the way we operate and the way we think about things. And like, this is a project, right? And, and there's been many times on this podcast and my other podcast, where we've talked about just stepping back and, and taking, you know, surveying the landscape And then designing a way forward for ourselves, we don't tend to do that very often.

We tend to do that for our clients all the time, and we get so stuck on providing that as a service for others that we rarely take the step back and do it for ourselves. Yeah, I think we, inherently, we're [00:12:00] very reactive beasts, right? So, we're given a brief, we react to the brief. We're given feedback, we react to that feedback.

And I would say that, you know, The open letters, when we did those, they were a reaction. They were a reaction to what we, we saw coming from Autodesk. And, you know, that had an effect. It had, um, it, it built up some interesting conversations, but I think, you know, we, I think we were on the, the verge of writing another open letter.

And I think Aaron and I on the side were just kind of screaming a little bit thinking, no, we can't do this. So that's why, you know, we put forward an idea to the group, which. Resonated with everyone that actually, why, why don't we move from this reactive footing of, you know, responding to one provider to actually a more proactive footing and saying, Actually, can we, can we be totally open and say, you know, this is what we want.

This is how much we pay for our software every year. If you, if you tick these boxes, take our money. Yeah, we [00:13:00] don't want it for free. We want to pay for it, but we want to. We want the best possible solutions. And for that, we needed to put forward our vision of what that best possible solution was going to be.

And that's what the specification is, basically, right? I mean, and so what's interesting to me is you've changed the, the narrative to say, like, let's create an area for competition to happen, right? Rather than everybody capitulating and saying, well, there is the only, only one way to do this, right? No, there's actually.

And there's so many startups out there, there's so many other technology providers who have been fighting and fighting and fighting to find ways to differentiate themselves or to be, be a main player, right? And it's, and it's difficult when, when there's so much energy and dollars being focused into one entity to compete with that.

And so by you saying, no, like here's, here's what we, here's what we want. Here's, here's how much we already spend. So there's. There's actually a lot of money there to be had if you're willing to [00:14:00] build that, take it, take the money, like that, this is what we pay for, we're, and we're willing to pay for it, I, and I think this is also a shift in the, in the narrative a little bit, just a nuance, which is, you know, architects in my, in my view are very cheap when it comes to this stuff, but when you look at these numbers, they're huge, they're, I think what Martin said, something like 70 percent of the outlay of the IT is, It's for Autodesk, of their budgets for, for a lot of these large firms.

It's a big number. Yeah. I think that's about right. And there was a, a line in the sand that was NextEv. And, uh, Martin Day said, you know, we, we, next, um, next build. It's an annual thing. It happens all the time. It's, it's, it's appealing to a mass market. I'm going to, I'm going to try something which is called NextEv.

And it's all about development. And I think he knew. that since the open letter, more startups have come out of nowhere, [00:15:00] more interest has come out of that, more money has been pumped into these, these startups. So I think he was right place, right time to put together NextDev as a one day conference of A room filled with 500 people who were billionaires, investment funds, uh, venture capitalists, all the startups, some designers, some architects, some engineers, et cetera.

It was a good mix. And he said, Hey, do you want to, do you want to maybe present this? Uh huh. Um. And there wasn't a huge amount of time for us to He set us a deadline. Yeah, that became that line of sound. That's what architects are good with. That's actually what you need to do something. I mean, this is it.

This is, you know, Aaron and I and everyone else who was involved, we've got our day jobs and they're fairly significant. Jobs. Yeah. Um, but actually to do this on the side in our own, your side hustle. Yeah, exactly. . But, you know, we needed for the good of the industry though. Yeah. [00:16:00] We needed that focus point.

We needed to say, okay, this is our, this is our goal, which was June for the Mm-Hmm. presentation and then July for publishing. And you know, I think Martin probably saw that we needed that. It was really quite good. Mm-Hmm. . Yeah. And so, uh, that, that deadline. focused everybody, um, we had some really incredible input from some amazing engineers and architects in the last maybe 30 days of the process, which, um, probably added 20 to 30 percent to some of the work we'd already been doing.

Um, and, you know, really just brought in some, some slightly different ways of thinking about things that I've been really grateful for and I think really helped and just made sure it was a, it was a wider representation. You know, you talked about, uh, you know, the AIA large firm round table. yeah, it's not uncommon in software development to be asked, how would you prioritize this, this list? And that was definitely something we, we, we were doing towards the [00:17:00] end when, for example, speaking to the American, um, group that we're contributing. . Um, I remember vividly one of them saying, well, you know, existing buildings and responsible building design is interesting, but you know, in London you have buildings that are 400 years old and you know, and we don't have that over here and we don't have that same challenge.

So it might not be at the top of our list, but we can recognize it's important and we recognize it. And so again, that was all part of the benchmarking process is to make sure that we were representing an industry. Mm-Hmm. , because we knew that. And I guess we hoped that the specification launch, that presentation, uh, would try and move the needle.

Mm hmm. Mm hmm. It's interesting just walking around here and at Autodesk University in Las Vegas, how many, in preparation for this, just people like, oh, are you recording here? And I'm like, yeah, I'm going to talk with Aaron and Andy and talk about the software specification. Have you heard about it?

They're like, nope. [00:18:00] And, and so, I mean, that's, that's what I want to do with this, is get this out to more eyeballs, right? Because I think, uh, people just need to know that this kind of thing is happening and whether they want to be a part of it or not. And, and so, I mean, we'll, we'll, we'll do a little call to action at the end of how people can show support or, or get involved or things like that, but it is surprising to me with, even with the success of that.

Next dev presentation and the LFRT's involvement from, from the US side and the firms on here that it's still, there's an air of like, not knowing that this exists yet. And so, and so to me that I think it's important just to read, to put this out there in the beginning is to say, like. We can't expect everybody to, to understand it, let alone know about it even.

Right? Because, and I think this, this goes back to things I'm seeing here, which is like, everybody's drowning in information. Right? [00:19:00] And, and to read a document, a multi, how many pages is this document right now? Well, uh. It's, it's a few, I think it's, you know, if you were to look at a PDF, it's about 16 pages, but you know, it's now on a website, so it's about, it's 10 subjects is what we've kind of brought it down to.

So it's not huge, but at the same time, like getting somebody to read something more than a social media post now, it's really hard. Yeah, I remember Martin the day before NextEv saying, Hey, you've got 45 minutes. And I was like, I'm going to need an hour and 20 maybe? He told me that. And, and that was.

Cutting it down, cutting it down, cutting it down. It was a very, very tricky, um, because it was providing context to some really major changes in thinking. And, and, um, I needed to get the pacing right. I needed to get the delivery correct. I needed to not assume that people knew what I was talking about. I was presenting to an audience of different personas from again, venture capitalists.

Try and understand why we [00:20:00] need this. Software developers who. Maybe had their own roadmap and we were kind of saying you might need to change your roadmap based on this. Um, and again, a bit of a call to arms where actually directly afterwards we had main contractors walking up to us. We had, um, engineers walking up to us saying, how do we, how do we be involved?

And I think maybe it's worth talking about the, our objectives because you could walk around. What's this university and people may not have awareness of it. And I guess that's always going to be the case. There's always going to be people that weren't aware of it. I mean, we kind of knew that and I'm not sure that our primary objective was for the global industry community to know about it.

Um, I think from my perspective, and it'd be interesting to hear if there's anything else from, from others, but. For me, it was talking to that audience at that moment in time. It was, it was influencing somebody in that room with a checkbook who was about to sign an investment round, you know, or [00:21:00] for them to understand that there is an industry out there where that industry is standing on stage saying, this is what we want and we want to pay for it.

Because I don't know how often that happens in automotive, you know, and so that was a That was an initial objective. I think we all know that nothing was going to happen a week later. Right? There was no big event that was going to happen to just magically achieve the items in the specification. This is a long, slow process.

It involves changes in direction, it involves changes in roadmap, it involves projects being spun up, teams being created within different vendors. Undoing what they're already doing in some cases, potentially. Yeah. And, you know, I think we Even before it was launched, we were having to think actually how we could having to 11th hour, we changed the name from the future design software specification to the future AEC software specification to actually think, actually, you [00:22:00] know, this was put together by architects, but, you know, that feels very limiting.

Yeah, you know, we need to actually be looking at this as an industry, as a supply chain. So we did that and I think we were pretty pleasantly surprised. The immediate reaction, you know, beyond those in the room when Aaron did his amazing presentation was engineering firms reached out. All the major players within the UK reached out and said, we need to be part of this conversation.

And since then, you know, there's been. Some contracts have got in touch to say, actually, you know, this resonates with us. We've seen a bit of traction in the US. Um, we're part of a research consortium in, in Sydney, in Australia, where they're actually using the specification as their reading list, which is fantastic.

You know, it's funding 21 PhDs across, um, a range of subjects, but all trying to align with the spec, which it's amazing. But I think to your point about, you know, people not necessarily. Having heard of it, I [00:23:00] think we're, at this moment in time, we're like one or two degrees of separation from NextEv. Yeah, yeah.

And I think, you know, we want to be reaching three to four to actually start to put this out a little bit further. And messaging and communication needs repetition. Yeah. You might hear it the first time, but it doesn't land anywhere. You hear it the second time, the third time, and it starts to stick. Yeah.

But I do want to go back to you delivering this in person to a group of You knew your audience, right, who was going to be there in the room. How much more effective do you think this was by delivering this in person versus putting up a post on a website or something like that? Respectfully, anyone can put something on LinkedIn.

And it might get shared, it may get likes and reactions and so on. Being in person and being able to look people directly in the eye and create an emotive and creating empathy for what it is we're trying to get across. [00:24:00] Um, yeah, we, we literally had venture capitalists walking up to us afterwards and saying, I don't normally feel empathetic or kind of, you know, And again, to some of the investments I'm trying to make, you know, that's not my primary objective.

I want to do that. I want to be involved in this process. I want to help you. And again, you know, it has been lots of surprises afterwards. Andy talks about, um, you know, construction firms or main contractors, we, the one that I will always remember, and I won't mention their name, is somebody coming up to me afterwards and say, we have a multi million dollar enterprise agreement with Autodesk and We, we understand the limitations of what we can do outside of that.

So how do we get involved with you guys without them finding out? You know, it was a kind of, uh, clearly people were, I think, more moved by the presentation than maybe just reading just a, you know, a document online. Yeah. Yeah. I mean, the writing, [00:25:00] they say, if you Don't send something in an email when it could be done over the phone, because somebody couldn't read it so differently.

They could take it in a much worse way. They could take it in a much better way than you intended. Because it's hard to express through writing, right? And, and, I mean, that's one of the reasons we, I do video even. It's just because, and this is the first in person one, so that's really cool. But, uh, but, but this, but this connection is.

Better. It is different. Yeah. Uh, and, and I feel like, like as architects, again, like it's our job to connect emotionally with people through architecture, right? Like that's what makes architecture, architecture even, right? And so I think for you to have delivered it in a way that really speaks to somebody, I mean, again, this all falls under this.

My observation of Mm-Hmm, , okay. This totally makes sense you guys being architects, but at the same time, like that's a different [00:26:00] experience than people are used to seeing. And so I think it that also helped make a difference. Just, just presenting it in person, connecting with people and, and really having thought through it ahead of time to, and cut it down and edit it to what you could to, to make those key points.

did make it an impression on people that you otherwise could not have made. And so I, I think that, wow, well timed, well influenced by Martin. Right. Uh, but all of that kind of is, is working together to create the energy behind this. Yeah, absolutely. And I think, you know, we've, we've curated the conversations we've had with software vendors afterwards.

Um, You know, we, we kind of expected that every single, uh, startup was going to get in contact and say, I already do all these things and, you know, something to that effect. Um, but we have definitely [00:27:00] found the communication coming from certain software vendors to emulate some of the language and some of the terms we've been using.

Um. And so I think, I think, you know, they're all aware of it. Yeah. They understand it. Yeah. They've got into it. I've had one on one conversations and I've had kind of more formal conversations with different vendors. Um, I think they've all been grateful for this to exist, actually. I don't know that it's been received in a, in maybe the slightly, possibly negative way that something like the open letter was, was, yeah, received us.

Well, I think, you know, this was. It's always aimed at being a much more positive endeavor. You know, this is not saying what we hate, it's saying what we want. You'll actually get farther if you change that tone from complaint to a what if kind of a thing. Yeah, and I mean, I think in the context of, you know, where we are this week as well, I mean, we've just come from the futures briefing and it was interesting to hear that a lot of the language that was put forward as [00:28:00] part of Aaron's presentation was actually shining through as part of, you know, what the roadmap is for, for architecture.

Within Autodesk and that was, that was encouraging to see because I mean, we, we, we talk about startups, but, um, I think when we put this out there, it was very much with the intention that we're looking to anybody to build this. Yeah. You know, we're not discounting the, you know, the, the Autodesks, the Bentleys, the Nemechecs of the world, you know, anybody could be part of this.

We're just saying what we need from our tool stack. Mm hmm. Um, and so it's actually been encouraging to see that. Even the big players are starting to, you know, whether, whether it's a conscious concerted effort or not, or whether it's, you know, through attrition, they're just kind of, um, you know, that they're starting to include it as part of their, the way that they talk about it, because, because it was put together as an industry representation, not just one or two companies, you know, it's, it's [00:29:00] been a much wider range in conversation.

I think they're thinking, okay, to That's a client base, you know, that's not just a client, it's a client base who are saying this. And it's actually really encouraging to see that coming through. Well, do you want to talk about the document and just kind of give an overview? I don't, I don't want to go through it.

You, I will link to your presentation and everybody will have to sign in to Martin's website to watch it, but it is freely available. And so we don't need to rehash all of that here, but I do want to give people a taste of what we're actually talking about here, because this has been a great setup for all of that.

And, and why. This happened and so now let's get into what it is. I think it would be good. So just, just kind of a high level overview. Again, I'm going to encourage people to click on the link and look at the 10 points. And then you actually have a link in there to also read the document that I said a Google doc or something that you've shared with everybody to, to look at.

But [00:30:00] so we'll do that, but go ahead. Yeah. So the specification, um, uh, is a meaty, wordy. Document that needed some contextualization and, you know, some explanations between the lines and that's really what the presentation will do. So I think to anybody listening to this and watching this, there's those are your options.

You can you can kind of read it and you can also probably go and watch the presented version of the same thing. So the specification is broken into a number of different chapters and sections that are relative to kind of key areas and the primary. underlying part of that is something that we make a reference to as a data framework.

And so we are talking about a centralized, cloud based, cloud enabled, um, you know, web orientated, granular data at an entity component system level where It is outside of any desktop application, and it is not [00:31:00] tied to a specific file format, or file type, or vendor, whatever that may be. And so, you know, we made references, or we made parallels to Universal Scene Description, and how open and efficient the media and entertainment industry will become, and already is.

By removing proprietary file formats that are kind of vendor locked or tied to specific applications and, you know, using that as a parallel to kind of say, this is going to be really appropriate and useful for our industry, but actually maybe not the USD bit because you can still have multiple versions of the USD file, um, and it's still an offline file that I'm kind of chucking backwards and forwards.

So, um, we are talking about, Uh, a more equivalent of kind of a, uh, a GitHub style environment where multiple coders are, uh, compiling and committing their code into a central resource and central data and, you know, being the project, correct. [00:32:00] The architectural, interstructural, inter MEP, inter building it, inter operating it.

Let's do away with application tied proprietary file formats. That was just such a, just a critical topic, which actually is referencing. Every other section within the within the SPAC. So what's the benefit to that? Just so just because I think Depending on where somebody's coming from when they hear that when they hear github when they hear, you know database Data lake whatever it is versus file like somebody could could be hearing this for the first time and what do you mean?

Like everything's a file, right? Yeah, so I I guess if if you were to look at your own workflows within your own business There's going to be a preference for you to use the right tool for the right job. And unfortunately, sometimes if you're a slightly smaller firm, that means you might not always use the right tool for the right job.

The tool you have. You use the tool you have or the one that's easiest to move [00:33:00] information, whether that be geometry or data within the ecosystem of the project. Um, the larger firms, the likes of, uh, Grimshaw or, or anybody else, they're more likely to say, well, we want to use the right tool for the right job because we want to be a bit more creative and we want to, you know, think outside the box.

And they'll pay for the specialists, the people, the tools, the plugins, the code, the, the, the extra stuff that you can do to try and bridge some of those gaps. But that is an expense. Um, And, and to some extent, we waste a lot of time, energy, interest, uh, and money just, just trying to solve those problems, which, you know, to some extent wouldn't happen or wouldn't be there if we had a universal data framework where information can be accessed by different parties in different tools.

And one of the, one of the most amazing additions, I think, to the specification came from, um, somebody who, who, [00:34:00] who helped us kind of audit right towards the end. And she helped us start to think about equity. And to some extent, a lot of us are bound by expensive tools with a significant skill barrier to be able to interact with some data that exists that we're trying to collaborate and co produce.

Now, if you take away the application and you make that, you expose that data in the web. That creates equity for such a more diverse range of stakeholders, small firms, large firms, people that just, you know, haven't got the skills to be able to open up a giant model and just to look at one package of information, like a door package, for example.

And so again, this whole idea of moving away from large monolithic products and, um. Offline file formats where we're kind of chucking them over the fence to each other. Um, which we used to do in a messenger bike with drawings or USB sticks or the cloud. FTP. Yeah, but we're still chucking stuff at [00:35:00] each other rather than kind of it all being there for us to collaborate on.

I mean the whole idea of it being on the web, like that, that is the idea of the open web, right? It's like no one entity owns it and it, everybody has access to all of this information. You can. create links between disparate pieces of info, like the whole idea of hypertext, hyperlinks, HTML underlies kind of a lot of these ideas, but we don't really see it like that anymore, right?

Like, for some people, the web is Facebook, right? Um, so just as an example, but it's, it's interesting to me to kind of go back to these original ideas of what the web are. And that's kind of what you're talking about here with, with like you're throwing code. onto a server that describes at the object level, you know, with metadata, and that can be passed to any application that is willing to read to it, read from it, and write to it.

And that could be any tool that you want to use. It could be the right tool for the job. It could be the only tool that you have, etc. But it's going to [00:36:00] be able to communicate with this repository. That consultants can also get into, so not just architects, but also the other stakeholders on the team, even owners, even contractors, everybody.

And you don't have to have one piece of software to read it, right? That's a, that's a key piece of it as well. Yeah, I think that's, you know, that's a critical piece that underlies this is that at the moment we work with, you know, silos of data. And, you know, even moving between those, which, you know, as Aaron described, it has its own cost.

You also lose a lot, you know, the, you know, one piece of software may not look at things in the same way as another one. So, you know, we were, we were very much influenced by conversations that, and presentations from, from Greg Schleusner that, from, you know, Next Build a few years ago, where, um, you know, he, he's kind of, you know, planted this seed in our mind that, you know, can we actually just be, you know, talking about a single [00:37:00] data format, at which point, You know, our software products just become readers and writers of that.

And that, that becomes a critical kind of underlying part of the specification. You know, we're not looking for one piece of software. Because that's been a question that we've had repeatedly. It's, you know, it's going to take ages to build this software that does all these things. Like, that's not what we want.

We want a series of tools that are, that are nimble, that can actually do what we need, but they all speak the same language. That's, that's the critical point that we're looking for. There are people in firms who only want one tool, and then there are other people in firms who want, Their choice. Mm-Hmm.

using the right tool for the job and, and different firms are set up differently, but it's interesting to me to hear you say that, but there, there are people out there who are like, can't we just do it all in one thing? Yeah. And so, and I also think of the small firms, right? Who are, who are. Less fortunate to have the revenue to purchase all of the different things to do [00:38:00] the design work that they want to do.

But, but what you're saying is it doesn't matter. The flip side of that is those small firms don't need to buy the monolithic, really expensive product. Yes. If their only interaction with the data could be a lightweight tool that helps them, you know, integrate exactly what they need to do. Yeah. And, you know, coming back to what's the most common questions we get, probably the second most common question we get was like, isn't that IFC?

Hmm. Um, Yeah, good point. Let's talk about that. Yeah, so, it, it is something that we've talked about as kind of parts of next steps of, of, you know, what happens around the data framework, because we need to unlock that first before anything else is kind of achievable, so, um, IFC has been around for a while.

It is mature. It's not perfect. But it, in terms of a library, in terms of a, um, a dictionary, The multiple tools, multiple software and all these startups have kind of said, well, where do we, where do we begin, um, that dictionary, that library of, of, okay, well, [00:39:00] in this tool, it's a level in this tool, it's a story and you need just that kind of, um, common dictionaries between these products.

I think IFC is a great place for us to start. I think it's challenge is that it is still currently. An offline pro, you know, file format basically. Yeah. Yeah, that's, and so it's not quite delivering on the other part of where the specification gets into this, this data framework, because we need that to be web enabled.

We need that to be cloud enabled. And you know, last 10 years ago when IFCU was kind of evolving and maturing, maybe the web processes and technologies wouldn't enable. So, uh, we actually have meetings next week with technical directors at IFC to kind of understand how we can maybe bring this all together, because the last thing we want to do is create yet another data standard.

Right? That's not our objective. And there are a lot of tools that, that use IFC. Yeah. Right. And for them, it might be a big mountain to climb again to, to reinvent [00:40:00] something new or to impose something new into their system. So if there is a way, If there is a way forward with that, it does seem to make sense at least as a place to start.

Yeah, absolutely. And so, uh, to the rest of the specification. So, uh, we then went into talking about hybrid compute. So, um, again, many of the tools that we currently have access to at the moment are desktop products that are 10, 15, 20 years old. Um, I don't think there's a startup out there now that would be looking to make a product in the same way.

Um, things change. Um, and one of the reasons that we're really kind of making a point to that is, uh, post COVID, uh, I think I first heard this quote from Andy and it sort of stuck with me. We went from having an office to 500 offices because everybody worked from home. Right. And so, um, you know, the concept of being tied to, oh, I can only contribute to design or, you know, construction if I'm at a desk with a desktop computer next to my feet.[00:41:00]

Um. That's not the world we live in anymore. And so, you know, we, we talk about hybrid compute within the specification as, as ensuring that people have access to information. They can contribute to that information because it's in the web on a hybrid compute platform, whether that be still, I need to do loads of heavy lifting and I need a beefy desktop computer under my desk, or I just need to review what my team has created, I'm going to do that on my iPad, I'm going to do that in the web.

So Hybrid Compute for us was, again, built on the concept of the Data Framework, and because the Data Framework would be there, it would enable us to be able to move around on different platforms, different hardware, in order to access, interact, measure, you know, whatever that kind of, um, that workflow, that persona might need.

They'd have the access and those, those barriers about monolithic tools or that the skill level required to be able to do anything with them or simply just waiting 20 minutes to open a file to just read one parameter, right? Those kind of go away when we think about hybrid, uh, hybrid compute. [00:42:00] And then we talk about context and scale.

So for us, what we mean by that is we are only going to now deal with even more quantities of data related to projects. It's like, it's kind of hard to say. I mean, you hate to say that, but it is totally true. I mean, especially when you think about it in this new way, because now there will be the need to apply the metadata to absolutely everything so that everything can read it and write it.

Yeah. Right. So it is only going to get more intense. Correct. And, uh, something just very simple. Uh, the data footprint of point cloud laser scans for existing buildings that are much more of a focus about how much we can retain of an existing structure. The data footprint of just the point clouds alone is ginormous.

Yeah. And so we need tools that can understand it. a much greater level of context, level of detail, you know, being able to get right in there and seeing a much greater level of detail than we've had as a kind of a barrier [00:43:00] today, because the tool performance just drops off completely if we're trying to achieve that level of detail.

Um, and so for us, that was really about, you know, registering on people's radars that, that this is a really important thing for us. And that suggests the future is digital twins of, you know, Occupants and owners of the built environment needing that level of detail in order to understand the asset that they're trying to manage and trying to exist.

So, yeah, context and scale is a big section. Uh, it then moved into, um, designing responsibly. Um, so all the tools we use on the market today start from a white blank open screen. Um, the reality is, at least, you know, for a practice like ours, who, who works a lot in central London, again, you know, we're dealing with existing buildings that are complicated, that are difficult, there's data that's already available about some of those, um, and, you know, again, at least for [00:44:00] my firm, we spend, you know, months analyzing What of the existing building fabric can we retain to reduce the, um, the carbon footprint?

Mm hmm. And at one end of the scale that might be some really light touch work and at the other end of the scale that's all demolition and we're never at that end, you know, we're trying to find out Okay, sure. How can we, how can we make changes and implications to this project and to this building that will give it a longer lifespan?

You know, it's more appealing to the market who will then want to live or to work in that building, but also um Minimizing the, the, the impact in terms of, uh, building fabric that is just being lost in the process as it's being demolished, or maybe carefully being recovered. So for us, this was a big piece about how can we use the tools to evaluate the design process?

Because there's not a from a blank page, there's not a tool on the market that understands how we can try and evaluate The existing condition, um, retain as [00:45:00] much as possible of the existing project, but also reducing that kind of carbon footprint. And I think one of the analogies that Andy used quite a lot is if I see one more architecture firm that's created their own embodied carbon calculator, I'm going to go crazy.

But that exists because no software vendor on the market was in front of that. Yeah. And so many firms like ours created them. Yeah. You know, we, we see that across a lot of the challenges, you know, interoperability when we talk, when we go back to talking about data, you know, everyone created their own interoperability processes.

We're now seeing it with carbon. We're also starting to see it with a further point though, Aaron I'm sure will come on to, which is the DFMA and industrialized construction, you know, proliferation of tools around that at the moment. That's a response to us not having those in our tool sets at the moment.

Yeah, and as Andy says, the specification goes on to talk about modern methods of construction, prefabrication, offsite, and, um, you know, we, we see [00:46:00] companies that are operating in that sphere, finding it really tricky, and we see every other week, the media picking up on a, yet another modular constructing company kind of struggling, et cetera.

Now, it is a very complicated issue, and there are so many factors in play, but the thing that really hit home for us is whilst. designing a scheme, if we can have no context as to the constraints of any prefabricated or modular systems in the tools that we're using, we will continue to make things that aren't that buildable for prefabrication or off site development, and so we're forever just going to keep falling into the same problems and the same traps where we create something, it doesn't work, we go back, uh, or we try and ask them to make something and they're kind of saying, well, we'll try, but it's not, it's not what this is designed for.

And so a big piece here was saying, well, look, for the volumes of, of building what needs to be built and doing that in a careful and considered way. [00:47:00] Um, we as designers need to enable our construction partners to be efficient and to be effective. But if the tools on the market that we have at the moment don't even understand prefabrication, we can't reference a manufacturing level of detail for a prefabricated modular pod bathroom even in a residential scheme.

We can't bring that level of detail into the tools we use whilst designing. We're forever going to keep making these mistakes. I can't help but think of two things as you're going through this right now, which is all the tools are based on the traditional ways of project delivery. Correct. And that goes all the way through construction, right?

So they're reacting to the way it's always been. And then there's a lot of talk here about the future of work and the future of technology and the practice. And at the same time, Andy, what I'm hearing you saying is like the technology is also just reactive to. Practice, even though there is so much marketing and promotion [00:48:00] being put into the future of Yeah, there is still, like the actual tools that are being delivered are in reaction to the way we've always done it.

Right? And, and so we are in this weird. zone, once again, where you, by putting this out there and proposing what we need, why we need it, how it ties into all these different pieces, including manufacturing, including sustainability, including adaptive reuse and data sets, and that's a game changer for how everybody's approaching this, right?

It's also in how architectural firms are approaching projects, right? Because the landscape is changing. Not every solution is a new building. Adaptive reuse needs to happen a lot more. And we need repeatable, modular. We need and, and, and for all of this. Yeah, I mean, that's also thrown into stark contrast because we as an [00:49:00] industry have a huge responsibility.

And so we need to, you know, be able to do this a lot. Faster and a lot more efficiently because, you know, I think there is a risk that, you know, some of these incredibly important considerations like um, sustainability and, and you know, carbon and things like that. They may be pushed to one side if we're not able to produce things as efficiently as possible.

That's why, you know, there's a huge spectrum of things that actually need to be happening at the same time, which was, you know, really in the back of. I would say both our minds when we were putting this together is there is definitely a sense of urgency around this, you know, this isn't just please make our lives easier is actually, it's like, no, we need to do this.

Yeah, absolutely. You have a responsibility. Right. Yeah. And I guess that takes us into one of the final sections really, which is specifically about automation and intelligence. And so, um, all of our firms today move on to that next project. [00:50:00] bringing very limited, if not no prior experience or knowledge from the projects we've done before in the digital sense.

You know, uh, we, we have those much more experienced architects that will move on to their next job and they'll know the rule of thumbs and, and, you know, they'll know the, the basic parameters that we should be taking into account. But we all start from a white, blank screen as we start that next project.

And so, you know, part of the specification goes into then quite in a bit of detail about automation and intelligence. How do we bring through that experience? How do we, how do we augment the architect? By bringing through some of that knowledge on a previous harvesting, that previous work to inform the next Exactly.

Right. And one of the, uh, one of the analogies that I think got cut as part of trying to save time for the, for the presentation was, you know, we work on tool, uh, commercial buildings in the city and, um, you know, the analogy I. Provide is that there's a central core to the building with a certain number of lifts based on how tall the building is.

There's [00:51:00] a certain number of restrooms or toilets based on the number of desks or, you know, the headcount that you might have on that floor plate. And sometimes we might get a question from our clients saying, Oh, Hey, we, if we did something special with the massing and, you know, could we, could we get a bit more out of this in terms of interior area?

And, you know, the most experienced architect on the project knows. That if you make the building slightly bigger, you now need more toilets, which means the core is bigger, which you have actually a deficit floor area. But only the most experienced architect in that team knows that. Right. Everybody else is now spending two weeks trying to do the analysis and the study and recreate.

Everyone else says yes without thinking. Yeah. So, you know, how do we, how do we. retain that experience and that knowledge through configurators or through tools on a kind of project by project basis. And so that's what we're talking about when we, when we talk about things like automation and intelligence, but also, um, mundane, repetitive processes.

I think, I think back to, uh, you know, we, most of what we do. Yeah. I [00:52:00] think that's when we, we were the. involved in the process of moving people from 2D CAD to, to, to 3D object based modeling. And I've always annoyed a few people with this analogy, but, you know, moving from the drawing board to 2D CAD, whilst, you know, it was different, you were still drawing exactly what you wanted to see.

And when you moved over to object based modeling, You kind of had everything presented in front of you and then you were trying to control the, you know, what you did or didn't want to see. And, you know, I don't think there's an architect now that looks back to manually having to create door schedules and itemizing every single door by looking at a plan and then updating it on an elevation and then updating it on a, on a, on a, you know, spreadsheet.

I don't think anybody looks back at that and going, ah, I missed those days. But at the time people were saying, oh, we might need less stuff because these are all automated now. And so that has kind of always been part of when we talk about automation intelligence is saying, well, do you want to study for seven years [00:53:00] and get in a significant amount of debt to join an architectural practice to manually do something we have done hundreds and hundreds and hundreds of times before?

Or would you rather join an architectural practice and be creative and have an opportunity to improve design? Yeah. The value of an architect. is what you're talking about. And we sell that short so often because of the needs of production. And the tools are the problem here, when it comes to that. I think the nature of the, the nature of where we've got to, and, you know, I think digital comes into this a huge amount, is, you know, the tools we use, you know, a ridiculous percentage of our time is on documentation.

I'd say there's then another. And I think the most decent proportion of the remaining time is on actually moving data around. And there's probably a very thin sliver, sliver of our time which is actually on design, ideation, analysis. The things that we, that you [00:54:00] associate with the role of an architect, the role of an engineer.

And I think that we really need to change that pie chart of time. Well, we're actually incentivized to spend less of it on a project than Then we should, I'll just put it generally. Yeah. Right. It's like, because our fees are the lowest fees. I mean, and I'm not talking about every firm, obviously. Mm-Hmm.

There's some firms that are killing it in this regard, right. . But then there's other ones who are like, they're really competing on hours. Yeah. And so you're incentivized to spend less time on it, right? Yeah. And so to only have a sliver of time to, to. provide the value of what we do on a project because we compete on drawing.

If you step back and you survey the landscape, that does not make sense. It doesn't make sense at all because the value is not there. And one thing we, we didn't want to do with the specification is, uh, really confuse or turn everybody upside down. Afterwards and after the fact, we can have this conversation, but the entire value proposition in [00:55:00] architecture is broken.

And it will be something that the whole industry will need to address. We'll need to leave our pride at the door and we'll need to have a serious conversation that if we can bring automation through to mundane processes, we can deliver projects in a more efficient and effective way. We'll be billing less hours.

And if you do bill by the hour and all of a sudden, you know, you're doing production is 45 minutes. How do you charge by the hour? And so we need to have a completely different conversation about how we as businesses work. Um, to some extent, and again, without trying to, to even further confuse anybody or, or cause concern, the data framework, where moving information between different stakeholders.

I might have somebody at the moment that I'm working with who's helping me with a internal door package. and they build doors and they're going to be the party we move forward with. And right now, at least in my experience, everything is about risk [00:56:00] mitigation. It's about how do we bring construction package experts in earlier so that we can avoid costly mistakes later and we can kind of design around them and design them out.

And so again, using this analogy of this subcontractor I might be working with on the door production, if I can Exchange just the data they need about a package of doors so they can see the geometric representation, the parametric constraints of those items, and then the sort of specification of those in terms of acoustics or fire.

If they can have access to just those data points, they can co author that with me and commit that back to me and I'm accepting that change. Do I need to do 300 drawings? Right. I've had this conversation with Adam Wilbrecht at CONCERT, which is like a blockchain for AEC, smart contract kind of stuff. And, and he, this whole idea of, what's the intent of me sending this package to you?

If you're a door subcontractor, I'm sending it to you for this reason to, to look at the [00:57:00] doors, but I'm going to send you more of the project than just the doors, right? There's context involved for you to understand it, but for us to granularize. The reason why we're sending it to you, and what we're sending to you, and why, and for who, and by when do I need a response.

These are the kinds of things that all are completely different to the process today. Or maybe even future state, like what we, what we see as possible, then what we're currently dealing with, right? Because now we just chuck models over the fence, right? The whole thing, and then it's left to the engineer to sort through it and see what changed, try to figure that out.

Now, there are more sophisticated ways that people are operating, but for the most part, I would say that 80 percent is probably like that. It's like, we said we'd publish the model every Friday, here you go, and it's like, good luck figuring out what, what we did, because we don't even want to, we don't even have time to talk to people and tell them, right?

So, it is interesting to [00:58:00] me to think about, like, again, if you're, if you're starting over, you're starting from scratch, if you're starting now, and you want to design software for the way that we want to work, we're actually prescribing even what is, Well, how we want to work in the near future or the future, even maybe farther out, but we could see the value in having those tools that will enable us to work like that.

Absolutely. I mean, I think, I think we've all seen it, whether it's the end of the stage or whether it's a tender or whatever, when, you know, you send over your package of information and it's then just, you know, the next party will just start from scratch again. So, you know, a huge amount of work has been done up to that point, huge amount of valuable work.

Um, and so actually being able to access, you know, the, the version, the decision history behind a lot of these points, you can then actually, you know, increase the efficiency so much as part of that process. Mm hmm. Yeah. I think it's, it's worthwhile saying with, you know, the automation intelligence [00:59:00] piece. I don't think we can talk about that without mentioning what we've heard so much about this week, which is AI.

And I think, you know, we're still. Trying to understand what that means for us, you know, I think AI is often maybe misused as a term, you know, it can be used in place of automation. It's used interchangeably. Exactly. With automation, it seems. But I think one thing that we put forward is not necessarily we need AI in everything.

It's more we need. We need data to be accessible and, you know, in a way that we can actually leave the door open for a responsible use of AI at the appropriate time. Well, getting back to the specification, what we need is we, we need to say, this is what we need. Yeah. And then we figure out the tool to do it.

We don't, we don't just say. What are we going to use AI for? We actually need to define the business case first, and then define the tool stack that will help us achieve that, and AI may or may [01:00:00] not be a part of that. So yeah, I don't, it doesn't need to be everywhere, but it does need to be able to play with this.

Exactly. It needs to be a, a piece of the sandbox. Yeah. Yeah. Yeah, I think we've, we left it as leave the door open for AI. Don't, you know, build an entire toolchain that suddenly we're like, oh, we need to completely reconfigure. Well, and this gets back to the whole underlying premise of this. You know, what would you, what's, what are the words that you're calling this?

Like where the repository, right? Is it, is it a data framework? Is that what we're calling it? It, it, it, we, uh, we alternate it between a data bridge, data lakes, data sewer, you know, again, we're not trying to recreate something. We just needed to make it obvious what we were making a reference to. And so we have been calling it the data framework.

Um, it's been really interesting this week to hear Autodesk talk about the data model. Um, and, and, uh, but it's Autodesk's data model. Uh, [01:01:00] it's not something that, uh, perhaps is completely and utterly universal to, to all stakeholders. Um, and so I think that's the difference as to kind of maybe where we find ourselves at the moment.

Yeah, and I just bring it up because it is important to start there, right? And, and if you, uh, this brings structure to data across the industry as an idea. And for AI to play with it well, it has to have that as well, right? And so it. It's fundamental to start there for everybody to build on top of that.

Yeah. Yeah, I think it's worth saying as well You know We set out the 10 points of the specification, but there were then certain characteristics or footnotes that went with that, which is, you know, for a lot of this, we're looking for, you know, the software industry to, to build and for us to advise, I think when it comes to the data framework where, you know, we're not necessarily going to be pitching one single schema, right.

You know, the, the, the many languages in, in. There's going to be different [01:02:00] cases. There's going to be many languages. And yes, there's going to be. Yeah. You know, lots of different things there, but for us, I think it's critical for us as industry to be leading that conversation with, with the software industry advising.

So flipping that relationship of, you know, leader and advisor. And so, you know, that's the key thing. Other points being like, um, you know, I think we need to be very honest ourselves. We, we're not software developers, despite, you know, many practices having their own internal developers. I think in the grand scheme, they're people tinkering.

Yeah. Um, well, there is value in an entity maintaining all of that as time goes on and making, ensuring that it, that it's up and that it works and that is hard inside of a practice, right? Because people abandon projects, people leave offices and go other places and it's acknowledging to your point of acknowledging what we are, where our value is, where it isn't, what we're willing to pay for [01:03:00] is, is, I think all reinforced in that statement.

Yeah, and, you know, we, we very much, I think, acknowledge, you know, where our strengths, where our weaknesses are. But we say we're looking to the software development community to, to actually help us achieve this. Um, we know what we want in the end, but, um, getting there is where we need to look to the experts, quite frankly.

Um, but I think, you know, to, to the original point, I think with the data framework, which, you know, as Aaron quite rightly said, is the foundation, it is, you know, the, the linchpin to all of this, I think we're working through the steps of actually what that looks like as, as, um, As an initiative going forward, I think, you know, it's been, what, five months since this was presented now.

Um, there's been lots of great conversations, but it's a beast to tackle. And there's a lot of people who are very enthusiastic to get involved, which is fantastic to see. But it's then corralling that [01:04:00] into a direction, a trajectory. That's what we're working through at the moment. I think this is one of the things that I've always struggled with, even with the LFRT, talking about, well, let's just take this.

Take the horse by the reins. And let's do what, what we can do in it. And it's like, who's the decider? That's my question, right? Like are we, is one entity of the decider? Is it an elected position? Is it a house of representatives? Like, is it a Republic of representation? Like what is it? Is it a democracy?

Is it a and And it's because are we just going to vote? And, and, and I think that that is a, that's something to struggle through. Right. And so I'm wondering maybe how are you dealing with it? We're conscious that in order for us to then move beyond having just written something and actually, uh, finding some, some value for the industry going forward, we, uh, alternated and, and discussed with a [01:05:00] huge group of people.

You know, to, uh, to crowdsource what people felt was the next right step. One of which was, for example, engaging with a data architect who kind of knew nothing about our sphere to, to try and work out apples and pears and apples and apples and try and, you know, engage with that, that. That language of dictionaries and libraries and so on.

Um, we kind of said, okay, well then we need some money to do that. We need to pay this, this person. Um, do we look at sponsorship and then, okay, what happens now when one software vendor is a platinum sponsor to do? And so we, you know, we realized there were kind of some challenges around some of those things.

Um, as Andy said, we've been, we've been working with some higher education entities that have got. 21 PhD students that may be available to, to, to support us and to do some work there. We've been working with Building Smart who, let's be fair, are a commercial entity that have a great group of people that can possibly deliver out some of this with us.

And so those are the things we're kind of navigating at this point in time. [01:06:00] Equally, we are updating the software vendors. With what we're doing, we're not immediately saying, Hey software vendors, come and tell us what to do. Because, uh, we just feel like we're going to get a very different opinion from each of those software vendors on what should be done and how it should be done.

And so, as it stands at the moment, we're kind of informing them. And we're hearing their feedback rather than asking them to tell us what to do and, and, and so on. That's kind of like a grid. The point is, like, you, you, you intake all of it, and then you decide. It's, it's not, it's not like I'm going to do all of those things, because there's competing interests there, right?

It's impossible to incorporate all of it. You have to curate those decisions as you move forward. Yeah. And, you know, we, we both have full time jobs at international firms that require quite a lot of our time. And so we've also been looking at how can we get way beyond the premise of, Oh, you're just a group of architects.

So [01:07:00] we've very much been looking at putting a, um, a council together of some architects, engineers, completely independent consultants who do a lot with the kind of. being forced to solve the problems about information management. Um, and so that's kind of again, finding its feet, um, and something that, um, I'm sure we'll kind of, uh, yeah, another five months from now, there'll be, you know, a very solid piece in place.

Nice. Yeah. Methodical, keeping the momentum going, right? It's all, it's all a big, keeping that energy. We're constantly going back to why you're doing this. Yeah. Right? Because figuring this out as you move forward, it is a, this is like climbing Everest, right? And if you've never climbed Everest before, it's a, it's quite a different experience than if you have, right?

So that one step at a time, figuring it out as you go, I mean, I'm, I'm rooting for what you're doing and I'm happy to put it out there for sure. Uh, so you, you mentioned a little bit of call to action. How can people? [01:08:00] Find out more about this. Where do they go? Yeah. So, um, you know, one of the questions we've had is what does success look like?

You know, so, um, to some extent I would say engagement. So the specification is hosted online at the moment and is available for comment. Um, every, I think, eight weeks or so, the, the group of original authors get together to review those comments and, um, sense check the contributions that have been made.

And in most instances, I think we've, we've kind of added those thoughts and those comments. So, uh, in terms of the call for arms, the link will be available, go and have a look at the written specification. If you feel like there's something that's not there or not explicit, or there's an area or a topic that's not been covered, contribute.

because we are not gatekeepers of, you know, we're not being dictators about what is there. This is about a continued representation of not just the architecture industry, but the entire process of us delivering, you know, built environment. Um, so that would definitely be something I would say, [01:09:00] um, is the primary way for people to be involved in this.

Um, equally, do watch the presentation version, because I think that will expand on and contextualize what is effectively written. Um, And I would also suggest if anybody feels explicitly interested in, in supporting this and helping us take this forward, um, again, there are more than just me and Andy involved in this process.

There are a number of people, um, and we would really like to diversify that group to ensure that we've got better representation. Um, and again, more people will have different levels of energy that can pick up some of the kind of subprojects of that as well. I would also say, you know. In terms of the behaviours to inform us as well, and, you know, I kind of inadvertently promoted the spec yesterday through my presentation here, but, you know, question and challenge, you know, both the way that you're working, but also the way others are working around you, because that will then start to, you know, inform the feedback that you can give to us.

Challenge us [01:10:00] as well. I mean, we, we put forward 10 points as, as a group of Frankly, UK architectural practices admittedly with a lot of input from, you know, across the globe, but we may not have covered everything. So, you know. It is, you know, we are open to challenging. We have to be. It doesn't have to just be 10 points.

No, exactly. You know, give us an 11th or cross one of them off, whatever. If we roll back 10 years, would we have been talking about MMC and automation and intelligence and AI? No, we wouldn't have. So I think it's, uh, we have to be responsible and responsive to the, the trends that will occur in our industry going forward as well.

So absolutely. Um, and you know. Next time you have commercial renewals coming up, the software vendor, ask them how they are. They're aligned. They're aligned with that. Yeah, it, it, what's interesting to me about this idea again, going back to the idea of it being on the open web, Wikipedia style. Yeah, it's a living document.

It's constantly evolving. And so you could be crossing things off. You could be adding things. Uh, and as [01:11:00] time goes on, I would hope that this document continues to address. everything that people are seeing as needs in the industry. And this isn't just a one time thing. Yeah. Agreed. Yeah. Well, thank you so much for having this conversation that I'm so happy that we could get together in person and do this.

It's been fantastic. And I'm excited to hear the feedback from this episode. So yeah, we'll have links to. The document, the website, Aaron's talk, and I don't think there was anything else, but maybe I'll put, put ways for people to connect with you both on LinkedIn, uh, and I'm hoping people can reach out to you and have more conversations like this and help just so that we can understand each other better.

That'd be fantastic. Absolutely. I think the more voices lending Lent to this, I think is only going to make it stronger. So absolutely. Anyone's welcome. Great. Well, thanks so much. Thanks for having us. Cheers. Thank you. Okay.