The document discusses the importance of software architecture and leadership in managing uncertainty and making informed decisions. It outlines seven principles for effective design, emphasizes the role of architects in driving projects, and poses five key questions to navigate challenges. Ultimately, it highlights that great software designs stem from thoughtful consideration rather than rigid formulas.

1. Software
Architecture and
Decision Making
Srinath Perera
Chief Architect, WSO2

2. About me, in last 20 years

3. Goal of Software Architecture?

4. As practicing software architects:
● We know about many techniques
○ Abstractions
○ Arch styles, pros and cons
○ Patterns pros and cons
○ Where to use which one
○ How to compose them
○ Pitfalls, negative examples
● However, a lot of errors are not
made there

5. Causes of Mistakes
● Techniques conflict with each other. (e.g., Security vs.
Usability or Flexibility vs. Simplicity)
● Going overbroad with some technique. (e.g., cloud
portability)
● Given a project, we only partially understand the needs;
we learn more as we go on.
● There is a background of the project - like a deadline,
when can we rewrite, and the skills of the team
● Problems and techniques available evolve over time.
● There are techniques to handle uncertainty, but they
have costs, too.
I see Leadership Challenges, not
technical Challenges!!

6. Leader is a dealer in Hope
● To me, leadership is about
○ managing uncertainty
○ bringing order to the chaos.
○ providing a hope of a better future and making
progress.
● People follow whoever offers to handle
uncertainty
● It is a choice “A leader is a dealer in hope.”
--Napoleon Bonaparte

7. Software Architecture is about Managing
Uncertainty and Abstractions

8. Each area has good
Books!!

9. What if you are not in Charge?
● Good architects start to play the role years
before they are given the title.
● The more knowledgeable you are, the better
chance you’ll have if you do choose to lead.
● Take the initiative; help your leader and
deliver. You will find you own more and
more. Titles will follow.
● If you believe someone can do it better, by all
means, follow and learn from them!!

10. Book will draw
examples from
many technical
leaders that made
seemingly
impossible
Systems possible

11. Great Tech Leaders: Wright Brothers

12. Great Tech Leaders: Kelly Johnson

13. ● Seven Principles
P1: Drive Everything from User Journey
P2: Use a Iterative Thin Slice Strategy
P3: Support more users while doing as less as
possible on each Iteration
P4: Leader must make Decisions and absorb the
Risks
P5: Design Deeply things hard to change and but
implement them Slowly
P6: Eliminate Unknowns and learn from Evidence
P7: Consistency in the Architecture is a Tradeoff
We will discuss, Five Questions to Ask and Seven Principles
● Five Questions
Q1: When can we rewrite the system?
Q2: Performance sensitivity?
Q3: Skill Level of the team
Q4: Time to Market
Q5: What are the hard problems?

14. Questions to
tackle
Uncertainty

15. Q1: When can We rewrite the
system?
● You can rewrite it sooner than you
think.
○ If yes, We can be lean, simple, worry less
● Also, with the new IDEs, it is
comparatively easy to refactor and
align code to the new architecture.
● Let us plan to rewrite (partially) beyond
key milestones.
○ Having accepted that we will rewrite, we
can push non-essentials to the next
rewrite.

16. Q2: Performance Sensitivity?

17. Q3: Skill Level of the Team
“You go to war with the army you have, not the
army you might want or wish to have at a later
time.” ― Donald Rumsfeld
● Given the top 1% of programmers, not much leadership
is needed; leadership is needed when we work with
less-than-perfect teams.
● Have a hard, realistic look at your team.
● You must pick an architecture your team can manage.
○ For this reason, do not pick EDA CQRS without experience.
○ High costs in understandability and debugging
challenges.

18. Q4: Time to Market
● Time to market is everything; ask
the business.
● Our design must incorporate the
realities of time to market.
● We may rewrite it later
● Although deadlines are often not
negotiable, features in the
release are usually negotiable.
● Use UX-based design and, build
an MVP, and negotiate features
as needed.

19. Q5: What are the hard
problems?

20. Principles to
Make Decisions

21. P1: Drive Everything from
User Journey
Quote ??

22. P2: Use a Iterative Thin Slice Strategy
“Premature optimization is the
root of all evil” -Donald Knuth.

23. P3: On each Iteration, try to add most
value for least effort
● Deeply understand the user journey
● Do less
○ Embrace Minimal Viable Product (MVP)
○ When in doubt( when the team disagrees significantly with each other), leave it out.
○ Wait until enough X three people ask for the feature ( X decided by the leader)
○ Say No if features do not match the user journey. Saying yes to one means saying no to
others! (if we take a book store, the user journey is what people do when they come,
and it is never fully defined - e.g., someone wants to search by the number of pages in
the book, you need to gauge if that is useful for enough users?)
○ Do not over engineer/ Look out for Google Envy. (see You are not Google)
○ Whenever possible, build on top of middleware tools or cloud services. (E.g. IAM)
● Interfaces and other abstractions are techniques for creating options and
delaying decisions. But Mind the cost (. e.g., One often seen mistake
("anti-pattern") in using abstractions is an extensive use of layering (with
really terrible performance impact).

24. P4: Leader must make Decisions
and absorb the Risks
● Any project faces many uncertainties.
○ E.g., the capacity of the MVP's first version.
○ A leader must collect the required data and perform
required experiments, but that is often not enough.
● While designing the moon rover, nobody knew the
moon's surface.
○ Phyllis Buwalda wrote a specification of the moon's
surface, just elevating parameters from the harshest
desert on the earth. He absorbed the risks.
● Leaders must remove ambiguity, create solvable
targets, and absorb the risks. If they do, little time
would be wasted on indecision.
● Make it your goal not to slow down anyone!! Nicholas Mutton / A fork in the road / CC BY-SA 2.0

25. P5: Design Deeply things hard to
change and but implement them Slowly

26. P6: Eliminate Unknowns and learn from
Evidence

27. P7: The proper Granularity of the
Architecture is a Tradeoff

28. Produce Delivery Design:
Questions
● When can I rewrite the system?
○ Sales goals will tell you, OK, to rewrite in a year or so
○ Build on top of a single cloud
● How performance-sensitive is my system?
○ Depends on sales forecasts? Likely No.
● How skilled is my team?
○ Find out
● Time to market?
○ Likely, we need this pretty fast?
● What are hard problems?
○ How to handle perishability in the system?
○ Low-latency WAN networks
○ Security

29. Produce Delivery Design:
Principles
● Do less and as late as possible
○ MVP is built around key experiences, learns from users
● Make decisions and bind the scope
○ Set down performance targets
● Design deeply, implement slowly
○ Define APIs, understand future scenarios, implement the MVP
● Use iterative thin-slice strategy
○ Stage it, then use Growth Hacking to iterate
● Eliminate unknowns and learn from evidence
○ Build enough traceability
○ Test the thin slice to ensure performance
○ Verify third-party tools, APIs
○ Can simple DB handle it?
○ Growth Hack the Product

30. Book Outline
● Part II
○ Background: Performance, UX
● Part III
○ MacroArchitecture
■ Chapter 5: Introduction
■ Chapter 6: Coordination
■ Chapter 7: Preserving Consistency of
State Chapter 8: Handling Security
■ Chapter 9: Handling HA and Scale
Chapter 10: Microservices
Considerations
○ How to write a service
○ How to Build Stable systems
● Part III
○ Putting everything together

31. Conclusion
● Building Great Software Designs is about handling uncertainty
● We need to use a fluid approach rather than rigid principles, such as
maximizing options
● Five Questions gives you a framework to understand
● Six Principles gives you a framework to make decisions
● It is not a formula but requires careful consideration, and great designs
can’t come from formulas. You must think!!
Uncertainty is leaders responsibility