Technologists are good at seeing and building technology, but aren’t so good at seeing the business things. We’d rather invent entirely new specifications and approaches to things rather than having to actually sit down with other human beings and learn about how business works. After 165 Breaking Changes Episodes and 100+ enterprise conversations at Postman, and spending a year in the trenches at Bloomberg, I can confidently say that the single greatest reason API operations is in the sprawling state of chaos it is today is due to the lack of business alignment with how APIs are done. Yet, we keep thinking that if we just throw some more technology at the problem, eventually we are going to fix it.
I knew when I saw TypeSpec emerge that it would never receive widespread adoption or alleviate any pain, because it spoke to none of the business needs we are facing. When I saw Frank working diligently on the Arazzo spec, and Lorna push the Overlays spec over the finish line, I knew that these specs would see adoption and have an impact because they spoke to defining more of the business reasons we need APIs. When I saw MCP and A2A emerge, I once again see more technological solutionism without any awareness or consideration for the business details of APIs. MCP, A2A, and TypeSpec are technical specs created by technical people to satisfy their technical desires. These specs lead us to more API sprawl, which is good business for vendors, but not good business for your average enterprise.
To tackle API sprawl across applications, and deliver efficiency, productivity, and revenue for enterprises across desktop, web, mobile, infrastructure, and yes, even AI applications, you will need business alignment. We need the workflow discussions that Arazzo provides, the cross-team coordination on experience that OpenAPI Overlays provides, and we need the business alignment that APIOps Cycles provides. AI has many uses, it isn’t going to align the business and engineering canyon that grown alongside your API sprawl and chaos—it is just going to widen it. Making digital resources and capabilities available and useful in any applications means it has to be available technically, but it also has to meet the needs of businesses producing the resources and capabilities, but also the businesses who are consuming them. MCP and A2A do not drive this important work, and will further exasturbate the sprawl and chaos.