
Ask HN: What Learnings can you share from Being a Software Architect - anoviceuser
In my company I am going to conduct a session on &#x27;Being an Architect&#x27;. 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&#x2F;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&#x2F;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 &lt;https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=23152092&gt; but would love to hear more from the community.
======
javamantra
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.

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.

~~~
anoviceuser
@javamantra, Thanks a lot for your elaborate inputs. These are valuable
insights.

Thanks.

------
1ba9115454
My main learning as an architect for over 10 years.

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...](https://github.com/joelparkerhenderson/architecture_decision_record)
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.

~~~
anoviceuser
@1ba9115454, Really appreciate your inputs. Thanks.

------
maps7
\- No design is ever perfect

\- There are many correct ways to do things

\- It's all about constraints and trade offs

~~~
anoviceuser
@maps7, Thanks for your inputs.

Do you want to share any further insights about what factors you use to narrow
down the choices about the correct ways? Similarly how do you go about
managing the Constraints & Trade-offs - Do you change the scope? Do you
negotiate to relax the constraints etc.

Thanks.

------
rails
\- Reduce risks early on

\- Trade offs, everything is a trade off

\- Make desicions easy to change later

~~~
anoviceuser
@rails,

By "Make decisions easy to change later", do you mean, 1\. Getting the Module
structure of the system correct with well defined contracts between them so
that they can be changed, updated independently of each other.

Thanks for your inputs.

~~~
rails
To move the project forward, at some point you have to make decisions based on
incomplete information. Some of these decisions will be good, some will be ok,
and some will be completely wrong. The problem is: You only know this after
the fact, when parts of it or all of it is already implemented.

Because of this you should design for change and build a flexible
architecture. My goto technique for this is to encapsulate everything
regarding this decision into a module and put an interface around it. The
interface stays the same, the implementation can adapt. How this interface
looks like is not that important. You can build a library, it could be a REST
API or some gRPC thing, whatever. So yes, the main idea is to create well
defined contracts or interfaces (call them whatever you like), which will be
be flexible enough to adapt to different implementations.

~~~
anoviceuser
Thanks @rails. Really appreciate the clarification.

