Ecosystem map (size reduced and sensitive data removed)
Telstra spent $230m acquiring 18 companies, operating 40+ digital health projects.
No interoperability strategy existed and different teams had overlapping technology demands. I needed to modularise and access our collective technology. The goal was to achieve an $1b ARR by 2020.
The API platform was born.
What is an API Platform?
A digital platform allows engineering teams gated public, partner and internal access to all of Telstra Health’s application data across the enterprise.
APIs allow you to piggyback and use another applications features and data. Essentially, you don't need to build that function yourself because who really wants to build another Google maps when you can just use their API.
What makes it unique?
An open-source, digital single source of truth for engineers; reducing overlap, encouraging new product innovation and fast-tracking current and future flagship project. Recreating how teams strategise, design, build, deploy and operate technology projects.
Role and responsibilities
Innovation/UX Lead. I was originally hired as the Innovation Manager/Champion and identified the interoperability issue. I approached the Executive Board requesting funding, built the team and lead the project though production and delivery.
Manage the product team
Post discovery, the solution period from concept mapping through to prototyping took ~6 months
$550k spend vs $1.6m budget. Product still in use at Telstra Health.
Build an internal API Platform for Telstra Health and our entities
After the problem had been identified and validated internally. I needed to determine the environment the solution would impact.
The API platform was built on top of the research performed across each Telstra projects and potential customer. Customer interviews, contextual interviews, secondary research; stakeholder and contextual mapping, ecosystem mapping, content audits, IA, sitemaps, tests, API status audits, and working prototypes.
Developers transcended each layer of the ecosystem, it was essential to we better understand their needs to build our solution.
With Developers being our primary users, it was essential we knew which functions/capabilities they were needed to integrate into their solutions and why it was important to have access to this technology?
As part of our MVP, I contacted multiple partners, universities and developer groups across Melbourne, conducting in-depth interviews and surveys with key stakeholders.
Budget constraints require that we focused only on high demand business cases. Review the draft of the developer survey, issued to multiple companies, universities and developer groups to gauge demand. See more
Survey results, along with effort/impact/confidence prioritisation dictated our focus. Based on 12 key portfolio areas we conducted a thorough analysis of the current state of APIs company wide and establish an accompanying financial model.
Health business intelligence
Health data analytics
Home and mobile monitoring
Health data repositories
Payment and billing
Health research data
To understand the ecosystem, existing legacy systems and current project requirements in details, we commenced a full inventory audit across T-Health and it’s entities.
SOAP/XML: 63% of APIs were in a built-for-purpose format. This would translate into a rebuild or discard. Standardising these APIs would come at cost to Telstra. Business cases would be required.
REST/JSON: 30% where in an easily accessible format. These APIs were commissioned to be placed inside the platform given the relevant business cases existed to justify costs.
OAUTH: REST based APIs segway into another critical project; Identification and Authorisation enabling us to leverage other resources to build a stronger business case.
Challenges: Reaching commitments with all key decision makers across Telstra and it’s subsidiaries took substantially longer than we anticipated.
What failed: We assumed that significantly more APIs would have been in REST versus a SOAP format. However, varied states existed complicating governance.
What worked: The content audit prompted a company wide discussion around how to standardise APIs and how entities would be subsidised to do so.
What happened next: Entities begin to review and formalise their APIs based on our standards and guidelines. However, a platform was needed to house the internal API environments.
With categories and requirements in user story format, I undertook open card sorting activities creating taxonomies than closed card sorts and tree tests with survey participants to gain granularity around the sitemap structure for the MVP platform.
Challenges: To avoid duplicating the Existing Telstra API platform the mandates was to build one from the ground up. This involved considerably more requirements gathering.
What failed: Early prototyped concepts, we assumed an eCommerce-like shopping cart would allow developers to access and compare multiple APIs at once. This concept failed.
What worked: Multiple rounds of testing with developers from the internal layer - primarily those within Telstra Health projects, DevOps and developers within our subsidiaries teams.
What happened next: Working to document our governance and legal layers in Confluence. Covering API strategy through to retirement of those APIs onboarded into the Platform.
Prototypes were produced, tested with end-users and stakeholders and signed-off with our partners and executive team.
Next, we contacting multiple partners, universities and developer groups across Melbourne and Sydney, we invited them to get involved.
We engaged over 40 engineers within our ecosystem who helped shape the solution.
A video was created to communicate how an API platform could enrich the Telstra Health ecosystem:
With our content using customer language, our architecture and prototypes validated, we required another round of funding from the executive team to build a production-ready version of our API platform.
Using Sketchapp UI and Marvelapp for Prototyping, I went with an on-brand and inviting visual design.
I had some limitations as I was re-skinning the Microsoft Azure. Having reached out to Microsoft directly and see how they could assist. As customisation was only beginning to be possible for Azure, the Microsoft team helped shape our production-level requirements and build that into the platform, which luckily aligned with their roadmap.
Another video was created to communicate the commercial value of the API platform:
Approving public facing API layer was a most difficult, depending on approvals across a multitude of Telstra departments, requiring projects and products to be in production with established case studies and adhering to API best practice.
The initial prototype divided opinion around the project. A number of concerns around IP and data security could have been better addressed.
Running successful hackathons and inviting partners, developers and those considered detractors reframed thinking around the value of the platform.
What happened next
Telstra moved the API platform into production (internal). With 75+ APIs as part of the M.V.P and more APIs being added and managed by the internal DevOps.
Post MVP, the API Platform went live and moved into production using the Azure platform for internal purposes only.