- UID
- 120068
- 热情
- 9041
- 人气
- 10872
- 主题
- 163
- 帖子
- 4459
- 精华
- 2
- 积分
- 12334
- 分享
- 0
- 记录
- 0
- 相册
- 0
- 好友
- 3
- 日志
- 0
- 在线时间
- 6239 小时
- 注册时间
- 2010-7-12
- 阅读权限
- 30
- 最后登录
- 2022-6-28
升级 46.68% - UID
- 120068
- 热情
- 9041
- 人气
- 10872
- 主题
- 163
- 帖子
- 4459
- 精华
- 2
- 积分
- 12334
- 阅读权限
- 30
- 注册时间
- 2010-7-12
|
本帖最后由 ctai010 于 2015-4-14 21:36 编辑
Hi. Sorry for slow response.
Firstly IT architect is a very generic title, in some cases architect is no different to senior developer. And there is some very specialised architect roles out there where you are only expected to work on a very specific area / project.
So architect don't 'need' to know a bit for every domain. But the more you know the better, software solution is rarely isolated in one domain (at least in enterprise context).
Generally speaking, because you are the architect, people will expect you to know everything and have a solution for every problem. Sometimes you’ll get put under spotlight and expected to solve the problem instantly. Have multi-domain knowledge maximise your chance to do well. If you are able to consistently resolve problems quickly and effectively, you’ll quickly earn respect in the organisation and build a reputation among your peers. So to answer your question, how far you need to understand? You need to understand to a extend where:
1. Able to design the solution where you can justify that it will work (regardless it's single domain or cross domain) and able to convince business to spend big money on your solution. You may get challenged from all angles, technical, financial, future-proof, architectural elegance, and general good software engineering principles and design patterns.
2. When something went wrong, you can jump into the shit hole, find the root cause of the problem and come up with a idea to fix it. In a ideal world Architect just give instructions and let the dev/op team to fix it. But we don't' live in a ideal world, sometimes architect need get hand dirty and fix it yourself. So both development and OS / Unix skills is extremely handy.
Now, even if your role is, for example, WCM Architect. But when you work closely with Project Manager / Business owner / Senior manager, they don't know (or care) about any technical details. If there's a problem, they'll expect you to fix it, end of story. And for instance if you are able to trace the problem to integration layer, in a perfect world you should able to just hand over this problem to integration team and they should be responsible to fix it. But again, we don't live in perfect world.
Sometimes the downstream team can be extremely unhelpful for all sort of reason. If you also know a lot about integration, you'll able to spell out to them exactly what went wrong, where is it happening, proof that this is their fault, and how to fix it. This way you'll make your PM happy, and earn respect in the organization.
Having said that, the soft skills of how you handle the problems is actually more important. If you have the ability to handle tough situation with ‘silky smooth’ response, you’ll also do well as architect. An essential skill for top architect is able to make everybody feel the problem is solved, but actually we are still in square one - nothing is resolved. And the sad truth is talker actually progress further than doer. So there will be people just talk their way to a very high level role without any real skill / knowledge. That's just life. |
|