The Benefits & Challenges Of Adopting A Modular Mindset In The AEC Industry’s Technology Landscape
The built world continues to see the rise of modular construction. Modular is the new norm in the modern world, from construction to object oriented programing. And within an industry whose enterprise runs so many disparate systems, a modular view of enterprise applications means a scalable architecture that keeps process in place as it relates to all that information that needs to come together to be managed.
On this episode of the ProjectReady Podcast, ProjectReady CEO, Joe Giegerich, Head of Product Development, Shaili Modi Oza, Construction Innovation Agent at AE Partners, Aarni Heiskanen, and Vice President of Innovation at OAC Services, Salla Eckhardt discuss how viewing Enterprise platforms such as accounting systems, CRM and CDE’s as modules in a projects tech stack, drives the development of an integrated data environment by driving the same processes and project information management regardless of any single underlying system.
During This Episode Listeners Will Learn:
- What is the modular approach as it relates to enterprise technology for the AECO
- How to apply modular principles to enteprise technology
- The benefts of a modular approach and digitalization
- The importance of standards and integration
Sign Up For Podcast Updates
Contact Us Today For A Free Demonstration!
Transcript
Joe Giegerich:
Hi, everybody. I want to thank you again for coming out to one of our podcasts. Today, we’re discussing, well, the topic is or at least the title, It’s A Modular World, and how do you build the modern enterprise from an IT and data perspective through a modular approach. What brought this to mind was that the built world is all about modular these days. So anyway, before I go much further, today we have with us Shaili Modi as always. I’m Joe Giegerich. I’m founder and CEO of ProjectReady, but, Aarni and Salla, if you could introduce yourselves.
Aarni Heiskanen:
Yes, thanks. My name is Arnie Heiskanen. I’m originally an architect, a software developer, and a management consultant. Nowadays, I do more communication projects for my clients, and I’m also a blogger and podcaster myself. I’ve been doing that for over 11 years, and I’m from Helsinki, Finland, by the way.
Salla Eckhardt:
I’m Salla Eckhardt. I’m a Senior Vice President at OAC services in Seattle, Washington, United States. I’m originally from Finland like Aarni is, and also an architect with my background, but my career has been focusing on industry innovation rather than design and engineering per se. I’m super excited to be on this podcast today. Thank you so much for inviting me.
Joe:
Oh, always, and I believe we met you, Aarni, through Salla back in the day.
Aarni:
Yeah. I don’t know. Salla knows everybody, yes.
Joe:
There’s a point to that, well, because reputation proceeds. All right. So I’ll tee this up a little bit more and then I’m going to ask either and both of you to describe modular construction. Actually, why don’t we start there? Why don’t you each take a pass at what modular construction is in the formal sense?
Aarni:
Well, if I start first, modular construction to me is a systematic way of designing, planning, designing, building, and also maintaining the end product, which is a building. Of course, it requires a lot of planning and the idea is to make something repeatable, and when you make something repeatable, you can develop it as any product like a smartphone, for example, but you can also get a lot of efficiencies from that because you’re prone to standardize things. We have several good examples of modular construction. Here in Finland, we have been doing it for quite some time since the 1960s, but also, it’s gaining popularity globally right now. So I think that to me, modular construction is about systematization and simplification of the process and making it more predictable.
Joe:
Salla?
Salla:
Aarni nailed it. For me, modular and volumetric are both industrial construction, and what it provides for the developers and for people that are on the projects together is that everything is built in factory conditions rather than in the actual under the sun, under the wind and rain conditions, and that way, we can actually productize this space, and that pushes us into what Amy Marks has been talking about in productization. Overall from design and engineering perspective, modular construction enables us to standardize the geometry and the size of the module so that way it’s easier to also plan for the supply chain and logistics and bring efficiencies for the entire project team. From real estate owner perspective and facility management perspective, modular enables to plan ahead in operations and also in the next cycle of capex investments. So it overall makes things much easier to manage for everyone.
Joe:
It componentizes. Is that a fair way to end cap that, right? You have rooms, HVAC, it’s … I’ll simplify it, but it’s Lego-like, and to bring it all the way through with what you guys said, it starts from that inception, what are going to be the components, how are we going to assemble with the most efficiency, how do we repeat it in forward projects, and how do we maintain it post in a way that’s not unduly impactful to the cost of the operation of that facility or building or asset.
Salla:
That’s beautifully said. Makes everything easy because you don’t have to try to control a bigger entity than what actually needs to be managed at a single point in time. So you nailed it, Gigs. Thank you.
Joe:
No, sure because I just talk to smart people and repeat what they say. So that works out great. All right. So to move this along, what I found really very interesting, so what we do is we create an integrated data environment, and the more I would read posts from you guys online and the like, it struck me that that paradigm is universal in modernity. It even goes down to object-oriented programming. There are modules, there’s more rapid fire. If you talk about that, Shaili, from a development perspective, again, it’s modular-based. Is that fair?
Shaili Modi Oza:
Yeah, definitely, and I think it nicely brings together the technology behind AEC, where, again, there are so many different connecting pieces, and it doesn’t matter if they’re all coming from different places. We need to make sure that it’s all scalable in a way that when it comes together at the project level, at the end user level, it doesn’t matter where all of these different modules are coming from and we are able to work on a project as a whole. So it needs to be seamless that way. It doesn’t matter what systems are used, where the data is coming from. I think that architecture where things are standardized, that’s where it all comes together.
Joe:
So, the acts that I grind is that looking at I refer to old school not in a good way as I would say monolithic dev as I refer to it. So you’ll have an enterprise, it will adopt one system primarily for, let’s say, project accounting. That manufacturer or supplier of software then adds on a whole bunch of other stuff to their stack that may or may not be the best of breed. Now, the notion of a CDE is it’s all underneath one roof, but the reality with inside the AEC within the enterprise itself is that you’re going to be using different systems on different projects in-house, and then as you interact with vendors and owners who will dictate their own systems.
So if you have a prescriptive method to looking at what it is for a project from the inception of how you’re going to handle NDAs, how you’re going to handle all that content, all the data that flows when the project is awarded and lit up, that as you change modules, if you will, if you look at accounting and document management systems and CAD management systems as modules because there are different manufacturers, that as you approach a project, you want that simple, repeatable standard pulling together components that are off the shelf, and that’s the tieback for me on where the built world is right now and what I’ve just seen as it’s emerging, but it’s a deficit of approach as it relates to enterprise computing and projects. Salla, I know when you were at Microsoft and the like, you looked at a lot of different software solutions, so any comments or pickup on what I just said?
Salla:
Yeah, very valid point, and from the perspective of being swamped in the amount of software that currently is available for the AECO industry, just like Shaili said, that we need to have very frictionless experience for the end users to support their work and really lean in with digital platforms, and why I’m pro platforms is that it enables people to tap into the data source rather than input it again into the software that they use in their own organizations. So it is really related to synchronizing the data and harmonizing the data rather than repeatedly inputting the data into various software systems and spending a lot of time and resources in doing that. So I’m very, very pro frictionless and data synchronization.
Joe:
Which to do that in our experience is you have to have a view of those systems as modules, not as this will fix everything for everybody in the company. I would even go further because when we go in and we have prospects and we’re discussing project running to go, “Oh, we’re going to switch from …” I don’t know, Dynamics to Deltech as a backend or for accounting or they’re going to go, “Oh, from Procore to ACC,” or whatever it may be. The whole place comes to a grinding halt and the notion that you change your ERP system and now every other department can’t do their job, I think, is one of the great risks of not proactively looking at your enterprise as a series of modules that to your point, Salla, have to have frictionless interaction.
Doesn’t mean pulling people out of the applications of their choice. It just means that from an enterprise planning and design perspective, ripping out, as I put it, like your HVAC system in a building shouldn’t show off the elevator. Shaili, do you see that quandary or what’s a better word for it, that viewpoint in the industry that there’s too much obsession with one platform versus another?
Shaili:
Yeah, definitely. I think all of the different platforms that we integrate to, that’s where they’re trying to head where they are leading that everything happens in one platform, but we see that all the time where for projects there are external people and vendors coming in. There is always a variety of systems that users work with, and definitely what Salla said, we’ve seen that so many times where there is so much work going into things that they need to do again. There is an RFI in Procore, they have to download all of it and manually input it in another system. There are documents all over the place and so many different systems that as end users it becomes very difficult where if you’re only living in SharePoint or living in Procore, you have to go to so many different places to get everything that you need for the project. So I think while all of these systems try to do everything, I think at a project level definitely there are so many systems and things in play that as an end user there is a lot of repetitive work and manual efforts going into just bringing it all together.
Joe:
Yeah, and not to be completely all over the place on it, you do want to narrow the number of silos, but … Well, to our panelists, in terms of what you’ve been seeing in the enterprise, what do you think of this attempt by folks to just go to one platform versus another versus the modular approach? What are the challenges and when do you see the upside of going modular conceptually?
Shaili:
I think architecturally as we are working through driving towards an integrated data environment as we call it, there are going to be more systems in place, and that’s where I guess we are referring to it as modules today. You use different modules across different systems, and I definitely see a benefit of them that you have the ability to use the best of different systems. Different companies are relying on different vendors, but then bringing it all together makes that even change possible later on. As you said, if you switch from one system to another, there is no fear of just the entire project disrupting. Everything is being modular. We can switch systems in and out. We can bring the systems together. I think it makes it very powerful.
Joe:
Aarni and Salla, what do you see are the challenges for an enterprise to try to go versus all in on a product stack or the approach to modular? What do you see the obstacles and what do you see the benefits?
Aarni:
Well, one thing that I’ve … because I’ve also been a software developer, and the one challenge we had was that whenever we try to bring something that somebody would see it as a new system, again, one new system again, but the idea was to eliminate several other legacy systems at the same time. So there are so many legacy systems in construction companies that those are really, I think, some of the really problematic even today. So not everybody’s having the latest technology. So that’s one thing that how do we manage to get those also into the game or how can we convince people to let go of something and strip down the number of … Some companies have 200 different apps that they use. I see the legacy systems and the sheer number of apps that they are using.
The reason why they have so many apps, for example, I think, is that we are in a project culture and project thinking. Every project is like a new enterprise and every new enterprise can have their different choices. I think that the idea of modular is in that sense it’s really good because it doesn’t totally disrupt the idea of having projects, but it also brings in the idea or the benefits of what you’ve been talking about.
Joe:
When you think about it, it’s portfolio versus project at that point. If you look at your enterprise as a portfolio of data you have to connect, that gives you the freedom within that project.
Aarni:
Portfolio management and portfolio, I think, is really my favorite topic because I developed software for portfolio management. One of the eye-opening moments for many clients was when they saw all their systems, all their services in one portfolio, they understood what a mess they were in and they were then able to consolidate and get rid of something. So looking at portfolio level is, I think, that’s something that everybody should do.
Joe:
So, enterprise platforms are a portfolio that come together in projects. Salla?
Salla:
I love what Aarni said about the legacy systems. One approach that I’ve taken into solving the problem is data master plan. A lot of organizations don’t have that. So they are basically working based on what tools people want to use for their perspective and their role on the project, and that leads into the situation that people have hundreds of apps and software systems, and there’s a lot of dark data that nobody knows that exists. People don’t have access to it. So having a data master plan and keeping it as a live document, we can actually understand better the data users, and the data use cases, the data authors, and the data managers, and these are very different roles that people have in the portfolio management or the project management overall.
If we start taking the approach of creating the data master plan when we are creating something new, then we can actually start managing what needs people have in terms of data and information, how are they planning on applying it into knowledge and actually support the organizational wisdom that I’ve been talking about a lot, but that’s the approach that I’m proposing as a solution. Data master plan, we need that.
Joe:
That makes a lot of sense because what do you want your end result to be? Then with that stepping backwards going, “Okay. So this is what we want the end result of data to be so that we can understand,” now you have Bob, Jane or Mary out there, they’re using one of three platforms, what are their needs, and then going in that direction, figuring out then, I would argue, what systems should be in play because there’s always a choice on what systems, underlying systems that you use that may or may not be amenable to a data master plan. Is that fair?
Salla:
Absolutely, and especially now that everyone is moving to cloud-based platforms and using cloud and AI is evolving super rapidly. If people are locked into a specific ecosystem because they haven’t really thought about the data master plan and how other organizations might integrate with their systems or how might they integrate with others, then we might have roadblocks. So I like how you described it, Joe.
Joe:
That goes back to the AI Garbage In, Garbage Out podcast that you were on, that data master plan, understanding what systems, making the right choices, making sure that you’re accommodating the end user, making sure there’s a user experience for them to interact with then goes a long way to supplying quality data that if you want to apply AI and machine learning and analytics against. It all really does come together at the end of the day.
I think it may also pick up on it addresses the legacy problem. I’m 1005 with you, Aarni. There’s just this, although we’ve been seeing it thaw, but a fair amount of intractability of, “We built this system. We built it 10 years ago. It’s fine as it is.” Now, it’s an on-premise, it’s not easily supported. You go in and you try to integrate through these systems and you ask them for their own product information, if you will. Very difficult to get because the guy or gal who built it has been gone for six years.
So I think that’s the other thing that it drives people to on those decisions is, to your point, Salla, it’s the cloud, right? The cloud gives you, I just sounded like Christopher Walken, “The cloud.” Sorry. I just realized that my Queens, I’m from the Bronx, but my New York accent came through. The cloud affords APIs to do these things and the industry, and that’s a question I also have for you guys. What do you see in terms of the industry, at least in an attempt or an interest in standardizing data because it’s great to get to APIs, but you have to have equivalent data to even connect? Do you know what I mean by that?
Aarni:
Yes. I think that the standardization question is becoming more and more important. I was just at the seminar last week, two days, and many people refer to data and the usefulness of data, and they refer to standards and they say that we need structure and standards for our data, not just for interoperability across companies, but also within our own companies. So that’s really … By the way, I just read an interesting study from UK. It was a company that had interviewed several people who were in charge of purchasing these applications for contractors. They said that 7% of the industry-specific software that solutions that they used are not integrated with one another or almost 60% of their internal industry-specific solutions are not integrated internally. That’s really interesting.
One of the key findings, I think, was that, what is driving the organization’s digital initiatives in those companies? They said that number one thing is improving the user experience, and the second one was improving the accuracy of datasets, and the third one was data standardization. So I think those are really, yeah, they really important and it’s something that I always … Nowadays, I really like the idea of, as I’ve wrote in my latest newsletter, the idea of starting with the user who’s actually on the construction site trying to do their jobs efficiently.
If we start from watching what they’re doing, how much time they’re using for non-value adding activities, which nowadays is about 70% of their time, and then we just start rolling back from that, what should we do in order to serve these people, these professionals who are working on construction sites, and then you start building from that up to what kind of data you need, what kind of interoperability and so on.
Joe:
I agree with that 100%, but I would go further because the thing that I always rail on about is so hyper focused on the field on the built asset, but it is professional services. As put it, they’re professionals, and that brute force, inefficiency, inaccurate, kill your budget, kill your quality is throughout those organizations, overuse of spreadsheets, overuse of email. Even those things ultimately affect the efficiency in the quality of what goes out into the field because if you’re missing correspondences, if you don’t know where they are, if it’s not an answer that was put in time, well, there’s a problem, right?
So for me, it’s all the end users involved in a project, not just relegated to any one particular professional because it’s a whole bunch of people doing this. We have a podcast to be released, so this is music to my ears, User Experience is the New Middleware. My background is as a systems integrator, and what we’ve found early on, we specialize in SharePoint back in the day, was that if it’s not easy to use, they won’t use it. So you can pull together tons of data and have charts and make queries. People need a very comfortable way to interact and contribute to that dataset. I think that’s tantamount.
Aarni:
One thing that is also typical for our industry is that, as I said, we are a project-oriented industry and every project is a little bit different even though you’re making basically the same apartment buildings, for example, but every project has, at least here in Finland, very typically the teams are changing. The composition of those trades is different every time. So whenever you … Some companies are involved in several projects at the same time, and on every side, they have a different interface to data and the services. So if you can find some consistency across those projects like I imagine you can do with this integrated data environment, that makes life easy for everybody and they get on board much quicker than when everybody’s having a different approach to every project.
Joe:
Yeah, because otherwise, they just have shadow IT, right? They go, “Hey, another system. You know what? I’m going to email this to you, okay?
Aarni:
Yeah, that’s right.
Salla:
Yeah. I’ll add a little bit of perspective why people want bigger functioning systems and better user experiences like labor shortage. We are coming to the point where a lot of the people that have been driving digital transformation and digitalization are actually retiring, and the end users that are going to be floating the industry forward and continuing the innovation, they won’t be willing to use systems and solutions that are already complicated. They will just simply abandon them or create something new. So when thinking about the data standards that you guys were talking about earlier, it really ties back to the quality of the data. So can people actually trust what they’re dealing with and then the usability of the data that they can continue reusing and recycling the same data in various different systems rather than continue performing the non-value adding work that is just a time consumer but not really helping anyone out?
Then in the future, we need better accessibility for data as well so people can actually use the data in a way that is accessible for them, and then it’s comprehendible for both human beings and the machine. So we are not only developing the systems for ourselves, human beings, but we also have to consider that in the future, our coworkers might be computer algorithms or drones or robotics, et cetera. So thinking about the accessibility, usability, and quality, those are important topics to already start building up readiness for.
Joe:
That’s something I see pretty wanting and a lot of stuff out there, and we’ll get compliments on this. I’m just glad handing our own product, but they’ll go, “Wow, this is really easy to use. Oh, it looks modern,” and I see so many applications, even stuff coming into market or new additions to existing platforms where it’s just a thing out of the ’90s. Half the front ends look like Visual Basic, and that is really more than problematic. Again, that’s why nobody will use those systems, but if I can pivot back to the standards thing again, so Aarni, you had the triumvirate there, the standards. So a question and statement, ISO 19650, at least, starts to put some standards that you can chew on. Is that fair?
Aarni:
Yes, yes, I think that’s something that many companies know and mention whenever we discuss these things. Of course, standards are fantastic. I think that everybody should, whenever they develop anything nowadays, they should refer to standards, but I also see that software developers have a great responsibility because even though customers would like something to happen and have those standards in place, if the developers don’t want to support them, that’s the problem. Many companies traditionally see standards as a hinder to being competitive and somehow-
Joe:
It’s quite the opposite, yeah.
Aarni:
Yeah. So that’s the eternal problem, but I would imagine nowadays that there’s so much pressure from the industry that standards will prevail eventually. Of course, standardization is always a little bit behind what’s actually happening in the commercial world, but without standards, we will be having really big trouble, and especially now, as I said, when data and machine learning and things like that become more and more important part of our work, and I see no other alternative.
Joe:
Standards like Moore’s law, where you have the different slopes of politics is behind technology, and the standards in those committees are essentially the political element of a Moore’s law type of view of this.
Aarni:
Also, I know people who are really passionate about standards, and the problem is that they are not really good at communication. So many times, they use terms and concepts that somebody who’s not involved in those circles will not understand. So I think the standards are also a communication problem or issue that you should solve because if there are, I understand, but many times when you talk to these standards people, they throw out all sorts of acronyms and-
Joe:
It’s a language only understood by two twins.
Aarni:
Yeah, that’s right. So I also see that there’s a lot of development to be done in communication as well.
Joe:
Standards really are in two places. Going back to you’ve got to get your own house in order, it’s hard to hook up a hose to a fire hydrant if you can’t find the hose in the house, right? There’s no way you’re going to plug data in. On the larger standards level, personally, I think that has to be driven by industry, not by institution, and there are certainly enough major players, both from manufacturers and large firms, that I think should be able to champion those.
Aarni:
Yeah. Agree.
Salla:
To add to the standards discussions, standards are meant to be the shared foundation and they should be addressed as the law for the industry that supports everyone equally, all the organizations equally, and that’s why it’s important that the industry is the driver so we can get the buy-in and people can agree to it and buy into it, and developers can then start building on top of it and create the guidelines and the playbooks that then have more flexibility into the applications.
Overall, standards, they ensure that whatever we are trying to plug in into the various systems are actually pluggable so that you’re not trying to put a three-inch hose into a two-inch hole, et cetera. So that’s how I’m looking at standards, that they should be addressed as the law, not as something that is a guideline or suggestion.
Joe:
Yeah, and it has to be done by the UN, right? It’s like a UN charter, which may not be a effective place.
Salla:
Exactly.
Joe:
Not to go there, but UN charter is a very good example, and it’s not going to happen between Fluor, Jacobs, and AECOM because they all have different access to grind. That’s why it has to be a larger industry initiative that includes Autodesk, Trimble, and municipalities and major owners. That’s the only way I think you get to it. The other comment I always make on this is there’s also a tendency in the industry to boil the ocean. It’s like, “Well, what’s going to be this full comprehensive everything to everybody for all time?” Wow, you’re doomed if you do that, man. It’s steady incremental progress.
Aarni:
One thing that is now driving very much all technology soon and into the long future also is sustainability and carbon footprint management. So that is something that will also require us to manage data more and use standards because, otherwise, how can you compare any solutions if everybody is calculating the results differently based on different data?
Joe:
If you want to do a carbon tax, for instance, which has been floated about here in the States, there must be a universal way to do it. So I guess this brings me back to the modular thing. Those standards will help you help the industry get to a more modularized approach that will allow you to swap systems out as just as it’s going to be. In our case, if it’s Plan Grid or Procore, the way you interact with that dataset through ProjectReady is the same because you’re not in control all the time of say those two platforms as a point of example. With the advancements in APIs, with some emerging standards, Shaili, there’s always a better play for standards, but where do you see there to be some good standards in the industry? Where do you think they’re lacking in terms of the way we can get things to communicate?
Shaili:
I think the biggest challenge right now and what we’ve been talking about as well in terms of there are all these differences. Taking even a simple RFI or a submittal across systems, it’s our struggle right now because each system has a different workflow, different attributes, different properties. Earlier, we talked about syncing all of this information or even bringing all of these different data points together. The system don’t have same data points right now, which makes it very difficult to bring all of these systems together. One attribute in one system means something different in another system.
So I think as looking at it as a software developer, all of these different things need to be standardized to just make it even more seamless because they are all making APIs available, which is good, but then it’s this whole exercise to now map out all of these different properties and data points of what this means in one system versus another. There are no real standards there, and we see this talking to different clients daily that they have all of these different systems and they do want to bring it together, but it’s a struggle trying to figure out how all of these properties are matching and how we can best bring it together where it is consistent, basically.
So I think that consistency is key and we are heading there, but it would really help if there are these standards of, “Okay. This kind of a workflow, it doesn’t matter what system it is in, it has a consistent set of data points or properties that we can use to bring it together and basically flowing forward that will flow into AI,” and all of these things that we’ve been talking about. It needs that consistency to have that data integration possible.
Joe:
… and data integrity. Now, but a question for you. Like you mentioned, we integrate between Procore, ACC, and RFIs. The reason we can do that is the workflows are just more straight ahead, I have a question, you got an answer, but even when we’ve been looking at submittals, which is much more complex to pass that data, there are at least some data fields that could start that process right now. Is that fair? You wouldn’t be able to pass all the data because it’s not a complete match. Even assisting in, “Okay. This set of data we can write back and forth.” That’s-
Shaili:
Yeah, definitely. There’s a different flow process, but yeah, definitely there’s an initial setup that we can use to pass the data back and forth, for sure.
Joe:
If you start there, then I think industry players, the AECOMs, the Flours, the Jacobs of the world can then put some pressure on the various underlying manufacturers, the CDEs, they’re going, “You know what? We need another five data points and another five data points.” That’s the only way I can see progress moving forward because otherwise, it’s what I was saying before, you’re boiling the ocean if you go forward.
Aarni:
Yes, and it would take years and years. I agree. Actually, I remember one project where the developer asked the maintenance and operations people, “What kind of data do you need? What kind of information do you need to do your job in the future?” It was surprisingly small set of data.
Joe:
There you go, and they’re not even getting that. That’s my point because I was at some conference a couple of years ago, won’t name names, and everybody had breakout sessions of what they’re going to do, and it was just quibbles on a board, and my comment was, “Can we get five data points, please?” because I’m just a pragmatic person. I practically bring things together. It’s just my nature, and that’s what I found. It was eye-opening to me going, “Well, we did agree at least on some of these, so why don’t we make that a standard to start?” I think that’s part of the resistance in the industry.
The industry is so used to it’s got such smart people building these incredibly complex things that the notion of starting simply is somewhat anathema to the industry. Do you have any thoughts on that? Do you agree with that culturally or is it just too much of an open-ended statement to answer?
Salla:
I think it’s a good point. Overall, simplicity is what is needed because we already have COVID standard, and people keep saying that it’s too large and it’s too hard to manage. It’s not, but people keep asking for the same data or inventing additional datasets without really understanding or thinking about what’s the use case of it, who is actually going to be the author of the data, who’s going to be the end user of the data, and things get really mixed up because people tend to have their individual perspective into what data they need at what point in time.
So when thinking about if someone is a product manufacturer, they need certain sets of data to actually produce what they then sell to the industry, but do everyone in the industry need the same sets of data as they do? Probably not. So like you said, Gigs, that we need to simplify and really focus on what is the core data that we actually need to have available at any point in time, and then depending on what the perspective of individual is into the project and the product lifecycle or the technical lifecycle of the building itself, then they can add more to the dataset that they are managing and using, but not forcing everyone else to the same thing.
Joe:
Yeah, overlapping Venn diagrams with a central commonality.
Salla:
Exactly.
Aarni:
I think that the Pareto principle is also valid here, so that 20% of the data covers 80% of the use cases. Whenever you do some software development, you know that when you start asking the users what kind of ideas they have, what kind of features they would like to have, some people are really vocal and they want something, but if you look at it from the perspective of the majority of users, the dataset is really limited. Generally, people are happy when there are not too many choices.
Joe:
Yeah, no, it’s the illusion of choices. Someone used to say and it’s true, people like the idea of democracy, they just don’t want too many people to vote for.
Aarni:
Yeah, but talking about, if you think about modular construction, and I said that we have been doing it in Finland for … Of course, it was more panelized, panel construction, concrete construction, but we developed standards in the ’70s, and the standards allow any contractor to order the panels from any factory in Finland because everybody’s using the same standards. So if you’re just using one factory standards, when their books are full, it will delay the process. So that’s an example of just the industry coming together and saying, “We have to do this now because otherwise we are not able to build the amount of new apartments that was needed after the war in Finland.” Typically, unfortunately, it’s the crisis that make people collaborate and come up with good ideas. Hopefully, you don’t-
Joe:
It’s my … Sorry.
Aarni:
Hopefully, you don’t need a huge crisis to do that.
Joe:
Yeah, and there’s plenty of brewing out there. On the modularization of the enterprise, that is the logical extension for me, Aarni, is that those standards that you referenced established in Finland freed up the industry to work more efficiently and quickly, and if they did the same thing, if the industry took on the charge of doing the same thing as it relates to enterprise platforms, it would make the interchange of different platforms a lot easier. We have two prospective projects coming up for us. One is using P6 and Oracle, another one’s using something else and something else, but the way we’re going to approach it is the same, right?
So what do you see the advantages for the industry, just being cognizant of time and the like, what should the industry do, just as a summary, to get to this more modular concept as it relates to their enterprise computing, what’s required, and what are the advantages for the industry, ultimately? Why march toward this, basically, right?
Aarni:
Maybe Salla can start.
Salla:
From my perspective, I’d say that it enables organizations, the developers, investors, to really do some cost engineering when they are designing their projects so they don’t go overboard just because they are planning to build something bigger than what they can afford for. So modularization enables the cost engineer, and then like Aarni said that if everyone is following the same standards, then you can pick and choose where you order your supplies and materials and products from, so then it enables the developers to value engineer who they buy their product from, and the value engineering perspective is into increasing the quality and not stripping cool things out from the project.
That way, it enables developers and portfolio managers, owners to really tackle the total cost of ownership, and that way they don’t overinvest in their capex processes and undermine the operational expenses, but they can actually have the whole technical life cycle of their portfolio managed before anything is actually produced and built. When thinking about digitalization, modular construction enables to build digitally first and then create the physical twin, and that way, they can already plan for how to exchange the different products, how to align in with the retrofitting things, and exchanging things, upgrading things over time, and that way, it all boils down into the financial management and how much is spent, how many times do you pay for the same building over and over again during its life cycle.
Joe:
For me, it’s the extension into the enterprise applications that you should be able to swap out your ERP, you should be able to swap out your CRM, you should be able to swap out your field modules, your change order systems without bringing the building down.
Salla:
Exactly.
Aarni:
Yes, and I think that in general, this is one part, one essential part of the more industrialized process, construction process that we need in the future. This is one essential building block of the digitalized building process.
Joe:
Shaili, any thoughts from you?
Shaili:
I think great points that came here but looking at the IT side we talked about it before, but starting to put some standards in place and definitely starting slow yet making progress and bringing all of these systems together to have that standardized architecture. I think that’s a great first step.
Joe:
So that was our contention, folks, that this same revolution that’s been ongoing and developing as it relates to modular construction, those concepts really would have great benefit being brought to the enterprise as it relates to the modular components of data and data systems. So if nobody else has any other comments, and with that, I bid everybody ado and, look, really appreciate everybody coming out. Thank you, Aarni. I know it’s late over there, and as always, Salla.
Salla:
Thank you so much. Thank you, Aarni, for joining us and thank you, Joe, for inviting us.
Joe:
Yeah, it was fun. It was really fun, guys.
Aarni:
It’s been a pleasure and it doesn’t matter. I’m always happy how late it is, however late it is, I’m always happy to discuss these things with people who clearly have some fantastic ideas.
Joe:
Well, that’s great to hear. I appreciate it, man. All right. Thank you, everybody. Talk to everybody out there next time.