**Four aspects of thinking like an architect:** - Understanding the difference between architecture and design and knowing how to collaborate with development teams to make architecture work - Having a wide breadth of technical knowledge while still maintaining a certain level of technical depth, allowing the architect to see solutions and possibilities that others do not see - Understanding, analysing, and reconciling trade-offs between various solutions and technologies - Understanding the importance of business drivers and how they translate to architectural concerns Pyramid of all knowledges: ![[PyramidOfAllKnowledge.png]] An architect must add to it technical knowledge breadth, that means he must increase "stuff he know that he don't know". **Frozen Caveman Antipattern**, is a behavioural anti pattern. describes an architect who always reverts back to their pet irrational concern for every architecture. "While risk assessment is important, it should be realistic as well" Everything in architecture is a trade-off, which is why the famous answer to every architecture question in the universe is “**it depends.**” **There are no right or wrong answers in architecture—only trade-offs.** Programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both. **Thinking like an architect** is understanding the business drivers that are required for the success of the system and translating those requirements into architecture characteristics (such as scalability, performance, and availability). So we face various architecture characteristics, ways to identify and qualify these characteristics, and how to measure each characteristics to ensure the business needs of the system are met. **How can a software architect still remain hands-on and maintain some level of technical depth?** - First of all architect must not block the entire project and becoming a bottleneck by developing core frameworks. because he's not a full-time developer and he has to do his duties respectively, and this lead to slow speed of core framework development and making bottleneck. - Doing PoCs. - Tackle some of the **technical debt stories** or **architecture stories**, it also help freeing the development team up to work on the critical functional user stories. - Working on bug fixes within an iteration. - Leveraging automation by creating simple command-line tools and analysers to help the development team with their day-to-day tasks - Do frequent code reviews. **Questions:** 1 - Name for aspect of architectural thinking. 2 - Difference between technical breadth and depth 3 - Architect need technical ........... more than technical .......... 4 - What's reason for making a choice between many options? 5 - How an architect can remain hands on over the code?