现代企业架构框架： https://mp.weixin.qq.com/s/SlrEu0_t0slijrNZ6DP4Ng
业务架构： https://mp.weixin.qq.com/s/zQCjiHuxFvAg5QiOAuLAcQ
应用架构：https://mp.weixin.qq.com/s/HGRcbtq9E4j8ZuSpw3LFrQ
数据架构：
https://mp.weixin.qq.com/s/j4YawjKVHO7cfpeXEDr78w
技术架构是对某一技术问题（需求）解决方案的结构化描述，由构成解决方案的组件结构及之间的交互关系构成。广义上的技术架构是一系列涵盖多类技术问题设计方案的统称，例如部署方案、存储方案、缓存方案、日志方案等等。
企业架构中的技术架构聚焦在对业务、应用、数据等上层架构设计意图的开发实施方案的结构化描述。我们希望结合当前企业数字化建设的主流趋势和新技术成熟普及的大环境，阐述我们对技术架构设计的观察及思考。
6.1 技术架构元模型综述
技术架构元模型是对技术架构组成要素的抽象建模，用来定义用于结构化描述架构设计的模型元素， 技术架构元模型的定义需要满足当今企业数字化建设的实际需要。
为了适应当今企业对技术架构的描述需求，我们在经典企业架构框架方法的基础上对技术架构元模型进行了补充扩展，内容主要由架构模式模型、架构方案模型、以及技术策略模型组成。
6.1.1 架构模式元模型
模式分析是快速认识问题本质以及经验复用的有效实践，我们在元模型内容中增加了架构模式模型， 引入模式分析视角，对上层架构设计意图、问题进行分析建模，目的是快速、准确定位设计和复用技术方案。
6.1.2 架构方案元模型
架构方案模型是描述技术架构设计的核心元模型， 包含三个主要核心元素。基于平台型企业架构技术设计的特征，我们使用了平台、服务、组件这三个层次递进的元素对技术架构进行建模。
6.1.3 架构策略元模型
架构策略模型是为了约束和规范架构设计过程，保证架构设计遵循企业整体的架构设计愿景与需求， 符合企业整体的架构设计原则与规范，是对于架构设计过程本身的约束和指导。
需要说明的是，架构策略模型同样适用于业务架构、应用架构和数据架构部分，例如企业级的数据标准就属于架构策略元模型的规范对应的内容。
6.2 技术架构元模型应用
6.2.1 富技术时代如何做好平台型技术架构设计
受益于新技术的涌现和不断成熟，及技术工具的极大丰富，技术架构设计的灵活度和效率都得到了显著提升。
另一方面，在平台型技术架构的设计中，作为多业务条线、多应用、多数据场景落地的技术基座，技术架构设计所需覆盖的规模、应对的复杂度今非昔比。加之“富”技术条件的加持，一个好的技术架构设计的困难度实际上指数级增加。而一直以来，本质上是强依赖架构师的经验和能力的技术架构设计方法和过程，在这样的语境下，一系列挑战和问题再次凸显：
- 对于架构需求把握不足或者没有架构需求的分析意识，过早的进入架构设计，导致系统复杂度变高甚至过度设计，为开发落地带来额外的研发成本
- 架构设计采用的技术和工具过于超前，超出团队成员技术水平，造成落地难度高，新成员上手速度慢，进而对整体进度和实施效果造成影响
- 架构设计过程时间长，完成后团队就不再愿意对设计方案继续调整和迭代，当技术发展变化很快时，设计完成时方案已经过时
因此，富技术时代下，做好平台型技术架构设计的关键是：
- 系统性的分析架构需求
- 结构化的设计架构方案
- 沉淀可复用的架构经验
6.2.2 系统性的分析架构需求
在架构咨询过程中，我们看到很多由不良架构引发的问题现象，分析背后的核心因素时，都指向了一个关键原因，即缺少前期对架构设计需求的系统性分析。当技术团队被问到为什么使用某种设计思路， 为什么使用某种技术组件时，得到回答往往跟其自身的主观经验有很大关系。
这带来的重要影响是架构质量与设计者经验密切相关，而经验的传递成本很高，架构决策过程中的信息基本都被丢弃，只留下架构设计结果，导致架构最终难以演进和迭代。因此我们在技术架构元模型中增加了架构模式元模型，引入模式分析的方法对架构的设计过程进行建模。
问题 Problem、上下文 Context
问题和上下文是对上层架构设计输入的分析和解读。
问题描述了架构需求背后要解决的实际问题是什么，例如业务中台中如何保证前台获得一致的服务等级承诺（SLA）。
上下文描述了与问题相关的背景信息，例如问题产生的背景是什么，需要考虑什么样约束条件，期望达到什么样的效果等等。
模式 Pattern
模式是通过对问题和上下文的分析，快速映射到的业界或企业内的最佳实践。
模式是解决某一类问题的方案原理的总结，通过模式技术人员可以快速构成对问题及方案背后原理的理解，在问题不变时，模式具有相对的稳定性，是沉淀技术知识的最佳形式。
决策 Decision
决策描述了在模式的基础上，引入与具体架构方案设计相关的影响因素后，形成的符合满足架构建设需求的技术类决策，决策的描述方式可以是决策树或决策表。
对决策的建模有助于使企业建立起规范的技术决策管理，规范化决策过程及决策内容，是企业构建可演进式的架构治理能力的关键。通常决策的影响因素包括来自顶层设计的 IT 技术战略、架构策略、技术选型、跨功能需求、IT 实施方法等。
实践总结
通常使用问题、上下文对上层设计意图进行系统性的分析后，得到的问题如果准确，那么它在业界往往已经存在成熟的解决方案模式可以参考。架构模式元模型的价值是帮助企业识别和利用已经成熟的最佳实践，提高架构设计质量，降低架构设计成本。
我们以上面提到的中台如何提供一致的服务等级这个问题为例，经过分析，背后的技术问题定义是如何处理接入前台之间的跨功能需求（安全、存储、性能、可靠性等）隔离问题，由此可以快速确定对应的基础架构是多租户（Multi-tenancy）架构。
多租户架构在业界有标准化的成熟模型可以参考，因此我们可以将其作为参考架构，再结合上下文中的需求背景做架构细化，最后引入技术策略模型进行技术选型、实施规划等方面的技术决策，产出最终技术架构方案。
至此我们通过以上四个元模型元素描述了对架构设计过程的建模，实际应用中，每一个元素可以根据企业的架构设计规范，建立对应的参考模型（分类、图示、描述）用以规范架构过程的产出物标准，这里暂不进行展开。
6.2.3 结构化的设计架构方案
在复杂的平台型技术架构中，是否能够对架构元素做准确的识别和直观的描述，直接影响架构设计方案是否被易于理解、使用和管理。在现实世界中， 结构化是我们理解、记忆和描述复杂事物的最佳方式，我们希望将其应用在架构设计中来增强架构的表现力，因此我们在设计时对元模型的主要考量因素有：
- 架构元素的职责明确且易于理解
- 架构元素的职责之间相互正交
- 架构元素之间存在清晰可辨的层次关系
相对于经典技术架构元素，我们弱化了逻辑、物理上的分类，使用带有明确职责属性的分类方式定义架构元素，同时我们对元素的职责进行了符合平台化特征的重新定义，最终组成轻量的结构化的描述元模型。
技术组件Component
技术组件用于描述技术服务的实现，是可部署的物理组件，例如可运行的软件系统或构建打包后的应用组件，技术组件通过架构模式的决策元素，与技术选型进行关联。
技术服务 Service
技术服务用于描述实现上层架构设计意图所需的技术能力（或功能），例如网关、防火墙、数据存储、缓存等。技术服务属于逻辑模型，作为一种对服务能力的描述，与之相关的 SLA 等跨功能性需求会同时作为其参考描述信息。
技术服务的价值在于将上层架构中的技术需求与实现相分离，以保证架构设计的稳定性和实施上的灵活性。在技术架构治理中，技术服务是企业 IT 的核心能力对外的重要展现形式，也是 IT 的核心资产之一，从技术服务的角度实施管理将有助于提升企业整体 IT 服务水平。
技术平台 Platform
技术平台是用于描述由一组技术服务构成，提供解决特定技术领域能力的逻辑模型，它主要用于从更高的层次对技术服务进行管理，简化架构参与者对复杂架构的理解和使用，统一对用户提供一致的SLA 服务承诺。
下面是技术平台在架构设计中的典型用途：
1. 技术平台作为技术服务的提供者
例如微服务架构通常需要多种技术服务提供支撑， 在一些企业内部或技术产品中，将其统一归入微服务平台。
2. 技术平台作为技术组件部署运行的承载者
例如当架构中需要描述部署方案时，技术平台可作为对部署载体的描述，例如提供容器化运行的 PaaS 平台。
3. 技术平台作为外部服务的提供者
例如使用 AWS 等云平台提供的技术服务时，架构设计上即可忽略对技术服务支撑的技术组件的描述
实践总结
结构化的架构描述有利于企业从多种视角对架构进行管理和治理，实际架构设计过程中，可以由技术服务为切入点展开高阶设计和详细设计。
首先明确上层架构设计意图中对技术能力的依赖是什么，进而定义出技术服务所需提供的 SLA 服务承诺等级，结合架构模式中的决策模型选择技术组件的选型。
对于需要多种技术服务组成而成的能力描述加入技术平台进行统一描述，在高阶设计中以技术平台和技术服务为主描述清楚架构意图和逻辑，在详细架构设计中进而展开技术组件级别的设计。
6.2.4 沉淀可复用的技术知识
技术架构中的复用涉及两个方面：
1. 通过技术组件、平台提供可共享的技术服务
2. 架构设计过程中产生的可重复利用的技术知识
技术服务共享在企业中已经通过 IaaS、PaaS 等技术平台得以实现，在最后一个实践中，我们要关注的问题是技术知识的复用。
企业架构设计背后都是成本的投入，从技术管理的角度，管理者希望一次投入可以在更长的时间里产生更多的价值；从技术设计的角度，架构师希望用更短的时间完成更高质量的架构方案。因此很多企业在技术治理策略中，将技术知识作为重要的技术资产进行管理。
下面从技术架构知识管理关注的两个核心问题展开我们对元模型在知识复用上的设计意图：
- 当完成架构设计后，我们从中得到了什么？
- 有什么是可以在以后的设计中重复利用？
当完成架构设计后，我们从中得到了什么？
通过元模型可以看到，架构设计的产出物包含结果产出物和过程产出物，过程产出物往往在设计过程中作为隐性内容被忽视了，对架构过程的建模的目的之一就是将过程产出物显性的表现出来。
结果产出物的价值主要体现在对建设实施的指导， 而过程产出物则代表了对问题、方案的思考分析过程，其价值主要体现在技术知识传递环节，在知识管理领域中 “渔” 比 “鱼” 价值更高。
架构模式元模型中元素同样是对“经验”的结构化表达，使仅存储在少部分设计者大脑中的信息得以可视化的展现，便于经验的传递和学习，这也是架构模式元模型的重要作用之一。
有什么是可以在以后的设计中重复利用？
在现实世界中，能够被广泛重复利用的事物都有一个共同的特征，就是在较长的时间里具有很高的稳定性。稳定是可复用的基本前提，复用的价值是从外部变化时而自身可以不变中的获得的。
在技术架构元模型中，架构方案是架构模式在特定场景下的实例化结果，其中特定场景包含上层架构输入的设计意图、影响决策的技术策略等，这些因环境而变的信息是不稳定部分。
因此在一个架构设计中，问题、上下文、决策都是变量，只有模式是稳定的。最后我们可以将可复用的技术知识对应到三类架构产出物上：
总结
至此，我们完成了针对现代企业架构框架（MEAF） 的四个主要部分的阐述，即企业级业务架构、企业级应用架构、企业级数据架构和企业级技术架构的核心元模型以及元模型的应用场景和建模方法。
在框架的构建过程中，我们希望结合 ThoughtWorks 多年在敏捷精益、企业架构顶层规划与领域驱动设计为特色的 IT 系统落地、以用户为中心的产品化设计等方面的经验与实践，融合成熟的企业架构理论与企业架构框架方法，针对平台型企业架构规划与落地的新背景，为正处于数字化转型浪潮之中，尤其是以平台化架构为原生企业架构选型的企业，总结与提炼一套适配可真正落地的轻量级企业架构框架方法论，以应对现阶段以平台化中台化为代表， 从面向业务功能到面向企业核心能力的现代企业架构规划和设计过程中遇到的一些实际问题。
最后，在企业数字化转型中实践越多，我们越知道企业数字化转型的艰难与复杂，也越深感在云原生、平台原生、分布式架构大放异彩，企业不断强调敏捷、创新、产品化、可落地性的今天，需要重新关注企业架构领域以及相应的方法论，并持续结合当前的背景和趋势对于企业架构框架做出相应的演进与适配，使之真正成为真正能帮助企业在现代化架构、技术和趋势的背景下完成数字化转型的重要武器，助力企业数字化转型成功。
参考文献 1 《国际数据公司（IDC）3 月份的 CXO 月度调研》 国际数据公司
参考文献 2 《趋势洞察：数字加速，在危机时期推动增长的主要技术》 IBM 商业价值研究院
参考文献 3 《从技术走向商业看“中台” 投资机会》 中银国际证券参考文献 4 《中国行业趋势报告 -2020 年度特别报告》 罗兰贝格参考文献 5 2019 恒生电子技术开放日
参考文献 6
AFrameworkforEvaluationofEnterpriseWorldAcademyofScience,BabakDarvishRouhani,MohdNaz’riMahrin, FatemehNikpay, MaryamKhanianNajafabadi, PouryaNikfard，EngineeringandTechnologyInternationalJournalof Economics and Management Engineering Vol:9, No:1, 2015
参考文献 7 《Domain-Driven Design》Eric Evans
参考文献 8 《Data Mesh Principles and Logical Architecture》Zhamak Dehghani
参考文献 9 《TOGAF 标准 9.1 版》 The Open Group, 张新国等译 ,2016
参考文献 10 《Enterprise_architecture_framework》 Wikipedia
作者：
孔磊 首席咨询师
马徐 首席咨询师
王健 首席咨询师
赵志桐 首席咨询师
周宇刚 首席咨询师
（以上排名不分先后，作者均来自 ThoughtWorks 中国 EMPC
业务线）
