业务平台化趋势下需要重塑企业架构吗？

一个公司应该首先建立起战略，然后寻求建立一个实现该战略的合适的架构。

为什么重提企业架构

我们之所以研究企业架构，一部分源于之前研究中台的规划过程中发现它是一个企业级架构的问题。现在如果大家去看企业架构框架，就会发现大家众说纷纭，因为越靠近顶层，离战略越近，离企业界越近，就会越“虚”。企业架构已经被行业应用和发展了二三十年，为什么现在又被重新提起？而且，你会看到，就跟当年大家在谈中台一样，行业对于企业架构的理解和应用也是众说纷纭，大家说的都很有道理，但我不知道哪个才是适合自己。

那么这波浪潮到底代表什么，我分成了几个比较小的问题，比如第一数字化建设中有哪些挑战？第二，为什么说企业架构是解决问题的正确方式。第三，到底什么是企业架构，什么是企业架构框架，以及为什么说平台化是数字化转型。

第一个我们先想想什么叫数字化？虽然这个概念大家都在提，最近我发现好几位行业大佬在谈数字化的问题，我也在写一个系列叫“白话数字化”，从小白视角去阐述这样一个概念。那我觉得数字化的概念并不是特别高大上，最早有一个数字孪生的概念，就是如果没有信息化，没有网络的情况下，我们现实世界也是在同样运转。那有了信息化、数字化之后，我们发现数字世界里边做很多的事情要比我们在物理世界要容易的多。我们现在在做直播，那原来在没有互联网的情况下，这个形式是什么样呢？就是线下的聚会、社区的分享。比如我们现在做线上直播，要比把几千人聚在一起做一个线下的分享要容易的多。像现在我们通过直播交流，我现在在一个非常大的空旷的会议室里，我的物理世界就我一个人，但是在数字世界里边现在可能有几百人，甚至几千人，我们在一起沟通交流，这就是数字世界的魅力。这也是现在为什么大家在谈数字化的一个原因。

大家一定会想这个东西不就是简单的信息化，我的观点是一脉相承，说白了就是把物理世界的东西搬到数字世界里，但是不像数字孪生。数字孪生可能会太严格了，要求两边一致。我觉得最简单，当我们谈数字化的时候，就是把我们物理世界的一些东西搬到数字世界，我们做数字化转型就像把业务搬到数字空间。我们发现数字空间相比物理空间有很大的优势，比如简单、突破空间的约束。我们现在直播就是在突破空间的约束，这个在物理世界是很难办到的。还有突破时间的约束，我们现在很多讲的大数据，基于过去的历史信息做未来的预测，这其实就是在借助时间，在跨越时间的维度。

物理世界的计算单元是我们每个人，我们的知识传递主要靠义务教育，需要花前 20 年来做整个知识和信息的传递。我们的存储模式也有限，只能靠一些文字，靠大脑去存储，我们的算力也有限。这就是物理空间的局限，这就是为什么我们反而希望在数字空间构建世界的原因。但是数字世界是不是一定好？不一定。物理世界物理空间也有它的优势，比如高保真。这就是为什么我要去见一个客户，还是要跑到客户的现场去做，因为我发现在一个会议室里大家面对面的交流，跟我们线上开会议是不一样的。我现在稍微有一点点不适应，因为我感觉我自己在跟空气沟通，那这就是数字空间给我们突破了空间约束的同时，带来的一些损失。

我们先定义一下什么叫数字化。我认为数字化的过程就是把我们物理空间一部分的业务搬到数字空间，让两个空间无缝融合。我引自 Thoughtworks 出版的一本书，它里边给数字化做了一个定义：我们认为数字化转型不是模糊技术和业务之间的界限，而是用心记录重新为客户提供价值，是一个技术重构业务的过程，是业务和技术融合的一个过程。这个观点至少在行业里大家达成了共识。既然说数字化，那么什么叫数字化建设？就是我们原来的企业可能是纯物理空间，纯线下的业务，现在要借助数字化世界的一些优势把物理空间的一些过程、业务，搬到数字世界里。

我们发现在这个过程中，之前很多年的发展都是一个野蛮生长的过程，尤其是互联网速度带来的牵引力，让我们快速的构建了很多企业系统。大家都在讲烟囱式的建设，在我来看并不是一个烟囱式建设，可能更像下边图片中的这种，现在很多企业也随着过去 5 年、10 年的发展，现在我们的应用的现状可能差不多就是这样一个情况。

所以在数字世界，我们企业如果是这样的情况，那肯定会碰到很多的困难，比如企业做新的业务，去做任何的变化都会极端的困难，这跟物理世界是一样的。那现实中，我们是怎么解决的。

如果我们只看右边这张图，可能不理解图中的意思，但是我们很容易找到网上的一些雄安新区的规划图，我们发现在这些看起来杂乱无章的建设背后，我们之前要对整个城市和地区做一个整体性的规划。这个规划不光是简单的一张图，它可能是不同的视角，我在看这个时候，发现它跟我们在做一个企业级的规划很相似。企业级规划对应的是我们原来说的系统级别的规划，相信很多的朋友可能现在更多的是在一个系统，或者一个领域，可能更多的是在系统层面做架构设计。

软件产品的研发，一旦我们把视野提到企业架构层面，就跟我们把视角从建筑的结构，提升到一个城市的结构一样，这个时候我们看到复杂性是不一样的。所以企业架构方法我觉得在物理世界对应的学科应该像我们说的城市规划，是一个更大、更宽的视角。

过去几年，我们在研究信息化和数字化建设中发现现在的数字化建设并不是从零开始的。就像雄安新区一样，可能更像一个旧城改造，是把刚才那张图里已经建的可能相对杂乱无章的这样一个情况，通过一个重新的规划，重建成一个我们想要的样子。

现在我们在数字化转型的第一个阶段，大家在做一些企业架构的治理，包括业务架构的梳理和应用架构的治理等。那我们来看看到底什么是企业架构？架构这个词最早是在建筑行业，用我自己的理解，架构就是在一定的环境之中概念和概念之间的关系。

我们看到很多的架构图，发现最常见的架构都是分四层，每一层里边有各个块，块里边还有小块。在我看，它代表的就是我们企业无论是对于业务还是应用的元素，以及这些元素是什么样的关系，是不同的层次之间的关系，或是包含关系、关联关系。所以架构很简单，架构就是在一个上下文，或者表达在一个环境中有哪些概念，以及这些概念有哪些关系。

那什么是企业架构？如果我们了解了架构之后，企业架构很容易理解，那就是当我们去看待一家企业的时候，在这个环境之内，到底有哪些基本概念？以及他们之间的关系是什么？比如我们说的组织关系，也算企业架构关系的一种，比如什么人在这个过程中扮演什么样的角色，以什么样的流程，在做什么样的操作，所以组织架构就是我们这个组织、有哪些人和他们之间的关系。

所以当我们说企业架构的时候，我们就是在看，一个企业里边的元素和关系。我们在看一个企业架构时候也会以不同的视角去看待这个企业，比如说我们从业务的视角、组织的视角、应用的视角、技术的视角、数据的视角，这就是为什么当我们谈企业架构时候，经常大家就会在谈什么业务架构、应用架构、技术架构、数据架构，它都是在以不同的视角看待企业里边不同类型的要素和这些要素之间的关系，这就是企业架构。

前面我们了解了什么是架构、什么是企业架构之后，我们再看看什么是企业架构框架？我发现很多行业里面，大家经常把企业架构跟企业架构框架，就是 EA 和 EAF 这样的概念混淆。企业架构就是一种架构，把这个企业元素和元素之间的关系能描述清楚，这就是企业架构，企业架构更多代表的是一种结果，而且架构框架如果能产出这样的一个结果，有很多不同的这个框架和方法，就是工具。

如果我们追诉企业架构的历史，很多人说是从 1987 年的 Zachman 开始，作为一个企业架构的起点，我们也做了一些研究，通过往前追诉，就是左边这个 Paper，大家现在可能已经很难查到这个文档，它都没有电子版，现在都是影印照片。

我们看到了数字化的必然趋势，因为在数字世界里，通过技术或者其他方式，可以赋予我们业务更强的威力，而掌控这种数字化带来的威力是大部分企业要发展的方向。当我们关注这件事情的时候，我们单以系统的视角就不够了，我们需要把视角提升到一个企业视角，就跟我们在做一个城市规划，单看一个小区的规划已经不够了，需要一个大的视角，然后我们就找到了应对方法，原来企业架构是解决这个级别问题的一个手段。而且这不是新事物，它已经存在 20 多年了，直接拿来用就可以了。

那为什么大家现在又在谈企业架构呢？我们发现现在这个节点我们再去应用这些经典或者叫传统的企业架构方法的时候，感觉有点力不从心。

到底是什么让我们觉得原来的框架并不太合适？我们需要做一些企业架构框架的演进也好，改进也好，不光我们，如果大家最近关注 TOGAF，它本身也在做企业架构框架的演进，包括最近试图把敏捷揉入到比如像 TOGAF 这种传统企业架构框架之内。

第二点是平台化。为什么说平台化是数字化转型现阶段的一个重要趋势呢？我们知道原来最早做企业，可能需要从购买服务器开始，甚至如果再久远一点，我们需要自己去构建自己的操作系统，但是现在至少在企业外已经有很多的平台了，无论是云也好，中间件也好，SaaS 也好，我们发现不需要再从零开始了，只需要在金字塔的塔尖构建我们自己的应用就可以。那再往前，我们现在很多的企业，尤其是中大型的企业，觉得外边的这种行业通用的平台和工具已经不足以满足需求了，可能业务线非常的庞大，十几条业务线，上百、上千个应用，我们希望在企业内开始再去构建自己的这样的一个平台。现在国外没有中台的概念，国外相对比较对应的概念是企业内部平台。现在我们国内的很多客户在遇到新的业务场景，已经在考虑不是又重新构建一个新的烟囱式应用，而是看能不能通过构建一个企业内部平台，然后再其之上去构建业务应用，慢慢沉淀企业的内部业务能力和业务模式，中台架构也就随之诞生了。

我们发现现在的企业环境跟原来 20 多年前的有两个大的差异：一，技术上已经翻天覆地了，第二现在大家在做的已经是非常靠近业务的、很薄的一层了。最近行业里边都在争论低代码平台，但是其实就算没有低代码平台，我们去构建一个应用也比 20 多年前要容易的多。现在无论是企业内平台和企业外平台，都给我们做了很大的支撑。

我们再看看原来大家在很多地方都在用的 TOGAF 企业架构框架，最早我们去解决中台和企业架构治理的问题，就是用的 TOGAF。如果我们只看业务架构的部分，发现传统的经典企业架构，它非常的简单，这个简单不是贬义的，因为企业架构框架会涉及到一个使用范围的问题。如果大家看金融领域，金融领域也有像 BIAN 这种企业架构框架。我们说一个企业架构框架，如果想适用所有企业，它一定会设计的足够通用和抽象，这样才能满足更广的适用范围。

但是放到每一个企业应用的时候，你会发现很多的东西用起来特别别扭，需要做很多的工作，比如用传统的 TOGAF 去构建企业的业务架构，很简单，你只要能清楚业务架构的核心元模型、有哪些组织、有哪些人，以什么样的角色，使用什么样的功能，以什么样的流程去完成业务就 OK 了。

如果往前去看，先把业务搬到数字化这个过程，保持业务不变，可能只有一条简单的价值流。从生产制造到销售，我们可能只卖一个产品，只有一个业务。最早，我们只要在这里边，把它切分清楚：如何进行获客是一个系统，中间生产是一个系统，供应链是一个系统，营销是一个系统，我们只要把业务捋清楚了，每一个系统一个团队。过去二十年应用这些企业架构是 OK 的。

现在是一个什么样的背景？现在一个企业动辄可能就是三五个事业群，好几十个业务线，每个业务线里还有成百上千的应用。这个图只列了三个进行举例。然后我们发现在不同的业务之间有很多重复的东西，但是如果从整个价值链和价值来看，它又不一样。在这种场景下，我们如何还像原来一条一条去梳理它，构建一个一个应用去满足它，我觉得这肯定不是在现在这样一个业务复杂性的情况下可用的工作。

同时很多的企业在业务充分扩展之后，还考虑到复用：不需要每一次都重新去构建平台。那平台如何去建设？如果回到传统的企业架构框架里，虽然它也会引入一些扩展机制，引入一些 SOA，但是它跟平台还不是一个层面的事情。我们发现现在在数字化整个过程中，面对问题的复杂度要比二十年前要复杂的多。在这样的一个背景下，当我们如果去做一些企业的数字化规划，在原来的传统的企业架构的方向之上，我们能做哪些改进？比如如何处理平台，如何处理分层，如何处理技术和业务结合，如何处理数据被充分利用的场景？在这个趋势下，我们是在试图把一些我们自己的想法和今年的企业架构框架做一些融合，但是这个框架本身也在持续的改进。

现在行业里边就有很多的同学也在做企业架构框架的研究，那现在这样的框架能不能解决我们的问题？目前我们设计这套框架的时候，首先第一点就是能复用就复用。我们知道有一个奥卡姆剃刀原则，如无必要，务增实体。所以在传统经典的企业架构的框架下，有好的概念还是把它承接下来，像我们原来说的 4A 的架构，业务、应用、数据和技术，我们这个大的分类并没有变化。

什么是业务架构？传统的企业架构的思路我们觉得是没有问题的，就是从战略输入到业务，以业务为核心，然后去推导应用如何去支撑，技术如何去支撑，数据架构怎么去设计。但这里边我们看到了很多新趋势，一是整个企业在分层，原来可能就像刚才那条价值链一样，企业就一层，大家只要按不同的价值阶段去切分系统就可以了，相对比较容易一些。现在我们发现业务已经至少分成了两层，甚至多层。第二就是重，那我们现在想能不能把它变成敏捷化、轻量化，能不能在一个月到两个月的时间内去做完一个企业架构规划？

所以今天我也会把业务应用、数据架构和技术架构都讲到，但是时间有限，我把业务这块充分展开，因为我看到行业里边，大家目前的观点更多的聚焦在业务架构和应用架构。

评判一个业务架构是不是做的好特别简单，只要我们找一个不懂这个业务的人来看，给他一份业务架构图，无论是用什么画的，他都能看懂业务是什么。因为架构图，它一定是为了传递信息，跟我们去盖一个楼，施工队能按照架构图构建出来一样。我认为这是评判业务架构设计结果好坏的唯一标准。

应用架构和业务架构有什么区别？我认为最简单一个回答是业务架构可以没有任何应用架构，因为一个纯物理世界，纯线下的业务它是有业务架构的，但是没有任何的应用架构。那现在如果我们拆解开业务架构，把企业架构问题转换成四个架构问题。

第一，如何控制业务架构梳理的粒度，为什么？我们看到经典的企业架构在做业务架构时，就一个功能和流程，里边无限嵌套，但到底嵌套多少层？业务到底是分成什么样的粒度？场景和业务到底有什么区别？业务是在场景里还是场景在业务里？我们发现很多时候并没有去做对齐；

第二，现在大家都在讲企业分层，比如业务层、中台层，对于中台层或者平台层，最简单的目的是通过复用来降本增效，那怎么在业务表象背后找到可复用的能力？这是我们碰到的第二挑战，我们发现传统经典企业架构也没有帮我们解决这个问题；

第三，如何复用这些能力，实现业务的快速上线。

这个是在做企业架构治理，尤其是在平台性企业架构治理里一直困扰我们的问题，那我们怎么解决？

首先，我们也参考了行业里边的很多的经验，现在行业里都在讲五级建模、六级建模，如果大家往回追诉，这是有些标准和依据的，比如有些行业流程分级这些标准都有存在。

现在在行业里边大家分层不一样，但是我认为“分成什么样”不重要，“分”更重要。

这张图引自 C4 模型。大家应该了解 C4 模型，它相当于我们在做城市规划或者在做世界规划时，一定会有个标尺，我们才能知道我们到底在哪个纬度和哪个粒度上在谈论业务。

这里一定要有一个数字世界的标尺，或者业务标尺，那我们首先在传统企业架构方法之上，把业务的这个标尺建立起来，也就是图中左边这些。在这里边同时对于横向的能力，我们也可以通过这样的标尺，跟整个的业务流程进行一个对接，这样带来的一个特别大的好处是：很多企业在架构治理过程中，原来大家很难沟通，因为每个人说的东西都不一样，就是你说的一个场景跟我说的一个场景完全不是在一个维度上，你说的一个功能跟我说的一个功能、你说的一个流程跟我说的一个流程，也都完全不是在一个维度上。大家很难达成共识，就相当于没有地图的情况下，我们来谈论世界一样。有了这样的标尺之后，我们谈问题的效率会成倍的提升，这个很重要。

这是我们做的一个案例。可以五层或六层，大家可以基于不同企业的情况去定制。

企业架构里，我们给每一层都找到了一个标志物，确定大家至少在同一个相对的维度上。通过这样的分解之后，业务就会有条理很多。原来我们去做梳理的时候很难对齐，一旦建立一个标尺之后，无论是用户流程图还是价值流价值链的梳理，我们都可以很快地让大家聚焦在同样一个颗粒度，以同样的一个维度来思考业务。无论是知识的传递和知识的沟通，以及知识的沉淀都带来了非常大的好处，这给我们至少建立一个业务的共识。对于业务架构进行一个梳理，这个标尺非常重要。

第二个，如何定义共享可复用的能力？如果现在大家去构建比如像中台或者平台这样多层的企业架构的时候，这个问题就可能是困扰大家的问题，也是当时困扰我们的问题。通过前面建立一个这样一个业务标尺后，我们再去看业务，就可以在不同的维度，不同的缩放程度上对业务进行对比。

有了这样的标志，让我们去抽取不同的业务不同的场景下共同的能力也变得更容易。比如我们可以把单个步骤的能力变成一些基础的能力，把一些可能 L4 级别的能力定义成一级二级能力组件在解决方案层面复用。通过这样一个标尺和业务的梳理，我们就可以把这些业务放在一个蓝图上进行对比，这样我们就可以很容易找到哪些能力在不同场景下是完全一样的，哪些能力在不同场景下相似但有差异，哪些能力在有些场景下有些没有，这样的话就可以帮助我们去提炼识别这些可共享可复用的能力。

能找到但如何去识别呢？第一，比如需要进行流程建模。我们需要看不同的业务的表象之后有哪些通用的流程，这些通用的流程就像一个模板一样，如果大家了解 24 个设计模式，我们原来更多是在代码层面来去消除一些重复，做一些重构。企业级的中台在我看来就是在构建企业级的模板模式，在大家不同的流程模式之后找到通用的一致性流程，再通过扩展和继承的机制来去实现不同业务个性化的需求。

第二，我们发现很多的企业在去比对不同场景业务的时候，更多还是从流程层面，为什么现在大家在讲中台建设，往往会跟 DDD 紧密相关？我经常举的一个特别形象的例子，就是判断人的外在行为。每个人都是一个脑袋，两个眼睛一个鼻子一个嘴，但是每个人都长的不一样。这就是我们经常做业务时发现每个业务看起来都一样，但是往后看都不一样。你说能不能变成一个人？变不了。但是什么是一个好的能力复用的例子？我觉得医院是一个好的能力复用的例子。医院没法通过头疼、脚疼来去判断你是什么问题，但是医院里边的科室设计就是一个按照知识边界进行科室划分的，比如心脏内科、神经内科这些能力是可以复用，比如一个心脏外科大夫他可以给不同的人来去解决心脏外科的问题，所以在医院内他是一个基于能力构建的中台结构。那你如何判断一个外在的行为到底有哪些内在的领域和知识是复用呢？就是通过做检查，做 B 超，做 CT。

其实 DDD 就是对业务“照 CT”的一个过程，我们对业务进行了一系列的行为、事件的建模，包括领域建模，我们就相当于给业务做了一个 B 超。就像我们说的定单中心、用户中心，你发现它本身并不是外在的流程和业务，它更像是内部的领域和知识边界。我们经常说前台的划分和中台的划分，比如说从应用上的划分是完全不一样的。前台更多是基于价值流阶段，给那些人在提供什么样的价值来去进行划分。平台层考虑的是复用，更多要从知识边界、从内在进行划分。这就是为什么我们发现平台性的架构，也给企业架构演进带来驱动力。我们发现原来只从外边、只做外科体检的方式不太起作用，可能需要一些新的工具和手段。

第三，我们最终想要的是针对不同的前台产生不同的复用，行业常用的方式是通过业务身份建模加扩展机制实现。很多客户会问自己企业到底有多少层，怎么划分？但其实是难以划分，因为理论上一层和多层都可以解决以前的问题，而平台之所以是个战略，是需要从顶层去做设计，它不是一个能从痛点进行业务推导的过程。业务架构的输入一定是企业的顶层战略，包括平台战略也是企业顶层的战略之一。

通过这样的一个战略的输入，建立业务的标尺，用不同的方法梳理业务，在这个过程中再进行一些可复用的抽取，找到这些流程背后通用的能力，再通过这些能力将标尺和维度与业务进行对应，这就是以平台为代表的一个企业架构的业务架构。

业务架构未来是什么样？今天分享的题目是“企业架构的过去、现在和未来”，我们现在已经看到过去谈架构更多的是一个瀑布类型，业务战略输入、业务输出、应用输出、数据输出以及技术，可能需要六个月至一年的时间。

现在我们发现在数字化背景之下，用数字化技术来重新改造我们的业务，这个过程不再是一个瀑布流程，而是一个不断迭代甚至融合的过程，这是我们能看到的业务架构的一个特点。我们也在试图把一些数据的能力，包括数据的场景，技术的能力再融合到整个业务架构设计过程中，我们的方法也在持续的演进。

最后一步就是如何复用。我们认为行业里边当谈能力复用的时候，可定位成三个 Level，第一个就是简单共享，就是一个能力在这，你和别人都是用一样的，这就是为什么很多的企业叫管这个叫做共享中心。就是比如我一个查询定单，你查的跟他的没有任何区别，我认为这是第一个级别的能力复用。第二我们发现在互联网企业里边，很多业务深层扩展机制，可以针对不同的前台产生出不同的行为，我认为这是第二步。在我的定义里这才叫复用，之前那个叫共享。再下一步是提炼能力，把我们的能力包装成更抽象、或更大粒度的解决方案。直接告诉我如何做贷款、如何做理财、如何建一个停车场，我认为这样的复用是中台层面，或者往平台的方向演进。

我认为业务架构是最主要的，其他的架构更多是一个支撑。在应用架构里面，怎么判断一个应用架构画的好不好？就是给一个应用架构图，可以知道有哪些应用、有哪些系统，相互之间是什么样的集成关系，部署在哪。通过这种架构图，就能够基本了解清楚。

应用架构里面会遇到哪些挑战？如果业务架构的难点在粒度和抽象，那应用架构的难点还是在粒度和边界。应用架构主要是划分边界，到底分几层，有哪些中心、有哪些系统，系统的边界是什么、关键是什么，系统之间有没有什么集成关系，或者依赖关系。

我们其实是在谈“分”和“合”的问题，“分”和“合”的问题就是自治和复用的问题。首先回到最根本：为什么要“分”？因为我们认为从用户的角度来讲是看不到边界的，他看到的就是业务，就跟一个人一样，我们刚才拿人举例子，心脏和肺，但是要知道人内部是没有清晰的边界的，很难划分一个人心脏和肝的边界在哪，因为大家都是一体相关的。在我们看来，“分”的根本在于认知负载，以及如何通过组织或者架构上的设计来解决团队负载问题。当一个企业足够大之后，不可能让一个人了解所有的知识，类似医学发展到现在，不可能人人都是扁鹊，什么问题都可以治。每个人的知识负载是有限的，一定要划分开大家的专业领域知识，才能更深入。

边界永远是最难分的，因为本质上就没有边界，系统和业务就是一体的。回到企业初创过程中，那时不会做复杂架构，就是一帮人做一个系统，一个系统就是整个业务。此时其实没有边界，随着发展才产生了边界。对于边界，同样要有一个颗粒度，颗粒度就是一个相应的定义。

比如说我们现在的理解，中台是商业模式的边界，中心是组织的边界，微服务是弹性边界，聚合是业务一致性的边界。在此过程中，我们就是在给颗粒度建立标尺，同样颗粒度也需要有一个标准，否则到底多微算一个微服务，每个人都会自己不同观点，需要大家达成共识。

为什么要去“分”？前提是因为我们要减少知识负载。如何确定应用的边界？我们现在用的方式是基于原模型里业务架构的输入。可能采用两种方式，一种是自上而下，比如通过业务场景这个大粒度，包含现在组织的现状，这就是为什么每家企业可能做应用架构做企业架构都是不一样的。每个企业都一样可能就不需要这么多企业了，因为我们组织不一样，我们的业务场景不一样。同样，因为我们在业务上建立一个标尺和粒度，最细粒度已经到事件级、原子级，我们同样是可以通过比如像 DDD 子域问题空间，业务架构里的价值流阶段，来进行自下而上的逻辑边界划分。然后最终我们可能确定了一个物理边界，就是应用架构边界。

举个例子，一般如果我们把企业默认分为两层的架构。前台基本上都是基于价值流、价值链。但是对于中台来讲，往往是基于知识边界来进行划分。就是我们有哪些领域的知识、订单、用户、营销，我们在基于知识来进行划分，可能一般行业里边现在通用的做法就是基于 DDD，来做平台层的基于知识的边界划分。

我们再往下讲一下就是数据架构，数据架构目前存在比较大的争议，我比较赞同“把数据架构和应用架构合并”的观点。在传统的经典企业架构里，数据架构也是在 TOGAF 8.x 才被引入到 TOGAF 框架里边。原来为什么没有独立的数据架构？是因为我们一个应用就到应用粒度即可，里面如何实现它，怎么设计，不用特别的关注，但是需要有一个仓库把所有这些东西提到一起，建立数据域。现在随着我们对于应用架构和业务架构的细化，很多原来在数据架构里边的知识，比如问题域、子域，这个可能就被移到了业务架构里面，要去分不同的业务系统在处理什么样的问题，所以数据架构可能就被缩展。

还有一个是目前行业里边经常混淆数据架构和以数据的视角看待架构这两个概念。数据中台不是纯数据架构，也包含了数据类的业务、数据类的应用和数据类的技术。数据架构在我们模型里面定义很简单，因为很多都已经在业务和应用中已经涉及到了。这里我们只定义了数据对象、数据组件和数据服务来去解决这些数据流的问题，后面会考虑把数据源和数据标准加在这里。

对于数据架构的设计过程行业里边也有很多发展方向，包括 Data Mesh，就是分布式的数据架构。一旦我们认为数据是跟应用一体的，尤其是在微服务架构设计里，你会感觉到数据是跟着应用走的。类似前端经常讲的组件化，原来大家习惯谈分层，现在其实更多是谈组件化。数据一旦跟着应用走之后，那以后未来的数据架构，或者我们这种大数据的场景是不是也是一种分布式的数据场景？如果已经是一种分布式的数据场景，还是不是需要一个集中的仓库，来去统一的单点的管理这些数据和过程？这个可能也是一个需要考量的点，或者我们可以持续的关注这方面的一些演进。

最后，关于技术架构。技术架构是在这里是相对比较明确的，因为我们经常谈技术架构、技术选型，企业级的一些技术选型的标准，技术架构的一些标准。比如我们如何处理高并发，如何处理高可用，如何处理分布式架构，这些都是技术架构要去做设计的。我们在帮很多的客户在做数据架构，包括基于数据架构和业务架构融合，我们认为传统的数据架构没有这种问题，就做一些选型，找一些组件，做一些平台，需要增加的一点就是希望把数据架构的资产进行沉淀。比如能不能构建一个自助的技术架构设计平台，就像问答式，你告诉我这个系统是什么样的？比如是用户量多少，并发量是多少，访问量是多少，用的是什么样的一个架构模式，我能不能自动给你出一个技术架构。

这里我们更多关注的是在富技术时代如何做好平台型技术的复用，这里面三个主要的问题。第一，如何能系统的分析架构设计的需求。到底有哪些架构的需求，这些需求如何分类？这些里面有哪些模式？基于这些模式到底有哪些现成的不同粒度的解决方案，可能是不同平台服务或组件甚至方案的组合，这就是一些技术架构的沉淀。那如何通过这些沉淀拿到一个新的系统，或者应用设计的时候，能不能不再从头去建设？发现很多的企业在做数据架构，每一个系统要从头到尾来一遍，然后可能大家的技术栈选型，技术方案都不一样，那么是不是可以在企业层面给大家制订一些相应的解决方案，甚至可以用一些架构平台进行沉淀，最终让前台或者中台的应用可以实现自助式，基于一些最佳实践和方案沉淀的技术架构设计。这是行业正在探索的一些方向。

最后做一个回顾。

首先，我们认为在数字化时代背景下，平台架构模式被越来越多中大型企业，甚至很多初创企业采用。我们面对的问题可能要比过去十年、二十年要复杂的多。在这种场景下企业架构是解决问题的好方法，但是我们发现它在解决这些新问题有点力不从心，或者有点过于抽象，过于繁重。

目前行业里企业架构是一个新的方向。大家为什么都在谈论？因为重新认识到了做企业级治理和规划的重要性，也在尝试用这种方法来去解决问题。我们现在正在尝试 MEAF 设计办法，且我们认为使用效果较好。

如果从整个方法论来讲，设计过程没有变化，但我们认为未来企业架构的发展方向可能有几个趋势。首先是这些架构会不断融合，未来可能分不清什么叫做技术、业务、数据架构。可能技术就是业务本身，数据也是业务本身，我们发现可能它更像从瀑布到敏捷的这样的过程。在这里边我们发现，第一，整个过程一定会更加的轻量；第二，整个过程一定会越来越关注落地性和演进性。在这个过程中，我们发现可能从整个的企业架构端到端的规划过程中，可能也要变得更敏捷、更持续。现在我们有很多的客户企业已经可以做到一次这样的大范围的架构治理只需要 4 到 8 周的时间。当然是建立在之前已经做过一次比较相对全面的构建过程，每三个月到六个月就要重新审视一下整体架构，甚至建立一个更快的架构的运营和治理的体系。