Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Independent of being an architect, it will make sense to clarify what your authorities/responsibilities are. What are the expectations from your colleagues and bosses?

Is your role more a consulting one, because the teams should have a high degree of autonomy? Or are you held personally responsible for the (architectural) decisions, and therefor should have the authority to take the decision (which doesn't mean, you should not consult others).

What is/should the "border" of your personal responsibility starts, and where is it more consulting?

Do you only define (or facilitate to define) the top-level architecture, or are you responsible for a complete top-down design of the software?

Are they hoping for a detailed structured approach going even into the teams? Or "only" someone keeping an eye on the big-picture / having a long-term vision? Or all of the above and more?

So, in a way, the same steps to take as an architect in software. First find all the stakeholders involved (bosses & colleagues), gather their requirements (what do they _really_ want from you), facilitate an agreement between the stakeholders about the outcome (chances are, they too many and even conflicting things). Then you should also be closer to know, what you need to learn.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: