by anoviceuser on 8/27/20, 7:14 AM with 10 comments
I would love to hear any insight, perspective, experience, opinion on Being an Architect. But if someone is looking for some specific questions then I have attempted to come up with few of them as below:
+ What aspect of the Architect role do you like the most and Why? + What challenges do you face in your role and how do you manage them?
+ What is your process of arriving at an Architecture for a given requirement? + How do you identify the key requirements to be addressed by Architecture and the ones to be addressed by the later design phase? + How do you manage competing Design concerns/constraints while Architecting? + Do you seek contributions from others while Architecting? How do you elicit contributions from others? + How do you review your Architecture? + How do you build acceptance for your Architecture within the Team? How do you build consensus among stakeholders?
+ How do you self-evaluate your effectiveness in playing the role of an Architect? How do you decide the aspects you have to improve on? + What Qualities, Personality Traits, Habits do you think have help you become effective in your role? Similarly what Qualities, Traits, Habits became a hindrance in playing the role? + What is your process of Continuous Learning? How do you identify technologies/skills for learning?
+ What in your opinion are some great examples of well Architected Systems and Why? + Who are your Role Model Architects and Why? + What will be your advise to aspiring Software Architects?
I am already going through some other similar threads <https://news.ycombinator.com/item?id=23152092> but would love to hear more from the community.
by javamantra on 8/28/20, 1:41 AM
Most architectures fail at integration points. so focus on interfaces first. The way to build acceptance is to distribute ownership of various aspects of the architecture across the team
How to evaluate the architecture and your own effectiveness - The product is delivered on time and within budget
Identifying key requirements - Strength (NFRs) - Functionality - Elegance (Documentation, clean code, multiple visual models)
The architect should know the cost of building each and let stakeholders decide the priority. If the arch believes the choice is wrong he/she should challenge that but understand that politics will decide the choice. In which case document and move on.
by 1ba9115454 on 8/28/20, 8:26 AM
The best architectures come from teams not individuals. If you don't have buy in from the team, you will fail. Listen to them, some will need your help, some won't.
The boxes you draw on a white board won't survive 5 minutes when real development starts. Make sure you have used the tech yourself either previously or via a PoC before you recommend it.
Complexity is the enemy, make it simple. It's very easy to add complexity but almost impossible to remove it again once it hits production. Production turns software into concrete.
Document the team decisions in a architecture decision record. https://github.com/joelparkerhenderson/architecture_decision... This will really help the next set of developer who are trying to figure out why you did what you did.
Setup your CI/CD pipeline very early on. Make sure testing is integrated including browser testing if applicable.
by maps7 on 8/27/20, 10:14 AM
- There are many correct ways to do things
- It's all about constraints and trade offs
by rails on 8/27/20, 3:15 PM
- Trade offs, everything is a trade off
- Make desicions easy to change later