Have you ever asked yourself why API development can’t be more like industrial manufacturing — predictable, efficient, and relatively drama-free? They’re quite similar endeavors, after all. Whether your organization builds APIs or electric cars, the goal is still the same: to make something that people will love to use. The only difference is how tangible (or intangible) the inputs and outputs are.
Yet manufacturing and software development are perceived quite differently. Manufacturing is often associated with efficiency and economy of scale, while software development is more often associated with delays and cost overruns. Why is that?
Let’s discuss some of the disconnects between traditional manufacturing and API development and how adopting lessons learned from lean manufacturing can enable API developers to implement a more stable and efficient development process that leads to superior APIs and business outcomes.
Bottlenecks and Pinch Points
One reason for the disconnect is that manufacturing takes a design-first approach, builds quality assurance (QA) into the process, and identifies bottlenecks and potential pinch points in the process before production starts.
On the other hand, the most common software development models (whether leveraging waterfall or an agile-based methodology) do not bring QA into the process until much later, and they’re less focused on standardization and pinch points. These blind spots can lead to delays, cost overruns, and inefficient use of software developers’ time. These delays are expensive and disruptive — but mostly avoidable.
The good news is that API development can be a more systematic and streamlined process if organizations take a design-first approach that takes resource constraints — such as crunches on developers’ time — into account beforehand and builds process improvements and workarounds into the process from the beginning.
Reenvisioning API Development through a Manufacturing Lens
While manufacturing and software development differ in many ways, they share a key similarity: both are subject to scarcity and resource constraints. Manufacturers can run out of raw materials, while API developers can exhaust their budget for developers’ time. Fortunately, best practices from manufacturing can significantly improve outcomes in both cases.
The Toyota Production System, the precursor to Lean Manufacturing, is considered to be one of the best models for automotive manufacturing and is an early example of a design-first approach. The system was based on the seven wastes identified by Taiichi Ohno, which are still relevant to any manufacturing or production process — including API development. Each provides an opportunity to proactively address a bottleneck before it slows down production. Examples of waste most relevant to APIs include:
- Defects – resulting from the lack of QA early in the process
- Service failures – APIs that don’t meet customers’ needs
- Overproduction – missed opportunities to reuse code and avoid one-off uses
- Time – downtime waiting for the next steps in the development process to happen, lack of parallel development processes, and lag between sequential activities
- Talent – underutilization and/or misuse of developers’ talent, skill, and knowledge dealing with untested approaches and development plans that haven’t been fully thought through
Once the seven wastes are under control, successful manufacturers go a step further and build a culture of continuous improvement. According to Toyota, they do this by focusing on “a quest for continuous improvement and with an emphasis on their ‘Always a Better Way’ slogan.” In the context of software development and APIs, this translates to building a design-first API program that fosters a deliberate and proactive approach to process design and allows for optimization as lessons learned and best practices are incorporated over time.
Additionally, the design-first approach provides design and development teams with the opportunity to think through potential bottlenecks and vet the approach with developers and other stakeholders in advance. It also provides an opportunity to think about the broader platform perspective, which is an important consideration for APIs.
The API Is the Product, but Integration Is the Goal
One manufacturing characteristic shared by both automobiles and APIs is that the final products created tend to reflect the efficiency and coordination (or lack thereof) in the processes that produced them. For example, Toyota cars and trucks — which are generally sought after for their reliability and value — are the products of efficient, highly integrated systems that have been continuously improved for decades. A design-first API program can set a company’s API products on the same trajectory and add a great deal of stability to development processes.
The reality of developing APIs is that the success of the final product depends on its rate of adoption, based on the ease of use by developers and the efficiency of machines. The API, along with its specifications, governance, and documentation, needs to be in sync, stable, and predictable.
For this to happen within any reasonable or predictable time frame, all components must be developed and maintained simultaneously within a well-orchestrated process. The traditional “code first and worry about the docs later” approach precludes the possibility of this level of tight coordination. This results in a great deal of wasted time and developer rework and ultimately produces APIs that don’t look and feel like they came from a sound and stable process.
For a better outcome, organizations creating APIs should adopt tools that facilitate an efficient, comprehensive process that yields predictable, high-quality results. The goal should be to create APIs that are designed with all consumers and stakeholders in mind, with the adaptability and flexibility to integrate into other technology down the line when innovation strikes. At Stoplight, we refer to this approach as ‘design-first.’ The result of a design-first process is an API product that is comprehensive, consistent, and understandable by both collaborators and machines.
Design First, Code Less
If you’re building APIs or paying another company to do it for you, how’s the process going? Is it an organized, cumulative process that builds on itself, or are you seeing disconnects, tech debt, redundancies, or loose ends?
I help organizations bring their API business strategy to reality and get them implemented onto design-first API development platforms and processes. Feel free to leave a comment below or contact me through LinkedIn if you would like to discuss how to improve your APIs and business outcomes.
