The Future of Data: Forge Data Platform.

CARLOS VANEGAS: Good morning. Can you guys hear me fine? Excellent. All right, so thanks for joining today to participate in this conversation around data. This talk is called The Future of Data-- Forge Data Platform. And we're going to be talking about what we're currently doing in Forge in the Autodesk platform around data. How are we preparing data to support the future needs of our products and all the products that we'll be building on top of our platform?

So thank you for being here, by the way. I know the CEO keynote is going on at the same time. So this shows a lot of commitment from you guys that you decided came to this talk. So data's an incredibly exciting topic, right? And the reason is that when you start talking about data, right, whether it's data descent or a common data environment, or one place for data or however we want to call it, the reason this topic is so exciting is that a lot of people actually care about it, right?

And it seems to us that many of you are also looking at Autodesk as the company that is expected to be solving all these problems around data, at least in the domains of architecture, engineering, construction, manufacturing, and production. So again, I'm here today to, first of all, acknowledge that this is a problem for Autodesk to solve and also acknowledge that we're fully aware that this is the single-most important thing that we have to get right in order for everything else to work well. And then, again, we're going to talk about not only the solutions that we have been building so far as part of our internal advancement on this topic, but also we're going to talk about how we are approaching the problem and how we think that data needs to work and how we think that the engineering and architecture around data needs to work going forward.

So I have to start with a safe harbor paragraph. I'm going to assume that everybody just read it. And this is not the most exciting slide in the presentation, I promise.

So I'm currently an architect in the Forge Data Platform. I'm based in San Francisco. And I've been at Autodesk for about four years now. The reason that I joined Autodesk, instead of a bunch of other software companies that are out there in the Bay Area, is that I am really excited, truly excited, about what Autodesk does. I'm truly excited by all the things that our users and you guys and your users build and design using Autodesk products, whether it's a skyscraper, an airport, a movie, the Tesla. It's the amazing stuff that gets created with our technology.

And our software is used to really design and make the things that have a huge impact in the world and in our everyday life. So having the opportunity to at least try to contribute a little bit to that technology is very exciting and something that I'm really grateful for. Now, over more than 30 years, Autodesk has been developing a tremendous amount of IP around all these industries, right, again, manufacturing, entertainment, media, construction, and architecture, and so on.

So where we are today is that each of these products, if you look at them, it's fairly successful in the domain, in the industry, in the verticals that they serve. But a big challenge that we face is that the IP of these products and the data itself is kind of trapped in these products, right? And so when you have data that is slightly coupled to the product, that's actually advantageous for a number of reasons for the product itself.

You can make assumptions about the structure of that data. You can optimize the design of your business logic around those assumptions. And so there's really nothing wrong with it when all you care about is your product And when everything that you're trying to do is kind of captured and contained in that specific product that you're designing.

So nothing wrong so far, right? The problem is that when you also keep the data locked in that product, as we're going to see, it leads to two obstacles that makes it difficult to do the kind of things that we would like to do with these products when they are working together. So let's look at an example.

Let's take a look at Revit. And I'm not going to go into the details of the architecture of Revit or any individual product. But the story's kind of similar for all of them.

So again, there's a very high-level, very traditional architecture stack for Revit. At the top, you have a presentation layer. That's where you have your user interface and all the interactions that your users would do with the application that is underneath. Then you have the business logic. It's also typically specific to Revit. You have a lot of algorithms and methods and functions with domain-specific business logic.

And then further down you have the data layer, which is the thing that handles all the logic and operations around data models, around data management, around data persistency, right, so again, a very generic architecture stack. So real quick, which of the people in the audience are software developers or architects or coders? OK. So we have about one third to half of the room in that role. Great.

So ultimately, Revit goes down to store whatever data it needs to persist, typically to a file, in this case, an RBT file. And that file is stored in your hard drive or a remote location. And next time that you open Revit, if everything goes well, the file is going to be there for you to continue your work.

Then some other times you have to do collaboration, right? You have to exchange that file and share that file with somebody else. And then for some use cases, you also have to translate the file into another format. So that's how most of our applications operate today.

Again, nothing wrong with that. When you look at Revit in isolation, it's a pretty fantastic tool. It's very successful. It's use in hundreds of thousands of projects in the world every day. So the whole Revit data model, which is hierarchical, it works fine, and there's really nothing wrong up to that point.

Then you look at AutoCAD. You look at Inventor. You look at Fusion. You look at Siebel 3D and all these other products. And the architecture stack will be very similar, and the persistence is typically going to be files.

But we know that our users and your users on their day-to-day work, they typically employ many different tools. It's not just Revit. It's not just AutoCAD. It's not just even Autodesk tools. There are hundreds and hundreds of applications that are part of the workflows that the users are trying to complete every day.

So one of my favorite examples to illustrate this is this graphic, this image, that we use a lot at Autodesk and other companies that are involved in BIM also use. And it's the BIM lifecycle, right, or the BIM process. And some people even call it the BIM happy wheel.

And so in this lifecycle, you start with a program. Sorry, if this is redundant to a lot of people who are experts in this field but just level setting the room. So you start with a program. You go to conceptual design stage. You go to a detailed design.

Then you analyze that detailed design and how well it meets or it fits your goals or constraints. And then you document what you're trying to build. Sometimes there's a fabrication process involved, and then there's a construction process involved.

Then it goes on to operation and maintenance. And sometimes you even have to plan the demolition and the renovation of the structure. So the point to note here is that in this process, in this lifecycle, there are many applications that need to be involved, right?

Revit cannot handle all of this lifecycle. It's a very important tool in some of these stages. But it's by far not the only tool that is used as part of these stages. So where does that take us?

Well, so, that's an example in BIM. But in general, we see the same patterns and make a similar argument for pretty much any complex workflow, especially workflows that combine the design and make. And if you've been listening to Autodesk for the last few years, this is an area. The convergence of design and make and the interfaces between them is something that we are very interested in at Autodesk.

So we care about interdependencies between the things that we design and the things that we make and the things that ultimately get built or manufactured or produced. Yesterday, our VP of Forge, Sam Ramsay, gave a keynote where he said that we are building at Autodesk, the world's first design-to-make platform. So this interoperability problem that I'm describing here, helping the data flow smoothly and frictionless between applications is something that we care about very much today.

So what has been the solution that we have offer up to this point? Because people are exchanging files, and people are moving files from one application to the other. So think of these gray boxes as walls between the applications, right?

And think of those walls as the boundaries, as the dividers between those applications. So although the stack of these applications, as I'm showing, is fundamentally the same. At a very high level, each application kind of has followed a different approach to implement their presentation layer, their business logic layer. They do different UIs, different widgets, and so on.

And crucially, the data layers are also different, right? So we have a bunch of standalone applications that are built for specific purposes, all of which have different approaches to data. So the data back end is different. The persistence mechanisms are different. The file formats that they use to keep that data are different.

And so a lot a lot of complexity arises from these differences, right? When you need to manage aspects like versions and collaboration between users and access to data and history of your data, multiple legacy formats in files that our users may work on not only for days, but sometimes for months or for years, then it becomes a really challenging task to manage all this diversity of approaches to data. And then also you end up with this need to be constantly translating between formats, right?

So it's one of the negative aspects of this approach. So you need to carry that data from one domain to the other. You end up translating from RVT to SVF to the DWG and so on.

So we end up with something like this, right? We end up with a bunch of point-to-point connections between all of these applications. And there's really nothing in the middle, right? That's where things like the Forge Derivative Service, the Forge Translation Service-- are you guys familiar with those services? Just taking a look at how many of you use Forge today. OK, so a bunch of you in the room.

So that's why we use those services, right? Because we need to be creating derivatives and creating translations from all of these files. And that's fine. In many cases, that translation is all you need to complete simple workflows. And again, our users do a lot of amazing stuff today with that technology.

But that doesn't mean that there's no room for improvement in how we do things today, right? There are several limitations with this approach. And I'll mention just a few.

So this architecture doesn't really tell us where the data goes, right? It doesn't give us a data persistence mechanism that is independent from any of the tools. This architecture, again, it kind of lacks something in the middle.

In some cases, you lose information that might be relevant. And because that is being translated back and forth, there's loss of information. In some cases, you really cannot follow workflows as smoothly as you would like to because the translation takes a lot of time. So you guys hear about generative design all the time. Imagine you're trying to explore a design space, and you have to create thousands of samples or millions of samples in that the design space.

And every time you're trying to create a sample and trying to evaluate the fitness of that sample against some objective function or some goal that you establish, you have to do a translation of files. The problem becomes very slow. It becomes intractable. It's not an approach that is going to let us through the kind of workflows around generative design and insights and machine learning that we want to do at Autodesk.

So these are limitations that we are fully aware of, right? And that in order to address, we believe that we have to take a fundamentally different approach to data. So why do we care about this? Why do these limitations matter?

Well, we care about our users, both the developers that are using the platform and also the end users that are using our products and that are using the products that all of you guys build. So these are the kind of things that we're hearing all the time. I want to use my data in multiple Autodesk applications, right? I want to use data from Revit. So this is a more specific example of the quote above. I want to use data from Revit to drive changes in my Excel spreadsheet and vice versa.

There's a few more here that are really cool. I want to see data from multiple applications in one place. This one happens all the time. I have to be able to add my own data that nobody else will delete, right? So there is an expectation. There is a need to have some sense of ownership over the data and to be reassured that as a user and as the author of that data, you are in full control of it.

Take a look at this one. This one is specific to AEC. I need the things that I learn about the design decisions during the pre-construction stage to carry through to construction and operation. So this one takes us back to the BIM workflow that we saw before, right? People want their data to not become useless once their phase of the workflow is complete, right?

They want their learnings and insights to have value in the phases that come after. So let's just do a quick check here of how much you guys can relate to the things that we're hearing and seeing in this quote. So please raise your hand if this sounds familiar to you, if you've heard it from your customers or if these are things that you care about just, a quick show of hands? So this is clearly a very, very hot topic and something that we have to solve.

So hidden behind these needs are existing limitations in our technology. But one thing to note here is that these limitations are not specific to any given product. We're not going to solve these problems. We're not going to address these concerns by adding a couple of features to Siebel 3D or to Revit or to InfraWorks, for that matter.

Also, we don't control many of the applications that our users, you employ in their workflows. So it's not like we can go and make changes to Excel to better address this problem. So this is pointing to a much more fundamental problem that is all about data. And what we have come to realize is that in our users' minds, data comes first, and applications come second.

So it has also become clear to us that throwing data over these walls, which is essentially what we do today, is not going to be enough, right? That's not going to solve the problem. What we really need to do is to start breaking these walls.

And so the next question that we're trying to answer is, what's the right place to break these walls, right? Do we do it at the presentation layer? Do we unify user interfaces and interactions for all of Autodesk products?

No, there might be some standardization at some level that kind of makes sense. But we're certainly not trying to standardize all our UIs. And it also wouldn't really be the best decision for our users because the user interface that you want, say, a structural engineer to follow is not necessarily the same user interface that you want a construction manager to follow. So we're not seeking standardization, or standardization at that presentation layer is not going to solve the problem.

Do we break the walls at the business logic layer? Again, probably not. Some of the logic, some of the business logic may be common, and there's opportunities for re-usability. But a lot of it is, of course, unique to specific domain needs. And in any case, unifying the business logic is not really going to do much for data interoperability.

So what we have realized is that data is the layer at which we want to start breaking these walls. We want to provide customer experience that are tailored to the domain. But we know, we realize, that the data kind of naturally needs and wants to cross boundaries.

So that layer, that attempt to break this wall through the data layer, that is Forge. That is the Forge Data Platform, and it's our response and it's our key tool to break the walls, to allow data to go across application and domain boundaries. And as you will see, we will use the Forge Data Platform to improve interoperability not only between out Autodesk applications, but also with third-party applications because again, our users are using all of those applications in their day-to-day work.

So we define the Forge Data Platform as a collection of platform components that supports common data modeling and data management needs of Autodesk applications and third-party applications. Let's take a closer look at this definition. So the needs part is a key thing here.

We start with the needs that are coming from many stakeholders, both internal and external, or although we're focusing first on our internal products. And those needs, at first they may seem very different. But there are still many commonalities between them, and those are the commonalities that we're trying to understand.

So we're synthesizing those needs into a smaller set of concepts and into a common architecture. And that's where the Forge Data Platform comes in. That's where a platform makes sense. It's serving a collection of common needs that then many products can build on top of and can take advantage of.

So let me be a little bit more specific, right? All of our products have needs around data, right? The products that we build, the products that you guys build have needs around data. And as we all work to make our products more cloud centric, we kind of tend to do the same thing. We go and spin up our own databases, and then we go and take care ourselves of our own collaboration tooling.

If we need to synchronize files, if I need to make changes and you make changes, and then we have to reconcile those changes, we try to build this tooling ourselves. And then we set up our own resiliency and security infrastructure and our own data models. So that's fine. Again, that works. And I'm sure we're all building great technology with that kind of approach.

But is that the way that we want to be spending our time? Does it make sense that every time we build a new application, we're kind of spinning up all these databases on our own and kind of managing these databases and taking care of these other problems on our own? So we believe that Autodesk products and then your products should have access. The product of people that are building on Forge should have access to a platform that does all the heavy lifting around data for you instead of asking you to do it yourself. And so that's the Forge Data Platform.

So as I mentioned, we are first focusing on building our platform for our own products. And there are two fundamental reasons for that. First reason is that if we test the platform against our products first, we are going to be testing it and validating it and making sure that it will really be sufficiently stable and robust when we put it in the hands of all the people that are building applications on top of Forge, all the third-party developers.

The second reason is that once we have Autodesk applications plugged into Forge, then it's going to be very easy to start feeding the platform with data. And the platform needs data before you can do anything useful with it, including workflows. So we need Revit and AutoCAD and Inventor and all these other tools to start feeding data into the platform. And we need to provide the mechanisms for these applications to feed that data in an easy way.

So why am I telling you all of this? Because those of you in the room that are using Forge or that plan to use Forge to build your applications, you're part of this community. If you attended, again, Sam Ramsay's keynote yesterday, he said something like, it's everybody's platform. Forge is everybody's platform. And we deeply believe that.

And so you're part of this platform, as much as any other Autodesk engineer is. And we think that you, as members of this community, need to know where we're going and need to know how we're getting there. So again, what we're doing here is putting together a unified architecture that addresses common needs around data management and data modeling.

And there are many benefits that we see in unifying these data architectures, as opposed to having them in separate silos. So let's talk a little bit about those. For our users, our end users, having a unified platform improves interoperability between applications. That's one of the main things we're going after.

It also enables workflows that are not possible today, workflows that are a lot more complex than what people can do today. It also means that you will spend less time massaging, converting, and linking data. And it will mean that our users will be able to get insights and advance querying. And we will make machine learning applications available that will help extract information and make sense of potentially huge amounts of data.

And then the benefits for Autodesk is that when we unify data architectures, it's going to make it easier to maintain all of the infrastructure and the services and the components around data. And it will also help us increase for usability, and it will help us guarantee scalability and resiliency of the platform components that we're building. So taking a step back, remember, the architecture on the left reflects an application-first data-second kind of mentality.

Where we're going with the Forge Data Platform is something that looks more like this. You have data at the center. Again, data comes first. And applications come second, right? We're forming this common data environment, where you happen to have different experiences, right, different user interfaces and different business logic that connect to the data, that consume the data, and that can contribute back to the data.

But the most important thing to note here is that the data exists regardless of the application that was used to create it, right? The data doesn't die, doesn't disappear when the application goes away or when the application stops in whatever stage of the process you are in. So that's very important, right? Decoupling the existence of the data from the existence of the application is something that we care a lot about.

So s where are we now in this data platform journey? Our applications-- so we're starting here. Our applications are internally becoming more cloud aware by integrating their data models deeper into the platform. They are starting to enable new and innovative user experiences that we were not able to do before.

And I'm going to show you a couple of examples to just give you an idea of the kind of things that we are now enabling today. So this one, this first one here, comes from a project called Project Terra, internal project. What we see here is an Excel spreadsheet with data about boreholes, which was created by a geotech specialist. So Excel connects to a project that is supported by the Forge Data Platform and shares some of the data in this spreadsheet.

And then there's a civil engineer that connects her AutoCAD model to the same project and retrieves the borehole data from a shared space. Then another civil engineer joins and retrieves the same data set from his InfraWorks model and puts in a request for a wellpoint. All these data exchanges can happen synchronously or asynchronously. And all these changes propagate through the system without the need of exchanging any files.

And then, while all of this is happening, stakeholders, like this manager here, can get on-demand access to the latest changes. Again, no files are exchanged in order to enable to support that work, right? It's not because there's anything wrong with files themselves, but simply because we don't need them to do this kind of data exchange.

Each of these applications is still using locally the same files and the same file formats that we are all used to. And that's fine. We don't expect that to change anytime soon. But it is the Forge Data Platform that is enabling the exchange of data and the flow of data between all of these and managing the data exchanges between all of these applications.

A second example that will be covered in detail in a talk that is going to take place later today shows measurements that are extracted from Revit and are pushed into Excel. And then there's-- it's all through the platform as well. And then there's another user in Excel that connects to that same project and extract the measurements. And in this case, the connection is life, right? As Revit's making changes here, Excel is consuming those changes in real time.

One thing to note here is that this is not a point-to-point connection between Revit and Excel. It's not like Revit and Excel are agreeing on a translation format or a data exchange format. That only works for that pair of tools. They're only agreeing on some reusable and common constructs that are defined at the Forge Data Platform level for how they're going to exchange the data. But it's not specific to that combination of products.

So again, those constructs are the same, regardless of which products we are connecting here. So if you're more curious about this specific workflow, there's a talk about Forge workflow automation, which is happening today, I believe, around 3:00 or 4:00 PM. And you can learn more about what we're doing with these workflows.

So a third example shows a user that is updating properties of a suspension model in Fusion 360. And those changes are pushed down to a shared space, also managed by the Forge Data Platform. And the changes are then reflected in a standalone and custom-built web application.

So in this case, some of the properties from Fusion 360 are, again, exchanged. And they're publishing this application running on the browser. One thing to note in this particular example is that one app is running on the browser, and the other app is just-- it's just Fusion. So the Forge Data Platform is not unique to desktop applications.

Remember that the data comes first, and the applications come second. So we don't really care about what kind of application you're building. You can still connect to this data platform. And once again, it's not a one-to-one connection between a web application and Fusion. And in this case, we happened to build this web application that is connecting to the platform and to all the storage that is there.

But you could build some other web application that will connect to the same space or to the same data back end. Or you could build a microservice that is going to do some computation or some simulation simultaneously. So we're not interested in point-to-point connections. I cannot overemphasize that enough. We are interested in a shared data environment.

So again, where are we now? We are starting to connect our applications to the cloud via the Forge Data Platform. This greatly facilitates the flow of data between applications with different data representations. And our applications are also starting to learn how to talk to the cloud by using new APIs and new SDKs in the Forge Data Platform and other tools like adapters and connectors.

One thing to note here is that this approach also allows us to represent access to data in a much more granular format. So typically, when you need to give somebody else access to your data, you exchange an entire file, or you select the file, and you say, I'm going to share this file with these people, with these collaborators. I'm going to give write access or read access or commenting access or whatever you need to do.

But you're granting that access to your entire file. You cannot be selective about which parts of the data you're going to give access to. So what we're doing here is allowing users to be more selective and more intentional about the parts of the model that they want to exchange.

So we're very excited by all of these advancements. We think that these are all steps in the right direction. But we want to go deeper than this. And that's what I want to talk to you about now.

So where are we going? We're looking at how we can model application data directly in the common data environment. We want to achieve deeper integration with the platform by looking and by reusing data models that are defined at the platform level.

So we're providing core concepts that serve as building blocks of data modeling and that have greater alignment and greater agreement across our products around those core concepts. So we think that by achieving that deeper level of integration, we will not only reduce the need for translation across formats, which is something that we definitely want to do, but we will also take interoperability to a whole new level So remember that we mentioned that the Forge Data Platform supports common data modeling and data management needs. So that's where we're starting as part of this next step. We're taking a look at what those common needs are.

So let me bring us a little closer to what we're doing here. We're asking ourselves, what is common across all of these applications that we have at Autodesk, right? So think about this for 10 seconds, right? How is AutoCAD similar to Revit and similar to Inventor and similar to InfraWorks? What's the common denominator across all of these applications?

So this is a question that we've been asking ourselves for a while here. And the answer that we're giving is that most of our apps in our ecosystem are used to model proposed or existing systems. That's what our applications are about.

And you can look at cars, at buildings, at breaches, at even movies as complex systems. And these systems can be mechanical or architectural or automotive or electrical or whatever. But we need common tools to model those systems.

And so now what we need to understand is how do we model a system, right? And then going back to systems architectural literature, a system is defined as the conjunction of form and function. So the key things to understand about a system are the form of the system and the function of the system.

The form is what the system is. The form is what exists. And the function is what the system does, right, what happens over time. So we are first starting with form. Then the form of a system is dictated by the objects that make up the system and by the relationships between those objects.

And so the next natural question that we're asking is, how do we model objects? How do we model relationships? And also very important, how do we define and extend object types and relationship types? So see how we're breaking down the problem. It's a very complex problem, we think. We're breaking it down into smaller chunks that are more manageable.

And just as we're looking at data modeling needs, we're also looking at data management needs. So the questions we're asking around data management are, what is the extent of the system? Where does the data live? And who owns that data? Who has what access to which data? How do we surface relevant data, either through search or querying or filtering? How do we support concurrent and collaborative data operations?

How do we facilitate data exchange between users in different organizations? This is really important. This is something that our users come to us looking for help. So I'm in this firm. I need to exchange data with a collaborator that is in this other firm. How can we do that in a secure way without getting ourselves into any legal or liability problems and making sure there's always a clear understanding of who owns the data?

This one is also key. Who has done what when? All of our users, many of our users are asking for audit trails. They want to understand the history of data. They want to understand when this change was made and who is responsible for that change.

So let's go over some of these data modeling questions in a little bit more detail. One of the questions, again, is, where does the data live, and who owns that data? And so we're providing this concept of a space. I'm just going to tell you the answer is that we're starting to provide to these questions.

We provide this concept of space, which is a place where we put the data. A space also has the characteristic that all the data that lives in that space shares of common history. And we attach a space to a scope, which is basically a container for managing users and entitlements. So when you attach a space to a scope, you're essentially dictating the ownership of the data in that space.

So one thing to mention here is that we are exploring change-based representations as the primary store for our data. This is different from what we do today, right? Today we store the whole state of the data. And when you make changes in that data, you go to the next version, and then you're storing the state of the data, the state of your model at that next version, right?

So we see a lot of advantages in having change-based representations. So the first thing is it collaborates-- sorry, facilitates collaborative editing, things like branching and merging and other operations. It also significantly reduces the storage space that is required to keep the history of your data. The history of the data is fundamental.

If you've used Google Slides, Google Docs, any of these applications, you will see that there's a history panel where you can go and look at basically the history of your entire documents since the moment you created it. So by using a change-based representation, what we're saying is, hey we're just going to store the deltas. We're just going to store what changed between one version and the next instead of storing the entire state of the model at every step.

It's also easier this way to, again, support transaction logs, audit trails, versions, and so on because you're already kind of storing all of that information as part of your history. So I don't know. Did anybody attend the previous version of the Forge Developer Conference, either last year or the year before? OK.

So we have this technology at Autodesk, called HFDM, which is basically a data persistence platform component that stores the data based on changes. And you might have heard about HFDM in previous instances of the Forge Dev Con. And so since then, it's still making progress. I'm sorry?

AUDIENCE: [INAUDIBLE].

CARLOS VANEGAS: What does it stand for? High-Frequency Data Management. Yes. So you might have heard about it in previous conferences. We've been making progress with it. We've been maturing it, stabilizing it. And it's the primary data back end of all these things that I'm telling you about and all the demos and videos that you're going to see here.

So for the coders in the room, since it's about a third to half of the room here, just a little sneak peek into what this could look like. When you're creating a space, you have a client SDK. This is a JavaScript client SDK, but we're working on client SDKs for other languages, including C++, which is what a lot of our applications use.

And so it's very simple, right? You're just creating a space. You go and say, create space. You give it a name. You give it the URN of the scope that you're going to attach this space to. And then you end up with a client site object that manages that space.

The next question is, how do we model an object? So we're introducing this concept of assets. Assets are what are what we use in the data platform to model objects. They are tracked in the space, which, again, maps to an HFDM repository.

But the content of the asset may live internally or may be fully contained in the asset or maybe just a reference to an external file. The asset is also uniquely identifiable, and it can be named. It can be related to other assets, and it does not need to be typed. I'm going to talk a little bit more about this.

So again, going back to our little example, you create an asset, and you just say, I'm going to call it My Desk. I'm going to specify the URN of the space, where this asset is going to live. And then I get a client site object, which is called Desk. Then I do the same thing for a lamp. So far so good.

Now, what's missing here? What's missing here from how we would typically do this? Well, first of all, we're not assigning any properties to any of these objects that were created, right? That's one thing that is different. The second difference is that we're not really assigning any type. We're not saying this object we're creating, it comes from this specific type, right?

And if this was C++, then you would definitely have to assign a type to it. So it's something that we're doing it a little differently. And I'll tell you more why we're doing it this way.

The other question that we're asking is, how do we associate data, right? Here we're defining a framework for managing extensible and reusable relationships between assets. And the questions that we're answering with this framework are, how our assets related or which assets are related? And in what sense are they related?

So this is where we model things like parent-child relationships, container relationships, adjacency relationships, and so on. And we also offer a mechanism to group relationships into collections. And each of those collections can have a defined set of constraints and defined behavior.

So again, how do you create a relationship? Very simple. It's basically the way that you will be defining a graph, right? You say, I create a relationship. I pass the space URN. And I'm going to tell that relationship what are the two objects or the two assets that are being related, that are being associated.

And I can also optionally tell the relationship what kind of relationship it is or what collection does it belongs to. And again, we do that by defining relationship sets. And as I say, these are the two fundamental questions that we're trying to answer here.

So why does it matter? Why do we care about telling the relationship what kind of relationship it is? Well, it turns out that we're trying to stay away from rigid hierarchies both in the way that we assign types to objects, and also in the way that we define relationships, right? So when you have rigid containment relationships, you say something like, this object is always inside this other object. So something like, this floor is part of this building, or this chair is inside this room.

And you kind of have that single containment. And that's how-- or rigid containment-- and that's how a lot of our applications work today. But with that approach, you end up with a very deep tree of associations, which doesn't really give you the flexibility that you may need sometimes. So let me talk more about this.

So we understand that different objects are related in different ways, depending on the application or use case that you have in mind, right? So you can say something like, that lamp is attach to the ceiling. That's one relationship. Or you can say something like, that lamp is centered on the ceiling. And that's a different kind of relationship, right? They're independent. One does not imply the other.

But for different use cases for different applications, you might still need to capture both of those relationships. And so that's what this graphic here tries to capture, right? These are building blocks. These are all assets that could be part of a building.

So you have things like windows and facades and units and levels and bathrooms and so on, very simple model. And you can also have different types of relationships between those assets. You can have the composition. You can have adjacencies. You can say the bedroom is adjacent to the bathroom. You can have connections between all of these assets and so on. It's not one single hierarchy, right? It's not a single topology of relationships.

So we just want to provide something in contrast to the more rigid relationships model that our products have today, something that is a little bit more customizable and extensible so that you can easily define relationships as part of the data model of your own application. So we're going to provide some of these things out of the box so you don't have to define them yourselves. You can reuse them. But if you want to extend these relationship types or these object types, for that matter, you will be able to do so.

This is one of my favorite questions that we've been trying to tackle. It's a very important problem, and it has to do with typing. So how do we define extensible and reusable types? And how can we define them, and how can we extend them?

So we're defining this concept of component. A component is a type, collection of properties that is associated to an asset or to a relationship. Is anybody in the room familiar with the entity component system pattern for type extensibility? OK, somebody. Good. So entity component pattern is widely used in video game development.

And what's nice about this pattern is that it lets you define reusable types, basically reusable collections of data, as components. And it lets you attach those collections of data dynamically, at runtime sometimes, to the assets that you are defining. So that way you don't really have to define the type of the object that you are instantiating ahead of time. You can just say, I instantiate this object, and I will worry about the type later.