I recently attended #APIconUK, a conference on APIs organised by the folks at Programmable Web. This event was aimed at developers (bottom-up API development) rather than more traditional enterprise customers (top-down SOA-types), and as such was very poorly represented by enterprise-minded folks. Which, IMO, is a bit short-sighted.
The conference was good – a nice mix of hands on, technical and strategic presentations with plenty of time to chat to people between sessions.
Sadly I couldn’t make all the sessions, but key themes I picked up were:
- Emphasis on treating APIs as a product
- Computational APIs using Wolfram Alpha’s Mathematica
- The rise of Linked Data
- API Security
- Payment APIs (Stripe)
- Monetisation of APIs using crypto-currencies
- Mobile developers & APIs
Adding all these together, what does it really mean?
- APIs must be treated as first-class citizens with respect to technology management..inventoried/marketed, governed and supported in much the same way applications have been in the past.
- It is possible to rapidly build useful services using sophisticated but usually not enterprise-standard tools like Mathematica, but to expose the end result as a RESTful API, which the enterprise IT teams can then re-implement in standard technologies. This allows consumers of the API to gain early benefit, and allow enterprise IT time to implement it in a sustainable,medium-term cost effective way.
- Linked Data – the idea of attaching semantics to API information – is key for Machine Learning. APIs have the opportunity to become dynamic and self-forming when coupled with semantic information via Linked Data standards. Machine Learning is, in turn, key to automate or significantly improve processes that have relied on traditional BI reporting methods.
- API security is a huge concern, but lots of vendors and solutions are beginning to appear in this space. In essence, it is quick and easy for anyone to create an API (just build a RESTful interface), but API management tools can help control who accesses that API, etc. It also imposes a level of governance to avoid proliferation of dubiously useful APIs.
- Payment APIs are the next big thing. Stripe demonstrated a live build-it-from-scratch example of how to use their payment APIs, and it is remarkably simple. It doesn’t even need a client side SDK, as you can invoke the API via tools like CURL etc. An excellent example of how a simple API can hide the complexity of the back-end processing that must go on to make it appear simple..
- Monetisation of APIs could be huge to incentivise the development of reusable services in direct response to demand. This is a significant topic, but essentially the current API model relies on many (internet-based) API providers ultimately making money from advertising, and not from the API itself. Introducing an API currency which is exchanged whenever external APIs are used, or external services use your API, is an intriguing concept, which may be useful even in a ‘traditional’ corporate environment, and would allow service providers to monetise their services directly without having to rely on ‘eyeball’ oriented revenue.
- Mobile developers today still tend to build the back-end in a way that is highly optimised for the mobile application – in other words, any APIs built (RESTful or otherwise) tend to be designed for the specific needs of the mobile app, and not provided as a general service. Mobile developers have the opportunity to take the lead in ensuring that any mobile app results in the publishing of one or more enterprise-relevant services that other (mobile) app developers could use. Clearly this has an impact on how systems are designed and built, which is likely why the focus on mobile hasn’t produced good enterprise-relevant APIs.
Where does this leave the enterprise CTO? Here’s my take:
1) Mobile apps is where a lot of attention is these days..make sure every mobile project catalogs its data and makes an effort to publish reusable APIs. Do not let every mobile app have its own back-end server implementation, unless it is essentially just an orchestration layer.
2) Encourage developers to build and catalog APIs..even creating a simple, human-discoverable internal catalog like the one Programmable Web has would be a good start.
3) Understand your data from a business perspective, and document it using semantic web standards. This not only helps with IT planning, but is also directly usable in API and machine-learning initiatives, through standards like RDF and JSON-LD. Data architects are the best folks to tackle this.
4) Use API Management tools to help manage and control the creation and use of APIs.
5) Adopt principles like those proposed by the Reactive Development Movement to ensure that architectures behind APIs meet basic architectural standards, so they have some hope of coping with unplanned growth and utilisation.
6) Any app that does Payments should use a well-defined Payments API. It’s beyond the right time to develop internal Payment API standards for apps that have payment processing requirements..the increasing use of alternative currencies will expedite the need for this, as many traditional or legacy systems will not be able to cope with these currencies, so the API should hide this. Plus. it will help manage the transition from current state to target application landscape for payments-related applications. A model-driven approach to payments is key to this, especially as international payments standards take time to evolve.
7) APIs can enable innovative (read: non-standard) use of IT solutions, as long as the innovation can be encapsulated behind standard APIs. This gives the enterprise IT folks time to plan how to support the API, but still allow (limited) business adoption of the API for immediate business value.
With respect to how this all relates to SOA-type enterprise integration strategies, I’m still forming a view. Specifically, the internet itself does not have the concept of a ‘bus’. Someday it possibly will. But this is one space where the innovation still needs to come from enterprises, which still struggle with implementing successful SOA architectures that extend much beyond departmental boundaries.
Finally, the relationship between APIs and crypto-currencies is potentially so huge, that I will cover that another day..