架构设计系列文章，请参见连接。
0. 背景
想成为架构师或者已经是架构师的同学有没有问过自己一个问题：为什么你是架构师？其实就是问问自己为什么想成为架构师，是不是真的是一个架构师？架构师只是一个称呼，并不是你拥有了这个称呼就是架构师了。最主要的问题还是架构师和其他岗位同事的思维模式是有质的区别的。
很多公司为了职级的完整性而定义的架构师，技术专家到底是不是同一个概念？在某些时候授予了一些人，做了一些事可以认为他们就是架构师了吗？我们这里讨论和追逐的真理是你自己本身认为你是个架构师，而不是外部的授予。
本文主要从几个方面为什么你是架构师：
- 为什么你是架构师？
主要以排除法说明什么岗位的同事并不是架构师。 - 架构师的目标与定位
架构师以什么作为目标和责任来帮助团队完成系统研发工作。 -
架构师的思维方式（重点）
架构师最主要的与其他人不同的点。 - 架构师的执行力（架构师落地的过程）
架构师要有自己的执行能力，去具体的落地架构设计以及解决落地过程中的问题。 - 架构师的沟通能力（架构师核心的说服力）
与团队，上级之间沟通推行架构设计中的目标。
1. 为什么你是架构师？
架构师不是框架师、不是算法工程师、不是高级程序员、不是项目经理。架构师与这些岗位的同事有着很多共同点，导致很多在软件行业从业多年的人都分不清他们之间的区别。本文从不同点出发说明架构师的特点。
1.1 架构师并非框架师
框架和架构的区别大家都是知道的，可以说框架也是有架构的。并且框架的问题域中有一个问题是怎么解决业务软件开发过程中的架构问题。所以说，框架影响着架构但框架并不是架构。因为架构中除了框架外还有中间件、组件需要由架构师来处理，描述框架、中间件、组件等之间的关系是架构设计过程中技术选型内的一部分。
对框架的架构进行设计与演进也是架构师的工作，就现在来说软件开发基础设施的开发团队很少，并且软件框架的架构设计技术了解的人也很少。所以，可以认为框架只不过是一种特殊的软件，它解决的是软件开发与运行阶段的问题。
可以说对于架构师来说，框架只不过是一种特殊的软件，就看要实现的软件是框架、中间件、组件还是业务软件根据软件所处领域的不同进行针对这个领域中的问题进行分析和解决即可。
1.2 架构师并非算法工程师
随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。
--《An Introduction to Software Architecture》卡内基·梅隆大学的 Mary Shaw 和 David Garlan，1994 年
在我之前的文章中架构设计00-架构师知识体系10-对软件认知层次的思考中有详细的说明代码是由数据结构和算法组成的，在代码之上还有程序、软件、系统、平台、企业架构这几个层次。所以，算法是组成软件系统不可或缺的内容，但算法在软件系统中绝对不是主角。
根据上面mary和david所描述的由于软件规模在不断的扩大，架构更多的工作用来解决规模问题。而不是算法和数据结构问题。
1.3 架构师并非高级程序员
架构设计的关键思维是判断和取舍， 程序设计的关键思维是逻辑和实现。很多程序员在转变为架构师后，很难一开始就意识到这个差异，还是按照写代码的方式去思考架构，这样会导致很多困惑。--李运华《从零开始学架构：照着做，你也能成为架构师》
架构设计与软件编程一样，有很多中模式、方法。具体使用那种模式、方法进行实施工作并不是确定的，这样就会有优化的架构和粗陋的架构，优秀的代码和低劣的代码之分。而对于架构师来说设计模式、架构模式、架构风格在实践中的运用就成为了判断架构师能力的最基本方法。优秀的架构师可以让这些有机的结合并高效的解决问题。而高级开发能写清楚设计模式已经很不错了。造成这个的区别就在于决策方式与过程的不同。
1.4 架构师并非项目经理
项目经理的职责是让软件能够在有限的资源与时间的情况下保质保量的交付。而架构师为这个过程提供技术支持让软件能够平顺的落地。所以架构师必须懂软件过程过程管理，但并不是实际操作这部分内容。
1.5 架构师并非运维工程师
很多架构师都是运维出身的，这是不争的事实。不过像架构师不是高级开发一样，运维工程师成为架构师之后也需要思维上的转变。需要从原先的以系统稳定、系统性能、系统安全而努力，转变为整个系统支撑、提供可行的解决方案。
2. 目标与定位
明确了哪些不是架构师，这里再说明哪些是架构师应该持有的理念。作为架构师实际的、落地的工作是很重要的，但应该要想清楚在实际的设计与落地过程中我们为什么这样做。应该抱着怎样的理念去推进我们的工作。
2.1 定位：业务与技术之间的桥梁
软件架构设计的最终目标就是跨越业务需求与软件实现之间的鸿沟，而在跨域这个鸿沟需要做的就很多。需要想尽一切办法满足业务与非功能需求的同时，还要让实现团队能够接受设计中的复杂度，以实际可行的方式设计出架构实现路径才能有益的沟通业务团队与技术团队。
2.2 目标：
就像之前评价一个公司的层次一样：有理想、有目标、有原则、有方法，理解清楚通过具体化的目标来实现定位中的内容这样层次递进的方式来逐步的细化来提高可行性。
通过适度设计来制定更加贴近实施过程的设计，并尽量的做到以推迟决策，快速决策的方式推进实施工作。以控制复杂度来理清业务与技术的复杂度，并以合理有效的方式解决实现过程中的复杂度。做软件研发只有一个目标就是提供有价值的软件，而有价值的软件就必须从架构的角度服务软件研发过程。
-
适度设计
在马丁富勒的《设计已死》已经说明了适度设计的重要性。 -
控制复杂度
在张逸老师的《解析领域驱动设计》中复杂度的来源有：规模、结构与变化。并且详细阐述了应对方法。 -
服务于软件研发过程
保证架构设计中的元素是可以被拆分与执行的。这一原则代表着我们可以小步的交付与验证软件。最主要的也是快速交付，交付有效的软件。
2.3 达成目标的方法
-
接受现实
接受自己的平凡，接受自己做的事情的平凡。我们绝大多数人都是智力平凡、能力平凡、精力平凡的人。不要认为别人做不成的事我自己上手就绝对能做成，在平凡人做成别人做不成的事只有一个原因就是比别人更加细心更加专业才能做成他们做不成的事情。
巧妇难为无米之炊，有投入才有产出。只有在有实际投入的时候才能有产出，这句话大家都知道但是并不是所有人都能接受。需要接受它并不是相信你可以打破它。就想很多三角不可能一样，有很多人想破解它但是从理论角度已经证明不可能的事情是不可能破解的。
罗马不是一天建成的，冰山之下才是关键。接收干起来比看起来要复杂的多也是很多人无法预先估计也无法估量的事情。但是对于我们来说需要接受，并通过方法论来明确它即可。 -
消除不确定性
从软件实现的角度来看不能有模糊的内容，因为模糊了就没有办法去写代码。对于架构来说可以模糊，因为不确定的内容可以推迟决策。所以从三个角度来消除模糊、不确定的说法：业务需求，技术需求，管理过程。这里所有的不确定性都可以使用SMART原则来解决。 -
降低业务和系统的复杂度
复杂的事情对于人的认知，解决方案的制定都是问题。所以简化、降低复杂度是对问题更好的应对方式，以简化和降低复杂度为理念去实施才能真正的落地。对于这方面可以参照领域驱动设计中的问题域与解决域之间的关系。 -
为团队服务的理念
在管理铁三角上只有时间和范围的调整，没有质量的调整。为软件能够按质按量的开发并上线就得考虑进入就得保证有完整的RoadMap来保证实施过程。
3. 思维方式
只有细节没有整体，只有整体没有细节的。并不能很好的说明你是一个架构师的思维方式。以《金字塔原理》的方式来系统的认识一个软件需求才能做出有效的决策。
3.1 解决问题的方法
解决问题必须要明确问题，批判思维中有很多深入挖掘问题并分析问题的方法。在定义好问题空间之后，对于问题空间的解决办法就如《恰如其分的软件架构》中所给出的解决方案：
-
分解
分解可以解决问题如下：1. 有没有应对未知问题的方法？2. 对于软件系统的业务与技术进行系统性的认识才可以进行决策。片面性的？ 3. 在开发过程中与运行过程中怎样使用技术？ -
抽象
抽象可以解决的问题如下：1. 对于业务的事务脚本式的写法来说，怎么抽象出事务脚本中流程式的实体与关系？2. 高内聚、低耦合在不同级别上应该怎么实现？ -
知识/经验
知识可以解决的问题如下：1. 最新的就是最好的吗？
3.3 从“问题”开始，而不是“技术”
技术人员对于新技术的都有着一种与身俱来的激情，总是乐于去学习新技术，同时也更有激情去使用新技术。但是这也同样容易导致一个通病，就是“当我们有一个锤子的时候看什么都是钉子”，使用一些不适合的技术去解决手边的问题，常常会导致简单问题复杂化。
技术只是解决域中的解决工具而已，在针对不同的业务问题选择不同解决工具是架构师的基本能力。很多时候这个问题都会被导致，有什么样的技术可以解决我现在与到的问题，如果解决不了业务问题就不实现了。这其实是一个知识陷阱，从开发转为架构师时一个很重要的问题就是超越这个问题并解决这个问题。
3.2 方法论
作为中层来说并不是简单的执行命令就可以成为一个好的架构师，需要有自己的决策过程与决策方法。并在决策和解决问题这两个能力上保持有有效可实现的方法。
使用金字塔原理 + DDD + 分解/抽象/知识可以解决问题，再配合例如：SMART、PDCA、SWOT、5W2H等方法来分析问题就可以将分析到解决了。但是决策并不是一件容易的事，我在做决策是一般的流程如下：
- 系统性了解业务然后才能进行决策。**
- 分析系统中各个点的重要性与优先级。
- 根据分析结果进行权衡过程。
- 给出解决方案并给出决策理由，并制定备用方案与决策理由。
这个过程就需要根据团队的情况、业务的情况、技术的情况等进行问题list的制定并解答。来进行决策，问题例如：
- 在团队现状的情况下，怎么让这个团队可以按照时间点实现出来？
- 复杂业务是不是可以进行化简或者简约化？
- 性能问题是否可以通过某项技术彻底解决，还是通过多项技术组合来解决？
4. 执行力（知道怎么落地）
做了架构设计之后要能将架构落地，落地了才是好架构。所以，在落地过程中需要保证实现的内容是按照设计走，并且能够很好的按照实现路径进行实现。在这里经常与到的两个问题：
-
做正确的事，而不是容易的事。
例如：不要让混乱的、坏味道的设计在一个组件中因为各种原因传递到其他组件中。 -
步子迈的太大，是不是会扯到“淡”。
计划可以很小，落地。不能因为压力就在没人，没资源的情况下就赶着上线。
5. 沟通能力
对上要有目标与过程，对下要有逻辑与实现。这样才可以落地软件目标。沟通的一般原则是坦诚，不带任何歧视，有逻辑性，分优先级，对事不对人。在逻辑通顺，保持简单，可用很难的情况下需要说明情况并让团队达成共识。
6. 总结
君子和而不同。认识到一件事不同的侧面理解出来的内容是不同的，但以落地实现就为目标既可以达到我们最终目标即可。所以，可以容下别人的意见与建议并推动实现的发展才是好的实现。
真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起井发挥出最大功效，井且能够快速落地。这也是很多 BATJH (百度、阿里巴巴、腾讯、京东、华为)出来的架构师到了小公司或创业团队反而做不出成绩的原因，因为没有了大公 司的平台、资源、积累，只是生搬硬套大公司的做法，必然会失败。
7. 参考：
如何从架构图开始让架构设计平滑落地
为什么需要关注软件架构
上班第一周，怒怼CTO
微服务架构及设计模式
开发者需要知道的有关软件架构的五件事
你是个软件架构师吗？
一位架构师的感悟：过度忙碌使你落后
