技术架构是对某一技术问题（需求）解决方案的结构化描述，由构成解决方案的组件结构及之间的交互关系构成。广义上的技术架构是一系列涵盖多类技术问题设计方案的统称，例如部署方案、存储方案、缓存方案、日志方案等等。企业架构中的技术架构聚焦在对业务、应用、数据等上层架构设计意图的开发实施方案的结构化描述。
一、技术架构元模型
1、架构模式元模型
架构模式模型引入模式分析视角，对上层架构设计意图、问题进行分析建模，目的是快速、准确定位设计和复用技术方案。架构方案模型是描述技术架构设计的核心元模型，包含三个主要核心元素。基于平台型企业架构技术设计的特征，我们使用了平台、服务、组件这三个层次递进的元素对技术架构进行建模。架构策略模型是为了约束和规范架构设计过程，保证架构设计遵循企业整体的架构设计愿景与需求，符合企业整体的架构设计原则与规范，是对于架构设计过程本身的约束和指导。1、富技术时代做好平台型技术架构设计面临的问题
新技术的涌现和不断成熟，及技术工具的极大丰富；在平台型技术架构的设计中，作为多业务条线、多应用、多数据场景落地的技术基座，技术架构设计所需覆盖的规模、应对的复杂度今非昔比，面临一系列的问题与挑战。（1）对于架构需求把握不足或者没有架构需求的分析意识，过早的进入架构设计，导致系统复杂度变高甚至过度设计，为开发落地带来额外的研发成本。（2）架构设计采用的技术和工具过于超前，超出团队成员技术水平，造成落地难度高，新成员上手速度慢，进而对整体进度和实施效果造成影响。（3）架构设计过程时间长，完成后团队就不再愿意对设计方案继续调整和迭代，当技术发展变化很快时，设计完成时方案已经过时。富技术时代下，做好平台型技术架构设计的关键是：
• 系统性的分析架构需求
• 结构化的设计架构方案
• 沉淀可复用的架构经验
由于缺少前期对架构设计需求的系统性分析，而且架构质量与设计者经验密切相关，而经验的传递成本很高，架构决策过程中的信息基本都被丢弃，只留下架构设计结果，导致架构最终难以演进和迭代。问题和上下文是对上层架构设计输入的分析和解读。问题描述了架构需求背后要解决的实际问题是什么，例如业务中台中如何保证前台获得一致的服务等级承诺（SLA）。上下文描述了与问题相关的背景信息，例如问题产生的背景是什么，需要考虑什么样约束条件，期望达到什么样的效果等等。模式是通过对问题和上下文的分析，快速映射到的业界或企业内的最佳实践。模式是解决某一类问题的方案原理的总结，通过模式技术人员可以快速构成对问题及方案背后原理的理解，在问题不变时，模式具有相对的稳定性，是沉淀技术知识的最佳形式。决策描述了在模式的基础上，引入与具体架构方案设计相关的影响因素后，形成的符合满足架构建设需求的技术类决策，决策的描述方式可以是决策树或决策表。对决策的建模有助于使企业建立起规范的技术决策管理，规范化决策过程及决策内容，是企业构建可演进式的架构治理能力的关键。通常决策的影响因素包括来自顶层设计的 IT 技术战略、架构策略、技术选型、跨功能需求、IT 实施方法等。通常使用问题、上下文对上层设计意图进行系统性的分析后，得到的问题如果准确，那么它在业界往往已经存在成熟的解决方案模式可以参考。架构模式元模型的价值是帮助企业识别和利用已经成熟的最佳实践，提高架构设计质量，降低架构设计成本。我们以上面提到的中台如何提供一致的服务等级这个问题为例，经过分析，背后的技术问题定义是如何处理接入前台之间的跨功能需求（安全、存储、性能、可靠性等）隔离问题，由此可以快速确定对应的基础架构是多租户（Multi-tenancy）架构。
多租户架构在业界有标准化的成熟模型可以参考，因此我们可以将其作为参考架构，再结合上下文中的需求背景做架构细化，最后引入技术策略模型进行技术选型、实施规划等方面的技术决策，产出最终技术架构方案。
在设计时对元模型的主要考量因素有：
架构元素的职责明确且易于理解
架构元素的职责之间相互正交
架构元素之间存在清晰可辨的层次关系
技术组件用于描述技术服务的实现，是可部署的物理组件，例如可运行的软件系统或构建打包后的应用组件，技术组件通过架构模式的决策元素，与技术选型进行关联。
技术服务 Service
技术服务用于描述实现上层架构设计意图所需的技术能力（或功能），例如网关、防火墙、数据存储、缓存等。技术服务属于逻辑模型，作为一种对服务能力的描述，与之相关的 SLA 等跨功能性需求会同时作为其参考描述信息。
技术服务的价值在于将上层架构中的技术需求与实现相分离，以保证架构设计的稳定性和实施上的灵活性。在技术架构治理中，技术服务是企业 IT 的核心能力对外的重要展现形式，也是 IT 的核心资产之一，从技术服务的角度实施管理将有助于提升企业整体 IT 服务水平。技术平台 Platform
技术平台是用于描述由一组技术服务构成，提供解决特定技术领域能力的逻辑模型，它主要用于从更高的层次对技术服务进行管理，简化架构参与者对复杂架构的理解和使用，统一对用户提供一致的SLA 服务承诺。技术架构中的复用涉及两个方面：
1. 通过技术组件、平台提供可共享的技术服务
2. 架构设计过程中产生的可重复利用的技术知识
技术服务共享在企业中已经通过 IaaS、PaaS 等技术平台得以实现，在最后一个实践中，我们要关注的问题是技术知识的复用。
通过元模型可以看到，架构设计的产出物包含结果产出物和过程产出物。结果产出物的价值主要体现在对建设实施的指导，而过程产出物则代表了对问题、方案的思考分析过程，其价值主要体现在技术知识传递环节，在知识管理领域中 “渔” 比 “鱼” 价值更高。
架构方案 = 模式( 问题，上下文，决策)
因此在一个架构设计中，问题、上下文、决策都是变量，只有模式是稳定的。
