AI会带给企业架构新机遇吗？

前些年，“软件吞噬一切”好不容易成了大家的共识，解决了数字化必要性的问题，接着，去年还被不少人看作“大忽悠”的AI，今年就堂而皇之的喊上了“AI吞噬一切”，似乎要直接解决智能化的必要性问题。感觉世界就像超级英雄电影中的故事线一样，不是被这个吞了，就是被那个灭了，打个响指都能扑街。

不过AI带来的影响经常被正反两极化，一边是“神之一手”，一边是“斩杀线”，反正是讨好型人格，你说啥AI也不在意。AI可以不在意，一个存在的不存在而已，我们却没法不在意，毕竟，软件工程是铁定了会改变的，昨天腾讯TVP七周年庆典上，听到一位嘉宾演讲时说，一位朋友在他开始演讲前跟他说，年初说的AI编程，一旦用上了就回不去了，好像今年确实就这样回不去了。

AI必然会改变软件工程，所以很多人的工作方式都会被改变，上一篇文章中我也说到，我自己今年也实际看了从前端到后端、从功能到架构、从需求到运维，各个位置上都有挺好的探索和实践，而且往往是3、4个人，3、4个月就搞出了些东西，有专职搞出来的，也有不少兼职搞出来的，说实话，如果真心拥抱，IT侧本就应该是应用最快的群体，毕竟这轮大模型浪潮，编程能力一直是模型毕业的“准生证”，而谁能改变IT，谁就能改变数字化的进程。

软件工程的改变也一定会涉及到企业架构，在这个大的应用革新背景下，企业架构要思考的事情也少不了。

一、企业架构还需要吗？

软件架构必然还是需要的，因为AI也是按照结构写软件的，软件是工笔画不是大写意，就算用户输入的需求是模糊的，AI自己也把它清晰化、结构化了，只不过，说的越模糊出来的东西要调整的就越多，所以，软件架构依然是必须的，无非是AI把架构能力内化了。

看着AI编程其实挺规范的，他也愿意遵守交给他的规范，最近一些实践分享中，也有不少人把开发规范以skill的方式交给AI去遵守，之前rules之类的东西，以后也许还有其他方式。AI最大的优点莫过于他愿意遵守，虽然有时会因为幻觉、会因为“偷懒”出些岔子，但总体是靠谱的。

如果软件架构需要，那企业架构需不需要呢？我认为还是需要的，AI写软件的方式是跟人学的，就算以后自己开宗立派了，软件大体还是结构化的，只是遵循哪种结构罢了。当软件的规模小时，你不会感觉到宏观架构的存在必要性，而软件多了、交互多了的时候，宏观架构的存在就有必要性了，企业架构的总体原则也就是“先整体，后局部；先定位，再解决”，人做、AI做都一样，软件规模庞大了，都需要通过视图更好地建立知识结构，来完成软件设计，企业架构提供的最有价值的东西莫过于这样一套视图。

当下最火的本体论，不也是构建本体视图来理解业务吗？如果业务复杂度低，没有本体论，AI也能聊个七七八八，如果业务复杂度高或者希望AI的回答非常符合本企业的业务环境，那就需要通过本体论等方式来加强语境边界、强化语义。所以，作为解决规模复杂度问题的有效工具，企业架构，也还是有用的，尤其是它提供的视图。

二、需要什么样的企业架构？

企业架构还分样子吗？当然分，“一花一世界、一叶一菩提”，每个企业做出来的企业架构都是看着有亲戚，其实都不亲，只有血缘上的“远亲”，找个“近邻”都难。想着AI应用的发展，我们最需要的是最符合本企业实际样子的企业架构，那是AI给你建议的起点。大家可能会奇怪，这东西还有不合自己样子的？当然有，总盯着别人的样子做，总想着别人的方法做，做出来的就不一定向自己的样子，这也是这个行当里常有的事情，比起自己家的问题，总是更关心别人家的问题，总想在自己家镜子里照出个别人。

企业架构做起来不难，工作量也没有想象的大，而且可以渐进式或者策略式的完成，这方法“成”之于大型企业，也“迷”之于大型企业，毕竟十几年前做法还不成熟的时候，只有大型企业可以花那个时间、精力，踩那个坑、雷。随着企业自己数字化进程中软件数量的增多，很多企业已经把自己推上了需要整体视图的治理阶段，但是还在对大型企业的实施经验存“迷”，也存“谜”，即想要又困惑。

其实每个企业需要的都是自己的架构，不是别人的方法也不是别人的资产，都需要在自己环境下搞个自己兜得住、管得了、用得上的架构，这跟大模型需要本体论有点儿相似，需要把一个通用的东西变成你自己企业环境里的东西。随着方法实践经验的增加，这个领域的实施，就不要总是“迷”了，更不要把自己家的架构、方法也做成了“谜”。

三、需要怎么做企业架构？

现在做企业架构必须一只眼睛看着AI了，我觉得还没到两只眼睛都得看着AI的时候，什么时候两只眼睛都要看AI？当然是AI编程工具等开发助手可以真的让企业觉得能够放心地大范围重构遗留系统，多智能体协同等应用模式也不存在运行效率的时候，也就是说可以完全基于AI构建、运行、管理大型复杂系统而且没有效率问题的时候。

那个时候还没到，所以先一只眼睛看吧。一只眼睛看什么呢？我觉得先看数据架构，企业架构方法落地实施中，其实受益最大的就是企业的数据治理，如果用心做，做好逻辑数据模型，可以从源头上处理很多数据治理问题，提升数据质量，当然，这里要强调下是面向业务对象的实体级逻辑数据模型，那是整个架构结构划分的重要依据，我自己常讲的就是“以数据为锚”，这个是核心，恰好AI也很依赖于数据，不仅是高质量的数据集，还依赖数据形式反映的业务知识，比如本体论这种东西。数据编织、双模数据库，这些新的数据管理手段也都需要、也都支持从源头上治理好数据了，所以也不要只盯着AI看，还有别的技术也在发展。

就架构而言，数据模型的重要性要略高于流程模型，尽管企业很重视流程管理，但是流程就像流水，是有一定变化自由度的，是遇着“石头”就会绕的，这个“石头”就是岗位，就是组织结构，组织结构、岗位变化，数据可能没啥变化，但是流程可能会变化很大，所以，流程不太适合于在业务有一定复杂度的企业中用来切分结构，它更适合描述协作，所以也有人讲，流程是系统集成后的表现。而且流程实现技术也越来越支持流程的灵活实现、灵活定义，流程方面重要的是从流程中分离出规则，分离出可固化的业务知识，说悬一点儿就是流程与能力的分离。

从做企业架构的实施难度上来讲，组织逻辑数据模型，尤其是实体级逻辑数据模型的建设工作要比组织同等规模的流程模型建设容易开展，当然，我不是说流程不要建了，而是有实施困难时，可以优先开展逻辑数据模型建设，而跟着数字化项目的节奏逐渐发展流程模型建设，最终达到补齐的目标，搞个最终一致性。建设逻辑数据模型这个工作可以逆向，尤其是可以用AI逆向。

这只眼睛除了盯着数据之外，当然也要盯着应用形态的变化，但还是一只眼就可以，毕竟AI现在在遗留系统中的覆盖范围有限，而很多实施也都是不太触动原有业务系统的“旁路”模式，毕竟智能体就是提供了这种自由度的实施模式。应用形态的变化其实会促进遗留系统的服务化、标准化，这样才能更好地通过智能体模式与AI进行配合，所以，多少还是会带来遗留系统的变化，只不过未必是完全替换。当然，有替换的壮志也没问题，就是要考虑下，基于AI的应用多少会有些延迟的，有时候也可能延迟还会很大，所以要谨慎选择工作流模式、AI介入程度。

流程、数据、应用三个架构的一致就是企业架构中常说的“融合一致的架构”的基础。

四、做出来的架构还跟传统架构分层一样吗？

这个问题怎么说呢，架构分层其实是对整体结构的一种抽象，但是，经常让人混淆的是概念图和企业架构制品中该有的架构图。概念图只要说清楚一个人是怎么想的就行了，企业架构制品中该有的架构图是分视角的，不同的视角图是不一样的，比如方法论层面高阶抽象的元模型，这也是架构图，而且还能持续分级；价值链自己可以是个高阶业务架构视图，但也可以不是，而是作为流程树的“根”；业务领域可以是局部的职能化视图，也可以是产品化的贯穿价值链的视图；流程图可以用不同的分级分类，但是最底层一般是跨岗位工作流图、岗位任务（也要有叫活动的）和任务执行步骤，也就是从多岗到单岗的执行过程描述，其上则可能有千奇百怪的分类聚合；数据模型也有自己的顶级分类、主题域、实体关系图等不同层级的视图；应用架构也有自己的架构分层，但有时又可以跟技术架构共用分层结构，而自身只关注应用的分布和关系；技术架构不用说，当然也有自己的分层结构。企业架构里能够一张图讲很多问题的也就只能是个概念图，因为你想说的越多你可能就越说不清楚。

所以，如果想研究AI的架构，可以适当区分下，是在研究什么视角的架构。笔者自己喜欢看业务视角的，而且写文章多数是写概念图，毕竟文章这东西聊方向、聊感受的时候多，而走进企业，走到实施中才会画具体的企业架构制品要求的视图，那些图一般不会出现在文章中，有些企业就算公开一些，也会脱敏、混淆，不一定会把真的拿出来，最多也是把高层汇报用的拿出来说说。

从技术架构视角看的AI架构相对清晰，是一套AI体系的技术栈；从应用架构视角看，会出现跟遗留系统的关系问题，也就是智能体或者智能体所在的工作流与遗留系统的关系，这涉及到如何定义AI融入企业级应用架构的方式，而不是孤立地看AI应用，因为孤立地看AI应用，你怎么画图都行啊，系统都做出来了，说清楚事实就行了。

但是，多数企业的AI、智能体还是要考虑应用到传统业务过程中的，那样才是转型啊。所以，智能体在应用架构上到底该定位在哪一层上，如果企业原来是有类似于总线之类的编排类机制的，智能体中有一部分也可能被划分为编排层，毕竟智能体内部是可以当成一个调度来看的，即可能是脚本，也可以是调用，如果非要细分，也可以分成有编排和无编排的，有编排的当成编排层，或者专门以一个应用的身份在做编排，而无编排的就入了功能层，skill之类的也可以糊里糊涂地分到功能层的，当然分到哪一层主要解决的是“作用定位”问题。对于没有编排类机制的，自然会当成功能层去看，跟一个微服务也类似，也可能会乱七八糟的搞一堆横向调用。

其实从现有常见的智能体平台来看，处理流程的编排层，处理功能的智能体层是比较常见的分层方式。我自己做的模拟业务系统，从分层上来看更像是编排、智能体、传统服务和模型这几层，模型一般是处于下层的，但是智能体和传统服务到底是南北关系还是东西关系，这个可能见仁见智，还是像刚才讲的，如果有类似总线机制，大概率应该是东西关系，如果没有，就会是南北关系，因为出于安全考虑，可能稳定执行、写入数据还是会由传统服务完成，不过很多时候实施都是不太规范的，一个企业里两种关系并存也很正常吧，有的时候还得看人呢，看是谁做的。总的来说，智能体更适合放在应用架构上看。

数据架构方面按理说不会有特殊变化，尤其是逻辑数据模型，这里本来就是业务对象，跟是不是AI应用关系不大，AI不过是系统的构建、运行方式的变化，多数不是业务处理对象上的直接变化。

业务架构方面比较有趣的地方是，AI要不要作为一个泳道出现在流程图中，其实严格的业务架构建模是不打算这么做的，因为业务模型描述的是不依赖于特定业务系统的情况下，业务本原的运行模式，出现在流程图中的一般是岗位、角色，而他们执行的任务，代表着岗位、角色的职责，或者说责任，这是系统无法替代的，说的难听点儿，业务系统运行出了问题，你也许可以让IT人员背锅，但是让系统背锅就没啥意义了，“审葫芦问黄瓜”只能是说书人的桥段，无法用在现实世界里。我们可以把AI当人看，但是没法让他当人去背锅，最近一些有趣的段子，比如搬到法庭上的证据中也有AI“生成”的，这显然是无效的。既然AI不能背锅，那他出现在流程中的意义是什么呢？总不能AI错了，下个月少给点儿算力、少给点儿电吧。

AI虽然出现在流程图中的意义不大，但是AI的发展却着实能改变流程图，也就是说不排除AI的应用导致大量的岗位、角色被整合了，做一个工作需要过的“手”越来越少了，一些非必要的传递、审核过程慢慢就没了，而且也可能流程逐渐由上而下发起的也增多了，当然这个“上”未必指的都是最高管理层，而是一件事情的最高责任权限岗位，信息经过AI分析后第一时间到达决策者，然后再指派到执行者，AI辅助分析应该会大大缩短指挥链，就像在军队中已经发生的那样，这可能会导致流程的变化。也许以后衡量一个企业效率的极简方式就是看他流程图的长短，这背后就是企业中的每个人与AI配合的好坏。

五、企业架构师们要多学点儿什么？

自己操练AI编程，自己思考AI模式下的软件工程、企业架构，以后不会用AI编程，可能都慢慢失去成为企业架构师的机会了，本来AI就搞得用人模式像有断层似的，而且以后架构的主要讨论对象中AI可能占据的时间越来越多，不跟AI聊，架构讨论机会都少了，要是等到需要两只眼睛都看着AI的时候，不能跟AI聊实现，还怎么当企业架构师呢？顺便说一句，未来就真的是至少人人都是业务架构师了吧！