One year into his role as an application programming interface (API) evangelist for Australia's biggest telco, Frank Arrigo is hoping for a "Bezos moment" that catapults APIs into the fabric of Telstra's being.

The reference is to a piece of IT folklore - a mandate said to have been issued by Amazon founder Jeff Bezos around 2002 that led to the company's transformation from book seller to cloud provider - and beyond.

As folklore has it, Bezos mandated the use of service interfaces - effectively internal APIs - and is said to have famously signed off the mandate with words to the effect of, "Anyone who doesn't do this will be fired. Thank you, and have a nice day."

While Arrigo isn't expecting a similarly-worded missive from Telstra CEO David Thodey, he does hope to eventually see some sort of top-down mandate on API use.

"I don't think I'll see a moment exactly like that happening in Telstra, but I'd like to see a variation where we get this driven across the organisation," he told the recent APIdays conference in Sydney.

"We've got executive sponsorship and part of what we're doing is continually updating our executives on what we've done and what the plan is to take it forward."

Back to the beginning

Telstra's API journey began with internal research that pointed to the need for an API strategy.

One of the recommendations was for the formation of a "dedicated API team", rather than simply adding API responsibilities to an existing team's responsibility.

"The research found organisations that had success with APIs had a dedicated team that looked at what APIs were about and helped drive that change," Arrigo said.

A dedicated team was established in Telstra's Software Group (TSG). One of Telstra's hires was Arrigo - a Microsoft evangelist well-known in developer circles.

About a year ago, TSG president Charlotte Yarkoni laid out a vision for Telstra's API adoption at a conference in San Francisco. The focus of the talk was around APIs as a "lego block world of opportunities".

"APIs are the connectors," Arrigo said. "They're the things that connect different services and applications.

"They're 'lego block' opportunities. By having them, you can compose or create something that you hadn't planned on before, unlocking the value that sits inside your organisation."

Yarkoni's talk set a key reference point for Telstra's API journey. One year on, and with one public API and several internal APIs now published, it's a reference point to which Arrigo constantly refers as he seeks to execute on Telstra's vision.

TaaP - Telstra-as-a-platform

With a team in place and vision set, the telco embarked on what Arrigo calls "strategy" works.

"We needed to come up with a language and a way to describe what we were doing that made sense to the different business groups, shareholders and the multitude of people we were going to engage with inside and outside of Telstra," Arrigo said.

The team set about formalising its mission, vision and values.

"The vision was very simple - Telstra as a software platform," he said.

"Everyone is doing things as-a-platform so why can't Telstra be the platform? The mission is about connecting developers to and through Telstra - making it easy for developers to use these services, wherever they are."

Formal values would also help the team communicate its aims via a common taxonomy.

One of the values was to institute an API "culture". "It's about APIs being front and foremost with everything that's being done in product development," Arrigo said. "They're not a side issue or an add-on later - they're core." Other values included using APIs to stir innovation and gather feedback.

Next, the team created an "API version" of a business model canvas - a way of documenting the new business model being proposed.

"I made sure I had the book of the business model canvas so whenever I had meetings with people that didn't know about it, I could say, 'Here's the book. You can read about it'," Arrigo said.

The canvas provided a shared language that the API team could use to explain its vision and strategy to the various stakeholders with which it worked.

In particular, the canvas enabled TSG to explain the different types of APIs and ways they could add value.

"There's an API that extends the existing capabilities of a product, there's an API that is the product - the only way you can get to it is through the API. There's also an API to promote or drive more usage of a product, and an API that's a feature of a product," Arrigo explained.

"The canvas allowed us to have a structured way of defining and explaining these things and have an artefact as a result that people understood and agreed."

Tackling the ark

With the strategy work complete, the API team shifted into an execution phase. It started looking at enabling technologies, and effectively found a Noah's Ark of systems.

"Telstra basically has one of everything," Arrigo said. "Any API gateway that's in the marketplace you could probably find it in a group of Telstra, a point solution solving a particular problem. But it didn't accrue to a greater strategy."

The team took a step back and engaged Telstra's architecture organisation and business groups in a bid to agree on a common technology platform.

Once solved, Telstra was able to create and "onboard" its first APIs. One is public - an SMS API, which is now in beta preview. There are several other internal APIs that are live to Telstra developers, and it is hoped other APIs will follow that are aimed at developers at Telstra's partners.

Driving change

The first year has not been without its hiccups - and Arrigo is candid when it comes to the challenges of driving an 'API first' culture through a company as big as Telstra.

One challenge is in driving a change program horizontally across a vertically-aligned organisation.

"It's about working through the different business groups and getting agreement through them," he said.

Another challenge has been getting Telstra's people to understand APIs, such as the security or privacy implications of providing granular access to data via APIs.

Arrigo notes there is no "playbook" that the team can fall back on when establishing the API first culture.

"The first time you do this, you're going to learn, you're going to make some mistakes, and you're going to build into place the processes and procedures to manage that," he said.

"There isn't a playbook that already exists in the organisation around this, so it's about working through the different organisations - the internal organisation, or the organisation responsible for putting the APIs on the system - to make sure we're all on the same page, and we're ready to get moving forward."