The document outlines an architecture for software autonomy, emphasizing principles such as domain-driven design, team ownership, and continuous delivery. It introduces bounded contexts with cross-functional teams to drive innovation, streamline integration, and ensure data integrity within cloud infrastructure. Additionally, it discusses decision-making frameworks to balance autonomy and oversight in technology choices among teams.

1. An Architecture for
Autonomy
Dave Adsit
Lead Architect @ Pluralsight

2. Thanks to our Sponsors!PartnersMarqueePremierPrize

3. Monolith
A single massive stone or rock

4. CRAFTSMANSHIP

5. • Domain driven design
• DevOps mindset
• Team ownership of quality
Pride in
Workmanship

6. • Paired programming
• Acceptance test driven development
• Continuous Integration
Professional
Practices

7. • Automate build and test process
• Push button deploy / rollback
• Reduce lead time
Continuous
Delivery

8. OUR CHALLENGE

9. • Increase product usage capacity
• Increase development capacity
Growth!

10. H. L. Mencken
"For every complex problem there is an answer that is clear,
simple, and wrong."

11. OUR SOLUTION

12. F. A. Hayek
"The curious task of economics is to demonstrate to men how
little they really know about what they imagine they can
design."

13. OUR SOLUTION
A Principled Approach

14. • Engineering Excellence: Security &
Reliability
• Data Availability & Integrity
• Amazing User Experiences
• Innovation & Speed to Market
Strategic Goals

15. • Autonomous teams
• Cross functional teams
• Think 10x
• Cloud infrastructure
• Instrumentation and System Visibility
• Smaller codebases
Architectural
Principles

16. Complexity
Minimize locally
Accept globally

17. OUR SOLUTION
Bounded Contexts

18. • Owned by a cross-functional team
• Collection of microservice(s) and/or
microsite(s)
• Management/support tools
• Unified domain model
• Anti-corruption layer
• Self-healing API: business events & REST
• Source of truth
Characteristics

19. • Source code and repository
• User interface
• Databases
• CI/CD pipelines
• AWS instances in each environment
• Local data caches
Independence

20. • Single source of truth
• Distributed data caches
• Business events
• APIs
Local data

21. • Grow and split existing teams
• Separate the codebase(s)
• Implement integration patterns with
adjacent bounded contexts
Creation

22. • Start with domain knowledge
• Find shared services
• Imagine an external collaborator
• Look for “products”
• Be wary of shared data
• Be prepared to rework boundaries
Seams

23. OUR SOLUTION
Integrating the many
components of the system

24. • Deploy independently
• Favor asynchronous integration
• AMQP + JSON when asynchronous
• HTTP + JSON when synchronous
• Web components
Loose coupling

25. • Message naming
PUB: publisher.event.version
identity.user-signed-in.v2
SUB: publisher.event.version=>subscriber.daemon
identity.user-signed-in.v2=>geocoding.signin.20170217
• Message content
Strive to be idempotent - f(f(x)) = f(x)
Include
Timestamp
Entity Id
Resource URI
Updated fields
Integration
Asynchronous

26. • Self-healing APIs
GET endpoints for resources
Provide authorization tokens for tracking
• Intrinsically synchronous operations
Charge a credit card
• Algorithmic operations
Search
Integration
Synchronous

27. • Categorization
Visibility - public / internal
Scope - user / system / bounded context
• API versioning
vPrevious, vCurrent, vNext
GET https://id.pluralsight.internal/api/v2/user/{id}
Version the whole API as a unit
Integration
Synchronous (cont.)

28. • Shared widgets
Web components
Backed by public, bounded context APIs
Integration
Web UI

29. • Orchestrated within a bounded context
• Choreographed across bounded
contexts
Business
Processes

30. • It’s so easy, I don’t know why everyone
doesn’t do it!
• You may not actually need *all* the data
• Can you only get the data as you need it?
• It is a smell if you consistently need all
the data.
Bootstrapping

31. New Bounded Context will become the
source of truth
Dual write to your new data store
Create a standard ETL job

32. Not the source of truth but require every
record to make local decisions
Talk to your Architect
Subscribe to message from the source of truth
Create a standard ETL job to bootstrap

33. Not the source of truth and can work with
an incomplete cache of data locally
Subscribe to message from the source of truth
When local data is missing call the read-only API exposed by the
source of truth and write the response data to the local data
store

34. OUR SOLUTION
Bounded Contexts

35. Technology
Radar

36. WHAT ABOUT AUTONOMY?

37. Subsidiarity
Matters ought to be handled by the smallest, lowest or least
centralized competent authority

38. 7 DELEGATION LEVELS

39. Technology
Decision delegation framework

40. • Deciding that all production code must
be reviewed by 2 or more people
• Selecting a hosting provider for
production systems
• Required use of MFA on particular
systems
Tell
Architecture, Ops, Security decides

41. • Defining a menu of messaging patterns
for use between Bounded Contexts
• Selecting a version control hosting
provider
• Updating the menu of operating
systems approved for production
applications
Sell
Architecture, Ops, Security decides

42. • Updating the menu of approved
programming languages
• Adding a previously unused service
provided by AWS into the menu
• Cryptographic standards for sensitive
data
Consult
Architecture, Ops, Security decides

43. • Selecting a shared library or 3rd party
service
• Deciding when and how to split a
Bounded Context
• Backup strategies for each Bounded
Context
Agree
Group decision

44. • Deciding to publish a new message
• Monitoring/alerting strategy for product
development owned hosts/services
• How to implement specific security
standard controls
Advise
Product development team decides

45. • Defining the architecture for a single
Bounded Context
• Selecting an application server operating
system from the menu
• Cassandra schema modeling
Inquire
Product development team decides

46. • Defining the architecture for a single
application, website, or API
• Selecting a code editor or IDE
• Selecting a web application framework
Delegate
Product development team decides

47. EXECUTE
With increased clarity
around decision making

48. OUR SOLUTION
Limitations and downsides

49. Questions?