My Key Takeaways from APIdays Australia 2016

Posted on by
Share Button

On March 1 & 2, 2016, I attended APIdays Australia in Melbourne. (Actually, I also spoke! I’ll write more about that later.) I’m a chronic note-taker at conferences and I like writing my notes up afterwards both for my own reflection and so I can share them with others. Here are the key platform and API takeaways I’ve pulled out of my notes from #APIdaysAU16.

Innovation

APIdays Australia 2016 welcome poster: "API days - Platforms for Innovation"Innovation has been established as the main driver of economic change.

If people have to fill out an application to innovate, it’s not going to happen.

An innovation model for organisations based on the way ants achieve the colony’s goals:

  1. Powerful central mission with loose structure
  2. Maximise learning and sharing of learning
  3. Constant experimentation
  4. Freedom to look for the next horizon

Elon Musk: “Failure must be an option. If you’re not failing, you’re not experimenting enough.”

People in your organisation who think differently to others may well be key innovators. Don’t shut them out of the organisation.

Building Platforms

“Platform” is chiefly an idea to expose the core of your business in a way that can be used to compose new business ideas more easily, either by your own business or by others.

For some companies, building a platform is now the main product effort. These companies are not concentrated just on “API first”, but on “ecosystem first”.

A key task of many ecosystems involving third parties is figuring out how to share the revenue generated.

Tesla Motors, by open-sourcing their patents, has shown that if you’re far enough ahead of others on the curve, you can open up your technology in a way that turns your competitors into your customers. Others can now build electric cars. Tesla will be happy to sell them batteries.

There is a trend towards building platforms on top of “zero”: Wikipedia employees zero academics, Uber owns zero cars, AirBnB owns zero rooms. This type of ecosystem is supported by “prosumers” – consumers who are also producers of content.

Platforms can be built that remove whole classes of problems for many people in the business, allowing them to focus on the real work of solving business problems.

If you build the right public platform, you can ship unfinished products to customers and allow others to put the pieces together in whatever way they want.

James Bligh from NAB said he isn’t too concerned about competition from other banks, but loses sleep about Fintech challengers.

APIs over core systems are one of the best ways for large companies to increase their ability to adjust quickly to changing customer needs.

NAB’s API team has a rule that anything they produce must be awesome, not just “good enough”.

Figure out what the business value is of the API and focus on that. It may not be direct revenue, but may drive usage, attract partners or increase stickiness.

Measure success using real metrics that matter to the business. Avoid vanity metrics like number of API keys requested.

Telstra has a vision to be a software platform rather than just a telco.

Don’t focus just on your own APIs, but think about how you can leverage APIs that others are exposing.

Collect metrics and know who’s using your APIs and why. API usage can be a great source of ideas for your product.

Designing & Marketing APIs

There’s a real need to focus on the value that an API is providing to it users, and to let that value drive the development and evolution of the API.

APIs need to be a first class product. Achieve this by telling stories about the API: what could a customer or partner achieve if we build this API?

Know your customers. The people who want to integrate with your system may not be developers, but could be marketing folk or analysts.

Some key guiding principles for good APIs:
– Developer experience first
– Don’t surprise users
– Experience is more important than ideals (e.g. REST isn’t always best)
– Deliberately design the API
– Provide options in the API, e.g. for how much data is retrieved

Schema modelling is a tool used to design APIs. See RAML, OpenAPI (formerly Swagger), and API Blueprint.

Don’t invent your own standards for APIs. There’s already stacks of momentum around existing standards and they work.

Developers will expect consistent APIs. You need to set up a standard to achieve that.

Don’t leak info (especially about errors) from downstream systems. Create “clean” APIs.

There’s little point in building your own public API infrastructure nowadays. There are so many vendors in this space; just use the best tools available.

Think about the frequency at which data can be provided (monthly, daily, hourly, real-time) and the difference that can make in the kinds of problems that can be solved.

When marketing your API, show code. Your market is developers.

Documentation should not simply be an API reference. You need tutorials, recipes, FAQs.

Provide support and make it clear to users what the channels are and the associated SLAs. Consider creating a forum to allow for community support stored for posterity.

There are three big issues with using REST for everything: continuous polling, data redundancy, and coupling. Some of the solutions include using a message broker, HTTP 304, and JSON patch. There’s no “one is fits all” architecture choice.

Telstra used presenting at APIdays 2015 as a marketing opportunity for its APIs, but also to build awareness within Telstra itself of what the API team is doing.

There’s no such thing as a private API. You need to accept that and be able to cope with people playing with your APIs, even if you don’t intend them to.

Innovation in Government

The national innovation agenda shouldn’t just be about businesses and startups, but also about innovating in government.

In the business of social change, human lives are at risk.

Major beneficial social change is unlikely to be brought about by government or NGOs, but by innovators and communities. The government should figure out how to work with those groups to enable and direct change.

People tend to deal with government a lot during periods of life transition, and usually have multiple transactions during those periods. The lack of integration between those transactions can be a huge annoyance for users.

Government departments tend to ask, “How do we digitise this form?”, but should be asking, “How do we collect less data?”

The Digital Transformation Office is building a technology platform to support fast innovation within government, as well as assisting service delivery teams in building simpler, integrated services that focus on customers.

Some Of My Tweets From the Conference

Some further API-related reading you might be interested in

“The New Kingmakers” (via Frank Arrigo)

JSON Patch (via Ross Garrett)

Deborah Gordon TED talks on colony intelligence of ants (via Mike Amundsen)

“Irresistible APIs: Designing web APIs that developers will love” (by Kirsten Hunter)

Upcoming O’Reilly book “Microservice Architecture” by Mike Amundsen et al.

Kudos

All the wisdom above is gleaned from talks I attended by Brett Adam, Mike Amundsen, Frank Arrigo, James Bligh, Andre Charoo, Andrew Cutler, Anne-Marie Elias, Ross Garrett, Lindsay Holmwood, Kirsten Hunter, Tim Liddlelow, Steve Sammartino, Steven Willmott. My apologies to all the other great speakers who I didn’t get to see. I’m look forward to catching up on InfoQ!
Share Button

One thought on “My Key Takeaways from APIdays Australia 2016”

  1. Great article. There is still so many companies stuck in hold ways of working. Driving long projects without any MVP thinking. APIs are a good way to open up and let the market drive the creation of products.

    Reply ↓

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.