API-first strategy: Three guidelines
Leading companies put this product mindset into action through “API-first” strategies in which APIs offered to business units and third parties become the primary product of the IT development teams.
Three lessons have emerged as these approaches have evolved:
1. Consider the digital business perspective first.
It’s tempting for development teams to crank out APIs under the premise that the more created, the more digital services the enterprise’s business-led IT teams can build. This overlooks the critical first step in any digital strategy: understanding the current state of the enterprise’s business capabilities and mapping how and where they need to advance in order to meet digital objectives. While this may sound academic, it’s essential to both prioritizing the production of APIs and avoiding APIs that won’t see adoption or usage.
One company we work with looked at its business capabilities through the lens of digital interoperability. For the capabilities they deemed most important to achieving their digital objectives, they asked how easily new systems, services and data could tie into those capabilities. They used that assessment to determine where the enterprise should prioritize API development — for example, in areas that represented clear business opportunities as interoperability improved.
2. Figure out corporate IT’s comparative advantage.
Even when business capability mapping is used to help prioritize API development, many corporate IT departments shoulder the full burden of development. But this approach risks falling into an old mindset — that the enterprise wants APIs so IT will produce them, even if IT developers will struggle to keep pace with demand.
Smart API-first strategies recognize that what the enterprise wants is simplification and speed. Thinking in terms of these outcomes leads to not just IT-led production of APIs but the development of tools and environments that allow business users to develop their own APIs. In other words, corporate IT doesn’t need to be a producer, but an enabler — and ideally should only build APIs when it brings a distinct advantage to task.
One company used its business capability mapping to focus corporate IT development on the APIs that had the most complex information risk and compliance requirements — areas where corporate IT had the most expertise and insight. For APIs with less complex requirements, corporate IT provided oversight and coordination but permitted business units to lead API development independently. By doing so, the IT department adhered to its philosophy that, with appropriate risk management, development should be something that corporate IT enables rather than owns.
3. Build a marketplace, not a store.
At enterprises where corporate IT sees itself as sole producer, APIs are often offered to the business through a store similar to an app store. This model presupposes that corporate IT runs the store, and that everyone else is a consumer. But if the goal is to enable API development (and sharing) within business lines, corporate IT should offer a marketplace, not a store.
A marketplace offers not just APIs to potential consumers, but also the tools for other potential producers to build, test and share their own APIs. It serves as a hub to build and offer APIs, complete with descriptions, usage statistics and consumption readiness information. This makes corporate IT an enabler for business-led IT, setting up the guidelines to ensure all APIs meet regulatory standards, avoid redundancies and help consumers use APIs effectively and independently. The ideal marketplace is facilitated by corporate IT, but functions as an active environment for learning, building, testing and sharing, scaling development across a wider ecosystem.