Break Free From Siloed Data & Learn What’s Possible in Today’s AEC
Note: This is Part 1 in a special podcast series called, “The Art of the Possible.” You can click here to listen to “Part 2: Creating The Integrated Data Environment.”
Siloed data and information put the entire project at risk, which has led to the introduction of policies and standards like ISO 19650. To break free from these siloes, architects, engineers, construction professionals, and project owners must prioritize system integration strategies, improve document management, and deploy operations and maintenance initiatives to avoid risk of noncompliance, lost bids, and financial instability.
Join ProjectReady CEO Joe Giegerich & Head of Product Development Shaili Modi Oza as they discuss the challenge AEC firms face today and what’s possible in bringing information together across systems to deliver collaborative project information management.
What You’ll Learn About Solving Siloed Data In This Episode:
- The Challenge and Risk of Siloed Data
- What’s Pushing the Industry to Integrate
- What are leading CDE’s such as Autodesk, Procore & Microsoft doing to help their customers
- The importance of Open API’s
- What you can do today to bring your project information together
Note: This is Part of a special podcast series on “The Art of the Possible for AEC Tech”. You can click here to check out the rest of the series and featured blogs.
Sign Up For Updates
Want More?
Check out these additional resources:
How To Find Your AEC Files Faster
Contact Us Today For A Free Demonstration!
Transcript
Joe Giegerich:
Hi everybody. Today begins the first in a series of podcasts around the art of the possible. And what this is about is talking about the ability to integrate all these siloed systems within the AEC. So today we’re just going to start with the problem with siloed data and take it from there. And I’m Joe Giegerich. I’m the founder and CEO of ProjectReady. And with me today is our head of development
Shaili Modi-Oza:
Hi everyone, I’m Shaili Modi-Oza and I’m the head of development with ProjectReady.
Joe
And so, to begin with, I mean Shaili, we’ve been at this for a while. Really what ProjectReady is about came off of years from services practice where we just saw the constant challenge where companies were trying to make sense of information in different places. And with that we started doing one off integrations. But when we started Shaili, were there a lot of opportunities to integrate these systems going back a few years.
Shaili
Definitely not. All CDEs have their own set of features and APIs, which have definitely been coming along better now, but it was extremely difficult to bring all of those together, all with your own different sets of workflows, different sets of features, and finding a way to consolidate and bring these systems together where the users could work.
Joe
At the level of a project, while still being able to access the data and functionalities across all these siloed systems, yeah, and that breakdown in communication, I mean, what we’ve seen, you’ll see about studies like Mackenzie has a study about this KPMG Dodge Analytics. It’s a pretty well-known fact that these data silos, this inability to collaborate on information in a way that’s integrated into the way that people can work is driving really for one poor productivity. You have a lot of brute force work out there still, Now, that you have APIs available to integrate these things, that goes away. And there are industry stats that more than half of an AEC professional’s day is spent on. Things like managing e-mail, searching for project information, and so this is a real time suck, right?
Going back, you know we released our beta in late 2019, been in market now for a few years. Shaili, what was the availability like from Autodesk and from Microsoft PO core.
Definitely. When we started a few years ago, we started with the integration basically on the Microsoft side of things, and even with that there were limited APIs available with the older versions of SharePoint and it has come along really well now with the M365 stack where a lot of different things with M365 are now.
Integrated very well, but initially that that was not the case. There was a whole separate API set for SharePoint and just managing SharePoint and bringing those data points together was difficult. And with Autodesk a few years ago we started with BIM 360 and it evolved a little bit as we started the integration, but the original APIs with BIM 360 docs were very limited as well to We were trying to bring together the documents and even with those all the APIs were not available. So, we couldn’t really have parity in trying to bring these systems together because all of them had different sets of APIs and they all gave us different data points. And that presented a problem when we were trying to have consistency in everything that we were trying to do across these systems.
Joe
And now they’ve moved very, very far ahead in terms of what you can do with their different systems and interoperability. I mean, it’s been light years. I would argue too that a big part of this has been, you know, the cloud has been around for a while, It’s forever emerging. But the industry itself was way behind on cloud technologies. There were unique challenges for cloud computing, you know, the size of content in the case of Autodesk, you know, being able to.
Work with documents in a cloud platform without as much dependency on the rich client and all that’s emerged. But I would I have to believe and it’s what we’ve seen, I think is not as a result of the pandemic. There was suddenly a really rapid-fire push to get all things cloud. I assume you’ve noticed the same,
Shaili
Yeah, definitely we’ve seen that kind of availability where the services that were available on the cloud have improved and even within these siloed systems, be it Microsoft, Autodesk, they have tried to bring together internally the different things going on within Microsoft, within Autodesk and then having that overlay of APIs on top of it, which definitely makes it so much better for us to just connecting to all of these systems and as we’ve kind of progressed, these APIs have as well a lot of them have been available now giving us that flexibility to get all the data that we need from different systems and have that parity of features as well where we can connect to all of them.
Joe
Can you start a couple of the features where you believe there’s parity now?
Shaili
Definitely with the main feature with ProjectReady where we can connect and provision all of these systems. So, we have provisioning with M365 where we provision the M365 group we can provision the SharePoint site. We can security trim all of it by adding the owners, members as well as do library level security trimming of all of the data so by bringing in the M365 graph APIs and using the M365 groups that has made that possible where we can seamlessly provision all of these And then extending that parity into Autodesk as well, we can provision projects in Autodesk and provision those projects in Procore as well. And then with our other feature sets like with document control we have a lot of features where we can sync documents and with our document control functionality bring in the data as well as send the documents to and from all of these systems. So, there is parity across Microsoft, Autodesk, Procore, all of these. We are able to basically have our document control features across all of these systems.
Joe
Yeah. And it would seem counterintuitive, right? So we’ve watched Autodesk very early with Forge and Procore, you know, sort of following that charge that Microsoft has always been about interoperability, but they’re more of a platform as a service and infrastructure as a service versus Procore and Autodesk, which are sort of industry specific and bespoke, but what’s been driving it from?
What I’ve been seeing out there, and we’ve been seeing collectively is this is being largely driven by the demand of their customers, right? Because just think about ISO 19650 and the UK and GIIG where you have culpability to the owner to make sure all this data is correct, like for instance there was that building tragedy in London about six years ago. A whole bunch of people died in this fire principally because they couldn’t find any of the drawings to indicate what the engineered final built product was. So, they could effectively extinguish that fire. And so, this leads to a lot of lawsuits and arguably it sort of trickles down to construction management, project management, program management who each have in kind their own good cuts to mate, when you guys were ideating.
they couldn’t find any of the drawings to indicate what the engineered final built product was. So, they could effectively extinguish that fire. And so, this leads to a lot of lawsuits and arguably it sort of trickles down to construction management, project management, program management who each have in kind their own similar responsibilities. So even though you think it would be counterintuitive for Autodesk or Procore or Microsoft to be friendly with each other, this is being heavily driven by customer need. Now I would think too that for our friends at Autodesk, at Microsoft and Procore, this is actually good for them as well. I mean, there’s plenty of business to go around.
And given that you know no one company can be the one CDE as much as you know everybody would like that to be. This really, I think just stands in recognition of that reality. Anything you would add to that Shaili?
Shaili
No, I think definitely the need like you said where we’ve seen across the industry that there is a need for something to integrate these systems were at a project level. We have customers who have been using all of these systems for a project. So, you would need something that can overlay where you would need basically a way to collaborate and bring all of these systems together. And it’s not just that you would work in one system versus another, but the users who need to do the project management or managing the Project as a whole need a way to bring all of these systems together for sure.
Joe
Yeah, that’s a good point because you know certainly within project rate itself, we don’t tell folks don’t go to ACC, don’t go to Procore. If you have a design team that lives in ACC or BIM 360 then well they should but not everybody does and I think that’s really the moral of the story is that not every single member of a multi-phase, multi-company project is going to live in any one particular system and I think that’s what the industry is really recognized and trying to address definitely. So, I guess one other question too is you know what we see generally with the cloud is this notion of open APIs and actually just for one, for the audience, how would you define open APIs?
Shaili
So open APIs are essentially something that has been provided by all of these different companies where we can have an app or some sort of trusted connection. So, let’s say Autodesk and Microsoft and Procore and they have and using that they would give us access to a set of APIs which are defined by the company, and we are able to basically get access to the data within those systems programmatically. So, if we take an example of getting access to the different documents across these systems, we would need to use the APIs that are associated with documents for Autodesk and then Microsoft would have their own APIs where we can get access to the different documents and files and SharePoint and Teams. And the same thing with Procore where we would use the Document APIs to get access to the documents within Procore. So just using documents as an example, but they all have this standard set of APIs that are provided, and they use this concept of Restful APIs using which they have. All of them have basically a common format which makes that easy and they all kind of follow that standard of APIs. So that makes that consistent in a way we can get data and send data to and from all of these systems.
Joe
Yeah, and you know, going to pick up on one of my favorite phrases I coined, which is that the user experience is the new middleware. So, it’s kind of a good transition. So, these open APIs are important. They’re emerging, but in terms of best practices of their use, speaking for ProjectReady.
Bringing it into a very friendly user interface and very intuitive workflows so that you can collaborate on it, right? There’s project information management, but then there’s this really important layer that makes that work, which is collaborative project information management. And so in terms of the best practices, trying to bring this information together, not in some like data Mart or you know, piece of middleware with data aggregates which is good for reporting and the like, but really can’t stress enough That its presentation and the workflow around it and the governance around it is really what is tantamount to success.
So, on that basis, what would you think are some of the best practices as you know, customers out there would start to approach integration on their own with open APIs and the like. Any advice on the best practices around that?
Have a list of what you want to do, find out what you can do and then make sure that its delivery is in such a way that end users’ people day-to-day can. Get value from it without being overburdened with learning curve or going to too many interfaces. Really just a single way to get to it. So, you know it starts with what problem you’re trying to solve, what capabilities from these manufacturers are available, and then trying to find some way to bring it together so that people can actually action on it in a way that’s not too burdensome to end users.
Shaili
Yeah, definitely and I would think to go back to what you what you said earlier showed that the UI and the front-end side of this is extremely important as well. The getting started with the APIs is simple enough where we can basically Get that connection going, but then it’s important to understand what the end result is and what are the different data points that we are trying to get using these APIs. And it’s not just getting access to these data points and using the APIs, putting all of that into a data Mart or a database, but it’s more about what needs to be the end result, does it just need to be a report bringing all that data ahead or it needs to be more functional, where we can have some sort of a UI which is user friendly and intuitive to basically help us accomplish what the end result of the use cases.
Joe
Yeah, and one of my other aphorisms is the challenges with business continuity have nothing to do with the datacenter anymore because they’re kind of gone. Business continuity has to do with making sure that you have a way for your users to work continuously, right? To maintain that continuity and to build out those solutions in a way that you know it’s MVP, you’re always going to be releasing and improving. That’s what great thing about human endeavor is, is you always strive to do something better, but that usability is really tantamount to all of this.
All right, well, I think we’re coming to the end of this segment of the conversation. In our next podcast though, what we want to do is go deeper into some of the topics that we touched on today and really what is possible today as it relates to creating the integrated data environment. That is the only way that the industry can move ahead and really take control of profitability and reduction of risk. So, with that, I want to thank everybody for listening today and look forward to talking to you next time.