Without good APIs Google would fall to the likes of Amazon, Microsoft, and Facebook, claimed Steve Yegge in his seminal 2011 internal memo. Although the intention was to emphasize the importance of APIs for webscale service providers, the need for robust, scalable, and secure APIs has increasingly gained traction among today’s enterprises seeking to “digitize” their organization.
If you look at announcements by Workday, ServiceNow, and others, the new path to building competitive advantage is through increasing accessibility. Put plainly, these companies are enabling third parties to plug into their platforms to increase the overall value for the joint end-customer. APIs make this outcome possible . Billion-dollar upshoots like Twilio, Slack, and Stripe have been built on these concepts. APIs serve as the lynchpin that drives velocity, adoption, and platform success, whether the goal is to deliver accessibility to internal developers in a microservices world, or to create platform hooks for external integrators. APIs open value to enterprise software vendors and their customers.
But API quality matters, whether you are looking to increase business agility through automation or provide a consistent and predictable method for developers to interact with a platform or service. Great APIs are designed with internal and external service consumption in mind. In the context of digital transformation, this is the piece that makes things move fast. APIs are the bridges that allow interoperability, automation, centralized analytics, and microservice architectures. The benefits are responsiveness and the ability to quickly find competitive advantages through fast release cycles, experimentation, and shorter feedback loops.
Unfortunately, for the vast number of enterprise architects that are tasked with delivering the IT components for their CIO/CDO’s digital transformation strategy, few have had hands-on experience with building and maintaining an API. The downside to this paradigm is that without the ability to objectively measure the strength of a vendor-supplied API, it’s nearly impossible to forecast the amount of work required for downstream platform and operations teams to implement the technology. This lengthens the time-to-value for the business, perhaps losing the competitive advantage goals, if not ROI, the business was hoping for.
So how do you know if a vendor has a usable API? It comes down to 4 key factors:
- Consumability
- Extensibility
- Versioning
- Security
Consumability: Does the vendor use an easy to understand, industry standard approach like REST? Is there an SDK ( a software development kit that serves as launching point with great documentation and templates) or is it just standalone HTTP calls? Ideally, you can do both—an SDK for quick start and version bridging, and HTTP calls for specific, advanced API calls. When you do interact with the API, does it work how you’d expect? Do the objects make sense and are they consistent? If you’re not getting the warm fuzzies on the first call, then imagine working with the APIs at scale or as part of a CI/CD pipeline.
Extensibility: A vendor’s ability to seamlessly incorporate new functionality into the API flow as the product matures depends greatly on the flexibility of the original API design. Yes, even an API can have technical debt. Extensibility limitations come to light when new features or integrations are added and do not fit within the current schema. The impact to the customer is either delayed feature enhancements or releases with limited potential for automation.
For example, incorporating strategic functionality such as machine learning and AI by integrating third party data sets into an application may not conform to the original API implementation of Create Read Update Delete, creating the need for an API refactor. By architecting the API with a high degree of extensibility, the vendor is able to add more types of requests/responses as situations arise.
Versioning: Every enterprise wants to partner with a vendor that innovates. The problem is that when a vendor releases a new version, the customer isn’t always ready to consume it. Versioning provides the best of both worlds. In software, product enhancements and new integrations typically result in changes to the object model. When this occurs, a new API version is packaged and released. APIs that do not include versioning require customers to upgrade (sometimes with minimal notice) their API calls/scripts to conform to the latest version for all functionality to remain.
With versioning, the API provides a bridge between what the customer expects and what the product understands, decoupling the customer environment from the natural evolution of the product. A few years ago Facebook opted to reverse course and offer versioning on their ads platform due to the disruption these types of changes can cause.
Security: Fortunately in the API space, you do not need to sacrifice accessibility to implement security. With security, it’s important to have a consistent model for managing roles and permissions. As more and more applications are brought into the fold through the adoption of microservices, role-based access control (RBAC) becomes paramount to creating bumpers while still enabling self-service and automation. Access to APIs needs to reflect this hierarchy and adequately provide logging of HTTP calls for auditing and ongoing tracing purposes. As APIs become more widely adopted, security professionals are beginning to evaluate them based on capabilities like requestor visibility, event-driven denylisting, and policy management.
API-first technologies that possess these fundamental attributes will make your platform engineering and SRE teams ecstatic. Rather than trying to overcome manual processes by “automating” workflows through short-lived, static scripting and CLI commands, operations teams can focus on value-creation by leveraging APIs. Through APIs, operators can automate entire lifecycles, from deployment to CI/CD pipelines to metrics-driven operations and autoscaling. Fortunately Google had its wake up call. Now it’s time traditional enterprises and their technology vendor partners had theirs as well.
