浅谈企业IT架构的十年困局

企业IT架构的近十年，对很多从业人来说是困惑的十年，伴随着企业数字化转型火热的10年，企业IT架构的方向似乎在互联网巨头身上看到了曙光，却又在实践中跌落神坛。理念的璀璨，实践的黯淡，最早在企业实践互联网技术的CIO或CTO们，是否还保留着心中的白月光，亦或是早已迷失，无奈回到最初的起点。

数字化转型这一概念最早在2012年由国际商业机器公司（IBM）提出，它强调了应用数字技术重塑客户价值主张和增强客户交互与协作的重要性。此后，数字化转型逐渐从企业（组织）层面上升为国家战略。在中国真正数字化转型的元年，我认为是在2015年。标志性的事件就是阿里巴巴提出中台概念，它从组织架构、业务架构、IT架构多个维度对企业产生了影响，激发了企业的CXO对“敏捷响应，低成本的快速创新”的热情。在IT架构方面，受中台架构的理念影响，企业已经不满足从单个领域的需求出发，开始思考如何一站式、一体化、一套标准的方式去践行。阿里在推动新一代企业IT架构的思潮，有着积极的意义，但遗憾的是它在过程中没有真正起到作用，更多的是从商业收益角度出发。下图是当时比较流行的企业IT架构发展趋势图。

作为身处这个飞速发展时代的亲历者，笔者有着深切感受和思考。在2008-2015期间，我在阿里巴巴淘系和天猫做核心交易链路和导购链路的架构，后面是菜鸟网络的总架构师，可以说我完整的经历了互联网架构的完整演进过程，知其然也能知其所以然。在2017-2019年初，在阿里云负责中台对外输出工作，积累了大型企业的IT服务经验，对企业数字化转型有了深度思考。2019年至今一直从事企业数字化转型领域关于企业IT架构方面创业。本文我会分享自己的一些关于“新一代企业IT架构”发展的思考，期待对大家有一定启发。

一：2015-2019年，是新一代企业IT架构伴随中台理念，从萌芽到膨胀的过程

在2015年前，因为互联网高速的发展，企业数字化转型的需求或痛点实际上已经积累到了一定程度。当时中台仅仅只是一个概念，根本没有任何技术标准可言，却非常的火，只能说当时企业IT架构面对数字化的挑战时确实苦无良方。经过2016年阿里对中台铺天盖地的宣传后，2017-2019间引来国内企业IT架构中台化改造的顶峰。伴随这个疯狂的过程，不管阿里内部还是外部都开始有质疑声音出现。

其实在2016年时就有迹象，因为阿里作为一家生态公司，基本上是带着合作伙伴来给企业交付，基本上都做得不好，甚至失败。但非常轻易地把原因直接归结于“由于伙伴对互联网技术的理解和能力”。

因此在2017年，阿里成立了原生交付团队，希望能够树立一些标杆案例。我和公司的核心成员也都来自于这个团队。17-18年做下来，我发现阿里也做不好，但这次做不好的原因不是技术不行或项目上不了线，而是上线以后预期的效果没有达到，其本质是企业的IT组织能力无法驾驭复杂的互联网中台架构。当无法驾驭的时候，所谓的目标“敏捷响应，快速创新”就无从说起了。结果客户会反馈以下三类问题：

1. 不是说敏捷响应吗？为什么改个需求这么慢，不但时间更长，付出的成本也更高了？
2. 不是说能力中心吗？当引入新供应商或有新场景开发的时候，为什么前期做的能力中心不能支撑了？
3. 不是说性能好吗？为什么我投入的物理资源更多了？

关于这三个问题我们都能很容易找到原因：

第一个原因是因为中台架构需要一定的技术能力和经验才能有效地应用，就像一个只会骑自行车的人给他一辆汽车或者飞机，他也不能驾驭它们。微服务对研发、调试、运维的各个方面要求都有一定提升了，但企业的IT技术能力却没有跟上。

第二个原因是因为能力中心是一种面向业务的能力组织方式，它将不同的业务能力抽象出来，以服务的形式对内提供。然而，由于业务场景的差异，不同的业务需要的能力也会不同，因此能力中心需要不断迭代和升级。对于新引入的供应商或新场景开发，需要根据实际情况对能力中心进行定制化和扩展化，但谁来负责呢？新项目的供应商还是客户自己？

第三个原因是因为中台架构采用微服务来解决单点瓶颈问题，提高系统性能和可用性，但是在初始阶段，投入的资源可能会更多。每个模块至少需要两个实例来保障高可用性，因此物理资源的投入量可能会比以前更多。

原因找到了，但是方案在哪里？在巨大的利益面前，软件厂家都选择忽悠，云厂商选择纵容，一起开始极限耍流氓。

云厂商在这个模式下不但卖出了更多的云资源，同时卖出了配套的运维工具。纵容软件厂商告诉企业：“中台是持续演进和快速迭代的过程，因此企业需要组建中台架构团队来实现，而他们则通过中台项目落地将中台建设方法论传授给企业。”这句话的前半部分是正确的，因为我们之前提到企业需要具备敏捷响应业务的能力，即应变能力，因为应变是不断变化的。然而，后半部分是不正确的，因为今天的企业已经有能力组建团队的话，那么这些中台软件公司到底有什么用呢？企业真的缺少方法论吗？

这种行为基本上算是在向企业收取智商税，都在欺诈，因为很多企业根本找不到足够懂互联网架构的人才。明白流氓在哪里了吗？这些流氓公司赚了很多钱，最后责怪企业无法招到人才，这是企业的责任。

二、2020年至今，是新一代企业IT架构，逐渐去除“中台崇拜”跌入谷底的过程，是进入理性反思寻找方向的过程。

在逐渐去除“中台崇拜”和进入理性反思寻找方向的过程中，发生了有两个标志性事件，以及一个趋势逐渐形成。

第一个标志性的事件是：2020年1月18日一篇36氪出的文章【中台，我信了你的邪】，其中大量描述了中台项目失败导致CIO离职、背锅的现象。1月18日在当时也被戏称“中台”历史上最“困难”的一天。面对这篇文章的论点，有悲观的，也有乐观的。我属于乐观派，我一直认为“敏捷响应，低成本的快速创新”，一定是企业数字化转型的核心诉求。但支持该目标的新一代企业IT架构，肯定不是照搬照抄互联网大厂的经验。

第二个标志性的事件是：2023年5月9日一篇国外的文章【从微服务转为单体架构、成本降低 90%】，该文章的意义在于，激励从业人员敢于反思当下主流技术的不足，同时它揭开新一代企业IT架构应该如何应对企业数字化转型时预期与现状的矛盾，客户在数字化转型的项目时，对未来的预期非常高，因为这个时代有太多一夜成名的企业，当一个国民品牌的产生的时间从20-30年变成现在的2-3年。那么性能的扩展性，就是IT架构不得不考虑的事情。所以在我们思考新一代企业IT架构时，能否更进一步，即能满足客户对未来的发展预期，有兼顾当下的成本效应。

一个趋势逐渐形成，不论从舆论、实践，企业逐渐开始去除“中台崇拜”，回归对目标的思考。如何做到“敏捷响应，低成本的快速创新”，呈现出了不同的方式。我们来看看现在企业IT构架的几种方式，从中总结经验找到适合数字化时代的新一代企业IT架构。主要包括受中台影响深远的盲从派、观望的保守派，以及独立思考派。

（1）保守治疗派

他们基本上是头痛医头的典范。套装软件不合适，咱们就外挂系统。每个外挂系统都要跟套装软件集成或者外挂系统之间集成，导致接口混乱重复开发，就搞个集成平台对接口进行资产化、规范化、标准化管理。主数据在各个系统中不一致，则构建一个主数据平台统一主数据管理入口，通过主数据平台进行数据的管理与分发。既然称之为保守派，只是缓解了部分管理问题，但无法解决企业对“敏捷响应，低成本快速创新”的诉求。以及一些根本的弊端无法得到根治。

1. 每个外挂系统，自成一体。系统企业接手很困难，特别现在每个外挂系统都是基于互联网架构，但各自又因为技术标准、数据标准不一致，形成了互联网式的烟囱，导致接手和运维难度相对传统的单体应用要更大。

1. 应用之间数据割裂，相同数据需要多次同步，保存多份。无形中加大成本。

1. 一个业务流程可能涉及多个供应商开发，每个应用只能依赖原有供应商，但凡有个别供应商反应不及时，影响整体效率。

（2）激进盲从派

他们认为企业碰到的问题跟互联网在架构演进过程中碰到的问题非常类似，基本照搬照抄互联网架构。这里还是拿阿里举例子。

我们要先看互联网架构的发展，是如何一步步到今天提的中台架构概念的，每一步又解决了什么具体问题，我们以阿里架构变迁史为例来看下（如下图所示）：

(图阿里架构变迁史)

在2009年，淘宝上线了五彩石项目，这标志着淘宝从单体应用向服务化应用的时代迈出了一步。那么，淘宝为什么要开发五彩石项目呢？因为当时淘宝面临两个非常严峻的问题，一个是性能问题，数据库连接不足，数据库成为了瓶颈；另一个是效率问题，当时淘宝有百余个研发人员，但核心系统只有一套测试、预发、线上环境，导致研发需求排队等待。在开始五彩石项目之前，淘宝还做了千岛湖项目，用来验证服务化架构的可行性，将用户中心独立出来。随后，淘宝开启了五彩石项目，目标是通过增加人力来提升效率，通过增加机器来提升性能。

随着淘宝的业务发展，他们又面临了一个问题：各个服务之间有很多重复的建设，效率低下。为了解决这个问题，淘宝开始从服务化转向平台化，并创立了“共享业务事业部”，将重复建设的公共业务分配给这个事业部，以避免成本浪费。这些公共业务包括商品平台、交易平台和结算平台等。平台化的目标是规避服务化没有规划导致的重复建设问题。

但是随着业务的快速发展，淘宝变成了一个拥有几十个事业部的巨型企业，而这带来了新的问题：效率问题。例如，如果需要在一个业务线上做出改动，需要与十几个平台进行沟通，这是非常低效的。同时，对于一个平台来说，需要面对来自不同事业部的需求，这需要平台研发人员具备理解和抽象所有业务线需求的能力，这让平台研发人员感觉回到了单体应用时代，所有的需求都要排队，即使增加人力也无法提高效率。这个问题主要表现在交易平台上。

为了解决这个问题，淘宝提出了中台的概念，中台是在一套规范下建立的，让具有专业技能的团队自主决策业务系统发展的平台。中台的目标是弱化平台的业务特性，提供通用能力。简而言之，就是将“共享业务”中的“业务”两个字去掉，只提供通用能力的平台

我们将每个阶段的核心目标总结为一句话：

1. 从单体到服务：通过增加人员和机器来提高效率和性能；
2. 从服务化到平台化：解决服务化阶段因缺乏规划而导致的重复建设问题；
3. 平台化到中台化：在一套规范下，让各业务团队自行决定业务系统发展，适用于多个业务线或多个场景应用的独立发展。

类似地，在企业数字化转型过程中，也面临着类似的问题：

1. 随着企业业务在线化，对系统性能和稳定性提出了更高的要求，但由于内部系统之间的割裂，导致很多重复建设。因此，我们需要进行服务化和平台化；
2. 在数字化时代还没有出现一个供应商能够解决企业所有的商业场景问题，所以需要多个供应商共同参与。我们可以将供应商类比为各业务线，在一套规范下让供应商或业务线自行决定业务系统的发展。

然而，阿里的中台架构方案并不能直接照搬到企业中。因为阿里的中台架构采用了平台共建模式，即让业务线基于平台设计的规范共同开发。这本质上还是平台主导模式，对企业来说历史包袱较大。在企业中，让不同背景的研发一起共建交易或商品平台是非常复杂的事情。平台化已经足够复杂，再加上共建会导致企业架构的负载过重，这对企业来说就不再是赋能，而是“内耗”。

同样只要我们稍加思考，企业面临的效率问题跟互联网面临的效率问题也是有本质区别的。

1. 企业因为IT组织能力无法与数字化转型的速度匹配，缺乏足够的人才支持。企业需要寻找工具和技术来降低开发难度，同时提高个人开发效率。

1. 阿里拥有众多优秀的人才，需要解决团队协作和知识共享的问题，即协同开发的效率。

（3）独立思考派

1.发掘诉求的本质根源

随着互联网的发展不断推动企业业务在线化，我们发现数字化时代，企业在以下三个层面发生了质的变化：

首先，从竞争环境来看，企业竞争已经超越了单一企业的范畴，转变为整个价值链网络的竞争。这意味着企业不再仅仅关注自身的发展，而是需要与上下游伙伴紧密合作，共同应对市场竞争。

其次，在业务建设内容方面，企业不再局限于内部管理，而是更加注重业务在线化和生态在线化（协同）。这种转变旨在支持现有业务的发展，并为企业未来的业务创新赋能。同时，这种转变也能够将企业内部的变化实时地反映到整个价值链网络中，促进整个生态系统的协同发展。

最后，从技术变革的角度来看，对技术提出了更高的要求。特别是在需求响应速度、用户体验、系统极限承载力以及智能化等方面的提升，以应对市场的快速变化和持续创新的需求。可以看出对研发人员的需求量大幅增加，同时对他们的要求也变得更加严格和高标准。

因此，在数字化转型过程中，企业需要综合考虑全链路业务解决方案的成熟度以及数字化场景的快速变化和持续创新诉求。只有这样，企业才能在激烈的市场竞争中立于不败之地，实现可持续发展。

2.思考问题的解法

在这里也分享下笔者的思考，而且这些思考跟独立思考派沟通完以后，有着不默而合的默契。在2017年-2018年在做中台对外交付项目的时候，觉察到了两个核心问题：

1. 绝大部份企业的IT组织能力无法驾驭复杂的互联网架构。
2. 中台概念推动新一代企业IT架构的思潮，有着积极的意义，但遗憾的是它在过程中无法真正起到作用。作为软件公司，这类项目实施落地对人员要求极高，根本无法复制。

当时之所以会面临困境，我主要有三个方面的反思：

1. 我们不应该依托于提升研发人员的能力，而是降低互联网架构的门槛。
2. 我们不应该只是输出中台方法论，而是把方法论固化到技术平台中去。
3. 我们不应该只能服务大企业，而是真正赋能不同IT组织能力的企业，让它们都具备持续创新的能力。

企业需要构建，适应“数字化场景的快速变化和持续创新诉求”的数字化底座，它必须囊括技术标准、数据标准、应用标准，这些标准不应该只是停留在方法论层面，而是固化到平台中，以平台特征能力的方式提供支持，做到跟单一研发人员无关。

1. 技术标准：满未来软件特性，同时所有特性由平台自动提供，跟单一研发人员能力无关。不改变研发人员习惯的前提下，提升研发人员的效率，降低研发难度。能够让专业研发与公民研发共同参与，专业研发专注核心业务平台的研发与迭代，公民研发可以参与临时性或者应急需求的开发。
2. 数据标准：建立XX集团数据标准，提供开箱即用的业务数据库。同时提供上层业务层基于标准数据的扩展能力。
3. 应用标准：通过前端交互规范建立应用集成门户，和体验一致的交互标准。同时建立应用管理运维规范。

三、新一代企业IT架构应关注哪些特性

在数字化时代，在新一代企业IT架构领域都关注哪些特征，而这些特征又应与具体研发人员的个体能力无关。我将从在软件工程、架构与技术的组合应用上，给出我的思考，这里主要介绍特征与用途。

先做个名称解释，下文中涉及“标品”、“升级”、“扩展逻辑”，这是站在软件公司角度出发描述的，如果是企业内部可以把标品理解为特定业务应用平台，升级则是业务应用平台的正常规划迭代，扩展逻辑理解为脱离平台发展的临时性需求。

（1）可逆计算

（可逆计算在应用上的特征图）

调查发现企业研发至少有40%的精力在跟各条业务线的团队在评审项目需求，判断需求是否合理。而且业务线对需求完善时间要求紧，每天盯着研发进度，经常问“这个需求什么时候支持，我们等着用”。导致产研部门的研发抱怨产品节奏乱，无法按照自身节奏进行迭代，被项目推着走，没有时间思考，人手不足，加班多，工作压力大……

该特性很好的规避了研发因为时间紧迫，写的一些临时代码腐蚀核心业务系统。它需要做到不论从数据模型、业务逻辑、交互展示都能有扩展能力，并且这些扩展能力与个体研发无关才行。它同时所描述的也是一个具备差量计算能力的软件架构模式，它允许用户通过添加或移除扩展包来定制标准应用，同时保持应用的可逆性和独立性。这种架构模式的核心优势在于其灵活性和可维护性，使得应用的定制和恢复变得简单而高效。

（2）专业研发与公民研发共同参与

（专业研发与公民研发共同参与在应用上的特征图）

它所描述是在应用开发的整个生命周期中，专业研发专注在标品的长期规划与迭代，当出现临时性的需求或者应急性的辅助场景则由非专业人士进行即公民研发方式进行。这种模式下，专业研发可以按照规划有节奏的迭代产品，做更高级的事情，不至于忙于应对临时性的事务没有深度思考，更加避免了因为临时代码堆积导致产品从内部腐化。同时利用独立的扩展逻辑包和无代码方式解决了业务的紧迫感，毕竟业务需求的合理性是很难争论出高低的。它在第一个特性基础上让研发效能进一步得到释放。

它本质是：在专业研发在以低代码的方式下实现应用，并通过无代码的方式，快速扩展逻辑功能和创建辅助性应用。整个过程无缝衔接，我们给他取个名字专业名称叫：“低无一体”。它大大降低了技术门槛，使得专业和非专业的研发人员都能参与到应用扩展和定制中来。此外，它还提高了业务响应能力，使得企业能够更快速地适应市场变化和客户需求。

（3）基于平台级别的AOP能力出现反向集成

（反向集成在应用上的特征图）

平台级别的AOP（面向切面编程）能力允许开发者在应用程序的特定点“切入”额外的逻辑，而无需修改原有的业务代码。这种能力特别适用于横向追加平台逻辑，即在多个不同服务或功能点插入通用的处理逻辑，如日志记录、权限检查、审计、多租户、多语言等。过往在微服务架构中，这些能力都需要业务系统各自主动去对接，有了平台级别的AOP能力，则这些通用能力可以反向为所有业务系统增加特性能力，无需业务系统研发感知。这种现象我们称之为“反向集成”，能让业务研发更加专注在业务研发本身，不需要关心与业务无关的通用功能上。

AOP的核心思想是将这些横切关注点（cross-cutting concerns）从业务逻辑中分离出来，使得业务代码更加清晰和专注于其核心功能。在平台级别的AOP中，标准化协议是实现这一能力的关键。平台具备统一的入口和扩展能力是非常重要的，因为它允许开发者在不修改现有代码的情况下添加新功能或修改现有功能的行为。这种能力对于快速响应业务需求变化、减少维护成本和提高代码质量都是非常有益的。

（4）应用研发与部署无关

应用研发与部署无关的理念确实为现代软件架构带来了显著的优势，它使得研发团队能够专注于业务逻辑和功能实现，而无需担心具体的部署细节。这种分离带来了灵活性、效率以及成本效益的多重提升。

首先，应该可分可合的能力使得系统能够灵活应对业务量的变化。在业务量小的时候，可以采用单体部署的方式，简化部署流程，降低初期成本。随着业务量的增长，系统可以平滑地过渡到分布式部署，通过拆分微服务来提高系统的处理能力和扩展性。这种灵活性确保了系统既能满足未来发展的需要，又能兼顾当下的成本效益。

其次，应用级别扩容的能力使得系统性能不再受限。通过增加微服务实例或调整资源配置，系统可以按需进行扩容，从而确保在业务高峰期或突发流量下仍能保持稳定的性能。这种按需扩容的方式不仅提高了系统的可靠性，还降低了运维成本。

四、引入CDM层让数据标准不在是文档

这里我们借鉴微软的CDM理念，CDM这个概念最早是2016年微软宣布“以Dynamics 365的形式改造其CRM和ERP”战略时提出的。微软给它的定义是“用于存储和管理业务实体的业务数据库，而且是开箱即用的”。CDM不仅仅提供标准实体，它还允许用户建立个性化的实体，用户可以扩展标准实体也可以增加和标准实体相关的新实体。

CDM可能并不性感，但绝对是非常必要的。它成为了微软的很多产品的基础，是构建了无数业务领域的原型。同时微软也期望它能成为快速实现数据交换和迁移的标准，这个有点像菜鸟网络推出的奇门，让所有TMS、OMS、WMS都基于一套数据接口API进行互通，一套标准是为了解决一个行业问题，而不是具体某一个企业一个集团的问题。 我们发现CDM的理念跟我们想要的“企业级的数据标准”是非常吻合的。但是我们也不能照搬照抄，虽然微软的CDM很好的解决了数据割裂问题，但就模型来说就够大家喝一壶了，模型库非常庞大而且复杂，学习成本巨高。

（1）数字化时代软件会产生新的技术流派

我们知道传统软件的设计理念：侧重在模型对业务支撑全面性上。优点体现为配置丰富，缺点模型设计过于复杂，刚开始有前瞻性，但在理解、维护都非常困难，随着业务发展系统原先的设计逐渐腐化，异常笨重。 而新一代的企业IT架构的CDM设计理念：侧重在简单、灵活、统一上，体现为在上层应用开发时，每一业务领域保持独立，模型简单易懂，并结合未来软件特征中提到的低代码开发机制进行快速开发，灵活应对业务变化。 所以我更想说新一代的企业IT架构中描述的CDM是在微软CDM的原有基础上，与互联网架构结合，利用低代码开发平台特性形成新的工程化建议。它不以“把模型抽象到极致，支撑所有业务可能性”为目标，而是抽象80%通用的设计，保持模型简单可复用，来解决数据割裂问题，并保持业务线独立自主，快速创新的能力。

（2）CDM本质是创新的工程化建议

引入CDM以后系统工程结构会有什么变化，跟大家认知的互联网架构有什么区别。

原本上层的业务线系统，需要调用各个业务平台提供的功能，增加CDM以后也就是我们右的图，每个业务线就像一个独立右边。看上去复杂了，其实对业务线来说更加简单了。

互联网整体平台化带来的问题：

1.业务线每次业务调整都需要给各个平台提需求

2.业务平台研发需要了解所有业务线的知识再做设计，对研发要求非常高

3.各个业务域的不同需求相互影响包括系统稳定性、研发对需求响应的及时性

结合低代码特性提出的新工程建议：

1.一些通用性模块继续以平台化的方式存在，能力完全复用。

2.业务线自建业务平台，保持业务线的独立性和敏捷性

3.业务线以CDM为原型，保证核心数据不割裂，形成一致的数据规范

互联网整体平台化

引入CDM层的新工程

（3）CDM思路示意图

该示例中CDM的商品域不仅仅提供标准实体，保证各个业务系统的对商品的通用需求、简单易懂，在业务产品中如全渠道运营、B2B交易等系统以此为基础建立属于自身个性化的实体，可以扩展标准实体也可以增加和标准实体相关的新实体。

带来的好处：

1.通过多种继承方式，继承后的模型可扩展模型本身、模型行为等，从而解决业务独立性问题。

2.通过CDM层统一数据模型，从而解决多应用数据割裂问题

五、新一代企业IT架构初露端倪

Gartner的预测：到2024年，所有应用程序开发活动当中的65%将通过低代码的方式完成。低代码在细分领域的差异化需求将被重构，复杂、核心业务场景的个性化迭代特性对低代码需求越来越高。在前文提到，“技术变革的角度来看，对技术提出了更高的要求。特别是在需求响应速度、用户体验、系统极限承载力以及智能化等方面的提升，以应对市场的快速变化和持续创新的需求。可以看出对研发人员的需求量大幅增加，同时对他们的要求也变得更加严格和高标准”。那么低代码是解决该问题的核心手段，数字化化时代低代码应该具备应对复杂多变的场景能力。

要打造新一代企业IT架构，至少需要从四个维度在展开：

第一层：是以低代码研发平台为基础输出互联网架构下的软件快速开发标准，在这一层我们需要封装互联网的高并发、大数据的能力，并且针对这些跟业务无关的基础功能提供标准化实现，让上层的应用研发专注在业务本身上。在这次一层让所有的技术标准都固化到研发平台，我们关注的特性都由低代码研发平台去承接，从而做到与个体能力无关。

第二层：是通用数据模型层，如果第一层输出的技术标准，那么这一层输出的是数据标准的实现方式。满足不同软件基于一套数据标准的扩展能力。

第三层：是业务应用层，在这层我们要支持内外部共同参与。

第四层：是无代码设计器以及应用市场，由非专业人士进行即公民研发利用无代码设计器来满足临时性的需求或者应急性的辅助场景。应用市场上管理会包括所有自建、第三方、以及无代码应用。

总结来说新一代企业IT架构，需要开放式地让企业自身以及不同的软件供应商共同参与，遵循相同技术、数据规范，打造一体化无需集成的企业级各类软件。

（1）技术路径选择，诠释低代码新模式

我们不会与其他无代码平台进行比较，因为它们不能解决业务复杂性的问题。相反，我们将重点介绍三种不同的低代码平台模式。

第一种模式是最基础的低代码平台，也被称为代码生成器。它通过预定义应用程序模板和必要的配置生成代码，简化了工程搭建并提供了一些基础逻辑。虽然在信息化时代内部流程标准化方面较为适合，但在数字化时代外部协同业务在线的情况下就不那么合适了。因为这种模式不能减少研发难度和提高效率，也无法体现敏捷迭代快速创新的优势。

第二种模式是经典的低代码平台，以元数据为基础，以模型为驱动。当无法满足需要时，通过特定方式将代码以插件的形式注入平台，作为低代码平台的内置逻辑，供设计器使用。它的优点在于降低了研发门槛，当无法满足需求时才需要编写代码。它可以实现企业内部的复杂流程和复杂逻辑，但其性能和工程管理存在局限性。性能问题使其不适合处理互联网化的在线业务，而工程管理问题则使其不适合处理快速变化的业务。这也是许多研发人员反对低代码的核心原因之一，因为研发人员变成了辅助角色，而软件工程是一门需要技术能力的学科，让没有技术能力的人主导是违反常理的。对于产研来说，产品需要迭代规划，需要多人协作，需要工程化管理。

第三种模式是由数式Oinone提出的基于互联网架构的低代码平台，它采用无一体的设计。首先，数式Oinone屏蔽了互联网架构带来的复杂性。其次，同样以元数据为基础，以模型为驱动，但是元数据的生成方式有两种：一种是使用无代码设计器（与经典低代码相同），另一种是通过代码来描述元数据。通过使用代码来描述元数据，可以无缝地与代码衔接，并在不改变研发习惯的情况下降低门槛、提高效率，并进行工程化管理。

最后总结来说：低无一体不仅仅是指两种模式的结合，还包括两种模式的融合应用方式。具体来说，这种融合应用方式可以分为两种情况：

1. 当开发核心产品时，主要采用低代码开发，无代码设计器作为辅助。这种方式可以提高开发效率和代码质量，同时保证产品的快速迭代和升级。
2. 当需要满足个性化或非产品支持的需求时，主要采用无代码设计器，低代码作为辅助。这种方式可以快速地满足客户需求，并且避免对产品的核心代码产生影响。

简单来说，低代码模式适用于产品的迭代升级，而无代码设计器则适用于满足个性化和非产品支撑的额外需求。低代码和无代码模式在整个软件生命周期中都有各自的价值，在不同场景下可以相互融合，发挥最大的优势。

（2）新一代企业IT架构，落地选型方式

1.新一代企业IT架构的供应商应该具备以下核心能力：

2.企业对供应商的方案应该从以下三个维度进行验证。

1. 确保咱们各类场景情况能被实现
2. 验证咱们各位纬度效率有提升
3. 证明供应商方案符合咱们公司未来技术选型要求

3.新一代企业IT架构，从应用研发角度整体示意图参考