In this talk you will learn how strategic tools like Wardley Maps, the C4 model and DDD’s strategic design helped a struggling CTO to fight against a crumbling monolith and the organizational practices that allowed its creation. Among other things we will cover: * How to plan, communicate and challenge strategies. * Why strategy and thinking strategically is important for software developers. * High-level overview of Simon Brown’s C4 Model * High-level overview of DDD’s strategic design * DDD Context Mapping * High-level overview Wardley Maps. * Wardley Maps: Landscape. * FUN random facts about software development in startups :)

2. Case Study: Practical tools and strategies
for tackling legacy practices and legacy
systems in a fast-growing startup.

7. Migrate
to
Am
azon

8. Migrate
to
Am
azon
Finish
iOS App

9. Goals for this talk
Simon Brown’s C4 Model & Software Guidebook.
DDD’s Strategic Design.
Wardley Maps.

10. Brownfield Project
Codename: Waterloo

11. Based on True Life Events

12. Based on True Life Events
pero contados por un argentino

14. Discovery
What is the software architecture?
What does the infrastructure look like?
Which projects are in progress?
How are projects managed ? How is work assigned
and managed?
What is the level of alignment?

15. The software guidebook
C4 Model: Context, Containers, Components and Code

16. The software guidebook
It focusses on the visual
communication and
documentation of software
architecture.
The core of this is the C4
software architecture model
and the software guidebook.

17. Template
Context
Functional Overview
QualityAttributes
Constraints
Principles
SoftwareArchitecture
Infrastructure Architecture
Deployment
Operation and Support

18. Level 1: System Context diagram
What are we building?
Who is using it? (users,
actors, roles, personas)
How does it fit into the
existing environment?
(systems, services)
https://c4model.com/#coreDiagrams

19. Level 2: Container diagram
High-level shape of the
software architecture,
showcasing responsibilities
distribution, major
technology choices and
containers
communication.
A container is a separately
runnable/deployable unit
that executes code or
stores data.
https://c4model.com/#coreDiagrams

20. Level 3: Component diagram
Decomposition of each
container identifying the
major structural building
blocks, called “components”,
and their interactions.
Includes responsibilities
and technology/
implementation details. https://c4model.com/#coreDiagrams

21. https://c4model.com/#coreDiagrams

22. Level 4: Code
UML class diagrams,
entity relationship
diagrams or similar.
Optional level of
detail available on-
demand and
automatically
generated using
tooling.
https://c4model.com/#coreDiagrams

23. Discovery Phase 1
One-on-one meetings with the head of each dptm

24. …
…
?

25. My goals
What is the software architecture?
What does the infrastructure look like?
Which projects are in progress?
How are projects managed ? How is work assigned
and managed?
What is the level of alignment?

26. Discovery Report
There are 19 “things” (systems?, projects?, modules?
components? features?).
Each “thing” has a very clear user/role.
There is no portfolio.
There is no team.
There is no alignment.

28. Infrastructure

32. Discovery Phase 2
Software Development Practices

34. DDD Strategic Design

35. Domain Driven Design
IMHO DDD is one of the
most essential concepts
in software development.

36. DDD Strategic Design
Context Maps
Core Domain
Supporting Subdomain
Generic Subdomain
Bounded Context
Relationships
Solution SpaceProblem Space

37. BC Relationships:
Big Ball of Mud
Shared Kernel
Customer/Supplier
Published Language
Open Host Service
Anticorruption Layer
Conformist
Separate Ways

44. BBOM

49. Organizations which design systems are
constrained to produce designs which are copies
of the communication structures of these
organizations.
Melvin Conway - How Do Committees Invent? (1968)

51. Guiding Principles
Common Closure Principle and Single Responsibility
Principle.
The Acyclic Dependencies Principle: Allow no cycles
in the component dependency graph.
The Stable Dependencies Principle: Depend in the
direction of stability.

52. “The best bits of DDD happen outside your IDE”
Nick Tune - Patterns, Principles, and Practices of Domain-Driven Design

53. Wardley Maps

54. Wardley Maps
A Wardley Map is a
representation of the
landscape in which a
business operates.
A Wardley Map represents
the shared assumptions
being made about a context
and hints at what strategic
options are available.

55. Wardley Maps
The cycle
The Landscape
Climatic Patterns
Anticipate (by applying climatic patterns)
Doctrine
Context Specific Play
Gameplay
Loop

56. Crossing the river by feeling the stones. By Simon Wardley

59. Crossing the river by feeling the stones. By Simon Wardley

60. Crossing the river by feeling the stones. By Simon Wardley

61. Crossing the river by feeling the stones. By Simon Wardley

62. Evolutionary Characteristics
Stage of Evolution I II III IV
Genesis Custom Product (+rental) Commodity
(+utility)
Ubiquity Rare
Slowly increasing
consumption
Rapidly increasing
consumption
Widespread and
stabilising
Certainty
Poorly
understood
Rapid increases in
learning
Rapid increases in
use / fit for
purpose
Commonly
understood (in
terms of use)
Market Undefined market Forming market Growing market Mature market
User perception
Different /
confusing /
exciting /
surprising
Leading edge /
emerging
Common /
disappointed if
not used or
available
Standard /
expected
Failure
High / tolerated /
assumed
Moderate /
unsurprising but
disappointed
Not tolerated,
focus on constant
improvement
Operational
efficiency and
surprised by
failureKnowledge
management
Uncertain Learning on use
Learning on
operation
Known / accepted
Practices Novel Emerging Good Best

63. Crossing the river by feeling the stones. By Simon Wardley

64. Crossing the river by feeling the stones. By Simon Wardley

65. Crossing the river by feeling the stones. By Simon Wardley

66. Crossing the river by feeling the stones. By Simon Wardley

67. Crossing the river by feeling the stones. By Simon Wardley

68. Crossing the river by feeling the stones. By Simon Wardley

69. C
D
E
B
A

75. Mapping Maturity by
Chris McDermott

76. Mapping Maturity by
Chris McDermott

77. Mapping Maturity by
Chris McDermott

78. Discovery Phase 2
Software Development Practices

80. Main Issues
A very loose criteria of what a "version" is.
Huge differences between development environments, each
developer has their own criteria and tools. Limited
availability of environments.
Developers are not involved in the release process.
Creating and deploying a new version is a manual process
and takes a couple of days.
Monthly deployment cadence.

81. DevOps: Bottleneck Analysis
Constraints Evolve in a predictable way

82. Constraints Evolve in a predictable way
Inconsistent Environments - Environment Creation
Manual Intervention - Code deployment
Poor SDLC practices - Test setup and run rate
Overly tight architecture
Product Owners

83. Principles & Practices
The Twelve-Factor App
Developers who wrote code are closely involved in
deploying it and watching its behaviour in production.
Continuous Integration
Visibility. Invest early in monitoring
Coding the Architecture & Infrastructure as Code.

84. Principles & Practices
“There is a SaaS for that” or “There is an API for that”
Don’t build it in-house. Leverage existing APIs. Focus
only on what’s core for the product, don’t reinvent
the wheel.
Optimize for speed of development. Remove all
impediments to a faster development cycle.

85. Key Changes
Unification of the development environment (Macs, PHPStorm and Vagrant for everyone)
Implemented 8 of the 12 points in the The Twelve-Factor App.
Introduction of git and the gitflow branching strategy.
Versioning
Introduction of jenkins and CI
Reduced time to release from days to seconds.
Reduced deploy cadence from a monthly to daily.
Moved from Pet to Cattle servers.
Decided to start developing services with Java and Docker.

86. I. Codebase (One codebase tracked in revision control, many deploys)
II. Dependencies (Explicitly declare and isolate dependencies)
III. Config (Store config in the environment)
IV. Backing Services (Treat backing services as attached resources)
V. Build, release, run (Strictly separate build and run stages)
VI. Processes (Execute the app as one or more stateless processes)
VII. Port binding (Export services via port binding)
VIII. Concurrency (Scale out via the process model)
IX. Disposability (Maximize robustness with fast startup and graceful shutdown)
X. Dev/prod parity (Keep development, staging, and production as similar as possible)
XI. Logs (Treat logs as event streams) #291
XII. Admin processes (Run admin/management tasks as one-off processes)

90. Feedback Door
5 - WOW! I learned something new and useful (in a
fun way).
4 - …
3 - …
2 - …
1 - I wish I would have been watching Netflix.

91. Gracias!
Alejandro Scandroli
@_ascandroli