企业架构及数字化架构原理

很多同学询问我架构相关的问题，我们对企业架构的理解、或停留在局部，或只触及它的表面和基本概念，无法真正理解内涵，着手实操。

今天我就从三个主题展开：
1、架构与系统是什么关系？
2、企业架构有哪些分类？区别是什么？
3、架构设计遵循哪些原则？
希望能用最朴素易懂的语言描述，帮助你解除疑惑。
# 1架构与系统的关系
谈起架构，就不得不提系统。
系统是满足某个目标或某项功能的集合体，系统无处不在。国家、政府、组织、企业、包括我们熟悉的房子、人体都可以算作系统，系统可能包含多个子系统。
架构本质上是系统的可视化表达。是子系统之间统一目标、统一语言、统一共识的基础。
对于房屋而言，除了外部框架结构，也有内部各个子系统，例如水电系统、通风系统、保暖系统、排水系统等结构原理。
对于人体而言，又分为神经系统、骨骼系统、血液循环系统、泌尿生殖系统等结构原理。
由此可见，架构可以有效说明系统的工作原理；合理的架构设计是系统稳定高效运作的基础。

上面这张图来自北京交通枢纽：西直门立交桥。西直门历史悠久，是北京内城的九大古城门之一，清朝开始这里就是交通要道。
然而这座历时四年、来自建筑大师的杰作却成了司机吐槽的对象，什么原因呢？
因为立交桥的架构设计太不科学，导致出入口的通行流量不均匀；车辆一旦进入立交桥，就很难出去。
因此，每一类架构设计都对应着一个系统目标。例如人体的目标是健康地活着；房屋的目标是提供安全、舒适的居住场所；立交桥的目标是利用合理的架构布局改善交通、提升效率。
## 越是复杂系统，对架构合理性要求越高。
不论人体、房屋系统还是立交桥，要想功能完好、运作顺畅，非常依赖系统架构的合理性。一旦某个环节出现问题，整个系统都可能出现崩溃。
如果把企业比做系统，我们应该如何用架构表达它呢？
# 2 企业架构的分类
传统企业在数字化转型过程中，尤其需要关注企业顶层架构设计（这一点常常被很多管理者所忽视）。
企业架构设计合理，数字化系统就能有效支撑业务发展；反之、可能会阻碍业务发展。
从大的分类逻辑来讲，企业架构主要分为业务架构和数字化架构两大类（当然你也可以把组织架构纳入其中）。
![](/media/202404/2024-04-13_111653_718108.png)
a）业务架构与数字化架构的关系
==业务架构主要以企业战略、商业模式为原点，将业务价值链、业务流程和关键活动可视化表达出来==
数字化架构就是指打造数字化产品时所需要完成的顶层架构设计，主要包含应用架构、数据架构、技术架构、安全架构等（其中应用架构你也可以理解为产品架构，通常很容易和业务架构搞混）。
业务架构就好比灵魂，它相对抽象、却是企业生死存亡的关键。
数字化架构就好比躯壳或者实体，它非常具体，但如果脱离业务架构去设计数字化架构，就好比没有灵魂的躯壳，这个数字化系统不可能产生真正的价值。
TOGAF是目前相对主流的企业架构设计思路，它将企业的长期愿景作为核心驱动力，不断通过架构体系来匹配业务能力，并形成很好的动态联动优势。
详情可参考我之前发表过的一篇文章“一张图读懂业务架构 ”。

![](/media/202404/2024-04-13_111719_922650.png)
b）TOGAF企业架构示例
接下来我分别介绍几类架构的侧重点和差异。
## 1）业务架构：业务架构是企业战略愿景的进一步解构，它起源于商业模式、终于业务价值和业务活动。
业务架构也是业务与数字化架构之间的连接纽带，是推动企业数字化战略落地，并带动信息系统与业务充分融合的关键。业务架构包含业务流程、业务活动以及支撑活动所需要的系统能力。
通常来讲，如果企业处在起步期、业务复杂度不高，一般不会配备专门的业务架构师。这部分工作往往由产品经理或者技术经理协同业务方一起讨论。倘若业务发展到成熟期，且系统和业务之间存在千丝万缕的耦合关系，企业会配备专门的业务架构师，作为业务与数字化产研部门的沟通桥梁。
如下就是业务架构师在业务建模之前需要梳理的关键业务活动。最终这些活动需要靠一个个业务系统的产品能力进行支撑，也就是会成为应用架构中的产品规划和功能层级。
![](/media/202404/2024-04-13_111749_600739.png)
c）业务活动模型示例
## 2）应用架构：业务架构和应用架应用架构根据业务架构的总体要求，描述支撑业务和管理的应用系统、形成规范、完整、灵活、可扩展的应用系统功能及系统之间的关联关系。
应用架构主要以数字化系统功能层级为主心轴，应用架构和业务架构之间主要通过系统能力构建连接关系。
通常来讲对于软件系统应用架构，包含数据库、数据访问层、业务逻辑层、以及终端界面层。不同层级之间通过服务接口和数据规范进行连接，因此规范和标准的定义在应用架构设计中尤为关键。此外，应用架构的层级也通常被用来定义数字化团队的组织架构。业务对应用功能的依赖程度越高，换言之应用功能所支撑的业务场景越核心，通常在组织层面也会存在资源倾斜。
## 3）数据架构：每个业务活动对应到数字化系统，本质都是数据的增、删、改、查。而数据模型就是在构建一套基础的基于业务对象、业务实体的数据标准和数据体系，以此来确保各个子系统之间可以正常进行数据对接和流转。
数据架构中包含数据实体关联表，主数据、元数据，数据模型库等要素。核心要构建统一的数据实体和特征命名规范，确保不同的业务实体之间针对数据的解析是一致的。数字化产品在经过不同阶段时，对数据架构的要求也不同。初期主要关注数据标准化和数据实体之间的血缘关系。随着业务数据的积累，一旦系统形成数据驱动业务决策的能力，系统对数据架构的完整性也就提出了更多的要求。
如果早期数据架构不够完善，会给业务带来巨大的灾难。某新能源汽车就因为早期没有做好数据架构，导致车主在接受汽车软件OTA升级时，失去了驾驶控制能力而停在北京长安街被交警罚款。此外对于金融、政府部门，如果缺乏有效的数据架构支撑，很有可能出现风控安全隐患。
如下是数据模型的基本示例。
![](/media/202404/2024-04-13_111830_129422.png)
d）数据架构示例
## 4）技术架构：描述实现应用架构所采用的技术，同时也包括支持应用系统部署所需的基础设施和环境。
技术架构通常由企业级应用集成平台、公共服务平台、基础设施平台和信息安全平台等组件组成。技术架构的核心原则是鲁棒性和可扩展性，一般基于微服务理念，遵循不同技术平台共享、开源软件与商业软件并存的原则，确保从基础服务能力上可以与主流系统对接。例如涂鸦的业务特性需要服务于全球智能解决方案厂商，因此技术架构上需要兼容国内外不同的云服务厂商，例如亚马逊云、阿里云、微软云等等。
此外技术是为业务而服务的，任何缺乏业务目标的技术架构都不太可能长久。技术架构的迭代方向要充分尊重业务的发展特性。例如滴滴就曾经进行三次大的技术架构调整，原因在于滴滴随着业务发展对系统并发和智能调度、安全等能力提出更高的要求。此外技术架构迭代也要充分考虑技术的前瞻性，例如考虑如何夯实核心技术底座（如云计算、物联网），提前布局前瞻技术，当AIGC技术成熟后考虑如何融入原有技术体系，还要充分考虑开放性、标准化和安全性。
如下是一个技术架构的示例。

![](/media/202404/2024-04-13_111852_856476.png)
e） 技术架构示例
# 3架构设计原则
不论业务架构还是数字化架构设计，都遵循几个基本原则。
1）整体性原则
务必统筹全局，架构设计切记只cover局部要素。架构的目标是让所有参与者对全局有共识，知道完整的业务或数字化体系是什么，也清楚自己团队的位置，明确合作目标和标准，清楚上下游的协同关系。
2）一致性原则
一定要确保不同架构的一致性。架构设计不存在职责边界，例如技术经理也可以参与应用架构的讨论，产品经理也可以参与技术架构的讨论。架构本质上是在使用不同的描述语言来表达相似的事情，例如应用架构、技术架构和数据架构，其实都在描述一种系统能力。
3）合适性原则
很多传统企业都在对标华为数字化转型，因此会采用华为的业务架构和数字化架构作为架构主体。架构不在于复杂、也无所谓前瞻，更重要的是适合。因此我们在设计架构时，既要借鉴优秀的行业案例，也需要根据企业的实际情况进行灵活调整。
4）落地性原则
做架构设计切记盲目追求大而全，而是要强调其落地性。一切不为业务目标服务的架构都是耍流氓，同样一切不以落地为目标设计的架构也是耍流氓。落地要考虑的是资源够不够、人员能力行不行、技术成熟度有没有达标。真正理解业务本质的人，才能设计好架构。
我总结一下，架构设计需要遵循整体性、一致性、合适性和落地性原则。架构的目标是确保团队统一共识、理清边界职责、组织高效运行。具备完善的企业架构，业务和数字化系统之间才能保持一个稳态，相互促进。
最后我引用《领域驱动设计》一书中提出的限界上下文（Bounded Context）的理念。限界上下文为高内聚提供了很好的理论指导，它的核心是将特定职责的相关行为控制在一个有显示边界的范围内。
书中的一个比喻非常形象：“细胞之所以会存在，是因为细胞膜定义了什么在细胞内、什么在细胞外，并且确定了什么物质可以通过细胞膜。”
企业架构正好遵循这样的逻辑，本质是通过清晰的领域业务规则和业务边界定义，来驱动更细颗粒度的数字化系统能力构建（微服务体系），确保系统的能力迭代匹配业务发展。