Increasingly, there is talk about “API Factories”, which is the idea of creating APIs en masse and at low cost. At first sight, this may seem appealing and even have a certain logic to it. After all, APIs become increasingly ubiquitous and thus large organizations will probably have many of them. In that case it only makes sense to focus on producing them in the same way as industrialization reduced manufacturing cost and started to produce items at cheaper prices, right?
Listen to Erik’s podcast interview of this article.
Before I start with my argument against this idea, here’s a bit of personal history. Not too long ago I joined a company that had what I still consider the best software company tagline ever created: “Business, rewritten by software.” It was the first time I thought that a tagline had both substance and was catchy, and I absolutely loved it. Then, like all campaigns, this one ended and was replaced by “The Modern Software Factory.” Not only was this one much more fluffy, it also was accommodated by a thoroughly confusing ad campaign where people asked a guy what the software factory was, only to be met with random handwaving and in the end both the people in the ad as well as people watching the ad were more confused than before. As you may be able to tell, this campaign (now discontinued) still hurts, and this may be part of the reason why “software factory” talk still gets me a little agitated.
Getting back to the topic of this article: Yes, the industrial revolution went through a major step when it advanced from its initial first phase of mechanization (steam engines) to the following phase of mass production (assembly lines). It is painfully obvious to point out that mass-producing physical products is very different from producing digital products (which can be copied at zero cost and thus there only needs to be one copy of each product being actively “produced”), but this sometimes seems to get forgotten. So let’s discuss the assembly line logic.
Workshops over Assembly Lines
The image of “digital assembly lines” sometimes is being used to evoke the idea of “low-cost production of digital products.” However, it is important to remember that assembly lines are optimized for churning out (nearly) identical copies of one (oftentimes cleverly designed) product, whereas the production of digital products is an entirely different matter.
Regardless of the assembly line idea, of course the production of software can be done more or less effectively. This is pretty much the story of enterprise computing. Working in the space of digital transformation myself, I am acutely aware of the needs of organizations to become faster and better at creating digital products that will improve their profits and competitiveness. But is what they need the ability to churn out nearly identical copies of the same thing, created by workers that mechanically go through their moves to create similar items over and over again?
What’s needed instead is the model of a workshop and a workbench: A place where workers get all the support and tooling that they need to create products of a certain class, but where there also are a lot of combined skills and sufficient autonomy to discuss product ideas, to create prototypes, and to test early versions of products and then improve them based on feedback gathered from users.
Working in the API space, this is what has proven to be the most effective way to produce quality products. The API platform nowadays is the equivalent of the workbench, and the workshop is the community of practitioners that is created by following organizational models that focus on cross-functional teams so that products are created with as much talent and input and creativity as possible.
Collaborating with a large car manufacturer, it was fascinating to see how their organizational DNA slowed things down tremendously. In their case, software production is organized in terms of car models, and everything clearly is organized in the spirit of designing and building something extremely carefully, because once millions of copies are out there on the streets, it is virtually impossible to fix them… Of course, this is very different for connected cars and onboard services, and in particular for services that are not safety-critical. But adjusting an organization to this entirely different model of design thinking and production processes can be very hard.
Value over Volume
By focusing on workshops over factories, what you’re doing is essentially focusing on value over volume. And when you think of your digital transformation initiative and your API strategy, do you want many low-quality APIs produced at record pace, or wouldn’t it be better to focus on quality instead and not be overly focused on counting APIs?
I have seen numerous organizations where literally the “number of APIs created” became part of team KPIs, and what happened was easy to predict and sad to see: Teams started churning out APIs (“thank you, low/no code tools!”) but hardly anybody used them because they had no visible value to anybody outside of the inner circle of people understanding which exact systems these APIs represented. This was seeing Goodhart’s law (my favorite law!) in exemplary action: If you turn a measurement into a metric, it ceases to be a useful measurement.
Instead, manage APIs as products and put the same care into creating them that you apply when you create other products that are critical for your business: Think about their utility. Think about (and talk to) who will be using them. Design them carefully to make users happy. Release early so that you can gather user feedback. Be prepared to continuously improve your product based on feedback and changing needs. Manage your product in a lifecycle that has a clear model throughout the product’s lifetime.
In short: Yes, absolutely invest in making API production more effective by supporting teams on their API journey. Establish an API culture so that thinking of products as APIs becomes second nature to everybody (specifically, not just the “IT specialists”). Make sure that everybody knows to focus on the business domain and the business value. Provide an API platform and an API program so that everybody get as much support as possible for all cross-cutting API concerns. But do not establish API quantity as a measurement of how well your API initiative is going. In the end, most importantly an API product is a product, so apply measures that make sense with this in mind. After all, you wouldn’t measure the success of your business based on just how many different products it can produce, right?
If you want to establish some metric, rather look at “time to value.” For this metric, figure out how quickly a value proposition can be turned into an API that is created and then used in a value chain. If there are problems along the way, focus on identifying these problems and reducing/removing them. This way, you are focusing on the ultimate goal of digital transformation: To become better at identifying opportunities enabled by digital technologies, and at tapping into them as quickly and as cost-effectively as possible.
API Factory Opportunity Costs
Another thing to keep in mind are the opportunity costs of focusing on volume over value. Yes, the API practice should be scalable, but as explained above, that’s different from “producing as many APIs as possible.” Each published API has costs associated with it, even when you make it very effective to publish them:
- Consumers start using the API and the API must be managed and maintained to satisfy these consumers.
- Low value APIs make consumer development more costly, and may impede consumer and ultimately customer experience.
- The more tightly coupled consumers are to an API (which is typically one aspect of badly designed APIs), the harder will it be for them to switch if that API is retired.
In summary, it seems that there are numerous good reasons why it is better to focus on quality over quantity when it comes to producing APIs. And there is one last point which some of you may regard as a bit of conspiracy theory, but I still want to mention it at least as some food for thought…
Cui bono?
When looking at who talks about “API factories”, it often are companies that directly benefit from more coding happening in an organization. They are the ones staffing these projects, and long-term they also may be the ones benefitting from the “API spaghetti” that this approach ends up producing.
So keep in mind who is having which incentives, and gives which kind of advice. It may provide additional insight into the dynamics of some of the guidance and discussions.
Summary
In summary, when it comes to APIs, focus on value over volume. This does not mean that you should not focus on making API product teams as effective as possible by having an API strategy, providing an API platform, and running an API program. You absolutely should do all these things. But just because you want to make the API part of API products as effective and scalable as possible, that doesn’t mean that the goal is to “churn out APIs.”
The trickiest part of effective digital transformation is getting the teams right, because as Conway’s law (another great law!) tells us, what you produce will inevitably be a reflection of how you are producing it. So focus on building high-value teams, empower them with an effective environment, and then let them focus on business needs and build products that directly address and solve those business needs. That way, your organization will produce just the right number of high-value APIs.
