Description
Are you building apps on the Forge, Construction Cloud, or BIM 360 platforms? Are you using Forge as part of your digital transformation strategy—or helping your customers transform their businesses? Do you want to learn more about what the Forge Team has been working on throughout the past year? Come join us to learn about the improved API, the new Construction Cloud and BIM 360 APIs, the next generation of API to work with data, and more. See what's new with Forge APIs and what's coming in the next generation of the Forge platform. Get the insights you need to confidently create your application development plans.
Key Learnings
- Discover what the Forge Team is working on for the future
- Learn about new Forge APIs
- Learn about the Forge platform strategy
- Learn how Forge is helping customers turn their digital transformation strategies into reality
Speakers
CYRILLE FAUVEL: Hello, everyone. Thank you for joining us today. We're going to talk about the fourth road map. I'm Cyrille Fauvel, I'm your host for this session. On I have Jim Clancy, senior director of the advocacy on support with me, as well as Jim Gray from the Autodesk Construction Solution on Ecosystem. We're here to talk about the Forge road map and give you information about what's coming.
And I'll let Jim Quanci to introduce himself very quickly, as Jim Gray will follow, Jim.
JIM QUANCI: Thank you, Cyrille, I would like to encourage folks as we go through this to recognize this Forge road map is going to cover a lot of material. We're going to keep it pretty high level. And when you see things that you need to deep dive on, just recognize after this class you should be pretty quick to reach out to this in any area you want to deep dive.
Because there's so much detail and because we're going to keep it high level. And many of you are already using Forge and you will have detailed questions that we want to help you with.
CYRILLE FAUVEL: Jim, Jim Gray, you here with us?
JIM GRAY: No, actually sorry.
CYRILLE FAUVEL: That's fine. OK. So let's move on. Before we start, we have a safe harbor statement. What is very important here is we're going to talk about future plan, about things we are thinking about or developing now. So if you have any questions about what we're saying, it should be easy to reach out to us later. Or come to the Q&A and ask questions.
What is very important is do not make decisions on what we saying today. If you have to make a decision, talk to us to have more details about what we're saying today. And we say we can start to the next slide, Jim. And for those of you who never heard about Forge, only are joining us today for the very first time, you probably want to know what Forge is about.
So Forge is a cloud offering from Autodesk for developers. So it's a developer platform, it's not a product. To give you an idea of what you can do with this, we have a slide where we summarize that Forge is a collection of web services, that you can use any programming language to access the API and build your product on top of that.
When I say any programming language, any REST capable language, programming language can be used to create your application. You can use any framework you want. You can connect things together. So Forge web service on APIs is there to give you access to CAD design file on information.
So whether you're using SolidWorks, Revit, Inventor Fonts, you can extract information, you can modify information, or you can build on top of that. And you can connect to other systems.
I'm going to reinforce with folks, again, if you're new to Forge, this typically means you have a subject matter expert which may be a CAD manager a BIM manager, a systems analyst in the IT department, partnered up with a full stack web developer. That is the typical two person team that gets started with using Forge.
Again as Cyrille said, it's not an end user product. It's a set of web service APIs, most of which are REST based, and if you don't know what REST is, go find your full stack web developer.
So what people are doing with our API, so they have very different use cases. So it goes from data visualization, digital twin, augmented reality, et cetera, et cetera. People use Forge to build these solutions, which are whether enterprise solutions or applications they sell to customers. What is really important here is that the API opens very new, different ways of working with the data you can use from CAD design files.
And you can deliver added value to your customers. So people are building configurators so you can configure a model, you can configure a product, or they have some automation to make the people more productive on saving money for the company. So all these scenarios or workflows are already implemented by a lot of customers.
But it's not the only one you can do. That's one which has been identified through the years. Jim?
Yeah and to be clear, folks, Forge is not like our desktops. This is not about putting a plug-in on top of an Autodesk platform. Forge is a component. It's a component that's really smart about design and make data that you build into typically a cloud, a mobile, or a desktop based solution. So it's working with components that we give you to make it very easy to work with design make data.
So for those of you who already use Forge probably attended last year roadmap. So let's see how much progress we did. And we'll go step by step through some plot updates on some API updates. So last year we talked about regionalization. So where are we with that, Jim?
So we last year we talked about additional data centers, where we were going to add data centers in various parts of the world. And that was both about the demand we were getting for better performance such as in sections of Asia. Plus we were getting a demand for a regional, I'll call it for kind of legal customers wanting to know what government controls and regulations are around where their data is.
I will tell you we had to pivot. As we started to make changes to Forge to make it easy to pop up additional Forge Data Centers, we did a thorough analysis on where the biggest revenue growth opportunities are. And it wasn't about a regional data center. It was about a US data center that supports FedRAMP.
This is very much about doing business with the US government. It was a huge revenue sales growth opportunity. So when we did that plumbing work with Forge to make it easy to pop up new data centers, the very first new data center coming out is FedRAMP. And that has pushed back us adding additional regional data centers such as Europe and Asia to the next year or two.
So we can finish up getting FedRAMP kind of out the door. So for those in Europe and Asia, you know I'm kinda sorry this kind of delayed things where having a local or regional data center is important to you. It's going to happen. We are going to add additional regional data centers but it's been pushed back a bit.
And it's important to say that FedRAMP is like the security and validation service which are important for the business like SOC 2 and et cetera.
So Autodesk paying a lot of attention on time, on making sure that we validate all these services, again SOC 2 on FedRAMP. We're making good progress on FedRAMPs. We have some certification going on. A few of the series are already FedRAMP certified, but not all. So we should complete sometimes easier as this federal certification.
What next? OSS binary transfer optimization, so today whenever you want to upload a donut file, you're going through the Forge developer API subdomain. And because you're doing that you don't have direct access to the storage, which includes some delays on the transfer. So we working on a new API to make sure that we accelerate this. So you can make faster transfer on activity.
You could also do transfer directly from the client rather than going through the server. So that will give you a lot of more capability. If you're interested to see what the API is about I encourage you to go to the Lightning Talk for details. Sometime in the next few months we'll deprecate the current API for binary transfer and introduce this one. But we guarantee that SDK will make sure that they work with both.
We also working on improving our SDK. So sometimes easier, we'll introduce new SDK versions which will also make back compatibility with the old one. So you have integration pass for your applications.
So the short version of this for those of you who are less technical, is when you're using Forge data management to push around gigabyte files it's never fast enough. And we're making it faster.
Exactly, Thanks, Jim. So let's talk about the Viewer and Model Derivative API, which are probably the most used web services today from Forge. And we have the reverse this year, some API for the viewer. So I think the major API we deliver was a data visualization extension for the viewer. We talk about it last year during the roadmap. And we had a beta version running until February.
And we heard feedback from people trying that extension during the beta. And we actually reworked completely the extension to make sure that what we were delivering to developers work for them. So IoT development kit introducing IT maps, having sprite viewables, an easier connection to the Azure IoT reference app. So that was one thing we delivered.
We lately also introduce Native support for gITF Wi-Fi on PDF. So you can natively load into our viewer gITF native. You don't have to go through Model Derivative if you don't want to. In June, or very late June, we also made SVF2 available to anyone. So getting out of the beta. So it was to increase the speed and make that more generally available to people to accelerate models on the viewer.
And although we had to modify also the Model Derivative API so Modern Derivative API now understand SVF2 as well. If you still want to use SVF, you can. The viewer can fall back to SVF loading mechanism if you want to. And you have an optional header on the Model Derivative API to tell that you want to continue to use SVF versus SVF2.
But if you choose to continue with SVF, not only you losing the improvement for speed on performance, but you also using a legacy system. So I would now trust you to move to SVF2 in future because you have a lot of more benefits using, it especially with AC models.
Now I want to personally apologize to many of you. We showed SVF2 two years ago. We thought we were close back then when we told you we were doing it. And we thought it was going to come in six months. But it turned out to be more challenging than we thought. And it very much had to do with how you synchronize the graphics with the data.
The metadata, the parameter data, the attribute data, that turned out to be trickier than we thought. So I'm sorry this took so long. But it's probably more important we get it right and we now have. And I really appreciate your patience and to many of you who worked with us and gave us feedback. And some of you took a few arrows in the back using betas, helping us get that right. We really appreciate your helping us.
What's coming soon? You probably complained, most of you, about an outdated version of THREE.js which is the back end system we're using for our viewer. We actually are working hard on updating the version of THREE.js to the latest version. And it maintains that latest version always for future release.
In a few months we'll be making that new version available side by side with a conversion. So you have the choice between let's say, the older viewer, let's say a new viewer with the oldest three years version owned the new viewer with a newer version of THREE.js. So you can switch from 1 to 0. We also affect the internal API so they can work seamlessly between both.
So you can have a migration pass for trying the new viewer and see if it's working. As we move to the new THREE.js version you would be able to use the latest and finest API from THREE.js for point plot, for example. We'll also introduce into the data authorization extension streamlines and you have a picture of what it means. So you can have some analysis free of time into your 3D models.
To complement gITF we also support USD or USDZ natively. So we have a broader, open format support for the viewer. Because we'll be supporting USD we'll be implementing a web-based wanderer using USD, so will be more or less compatible with some other system.
And last year we talked about web, let's say AR, XR, VR systems that Autodesk is syncing to, the first thing you'll see at AU is WEBXR. So we have enabled the viewer to support WEBXR so you can make use of this with your device from any device which you bought WEBXR. So that's a general improvement we made for the viewer.
I do want to reinforce, I'm excited about a supporting the latest version of THREE.js. Those of you who've used the THREE.js capabilities of the Forge viewer know we're back on 0.71. And you see more advanced THREE.js capabilities and some of you having to back port it it or giving up trying to back port it. So I'm really excited.
It's also about Autodesk making a commitment to open source making improvements to THREE.js so it's easy for us to keep THREE.js synced in with the Forge viewer, exciting stuff. The last thing when it comes to XR support, do not overthink this. This is what I call poor man's WEBXR support. For those of you who are building AR, VR, maybe you're using Unity or Unreal in your AR, VR application pipelines.
Don't worry, what we're doing is not going to obsolete any of that work you've done. This is just going to be kind of a lowest common denominator, hopefully give a lot more customers, users a taste for AR VR that will have them come back for more for many of you who've built really interactive kind of high quality, high performance AR VR pipelines.
You're absolutely right, Jim, that is only the first step. And that's probably the one which open to more people because WEBXR, it just needs a browser and that's working. So you can touch on more people. But you're right, Unity, Unreal, Omniverse are still in the past to be supported too.
OK, some updates about Model Derivative API, until now there was many problems with some other Derivative API whenever you wanted to access the hierarchy on properties from models. It was not fast enough. There was some limited query capabilities. You had these HTTP code returning to you, 202, which means wait, don't come back later, that people had hard time to understand.
So just to keep it simple, the API for accessing metadata directly from other derivatives was not working as expected. So we work on this and we have a new API that you be shortly have access to.
I also want to point out to people while we're here, there's enhancements coming in model derivative next year, based on Revit 2023. Because a lot of this performance issues with Model Derivative, or I say performance, sometimes failures of large models to be extracted. You're going to see dramatic increases in performance. So it's funny. We talked about changes to the viewer with that.
So you have to increase to performance, we are not done yet. There is more work being done to help those of you working with these very large, multi gigabyte Revit files.
So what is this API will allow you to do, so higher speed to access the metadata extraction, faster response time whenever you do a query. Actually you can now control what you want to get.
So not only you would be able to query leaf object from the hierarchy, instead of the full hierarchy which sometimes is too big to download. So you would be able to go step by step into the tree. You would also be able to create metadata by the name, by value, with one cup prefix if you want. You can ask for subset, more or less like an extra query where you say, I want to see these fields from this object, which has these returns.
So you would be able to get a faster response with the accurate data you need for your application. Because now you can also paginate or limit the query. See, the response would be faster but you won't have this tool to HTTP code anymore, which says let me load your model first. Do you have access to the properties immediately at your fingerprints?
Some design information update, so the first one, if you can move, Jim, we heard you complaining about some queue problem on the, not performance itself, but you know, I launch a work item and I have to wait. And we recognize that it's a problem because you can't predict how long you're going to wait. So we're working on making sure that the queues clear up as there is demand on running tasks.
So first thing we did last month was to actually increase the number of workers. But that's not a robust solution. Increasing the number of workers is just a temporary solution to make sure that we deliver in time. We are working on a stronger queue management system for better performance. So we have close to real time analysis on how many jobs are running or requested on scaling the number of workers on demand.
We are also thinking about having multiple queues. So not only having one queue accessible for the general public but you could have one queue reserve for yourself. That would be something which probably be available in future. We have also delivered web sockets on the design automation API.
So today the only thing we have for web sockets is to give you a callback directly from the design automation server so you can monitor your work item progress as it goes from any client, whether it's a mobile or any of those things. The reason for web sockets is that you can't have a callback directly on a mobile. You would need to have a server, and talking to a server would just slow down things.
So the right socket just enables that. We'll also have an open network capability using raised on HTTPS requests during execution so you can talk to your server as your [INAUDIBLE] is doing work.
And that would facilitate things like having a configurator so you can have the engine running with your model when you have a client where you make decisions for the configuration on Send instruction directly to your work item for, let's say, configuring your model line. So that's the two big things which we implemented on design automation.
And what I just say here will apply to all engines inventors, Civil 3D, AutoCAD, you know this one, 3ds Max. Go ahead, Jim
I just want people to recognize when we released design automation probably three or four years ago now with AutoCAD and over a year for Revit Inventor. We were not thinking design automation would be used for real time or near real time applications like consumer type configurators. We were aiming for more batch, kind of at night kind of processes where you need to do a lot of work over let's say a lot of files.
But you, our developers, our partners, our customers, have dragged us into making design automation more capable for these real time, near real time, applications like configurators. So we're doing our best to kind of meet that need, that demand that we're getting from you
So a few more things which are specific to Revit, so we have delivered PDF generation for the Revit engine that was not enabled in the past. So it's delivered. You have it right now. We have seen cloud work sharing so for write on grid access through your models. And we have also scaled Revit instances for very large model.
Before instances were working for large model but not very large models. So we have doubled the memory size for large model for Revit. Again, queue scaling on multiple queues is very important for Revit, too, because many people actually using the Revit design automation engine.
So to reinforce, the number one thing we are working on with design automation for Revit is enabling you to work with work shared projects without requiring a publish. It's not done yet. It's heavy lifting. We are doing the work. We know you want it. We know you need it. It will come.
And on the scaling side, so there's been improvements over the last two months. But we know it's not enough. Again you're throwing very large models at design automation for Revit and you're demanding near real time response from us and that's a challenge. And we're working on it. And it's not going to get fixed all at once. It's going to be incremental bit by bit over time.
So keep telling us, hey, that's working, hey you're making progress or that's not good enough. You know for my use case here I need better, more predictable response.
So now I'm going to talk about Forge data and I want to tell you I've had some trepidation. You know we've been talking about data, Forge data for about five years now. The very first Forge Devcon, we talked about HFDM, high frequency data management. Some of you have heard us talk about quantum and quark.
And I'll tell you, giving you the ability to have easy, high performance, kind of millisecond access to data that's coming out of a model that was originated in a binary has turned out to be a lot harder than we first thought. You may laugh. 20 years ago we tried to do this with AutoCAD, put an AutoCAD model in an Oracle database so you can do a simple query and get an answer on an attribute.
It turned out to be very, very hard to get both performance and scalability. CAD binary files are optimized for performance, for load time, for save time, and it's hard it's proven really hard to do that with the database. You know we then five years ago, high frequency data management, we took another shot at it. About a year in we realized it wasn't scalable and highly performant enough.
We then took another shot at it with HFDM. And now we're back to maybe a year and a half, two years ago, and we couldn't get it to work. And now we're coming to you with after a lot of hard work with Forge data.
And we're actually using it with Fusion today. So this is no longer kind of a hand-waving. And we believe we have it licked from a performance point of view, from a scalability point of view. While at the same time having to deliver what you expect today.
And things have changed over the last four or five years and what you expect. You want history, you want control over who gets the view, who gets the right, authentication, reliability, resiliency expectations have changed. So we've been working really hard at this. And frankly, we've been taking the arrows to get this right.
But at the same time many of you are like, what's taking so long? Yes, it's taken a while. It's heavy lifting. It's hard work. But we really truly believe we got this one licked. And I want to talk a bit about how we're doing that. So Forge data is going to start with being presented to you through two different areas.
One is cloud information models. These are mostly complete information models of what today is in a binary but up on the cloud, where you can do a query, you can count, you can schedule, you can link. Now the other thing we're doing is something called Forge Data Exchange and this is where you really don't want the whole model up on the cloud.
You just want to be able to share some data very easily with someone else in a very lightweight way.
And we're going to deliver you both of these. And it's about delivering high performance access to data, collaboration, lots of people working on the same data sets at the same time, the control you need, who gets the view, who gets the access, who gets the history. And the costs, because those are using Model Derivative or design automation today know there's cost involved in getting that data.
But once we have that data in a proper database up on the cloud, the cost drops dramatically. So let's talk about information models. And I'm going to start with an information model with a manufacturing example, actually what we internally at Autodesk call PIM, a product information model. We are actually using Forge data, this product information model, in Fusion 360 today.
Anybody who's used the Manage extension, and the Manage extension is an optional thing that a customer using Fusion can turn on, and when they use the Manage extension they are basically storing, keeping parameter data, attribute data, you know depending on what you'd like to call it, property data, up in the cloud in the Forge data repository where it can be easily shared with other people.
So today this is an end user capability inside Fusion 360 that customers are using today. And in this case to share data with folks, let's say in manufacturing, engineering, or between design and production. It's about ECOs, it's about bills and materials. So there is this external facing customer feature that's built on top of Forge data that is taking advantage of the fact that this data is mirrored between the Fusion 360 model and this Forge data database.
High performance, lightweight, is a full set of APIs, it's been in private beta with two different partners who've been using it. And we're ready to go to public beta. And those of you who want to use it, one of the calls to action is if you want to touch, if Fusion 360 kind of data is important to you, come touch.
Now do recognize this is going to come to other kinds of data, whether it's Revit, Inventor, AutoCAD, we're starting with Fusion where the size of the data that the data set is easier to work with. But there will be more coming. So enough for that video. Let's talk about how we do this and what this is all about.
So Forge data information models, you've heard this from us before. I'm not going to belabor this but it's having data at the Center, on the cloud, simple, easy connection with desktops, so as data is created in a desktop that parameter data, attribute data, property data, is mirrored up on the cloud, where you can get at it with maybe a server connection because you're grabbing that data and you've got it synchronized with CRM or ERP data.
Or you've got an application like a web dashboard that's kind of looking at that data and keeping that data in a place that's secure, high performance, we deal with things like GDPR or auditing, history, revision tracking, all those things that's hard to do. Especially those of you who are keeping data today using Model Derivative or design automation and your own separate database, it's kind of heavy lifting and we will take care of that for you.
It's about performance and speed, access to data, again, collaboration, lots of people accessing the same data at the same time. Again the control you want and low cost because you're dealing with small bits of data and not having to deal with whole models. So again, we have this for manufacturing today. It's in private beta today. It's working with Fusion 360 through the Manage extension.
You can read data today. It's got a venting hooked in today. Write's going to come in the future. Those of you who were on the manufacturing side who Fusion 360 is interesting to you, who want to get a feel for using Forge data information models, we welcome you. We embrace you reaching out to us to be an early adopter. And you should have every expectation we will have a public beta very shortly.
And when you're seeing this we may be announcing the public beta as you see this as part of AU with release kind of early next year for everyone to use. OK so again, right now if you want to see Forge's data in action go check out the Fusion 360 manage extension capabilities. It's built on top of Forge data. And it's the type of thing you will be able to do.
And hopefully this will inspire you on really a very seamless way to work with data in a model without having to worry about binaries, without having to worry about these performance issues because you're dealing with these big honking files. So again this manufacturing, this product information model is what we've done first.
Next is going to be AEC, we are well along working through how that's going to work. It is a bigger animal to tackle and why it's coming second. For those of you who work with Revit or any kind of building information model, the number of parameters you're dealing with is in the thousands. It's a lot bigger than you see on the manufacturing side.
And in the fullness of time we're talking media and entertainment, also. Now we are building this out so you can have your own extensions. So you can add your own, in effect, fields to the information model that we have up on the cloud. So you can store, or your customers can store, their own proprietary data that's related to the information model, to that cloud information model.
And that way we can manage it for you, for your customers, again in a very secure, reliable, meeting standards way. Now for some of you, maybe you're a customer, you have your own enterprise information model and you want to hook in to these information models that hold your design make data and absolutely that is where we're going.
Maybe you're an ISP, you've got your own app. And again you may want to do the same. Your app, you've got your own information model for what your app is managing. Maybe that has to do with scheduling. Maybe it's a costing thing. Whatever, you'll be able to hook your information model. You'll be able to federate your data with our data.
So again, I want to make the point you'll have choices. Do you have data that is very closely related to design make data and maybe you just want to do an extension to an Autodesk Forge information model. And/or do you have a very large amount of data that isn't as tightly related but yet you want a federate, to create insightful dashboards to automate data flows.
So you want to connect your own information model with these design make information models. Now with that, the other thing we're doing has to do with exchange. It has to do with a more lightweight way. And it's still about performance, collaboration, control, and cost, but can you we want it to be able to make it very easy to share data kind of point to point without a lot of heavy lifting.
It's what we call Exchange, so Forge data exchange, and with that let me show you a clip. So Forge data exchange, it's very much about allowing you to connect data that's in a model, treat it as data, and being able to share it with someone else. What you see here is inside Revit.
And in this case actually inside BIM 360 of the Autodesk Construction Cloud being able to take a very specific Revit view and using that view as a way to share data. So in this case the view has walls and windows. It only has walls and windows. And I can use this Forge data extension to share just those walls and windows data with let's say, somebody in purchasing who needs to buy all these windows.
Or maybe it's somebody in manufacturing, maybe it's the window manufacturer, and you want to share all these details. And that is actually what's happening here. What you're going to see is all the walls and windows are going to be passed using exchange to Inventor and being shared in a way that's constantly connected, so being able to deal with updates, and changes, and versioning. And also being pushed to Power BI.
So again, you may have someone else, it's kind of not a CAD person, not a graphics person, who's doing that. Again like somebody in purchasing. OK so Forge data exchange is about easily sharing just a subset of data. Again, initially based on Revit views you put together a review of the data you want to share. Maybe you want to share just the architectural and the structural with the structural partner a consulting engineering firm.
Maybe you just want to share a certain amount of data with the mechanical firm. Maybe you want to share data with let's say, somebody in purchasing. You'll be able to do that using Revit views. Later, a little farther on we're going to have a connector in Revit so from within Revit you can decide what data you want to share.
So I think of this, as I talked about Forge data information model. It's like taking a small subset in a very lightweight way to make it easy to share data between Revit and other folks who you need to work with the data with. So eventually this will go beyond Revit though we do recognize a lot of the demand is from Revit, given the environment is a bit. There's lots of players.
Moving data is really messy. Now you will have the ability to go hands on early next year. This is another area, if you want in on this exchange capability, again this relatively lightweight way to share data again, initially between a Revit model and other people in the organization without going the big information model route, do let us know. Reach out, we have every expectation of having public beta actually quite soon.
Again, it actually may be happening here during AU with the general release kind of early next year. There will be more to come. It's not just about information models. It's just not about exchange, things like project registry, making it easier to work with hubs, to work with projects, who gets access to what, search schemas.
So when you want to add your own data to Forge data maybe you want to add a lot of data. You want to add your own your own schema to our data, versus linking you know, your own data. So you'll have choices. Do you federate, do you keep your data as part of Forge data? You'll have choices. That will have impacts depending on the performance, and your costs, and what's it going to take to manage the data.
And do you want us managing it for you? Do you want to manage it yourself? Enhancements and inventing a graph, part of this is about graph databases. And I know some of you who have had experience with graph databases we will give you, I'll call it more deeper access to how much data is working.
So that's Forge data, again cloud information models, exchange, it's about performance collaboration, control, and cost when working with really granular object level data. I'm not going to go through this in detail. You're all going to be sitting there, well, when do I use that? I'm already using Model Derivative. I'm already using design automation to read and write data.
You know, you've got to take a step back and understand the problem you're trying to solve. What's the timeliness of the data you need? What are your cost constraints? What kind of expertise do you have to develop? Do you want to own and manage your own database? Would you rather have Autodesk do that for you?
And again the cost thing, working with individual pieces of data is cheap compared to, let's say, using Model Derivative or design automation where you're pushing around and processing these gigabyte files that has real cost to compute. We've got a table here, hopefully it'll give you an idea on how to look at, do I go the desktop plug en route to work with data? Do I use Model Derivative? Is design automation the right way?
Should I use this new exchange to deal with subsets of data? Do I go the full Monty club information model route? So refer to this later and again if you want to be an early adopter reach out to us, let's talk. And with that, I'm going to pass things off to Mr Gray.
Thank you very much, Jim, that was an awesome overview. And Thanks to all of today's attendees for joining the session. I'm going to attempt to bring us home with a quick update from the world of Autodesk construction. As you may recall, last AU we announced the release of the Autodesk construction Cloud. And we brought that to market in early Q1 of this year.
Now since then we've been making continuous platform investments in the Autodesk Construction Cloud. So today I'd like to share some of the ground that we've covered since then, where things are headed in the near term and a little bit about our vision for the future. Next slide, please.
So every platform needs a user facing entry point and we released the Autodesk Construction Cloud app gallery on September 21 to meet that exact need. So this is the place. This is how account administrators are able to browse for certified ECC integrations, explore their use and value looking at narratives, pictures, and videos that are provided by our ISPs. And to securely enable them for use on their accounts.
As you can see we also have a featured apps panel where our integrations team can showcase select apps. This capability is fully available right now in both our US and our EMEA regions. Next slide, please.
I'm going to reinforce, for those of you watching this who have BIM 360 apps, if you have not started porting to ACC to in effect Autodesk build, you need to get started. We have a hundred or so partners that are already running down that path. Don't wait, the water's warm, now's the time.
Absolutely, so there are several ways that you can integrate applications with ACC. I'd like to share one with you that you may not be aware of called ACC Connect. ACC connect is a powerful low or no code environment. This is a class of embedded middleware, which is called IPAAS, or Integration Platform As a Service, that allows extremely rapid integration and the creation of complex workflows between systems.
We currently have hundreds of customers actively using this capability. And they typically start from one of the dozens of pre-built templates that we offer. And those provide basic integrations, pre-built integrations between common systems. Sounds pretty cool, right? So what can you actually do with ACC Connect? Let's take a look. Next slide, please.
So while there aren't any hard limitations in the world of API orchestration there are a few common classes of integrations that are very popular with our customers. Of course, integration with a variety of document management and cloud storage providers is very important to our customers.
But it's equally easy to integrate with popular providers of project management reporting and communications platforms. The sky is really the limit. So these are just a few of the possibilities. If you're interested in learning more about the power of ACC Connect please reach out. Not all integrations need to be built. Some of them just need to be wired together. This is a very powerful capability. Next slide, please.
All right, so let's get down to brass tacks and talk about APIs. I'm sure that's why many of you are here. So I'd like to highlight some of the ground that we've covered so far this year, forecast some of our coming attractions in Q4, and share a little bit of our longer range vision. This slide is a good summary of all of that.
And I'd like to highlight a few things of particular interest. First, what are our goals? Well our immediate goal for this year has been to get to API critical mass. Providing basic CRUD methods for our first class entities so that we can enable valuable integrations. We're making solid progress on this front and we hope to fulfill this vision by early next year.
Now I'm particularly excited to share a few very in-demand APIs, which will surface in Q4. First project administration, which includes creation using templates and issues. These are both extremely important APIs that will enable many popular integrations in ACC. If you've been waiting for these, please know that they're coming soon, and please dive in and make use of them.
I'd also like to point out that our 2022 vision extends beyond simple REST APIs, we hope to be able to enable near real time integrations with the introduction of web hooks for some of our most critical APIs. And also to provide more flexible data access via service accounts. Please stay tuned for updates on that as we proceed.
By the way, if you'd like to learn more about some of our newest APIs, I'd strongly encourage you to attend a focused session being presented by one of our experts, Mikako Harada, from our developer advocate and support team. That's going to be a great session. So as you can see, this is a pretty iterative process proceeding through this year. Not only across our entities but also across our platforms as well.
So I've annotated here where some of these APIs support both ACC and BIM 360 projects. This is a really important nuance to understand as you look ahead for how to support ACC projects in your apps and integrations, very important topic. So let's close this segment by double clicking into that topic just a little bit. Next slide, please, Jim.
Jim, I will say I hear from partners every day about needed enhancements in administration and about the issues API for the Autodesk Construction Cloud for Autodesk build. So I know many people listening here are going to be pretty excited to finally get kind of what they need there.
Yeah these are long awaited APIs that we're very excited to introduce. I wish that we were live in the room right now so that I could observe some facial responses on those two announcements. But I'm very happy to be able to bring them to our ecosystem community. So let's close with some thoughts on bigger picture and context.
So what's the distinction between BIM 360 and ACC APIs? Why is there a difference on? So first, ACC is a literal combination of platforms. It brings together the power of BIM 360 and Plangrid into a single unified platform. Now, in this unification effort we have been able to retain forward compatibility for some of our APIs now this is not universally true nor will it be permanent in all cases.
So you might be wondering, Jim, why would you do this? Well, it was actually quite deliberate. And I'd like to help provide a little bit of context on this. The rationale here is that we wanted to provide continuity where possible and a path forward for our partners while not boxing in the system and our customers into a parity corner. We don't want to just replace existing systems. We need to have a path forward that we can integrate on.
So we critically need to make sure that ACC can evolve and that we can provide powerful new innovations to help drive our industry forward. So what does this mean for you? What does this mean for ISPs and corporate developers? Three things to keep in mind. Number one, BIM 360 remains an absolute cornerstone of our portfolio and will have extended continued support.
Where it makes sense, thing two, we will provide forward compatibility on every API where it's feasible, and possible, and practical. And thing 3, as the Autodesk Construction Cloud evolves forward we will version and in some cases deprecate APIs to help move our platform forward. We give you a commitment that we'll do that in a graceful and a predictable fashion.
So I hope this context was useful. And that this update on the Autodesk Construction Cloud platform gives you what you need to plan and execute on your integration initiatives. Thank you very much for listening.
I do want to tell people something that's happening that may be live by the time you see this. We are doing a refresh and a replumbing of the Autodesk app store. It's been a while. It looks a little dated. You know though, we have over three million visitors a year to the app store, over a million app installs per year from the App Store, you know, it's time for a refresh.
The other thing we hear again and again from the 900 publishers publishing near 4,000 apps in the app store is more capability around licensing. And that's licensing having to do with when your licenses are cloud based and their subscriptions. And licensing that helps you deal with multiple users' teams. The original app store was built kind of like a phone app store where you're dealing with individuals.
And we've heard again and again, that's not good enough. And this replumbing we're doing as kind of a first step to really enable us to deliver you and your customers a better and easier licensing experience.
And Jim, I want to add that if you have an application based on ACC or Forge, you're very welcome to contact us and publish your application on that store. That's really important for you.
So if you have any question about the content we delivered, I really invite you to come on the AU website and ask your questions there or email us directly. After this talk there is a live Q&A and the three of us will be there to answer your questions. But you're very welcome to contact us later, So please do.
To close out this talk, there is more Forge activity at Autodesk University. So as you interested or want to learn more about Forge please go to all the activities we made available for you.
And last but not least, if you want to learn, the best thing to do is to try it. So go to forge.autodesk.com and start immediately. It's a free trial and you can start using the API on testings on your side. Any last word, Jim and Jim?
I just encourage people, you've kind of already said it. People should be quick to reach out. We've talked about a lot. If you're a hands on developer I know you want more detail. And there's a couple of opportunities here to get involved in private and public betas. And for some of you, you want to get started early.
And you're interested in helping Autodesk form some of the new capabilities, like around Forge data. Do reach out, do not be bashful. We want to engage with you. You make us better.
OK, thank you everyone. I'll talk to you soon. Bye bye.