Without APIs enterprises cannot innovate. A bold but accurate statement. This post will examine why this statement is true and provide guidance to various enterprise roles on the apparatus necessary to move from laggard to a leader in innovation through APIs.
First and foremost, what is wrong with the old approach? Big projects and linking libraries or even better just copying and pasting common code? It did work, didn’t it? The answer is yes; it works but it is inadequate to support the rate and pace of change necessary to support an agile organization (which in turn is doing the important task of supporting an agile business model). The problem is that the level of technical interaction is too low in the stack and the cognitive overhead is too high to make use of the assets.
Enterprises must have a vibrant external and internal ecosystem supported by APIs. It is typical that enterprises have a complete and polished look for their external facing APIs and radically neglect their internal equivalents. Sure, customers don’t see the internal APIs but they do see the business model and innovation that results from them.
So, if you belong to an enterprise what do you do and who needs to do it?
Chief Technology Officer
The CTO must be the champion to instill the importance of APIs in fostering innovation. The CTO must also be the individual to mandate it. If a team is delivering a service that doesn’t expose an interface for programmatic consumption then shut it down.
The CTO must also provide the guidelines (fewer = better) and the technological frameworks to take the heavy lifting off the shoulders of the product owners and developers in terms of how to create these APIs. A reference technology stack (that exists outside of PowerPoint) that serves as the basis for new services goes a long way in helping teams to cooperate.
Lastly, the CTO must vigorously measure the heartbeat of the services in terms of health and consumption. If services have interfaces, but fail constantly, it is almost as bad as not having an interface in the first place (certainly in the eyes of generating business value).
Chief Information Officer
The CIO’s role is to provide the infrastructure for the CTO and the developers to do their job. This includes at a minimum:
- API Catalog
- Self-service API Management (self-service = no staff needed to board!)
- Gateway services for handling internal to external interface promotions
- A modern, social coding platform for the developers
An API catalog is the start of an effective API ecosystem. Without a catalog, developers are only going to discover APIs through ad-hoc social networks and random chance. A searchable, intuitive catalog that lists APIs as well as provides context around real usage is key to getting developers and services connected. If your enterprise does not have this then you have yet to take the first step in enabling an ecosystem.
API Management is necessary as it does a lot of the grunt work associated with exposing an API in the context of a service (i.e. user association, key provisioning, rate limiting). These functions will not differentiate your business, outsource them to a product or a SaaS offering. There are many high-quality options to choose from.
Gateway services imply that the networking infrastructure is in order and network zones haven’t been constructed in a way that makes service promotion from internal to external impossible. This needs to be a well-defined, well used process, not ad hoc.
Social coding platform should be a no-brainer but in the case of intra-enterprise API adoption it helps to enable developers to see the code backing each others’ services. Not only can they understand the functionality better but they can contribute to it as users.
Lines of Business
The LOB, or development muscle, need to understand that they aren’t the leaf nodes on a tree-based value chain. Rather, they are just one more node in an ever growing graph. The asset they produce must be used by others and augmented in ways they could not have originally foreseen. This is how enterprises seize business opportunities today. The answer isn’t to cauterize the innovation but to allow it to reconnect to other existing services and new services.
The technical community at large has done wonders advance the methodologies, toolsets and experiences necessary to empower enterprises to innovate orders of magnitude more quickly than they do today. It is not up to enterprises to embrace that their internal developers need just as a robust system as their external clients. Don’t wait, make a meaningful commitment to supporting your agile enterprise by looking to your CTO, CIO and LOBs to leverage APIs for a new level of innovation.
Do you work in a large enterprise? Are you satisfied with the level of internal tooling available to empower an internal API economy?