Stop Siloing: An Open Approach to Technology in Practice and Industry

ANDY WATTS: Hello, and thank you for coming to this presentation, which I've titled "Stop Siloing!" And the intended topic is an open approach to technology in practice and industry.

My name is Andy Watts. I'm the director of design technology at Grimshaw. We are a global architectural practice, covering a range of projects around the world of different sizes, complexities, scales. And all of them really need a unique approach to technology across every project, whether that's BIM, computational design, or other emerging technologies.

And this is really where my team comes into play, the design technology team. So we are a global team of specialists, covering a range of different disciplines, as I mentioned, BIM and computational design. But we also have specialists in urban computation, environmental performance, extended reality, and our own in-house applications development team.

But it's worth noting that despite our strong approach to technology, we still operate on this premise that Grimshaw is a design-led practice enabled by technology. And it's really in the statement that we have this idea of design and technology. And this is what we're focusing on today because that's the team that I come from. And it's really this juxtaposition that we're really trying to focus on.

I think, as we know, the dynamic between technology and design has shifted. And it's going to continue to shift. Technologies once seen by some as at odds with the process of design. And it's now more relevant and necessary to architectural teams in the delivery of any design vision that they have.

But with that said, the evolution of this relationship is not always seamless. Adoption is still an issue, whether through resistance, hesitancy, or lack of understanding. And it's not just at an organizational level. At an industry level, we have a field with different players at various stages of digital transformation, quite often trying to tackle the same challenges in the same ways, but in disparate silos of activity.

And it's these challenges of adoption and integration of collaboration that can be tackled through a much more open dialogue that enables change and works with the transformative qualities of technology. But making technology accessible is not just the flip of a switch. As I'm sure everybody watching this video is aware, the nature of business is on placing a focus on the need to produce a higher quality outcome in a shorter amount of time and at less cost. So how do we actually progress while still trying to meet these increasing demands?

As well as that we are an industry where at times we still struggle to get designers to switch from a traditional 2D drafting mindset to a more 3D data-oriented mindset. And even beyond that, there are much larger stakes at play as well. Understandably, a huge amount of focus has been placed on the impact that our industry has in the world that we live in today and our responsibility as an industry to help change that.

And then there are also big pieces in the news over the past few years about the responsibility of the AEC industry in actually delivering responsible designs. And so this is why I really come on to this idea of open as an opportunity. Because I think tackling all of these issues, we as an industry need to be as open as we can be in it, especially in terms of the dialogue with technology.

And so for architectural practices, such as Grimshaw, it does demand a focus on enabling designers to engage with technology more readily. And for the wider industry, progressing existing tools or leading on new solutions means a more open or collaborative approach needs to be taken. And so that's where these two questions really come from. How do we allow designers to engage with technology? And how can we be more open about technology as an industry?

And so let's face these one at a time. So when we talk about how we allow designers to engage with technology more readily in practice, there are a few different factors that come into play. One is around accessibility.

So for designers to really engage and leverage technology, access is critical and opportunity for hands on experimentation, i.e. learning through doing. And at Grimshaw, we enable this through promoting technology expertise directly into design and project teams by permeating design solutions as opposed to a siloed team that is pulled in at particular stages as a project progresses. We very much think that technology needs to work hand in hand with the design teams as we progress.

And so this integrated approach is fed by a centralized design technology team, comprised of specialists across a range of different digital disciplines, who all work together to test and deliver and bring the best solutions to projects. And so we have a collaborative design technology team and collaborative design teams as well.

Then obviously knowledge is also key. So as well as embedding specialist expertise into projects, we also need to improve accessibility through visibility and increasing knowledge as well. So whether that's through internal training and knowledge sharing, through specialist talks, CPDs, or information repositories, we have sought to give designers every opportunity to see what technology can do and expose them to as much of this work as we can.

So then taking that a step further, we also need to work to give our designers as much hands on experience as we can, whether that's through demonstrations, workshops, internal live demonstrations. Because once a designer has actually had to go, it breaks down a huge barrier of hesitancy or nervousness that we've seen and is inherent to anything new that we put in front of them. And so here on screen, we've got examples of our work in XR, where every experiment, every play around in a game engine with a headset, with a mobile device, we've documented it all. And we've always sought to put it out in front of the design teams as we go along, very much as a work in progress type approach.

So then moving on, beyond accessibility, we also need to think about mobility as well. With technology becoming more accessible, knowledge needs to constantly transfer between project teams, mobility and technology and its specialists across the practice and the wider industry. Technology in and of itself inherently creates more mobile working processes. However, the next step is mobility in execution, actually leveraging different expertise are the most effective time for a project.

Now, at Grimshaw, we are a global organization. We're also able to draw on expertise from across our international portfolio to import and export expertise as we see fit, essentially ensuring that we have the right skills on the right project at the right time regardless of where those skills may be based.

Then further amplifying that is this idea of cross-discipline opportunities. At Grimshaw, our work in urban computation has pulled together expertise from urban design and computational design and applications development to create a suite of tools that all of our design teams can use regardless of whether it's an urban project or an architectural project with an urban setting. And so these are developed off the back of projects, but without a specific project in mind, and rather are intended to be both project and geographically agnostic, allowing every project to benefit from the efficiencies that they bring.

But then even within our team, enabling mobility and mixing of specialist skills between disciplines to bring everything to bear on each project is a fundamental key. We cannot have these silos of a BIM team, computational design team, an urban computation team. We need to have one technological approach to every project which blends together a different range of disciplines-- a different mix of disciplines per project.

So then moving onto language, and I think this is one that possibly many watching this video can associate with. We recognize that technology comes with its own language baggage, specialist language and terms that are alien and often create barriers to an open engagement. We've all seen that glazed over look as we're talking to an architectural team. And suddenly we're pouring in all the acronyms, and they don't have a clue what we're talking about.

We do know, however, that the outcome wanted by technology and design teams is the same. We're all after the same goal. And so it becomes essential to develop a common language of recognition.

As an example, as a technology team, we know that we have capabilities in BIM, computational design, extended reality, urban computation, applications development. But then those are less important than actually understanding that a design team wants to know how to perform design ideation, check design performance, work on delivery and documentation, stakeholder engagement, or seek added value.

And so quite simply what we have to do is then a bit of mixing and matching to find that common ground in terms of terminology. We essentially need to bring together what, the BIN, CD, et cetera, and the why, design, ideation, performance, because we know what is possible. A design team knows why they need the technology. And so this is then how we can seek to enable and augment projects.

We move from a technical and program-based language, i.e. BIM, CD, et cetera, to an impact and outcome-based lexicon, such as ideation, performance, and stakeholder engagement. And in doing so we start to really see the benefits that this unsiloed approach to our team can bring. So by allowing an open dialogue and cross-pollination of expertise between specialisms, we start to see how design technology as an overarching function can enable project teams and unlock what they're trying to achieve.

And then the last point in this particular section of how we can break down silos within an organization is exploration. You we constantly need to push against the boundaries of what technology can offer through exploration, whether that's just through reading around a subject or actively developing tools and solutions. We need to be constantly looking at whether applications for stakeholder engagement can be used as part of our pitch, our sell. Or whether we can develop in-house analysis tools that can be used across a range of different projects to help iterate at a much faster pace. So we need to constantly be looking at our software stack and actually looking at where we can potentially fill gaps through exploration before maybe looking further afield at whether we need to invest in something.

And then we can also look at engaging and exploring new themes, whether they have legs or not. Case in point in this instance is the Metaverse, which we did actually have a project in. However, we've all seen where the Metaverse has gone more recently. But then there's the other end of the spectrum, going from the very virtual to the very physical. We've recently done a lot of work around an exploration around materials, in this case, the waste byproduct of sugar production, which has been incredibly exciting project that we're looking forward to continuing further.

And so that is the end of this part about how we can be more open about technology within practice through those four themes. But then how can we be more open about technology as an industry? So with a practice like Grimshaw that's conversant in and embracing and enabling technology, there needs to be a landscape within the industry that likewise delivers on the opportunity of being open and collaborative. However, we do recognize that there are barriers.

So in the context of this talk, I would point out two barriers. One is that the construction industry is historically notoriously slow on digital transformation. Anyone watching this video will have seen in an industry talk on digital transformation, will know the exact McKinsey slide that shows how far down the table the construction industry is.

And the other part is that as a result of the pressure on fees and scope, architecture has become incredibly competitive with firms incredibly protective over IP. The former of these is very well established. There's competitive fees and scope, but absolutely needs to be tackled given the emphasis placed on construction in broader sustainable and economic conversations. The latter part around IP is an area where we can begin to influence a change ourselves.

And so let's look at these. So then collaboration is the first real key part here. And this is where we start to push against what is what we can offer. We can actually start to broaden the conversation with others.

We are incredibly lucky within Grimshaw to have a very broad range of collaborators, some of which are mentioned here. And this is key. We need to be engaging in conversation at all levels, not just high-level strategy, but right down to how we do our work because there is no point being protective over what pencil we use. Likewise, there's not a lot of point in being protective over the technology that we use as well.

Which brings around the conversation of open source. And actually, a lot of those within the industry, and we have been guilty of this in the past, have been quite forthright in saying that everything that they develop is open source. And so let's dig into that a little bit.

And so if we look at the, let's say, the definition of open source. Open-source software is made by many people and distributed under an OSD-compliant license, which grants all the rights to use study, change, and share the software in modified and unmodified form. So let's look at the characteristics of this.

We've got peer production. We've got open access. We've got a willingness to share and then transparent collaboration.

And this is where we really start to fall down a little bit because it's really on, I would say that last point, the transparent collaboration and the willingness to share, because-- let's take an example in point. So that perennial issue of interoperability, moving information from Rhino to Revit. We can all sympathize with it. We've all done it.

But then let's have a look at just some of the different solutions that have come out to actually tackle this issue. We've got solutions from Rhino, solutions from Autodesk. We've got the likes of Speckle. Going back to legacy Grimshaw days, we've got Mantishrimp, which was developed in our New York studio. And then we've got likes of Conveyor and Beam. And this is just a few, this is just a few different solutions that are trying to actually achieve the same outcome.

Now, imagine if we had genuinely pulled together our resources, our knowledge, our expertise to develop just a fraction of these solutions, imagine what else could have been achieved with that remaining time, that remaining resource, that remaining talent. And this is just one example, one scenario. And I would say that actually in the context of what we, as an industry, need to do it's a relatively lower priority example when faced against some of the more societal or environmental pressures that we have.

There's this amazing quote. I absolutely love this tweet from Luis Fraguada of McNeel where he absolutely hit the nail on the head when talking about the proliferation of LCA tools and carbon tools, which felt like they were the next wave after interoperability. And it's absolutely right. We don't need to all be inventing the same tools, the same processes because there's a finite number of ways that this can be done. Let's do it once or twice as an industry, and then we move on to the next thing.

And we can see this barreling down the road in a number of different ways. If we continue down this siloed approach, how are we going to be tackling the likes of artificial intelligence, which is gaining so much more momentum as we go along? If everybody is developing their own processes, their own databases, their own approaches and embracing AI in different ways, we're all just going to be moving at our slow, individual paces.

And this was actually the premise for a piece of work that we undertook within Grimshaw over the past three to four years, starting actually early on in the pandemic, where anyone who's looking on LinkedIn at the time was seeing all of these proprietary configurator platforms, all developing-- I'm not taking away from these. They're all amazing pieces of work. However, they all felt like these siloed pieces of software that actually needed to break out of their individual molds to make the leap across into the mainstream.

And it's something that we really kind of picked up on as part of our work for the Construction Innovation hub, which at the time was this incredibly aspirational piece looking at how we could develop a platform approach to buildings in the UK. Now, the work that the Grimshaw design technology team in partnership with Buro Happold, Mace, and others, the piece that we were looking at was really how we could take that idea of disparate configurators and then start to link them together to essentially define what we termed as a common configurator framework with the intention of being able to actually share data from stakeholders to stakeholder, from one end of the supply chain to the other without any data loss, but always making sure that each tool was doing its own separate activities and actions and roles.

This is all open source. It's all online. We did prototype it with a number of different, in this case, the Rhino Grasshopper, but also Unity and Revit configurators as well. And so if you're interested, come and speak to me at AU and we can have a chat about it.

And then moving on from this idea of collaboration, which I've ranted on about for quite a bit, is this idea that we need to challenge the collective norms that we face within the industry. We need to be much more open. But we also need to look hard at the practices that we currently have. What can we be changing and reinventing where appropriate? We don't just need to adapt technologies to emulate or speed up existing processes, but really question the validity of those processes in the first place.

Even looking beyond that with a focus on openness and efficiency, we've been incredibly fortunate to be part of grassroots industry-led conversations that have led to open letters to our hosts and a drive for a rebuilt digital ecosystem for AEC with these topics as the focus. And this opens up the idea that open dialogue cannot just allow us to make better use of the technologies at our disposal, but also allow us as an industry to influence the technologies we use for the betterment of us as practices in the overarching challenges that we face as a profession.

And this is where a pretty substantial piece of work over the past year has come into play. This is the future AEC software specification. Now, this was put out there as really an intention for us, as an industry, to define what we need, what we are looking for within our future software. You know, it does exactly what it says on the tin.

So rather than chasing after individual organizations to make changes, a collective of architectural practices to start with, but we're growing that, all took a step back and thought, OK, can we put down what we want? Rather than asking others for change, can we say what we were aiming for? And this is where the specification really came from. It was us putting a line in the sand of this is what we need. If anybody wants to develop this for us, then we will happily use your product.

So this was launched at NXT DEV in London back in July. Aaron Perry, who was the main co-author of the specification, did a fantastic presentation at NXT DEV, where he very succinctly went through every single point. And it really started out with this manifesto that we, as a collective of AEC firms, are seeking to imagine the future tools that we need to shape the world around us.

And our intention here is that whilst this is defined by industry, we absolutely recognize that it needs to be enabled by developers. We need to work together hand in hand to create a tool set that meets the challenges that we face today. If any of you are interested, you can check that QR code, and it will take you to the specification. And you can sign up and give any thoughts.

But in terms of the specification itself, it set out around 10 key points that we have essentially termed as the basis of the specification. Now, these are really kind of focused around functionality. So this is how we want future software to behave, points around access to live data, being able to design and evaluate our work in real time regardless of the scale. We want software to be user friendly, efficient, and intuitive, but we also need accuracy, flexibility, and intelligent modeling tools.

Then there's what we want the software to enable. And that's obviously responsible design. We talked about that in terms of our responsibility to the environment, but also the societal responsibilities of our work. We need to enable new approaches to construction, including DfMA and MMC. We need to facilitate automation and the use of AI, as and when it's appropriate and ready. But we also need more efficient and intelligent deliverables. And then there's how we want to get value from this software, which is through actually more transparency, more access to how we are using software so that we know what we need and when.

But really all of this is then underpinned by this key point, which I've conveniently not highlighted at the top yet. This is the foundation-- a universal data framework, essentially a common language, that all of our future AEC software platforms can read and write-- can read from and write to. And that allows for a much more transparent and efficient and long-lasting exchange of data.

And this, in the context of this talk, is really how we break out of our software silos, rather than being bound by file types or particular schemas or anything. If we can take leaves out of other industries and look at how we can be talking with a common data language, then suddenly we are a much less siloed industry, a much less siloed supply chain. And actually, ultimately, we'll be able to create far better interventions, whether that be at building or urban scale as well. So if anybody is interested in being part of this conversation or really wants to add their thoughts or anything into the specification, again, head to this link, and I'd love to hear from you.

So the idea is put across in this talk across both practice and industry challenges to technology, whether that's looking at accessibility and mobility, a common language, open dialogue, we've seen success across all of these. However, we absolutely, as an industry, need to accelerate forward as we seek to really tackle the major issues that are facing our industry today. It's something that I firmly believe that we need to be much more open about. And I'm really looking forward to continuing this conversation going forward. And with that, I will say thank you very much.