如何应对企业架构中的复杂度问题？

企业架构经常被抱怨的问题就是复杂度问题——太复杂，做不来。这方面只能说见仁见智，没法有一个统一的、令人满意的解释。毕竟，抽象讨论共性问题只是动动脑、动动嘴，笔者自己也常在一些聊天群里做这样的事情，但这不过是练练“口才”罢了。如果真要聊复杂度控制，那么脱离实际语境去讨论就属于有点“臆想”了。很多聊天，聊着聊着就没意思了，也是这个原因，抛出一个概念图来就要开始“大杀四方”，谁真知道这张图的背后到底是啥呢？

架构的复杂度很令人头疼，归结起来常见原因可能有以下几种：业务复杂、方法复杂、周期叠加、阳奉阴违。

这是架构复杂度最基本的来源，架构从业务开始设计，业务复杂架构自然就复杂。比如，一个大型集团的业务架构，哪怕业务相对单一，业务自身的复杂性也不会太低，因为组织的庞杂本身就带动了业务的复杂，结构梳理起来就不会太容易，而且对流程的确认、调整都很难简单取得共识，天天都在处理的事情，也一样有说不清道不明之感。最怕的是，有些企业经常会觉得自己的业务是清楚的，但真到要较真做开发时，却怎么也定不下来。组织最奇特之处就是，可以很模糊地前进，但却给人以清晰的错觉，这可能也是流程管理一直不容易让人充分认知自己价值的一个原因吧。

小企业就会很简单吗？未必，笔者自己就是“一人企业”，但企业就是企业，无关乎是不是“一人”，签约、交付、开票、报税、发薪、宣传、设计、学习、交流等等，没有一样可以少的，只不过没必要给“一人”建立明确的流程而已。在此基础上，人数放大到一定程度之后，没有流程就是很低效的了。

但是，从流程建立开始，显式的复杂度管理也就开始了，如果企业没有类似“马斯克五步工作法”或者以前提倡的丰田精益管理之类的工作思路、管理追求的话，流程会新账压旧账，越来越乱，事情一样能办，就是低效之处很多。这时候不照镜子还勉强，一照镜子可能把自己吓一跳，吓到了之后反倒说架构复杂。

按照笔者自己的经验，人数 1000 人左右的企业，人手一个流程不是什么难事儿，也就是大约有 1000 个左右大小不一的流程或者叫活动，这一点从 APQC 的参考流程中也能侧面验证下，这里我们先不讨论颗粒度问题。以此为界，人数再多了之后，如果管理得当，流程数量增加未必就是正相关的；人数比这少，如果不能有意控制，流程数量下降也未必很明显，但是人数降到了哪个数量级，流程数量会出现明显的下降，笔者没有了解过，读者可以自己调查下。至少作为“一人企业”，笔者要干的事情也能凑够一个完整的价值链。

如果以此类推，非严谨论证的情况下，可能一个行业中，中等规模或者中等偏上的企业，流程复杂度已经足够高了，所以，中等规模的企业并非不需要架构能力。企业即便成长到更大规模，流程数量仍然可以有一定的控制，只是随着管理层级增加，会导致流程拉长。组织大到一定程度一般会“分裂”，也就是类似“分形”的方式产生小的“裂变体”，部门化、条线化的管理就类似这种。

如果流程控制得当，理想状态下是会有大量重复性流程出现，而不是真的增加了流程，这是“分裂”的复制结果，流程除了纵向拉长外，也会表现出横向拉长。管理得当的情况下，真实流程的增长数量应该是有限的，而很多集团企业的流程复杂实际上是标准化程度依然不高的表现。

标准化程度也左右了架构梳理结果的复杂度，很多企业觉得企业架构复杂，其实复杂的不是架构。做的过程让人觉得麻烦，正是为了消除标准化程度低导致的“杂乱”，但消除一次并非就结束了，为了保持不那么复杂，还要继续在流程优化上精进，这是热力学第二定律决定的，与架构无关。

所以从这个角度来讲，不要轻易谈降低架构复杂度这个问题。复杂度有个下限，再降低就只是在整体中转移复杂度的位置，而不是真的降低了。一个企业就是有 1000 个流程，如果流程数量优化不下去，还能怎么降低复杂度呢？如果在实现上就是想拼命降低，那业务人员还会觉得你做的系统是给他用的吗？

这个是方法论自己的毛病，但准确地说，是企业或者架构师、咨询师在落地实施过程中，对方法论适配的毛病。企业架构方法论不止一家，但家家不小，单看方法论，就没有很轻的，如果说介绍资料看着轻的话，那只是做法写得没有展开而已，如果真是完整做了全套架构，基本就没有太轻的方法。

单是流程梳理这一项就没听说过哪个企业做得轻松加愉快的，道理很简单，以前都是散步的走法，如今标准化了，忽然让人踢正步，那一步该多长、腿该抬多高，都得合计合计，顺便有些想甩的锅、想抢的碗也都搅合进来，所以，单就流程这一项来讲，谁都很难轻。要不要承受其重，那就需要企业自己掂量了，好处毕竟不是那么立竿见影，一个企业可能一两年功夫就能通过流程管理有所改善，但真到了所谓的提升整体竞争力，甚至堪称为人师表的境界，那估计得十年八年了。

流程梳理倒也可以有轻有重，轻重主要体现在对细节的关注上，比如，对最细的业务步骤、业务规则的梳理，都是可以控制的，因为不控制好的话，工作量会增加数倍。这个还是要取决于目的了，如果只想要整体视图，那就不关注细节，牺牲细节就是牺牲准确度，不要太高的准确度就行了；如果想要与开发深度连接，要的就是准确度，不太准确，不能指导细粒度结构划分、组间边界争端的流程，开发上是会看看而已，提供的指导意义不大，开发上还是以跟业务人员沟通得到的具体业务细节为准进行设计。

流程是架构梳理方法中耗时、耗人最高的一块，如果要轻，就要考虑这块是不是能越过，越过不是因为它不重要，而是企业承受不起，做不起全套的复杂操作，只能做基本能用的，这时就要考虑通过逻辑数据模型进行简化的架构梳理。降低方法复杂度并不是把所有东西都做浅就算降低，而是根据做架构的目标保证架构梳理出来的东西依然可用，如果只剩下轻飘飘一层，干啥都干不深，那还不如不做。

逻辑数据模型如果集中在实体级，耗时、耗人最少，而从架构视角看，企业架构方法要同时保证业务和技术两个视角都具备。技术视角主要是应用架构，要是把这个“轻”了，那开发上可能根本就不理解到底为啥要做企业架构；但如果没有业务视角，应用上以前搞不清的事情，即便搞了架构之后也还是不清楚，因为视角不完整。逻辑数据模型就是在无力完整梳理流程的情况下，作为独自承担业务视角这个重任的可选部分了，也是可以轻的一种选择。

单纯讲方法的复杂和简单是没有意义的，要根据目标和企业环境去考虑怎么做选择，这不是坐而论道的问题，只能是走进每一个企业去回答的问题。

企业的发展都是在给正在飞着的飞机换发动机，停下来调整好了再走，这是很理想的状态，几乎没有企业真做得到。所以，很多企业搞企业架构会很挠头，也都是因为飞机不能落地，都是在天上修的，这倒不是企业架构方法造成的复杂度，因为只要企业决定了要去解决那些问题，用不用企业架构方法，都是会在天上修飞机的。比较省事的做法是继续“挺”下去，直到真觉得“挺”不住。

老的系统不能一步替换、业务流程不能一下子调整到位、数据不能一天治理好、技术不能一天学会、生产一天不能停顿等等，这些问题交织在一起，学习周期、实施周期、新旧并行周期、市场周期都混在一起，会让方法看起来比其本来的复杂程度还要复杂。上文讲，“挺”到真“挺”不住，那时对方法复杂度的畏惧也会下降，所以“降低”复杂度，有时也是可以通过提高“刚需”程度来反向解决的。

周期叠加导致的复杂度是很难消解的，其实这个时候更需要的恰恰是企业架构主张的全局视角，通过全局视角判断优先级。实话实说，出现太高的周期叠加导致的复杂度时，架构工作未见得是第一位的，搞架构，晴天修房子最理想，但不下雨企业又注意不到房子漏，天一晴了又去忙别的了，所以常在漏雨时有感觉，但这个时候往往搞不太好，比修房子重要的事情可能太多了。真要在这个时候搞，就不是降低复杂度了，这属于迎难而上，需要的是定力和智慧。

这个指的是隐式架构导致的复杂程度，业务层执行的实际流程与业务架构梳理的流程不保持一致、技术侧执行的开发与企业架构设计的分工不一致，两侧的隐式架构都力量强大，那等于处处不一致，自然就复杂度爆棚了。这个问题不是方法问题，是管理问题和价值认可度问题，解决之道也不在方法本身，就算降低复杂度也未必有效。

这个问题的普遍程度之高也是令人叹息的，架构方法分开看的话，业务、应用、数据、技术、安全架构，其中的每个部分都不比同类方法更复杂。比如，很多人讲梳理流程如果用 BPMN 对业务人员而言太复杂，这其实没啥道理，就好像只有让人随便画流程才是合理的。笔者自己接触过多种业务上实际采用的流程画法，而且做业务人员时参加 ISO 贯标就画过比较标准的流程，至少不认为 BPMN 会是其中对业务人员而言最难理解的。

架构自己略微复杂之处是追求各个架构之间的协调一致，而很多企业都没做或者没做到这个衔接，如果单论各个架构部分，就说企业架构太复杂，那只能说是比较的可能不太充分。

综上，复杂度本身不是问题的根源，对其的控制也不是一概而论的，就像喜欢名牌就不会嫌名牌贵，喜欢廉价也不会真抱怨质量问题，都是根据需要做出的决策，都不盲目，只有脱离具体目标和实际环境聊复杂度会显得有些盲目。

付晓岩，天润聚粮执行董事总经理，原国有大型商业银行资深业务架构师。

《银行数字化转型》、《企业级业务架构设计：方法论与实践》和《聚合架构：面向数字生态的构件化企业架构》三书作者。中国计算机学会软件工程专委会委员、数字金融分会首批执行委员；国家工程实验室金融大数据应用与安全研究中心研究员；CIC 金融科技与数字经济发展专家委员会成员；信通院企业架构推进中心、组装式推进中心技术专家；中华全国数字化人才培育联盟专家委员会特聘专家；工信部中小企业发展促进中心产教融合产业实践教授；国家互联网数据中心产业技术创新战略联盟专家委员会副主任专家委员。