架构师日志

架构的视角每个人都不一样，可以说一万种眼光，有业务架构、安全架构、平台架构、数据架构，各不相同，这里仅是我的一家之言。

《软件系统架构:使用视点和视角与利益相关者合作》，里面提到的理念也是这样说：系统架构的目标是解决利益相关者的关注点。

• 每个系统都有一个架构
• 架构由架构元素以及相互之间的关系构成
• 系统是为了满足利益相关者（stakeholder）的需求要构建的
• 利益相关者都有自己的关注点（concerns）
• 架构由架构文档描述
• 架构文档描述了一系列的架构视角
• 每个视角都解决并且对应到利益相关者的关注点。

架构系统前，架构师的首要任务是尽最大可能找出所有利益相关者，业务方，产品经理，客户/用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。架构师常犯错误是漏掉重要的利益相关者，沟通不充分，都会造成架构有欠缺，不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的，比如管理层（可管理性）vs技术方（性能），业务方（多快好省）vs 技术方（可靠稳定），这需要架构师去灵活平衡，如何平衡体现了架构师的水平和价值。

关于架构的第二点定义是说架构主要关注非功能性需求（non-functional requirements），即所谓的-abilities。

没有监控或者监控不完善的系统相当于裸奔。

收集->测量->调整->闭环重复，在有测量数据和反馈的基础上，系统、应用、流程和客户体验才有可能获得持续的提升和改善，否则没有数据的所谓改进只能靠拍脑袋或者说猜测。

第三条道路，鼓励勇于承担责任，冒险试错和持续提升的文化。这点是最难的，一般和企业人才密度有关。工具，技术，流程只是一个公司的冰山浮出水面的部分，而真正对企业效能影响大的则是冰山水下的部分，即企业的人和文化，架构师作为技术和架构的布道者，有责任义务鼓励和推动试错文化。

架构师要深入领会这三条道路，关注整个价值交付链的效率，关注每个环节的闭环反馈，鼓励和推动公司的试错文化，打造全系统的闭环架构（Architecting for closed loop feedback），提升整个系统效能。下图的DevOps和每日交付是每一个互联网系统架构师的梦想和努力的方向。

推荐一个本书《软件架构师的12项修炼》，这书中三个观点很值得每个架构师学习领会:

• soft skills are always hard than hard skills，软技能比硬技能难
• choosing relationship over correctness ，注重关系重于谁对谁错
• 架构的政治性，在中大型公司里混的架构师尤其要学习

政治指的是和他人协作将事情搞定的艺术，架构是一种社交活动，在技术的世界里，个人主义很容易被打败，即使你的目的是好的技术是最优的，技术决策是政治决策（technical decisions are political decisions），一个技术产品，一波人可以做，另一波人也可以做，到底谁做的好，真不好说，不管谁做，都给业务套上了一副手铐。

架构师如何提升？实战，实战，实战！规划职业，找好的团队和项目，总结分享，学习GitHub开源项目，尽可能参与和开创自己的开源项目和产品，并长期积累。

主要争议是两个话题：

• 技术和业务的关系。
• 架构师要写代码吗？

架构师怎么回答这类问题？一个成熟架构师的口头禅：视情况而定，不一定，是也不是，it depends。技术和业务，架构师要理解业务吗，看产品和客户，如果是业务性产品，肯定要理解业务，如果是技术型产品，就不一定。

架构师要写代码？也不一定，个人觉得尽可能要写，如果你写过十年以上代码了，每年不少于2万行，都玩通了，可以不写。另外架构师如果写代码，要把控度，不要一头钻入代码，花大量时间解决细节和复杂性问题，忽视全局和系统性问题。

 

来源