Un-Platform by Design: from Generative Design to Generative Infrastructure
When we delivered the most recent round of API capabilities in Skema – it marked a major milestone. Skema became a platform, even though we did not set out to build one.
There’s a story behind that, of course.
The honest version? We didn’t mean to.
When we first launched Skema, we were a generative design tool. That was it. We weren’t trying to “platform-ize” AEC. We weren’t designing a marketplace. We weren’t building a transaction engine. We were trying to solve one of the more frustrating problems AEC: Having to start from scratch on every new project. And while we were at it, we thought it would also be good to reduce the amount of file wrangling.
This has led to a journey of so much more…
Tool Chains for interoperability
We called it a “tool chain” because we were delivering peer-to-peer interoperability.
We used Web endpoints instead of file exchanges so data wouldn’t degrade every time it moved between systems. No exports. No imports. No translation loss. Not a hub where everyone pays tolls.
That was the idea — To make standing up a new project much easier by making the tools that firms already use work together, better.
And that was great. So great, in fact, that customers pushed us for more.
Delivering more when Customers asked for more
Customers wanted bi-directional Revit syncing. Fair enough. We delivered bi-directional Revit syncing.
But then we needed to do more. Because once an app is truly bi-directional, version control becomes mandatory. That is, if both sides can update, you need to know what changed since you last looked at it.
So we implemented version control.
At the same time we were handling models that architects used, no matter what tools they were using. Not just Revit.
We had multiple models coming from multiple systems.
Rhino. Grasshopper. SketchUp. IFC. Speckle. ShapeDiver.
So that led to building model federation capability. So that we could do what our customers wanted.
Our customers wanted to do custom computational designs using Grasshopper while also generating a lot of the building with Skema.
We needed a way to spatially organize all that — to allow any version of any model to locate itself relative to the project.
That’s where our analytic model comes in.
We didn’t pivot. We implemented what customers asked. So that they can do the work they need to do.
And, in the meantime, we implemented an API so you could use all this in Grasshopper+Rhino, or any other system where you could fetch JSON data
✔ JSON and Grasshopper APIs
✔ Version control
✔ Model federation
✔ An analytic model as a spatial locating system
🟰 That’s a Platform.
From Generative Design to Generative Infrastructure
Even though we have done the work to deliver a platform, we are not planning to adopt a platform revenue model – often described as a ‘walled garden with a toll booth’ -- anytime soon.
Our focus has always been outcomes. High-value outcomes.
What does the architect gain?
What does the project gain?
What does the owner gain?
We are not charging tokens for you to query your own data. We are not monetizing transactions for the sake of monetizing transactions. Why? Because we think it is a disadvantage and turns your services into commodities. We reserve the right to consider it in the future, if and when delivering value involves revisiting revenue models.
But we didn’t start with a toll booth mentality.
We started with a workflow problem. And delivered the best solution in the market.
Check out our comprehensive end-to-end workflow video on YouTube for a deep dive into how to use our API to embed your custom solvers into your design pipeline