这是我前一段时间帮公司面试解决方案架构师时的感慨。跟几位 10+年经验的技术软件架构师面试下来，感觉技术能力都很过关, 尤其是对新技术，能从架构师的角度思考问题，对架构设计有成体系的理解与输出。
但是，当我在围绕着一些比较宏观灵活的解决方案架构方法与思维上的问题时，比如：
跨领域发展的解决方案架构设计方法与模型
从模糊的商业问题或抽象的业务愿景落到解决方案的方式
如何治理解决方案架构设计，从抽象到具体的思路
我发现，多数人停留在“技术架构，或软件架构的层面。少有能做到“开放性思维”，能从商业问题的本身出发， 带领团队让“理真的越辩越明”。
为什么会这样？原因在哪里？
结合自己从工程师到企业架构师的经历，主要的原因是：构架师在解决跨领域复杂问题是的方法真的不多。这主要是因为大多数的架构师都是技术出身，他们解决问题的思维与方法主要来自之前技术领域的积累。
大多数架构师的思维模式是”专家模式“. 这种思维模式是习惯于把已熟悉的"解决方案"(比如:微服务等)对接商业问题.。这种单一视角就类似查理·芒格说的：手里拿着锤子的人，眼中满世界都是钉子。
本文旨在探讨解决方案架构设计过程的方法，原则与逻辑思想以及我将分享根据过去的经验提炼出的一套解决方案架构的方法。
该方法曾在我工作过的世界 500 强公司，国际 4 大咨询公司，以及政府部门，银行，电信，航空, 金融等行业中使用。所以，无论你已经是架构师，还是目标成为一位优秀的架构师，这篇文章都与你有关。
让我们先了解什么是解决方案架构以及从我踩过的”坑“开始。
什么是解决方案架构设计？
解决方案架构设计是使用解决方案架构师的丰富的知识与经验，从纷乱复杂的问题中，应用科学的解决方案分析方法，进行定量和确有论据的定性分析，找出企业要解决问题的核心原因，提炼能被实施的解决方案与设计架构，进而指导方案实施的过程。
需要解决方案架构师解决的问题，大多数都是是由现状和期望的差异产生的，如下图：
有人会疑惑：我拿到需求后进行确认，再进行分析设计，输出框架方案。我也不需要设计解决方案架构啊？当然。不是所有的问题和项目都需要解决方案架构设计。
在分析处理问题时，解决方案架构师会从两方面思考问题：
我要解决的是什么类型的问题？
在不同的问题类型中，由于问题本身具备不一样的复杂度，认知问题和解决问题的方式也是不同的。
一般来说，解决方案架构师会把问题分成 4 类：
Cynefin 框架-IBM 在 21 世纪初开发
对于简单（Simple）问题，一般是可预测的、可能已经有最佳实践方案，或者你已经解决过类似的问题。问题和解决方案相对稳定；有已知的解决方案。例如有已知框架模型，可复用的方法和步骤，流程，组件。
这类问题不需要解决方案架构设计。比如，给产品需要添加新功能模块。
对于繁杂类型（Complicated)的问题，一般是可预测性大于不可预测性，可能有多种可能的解决方案，但是无法确定哪一个解决方案是最佳实践。这类问题你知道存在哪些未知问题域，你需要用系统的分析过程把因果关系整理清楚，再诊断和找出适合的解决方案架构。这类问题一般是需要解决方案架构分析的。
当然，问题本身不是非常繁杂，可以进行“轻”解决方案架构设计，或者直接进入系统设计。
对于复杂问题（Complex），我们需要通过建立一系列的假设，在多个备选方案中反复对比验证，从反馈中筛选出最符合实际情况的方案架构。再把复杂问题切割成若干个简单或轻度繁杂的问题进行详细架构设计。这个过程可能长达几个月或更长。
因为对于未知的问题，方案架构分析过程就是一个学习的过程。下面是一个对复杂问题认知的模型：
在方案架构设计初期，架构师通过分析，验证，反馈学习逐步更加认真范围，最终完成架构工作。
但反之，如果框架师判断错了问题的类型，使用错误的方法，就可能会输出与问题不匹配的方案架构。
对于混沌问题，无法通过解决方案架构设计过程找到答案。这类问题只能选择解决问题的一部分，或者为问题专门设计套创新的方法。
我之前航空公司就曾经被公司要求解决过这类型的问题：如何把业务，数据和功能从一个已经跑了 60 多年的航空系统（Astral-是爱尔兰第一个 IT 系统，1960 年上线，目前还在使用中）迁移出来的方案。
1960 年,IBM1440 Astral 系统在 Aer Lingus IT 系统部
解决方案架构与问题是否匹配?
通常在一个解决方案架构设计过程中，架构师需要在 4 个层面和阶段思考架构是否匹配，如下图
1 问题与愿景需求匹配
在开始阶段，架构师需要清晰的定义问题，确保问题与愿景，需求，期望相匹配。这里还包括确定问题的类型，复杂程度等。
2 解决方案架构与问题匹配
在方案概念架构设计阶段，在多个假设或备选解决方案中，哪些是与问题相匹配。这里概念架构不需要包含太多的技术细节。概念架构应该做到对业务方人员，非技术背景人员友善易懂。这样我能确保最大程度的获得不同部门人员的参与与反馈。
这里架构师一般从 2 个基本维度去考虑问题与解决方案的匹配：
问题的复杂度与解决方案的复杂度相匹配
问题的类型与构架设计方法步骤相匹配
3 解决方案架构与企业能力匹配
在总体（或概述）方案架构设计阶段，需要确保方案架构设计与企业的能力相匹配。这个很好理解，总体架构设计需要与企业能力对齐。意思就是能做的出来，而且没有太多的阻力。
举个经典的例子，如果你的架构设计中需要使用微服务技术，容器技术支撑。但企业实际没有这些能力，要实现这些能力就会变成方案架构本身的阻力（要解决问题 A 就先解决问题 B 和 C）。在方案中解决这类能力依赖的方法有很多，本文就不具体展开。但最直接高效的方法就是尽量避免选择这类与企业实际能力差距较大的解决方案架构，选择企业能驾驭的折中架构方式。
4 解决方案架构商业运营合规匹配
商业与运营相匹配确保方案架构设计达到质量标准，能被商业使用。包括功能需求，非功能需求，运营支撑。同时，方案架构是否符合法规，政策也需要在这个阶段考虑。我踩过的解决方案架构与问题不匹配的 5 种“坑”如下图：
“坑 1”：解决方案架构只解决了部分问题，这种坑可能是最常见的。如何避免? 做好问题分析定义，在构建设计初期确保架构方案与问题匹配。
“坑 2”：解决方案架构只解决了问题的表象。而真实的问题或更深层的核心问题被忽略。如何避免? 确定问题类型，做好深入的问题分析定义。
“坑 3”：这种坑也是常见的。解决方案架构虽然解决了问题本身。但同时也生产出新的问题。 如何避免? 这种坑一般是应为架构设计质量没有把控好。
“坑 4-巨人解决方案”。这种情况会造成资源的浪费。所以，我在需要架构设计过程中对比，评估筛选不同备选方案。如何避免? 架构成本效益分析(Cost Benefit Analysis) 是一个很好的方法。
“坑 5-国足问题” 。这类坑的意思是解决方案可能就不存在。就好比有人要你去解决“中国足球”的问题，你的标准答案是-这个我做不了，能力有限。如何避免? 做好问题类型分析，避免直接去解决混乱类型的问题。
解决方案架构分析过程漏斗模型
根据上面的解决方案架构关注与思考点，我们能形成一个系统的方案架构分析过程漏斗模型。如下图：
我们先把解决方案架构过程分成 2 个域：问题域与 方案架构域。
问题域
大部分问题解决者专注于解决方案域，而容易忽视问题本身，那么问题解决的一半就已经被你丢弃了。
爱因斯坦说：如果我只有 1 个小时来解决问题，那么我将花 55 分钟在问题本身和定义它，剩下的 5 分钟来找解决方案。“
作为解决方案架构师，我觉得选择正确的方向比一个完美的技术架构重要。去筛选出有价值的问题（找到 20/80 里的 20）远比一个大而全的解决方案架构重要，因为：
不是所有问题都是真正的问题
不是所有问题都有方案
问题与问题之间本就是不平等的。抓住主要矛盾，解决关键问题
所以在问题域里，我们去定义问题，分析问题类型，搞清楚因果关系，价值与重要性，然后 输出清晰的问题陈述文档（Problem statement）。
方案架构域
在解决方案架构域里，架构师专注与分析寻找可能的备选方案架构。评估，对比筛选出可行的总体架构设计。之后，再进一步切割划分技术架构领域，输出详细的技术架构设计方案。
从技术角度来说，架构的风格有由抽象到具体。思维过程遵循：为什么做 -做什么 - 怎么做。
从业务的视角，架构的风格从初期使用业务易懂的语言到后期使用具体的技术设计语言。原因是在方案架构设计的初期，我们希望有业务知识的人员都能参与其中，提供反馈。
方案架构的概念设计的目的是与架构利益相关者的高效沟通。所以，我会避免使用软件系统架构设计语言。比如： UML，Togaf Archimate。
上面方案架构分析漏斗模型也是架构概念设计的一个例子。
这里，我希望读者能能直观的理解这个概念，达到交流的目的。如果我使用更专业的架构设计语言来呈现，这就给大多数人带来理解上的门槛。再比如，对于一个不懂建筑的人，下面哪种架构呈现方式对你更友善呢？
好的，现在我们有了漏斗模型作为概念骨架。
接下来，我们来看在骨架模型之上建立的方案架构设计体系。
企业解决方案架构设计框架
如下图：解决方案框架设计框架体系包括 3 个主要模块：
模块 1－企业解决方案框架设计方法
模块 2－解决方案架构原则。
模块 3- 解决方案架构工具箱。一些在方案框架分析设计过程中，能用得上的经典工具，方法与模型。
模块 1：解决方案框架设计方法
与上文中介绍的架构漏斗骨架模型对应，我们把架构分析设计分成 3 个阶段。
1 发现阶段
在发现阶段具体的步骤是:
1.1 确定愿景与目标
具体步骤：
清晰业务的愿景
确立项目的目标
创建业务案例（business Case）-项目立项原因，以及项目存在价值的分析。可以理解为：项目论证，项目理由，或项目价值分析。
确定效益指标-如何衡量成功或是失败
上面大部分的工作都有业务分析师和项目经理负责。但作为方案的架构设计师，我会参与其中，确保重要的信息不会被遗漏。
1.2 定义分析问题
具体步骤：
明确问题
验证问题价值以及解决的范围
问题分析（问题的类型与因果关系）。结构化梳理问题可能的原因
问题陈述文档
这些工作由业务分析师与方案架构师共同完成。业务分析师关注与业务需求，而方案架构师则要从更全面的思考.
在解决方案的范围选择上，架构师需要根据技术，时间，成本，风险等角度全面分析。确定一个问题的方案架构覆盖的范围（同时考虑深度和广度）是否合理，在预算及计划期范围限内能否实现。否则，架构师需要与业务沟通，做出取舍。
这里作为解决方案的架构师要区分一个概念：“业务想要的方案”VS ”业务需要的方案“。在解决方案的立场，架构师应该专注把“业务需要”从“业务想要“ 范围里区分开来。
一个区分的技巧就是问 “如果不… …做会怎么样?” 例如 ，“如果解决方案不提供功能 xxx，对业务有什么影响？”“如果功能 xxx 不是自动化的，需要人工处理，对业务有什么影响？” “如果功能 XXX 不能在解决方案上线的第一天出现，只能在 3 个月后才能上线. 对业务有什么影响？”
如果方案架构覆盖的范围过广，则有可能成为项目的风险。
1.3 设计方案 &假设
具体的步骤是：
确定解决方案的分析方法
提出假设
验证假设
1.3.1 确定解决方案的分析方法
根据要解决问题的实际情况来明确解决方案的分析方法和步骤，计划到底要做哪些事。
1.3.2 提出假设
在架构师探索问题解决方案的过程中，一个最重要的工具就是提出假设与验证。
建立假设的目的就是找到问题存在的核心原因。然后去证明假设的正确性。事实上假设验证不是什么新的方法，这种方法一直都在各行业中广泛使用。
举个最常见的例子，医生治病的过程就是要出的假设与验证的过程：
医生会根据病人表现出来的症状做出初步诊断 -这是提出假设
然后医生会对病人去进行各种化验，检测 -这是验证假设
在根据数据给病人确诊/确定病因 -这是确定问题的核心原因
最后根据病因提供治疗方案 - 这是提出解决方案
这个过程也是我们经常听到的 “大胆假设，小心求证，对症下药”但解决方案架构师常犯的错误就是根据过去经验，作出了过分简单假设，并经过少量的验证之后，就把它当作了问题的核心原因。
所以，我们需要一些方法帮助我们进行假设分析。结构化思维就是其中一个最常用的工具。
结构化思维就是面对问题的时候你可以通过某种结构（例如，一定的范式、流程顺序进行），把它拆解成一个个你能解决的部分。
结构化思维在这里就不展开讨论. 一些我常用的结构化思维工具有：5Why，鱼骨分析，MECE，逻辑树分析。 方法有很多，大家选择自己比较熟悉的使用就可以了。
1.3.3 验证假设
验证假设就是找到支持你分析假设结论的证据。验证假设的方法有很多，我最常使用的有：
通过数据验证假设-这种是最常见，大家都懂。
通过事实，案例 - 看看过去相同类型的问题是怎么解决的案例作为证据。例如，我们的竞争对手也是这么做的哦。
通过实验，不行做一次就这知道了。例如，软件开发的 POC
通过专家意见，还可以通过专家的意见反馈作为证据。比如我之前所在的一家科技公司做过一个非常复杂的解决方案架构，我们就是聘请第三方咨询公司对方案进行论证的。当然，这里不是教大家都去聘请外部专家或咨询公司。不要忘记，对你公司业务最了解的专家就在自己公司里面。所以，记住要善用公司里的专家资源。
1.4 概念方案架构
在验证完假设，找到问题核心原因后，我们就可以根据核心原因提出概念方案架构设计，包括：
提出概念解决方案架构设计
评估概念设计
1.41 解决方案概念架构设计
做概念方案架构时，概念方案尽量少使用技术语言。不要设置过高的理解门槛，尽量做到通俗能懂，能交流就好。 概念架构的受众主要是业务人员与解决方案的利益相关者。
概念架构的目标是推荐与”推销“概念方案与架构愿景给决策者。目的是获得决策人员与方案利益相关者对方案的认可。
所以，概念方案架构不需要提供具体的设计，只需要与业务的愿景，目标，核心问题做出对应。
例如概念方案架构不需要回应下面内容：
对业务的深入分析
解决方案架构的完整蓝图
解决方案架构的详细设计
如何满足详细需求
1.4.2 评估概念解决方案架构设计
评估概念解决方案架构设计。如果有多个备选概念设计，需要评估对比。
在实际情况中，出于节省时间的考虑，或者想敢项目进度，我们也可以把备选方案带入下一阶段的设计。在下一阶段的总体架构设计时，我们再根据更细致的分析做出对比评估后，筛选出更合适的架构。
2 架构设计阶段（总体架构与详细设计）
方案架构设计分成 2 个阶段：
总体方案架构概要设计。在宏观的角度勾勒出整体解决方案的轮廓与脉络。
详细解决方案架构设计。如果对于庞大的解决方案架构，例如跨越多个领域（如，信息与数据，基础技术，安全，服务，甚至方案会影响到多个业务应用， 甚至引入新厂商产品…）时，我们需要对总体方案进行领域分割。在对每个单独的领域进行详细架构设计。这时我们可能需要多个解决方案架构师或技术架构师共同协助完成工作。
实际情况中，不同公司会对架构设计的交付物要求不同。这里我们根据一般性的方案架构设计进行讨论。
针对于不同类型的方案架构，例如有些偏向外部用户，有的偏向企业本身，有的偏向技术领域的解决方案。下面步骤可以根据你的实际情况做加减法，步骤的次序也可以进行调整。
2.1 总体解决方案概要架构设计
具体的一般步骤是：
解决方案业务架构设计
总体解决方案架构设计
确定解决方案架构设计范围
总体解决方案架构设计可行性评估
解决方案架构规划（计划，线路图）
2.1.1 解决方案业务架构概要设计
我个人的习惯是遵循业务第一的原则，从业务架构开始。
什么是业务架构（business arcihtecture）？InfoQ 之前有一篇（The Subject and Discipline of Business Architecture）文章介绍过在这里就不多太多的解释。
从企业价值与能力视角，作为解决方案架构师我一般会关心：
价值流- 描述在企业中价值是如何创造与传递的。把企业创造价值的过程分解为一系列互不相同但又相互关联的活动，或者称之为“增值活动”。
作为架构师，我希望明白在业务的层面，解决方案架构在宏观视角将会影响价值链/价值流中哪些些环节（节点）。
从这些被方案影响的环节出发，研究哪些业务能力（business Capability）被解决方案使用，哪些业务能力将被解决方案影响或改动。这里我会使用业务能力图（business Capability Map） 帮助我进行下一步更具体的分析。例如使用类似下面的模板：
业务能力图（business Capability Map）-能帮助我了解一个企业为了创造价值而做的事情 What，而不是如何去做（其业务流程）How。目的是在业务能力的成面，我希望明白解决方案将复用和改变哪些业务能力，影响改变将在哪里发生。如下图：
业务服务（business Service) -我还希望知道解决方案会复用或影响到哪些业务服务。
从业务运营/运作视角，作为方案架构师我一般还会关心：解决方案将影响或改动哪些业务流程 。
为什么最后才分析业务流程。 这是因为业务流程相对于业务能力，业务服务，是变化比较频繁的元素。
根据解决方案架构从稳定到变化原则，和从宏观到具体的原则。我会把业务流程留到最后。还有，在总体解决方案架构阶段，总体方案也不需要对所有详细的业务流程与需求做出一一对应。
为什么我先从业务架构开始分析？
首先是因为，这些是业务部门人员能看懂，也是他们最关心的事。同时也符合解决方案设计业务第一原则。
其次，这些业务元素是相对稳定，与技术无关的。我希望解决方案是从稳定的元素开始分析，然后从稳定的元素映射到更具体变化的元素。例如下图：
所以，我一般会从解决方案业务架构入手，用 Top-down 由上而下的方法推进到总体方案架构设计。
上面的业务架构是以企业为中心的视角（即，企业需要什么）的分析方法。
根据不同的解决方案类型，例如，以用户为中心的解决方案（即，用户需要什么），方案架构师还能使用例如：
用户旅程图，event storming 等工具，分析价值流向以及在价值节点上如何调用企业业务能力,服务与流程。下图是一个用户旅程与企业服务调用的例子：
2.1.2 确定解决方案架构设计范围
根据解决方案业务架构的分析，下一步我们来确定总体解决方案架构设计的范围。
总体解决方案架构设计范围就是确定究竟哪些领域需要“变动”。解决方案架构设计范围可以参考下面架构设计范围图：
一般情况下，一个解决方案至少会影响一个以上的范围，以及改动多个企业能力。如，改变多个应用系统。
一般对应于复杂的方案架构设计方法，我们还可以使用“热力图”把变动的类型标注出来。例如：
用不同的颜色显示：添加新功能，修改已有功能，删除已有功能，迁移功能等。
用便签来提示变动的大小：XL－变动非常大， L-变动大，M－变动一般， S－变动小
2.1.3 总体解决方案架构设计
在总体方案架构设计阶段，我会根据上一步确定的解决方案范围去指导总体方案架构设计的工作。
一般会使用下面的架构设计步骤对每一个变动领域进行分析：
步骤 1：描述现状
步骤 2：描绘目标状态 -从企业已有的参考架构（reference architecture）开始，到逻辑架构（logical）再到物理架构（physical )
步骤 3：差距分析，勾勒出存在哪些差距
步骤 4：对存在的差距进行分析。对复杂度，优先级别进行评估
步骤 5：初步估算复杂度和工程大小。这里我们只能是进行粗略估算，一般我会用 T-shirt size：XL,L,M,S.XS 进行估算。
步骤 6：在变动模块之间标注依赖关系。
也可以使用其他的架构设计方法如：TOGAF ADM 方法进行设计。
2.1.4 总体解决方案架构设计评估/分析/对比
总体解决方案评估在前文已经讨论过，这里就不多做介绍了。
如果你有多个备选架构，你需要在这里进行评估： 如，可行性评估，成本效益对比评估等。 然后做出选择决定。因为我们不会再把备选方案带到下一步的解决方案规划，以及后面的详细架构设计阶段。
2.1.5 解决方案架构规划（计划，线路图）
我们还需要提供解决方案的实施规划。例如：下一阶段的领域详细架构设计架构师人员需求、工作计划、线路图 等。
同时，PM 也可以根据总体方案架构向相关实施的负责团队索要起始階段实施工作量成本初步估算（Order of Magnitude）以指导下一步项目实施计划。
2.2 详细解决方案架构设计
在详细设计阶段，总体方案已经把架构设计范围划分清楚，切割成不同的领域。
因为各自领域都有不同的特点，设计方法与设计流程也不尽相同。所以，各领域的详细架构设计在这里没法具体展开。各领域架构师通过使用总体方案架构设计，详细需求等文档进行详细设计。
3 架构评估与验证阶段
架构评估与验证阶段我们可以进行下面 2 种类型的验证：
商业运营匹配验证评估
合规性架构验证评估
3.1 商业运营匹配验证评估
商业运营评估可以进行下面验证：
详细方案架构质量评估
架构技术评估
方案架安全评估
作为总体解决方案的架构师，需要参与全部评估，确保领域详细架构设计与总体架构设计相匹配，满足功能需求与非功能需求，以及与解决方案架构的愿景一致。
3.2 合规性架构验证评估
合规性架构评估验证的范围包括：
对内合规性架构评估-符合企业的政策，原则。例如，企业架构原则，安全原则，与企业战略框架一致。
对外合规性架构评估-符合地区区域，国家，行业等的法规，政策。如果你设计一个跨国，跨洲际的解决方案架构。对外合规尤为重要。方案架构需要符合所在国家，地区，行业的方案。例如：安全法案(如：GDPR,…），个人隐私方案(PCI,… )，行业方案(PSD2…)
部分 2：解决方案架构设计原则
什么是架构原则？参考 InfoQ 这篇文章 架构设计原则的力量
下面提供一些帮助方案架构师在工作过程中做出设计决策的指导原则：
1 业务第一原则：“理解业务领域优先与理解技术领域”
理解业务的愿景，问题，痛点，需求是解决方案架构师要优先关注的事情。
2 沟通优先原则：“可理解优于大而全”
解决方案架构的首要目的是沟通和获得反馈。沟通的前提是别人愿意看/听，和看/听得懂。
业务部门人员及方案利益相关者是不会去阅读一个两百页满是专业术语的方案架构文档。架构师需要去平衡方案的专业性与可读性，用让人能懂的方式去呈现专业的技术方案。解决方案架构师的沟通做到简洁，易懂，是高段位架构师的体现。
3 建立关系，建立信任感
解决方案架构师需要花大量时间与非技术人员及业务部门打交道，包括“推销”你的解决方案，获取反馈，获得他们对你工作的支持。
这一切都建立在他们对你的信任与关系之上。信任感与关系的建立来自于你的沟通，这包括你对业务的理解，你提供的价值，你对承诺的兑现，你用适当让他人感觉舒服的方式呈现你的方案与想法，还包括让人舒服的着装与谈吐。
4 从分析稳定的开始再到理解变化
解决方案架构分析设计应该从相对稳定的元素开始入手，然后才去理解变化。
5 从宏观再到微观具体
从宏观入手，然后才去处理微观具体。
6 解决方案与问题匹配原则
解决方案与业务问题匹配优与业界领先的解决方案.
7 即时（Just in Time）、够用就好（Just Enough）
方案架构设计做到在重要的时间点上为最重要的决策者与利益相关者提供价值，够用就好。
8 80/20 原则
解决方案架构师应该去思考方案中哪些部分属于最重要的 20%。然后在必要的时候做出取舍。
部分 3：解决方案架构工具箱
下面是一些在方案框架分析设计过程中，方案架构师能用得上的经典工具。排在每类最前面的是我认为最好用或者用的最频繁的工具。
架构设计工具
白板－这是我认为最好的架构设计工具
架构研讨会 Architecture Workshop -这是我认为第二好用的架构设计工具
架构师访谈 Interview -我认为第三好用的架构设计工具
头脑风暴 -Brainstorm
架构设计建模语言工具
不需要多，用好一个就好。
Toagf Archmate 企业架构建模语言
UML
C4 模型
问题分析方法与结构化思维工具
这里许多工具都是我在咨询公司企业战略与架构分析项目中使用过的。一般公司架构师会使用一两种工具就能应付绝大多数情况。
设计思维方法工具
架构评估方法
风险管理
写在最后
实际的企业环境中，解决方案架构还会与企业架构（Enterprise Aarchitecture) 与架构治理等其他的企业架构能力互相配合。但因为文章篇幅有限，也考虑到这篇文章主要的目的是讨论可以复用的解决方案架构设计过程，方法与模型。所以，在这里不做展开。
感兴趣的朋友可以参考下图各类型架构能力间的作用关系。
作者介绍：
俞跃（Nick Yu），万事达都柏林（Mastercard）Principal Enterprise Architect(企业框架师)。在此之前，在 Aerlingus 爱尔兰航空与母公司国际航空集团 IAG 解决方案框架设计师与企业框架师，从事所在公司数字化与商业部门的解决方案与企业框架管理。更早之前，在德勤咨询都（Deloitte）从事技术，架构与战略咨询经理。曾为多家银行，多个政府部门提供解决方案框架与企业框架咨询服务。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论