技术架构是对某一技术问题 (需求)解决方案的结构化描述，由构成解决方案的组件结构及之间的交互关系构成。广义上的技术架构是一系列涵盖多类技术问题设计方案的统称，例如部署方案、存储方案、缓存方案、日志方案等等

(资料图)

企业架构中的技术架构聚焦在对业务、应用、数据等上层架构设计意图的开发实施方案的结构化描述。我们希望结合当前企业数字化建设的主流趋势和新技术成熟普及的大环境，阐述我们对技术架构设计的观察及思考。

技术架构元模型是对技术架构组成要素的抽象建模，用来定义用于结构化描述架构设计的模型元素技术架构元模型的定义需要满足当今企业数字化建设的实际需要

为了适应当今企业对技术架构的描述需求，我们在经典企业架构框架方法的基础上对技术架构元模型进行了补充扩展，内容主要由架构模式模型、架构方案模型、以及技术策略模型组成。

模式分析是快速认识问题本质以及经验复用的有效实践，我们在元模型内容中增加了架构模式模型引入模式分析视角，对上层架构设计意图、问题进行分析建模，目的是快速、准确定位设计和复用技术方案。

架构方案模型是描述技术架构设计的核心元模型包含三个主要核心元素。基于平台型企业架构技术设计的特征，我们使用了平台、服务、组件这三个层次递进的元素对技术架构进行建模。

架构策略模型是为了约束和规范架构设计过程，保证架构设计遵循企业整体的架构设计愿景与需求符合企业整体的架构设计原则与规范，是对于架构设计过程本身的约束和指导

需要说明的是，架构策略模型同样适用于业务架构.应用架构和数据架构部分，例如企业级的数据标准就属于架构策略元模型的规范对应的内容

受益于新技术的涌现和不断成熟，及技术工具的极大丰富，技术架构设计的灵活度和效率都得到了显著提升。另一方面，在平台型技术架构的设计中，作为多业务条线、多应用、多数据场景落地的技术基座，技术架构设计所需覆盖的规模、应对的复杂度今非昔比。加之“富”技术条件的加持，一个好的技术架构设计的困难度实际上指数级增加。而一直以来本质上是强依赖架构师的经验和能力的技术架构设计方法和过程，在这样的语境下，一系列挑战和问题再次凸显:

对于架构需求把握不足或者没有架构需求的分析意识，过早的进入架构设计，导致系统复杂度变高甚至过度设计，为开发落地带来额外的研发成本

架构设计采用的技术和工具过于超前，超出团队成员技术水平，造成落地难度高，新成员上手速度慢，进而对整体进度和实施效果造成影响

架构设计过程时间长，完成后团队就不再愿意对设计方案继续调整和迭代，当技术发展变化很快时，设计完成时方案已经过时

因此，富技术时代下，做好平台型技术架构设计的关键是:

系统性的分析架构需求

结构化的设计架构方案

沉淀可复用的架构经验

很多由不良架构引发的问题现象，分析背后的核心因素时，都指向了一个关键原因，即缺少前期对架构设计需求的系统性分析。当技术团队被问到为什么使用某种设计思路为什么使用某种技术组件时，得到回答往往跟其自身的主观经验有很大关系。

问题和上下文是对上层架构设计输入的分析和解读。问题描述了架构需求背后要解决的实际问题是什么，例如业务中台中如何保证前台获得一致的服务等级承诺 (SLA) 。

上下文描述了与问题相关的背景信息，例如问题产生的背景是什么，需要考虑什么样约束条件，期望达到什么样的效果等等。

模式是通过对问题和上下文的分析，快速映射到的业界或企业内的最佳实践。模式是解决某一类问题的方案原理的总结，通过模式技术人员可以快速构成对问题及方案背后原理的理解，在问题不变时，模式具有相对的稳定性，是沉淀技术知识的最佳形式

决策描述了在模式的基础上，引入与具体架构方案设计相关的影响因素后，形成的符合满足架构建设需求的技术类决策，决策的描述方式可以是决策权或决策表。

对决策的建模有助于使企业建立起规范的技术决策、管理，规范化决策过程及决策内容，是企业构建可演进式的架构治理能力的关键。通常决策的影响因素包括来自顶层设计的 T 技术战略、架构策略、技术选型、跨功能需求、T 实施方法等

通常使用问题、上下文对上层设计意图进行系统性的分析后，得到的问题如果准确，那么它在业界往往已经存在成熟的解决方案模式可以参考。架构模式元模型的价值是帮助企业识别和利用已经成熟的最佳实践，提高架构设计质量，降低架构设计成本

我们以上面提到的中台如何提供一致的服务等级这个问题为例，经过分析，背后的技术问题定义是如何处理接入前台之间的跨功能需求 (安全、存储、性能、可靠性等)隔离问题，由此可以快速确定对应的基础架构是多租户(Multi-tenancy)架构。

多租户架构在业界有标准化的成熟模型可以参考，因此我们可以将其作为参考架构，再结合上下文中的需求背景做架构细化，最后引入技术策略模型进行技术选型、实施规划等方面的技术决策，产出最终技术架构方案.