The Future of Manufacturing Systems — Part 1: APIs

Karan Talati
First Resonance
Published in
6 min readMay 18, 2020

A few weeks ago, fellow UIUC grad Marc Andreesen wrote a post titled It’s Time to Build. I couldn’t agree more and I have for a while. That said, I have been trying to think beyond the inspiration and aspiration. Specifically, I have been thinking about how we really jump start the promise of Industry 4.0 by applying the huge advancements in digital technology over the past few decades to the problems that have existed in manufacturing for decades.

When it comes to the future of hardware and manufacturing systems, I believe that Industry 4.0 will be shaped more by The Future of Work than it will be by AI/ML. If we are referencing the same technology already deployed in digital industries (e.g. marketing, e-commerce, etc.), we should look at how things are unfolding there to get a glimpse into what manufacturing will look like.

Future of work companies like Slack, Zoom, and GitHub have a large influence on the progress of software development and other digital functions. To add, API-first companies like Stripe, Twilio, and Algolia have been hugely successful by creating productivity gains for software developers so that they can focus on their products’ core value in new applications rather than having to rebuild payments, telephony, and search over and over. Each of these companies has or is already delivering huge value to their customers by using the data exhaust coming from the volume of interactions.

Manufacturing tech companies like Uptake, Sight Machine, and Augury are less about the future of work but rather about application of data technologies to existing problems. Most often, that comes down to a single application — predictive maintenance. Now, there are successful companies in software analogs: APM (application performance monitoring) companies like AppDynamics and software QA companies like Rainforest QA help software companies deliver more reliability to their customers by upholding infrastructure or application quality. However, it would be be shortsighted to say that the state of software has been solely improved by better server uptime and less buggy software. Both critical, no doubt, but what from there? See the examples in the previous paragraph.

I have more thoughts on all of this, and talking about how predictive maintenance is a small application in the grand scheme of what needs to happen in hardware and manufacturing may warrant its own blog post in the future.

For now, there are a few technologies/concepts that directly apply to the future of hardware and manufacturing systems and will open up massive potential in the next few years. APIs and event-based data architectures actually map to the problems in hardware and manufacturing organizations even more than they do in software development and digital industries, and I believe that companies that effectively deploy these new paradigms will open up massive, untapped potential to really push Industry 4.0 goals, rather than trying to leapfrog to the latest and greatest coming from FAANG.

Future of manufacturing software: A series

This series of posts will continue to grow and will break down each of these technologies with real examples and frameworks to apply them in manufacturing environments. I will also describe why each is important and why they are important to this moment in time to help achieve Industry 4.0 goals.

It’s also important to realize that these are paradigm-shifting technologies that are continuing to alter the way that even software is built today. So to think that these same technologies can be repurposed by traditional/legacy architectures to fit the needs of the future of manufacturing is likely incorrect. Just as IBM, Microsoft, and Xerox didn’t usher in the new wave of cloud, mobile, and user interfaces; so too, it’s unlikely that the path to Industry 4.0 will be paved by the companies that ushered in the last wave.

The evolution of software systems by John Luttig at Founders Fund. Where do you think manufacturing is on this curve?

Part 1: APIs (this post)

Part 2: Event-driven manufacturing and organizations

Part 3: Event-driven analytics and independent analysis (coming soon)

Part 4: Containerization (coming soon)

Part 5: Hybrid data architectures (coming soon)

Part 1: APIs

APIs have properties that share direct parallels to manufacturing and hardware systems: They are building blocks to something more complex, they are reusable by multiple clients/teams, they come in different shapes and sizes, and they have the ability to serve inside and outside of an organization. Think about it, and you’ll see that the same properties are shared with highly functional manufacturing companies and hardware products.

Let’s have a look at an example that mirrors a real-world API-driven system that I developed at a manufacturing company. This is simplified by only focusing on the relevant processes. In reality, you can add dozens more subprocesses and functions outside of the manufacturing workflow.

Previous architecture, involving stop-and-go manual interactions between each subprocess
With an API architecture, we were able to remove human error during analysis and mundane data shoveling for semi-automated processes

The diagram shows submodules that make up the entire system and the outcome to provide a pass/fail result to the higher-level system (MES). In a future post, I’ll describe how this architecture also makes data analysis of the actual test data much faster and more meaningful to enable things like automated certification analysis.

In the past, each transaction between these blocks was done by manually typing in commands or searching through folder structures to retrieve information and execute actions in the process. Furthermore, if something changed with the specification, the process to find out-of-date parts and recall them was manual and extremely error-prone. With event-driven manufacturing architectures (post coming soon), I’ll describe how you can automatically make new decisions using historical data from manufacturing rather than coupling part effectivity with a moment in time.

By putting programmatic interfaces (APIs) between each of these blocks, we not only removed the manual interface. We also made those interfaces reusable for other applications. In fact, once we had a common driver for the data analysis system, we were able to extend the system into more applications even faster — exponentially increasing our efficiency and our quality. For example, adding automatic photo documentation would have been a completely separate project and system. Instead, we just extended the same system:

Same architecture. Just a new downstream API to support automatic photo capture.

A key note about each of these APIs is that they are not all owned by one person or even one team. The core logic was federated between different teams, allowing the product to get built in the best way possible without having to funnel specific expertise from one team to another, which often creates distrust and friction. Whereas in the past, one team would own the methodology while another team owned the process (process engineering), teams use each others APIs to drive those methodologies into processes. This is incredibly powerful because “full-stack” engineers aren’t as prevalent in hardware manufacturing. In fact, you may have highly technical people doing dynamics analysis, thermal analysis, or materials research — all of whom still have an interest in building the product and using manufacturing data to improve their methods. If you’re so inclined, check out this ex-Amazon employees’ post on how service-oriented architecture served Amazon’s growing enterprise.

Finally, APIs allow more than just team to team communication and automated process coordination. They open up the possibilities for human-machine collaboration that previously was bottlenecked by the human interface. The cutting-edge interface traditionally has been the HMI (human machine interface) which still require the human to interact with the higher-order systems like MES or ERP. Now, APIs and drivers at the machine level allow humans and machines to both participate with the higher-order systems like ERP and MES, simplifying tasks for humans and removing redundant and repetitive “setup tasks”. With machines reporting up to higher-order systems, they can also report their own health, keeping humans safer and manufacturing lines humming.

APIs will play critical role as manufacturing returns to the USA and the low-cost and high-value technologies developed in the past 10–20 years leapfrog previous generations of technology. Specifically, software and electronics will more closely embed with mechanical elements and manufacturing methods like composites and additive manufacturing to accelerate miniaturization, cost, and reliability.

In the next post, we’ll show how APIs are the key building block to another new concept that is necessary to realize Industry 4.0: Event-driven manufacturing and organizations.



Karan Talati
First Resonance

Building the future of manufacturing at @firstresonance.