Through the Interface

For much of my career at Autodesk I (and eventually my team) focused on encouraging development (internally) and adoption (externally) of APIs (Application Programming Interfaces) to our products. It's why I named this blog "Through the Interface" when it started back in 2006.

At the beginning (for me this means the 90s) this was clearly around desktop software; starting with DOS and even UNIX, although by the time I had joined the company Windows was becoming the primary OS platform for our products. We worked to help companies integrate their own software with ours, whether "in process" via plugin architectures or driving our products "out of process" via automation technology of various kinds. AutoCAD - and therefore Autodesk, as the two were basically synonymous until the verticalisation of the late 90s - had it in its DNA from the early days to support workflows involving customization and eventually 3rd party software development… check this interview from 2008 with Autodesk founder John Walker to see how central this was to the company's early success: this really became part of who we are as a company.

We had many interesting discussions with product teams, over those years, emphasizing the benefits of adopting this ethos: we had really good survey data from customers saying that a solid third of our user base relied on the existence of a 3rd party software package to do their work. While the direct revenue from the Autodesk Developer Network was modest, the indirect revenue of Autodesk product sales driven by external, integrated tools, was enormous. It was interesting driving a multi-sided platform strategy in a company who's primary raison-d'etre was obviously to serve customers directly, but quantifying the network effect of a healthy 3rd party ecosystem (a third of Autodesk revenue is not to be sniffed at!) certainly helped.

This kind of effort gradually led to many Autodesk products that came from acquisition who were not focused on delivering an API - and I'm thinking in particular of Revit, in this instance, which had been developed by many folks who'd formerly been at PTC and had a very different attitude around ecosystem development - shifting track to not only exposing an API but also (and I'm once again thinking about Revit, here) to start developing their user features in an API-first manner (where you first build the API and the UI then uses it). Not every product went down this path but we did have pretty good success, over the years.

Then came the cloud, with the View & Data API morphing into Forge which in turn evolved into Autodesk Platform Services. Once again platform became central to our efforts as a company, with many of our partners and customers following along this path with us.

Great. So Autodesk has done a lot on the platform side of things, over the years. So what?

As everyone knows, Large Language Models (LLMs) have been changing the way we interact with software. We've become increasingly used to chatting with AI to research and solve problems, and with Anthropic's release of Model Context Protocol (MCP), late last year, suddenly these LLMs could access data - and even automate operations - exposed by cloud- and desktop-based systems.

Read the text on this AI-generated image. I love it, and the new logo.

People started writing MCP servers for their favourite web-services and desktop tools, almost always through a public API. All of a sudden the drivers for building an API grew from enabling the integration of other software packages to include enabling AI-driven workflows that are likely to radically change the way we all work.

The good news for Autodesk is that we're in really good shape for this new way of things: our tools often have APIs that provide extensive access to data but also allow their various features to be automated. The community is already building MCP servers that can be used in AI-enabled workflows, and the depth and power of the available offerings is only going to improve.

I genuinely feel Autodesk is well placed to support these new ways of working, and I'm glad if somewhere along the way my belief in driving our API strategy helped us to get here. (I was far from being the only one pushing, just to be clear: the names of the people involved in this effort over the years at Autodesk would fill a separate blog post, if I were to write it.)

It's going to be a fascinating journey over the coming months (and years) to see how technologies such as LLMs and MCP change how we interact with software. Not all of us will adopt these new ways of working, of course - some of us have decades of muscle memory in our favourite tools! - but they will certainly lower the barrier of entry created by highly complex user interfaces, something that will absolutely help casual users and novices. They will also simplify cross-product workflows that today take an inordinate amount of time. Interesting times!