Liz Douglass & Saul Caganoff share their experience with problems and anti-patterns in enterprise integration and APIs. They propose a model to overcome these issues through product orientation.

1. Growing an
API Culture
“T’aint what you do…”
Liz Douglass, Partner at Deloitte Platform Engineering
@LizDouglass
Saul Caganoff, Principal & CTO at Deloitte Platform Engineering
@scaganoff

2. Agenda
Part 1: Common problems and anti-
patterns
Part 2: What does better look like?
Part 3: Growing applications into domains

3. Part 1.
Common
problems &
anti-patterns

4. Bottlenecks
⊷ Consumers waiting on APIs
⊷ Waiting on central integration team
⊷ Waiting on shared infrastructure
⊷ System inertia due to technical debt
4
Silos
⊷ Lots of similar APIs
⊷ No benefits from reuse
Contention
⊷ Version proliferation – APIs don’t get
retired
⊷ Version churn – APIs change rapidly

5. 55

6. 66

7. 77

8. 8
Reference Henrik Kniberg: Spotify Engineering Culture (Part 1)

9. 9
Disconnected
Projects
Sweet Spot
• Domain autonomy& durability
• Governanceat the edges
😭
🚀
HighAlignment
• Discovery
• Consistency
High Autonomy
• Durability
• Self-service
LowAutonomy
• Order-takers
Delivery Model
Governance
Model
Integration
Factory
🏭

10. Part 2.
What does
better look
like?

11. The flow
model
⊷Features
⊷Defects
⊷Risk mitigation
⊷Technical debt
11
a zero-sum game
Project to Product by Mik Kersten

12. The problem with (only) projects
⊷ Compartmentalised scope and time
⊶ “Just need to get it done”
⊶ Sometimes this is unavoidable – but
technical debt is OK if you pay it back
⊷ Short-term incentives with no consequences
for shortcuts
⊷ More convenient to look at things as
evergreen
⊶ Easier to start from scratch than to re-
use someone else’s stuff
⊷ Projects are hampered in their ability to
promote durable, re-usable assets such as12

13. Product thinking
⊷ An antidote to some of the problems of
projects
⊷ Product thinking looks like:
⊶ A roadmap of features extending into
the future
⊶ Features driven by customer demand
⊶ The ability to push back (or say “no”)
on customer demand – e.g. to maintain
the integrity of the product
⊷ Typically manifest in a product manager
who has resources, rights and longevity to
deliver on a product roadmap
13

14. Part 3.
Growing
applications
into domains

15. Many organisations struggle with
product thinking
⊷ 50 years of the project paradigm:
⊶ Concepts
⊶ Processes
⊶ Funding models
⊶ Organisational structure
⊷ Procurement models based around COTS
⊶ Projects commission COTS “boxes”
and join them up (integration)
⊶ Pick the product then pick an
implementation partner (system
integrator)
⊷ Attention centres on the box rather than the
business capability
15

16. Integration
becomes a thing
we “do”
16
⊷Delivered via projects
⊷Lines between boxes
⊷An obligation
⊷Inherits the problems of projects
⊶difficult to create durable, re-usable
assets
Application 1
Asset boundary
Application 2
Asset boundary
Integration
Design
Build
Run
Endpoints
Data structures
Mapping rules

17. Can we flip this
model?
17
⊷Most organisations already have durable asset
teams
⊶Centred on COTS applications
⊶Stopping at the application boundaries
⊷What if we move the APIs into those asset
boundaries?
⊷Asset teams become the durable owners of their
domain APIs
Application 1
Asset boundary
Application 2
Asset boundary
API Provider
Design
Build
Run
Endpoints
Data structures
API Consumer
Mapping rules

18. 18
⊷ Application boundaries expand to form domains
Application 1
Asset boundary
Application 2
Asset boundary

19. 19
Domain boundary Domain boundary
⊷ Application boundaries expand to form domains
⊷ Domain capabilities expressed via APIs & event
streams

20. 20
Domain boundary Domain boundary
⊷ Application boundaries expand to form domains
⊷ Domain capabilities expressed via APIs & event
streams
⊷ Core applications augmented by microservices

21. 21
Domain boundary Domain boundary Domain boundary
⊷ Application boundaries expand to form domains
⊷ Domain capabilities expressed via APIs & event
streams
⊷ Core applications augmented by microservices
⊷ Domain boundaries become a scaffold for
modernisation

22. 22
Domain boundary Domain boundary Domain boundary

23. Integration “emerges”
from the act of
consuming APIs
Integration is no longer a thing you “do” in
projects
23

24. 24
Disconnected
Projects
Sweet Spot
• Domain autonomy& durability
• Governanceat the edges
😭
🚀
HighAlignment
• Discovery
• Consistency
High Autonomy
• Durability
• Self-service
LowAutonomy
• Order-takers
Delivery Model
Governance
Model
Integration
Factory
🏭
Slide design courtesy of slidescarnival.com – licensed under Creative Commons