Developer teams from across Finland arrived — often with a colleague or two from their business development unit — to Helsinki’s Skandic Park Hotel on Wednesday for the latest in the Nordic APIs “Private, Public and Partner APIs” event series.

“We‘re just starting with APIs,” said Anssi, who works in business development with a manufacturing team. He was attending with two of his developers and had traveled by train for 2 hours from other regions of Finland, showing once again how the event series is truly striving to bring together the entire region and make it more programmable. Anssi’s interest was in hearing more about how he could use partner APIs to help drive automated business processes in relationships with suppliers and manufacturing partners.

The development and business team from Transfluent were also using partner APIs, and were attending in order to connect with other API developers and to hear the latest in best API design and management practices. When it comes to APIs, their team members had a mix of skill levels. They appreciated the opening sessions which helped everyone get on the same page. “Normally, presentations assume that you should know this stuff,” said one of the team. “But the opening sessions brought everyone along to the same understanding.” They were excited to see an agenda focused solely on APIs: “It is fairly new and fairly rare to talk about APIs,” they said.

The approach of Nordic APIs was to begin with an introductory overview, and a presentation by co-organiser and founder of Dopter AB, Andreas Krohn discussing the differences between private, partner and public APIs. Andreas defined a common understanding for the day of the three types of APIs and gave practical examples of how they are used. He then walked through the return on investment from using APIs, and suggested that partner APIs may have the greatest business impact for those just starting their API journey.

Usability of APIs

By the time of the coffee break, even those participants who were deeply involved in their business’ API strategies were hearing a lot of new ideas: “Most of the presentations were new,” said one attendee. “How to improve the usability of APIs was new to me: the idea of showing examples of how the API should work, that was useful.”

The talk from Ronnie Mitra of Layer 7 gave many developers a new way to look at usability. While the theme of the conference has been private, partner, and public APIs, Ronnie shared the perspective that in fact, this categorization really refers to how much control API providers are giving to their API. So a private API is one that is tightly controlled, allowing access only to internal users, while a partner API seeks to control the B2B relationships that a business maintains.

Thinking about APIs in this way can help raise the priority of API usability. Often, private APIs are relegated to a poor user experience, much like how a company’s intranet is much less fun and friendly to use than their public-facing website. Yet Ronnie showed research data that suggests that when a company invests in making its intranet usable, productivity increases 8 times more than the design costs, and this multiples even more for larger companies.

The same productivity benefits can therefore be generated by usable private APIs. Ronnie says this means that businesses should focus just as much on documentation and helping new users to make the most of the API as they would for a public API. Most internal APIs assume that users are somehow already proficient in using the API, but businesses need to provide examples of how code snippets look for each API request function, SDKs where possible, user documentation and detailed error messaging.

Raising an API… accidentally

Marjukka Niinioja from project management software company PlanMill continued the discussion on usability of an API internally (see her Slideshare here). PlanMill have an open API, but in reality it is mostly used with partners. When the business first decided to introduce an API in 2009, she was unsure of the benefits and reluctant to invest so much time and resources into something that would need to be maintained in the future.

The first 12 months of using the API was a period of uncertainty for PlanMill. Consultants were unsure how to sell the API features to partners and customers, and usability support — like testing environments, API key registrations and documentation — were being created incrementally. First use cases centred around drawing out project and time reporting data, but the first real application was when PlanMill were working with a customer to integrate their website forms with their PlanMill CRM component. An internal developer at PlanMill saw this as an opportunity to dog food their API.

Using the API themselves gave the PlanMill team a deep insight into the potential and power — as well as drawbacks and challenges — of their API. “I never want to see dog food again,” Marjukka quipped, saying that the learning curve was worth it, as in future use cases they were able to “swap from dog food to donuts” in terms of how appealing using their API became!

The API has led to deep-rooted changes in the organization. Sales consultants will ask customers and partners for details of how they are making API request calls rather than asking for screenshots of what is happening.

To encourage internal and partner API usage, Marjukka now focuses on several mantras when talking with her colleagues to evangelize use of the API across the business:

• “Who has some great examples of using the API?”
• “Have you tested that with the API?”
• “Have you added that to the API documentation”
• “You can do this quicker and cheaper using our API”

Brief Mentions…

• Marjukka Niinioja from PlanMill started her presentation with a step back in time, reminding the audience that before APIs, the”hip cool thing in integration was MS Excel Web Query”
• E-commerce team Solving Maze summed up what they had been learning as “Having an API is like having a baby. Funny, truthful and painful experience!”
• With OAuth being a part of the neo-security fabric, commentators wondered aloud on Twitter if a clearer name would have helped: “I guess ODelegatedAccess would not have been such a catchy name,” pondered Mark O’Neill from Axway.

The Nordic APIs event series finishes today in Oslo. Summaries of each speaker’s presentation and links to videos and slides will be posted to this blog.