最近又看了几本关于架构的书籍，不禁回到原点：架构是什么？架构师职责是什么？
架构
在《架构与架构师2》中引用了1995年David Garlan和Dewayne Perry给出的定义：
系统的组件结构，组件的相互关系，以及管控组件设计和长期演进的原则和指导方针
十几年前，软件架构师只处理架构中的纯技术问题，像上面定义中的组件，可能是类，是包。而现在架构师承担着大量、宽泛的责任，并且范围还在不断扩大。尤其云时代，IT基础设施包括网络、数据中心、计算基础设施、存储，以及其他子系统都得考虑
贴一张思维导图来说明软件架构涵盖的范围
从图中可以看出，架构师的职责包含技术能力、软技能、运营意识及其他很多方面
所以定义架构不是件轻松的事，Martin Fowler也都拒绝尝试对架构做出定义，退而引用名言：
“架构是那些重要的东西…………无论它具体是什么”
—- Ralph Johnson
所以在行业内共识：对软件架构本身并没有一个好的定义。
虽然架构很难定义，但我们总得尝试着描述它，分解它，进而更好地运用它指导软件开发。如果说软件世界更迭速度过快，组件化定义显得太陈旧，那我们需要一种与时俱进的思考软件架构的方式
Mark Richards与Neal Ford展示了这样的思考方式
如图中所示：软件架构包含系统的结构、系统必须支持的架构特征、架构决策以及设计原则
系统结构
实现该系统的一种或多种架构风格（比如微服务、分层和微内核）
仅仅描述结构并不能完整地诠释架构，还需要了解架构特征、架构决策和设计原则
架构特征
架构特征定义了系统的成功标准，这些标准往往与系统的功能正交
在《架构与架构师》中，指出应用系统需要考虑两方面内容：一是功能性需求，二是非功能性需求。
但从语言角度来看，将一个东西命名为非功能会带来负面影响：如何说服团队充分注意“非功能性”的东西
另一个流行术语是质量属性，但它暗示的是事后质量评估而不是设计。
架构特征描述了对架构以及整个系统的成功至关重要的关注点，同时又不影响其重要性。
架构特征满足三个标准：
- 明确非领域设计的某个注意事项
- 影响设计的某些结构项
- 是否对应用的成功至关重要
构架决策
架构决策定义了一组关于如何构建系统的规则，构成了系统约束，并指导团队哪些可以做，哪些不可以做
比如在一个分层架构中，架构师可能会规定只有业务层和服务层可以访问数据库，限制表现层直接调用数据库。
设计原则
设计原则与架构决策的不同之处在于，设计原则是指导原则，而不是必须遵守的规则。
在微服务架构中，开发团队应该使用服务间的异步消息传递来提升性能。
架构定律
虽然架构范围已经大到难以置信，但统一元素仍然存在。
架构第一定律：
软件架构中的一切都是在做权衡
当架构师若认为自己发现了不需要做权衡的东西，很有可能他们只是还没有发现需要舍弃的东西而已
通过结合架构的原则、特征等，我们对软件架构的定义超越了软件结构脚手架。架构不仅仅是各种要素的组合，还体现了架构第二定律：
原因比方法更重要
架构师面对不了解的系统时，可以探明这个架构是如何工作的，但会很难解释某个选择背后的原因。
因此架构师需要去详细记录架构决策以及背后权衡的逻辑。
架构师
在之前的两篇文章中指出架构师必须要有屠龙刀还得有绣花针，需要技术+业务+管理三条腿。
总之一句话，架构师是最牛的人。可一个团队不能人人都是架构师，况且还有资深工程师，技术专家。作为架构师与他们的区别是什么呢？能力模型有什么不同呢？
决定一个人的强弱，是他的认知水平。对应技术人员就是对技术的认知。架构师的认知有四个阶段：
愚昧之巅（不知道自己不知道）、绝望之谷（知道自己不知道）、开悟之坡（知道自己知道）和持续平衡的高原（不知道自己知道），这也是架构师的认知逐步提升的过程。
如果人们对开发工程师的期望是把功能需求开发完成，那对架构师的期望就多样了
一、制定架构决策
架构师需要制定架构决策和设计原则，以指导团队、部门或者整个企业进行技术决策
二、持续分析架构
架构师需要持续分析架构和当前技术环境，然后给出改进建议。从整体上分析技术和问题域的变化，以确定架构的稳健性
三、掌握最新趋势
开发人员必须时刻关注技术更新，从而保证与这些技术与时俱进。对架构师来说，掌握最新的技术和行业趋势更为关键
四、确保决策被遵守
架构师需要确保架构决策和设计原则被遵守
五、丰富的经历和经验
架构师需要涉猎各种各样的技术、框架、平台和环境
六、具备业务领域知识
一个称职的软件架构师不仅要了解技术，还要了解问题背后的业务领域。没有业务领域知识，就无法理解业务的问题、目标和需求，也就不可能设计出有效的架构
七、具备人际交往能力
架构师需要具备出色的人际交往能力，其中包括团队合作、引导和领导力
八、了解并驾驭政治
架构师所做的几乎每个决策都会受到挑战。由于成本或工作量（时间）的增加，架构性决策将受到产品负责人、项目经理和业务利益相关者的挑战
针对以上八点，以及技术+业务+管理三项技术人普实能力，可以更简洁地概述架构师自身定制的三条腿：技能+影响力+领导力
1.技能是实践架构的基础。它需要知识以及应用知识的能力
2.影响力用来衡量架构师在项目中应用技能后给项目或公司带来多大的效益
3.领导力确保了架构实践的状态能稳步向前推进，同时培养更多的架构师
能力模型
论能力模型，与开发人员之间对技术方向的侧重有所不同。开发人员必须拥有很深的技术深度，但软件架构师必须具有非常广的技术广度才能像架构师般思考，并以架构的角度看待事物。
以知识金字塔展示世界上所有技术知识的类别，事实证明，技术人员应重视的信息类型随职业阶段的不同而不同
“已知”指代技术人员日常工作用到的技术、框架、编程语言和工具
“已知的未知”指代技术人员稍微了解或听说过，但没有掌握的技术
“未知的未知”是金字塔中面积最大的部分，指代能够完美解决技术人员面临的问题的技术、工具、框架和编程语言，但是技术人员甚至都不知道它们的存在
开发人员的早期职业生涯专注于扩展金字塔的顶端，积累经验和专业知识。金字塔顶端的知识需要投入时间才能保持专业。最终，金字塔顶的大小就是个人的技术深度。
而随着开发人员过渡到架构师角色，知识的性质也发生变化。架构师的价值很大一部分是广泛地理解技术，并且知道如何利用技术解决特定的问题。对架构师来说，最重要的部分是金字塔的顶部和中间部分
中间部分与底部交汇处的长度代表了架构师的技术广度
作为架构师，技术广度比技术深度更重要。因为架构师的职责就是根据功能做出与技术限制相匹配的决策，所以广泛了解了解各种解决方案是非常有价值的
架构师需要“博而不专”，牺牲技术深度来提高技术广度，虽然技术人都想在多个领域保持专业深度，但结果往往事与愿违，甚至无一成功。
对于能力模型为啥有区别，简单总结一下：
广度决定能找到的方法+深度决定选择方法的正确性+经验决定找到正确方法的速度
平衡编码
虽然架构师的能力模型与开发工程师有所不同，但还是需要保持动手编写代码，并保持一定水平的技术深度。
正好之前所说，不仅要有屠龙术，还要会瓷器活。
因此架构师面临的困难任务之一是如何在动手编码和软件架构之间取得平衡。
如果参与过多的编码工作，可能会陷入瓶颈陷阱。也就是当架构师在项目的关键部分（通常是基础框架代码）中拥有代码所有权并成为团队的瓶颈时，就会发生瓶颈陷阱。
避免瓶颈陷阱方法之一是将关键路径和框架代码委托给开发团队其他人员，然后着重于实现业务功能（一个服务），并且在1~3个迭代中完成。
如何保持编码能力和一定水平的技术深度呢？
一、频繁进行概念验证（POC），这种做法不仅要求架构师编写源代码，还要求架构师能够通过考虑细节来帮助验证架构决策
二、处理一些技术债或架构相关的故事问题，使开发团队腾出精力来处理关键的功能性的用户故事；或者在迭代中修复bug，能使架构师识别出存在于代码甚至架构中的问题和弱点
三、创建简单的命令行工具和分析器进行自动化来帮助开发团队完成日常任务
四、进行频繁的代码审查，通过代码审查能确保代码符合架构规则，并在团队中进行指导和辅导
总结
架构定义是件不容易的事，软件发展日异月新，架构的范围也日益扩大，进一步加据了定义架构的难度。但无论如何，我们还是有必要通过结构化思维去分析架构，进化古老的组件化定义，从架构结构、架构决策、架构特征以及设计原则四方面描述架构，继而明确架构师的职责，区别与开发工工程师的能力模型，加强“技能+影响力+领导力”三条腿能力成长，更好地服务架构。
