In my surveys of enterprises, the number worried about vendor lock-in has hovered around 90% for 30 years.\u00a0 When you ask enterprises how they avoid it, they respond \u201cstandard interfaces\u201d or \u201copen-source\u201d. Even today, the percentage who include \u201cmanaging APIs\u201d in their list of lock-in avoidance measures is in the statistical noise level, but APIs are perhaps the fastest-growing lock-in problem today, and they\u2019re surely going to become a major problem in the future.\nAPI stands for \u201capplication programming interface\u201d, but the term is broadly used in software today to describe the interfaces between all the software components used in an application, a cloud, or even a network. APIs let pieces of software talk with each other, and they\u2019re essential in every situation where software components rather than hardware devices are connected. What\u2019s creating a challenge in lock-in from APIs today is the fact that networking is shifting more to software, which means it\u2019s shifting to a model where APIs are just as important as those standard interfaces, and enterprises aren\u2019t tracking that important shift.\nInside a network device, you can expect to find four layers of software. At the bottom, there are drivers that provide a general way of linking things like Ethernet interface chips to the rest of the software. Above that, there\u2019s a network operating system (NOS) that provides general hosting capability, and above that is \u201cmiddleware\u201d that handles the specific network features needed. On top of it all are network-dependent applications, including management and service features like unified communications or denial-of-service mitigation. Each of these layers exposes APIs to the other layers.\nWe\u2019re used to different hardware interfaces, Ethernet or passive optical networking or even wireless, and everyone understands that you can\u2019t plug a goes-into into the wrong goes-out-of any more than you can plug an Ethernet cable into a USB port.\u00a0 What makes APIs different is that there\u2019s no physical connector to stop you from trying. An API represents a message exchange specification. Every aspect of message format, data structure, request\/response synchronization, and so forth, are set forth in API specifications, and they all have to match or the software using the API won\u2019t communicate correctly.\u00a0 In other words, mismatched APIs break software, including the software inside devices and network management centers.\nVendors know this, and many (particularly in the network-management space) license their APIs.\u00a0 That means that an enterprise can only use the APIs based on the license terms. It may be impossible to attach software from another vendor to a licensed API, even if you develop the adapter software to do that, without violating the license terms. If you build software to a licensed API and later change the software, you may lose the right to use the API.\u00a0 I saw this particular problem in action at a financial services company, and it took them months to work through the issue.\nEven when vendors aren\u2019t using APIs specifically to lock you in, APIs can create accidental lock-in. Remember those four software layers? It\u2019s likely every layer uses NOS APIs. Most NOSs will use driver APIs, and middleware will likely use both NOS APIs and the APIs of other middleware packages. All this creates a web of interconnection, right? Now suppose that your NOS vendor changes its API. Your primary middleware vendor picks up the change and supports it, but one or more of the other middleware providers doesn\u2019t. If you install the new NOS, you\u2019ll break all the middleware that doesn\u2019t support the API change. If you don\u2019t, you\u2019ll lose the new NOS features and any new features of the single middleware provider that does support the new NOS API.\nEven open-source software has an API problem. Most open-source licenses don\u2019t forbid customization, they only mandate that the source code be made available. A supplier of an open-source NOS or middleware, or of a network-management software tool, could customize some APIs, release the source code, and be compatible with open-source licensing terms. But other software, still expecting the standard APIs for the software, would no longer work with it.\nI\u2019ve seen this problem with Linux, which has a number of distributions that include Linux and various middleware components. You might have an application you want to run on Linux that uses Python, for example. Distro \u201cA\u201d might include a version of Python, and Distro \u201cB\u201d might include another. If you acquire an application\/tool that uses Python, and if Python APIs change between versions, there might be no way to write software that could be portable across the multiple distros.\nYou connect hardware with physical interfaces. You connect software with APIs. If networking, both at the network operations level and within disaggregated devices, is separating software from hardware and building functionality by combining software packages, then you need to be paying just as much attention to APIs as you do to physical interfaces, maybe even more.\nHow?\nThe first step is to require that all software products include a full description of all the APIs they expose and consume. That description has to include a reference to any standard they claim to support, and a full description of any enhancements or extensions.\u00a0 It also has to include the license terms, if any, associated with each of the APIs, and you should ask for sample code that uses the API to confirm how it works.\u00a0 Obviously, if you plan to connect Package A and Package B via an API, their API descriptions have to match fully, or you have to be able to avoid situations (like specific features or commands) that would invoke an extension that both packages don\u2019t support.\nThe second step is to obtain version histories on the software when any API changes are made. What you\u2019re looking for is the schedule of how the changes percolate across multiple software packages. If the vendor of Package A is very fast in supporting new APIs, and the provider of a competing Package A is slow, then you can expect problems to arise if an API change is made, and you select the slow-responding vendor. You may not be able to update your software without breaking some API connection until all the vendors who use the API are on the same page.\nThe final step is to contractualize your assumptions. Even the best research can miss changes in policy or direction, and if a software vendor changes an API, the result could break an application or a network. Get promises written into a contract clause.\nA network device or application is an example of the classic definition of a \u201cblack box\u201d, an object that\u2019s opaque and so whose structure cannot be examined in detail. Black boxes are defined, so the saying goes, by the relationship between their inputs and outputs. Software is really defined by the relationship between those APIs, the ones people aren\u2019t paying as much attention to as they should. If you want to avoid vendor lock-in, deliberate or accidental, then you need to take APIs seriously.