A lot of attention is spent on breaking changes when it comes to the technical details involved with releasing new versions of our APIs, but recent conversations I’ve been having with folks have left me wondering what breaking changes look like when it comes to the business side of things. While there is still a lot of confusion around what a technical breaking change is, it is generally accepted that if you remove or update anything that existed in a previous version of an API, you are introducing a breaking change–wat is the equivalent of this business side of things?
My recent conversation with Stanislav Zmiev, Tech Lead of Platform Engineering at Monite about versioning, another upcoming discussion around not versioning your API at all, as well as discussions around shifting priorities involving AI has left me pondering what is a breaking business change for an API versus a breaking technical change. I would say a pricing tier and rate limit change would be top of the list why I have been unable to continue using an API in my applications and integrations. Next, I’d say terms of service, privacy policy, and security changes would be next on my list. After that I would say the quality and reliability of the digital resources and capabilities are changing along with business changes. I’ve heard numerous stories over the years of these things breaking applications, but they generally aren’t something we showcase in change logs, and are talked about with the same levels of concern that we do the technical breaking changes that cause outages and the increased work created across our applications being powered by APIs.
Is a price change a minor or major change? Is a terms of service or privacy change a minor major change? What about a security breach because corners were cut based upon business decisions? Or could we talk about the business priority shift towards AI and automation leaving teams with fewer resources a major or minor change? These are all things we don’t track as API changes, because they aren’t technical. But, they do impact overall API quality and the ability of applications and integrations to operate or not. Why don’t we talk about business change in the same light as we talk about technical change? Is it because we don’t have source control for business decisions, and artifacts that document what happens when it comes to business priorities impacting the quality and reliability of our API releases? Or is there some other reason? I’ve been studying the business fingerprints across API operations for fifteen years, and I am often left wondering why we don’t have more versioning, road maps, change logs, provenance, and architectural decisions records from the business side of things.
I suspect that in the shadows of the business changes that impact API operations we are going to find more evidence of change that is equally destabilizing as removing or updating a parameter or schema property. I am hyper aware of the reasons we blame engineering folks for the divide between business and engineering across the API operations, but what business changes have occurred that have eroded trust, and also has contributed to the wide gap between business and engineering. I get a sense that there is a lot more hand wringing about breaking technical changes amongst engineers than there is hand wringing about breaking changes amongst product and business leadership. I am guessing product worries because they are accountable to consumers, but I suspect that business leadership is properly insulated from all of this. What are some ways you’ve seen business breaking changes impact an API you produce or consume as part of your applications? I’d love to talk with you about it either on the record or off the record—-feel free to reach out.
