Architectural practices for greater scalability and innovation

When dealing with application scalability, it is common to deal with topics such as microservices, cache, and NoSQL, among other buzzwords in the software engineering area.
However, particular needs are often overlooked, such as: ensuring that the organization's point of failure is not IT. But instead the human factor.

One of the biggest challenges in software engineering today is ensuring that the technology park grows and innovates while being stable and resilient. Delivering innovation with stability, despite sounding utopian, is possible through well-orchestrated work.

This talk will teach practices that lead to a well-documented, multiplier architecture.

Transcript

1. Architectural practices for greater scalability and innovation Otávio Santana Software Engineer & Architect and Open Source Committer otavio@osarchitech.com @otaviojava
2. Who am I? Software Engineer & Architect @otaviojava Otavio Santana • Java Champion, Oracle ACE • JCP-EC-EG-EGL • Apache and Eclipse Committer • Jakarta EE and MicroProfile • Duke Choice Award • JCP Award • Book and blog writer @otaviojava
3. What is Architecture?
4. What is Architecture? Several approaches @otaviojava osarchitech.com
5. What is Architecture? Organization view and structure of software Conway's law The two-pizza rule Integration Context @otaviojava osarchitech.com
6. What is Architecture? Everything is around software! “Every Company is a Data Company” CIO Network “Every Company is a Software Company” Forbes “Every business is a software business” CMMI @otaviojava osarchitech.com
7. Complexity Achieving Simplicity Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system. @otaviojava osarchitech.com
8. Complexity How to measure? Change amplification Cognitive load Unknown unknowns @otaviojava osarchitech.com
9. Why do we need architecture? Ref: https://www.csoonline.com/article/2130877/the-biggest-data-breaches-of-the-21st-century.html Less Damage Unite Team Fault Tolerance Incremental Delivery Avoid Complexity Scalability @otaviojava osarchitech.com
10. Scalability Handle a growing amount Technology Culture Methodology A single point of failure @otaviojava osarchitech.com
11. Who is an architect? Etymology Arkhi -Greek Chief Tekton Greek Builder Arkhitekton Greek Master builder @otaviojava osarchitech.com
12. Who is an architect? Duties Trade-offs Changes Fault tolerances @otaviojava osarchitech.com
13. Who is an architect? Stereotypes @otaviojava osarchitech.com
14. Who is an architect? Single point of failure Bus factor Management 3.0 View @otaviojava osarchitech.com
15. Who is the architect? Steward A person responsible for overseeing and protecting something considered worth caring for and preserving. Mark Reinhold Chief Architect, Java Platform Group, Oracle The Future of the Java Platform and the JDK: Who is in Charge? https://www.youtube.com/watch?v=HpbchS5kmio @otaviojava osarchitech.com
16. Who is an architect? The whole team Architecture without Architects Erik Dörnenburg The Myth of the Genius Programmer Software engineer at Google @otaviojava osarchitech.com
17. Architects assemble The whole team Design Architecture Documentation Communication @otaviojava osarchitech.com
18. Documentation None A self comment is a utopia The same mistake twice A huge effort instead of assembling Thousand of meetings People’s mind @otaviojava osarchitech.com
19. Documentation Over More enemy than an ally Easy to depreciate Hard to write More work to code Hard to maintain @otaviojava osarchitech.com
20. Documentation Trade-off PPT does not compile Over Documentation Blind code is Go horse None Documentation Document what makes sense Fair Documentation @otaviojava osarchitech.com
21. Documentation First steps C4-model Architecture’s map Tech-radar Technologies's view ADR Don’t repeat the error Communication A clear direction @otaviojava osarchitech.com
22. C4-model Architecture’s map C1 = Context C2 = Containers C3 = Components C4 = Code @otaviojava osarchitech.com
23. C1 Context Business Perspective Starting point Everyone understand Systems @otaviojava osarchitech.com
24. C2 Containers It is not a docker! Architecture Container = App, DB Integration @otaviojava osarchitech.com
25. C3 Components More details Multiples Components Technologies Details (Design Docs) @otaviojava osarchitech.com
26. C4 Code Avoid it! Exception Deep Detail UML @otaviojava osarchitech.com
27. Tech-radar Technologies's view Avoid a mix of technologies Breaking down the silos Duplicate efforts New researches @otaviojava osarchitech.com
28. Tech-radar Rings Languages and Frameworks Platforms Techniques Tools There is no standard Context matters @otaviojava osarchitech.com
29. Tech-radar Quadrant Strategic Essencial Potencial Deprecated @otaviojava osarchitech.com
30. Tech-radar Quadrant Strategic Essencial Potencial Deprecated The most important The team is more confident Several success cases @otaviojava osarchitech.com
31. Tech-radar Quadrant Strategic Essencial Potencial Deprecated There is an experience in using it Not fully mature There is training @otaviojava osarchitech.com
32. Tech-radar Quadrant Strategic Essencial Potencial Deprecated Research it at least a team It has a chance for more adoption Carry out studies and tests @otaviojava osarchitech.com
33. Tech-radar A clear direction Strategic Essencial Potencial Deprecated Unsafe Avoid it Out fashion @otaviojava osarchitech.com
34. ADR Record all the strategic decision Make sure about the trade-off The mistake is one learning path @otaviojava osarchitech.com
35. Communication Clear Async has a higher priority Meeting notes Write/Read deal @otaviojava osarchitech.com
36. Breaking down the silos Avoid delay Integration Prevent Avoid delay Integration Prevent @otaviojava osarchitech.com
37. Show me the case @otaviojava osarchitech.com
38. Previous scenario What is open source? Who cares about architecture? We need to believe! @otaviojava osarchitech.com
39. The decisions, why? • No decision description • No trade-off @otaviojava osarchitech.com
40. The user is the enemy No communication process No synchronization with DevRel @otaviojava osarchitech.com
41. The scalability that doesn't scale Why do we use microservices? To scale. Do we scale? No @otaviojava osarchitech.com
42. The premisses • Everything as code (Architecture and decision) • Synchronization with the clients • Decision by trade-off • Data-centric area @otaviojava osarchitech.com
43. C4-model C4-Builder https://docs.horusec.io/c4model/en#/ https://docs.usebeagle.io/c4model/en/#/ https://docs.charlescd.io/c4model/en/#/ @otaviojava osarchitech.com
44. C4-model C4-Builder @startuml c1 LAYOUT_WITH_LEGEND() LAYOUT_LEFT_RIGHT() Person(user, "Developer", "") System(charlescd_system, "CharlesCD System", "") System_Ext(kubernetes, "Kubernetes") Rel(user, charlescd_system, "Manages your deployments") Rel(charlescd_system, kubernetes, "Deploys...") Rel(charlescd_system, user, "Sends...") @enduml @otaviojava osarchitech.com
45. Tech-radar One to the whole area/company https://opensource.zup.com.br/radar @otaviojava osarchitech.com
46. ADR Log4brains Markdown Flow @otaviojava osarchitech.com
47. Data-centric Area • Every decision data based • Dashboards • Learn from the past @otaviojava osarchitech.com
48. The results Brasil: 80,6% EUA: 7,4% Índia: 2,7% China: 2% Rússia: 1,5% Alemanha: 1,3% Japão: 1% Indonésia: 0,7% Argentina 0,4% @otaviojava osarchitech.com
49. Thank you Barbara Rossalli Lucius Curado Wilian Gabriel da Silva Mari Moreira Carol Vilas Boas Jomar Silva @otaviojava osarchitech.com
50. Thank you! Otávio Santana Software Engineer & Architect otavio@osarchitech.com @otaviojava @otaviojava osarchitech.com