What Is An API First Strategy? IT architecture And Catalyst For Engagement
15 Aug 2014
I wrote about What Is An API First Strategy? Adding Some Dimensions To This New Question the other day after talking with 18F. One of the commonets on the post was from my friend Logan Powell (@logantpowell), and I think it was so good, that it deserves its own post. I will let Logan do the talking:
To supplement the pool of meaning here, I would like to add that an API-first strategy is one where the API serves as both a pattern of an enterprises IT architecture as well as catalyst for engagement.
In a nutshell, an API-first strategy is a systems paradigm shift
-- from a centralized, engineered mechanical system made up of subordinate parts serving as means to deliberately designed ends
-- to a decentralized, organic and evolving ecosystem where the individual actors can be spontaneously enfranchised or co-opted by any other actor / set of actors to serve new purposes.
This allows the system to be more flexible, respond more quickly and behave more dynamically to suit unforeseen purposes. I believe the API-first paradigm is thereby more scalable by nature.
Prudent separation of information from presentation through APIs should be the first and next step for most organizations with large IT infrastructures. To be more specific, this provides a number of efficiency benefits. To just name a few: by modulating infrastructure with solid APIs, stakeholders can create / hack together production-ready applications faster, more securely and more reliably.
This approach warrants a new form of IT team protocol wherein the curation of APIs is front-and-center to their role. When designing a new product / service, the design of it's API should be commensurate. As the product or service makes it's way to production, making sure the API is well documented, easy to use / as conventional as possible, hooked up with analytics, secure and prepared to scale should be a given (these are frequently included in any self-respecting API management solution). In so doing, not only might the enterprise benefit from the speedier and more rewarding 'dog-fooding' of these services / resources, if they ever decide to commercialize or publicize / open them up to users outside their organization (the decision to flip the switch itself being informed by the aforementioned analytics), it's just an invite / key request away.
Logan works in the federal government, on some pretty high value open data and API projects, and he is on the frontline for how APIs can be a catalyst for change within enterprise IT, but also connect externally in some meaningful ways--in short he knows his stuff, and is helping internalize APIs across the federal government.
What Logan describes IS why I believe so paassionately in APIs. In my mind It is the culural change, with an eye towards exernal interactions and conversations that make APIs work, and while the tech of APIs is critical, it is the cultural, organizational, and ultimately the human aspects of APIs that make the biggest impact.