VIEW SLIDES	SESSIONS	SLACK INVITE	PHOTOS

This week Nordic APIs hosted the Platform Summit, our largest conference to date. 400+ attendees and 60+ speakers arrived to a sold out event, jam-packed with the industry’s leading experts on web APIs. Our attendees represented 26 different countries, making this our most most global event ever.

With tremendous growth slated for the API economy, we encouraged our speakers to emphasize scalability in their presentations and Q&A sessions. Uniting business and technical aspects of supporting a thriving API program, our speakers covered many lessons on how to foster a scalable API platform.

Overarching theme: Scalability

In this article, we’ll outline the best knowledge imparted at the conference. We’ll cover the most pressing advice transmitted on things like new API architectures, realtime APIs, microservices design, GraphQL, open standards, and how all industries have now become API-fied. Stay tuned for in-depth reviews and featured contributors, but for now, here are the highlights!

Open Banking: The Wave Has Come, But The Tide Needs Gravity

Wow, this year really saw the advent of PSD2 in action. If you weren’t aware, EU member banks will soon be under regulatory pressure to open user data with APIs. Last year, stones were thrown into the proverbial world financial pool, and this year we saw the ripples turn to actual waves. As Gunnar Berger of Nordea told the API community:

“You changed something big” -Gunnar Berger, Nordea

Berger discussed the excitement in FinTech over Nordea’s first foray into the open API world. Eyal Sivan from CIBC also praised new microservices architectures for improving agility, Flavia Sequeira of ING embraced the API-thinker mindset pivotal to what the modern banker has become, and Mats Iremark of collector bank described their cloud-first architecture.

“A non-public API is just a future public API” –Patrice Krakow, ING Direct

It’s great that EU banks are adopting more open modes of behaving, and that even international banks want to play in the API economy sandbox. It’s a ‘paradigm shift,’ and I don’t use the phrase lightly. What banks must understand, however, is that simply opening an API and saying “run with it” is not enough. The banks that continue to stay competitive will not simply be proactive in responding to regulatory compliance; they will also have the best developer experience paired with the most streamlined architectures.

GraphQL Is a Go, But Adopt Carefully and Consider Tooling

Among the competing API design standards (SOAP, JSONAPI.org, Hydra, gRPC, etc.), GraphQL has dominated the discussion as a production-ready alternative. The attention given to GraphQL at our events continues to validate the approach as a firm method.

According to Nordic APIs veteran Chris Wood, enlightened enterprises will seriously consider using GraphQL as their weapon of choice. He praises certain characteristics, like product-centric, the combining of multiple specific queries, a strong type system, and support for introspection as reasons for adoption.

GraphQL: “the right weapon to do battle with” @SensibleWood @nordicapis #CallOfDuty pic.twitter.com/fh1D5tBVW7

— Bill Doerrfeld ⚙ (@DoerrfeldBill) October 10, 2017

In his talk GraphQL APIs: REST in Peace, Tomer Elmalem of Yelp endorsed GraphQL for increasing efficiency, since developer consumers do not want to program multiple requests into their clients. He mentioned that Python programmers will like Graphene, a Python library for GraphQL.

With the rise of new user expectations, some feel that REST doesn’t meet the nuanced demands of things like realtime data sharing, new delivery channels, gaming, and IoT protocols. In a brief interview, Ole Lensmar of Smartbear echoed REST in Peace, mentioning that:

“It looks like we’re taking a step back with REST. REST has been great for the API bandwagon — now, people are making a leap of faith to new technologies and protocols to meet more nuanced demands.” -Ole Lensmar, Smartbear

While interest in REST wanes, we should keep in mind that GraphQL as a REST alternative isn’t a silver bullet. For example, it doesn’t specify an authentication or authorization schematic. As its own specification decrees, what the GraphQL space requires is additional GraphQL tooling to make it a viable and extensible approach.

Ivan Goncharov of APIs.guru reiterated this point in his talk GraphQL: The Next Level of API Tooling. Nikolas Burk also described how the GraphQL schema can pair nicely with a a serverless backend-as-a-framework like Graphcool. Chris Wood, representing Arvata, reminds enterprises to assess discoverability, security, and analytics before diving into GraphQL usage.

Architectural Innovation Mimics Biological Evolution

From “big box” EAI, to SOA, to ESB, now to API-driven microservices. B2B communication architecture has come a long way, but businesses still must build for change to face the natural ‘evolution‘ and ‘decomposition‘ of service architectures. It’s interesting to note that our vocabulary of late is drawing inspiration from the realm of biology.

“The world of biology is coming into contact with IT” -Eyal Sivan, CIBC

‘Ecosytem’ is another termed linked to biology, and nowhere is ecosystem more alive than in the API economy. Zdenek “Z” Nemec, consultant at goodapi.co, presented an impressive stack of third party tooling implemented in his time with Adidas; Apiary for documentation, Dredd for validation, Runscope for testing, Jenkins for automation, and other tools for automated security checks and analytics. Not only is this stack helping Adidas reach an “automated, contract driven API lifecycle,” but it’s evidence of a vibrant API tooling ecosystem that has arisen to support API providers.

Serverless Microservices, And Scaling Beyond

We heard a couple presenters endorse OpenWhisk, the open source serverless cloud platform by IBM and Apache. To Ken Parmelee of IBM, OpenWhisk offers the sort of flexibility that is “hugely important for microservices,” allowing a team to orchestrate and scale rapidly. With microservices, it can be tricky learning how to orchestrate their inner-communication. Nikolas Burk recommended using PubSub as a means of getting them to talk.

On scalability, Adrian Hornsby of AWS described the cultural change required to meet new technological demands. To him, software is a reflection of how the entire organization is composed:

“Scaling touches a lot more than just architecture”
-Adrian Honrsby

You can’t automate the entire release process, but with the right combination of tooling you can increase efficiency and focus more time on your main value proposition. Adrian advises API providers to avoid re-inventing the wheel when it comes to things like security: “don’t pretend to be a security expert overnight.”

Identity Is At the Heart of API Security

When we discuss API security, there is a messy blend of confusion around open standards like OAuth, OpenID Connect, SAML, JOSE, and others. In fact, there are 50 API security specifications you need to be aware of (with documentation equating to 2,000 written pages). That’s why Travis Spencer of Curity aimed to turn this confusing API security “soup” into actionable, definable units. We’re finding more and more validation that API security is founded on quality identity management.

Open Standards Will Drive Business

Anders Eknert of Curity gave an in-depth review of SCIM, the open standard protocol for tracking user information that is seeing more and more adoption. With data privacy regulations like GDPR nearing compliance dates, a standardized method to synchronize private data with user information will become critical to IT.

Shelby Switzer of Healthify also described the importance of open standards as applied to the healthcare industry. Enterprise healthcare is slowly shedding the old custom integration mentality to embrace API-first best practices. Consolidating approaches around open standard technology and best practices is detrimental for increasing agility within clunky data service ecosystems like enterprise healthcare.

Thanks to open standards, raptors won’t eat these children. Credit: Anders Eknert

What Is Your “Single Source of Truth”?

Documentation-first is one way to have a contract-driven approach within an API company. This improves consistency and reliability throughout the platform. Advocating a documentation-first approach, Jason Harmon of Typeform recommends using a YAML-based OpenAPI Specification as a “single source of truth,” paired with a tool like ReDoc for quickly generating beautiful docs. Of course, curated guides or technical writing will still be manually crafted.

Jeremiah Lee of Spotify described the technology used at Fitbit. He described how using JSONAPI.org, a pragmatic specification for building APIs in JSON, can standardize how data is sent and retrieved between the client and server.

“Without clear guidance, data models get messy” -Jeremiah Lee

Also, going back to the GraphQL point, according to Jeremiah, “GraphQL might not be right for you.” As JSONAPI.org offers Compound Document Request, and increases an app’s “perceived speed,” he recommends the JSON API.org specification for API design over GraphQL.

.@JeremiahLee recommends https://t.co/36Ltonx6Q8 for #API design, offending both #hypermedia and #GraphQL folks 😜@nordicapis pic.twitter.com/YPJC5zUC12

— Bill Doerrfeld ⚙ (@DoerrfeldBill) October 10, 2017

For Adrian Hornsby of AWS, their team even writes a press release, documentation, and FAQ before actually building anything. Talk about a documentation-first mindset.

Tips On Structuring An API-First Company

apigee compass: A business litmus test for enterprise APIs.

Regarding the makeup of API-first organizations, Ronnie Mitra of API Academy communicated his theories on increasing autonomy in an IT organization, stressing to build a people platform in the same way we architect technology. His activity mapping techniques could be used to distribute talent effectively across a company.

On applying business savvy to an API program, Kevin Boumeester noted the varying strategies for public, internal, partner, and industry ecosystems, encouraging first-adopters to consider using the Apigee compass to gauge their digital score.

Konstantin Yakushev of Badoo emphasized the operational process of code iteration in a large, and at times bureaucratic company.

“How many developers does it take to change a lightbulb?”

Badoo’s answer is 24 developers per enormous lightbulb. Their “bureaucratic flow,” as Konstantin calls it, can surprisingly work pretty well, and just may be their secret recipe to win. They’ve found that having a review process in place while trusting server folks to make moves quickly is a good way to balance attention to detail and a “careless agile” mindset.

“Getting your API platform up and running is a balancing act” -Eyal Sivan

Technology is There. Now We Need Businesses To Talk

By now, most companies understand what an API-first strategy is, can see the benefit, and largely understand the technology needed to implement a developer program. Open software like OAS and GraphQL are evidence that a matured software ecosystem has formed.

Since technology now gives a solid baseline for API development, our current issues include preparing platform legalize, determining business strategy, and figuring out the perfect combination of tooling to get the job done. According to Bruno Pedro of Hitch (recently acqui-hired by New Relic):

“The technology has been developed – people know what an API is how how to build one. What companies are trying to work out now is how to piece it all together”-Bruno Pedro, New Relic

All Companies are Now API Companies

Our speakers represented a diverse range of traditionally non-technical industries; enterprise healthcare, medical IoT, manufacturing, dating services, banking, and others. It’s evident that companies within all industries, and traditionally non-technical ones, are quickly adopting APIs.

“This is how you package software these days” -Kevin Boumeester, Apigee

Adidas was an impressive example of this on a massive production scale. Their Speed Factory is creating fast, on-demand, and scalable manufacturing through the use of automated machinery, and the robotic assembly line is simply not feasible without efficient APIs.

“We don’t see ourselves as as sport company anymore, we see ourselves as a technology company” –  Oldrich Novak, Adidas

Though the Badoo dating service is not an API-as-a-product company, Konstantin Yakushev describes them as applying “API-centric development” to reach their unique user demands.

What Should We Test In Our APIs?

To garner insights from API usage metrics, Bruno Pedro of New Relic recommends using strategic perspectives like identity and consumer app ID to filter API usage into isolated views. This can offer new insights into specific usages. Ole Lensmar of Smartbear also described the benefits of API virtualization in API testing, essentially mimicking API behaviors in mock environments.

Patrick Poulin of API Fortress demonstrated how a lack of proper API testing (functional, uptime, regression, and integration testing) can result in a huge financial loss. Take Etsy, who he found were losing $75,000 day in revenue due to unavailable endpoints.

APIs That Listen To Developers Are Full-Spectrum APIs

One way to help the API platform is to improve developer experience. Considering API usability and discoverability are continually vital methods to offering dependable services that developers actually want to use.

Adam Duvander’s 8 traits of a Full Spectrum API.

A top aspect of this is creating a feedback loop. Richard Jones of Dun and Bradstreet said “it’s about getting feedback, and understanding what they’re doing.” This can not only improve DX, but have business implications too.

Nordic APIs all star speaker Adam Duvander of Zapier wrapped up the conference with perhaps the most colorful display of advice the API space has ever seen. A double rainbow API experience is more than sleek API references or complex functional offerings – it’s made of 8 traits.

“What your API does doesn’t have to be simple, but how developers get started does”-Adam Duvander, Zapier

Adam inspires us to all apply Kaizen, the Japanese philosophy of incremental improvement, to our businesses and API programs

Platform Summit 2017 Wrap Up

Thank you to our attendees, who engaged in quality discussion throughout the week! Also thank you to our speakers for their incredible presentations, as well as the insightful workshops presented by Apigee, Curity, and 46 elks. All speaker sessions will all soon be live on our YouTube channel here.

Thank you to all our of our sponsors: IBM, CA Technologies, TIBCO, Mulesoft, SmartBear, Jitterbit, Axway, Apigee, Arvata, Digia, APIMATIC, Typeform, C.A.G., and Teks Mobile. We simply can’t deliver events at this caliber without the support of organizations like these! If your company would ever like to sponsor Nordic APIs in the future, you can leave your information here.

We also had the support of media partners this year, which deserve special mentioning: Swedish FinTech Association, Open Bank Project, API Strategy & Practice, and Holland FinTech. They helped expand our reach to more people interested in APIs.

Lastly, our event was organized by the staff at Curity.io; they deserve a big hand for coordinating an event with many moving pieces.

What’s Next For Nordic APIs?

Since our last Summit, our community has increased by over two thousand followers and digest subscribers. However, we’re still learning a lot and growing into new roles. For one thing, we’ve learned that our Summit is now too large to patron the Globen hotel. For our next Summit, we intend on booking a larger capacity space!

Nordic APIs mission: Make the world programmable

At the event we also shared some announcements that we’d like to now share with our online community as well:

Consulting

Nordic APIs is now starting to offer consulting as a service to a limited number of clients. Our team and close network of API specialists are poised to offer strategic insights into API design, security, architecture, marketing, business, competitive analysis, and the other topics we routinely cover on the blog. For an example of our first project, see how we helped CIBC, a Canadian Bank, validate their microservices framework.

Webinars

In 2018 we’ll begin scheduling webinars to bring the same sort of conference knowledge to our online community. We are in the process of settling on themes and scheduling with partner companies. If you would like to participate in an upcoming webinar, or have suggestions please Contact us.

Join us on Slack

Join our new community of API practitioners on Slack! Here is an invite link to join the #general chat: Nordic APIs Community Slack. We hope this will extend conference discussion, and lead to new connections between our attendees, speakers, bloggers, and beyond!

Submit An Article

For those of you interested in writing – we’re very open to featuring vendor neutral thought leadership style posts on the blog, so let me know if you have any topic ideas. Please visit our Create With Us page for a list of style guidelines and our article submission form.