In a globally distributed application architecture environment, it would be easy to assume that technology trends span across geographic borders. In many cases, that is true but as research by Lawrence Hecht for InApps Technology has shown, there are also regional influences that shape uptake of new technologies and create local communities of knowledge and experience.
Australia — perhaps more than other regions of the world — has a particular need for taking up APIs. With its geographic distance and time difference with the rest of the world, APIs could provide a 24/7 business mechanism that allows global customers and partners to self-serve access to services and assets from Australian-based businesses. APIs have helped IPO’d-tech giants like Atlassian and strong, smaller players like Envato to become global businesses regardless of their location headquarters. Australian industry could adopt a similar digital leadership approach as some of the Nordic countries which have leveraged APIs to compete as global businesses, offering their services and opening their business assets to the U.S., Europe and emerging markets.
Australia faces some local characteristics across the API landscape that risk slowing down industry uptake. The recent APIdays Australia demonstrated that it is a complicated market, with some signs of digital leadership on one hand, and some willful lagging on the other. This year could be a defining moment in demonstrating whether Australia will help drive tech innovation, or be content to amble along behind international pioneers.
At APIdays Australia earlier this month, local businesses, government agencies and enterprise shared their roadmaps and experiences in building and implementing API strategies across local industry. Those who have been managing APIs so far showed the same level of international expertise and insight as at any other APIdays event — which is now held in eight cities around the world — and the audience was dynamic and keenly interested, with about a third of the 400-strong audience indicating they currently have private APIs, and about a quarter working on public-facing APIs but all the same, I still had the feeling that the benefits of APIs should be reaching a larger audience in Australia.
Part of the reason is cloud availability for local business adoption is still in its nascent stage and this is reflected in the level of growth expected in cloud computing amongst enterprise. A study last year by local industry researchers Telsyte found that the total market value of public cloud infrastructure services would reach $775 million by 2019, while the current spend is about half of that, $366 million. The study notes that about half of all organizations with more than 20 employees are using public cloud services for some part of their infrastructure, but $366 million for all businesses across the country seems a pretty low spend for a market that produces goods and services valued at 1.6 trillion Australian dollars, according to Industry Australia.
Perhaps the lack of local cloud server infrastructure is limiting uptake of API innovation amongst industry: Amazon has had EC2 availability in Sydney since 2012, but Amazon API Gateway, Lambda and Amazon’s IoT cloud service infrastructure are not offered locally. Google Cloud Platform’s closest Compute Engine servers are based in Taiwan. While Telsyte’s study found two-thirds of businesses surveyed are already using international cloud services, 54 percent of CIOs are either subject to restrictions on using offshore cloud services or don’t know if they are permitted to use them. That means half of Australian businesses will be reluctant to move much of their work into cloud infrastructure until the local options are more robust.
At APIdays Australia, this issue came up in several discussions, with enterprise and government presenters being asked from the audience how they are managing their data in the cloud, and whether they are keeping the data that sits behind their APIs in locally-based cloud servers. Government innovators, for example, must find local cloud server options before implementing API-enabled projects.
Overall, APIdays showed that there were some unique differences that face the local API scene and some similarities with other world regions. Uniquely, Australia seems to be having a more acute conversation on how to frame APIs as a business value. But much like the rest of the world, Australian businesses are trying to balance internal and public API priorities — which in turn is challenging businesses to really consider what the platform business model will mean for them — while also experimenting with the next horizon of technologies like blockchain.
Australian-Specific Conversations
Agile design processes and the new paradigm of global application development architecture lend themselves best towards a Spotify-type pod organizational structure where work teams are made up of staff from business, design and engineering. That sort of approach is still novel even globally but creates a need to express the benefits of APIs within the business, a point that seemed to particularly resonate with Australian speakers at APIdays. Opening keynote Steve Sammartino, whose book The Great Fragmentation: And Why the Future of Business is Small surveys the way lean startup and agile processes are disrupting business practices, spoke more to the heart of what APIs are enabling and how he expects that this will lead to a ‘horizontalization of industry’ where APIs and the Internet of Things will mean that, in the future, industries like plumbing will be intrinsically linked to healthcare, and so on.
This was backed up by James Bligh, senior manager of commercial feasibility at the National Australia Bank who framed the API advantage within the banks as not being about an “API strategy”, but about being “a customer strategy”, where APIS are the most convenient and effective way to reorient the bank’s services towards digital accessibility for customers, where and when they want.
Lindsay Holmwood from the Australian federal government’s much-vaunted Digital Transformation Office (the whole team moved to be directly under the new Prime Minister when he assumed the mantle in September last year), spoke about the Government’s API-enabling approach, who again avoided talking directly in terms of APIs and instead focused on the three Ts: Transitions, Transactions and Transformation. Holmwood described key life transitions like having a baby, opening a business, where currently there are numerous forms and government agencies involved across Federal, State and local levels.
Like API innovation labs within the U.S. Government (notably 18F) and in the UK, Australia has adopted the Cloud Foundry Platform as a Service as their core tool for building a new wave of digital workflows and products: parents could have all their paperwork transacted directly for them, given that a baby’s birth details are recorded by doctors at a hospital in the first place. Where a transaction is necessary, Holmwood envisions Government websites that work as single page apps to simplify and enable (transform) digital engagement around key aspects of citizenship.
What was interesting about how these speakers framed their talks was probably best summed up by research from Andrew Cutler from SoftwareAG. He had conducted a survey with 65 of his senior business contacts across a range of sectors and found that while 40 percent of them had heard of APIs, the majority saw the main IT obstacle facing their company was the ability to leverage integration. (He also found that in more traditional enterprises, few business leads had heard of the role of API evangelist or were even aware their own company had one, suggesting that this role has been perhaps overly focused on facing outwards to third party communities.) The subtext of Cutler’s presentation (and of Sammartino, Bligh and Holmwood) was that the API conversation needs to happen internally in new ways that put aside the term API and instead talk about the benefits to businesses. You would think ‘digital transformation’ was one way of doing that, but in my discussions with business participants at events like APIdays, there is already a feeling that this has become a meaningless buzzword, and in a culture like Australia’s that is highly cynical of ‘weasel words’, a new way of describing the value of APIs to a business needs to be found.
Common International Conversations around APIs
Two themes that were repeated by several speakers at APIdays Australia echoed conversations that are also being held around the world.
The first was a dominating discussion around platforms, which is probably no surprise given the conference theme was “Platforms for Innovation.” Ever since Tom Goodwin’s meme about Uber having no cars and Airbnb having no actual building assets, startups, entrepreneurs and enterprise have been curious about how to leverage a platform manifesto.
Steven Willmott, CEO of 3scale, gave a keynote that walked through both the vision and the practicalities of reorienting a business model to a platform perspective. One of his main take-homes was that platforms are hard work. But it is not work that can be avoided. So best you learn how to leverage APIs to enable your customers and partners to become your co-creators.
Mirroring some of the local discussions aimed at framing APIs for business, Willmott urged: “The API is not the key thing, the value is the key thing. To create a successful platform, you need to focus on how to get the business value to more people, and use the API as the channel for that.”
The second theme matching the international landscape was evident in discussions around emerging tech and how to seize opportunities. One of the best examples of this Liming Zhu’s overview of new use cases emerging for blockchain technologies. Working at the ideas lab Data 61, a part of Australia’s key science organization CSIRO, Zhu outlined some possible new use cases for blockchain technologies beyond bitcoin, showing that blockchain could solve some of the problems inherent in trusting third parties in a platform economy, by enabling smart contract negotiations, managing open data registries, and coordinating business processes. Zhu noted that, like in other regions of the world experimenting with blockchain tech (beyond bitcoin), Ethereum is emerging as a common DevOps framework for building prototype applications.
The Expected, the Disappointing and the Surprising
Adeel Ali from SDK automatic tool generator service APIMATIC shared his Ph.D. findings from a study of over 11,500 APIs. He grouped his findings into the expected (that API versioning is creating problems for a third of all API providers), the disappointing (that the majority of APIs don’t bother including metadata that can help API consumers) and the surprising (that 25 percent of PUT/POST and 68 percent of PATCH endpoints violate what is currently considered industry best practice).
Mirroring this categorization, APIdays had many of the expected suspects presenting, with key discussions on developer experience, building hypermedia APIs, open data opportunities and API management. Most disappointing was to see that this conference could have been bigger — Australian businesses could be a leading international base for API strategy and best practices, but there wasn’t really any sign that Australian businesses and government in the main even realize that opportunity is there yet. And perhaps most surprising was to see some innovation coming from the Federal Government, and to hear the earnest grappling that many speakers and audience members shared around how best to frame the API advantage in their industry.
With eight city events around the world each year, APIdays is uniquely placed to surface some of the regional differences in how new technologies are being taken up. In May, APIdays Mediterranea will focus on machine learning APIs while a new APIdays event in Tampere, Finland on 18 and 19 May will focus on the rise of API Ops (DevOps for APIs), the use of APIs in heavy industry and the way APIs are helping governments create platforms.
Feature image: “Melbourne, Australia by night” by Hai Linh Truong. (Licensed under CC BY 2.0.) Embedded images by the author.
