This document serves as a beginner's guide to API strategy, highlighting the importance of differentiating between internet-facing and public APIs that can create new business opportunities even without generating revenue. It emphasizes the significance of understanding the 'why' behind developing public APIs, community engagement, and having a well-documented developer portal, while cautioning against several pitfalls such as poor documentation and not listening to the developer community. Key elements discussed include architectural patterns, budget considerations, and examples of successful API implementations.

1. API strategy a beginners guide
1

2. API’S…?
2
Most people are talking about API’s, of all types, are crea9ng business models to exploit
them (or are trying) and are looking to generate a significant amount of revenue
through them.
Its probably important at this point to differen9ate internet facing API’s and public API’s.
The API’s that are aErac9ng a lot of press and corporate aEen9on are publicly facing
API’s that 3rd party developers & organisa9ons consume, and create new business
opportuni9es and or new products etc using your API.
These business opportuni9es do not necessarily need to have a $ value. There are a large
number where there is no revenue generated - but these API’s do extend an
organisa9on’s reach or footprint.
Having a successful developer / api portal is considered a reasonable measure of an
organisa9ons technical maturity and this can help aEract tech talent.

3. ARCHITECTURAL MODEL
3
Strategic Goal Architecture Capability
Why? What? How?

4. WHY
4

5. WHY
5
Everything starts with Why, or at least should start with Why!
A few ques9ons to help you understand the Why of pushing an API
into the public domain could be…
Why would a developer want to consume my API…?
Why am i developing this API…?
Why am i going to the effort of ‘pushing’ this API into the public
domain…?

6. WHY
6
This Capital One blog that has some great thoughts about the ‘why’
of API’s
hEp://www.capitalone.io/blog/inside-out-taking-your-api-public/
It also has a reference to Simon Sinek’s talk on the ‘Why’ of why
organisa9ons and people are successful.
If you cant answer the Why…then pause… and work out the Why!

7. WHAT
7

8. GOOD
8
• Why understood
• Well documented
• Clear instructions on how to invoke
• Description of what the developer can expect with examples
• Readonly to start with is better
• Not tightly coupled to back end systems
• Application Performance Monitoring tool to monitor and visualise
traffic

9. NOT SO GOOD
9
• API Logic in Vendor products
• API’s that are both internal and public
• Can be difficult to segregate traffic during production incident for
those just starting on their public API journey
• API’s with only 1 or 2 consumers
• Poor documentation

10. ARCHITECTURAL PATTERNS
10

11. HOW
11

12. WHATS THE MOST IMPORTANT THING?
12

13. COMMUNITY ENGAGEMENT
13

14. COMMUNITY ENGAGEMENT - HOW?
14
Portal
Your public presence.
A place where developers
can find information about
your API’s.

15. COMMUNITY ENGAGEMENT - HOW?
15
Evangelist
Externally facing role.
Someone who actively engages
the developer community.

16. COMMUNITY ENGAGEMENT - HOW?
16
Status
A page that publishes
the state of your API
e.g. Active, Degraded,
Not Active.
Typically a subset of the
portal.

17. COMMUNITY ENGAGEMENT - HOW?
17
Forum
An online community
to discuss your API’s.
Allows all
conversations to be
public.
A search resource for
developers.

18. COMMUNITY ENGAGEMENT - HOW?
18
Blog
Whats happening in your
API world…
What worked well and
what didn’t?
What do have coming
next?

19. SOME GOOD EXAMPLES TO LOOK AT
19
Capital One
hEps://developer.capitalone.com/products/
BBVA
hEps://www.bbvaapimarket.com/web/api_market/
Telstra
hEps://dev.telstra.com/
TwiEer
hEps://dev.twiEer.com/rest/public

20. AN EXAMPLE TEAM
20
• Business Owner of the API
• Product Owner for the API
• Empowered DevOps - only 1
team required to release API
• How does the maintenance of
the Public API ‘work’?
• Is this API the teams sole focus?
• If no, how is the effort to
maintain the public API
interweaved with the internal
effort?

21. BUDGET / FUNDING
21
What budget/time/effort is
assigned for public API’s?
Is the funding flexible
enough to cope with
unpredictable demand?

22. DONT FORGET THE MVP
22

23. GOTCHA’S
23
• Trying to short cut the maturity scale
• Slow is ok
• Dont be tempted to go ‘early’
• Not listening to your community - always have an open
channel and someone ‘listening’
• Good internal does not necessarily equal a good
external API
• Vendor lockin

24. andy.mcquarrie@thoughtworks.com
@andymcquarrie
24