遥不可及|每个架构师都在研究的康威定律，程序员进阶路上，你思考过吗？背景今天的分享主要来自我之前的工作经

背景今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构，之前的工作过的公司eBay、携程、唯品会都是平台型互联网公司，所以今天主要带着平台架构视角和大家分享心得体会。架构的视角每个人都不一样，可以说一万种眼光，有业务架构、安全架构、平台架构、数据架构，各不相同，这里仅是我的一家之言，欢迎大家加入『聊聊架构』社群参与讨论。今天聊的话题主要包括以下几点：

我对架构定义的理解
架构的迭代和演化性
构建闭环反馈架构（Architecting for closed loop feedback）
谈谈微服务架构和最新主题
架构和组织文化关系
架构师心态和软技能
我对一些架构师争议主题的看法

我对架构定义的理解大概在7~8年前，我曾经有一个美国对口的架构师mentor ，他对我讲架构其实是发现利益相关者（stakeholder），然后解决他们的关注点（concerns），后来我读到一本书《软件系统架构:使用视点和视角与利益相关者合作》，里面提到的理念也是这样说：系统架构的目标是解决利益相关者的关注点。

这是从那本书里头的一张截图，我之前公司分享架构定义常常用这张图，架构是这样定义的：

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

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

这个是我上次公司内分享的一个图。

这个是slideshare一个ppt里头截取的，两个图都是列出了架构的非功能性关注点；关于架构的水平该如何衡量，去年我看到一句话，对我影响很大。
Architecture represents the significant design decisions that shape a system, wheresignificant is measured by cost of change.