Ecosystem map (size reduced and sensitive data removed)
Anton Stout
UX Strategist | Product Designer | Product Manager
TELSTRA
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.
Stakeholder buy-in
Manage the product team
Content audit
Information architecture
Prototyping
Financial modelling
Business lead
Duration
Post discovery, the solution period from concept mapping through to prototyping took ~6 months
Budget
$550k spend vs $1.6m budget. Product still in use at Telstra Health.
GOAL:
Build an internal API Platform for Telstra Health and our entities
Build an internal API Platform for Telstra Health and our entities
Ecosystem mapping
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.
What next?
Developers transcended each layer of the ecosystem, it was essential to we better understand their needs to build our solution.
Discovery
400+ engineers across T-Health, subsidiaries and partners
Survey Design
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
Wireframes of our survey - the opening to the API platform: T-Health Developer
Requirements
Inventory Audit
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.
Leading Categories:
Health business intelligence
Health data analytics
Health improvement
Professional services
Home and mobile monitoring
Health data repositories
Payment and billing
Health research data
Pharmacy/medications
Secure messaging
Prescribing services
Health record/storage
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.
Draft tracking and reporting document of APIs
63%
SOAP/XML
30%
REST/JSON
90%
OAUTH REQUIRED
Key insights
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.
Architecture
Example of Tree-Test task: Find the developer docs
Sitemap
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.
Draft sitemap of the MVP platform: T-Health Developer
Key insights
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.
Delivery
First version (lo-fi) of the API platform prototype
Wireframes
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.
What next?
A video was created to communicate how an API platform could enrich the Telstra Health ecosystem:
UI Design
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.
What next?
Another video was created to communicate the commercial value of the API platform:
Challenges
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.
What failed
The initial prototype divided opinion around the project. A number of concerns around IP and data security could have been better addressed.
What worked
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.