Ask HN: What Learnings can you share from Being a Software Architect

7 points by anoviceuser 5 years ago | 10 comments

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.

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.

javamantra 5 years ago |

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 5 years ago | |

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

Thanks.

1ba9115454 5 years ago |

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... 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 5 years ago | |

@1ba9115454, Really appreciate your inputs. Thanks.

maps7 5 years ago |

- No design is ever perfect

- There are many correct ways to do things

- It's all about constraints and trade offs

anoviceuser 5 years ago | |

@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 5 years ago |

- Reduce risks early on

- Trade offs, everything is a trade off

- Make desicions easy to change later

anoviceuser 5 years ago | |

@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 5 years ago | | |

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.