Accelerating Industrialized Construction Through Configurators for pDfMA

ANDY WATTS: Hello, and welcome to the session on Accelerating Industrialized Construction Through the use of Configurators. My name is Andy Watts. I'm the director of design technology at Grimshaw, but I've also been part of the Digital Working Group at the Construction Innovation Hub alongside Alain.

ALAIN WAHA: And hello. I am the chief technology officer at Buro Happold, and with Andy, have been working in the Digital Working Group at the Construction Innovation Hub in the UK.

ANDY WATTS: During this session, we will be covering a few different topics. One is a background to platform approach to design for manufacture and assembly, the work that we've done on the Construction Innovation Hub, our work with the common configurator framework, the return on investment for this type of approach, and then lastly, how you can get involved in the future. I'll now pass over to Alain.

ALAIN WAHA: So yes, it may seem strange to start with talking about platforms, but I think it is essential to explain the context of the work that we've been undertaking. And so we'll just spend a few minutes on this concept of platform and how they apply to construction. Next.

So the UK government launched this idea of a platform for construction, and going back to what are platforms. And they can be product platforms, they can be industry platforms, they can be business models. And this is very well codified. I've taken this diagram from the Business of Platform book from Annabelle Gawer, and I really invite people to go back in this analysis.

And this is the central approach that we're trying to apply to construction. So on the next slide, why we are trying to do this is because traditional construction relies on many firms coming together and delivering a project. And in the pursuit of industrialization, what firms have done is to vertically integrate. And what we understand from platform business models is that that's very stable, but that vertical integration comes with many problems.

First, you have to do it all yourself-- and you can see it on the left of the slide-- but also, as soon as you own your own factory or you are geographically located in a single place, you buy yourself into all sorts of problems relating to factory loading and having to have the factories that produce the product. So you need quite a big pipeline and that pipeline, geographically, cannot be too dispersed because otherwise, you incur very high logistics costs. And in construction, that really puts a limit to what industrialized construction can deliver in a vertically integrated approach.

And the idea of a platform is that, actually, we would create different suppliers that would produce locally, parts, assembly, subassemblies that would come together to create a building. And that is a platform approach.

And if we go to the next slide, this approach has been developed over time by many researchers here. Make a call out to Daniel Hall at ETH and SCIFI and trying to understand how this fits into an industrialized construction context. And you can see that product platform is one way forward to try to organize your supply chain. And a lot of business model analysis and supply chain analysis was put forward by the UK Research program called Transforming Construction, and they came up with a little video to try to explain in simpler words what the platform might look like in construction.

[VIDEO PLAYBACK]

- Platforms underpin many of the world's most valuable firms. Google and Apple have technology platforms, for example, and manufacturers, like Tesla, use product platforms. But what are platforms, and what have they got to do with construction?

There are different types of platforms, but all of them have three things in common. First, a set of core assets that doesn't change a lot. Think of the chassis of a car. Second, a set of peripheral components that can be combined with the chassis to create different variations of the same car. Third, a stable interface that enables the components to connect.

A platform can be digital or physical or both and is a way for companies to offer a variety of products and services, while still benefiting from economies of scale. At Transforming Construction Network Plus, we found that product platforms can be useful for the construction industry. Already common in manufacturing, product platforms are helpful in construction because they produce physical objects.

Think how much more efficient things could be if you could customize buildings with different cladding and roofing, the peripherals; using a standardized connector, the interface; to attach them to an appropriate structural frame, the core. By standardizing the interface, product platforms enable companies to create new product offerings for new markets without disrupting core production.

So how do companies develop a new product platform? There are two main approaches, top down or bottom up. A top-down process starts with customer requirements and develops a family of products to create a modular product platform. A bottom-up process, on the other hand, takes an existing product and deconstructs it into its separate components before recombining them into a product platform.

Adopting a platform model offers huge long-term benefits for construction, enabling companies to create variety, respond to market demand, reduce development time, and improve the way they learn over time. But it is challenging. It requires rethinking the way companies engage with their suppliers, clients, and the market, and that requires rethinking their business model.

To find out more about developing a platform, download a copy of our digest, Platform thinking for construction. Transforming Construction Network Plus, transforming the way buildings are designed, built, and managed.

[END PLAYBACK]

ALAIN WAHA: So there you are. You're now world experts on platform and how they apply to construction. And with that knowledge, what happened about four years ago is that the government in the UK analyzed, with the help of its advisor, Bryden Wood, in this case, on how could we procure and create product platform for Demings. And the hypothesis was, we can serve the British government's procured assets from the Ministry of Justice through the Ministry of Education that buy schools, through the army that buys training facilities, through this product platform, and we should attempt to make this become a reality.

And I'll hand over now to Andy to take over the story from here.

ANDY WATTS: So following that work that was done with the government, that really provided the inception of the Construction Innovation Hub, which is a UK government and Innovate UK-funded research consortium within the United Kingdom. The CIH covers a range of different topics, including manufacturing and products, through the standards of compliance information management and security as part of digital endeavors there, but also, looking at how various outcomes from the Construction Innovation Hub can really start to further transform the UK construction industry.

And so we were part of a program within the Construction Innovation Hub that brought together a real cross-section to the UK industry. That covered three core bodies of the Center for Digital Built Britain, Manufacturing Technology Center, and BRE, or Building Research England. But it also really did something that a lot of these research consortia don't necessarily do, which is really embrace industry partners en masse.

So what we ended up having is a real cross-section through the industry with industry partners right through the entire supply chain from design and engineering through to tier 1 contractors and including suppliers and manufacturers as well. But also, a key part is that we also had a client in mind for this as part of the Construction Innovation Hub, which is we were give them mandates to define an outcome that could be used for social infrastructure moving forward across six government departments, including transport, education, health care, justice, defense, and housing.

And so the Construction Innovation Hub covered a wide range of different areas of which ourselves at Grimshaw and Buro Happold were a small part of. And there were four integrated projects within the CIH. There was the value toolkit work, which you may have seen the work from [INAUDIBLE] more recently really promoting that. The platform program does work around information management in concert with CTBB, and then there was an international program of engagement as well.

And it's that second point there at the platform program, which we are talking about today, and Alain is going to go into that in more detail now.

ALAIN WAHA: So bringing this all alive and before jumping into the digital part that's coming in a moment, so the idea here is all these clients want to procure spaces, essentially, because they repeat. If you think about a hospital, it's just a number of spaces, some are teaching spaces, some are receptions, some are kitchens, some are corridors. There are some specific spaces to hospital, but many of them repeat, and you'll find them in schools. And you'll find them in research facilities or defense facilities.

And so rethinking what the overall demand for these spaces might be was our next step. So if we go to the next slide, a huge piece of work was undertaken to understand of the 35 billion pounds that the UK government was going to procure in the following five years, so 7 billion a year, how much of it was actually spaces that fundamentally repeat and could be thought of as subassemblies of buildings and themselves being created from paths that were going to come together.

And we found there we're about 13 billion worth of assets that were going to be procured and that could be delivered through a product platform. But what was really interesting is we found quite a few other things, and going back to one slide just to signal that, we talk about standardization and say, well, we've seen industrialized construction. And it's always an oversimplification. And you say, yes, but actually, there's a lot of diversity and complexity that's unnecessary.

And so this 104 number is actually the number of different ways that the UK government described a space that you and I know as a toilet. Now, I wouldn't disagree that you want to have diversity, but is it really necessary to have 104 different way to specify a toilet? Maybe 20 is enough. And so this unnecessary complexity is what creates complexity in an environment that if we could reduce that unnecessary complexity, we would be able to start creating more stable supply chain.

And really interesting that we found that 50% of the spaces have nothing to do specifically to what the client is, a hospital or a school. And on top of that, many of those spaces that the government procure are also spaces that the private sector wants to procure. So if you unlock the supply chain or platform with the government procure spaces, you also do it for the rest of the industry. Move on to the next slide.

And so you want to put yourself into a situation where what we're doing here is understand what is the overall demand for space, part subassemblies, then create a platform system that allows you to create these spaces by defining them in abstract way, partition how many linear meter partition, how many linear meter of corridor, circulation spaces, classrooms do you need to buy. And then define a product platform that allows you to configure all these subassemblies and deliver the assets that you want, and then they would be deployed by a very diverse supply chain, but in a repeatable way.

And that's what is shown in the blue. What's the demand? The orange, creating the product platform, and then the green, each time configuring those subassemblies into the actual asset building that you are delivering.

Now, if you move to the next slide, making this non-trivial and using computer and computational thinking to actually manage those interfaces and allow you to configure interesting buildings. Because we can all do it with simple trivial cases, but that's not of interest. What we want to do is great schools, not boxy schools. What we want to do is great student accommodation, not just boxy one.

And so how can we let that diversity that we need through technology? And that becomes the exam question for Andy.

ANDY WATTS: So then as part of our work with the Construction Innovation Hub and as Alain alluded to, we were set the brief of we need a configurator. That was what we were told we needed to do, and we thought, OK, let's take a step back from just being told we need a configurator for a kit of parts and think actually how can we make this a real kind of useful tool, not just as a one off within the CIH, but as something that can be used across industry, hopefully.

So first of all, we take a step back and think, OK, what our configurators? So they're quite a buzzword in the industry at the moment. People are getting excited. People are wanting to configurator for various different purposes. But essentially, when it comes down to it, a configurator is a method of providing the user with the ability to manipulate a design within a preset range of parameters and constraints, all within a usable interface that essentially, removes a lot of the overwhelming potential of the computation in the back end.

And it's something that we started to see within the industry as well. This is a real trend that's permeating the AEC industry. And what we started to notice, anybody who's been aware of what's going on beyond their own practices is there's a rich ecosystem of configurators starting to be produced and publicized and made available.

But in doing so, it starts to really replicate the same challenge that we have within the industry as a whole, this idea that we are a very fragmented and siloed industry, and we see this with these configurations as well. They don't speak to each other, they don't share information, and there is a lot of potential there for reinvention of wheels going on.

And so this forms the basis of our task, our exam question, so to speak. How can we look at providing an environmental framework within which all of these kind of flourish and speak to one another and we as an industry can, hopefully, move forward in this particular realm? And so to summarize that with configurators, wandering cannot rule them all. So the power has come out recently, so that had to go in there.

The construction industry is naturally distributed and fragmented. There's a wide range of relationships to manage there. And that, essentially, then takes us on to the second point. Now, there are a lot of existing varieties and versions of configurators out there. They might be web based, they may be bespoke plug-ins, or they may be platforms in their own right.

Now, how do we make them start to speak to one another and essentially, remove a lot of the entropy that we can see in these efforts? And so with that said, we came up with the idea of this common configurator framework. So this was undertaken as part of the Construction Innovation Hub platform design program, and it was a joint effort between technology teams at Grimshaw and Buro Happold. We were very lucky at Grimshaw to be working with Dr. Al Fisher, who's the head of computational development and Alessio Lombardi, and then our own team of Georgios, Justyna, Natalia, and myself.

And so in looking across the industry and also performing user requirements capture within the program, we came up with a set of principles of how we would need a common and configurator framework to function. The real idea here was that we needed to allow communication between and the combination of multiple, discrete configurations. And from that, we were able to then extract four key principles.

One is that we need interoperability between configurators, we need the composability of exchange data, and we need the extensibility of an object schema, or of those objects and their functionality. Now, those three are pretty standard. Anybody who's interfaced with interoperability and these solutions out there will be aware of those.

The key one for us, as part of this idea for configurators and this idea that there is a design space within which you configure is the need to provide design verification through common object specification. So that was the point that we were really adding in there to make this contextualized towards configuration.

So looking at the basics of what we understand the configurator to be, it is fundamentally based on a standard input process, output, diagram or flow, but with two key additions, which really start to differentiate it from any computational task into something that is more open to an end user, and that is the addition of a user interface to which a user can start to manipulate inputs and the computation and a graphical view to provide some feedback on what those different decisions are resulting in.

And so as part of our exercise, we came up with a-- let's say a glossary, so to speak, of the constituent parts of a common configurator framework. There's our objects, or our parts. There's our object specifications, which can be the set of rules that govern those parts. There's the common object schema. So this is the language that all of this is based on, and that can be, I wouldn't say anything, but it can be a predefined schema that everybody has agreed to in preparation for this.

And it's a key thing to note that as part of this exercise with the CIH, we are not defining the exact schema itself, but more outlining the schema should be agreed, and we've seen examples of this in the industry in the past, things like speckle, things like the BOM from Buro Happold, and other such initiatives going on.

Moving on, we've then got common repositories, which is where these objects and specifications live, we have our users, and then we have the configurator themselves. And so looking at that as a diagram of bringing all of this together, as you can see, we've got our schema on the left-hand side. From that, we're able to build out our repositories of objects and specifications from which we actually pull the data themselves. We combine that into a configurator with the user being able to then interact with it.

So then the configurator itself then starts to push out objects and specifications itself. And from that, you can start to understand, OK, then those can, obviously, be used as input into a future configurator as well. So this is really what we were trying to push for is that ability to have a network of configurators. So rather than one configurator being able to do everything, there's a real need that modularize the process as we move forward.

And so as part of our work, we developed a framework that really allowed that transfer of information, as structured data represented parts of a building, but also, it means to verify those parts to ensure that they meet set standards. Now, those standards may be coming from the project brief, from contextual factors, or from the manufacturers and construction partners as well, so parts of the building and those encoded rules and specifications.

Now, the top part is something that is really known within the industry at the moment. We are used to referring to building elements as object. The idea of object-oriented design as fundamental to BIM, as we all know, and so this becomes our kit of parts.

The second part around object specifications, or let's say architect rules is providing encoded rules against each of those objects. This is how we look at the question about how we verify and validate our objects against predefined conditions. And so in summary, those specifications come down to filter and check conditions on our database of parts.

So those parts of the building, we then looked at how we can strategically organize those into a hierarchical system, so going from a building level, down to subassemblies, down to Interfaces, and then down to components. And each of those will have their own rules, so you can imagine at a building level, this is where the project brief comes into play, whereas at the component level, this might come down to material or manufacturing tolerances and capabilities.

So then those design requirements-- and the coordinator set of specifications for anybody who's aware of systems thinking, this can then be applied into an iterative process or this B diagram, which allows us to apply the specifications and then perform verification and validation against them, following that same hierarchical approach that we applied to our kit of parts.

And so when we look at bringing this together into a process, it really allows for a decoupling of the rules and parts. On the left-hand side, we have our kit of rules, our object specifications. On the right, we have our parts. Based on what we've already said about that not being one configuration that fits all, we can assume that from this, at least two different types of configuration going on, there's design configurations, and there's part configurations.

On the left, we have our design team defining the design of a project of a building as they see fit to meet their brief and any other constraints. And then on the right, our manufacturers and suppliers can come in, and they can start to configure their parts to meet that brief. And obviously, there's a meeting of the minds here, but in broad terms, that is how we can see that decoupling.

So then moving on from this, you start to see that actually, there is, again, that hierarchy of design configurator just as there is that hierarchy of part configurators as well. And so in an ideal world, you would end up with this kind of approach, looking all neat and tidy. We go down from the building level M specification, you're defining that need, defining what the building is, to sub assembly interfaces and components, and you would then verify and validate that going the same way.

This is the dream, as you can see then, there's also cutoff points at which we can look for that configure-to-order and engineer-to-order approaches as well. As we all know within the AC industry, the reality is much more complicated and bespoke than that. So we start to see a lot of recursion going on, some iterative processes.

And so this diagram we've got on screen is just a very small sample that we started to put together around a reference implementation based on some of the thinking that was going on elsewhere within the platform design program. But it's really there to demonstrate that we can, in fact, go ahead and modularized the configuration process rather than trying to build out one tool that can do everything.

And so from this, a set of prototypical configurations with that developed by the teams at Buro Happold and Grimshaw, along with this, a set of accompanying reports. These have been made publicly available, and there is a repository on GitHub of some of the work that was done in the back end to start to build out some of this framework, but it is all very prototypical at this point.

With that, that's the end of the work that we did on CIH, and I'll now pass over to Alain for the ROI.

ALAIN WAHA: Right. I think there was a lot to take in there. In fact, that was the central part of this industry talk, so I would encourage everyone to reach out back to Andy and Fisher. And this was a research program in the UK, so it's publicly funded, and it's publicly available. Just wanting to celebrate this amazing work.

And I'm glad that at the end, it all looks very graphical and very simple, and we come back to, ah, yes, now, I can start seeing buildings again. But I think it is built on something that is very fundamentally different, and maybe that's why we have this section on ROI and then the follow-on section.

So what have we unlocked? What's the hypothesis here? And the idea here is that with this framework, you have composable configurators. So it's highly extensible, and we've gone way beyond saying, well, it's interoperability I'm sharing information.

No, you're sharing rules, and you are making things react to each other in a controlled way, and you are, for the first time, invited to say, look, you will not do the master configurator. I think, Andy, you called it the God particle of configurators. It just does not exist.

And so we now can get back to work and say, look, this is a composability. And so in the same way as we were talking about creating product platforms that compose and we can compose to create an asset, here you are able to compose-- I think that's how you present it, Andy is that we also do that with the digital toolchain that needs to be configured to deliver an asset, and I think that's hugely exciting.

And if we go to the next slide, it says, OK, so in summary, what we're saying is we've got composable platforms, so digital platform. We've got composable platform in terms of systems thinking and product platform. And this unlocks new platform business models, which is also in itself highly exciting.

And if we move to the next slide, it's often being asked, what are the possible future scenario for a digitally transformed industry? And I want to shout out the excellent work done in Finland on this topic. And they understood that there are possible scenarios where either the industry is more concentrated or more distributed.

And it's more captured by closed system or captured by open interoperable composable system. And what we are proposing here is this scenario C that they proposed, where the industry, because of its nature of being distributed geographically, but culturally as well and all the parties that are required to come together to make a project come to life are distributed, then internet of buildings scenario is the more probable one to happen.

But for that internet of buildings market scenario to happen, you needed these composable configurations or rule or solvers, and that is what has been unlocked because with that approach, what we can start thinking is, indeed, industrialization of those subassemblies that repeats and can be produced in a predictable way and procured in a predictable way in a sustainable way means that we can start to envisage that, indeed, buildings are made in factories and assembled outside.

ANDY WATTS: And so moving on from this, we wanted to talk about what is next for this work and how we are looking across the industry for involvement, for engagement, and essentially, like-minded partners to start thinking about how this can be pushed forward. The work that we did on the construction innovation hub, it was prototypical work, and we're now, in our respective practices. For Alain and myself, we're looking at how we can start to move forward with potential real-world examples and applications of this thinking.

So we're doing work, potentially, with the NEOM IBA, with the School Infrastructure in New South Wales, and the work that Buro are doing with the IC tool kit at CREE. But also, in a slightly more academic sense, we are continuing conversations with collaborators at the construction innovation hub and other potential initiatives such as NEOM, about how we can start to really coalesce some thinking around these ideas.

But something that's really given some impetus to this is the fact that the transforming infrastructure performance, the roadmap to 2030 was launched by the UK Government Infrastructure and Projects Authority. And in this, they said that one of their focus areas was addressing the need for social infrastructure using a platform approach.

So you can see that already, the UK government is buying into this, but as part of that, they were very clear in defining their platform approach constitutes, I think I'm paraphrasing at this point, kit of parts, a kit of rules, and a configuration layer. So that's all the terminology that we're embracing as part of this work, but also, this fundamental to the work that we've taken, and we believe that this work, particularly around the common configuration framework, is going to be vital to actually enabling this as an industry-wide piece of work.

And so with that said, we are looking for collaborators. We are looking for people to start to bounce ideas off and feed into this. So like-minded partners within the industry, within architecture engineering, and anywhere across the supply chain to work with us, bring some thinking to the table, and try and drive this forward. But likewise, we are also looking for those real-world examples to act as our case studies, our catalysts, further developments to actually really add to the proof of concept for some of the thinking that we're trying to drive forward.

And then underpinning all of this because it is an incredibly digitally-enabled piece of work, we are looking for technology partners to help define and shape that ecosystem. We don't want it to be one silo. It can't just be one partner. We're looking to embrace as much of the industry as possible. So if any of you out there are interested in getting involved, please get in touch with either myself or Alain. We would love to hear from you.

And with that said, thank you very much for taking the time to listen to Alain and myself. And yes, please reach out. Thank you.