BAPO stands for Business Architecture Process Organisation. It is Jan Bosch's more fleshed out expression of "structure should follow strategy". I recently experimented with applying this framework and would like to share what worked and what didn't. Concepts expanded beyond BAPO to include product capabilities versus architecture services; overlapping product lifecycle s-curves; Simon Wardley's Pioneers, Settlers, Town Planners; and a reframing of the teaching people how to fish metaphor.

1. 1
Using BAPO to
apply structure
follows strategy
to your
organisation
According to Jason Yip
@jchyip
https://jchyip.medium.com
jchyip@gmail.com, jyip@spotify.com

2. https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/
BAPO is a way to
approach org design

3. https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/
But, org design is typically
OPAB, not BAPO… why?

4. 4
Changing org structure is
messy

5. It’s reasonable to expect
that an org structure
change may include
manager changes
“people leave managers,
not organisations”
Retention
problems

6. It’s reasonable to expect
that an org structure
change may include
manager changes
Some managers get
more or less direct
reports than others
Politics and
manager
retention
problems

7. Don’t change managers
to avoid retention
problems
Direct reports are on
different teams
Managers can’t stay
on top of context of
different teams
People prefer
managers who are
familiar with the
context
Retention
problems
Managers can’t stay
on top of context of
different teams

8. It’s reasonable to expect
that an org structure
change may include
re-allocation of
responsibilities
Some people might lose
responsibilities they
liked OR gain
responsibilities they
don’t like
Disengagement
and/or retention
issues

9. 9
Therefore, we should avoid
changing the org structure
unless we really have to?

10. 10
Organisation constrains
architecture;
architecture constrains
strategy

11. “Any organization that
designs a system (defined
broadly) will produce a
design whose structure is a
copy of the organization's
communication structure.”
Melvin E. Conway

12. You can’t pretend
product capabilities
are independent if
the architecture is
coupled

13. 13
Therefore, structure drives
architecture, architecture
drives strategy?

15. 15
Structure should follow
strategy

16. “Unless structure
follows strategy,
inefficiency results.”
Alfred D. Chandler Jr

17. https://janbosch.com/blog/index.php/2017/11/25/structure-eats-strategy/
BAPO is Jan Bosch’s more fleshed out expression
of “structure should follow strategy”

18. 18
“Business” → product strategy
→ product life cycles →
overlapping s-curves

19. https://hbr.org/1965/11/exploit-the-product-life-cycle
Not every
product idea
makes it to
growth
Every product
eventually
becomes a
commodity

20. https://colescottgroup.com/understanding-growth-using-s-curves/

21. 21
Innovate to identify the next capabilities;
Differentiate to exploit current capabilities;
Commodotise old capabilities for efficiency or to exit

22. Category Description KPI (Key Performance
Indicator)
Commodity
(aka hygiene)
● Needed for product to work
● No customer will select the
product because of this
functionality
● Minimise total cost of
ownership
Differentiating
(aka better = $)
● Unique capabilities that
drive customer interest and
buying behaviour
● Maximise business value
Innovation
(aka not
guaranteed to
work)
● Experimental functionality
as part of trying to identify
new future differentiation
● Number of experiments
attempted

23. Commodity Differentiating Innovation
Account
management
Audience
management
Payments
Campaign
management
Commodity 3rd
party
measurement
Advanced
forecasting
Advanced pricing
Decision
optimisation
New client
platforms
Reporting
New formats
New targeting
Example

24. 24
“Architecture” is about
cohesion and coupling
(aka dependencies)

25. Services should align to capabilities, though not
necessarily 1:1. Services should avoid coupling
unrelated product capabilities.
Product capability
Architecture
service
Product capability
Architecture
service
Architecture
service
Product capability
Architecture
service
Product capability

26. Dependencies should be 1-way. Volatile things
might depend on stable things. Stable things
should not depend on volatile things.
“Commodity”
service
“Differentiating”
service
“Innovation”
service

27. 27
However, fixing an
architecture is typically not
instantaneous and...

28. It’s not useful to
play pretend

29. 29
The point is that you have a
target architecture designed to
be aligned to product strategy.

30. 30
“Process” is about ways of
working aligned to product
strategy constrained by
architecture

31. Category KPI (Key Performance
Indicator)
Potential ways of working
Commodity
(aka hygiene)
● Minimise total cost of
ownership
Outsource, use 3rd party
services, internal platform
teams, minimise unnecessary
variation
Differentiating
(aka better = $)
● Maximise business value Iterative-incremental
development, maximise
valuable variation
Innovation
(aka not
guaranteed to
work)
● Number of experiments
attempted
Running lots of parallel
experiments, acquisition

32. 32
Different people have different
preferences for different ways
of working

33. https://wardleypedia.org/mediawiki/index.php/Pioneers_settlers_town_planners

34. 34
“Organisation” is structure to
support desired ways of
working

35. Minimise staffing allocation to “commodity”.
Decide appropriate % allocation between
“differentiation” and “innovation”.
“Commodity”
teams
“Differentiating”
teams
“Innovation”
teams
Minimise
Judgment call on how to balance remaining allocation
between “differentiating” and “innovation”

36. Note there might be a cascade from “product
teams” to “internal platform teams”.
Product team
Internal platform team
Innovation
Differentiation
Commodity
Differentiation Innovation

37. 37
Design teams to minimise the
amount of coordination
required across teams.

38. 38
“Collaboration is expensive. Unnecessary
collaboration is particularly expensive,
especially as it can mask or hide
deficiencies in underlying platforms or
capabilities.”
Team Topologies by Matthew Skelton,
Manuel Pais

39. BAPO:
Step-by-step
1. Categorise product capabilities on
where they are in the product life cycle;
2. Decouple technical architecture across
categories, ensure one-way
dependencies, make appropriate tech
choices;
3. Minimise effort on commodity, decide
distribution between differentiation vs
innovation;
4. Design teams and account for
individual preferences

40. Example: What
I actually did
1. Create a strawman categorisation
starting from existing high-level
architecture diagrams;
2. Validate with one of the senior
engineers;
3. Validate using 1:1s with Product
Area/Tribe Product Leads → this
led to separating “product
capabilities” from “architecture
services”;
4. Validate in a group session with
Mission Leads (NOTE: This didn’t
quite work, will discuss why later)

41. Example: What
a colleague is
trying
1. Create a strawman with one of the
Mission Leads;
2. Validate in a group session with the
Product Area/Tribe Leads

42. PRO TIP: Start where you are;
expect to iterate
42

43. PRO TIP: Sometimes it’s not
about teaching people how to
fish. If someone delegated the
fishing, just provide the fish.
43

44. Concluding
thoughts
● BAPO is a useful way to frame org
design by connecting product
strategy, architecture, ways of
working, and org structure;
● Expect to iterate - “all models are
wrong, but some are useful”
(George Box) ;
● (Change agent advice) Sometimes
just provide the fish

45. To learn more
● (blog) Jan Bosch’s 2017 post on BAPO:
“Structure Eats Strategy”;
● (book) Impactful Software by Jan Bosch;
● (blog) My Medium post on this: “Concepts
I use every day: BAPO”
● (paper) An evolution of BAPO: “ESAO: A
holistic Ecosystem-Driven Analysis Model”
by Jan Bosch and Petra Bosch-Sijtsema
● (article) “Exploit the Product Life Cycle” by
Theodore Levitt, Harvard Business
Review, Nov 1965
● (blog) Simon Wardley’s 2015 post “On
Pioneers, Settlers, Town Planners and
Theft”;
● (book) Team Topologies by Matthew
Skelton and Manuel Pais