Book: How do we minimize Software Architecture mistakes?

Uncertainty is the leading cause of mistakes made by practicing software architects. The primary goal of architecture is to handle uncertainty arising from user cases as well as architectural techniques. The book discusses how to make architectural decisions and manage uncertainty. From the book, You will learn common problems while designing a system, a default solution for each, more complex alternatives, and 5Q & 7P (Five Questions and Seven Principles) that help you choose.

Book, https://amzn.to/3v1MfZX
Blog: http://tinyurl.com/swdmblog
Six min video - https://youtu.be/jtnuHvPWlYU

Transcript

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