Last week, the Nordic APIs team took on 4 events in 4 Northern European cities in 4 days. There was something for everyone in an agenda that covered API neo-security frameworks, the latest trends in B2B integrations, how government agencies are opening up their data, and API usability best practices. ‘Circuit’ speakers — from Twobo Technologies, Dopter AB, MuleSoft (the parent company of ProgrammableWeb), Layer 7, Twilio, Ping Identity and Axway — were joined by local speakers in each country (including government open data experts from the World Bank, the Danish Government and the Norwegian Weather service, and software vendors Kapow Software and PlanMill). Here are seven key take home messages that ProgrammableWeb heard participants discussing across the four days.
1. “If Only Tesla had Used OpenID Connect”
Tom Burnell, Senior Solution Architect at Axway, works with mostly B2B customers creating private and partner APIs. When speaking with his customers, he shares the cautionary tale of how the private API of electric car maker Tesla was accessed by enterprising external developers. “Three months is a long time to give access to your car to turn on the headlights or windscreen wipers while you are driving at 150 kilometers an hour,” joked Burnell, but the example resonated with the audience, many of whom were developers keen to hear more about how to make their APIs secure. Private and partner APIs need to be designed with the same levels of security that should be used for robust public (open) APIs. This also makes it easier for API maturity growth, when businesses want to start opening up their private and partner APIs to a wider developer audience. Presentations by Travis Spencer (Twobo Technologies) and David Gorton (Ping Identity) shared the latest advances in API neo-security frameworks. Currently, most industry players with an eye to best practice identity management and user authentication are using OAuth 2 and SAML. OpenID Connect is still seen as “the new kid on the block”, but is now being implemented by Google and Salesforce and is expected to become the preferred security protocol, given its ability to rotate security keys regularly with lower maintenance requirements, and a simplified approach to encryption and identity security.
2. APIs (Mostly) Win in the Ongoing SDKs vs APIs battle
There is no doubt that SDKs have a place to play in the developer on-boarding experience. SDKs particularly speed up time to first hello world (as John Sheehan has previously noted), and enable in-house developers to build quick prototypes to demonstrate how to consume external APIs to create business solutions or new application products. But when moving to the production stage, Holger Reinhardt from Layer 7 cautioned developers to avoid the SDK trap. Sharing his personal research and distilling the key findings for the Nordic APIs audience, he noted that the two main problems API consumer-developers face are versioning control and bloated code. If building SDKs into a business application, there is “a whole dependency chain you start consuming in your product because you are using an SDK.” The second problem is the additional code that you end up importing into your app that may not be necessary for the API functions you are using. Reinhardt, fresh off a plane, made the analogy that it is like having a full suitcase as your carry-on luggage when all you really needed was the toothbrush. It was a message that, during the breaks, developers seemed to accept, albeit somewhat reluctantly, still wanting to chase that initial buzz of satisfaction that comes with creating fast, workable prototypes with SDKs, ready to show off to their peers.
3. Open Data Needs Your Success Stories
Swedish developer Pernilla Näsfors is currently working as the Development Data Specialist at the World Bank, where she is leading a work program that is opening up developmental aid data to disrupt the whole fundraising environment. By allowing countries to publish what donations they receive, the World Bank’s Development Aid Data program is bringing more accountability to a once-convoluted and confusing system. Top donors are already using World Bank Development Data APIs to power the visualizations on their home pages, which in turn are igniting a new wave of policy discussions on best practices in aid funding. In Copenhagen, Innovation Specialist with the Danish Digitization Agency, Cathrine Lippert, described some of the challenges that occur internally for bureaucrats committed to opening up public data. In Oslo, Kristin Lyng from MET Norway shared some similar experiences. One of the biggest challenges for government stakeholders is that with the opening of data comes a new wave of criticism. This can make some of the more reluctant government officials defensive, and even more reluctant to continue on the open data journey. Lyng’s response is to argue that often, these criticisms are justified and actually end up creating a better data supply if heard as a part of a dialogue with end users. Meanwhile, to demonstrate the value of open data to her peers, Lippert needs more examples of how open data is being used. There was some discussion during breaks about how developers could use open data, but it is far from top-of-concern and many are unaware of the plethora of data supplies that are available that could be used to enhance business processes, monitor risks and new market opportunities, or be used as the raw fodder for building new data products and applications. (Perhaps today’s launch of the Open Data 500 will help turn the tide — full details on that story tomorrow — and a new stream of impact data has just been made available on data.gov that shares open data success stories across a range of industries.) However, there were a number of Nordic APIs participants that were open data savvy. Traverse is a startup using open data to create a public transport ticketing system. Beyond the usual travel planner applications, Traverse is going the next step by letting passengers book their tickets, and is creating a platform that allows public transport operators to more seamlessly provide the ticketing service within their own apps and portals. Meanwhile, Energimolent is making use of energy utility data to provide energy-data-as-a-service to power a new wave of business startups and B2B products built using the data funneled via APIs that Energimolent has opened up.
4. Uniform APIs and Standards Start With Specs
A central theme from many of the speakers was the need for more uniformity and use of standards in API design. Good luck with that. Sumit Sharma from MuleSoft argued that APIs are actually just the latest in a B2B trend that is about enhancing human relationships between business peers. As APIs become a key tool to enable businesses to communicate and share information effectively across their boundaries, it will be API service descriptions that will allow the humans managing the interactions to better understand each other and what is possible via API capabilities. While not there yet, he sees a time when API service descriptions will be written in plain-speak that can be used by non-developers to understand what data and functionalities an API is enabling. Ideally, Sharma would like to see a catalog of standard service descriptions that could be applied to each industry vertical, like a set of whiteboarded process maps that describe each common workflow in the relevant industry vertical, and enable faster time-to-market creation of integration solutions.
5. The Rest of the Iceberg Floats Up
Keeping with the theme of the event series, Private, Partner and Public APIs, Andreas Krohn from Dopter AB gave an overview on controlling the level of openness of an API and, along with many of the speakers, urged API developer-providers to build their APIs with a long-term view that they may become more public-facing, even if they start life solely for internal use. This matched the interest level of many of the participants that I spoke to: the majority were attending to learn more about building secure, usable internal and partner APIs, while also wanting to keep the door open to the idea of moving to an open API offering somewhere down the track. API Management Providers like SOA Software are already seeing this play out in the enterprise, where companies with internal APIs are wanting to fast-track opening them up to partners, while Steve Willmott from 3scale spoke this week in Korea about the organization API cycle which starts with making raw data accessible via APIs internally, then becoming available for customer re-use and distribution in partner ecosystems before blossoming into the 1,000 flowers of an open API market.
6. The Business Case of APIs Still Struggles, but Shows Signs of Improvement
In the fast growing API economy, there are plenty of contradictions. And while on the one hand, API maturity is growing fast with previously private APIs being opened up more publicly, other businesses, enterprises and institutions are still wanting to see more evidence of the benefits before committing resources. Anne-Sofie Nielsen from Kapow Software showed how at times, those who would benefit from API access may not be the ones creating the API, leading to the need for Kapow’s web-scraping services that allow enterprises to automate aspects of their data flow by turning data sources into APIs. Nielsen argued that “has an API” should be listed on any IT Manager’s checklist when reviewing new software (and increasingly hardware) for possible purchase. Participants also asked speakers for advice on how they can encourage their business colleagues to invest in APIs. Others shared that there may be agreement to open up data assets via API, but without any real business model discussed, leaving developers bewildered as to how they are supposed to progress with an API strategy. meanwhile, some smaller developer outfits were attending who had placed their API goals further down the track, unable to commit the necessary resources for now, but interested in keeping up with the current industry conversations. Even Government departments need to be swayed: Lippert is, as yet, unable to convince her decision-makers to invest in the open source platform CKAN (which includes the CKAN API) as a way to manage the data she is encouraging agencies to open up.
7. From Dog-Food to Donuts: You Are What You Eat
Without doubt, participants left each event with a clear appreciation of the need to consume their own API if it was ever going to be successful in a wider ecosystem. “If your API isn’t good enough to use even as a widget on your website, you need to rethink it,” shared Krohn. “If you are still doing SQL queries down into your database instead of using your API, you need to rethink your public API.” Marjukka Niinioja from project management software company PlanMill described how the turning point at their business was when they began dog-fooding their API in earnest. Faced with a new customer integration requirement to connect website forms with their CRM. PlanMill’s in-house developer suggested using their API as a way to implement the customer project. “I never want to see dog food again”, Niinioja quipped, after her team discovered what it was really like to be using their own API to create new app solutions. Now, however, the learning process has paid off, with Niinioja comparing a later customer project to eating donuts, now that the in-house team had ironed out all of the documentation needs, error messaging and capabilities of their open API. Dog-fooding is an approach that Ronnie Mitra from Layer 7 suggests is easiest to digest when starting with internal APIs. He highlighted seminal papers in usability design, including research that demonstrates that when a company invests in the design of its intranet, productivity can increase at a rate eight times greater than the design costs. The same applies for API usability, as often internal APIs are poorly documented and assume an expert level of knowledge amongst developer-consumers. By taking an open API documentation approach to internal APIs (clear documentation and error messaging, giving example uses, showing what data is returned and even including video tutorials and the like), internal uptake is likely to be much higher and the benefits from integrating processes and data flow with APIs can be realized. These gains can extend even further when the API is opened up to partners or third-party developers.
APIs Go Global and Local
As the Nordic APIs team has demonstrated, business regions around the world are eager to host APIs discussions for local providers and consumers. While Nordic APIs was being held across the Scandinavian countries, a Dublin API meetup was being hosted in Ireland: “Like most other API meetups, developers come to API Dublin from a variety of backgrounds: from folks who work at local API companies (intercom.io, AYLIEN, evercam.io) to individual developers looking for cool APIs/hacks to general API enthusiasts,” shared Parsa Ghaffari, one of the organizers of the event, which included talks about the OpenStreet Map API, AYLIEN Text Analysis API, and the Vimeo API. Meanwhile, API Days is planning its next two regional conferences in Berlin and the Mediterranean (Barcelona) and Nordic APIs promises to host another event in October. We at ProgrammableWeb will be hosting an API conference on 27-29 May in San Francisco, and API Strategy and Practice is set to hold their next event on 24-26 September in Chicago. By Mark Boyd. Mark is a freelance writer focusing on how we use technology to connect and interact. He writes regularly about API business models, open data, smart cities, Quantified Self and e-commerce. He can be contacted via email, on Twitter, or on Google+.