In the early 2000s, companies like Amazon, eBay, and Salesforce drove a trend toward standardizing interfaces among web applications. The result was a complete overhaul of how applications were developed and integrated, thanks to a growing network of open web APIs that anyone could consume.\n\nDuring this period, Amazon founder Jeff Bezos wrote a memo to his employees that came to be known as the \u201cBezos API Mandate.\u201d According to secondary sources, this mandate included two strategic requirements that any IT leader should consider when seeking to maximize the value of their development teams\u2019 efforts. The first is that all interfaces among software developed by any team should be through APIs; the second is that teams should write internal APIs as if they were to be consumed by people outside the company.\n\nThis approach goes a long way toward explaining how Amazon was able to externalize its computing infrastructure \u2014 first to Merchant.com, the company\u2019s ecommerce-as-a-service platform for retailers to build their own online stores, and then to Amazon Web Services, a broader offering that has since taken a life of its own.\n\nFast-forward to 2023 and IT leaders have distilled many more lessons about effective API development and use over the past twenty years. Much of what has been learned is catalogued by the MACH Alliance, a global consortium of nearly 100 technology vendors that promotes \u201copen and best-in-breed enterprise technology ecosystems,\u201d with an emphasis on microservices and APIs.\n\nHere, MACH Alliance members and other IT leaders offer the following three commandments that should underpin any API strategy. These principles not only ensure software systems work well together, but also that teams work together in service of the organization\u2019s overall software development strategy. After all, just as with APIs, when one group of people provides a service to other groups, promises must be clear, and boundaries respected.\n\n1. Adopt an API-first approach\n\nThe most effective way to maximize your API strategy is to take what is known as an \u201cAPI first\u201d approach, in which APIs are prioritized as the building blocks of your software development strategy from the ground up.\n\nAPI-first organizations focus more on interfacing than integrating. They define APIs first, including the service they perform, the inputs they take, and the outputs they produce, before writing any other code. In this way, rather than integrating various software components to build a monolithic application, they use componentized services that are made available to an ecosystem through their APIs. Organizations that do not use an API-first approach develop their software before designing their APIs, which limits their usefulness, says Casper Rasmussen, global SVP of technology at Valtech and president of the MACH Alliance.\n\n\u201cAPI first is about designing interfaces that are versatile, rather than specific to a particular use case,\u201d Rasmussen says. \u201cIf you\u2019ve bolted APIs on top of your existing legacy software, you are not API first \u2014 at least not historically. The legacy software carries assumptions about what it does, to whom, and in what use case. API first is much more versatile, much more generic. Think about, for instance, an API strategy that assumes the consumer is going to be a web client. It communicates HTML, which makes it difficult to use in other environments.\u201d\n\nAn API-first approach enables organizations to take full advantage of microservices architecture, a variant of service-oriented architecture (SOA), in which applications are structured as collections of loosely coupled services. One company that has adopted an API-first approach is The Lego Group \u2014 fittingly, given that the concept mimics the Legos product set, where standard interfaces on the bricks enable users to piece together a larger whole.\n\n\u201cOur strategic priority is to build loosely coupled systems, supported by our product teams who build and operate APIs to expose their services,\u201d says Niall Edwards, vice president of marketing and channels technology at The Lego Group. \u201cOur Lego.com technology platform has been entirely microservices- and API-based for a number of years now and we are now propagating this approach across all of our technology areas. We are now bringing this approach to the more monolithic enterprise systems.\u201d\n\nThe Lego Group offers a perfect example of how the API-first approach favors microservices, rather than larger, more complex functionality. New APIs should perform narrowly defined services that can be used by a variety of applications. Older systems can be retrofitted with APIs in a way that enables applications to consume legacy services as if they were newly developed.\n\nAs legacy technology investments come up for replacement, CIOs would be wise to ensure new vendors are brought in only if they deliver microservices and conform to API-first principles.\n\n2. Develop an API policy and enforce it\n\nTo ensure loose coupling and high coherence among software components developed by different groups\u2014both internal and external\u2014a common API policy is necessary.\n\nThe policy should indicate that some services are performed centrally by IT, even as most API work is implemented independently by a variety of development teams. For example, to ensure consistency, access control should be centrally managed, with one identification and authentication scheme to be used by all APIs. Data format should also be centrally managed to ensure uniformity. And finally, service level agreements (SLAs) should be defined and controlled by IT. For example, you might say that for anything customer facing, the APIs should respond within 50 milliseconds.\n\n\u201cIf there is no clarity on who is responsible for what, then its chaos and no one knows the source of truth,\u201d says Edwards. \u201cThe enterprise data model must clearly indicate who is accountable for which data. Users of that data need to know they can cache it and use it but never change it. Changes to data occur only back at the source, and those changes should be discoverable and exposed to all consumers.\u201d\n\nAPIs needed to be backed by microservices to be most effective. CIOs should define APIs with this assumption and then either build the service internally or select vendors that provide services that adhere to this approach.\n\n\u201cAPIs should be independently callable, stateless, and idempotent,\u201d says Kelly Goetsch, chief strategy officer at commercetools and author of four books on APIs and microservices. This means that an application can use an API without having to call another first, and that values internal to the service are not changed in a way that causes it to produce a different result each time it\u2019s called. For example, you can invoke an API to add to a cart several times \u2014 and if it is idempotent, it will act the same way each time it\u2019s invoked.\n\nFinally, the policy should ensure there is no distinction between internal-only APIs and external APIs. \u201cOne of the brilliant parts of the Bezos Mandate was to say that APIs need to be externalized by default," says Rasmussen. "And if you look at AWS, which started as an internal project, they made it available to the outside world by just changing the access on what was already being used inside the company.\u201d\n\nOnce an API policy is put in place, the key is to make sure all teams adhere to it. With so many moving parts, connections, and data in transit, this is a crucial facet no IT leader should overlook.\n\n3. Build and maintain a catalog of APIs\n\nWith such a wide array of services likely to be necessary to fulfill your API vision, it\u2019s also essential to index the APIs your organization is creating, as well as those your organization is likely to rely on third parties to provide.\n\n\u201cCIOs should develop a catalog of APIs and a strategy for managing that catalog,\u201d says Goetsch. \u201cThe catalog should define APIs and include all functionality the enterprise needs. Then you can decide whether to build or buy the software that provides those services.\u201d\n\nWhile the catalog should be centrally maintained, the responsibility for implementation should be left with individual teams or external vendors. But those who develop the services must be bound by what\u2019s defined in the catalog, Goetsch says.\n\n\u201cThe teams implementing the APIs can pick their database, and a lot of other things,\u201d he says. \u201cBut then if they mess up, hold them accountable. You can very quickly and easily determine if a team is managing it correctly. If the APIs are going down, then you know you got a problem.\u201d\n\nThe central catalog should be well documented and be accompanied by discovery tools that enable internal and external users to find APIs based on a description of their needs or a set of keywords. \u201cThe Lego Group has invested in centralized discoverability tools to help developers find each other\u2019s APIs and use them to compose a bigger product, just like people do with the Lego bricks,\u201d says Edwards.\n\nBy adhering to these three commandments and heeding the wisdom gained through years of experience, IT leaders can build a framework that ensures a clear path to every service. Consumers can count on a solid interface and producers get the freedom they need to build services. Each side can innovate in their own time.