In my company I am going to conduct a session on 'Being an Architect'. I have my own insights, experiences to share from playing the Architect role for 10+ years. But I thought it will be great if I can also learn from the experiences of others playing a similar role and share it with the attendees.<p>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:<p>+ 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?<p>+ 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?<p>+ 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?<p>+ 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?<p>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.
Aspect I like most: Communicate the solution. Draw lots of pictures to standard models, maintain many views to cater to different stakeholders and relentlessly communicate the solution.<p>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<p>How to evaluate the architecture and your own effectiveness - The product is delivered on time and within budget<p>Identifying key requirements
- Strength (NFRs)
- Functionality
- Elegance (Documentation, clean code, multiple visual models)<p>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.
My main learning as an architect for over 10 years.<p>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.<p>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.<p>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.<p>Document the team decisions in a architecture decision record. <a href="https://github.com/joelparkerhenderson/architecture_decision_record" rel="nofollow">https://github.com/joelparkerhenderson/architecture_decision...</a> This will really help the next set of developer who are trying to figure out why you did what you did.<p>Setup your CI/CD pipeline very early on. Make sure testing is integrated including browser testing if applicable.