Journey Towards Data-Centricity with Autodesk Platform Services

GIULIO PAGAN: Hello, everybody, and welcome to this presentation about Ramboll's journey towards data centricity with Autodesk Platform Services. My name is Giulio, and I will take you through-- I'll introduce myself. I have here a representative from Ramboll, which we will introduce to you in a moment.

We're going to go through the problem statement, and we'll talk about the data-centric journey we are embarking in. And we'll cover some basic concepts, and we'll explain what we've been doing through demo scenarios, which we will follow by some conclusions.

So, without further ado, I will just show you briefly the safe harbor statement. I won't keep it for long. And, after that, I'm going to introduce you-- tell you a little bit more about myself. I'm a principal solution architect working for Autodesk.

By training, I'm a aeronautical engineer, but I've been practicing software engineering and solution architecture for over 26 years. And I like working with developers, partners, and customers alike developing solutions which are innovative and value-driven. And, now, I will let Puria introduce himself.

PURIA SAFARI HESARI: Thanks, Giulio, and thanks for having us. My name is Puria, and I am, by background, a structural engineer and a computational designer which have come to work with digital transformation for the past years and change management. And am currently leading Ramboll's computational design transformation program.

I have, during my years in the industry, become a software developer, self-taught software developer, and had the opportunity to work with development in the AEC apps and tools but also great projects like the Tottenham Hotspur Football Club, among others, during my previous position.

So what is it that we're going to dive into in today's session? Well, in Ramboll, we have, during many years, had realized what using files and not having a data-centric approach to project deliverables-- and how that can affect our employees and our projects.

Basically, the usual statement that we hear is that my data is locked in so many files. We have difficulties finding the right files that we're looking for. We cannot really trust the data. Is the data that I see correct? Is the data that I receive from my colleague-- is it the latest one? Has it been modified?

So this is really what the problem is about. And it affects us daily. We have information loss. We have reduced accuracy. We have security concerns, quality, trust, and lead time.

So why is this happening? Well, business units create projects or buy products to respond to a specific need with a deadline. KPIs, such as data control, quality, or reusable architecture are underestimated. And data repositories are created to respond to the needs of the application layer, application-centric approach, which is really hindering us from working from a single data lake.

So, now, I will tell you a bit more about the Ramboll's project data management and data centricity journey, which is the collaboration that we're doing together with Autodesk. So short about Ramboll-- we're architecture, engineering, and consultancy company founded in 1945 in Denmark.

We're present in 35 countries, but our strongest presence is in the Nordics. And we have over more than 18,000 employees. And you can just imagine how a data-centric approach would help all these employees to become more efficient in the way they collaborate and communicate with their data and design, but also with our clients.

And so what is the vision here? What is the big idea? Well, we want, in Ramboll, by 2025, to have widely adopted a data-centric approach to projects-- or to project delivery-- in which data is an open resource not tied to a specific application, that the data is readily accessible through a single source of truth, the data is easily exchanged across application, the data is suitable to support sustainability metrics for analytics, and that the data is actively managed and controlled.

And so the expected outcome that we're looking for here can be divided into short-term, medium-term, and long-term. And the short-term expected outcomes are basically improved interoperability and data handover in projects, improved collaboration and teamwork in projects.

The medium-term expected outcomes are sustainability metrics are embedded in our design in a consistent way, that we have improved quality and reliability in our deliverables, and that we have enforced standardization of production and delivery environment. The long-term ones here are opportunities created for expanded and diversified services and a common and trusted source provided for analytics and best practice sharing.

And so looking at this slide, I just wanted to take you through the roadmap here, and how it looks like, and where we are, and where we want to be. So looking at the five different columns here, we have the files and at the first stage, and then you might move over to working with data, basically, objects. And then you work with more richer objects, and you start utilizing the information on that.

And at the next stage here, you're starting to share knowledge and start to gain a lot of insight in terms of your data. And that can help you to make better decisions.

So talking about utilizing AI and machine learning for decision-making-- the end of this spectrum is where we want to move. And looking in terms of Ramboll and where we are, I mean, the landscape is really diverse in terms of Ramboll.

We can definitely have projects that could be around data and information columns. And we could definitely have projects where-- that we can [INAUDIBLE] the data. But we really want to find and utilize this program and this collaboration here, together, get towards the last columns.

GIULIO PAGAN: OK. Thank you, Puria. I guess it's a little bit of my turn to talk to you a bit about the kind of solution we've been discussing with Ramboll. But before we dive a little bit more in the details, I would like to tell you a few words about the concept of data centricity and also to show you a very high-level architecture which displays how-- if you want the anatomy of a digital data centric solution.

So, first of all, what about data centricity? Well, let's talk about a data-centric organization. A data-centric organization is one which would put a lot of effort, and it would invest resources into generating that relevant information-- so churning data into relevant information, which then they can effectively share to enable collaboration across the organization.

So, clearly, the focus, even in this definition, is on data, from which the term data-centric really comes from. And the reason why this model can bring benefits is because applications are effectively transitory. But the data, especially when you have the right data, data stays. It stays there for a long time.

So at the heart of a data-centric approach, there is importance which really gives to our major asset, which is data. And if things are done in the right way, then you can reap the benefits of such approach, which you can see here in this kind of donut.

You can certainly hope to eliminate or reduce the number of data silos, reduce data redundancy, facilitate a more effective access to data, but also more secure, compliant to certain constraints. You can simplify applications and simplify upgrades, make data more accessible, eliminate complex data transformation-- which is a specific scenario which we started exploring at Ramboll-- reduce data errors and inconsistencies, improve quality, and then, in general, also streamline data management.

So this sounds great, doesn't it? Obviously, it's the reason why it is a journey. And it is a journey that starts from the center, and this is very important. Now, how does a data-centric solution look like?

Well, a data-centric solution is also focused on collaboration. And it's a solution which provides an integrated environment which is capable of managing different types of data. And, in here, there is a summary of the kind of data you would expect to find in this context.

So we would have product-related information. It would be library of objects, for example or other product information which is associated to the design or manufacturing of buildings. Then you have information which is associated to a project, which is vital to the project execution.

Any relevant standard could be found in the-- managed by the block. You can have digital assets, status associated to each to each digital asset. Or, traditionally, that would be associated to a file. But this is a thing. In here, we hope to go beyond that and have-- enable, for example, the management of transactional data, like IoT data.

And another aspect which you would expect to be managed by the platform is data orchestration-- so the movement of data across the different parts. So this is a good opportunity to state that we should not-- while data is at the center of this, we are not suggesting here that all data will have to sit in the same repository.

And what we're talking about here is more the need for a single data model, which basically implies a unified and integrated vision around data. This is important. And the data-centric approach, also, is not to be confused with a purely data-driven approach. A data-centric approach is, in fact, complementary, I would say, to a data-driven approach, which existed already for many years, while the data-centric approach requires changes at all levels, not just the technology level.

So what's the vision? I'm mirroring here what we have already seen on this slide. Let me go back to it in a second. So you may recall this slide. And, now, I'm showing you here another cartoon which is showing, instead, how we want to change the sentiment of these users towards data we have to deal with.

So you may still have the same data input. But, now, the platform will help the users to regain trust with data. And that would help happen because the access to data is easier, so we don't necessarily need to download, for example, entire model.

We don't need to replicate data. We don't necessarily need to transform data all the time. And they can attach metadata to the entities, and they can also share, in an easy way, data with suppliers, for example.

Now, that sounds great. But let's now start to talk about what could be the first steps to move towards this vision.

Well, as a starter, we want to move-- so if you look at these bullet points in this slide, we want to move from a universe-- if these bubbles are the situation where we are-- they represent the present and maybe the ideal future-- you can see that we want to go from a scenario where we have low granularity, situation where it's hard to find data, where you have lots of proprietary and application-centric scenarios-- we want to move from there to a scenario where we have a finer, granular access to data. It's easy to find the data.

We have more data-- product-agnostic approach. And, now, you can see the relationship between the current scenario, the current situation in the future and the fact that, today, we are primarily shuffling files around. So we will hear, mostly, talking about this product model data or that product model data. And the data comes out depending on the applications you're using.

So we want to transition to a scenario where we talk more about individual type of entities and instances of doors and instances of reports or work panels. So everything is an object, and everything can be potentially related to another object.

Having said that, the files will not disappear for a long time. And, chances are, your best-case scenario, your platform may have to interact with other platforms. But, in some cases, you may have to import files into your platform and export files in the way that you have are dealing with that today. But at least, within an organization, you should be able to reap the benefits of the data-centric approach in your own little bubble.

Now, I want to also emphasize the importance of other aspects, which go beyond the way you organize the data. So we discussed so far the granular access to the data. But two other fundamental pillars to this are the journey towards having a more harmonized data.

We mentioned the need for a single data model. It might be necessary to invest into mapping external models to your model. But the reality is that a single data model is what will accelerate the journey, and it will allow you to really reap the benefits.

And in order to, again, to create a stable platform that also doesn't cost too much over time, it's necessary to keep an eye on the status of application landscape. So as we said before, the approach here is that the application layer should be built around the data layer. And this has to be reflected in the choices of applications.

So the applications should be chosen because of their ability to more easily interact with the data platform. And the purpose is to provide the core capabilities which you see listed at the top. So you want to be able to exchange data, by the way, access data, manage your asset lifecycle, manage your asset metadata-- so data about data-- and so on.

Now, this was a bit of an introduction in generic terms. And we're going to now start to talk about how we started the journey by talking more specifically about interoperability. And what do we mean with that? We mean trying to leverage a selected set of services for the purpose of facilitating vendor-neutral data exchange.

So, therefore, the solutions that we've been looking at so far is focused mostly on reusability, increasing the-- make it easy to access the data and make it easy for applications to exchange data. And you can see in this slide, this is a one-slide summary of, basically, what we've been focusing on. So you can see, on the right side, also, the list of the technology which we've been more specifically looking at.

And there is ACC, Autodesk Construction Cloud, as a flavor of software as a service. But we've been focusing our attention on how Autodesk AEC Data Model and the Autodesk Data Exchange and the number of data connectors can help to turn this vision into reality.

And we are doing this. Since the beginning, we have ambitious target, which we hope to achieve with our cooperation. It is a drastic reduction in process lead time, remove almost completely the danger of having accidental data losses caused by data transformations, improve significantly the trust in data, and, also, convince the other parts of the business that data has to live in the cloud for purpose of leveraging the cloud.

So, now, let's try to understand this in practice by looking at one of the first-- we picked a couple of scenarios. So we covered a few scenarios in our engagement, but we picked two of them for the purpose of this presentation.

The first one is about detecting changes of quantities across different versions of a Revit model. So what you're looking at here is a revised version of a model. Currently, when we [INAUDIBLE] process-- so the as-is process.

If it's as-is process, it's difficult to achieve this comparison. And we wanted to show that by using the platform services. This could be greatly simplified. So how does it work in practice?

The data is shared by different parties on ACC. And the data is extracted using the AEC data model API, which makes it fairly easy to compare elements from different versions of the files.

The comparison results are stored in a database, which then can be used for analytics. So in the initial demonstrations and prototypes, what we'll be doing is populating a database, which then we use to populate Power BI dashboards.

Now, a few words about the technology-- for those that don't know what I'm referring to, I'm sure you heard about this before. But the reason why AEC cloud information model has been picked here is because, while it would be possible to use other API, the AEC data model is really the newest, more intriguing and innovating way to have a cloud-based source of truth for building and construction.

And why is it so promising? Because it provides a great tool for developers through dedicated, also, interfaces, like GraphQL. It allows you to access data in an easy way, so data is, effectively, easier to access. And it provides a repository of objects.

So if you remember my slide about explaining the need to move away from files, it's a great technology that helps moving in that direction. So as you can see from this picture here, your model is effectively turned into a graph of objects which you then can access via the API. And the use of the API is facilitated, also, by data connectors, which will mature in time.

Now, how does the solution look like from a conceptual point of view? So the models are updating ACC, as I mentioned before. The interesting aspect is the ACC model will grow in terms of compatibility with multiple platforms.

This specific solution here has been tested against the Revit file versions, but the specific business cases could change without necessarily impacting this architecture, which is the interesting thing. So there is a reusability in the architecture here at play.

Now, the models versions are compared, and this is done by querying the data. So, for the first time, it's actually almost there-- the possibility to treat ACC as a database of objects, which is why this API is particularly interesting.

And we also use the Schema Editor available from Tandem to create a reference asset classification. And this validation tool, which you see here-- what it does is to compare the content in terms of values of properties and is checking whether the property exists in first place in the reference schema.

It can also calculate-- within the dashboard or up front, it can calculate quantities and the quantities of error reported on a dashboard. And you're going to see two demo videos. The first one will show this solution in an automated way, and the output is shown in a dashboard.

So the idea is to periodically run this process to validate to make sure that the models across versions don't have significant differences. But you also see how you can create a web application to perform a same analysis on demand. I'm going to kick off this first video, and we'll provide some comments.

So this is the-- we're going to load the model in Revit, first of all. And what we're going to do is to make some changes to the geometry. So for this specific example, we use some test data.

So you can see here, the master bedroom. I'm making a small change in the geometry. And after that, I'm saving the model, which gets stored in ACC as a new version.

So what happens under the scene is that this data becomes available for extraction via the AEC data model API. Now, what you can see here is the user configuring a Power Automate script to point to a specific order in project and account hub.

And it's using a JSON file to specify what exactly is-- from wherever data is extracted and which versions are to be compared. So this is-- and, also, there is something called elements properties filter element, here, which is an example of how it's also possible to confine, for example, the comparison to certain properties when comparing that.

Then the workflow is executed automatically. And this could be triggered, for example, when a file is dropped in the folder. Or, in this case, it's just manually triggered. When the workflow is successfully executed, an email is sent to the user, and the data is stored in timestamps in an SQL system.

And from that moment on, the data becomes historical data, which is available for analysis purpose. And you can see a very simple dashboard here which shows different rooms which have been analyzed. And the system detected that there are differences in the values of the area and perimeter and [INAUDIBLE].

This is a process which, in some scenario, is not tackled at all. And that can lead at big issues. And although this problem can be solved in different ways, the approach here is particularly interesting because of the possibility to work in a way which is effectively independent from the original data products-- products they use to generate data.

OK, now, I'm going to show you a different demo, which is basically using the same services. But, in this case, the analysis of the two versions is going to be fed directly to the website that you can see here in this slide.

So I'm selecting from a portal, in this case, the models to be compared. So this would come from ACC, the list. And then, also from ACC, I would get a list of versions, and I will be able to choose the ones I want to compare.

And the difference here is that, instead of relying on automation, I would execute directly a comparison of two models. I would use the services of the platform to, here, load in the same scene two versions. And in the table below, you can see the comparison results.

The models are aggregated in the scene, so you see them overlap. You can see many differences because the differences are small. But, now, if I click, I can also-- yeah, I can see where the values are different, but I can also click on an object and find the object there.

And if you pay attention, you also see, to the right of the object, also, some elements which are different in geometry across versions. Yeah, exactly.

And so this is basically how to compare, with a fairly straightforward website, two versions. And you can then accelerate the fixing of the problem.

And now I'm going to describe a second workflow which I will let Puria demonstrate. This workflow, we've been investigating the use of another emerging API, which is actually fairly mature at this point in time. It is just Data Exchange, Autodesk Data Exchange API.

And this API grants access to the data, which can be stored in ACC in something called Data Exchange. So in this workflow here, what we're going to do is update or create a model, identify which parts of a model we want to export, create certain views which represent the elements which we want to extract.

And this will allow us to create data exchange, which is shared via the platform. And you can actually see exchange in ACC, and you can view it before the data goes anywhere else. But what you can also do is when the other engineer-- in this scenario, an external engineer could-- or an architect, in this case-- can open their application can connect to ACC, browse to the data which has been exchanged, and import the data in Rhino.

Also, this is a fragment of a workflow. But the specific scenario which we studied is, basically, the round-tripping of this. So starting, actually, from Rhino-- you're going to see in a minute-- we send it to the Revit and back.

The technology we use, as mentioned, is Data Exchange, which is built on top of our platform. It provides an API, but it also provides several out of the box connectors, which we leveraged to do the first evaluation.

Yeah, at conceptual level, the architecture is pretty simple because, basically, we are-- in this first phase, we simply used the out of the box connectors to send the data from Rhino to Revit and back. Now, I will let Puria explain what he has been focusing on with Rhino and Revit.

PURIA SAFARI HESARI: Thanks, Giulio. So looking into this work flow, while the video is starting, I think it's also-- we have really tried to push this workflow to its limits.

We have also tried, as Giulio described, sending data in both directions, going from Revit to Rhino and back, but, also, from Rhino and Revit and then go back but, also, at the same time, receiving data from Revit in Rhino and then referencing that data in Grasshopper and manipulate it and then send it back to exchange to the Revit model, et cetera. So it allows for a lot of flexibility.

And to take you through the video and how we've done that-- and so we're basically here, starting with the massing model in Revit. And this could be a scenario in the very early stages when we're evaluating different design options and architectural disciplines.

And so what we do-- we're sending this data through the Data Exchange and allow other designers to tap into this and to utilize what already exists as kind of a starting point or as a reference geometry to start building up other parts of the system.

So here, for example, we have a facade engineer, where he, in Rhino, and loads that exchange which has been uploaded to Data Exchange and get that data here in Rhino for the reference geometry.

And so what the facade engineer and designer can now do is to reference the geometry here to a Grasshopper script and easily generate different variations and different options and create multiple versions of this and upload those to the Data Exchange for the rest of the team to review and to test out and evaluate.

So here, for example, we have a triangulated facade, where sails are randomly placed on some of the rectangles. And that can be varied back and forth. So we can create different exchanges, if we would like to. But, here, we're only just sending one, the one that we just created and looked at. So we're creating a new exchange here using Grasshopper.

Once we've done that, there is a reference to the exchange. And, now, we use the Send component and send the data, basically. And this is basically what I mean with the flexibility that it allows. You can take any route you want with the different Data Exchange connectors.

And now coming back here, we can see the facade geometry being loaded to Data Exchange from Grasshopper. And so what we can do is, basically, again, go back to Revit and load that geometry here. And if you would have multiple versions or would get a later version, another version in a later stage, it's just to switch that and reload a new exchange here.

All right, so this sums up the demos and the scenarios and a few of the scenarios that we have worked on that we wanted to share with you guys. But, moving forward, I would also like to share some conclusions that we've come to and challenges and the benefits that we have found and share that with you during this journey, which has just started.

So the benefits from our candidates here and the people that we have worked with in different projects that have been testing these different scenarios and workflows-- we want them, and they believe that, by us adopting data-centric platform services, and Ramboll will be able to achieve 50% less time spent searching for data issues, 80% data quality increased, less than 30% shorter lead time by bringing forward the problem detection, 30% to 50% reduction in process lead time, virtually remove accidental data loss caused by data transformation, 100% increase in data trust, and 100% migrated to the cloud.

So by adopting the data-centric platform services, we can definitely achieve a lot of great values here. So what was the objectives that we set up starting this, and what was the achievements here?

So we wanted to understand the challenges and evaluate the benefit of a data-centric solution for better project data management. And we also wanted to demonstrate the current capabilities together with Autodesk of the Autodesk Platform Services to support project delivery. So what did we achieve?

We have successfully managed to demonstrate how Autodesk Platform Services can make data-centric project data management a reality. We explored how granular data-- granular access to data benefits both interoperability and data validation quality. And we have, in this initial phase, provided an effective way to better understand the needs, promote cross-vendor cooperation, identify new opportunities, and influence the product roadmaps.

GIULIO PAGAN: And if I may add, Puria, to this--

PURIA SAFARI HESARI: Of course.

GIULIO PAGAN: --this first phase, which was an exploratory one, it was also particularly useful for us. So I work for Autodesk Consulting, and it was a really great cooperation, also, with the platform team, which is working hard to help customers. And it was a great way to see a close collaboration to make sure that the product goes in the right direction.

PURIA SAFARI HESARI: And so looking at some challenges we had and some feedback that we've gathered from the people that we have worked on from the project teams and when they have tested out the workflows that we have suggested-- I mean, the overall feeling and the feedback is great. They're really happy to be a part of this journey, to be a part of setting the new standards in terms of working in a data-centric way.

And what we have achieved so far-- it's, overall, promising experience for easily round-tripping data between applications, which we saw in the last demo video, exporting data for data analytics and visualization, right?

But we also want to be clear about the Autodesk Data Exchange and AEC Data Model are in beta stages. So there are sometimes some issues to be expected. But that is something that we hoping to be able to collaborate together closely with Autodesk to mitigate as we go forward part of this collaboration.

We have had a great conversation with the Autodesk Consulting and the Autodesk Data Platform Team so far. We have already started discussing some of the issues that we're talking about-- for example, loading data exchanges can sometimes take time. They're listening to that feedback and taking it seriously, looking into this, which we really appreciate.

And there might sometimes be limitations when we exchange data types across different applications. And in the Rhino-Revit scenario that we looked into, we have had some reports from some of our users that tested the workflow that objects sometimes are only available as direct shapes, which can be a limiting factor.

And so, as mentioned, we're early in this journey. We're testing the cutting-edge stuff out there. And some of these tools and the platforms and the services that we use, they're in beta stage. So that's really to keep in mind. But, still, we're-- I think, from my side-- have come a really, really far way already this year and, specifically, working with [INAUDIBLE].

Well, thanks a lot for listening. It's been a pleasure to present what we've done during the last year to you guys. Yeah, thanks for joining in, and thanks, Giulio, for-- thank you for doing the presentation.

GIULIO PAGAN: And thank you very much for myself, as well. Thank you, Puria, for your very encouraging comments. And I'm looking forward to keep helping you guys in your challenging but rewarding journey towards data centricity. Thanks. Thank you, everybody. Bye.