中台之上（十一）：企业级业务架构设计的“五难”「建议收藏」

大家好，又见面了，我是你们的朋友全栈君。

我们简单回顾一下，以业务架构的发展过程和对业务模型基本介绍作为开始，结合笔者的工作经验和自身一些不成熟的理解，在业务架构设计方面陆续讲到了企业战略解读、企业组织结构的影响、如何划分业务领域和流程、与流程建模配套的数据建模、企业级的模型标准化，并设计了一个虚拟的案例；在业务架构驱动开发方面，讲到了如何将业务架构设计转化为业务架构方案、业务架构师如何基于模型与项目开发团队沟通、项目开发团队如何基于模型开展设计、项目团队之间的协调、模型基于实施的调整和企业级项目完成后如何继续建立持久的企业级工作机制，之后还分析了与敏捷开发的关系。这已经算得上是一个完整的历程了，包括了企业级转型的规划、设计、实施及建成后的应用机制。企业级建设是个很艰难的过程，经历前面的介绍之后，我们不妨聊一聊企业级的实施之难，也给各位已经投入或者即将投入企业级转型的同仁们提供一点儿思路上的参考，或者就算帮大家发发牢骚、吐吐槽吧。

企业级是一个美好而艰难的愿景，了解“领域驱动设计（DDD）”的朋友可能会知道，DDD是不对企业级抱太大希望的，认为企业级的建设路径只能是一个领域一个领域的不断尝试融合，换句话说，DDD不认为企业级真的可以通过自顶向下的规划产生，只能是自底向上的生长；科技公司中如果说企业级的代表，可能莫过于阿里的“大中台”模式，但这个模式是“演化”出来的，有兴趣的朋友可以读读相关书籍，但阿里毕竟有个好处，其业务范围总体而言是垂直的电商领域，当然，这并不是说电商业务很简单、很单一，而是领域中还是有一定的公共部分可以抽离的，这个观点也得到一些阿里同学的认同。但说到金融，学过或者做过金融的同学可能有体会，这是一个很不“专业”的专业，里边东西五花八门，看似大家都在同一个领域，实际上却是“各怀鬼胎”，传统的存贷款跟票据业务其实没啥直接关系，票据跟金融市场沾边，但是关系也不深，代收代付不过是个约定转账，现金管理是个大杂烩，托管是另外一个领域，后来还多出个养老金，这几年新兴的资管、理财完全可以自成一体，不然支付宝、余额宝也不会发展那么迅速。说到底，大家的共性无非是客户都是同一群客户，围绕客户共建了一个账户体系，业务虽然差别很大，但是多数都得记账。也就是说，如果自顶向下看，客户和账务是应该企业级的，而其他部分，严谨地说，真就像DDD主张的那样，得一个领域一个领域去研究，这也是建模和标准化的难点。所以，企业级建设的难度跟企业所在行业的特点有直接关系，没有一个通用的企业级业务模型可以随便套，甚至一个行业内，企业跟企业之间内部特点的差别，也会决定企业级建设路径和结果的不同。

这算得上是企业级的第一难吧，也即，很难通过简单复制的方式快速切换到企业级。别人的经验，无论成败，对你而言都是个借鉴，自己的路还要自己走，但是实践中找个“老司机”带带路，找个做过企业级开发的科技公司帮助做转型还是比较稳的。

第二难，企业级多数情况下不是个技术问题。这是非常让技术人员为难的，因为这根本不在他们的能力范围之内。前面提到过综合积分的事情，这只是众多要协调的事例中的一个，如果是一个业务种类繁多、部门庞杂、等级森严的传统企业，建企业级不次于一场“内战“，一场对部门边界、协同关系的重新界定。你可能会觉得，真有那么可怕吗？如果没有那么可怕，我倒宁愿相信是以下两种情况中的一种：一是企业之前分工非常合理，无可挑剔；二是大家都没去触动真正要解决的问题，一团和气的结束了。前者基本是不可能的，而后者是非常可能的。如果真的是下了决心要做，对于一个传统企业而言，要改的东西实在太多了，而引入新方法、新思维产生的冲击也需要大量的时间去消化，是一个彻头彻尾的大转身。这其中，需要业务上做的调整不亚于技术上的调整，而对企业文化的调整尤为重要，现代管理学之父彼得·德鲁克曾说过这样一句名言：“文化能把战略当午餐吃掉（Culture eats strategy for lunch）”，这的确是个难题。

第三难，应对理想与现实的落差。做项目很重要的一项工作是管理好用户的预期，企业级建设也是如此。因为要耗费大量人力物力，所以，企业级项目启动之前，往往会将蓝图描绘的太过美好，但是建设周期的漫长、建设过程的曲折，以及中间不断对现实做的一些妥协和折衷，会让很多“泡沫”被挤掉，这会让实现的结果看起来很“骨感”，之前文章中我也提到过，有些目标其实不是企业级要去解决的问题，有些成果也不是非得记在企业级的功劳簿上，甚至做企业级的成本和收益都难以直接计算。这有点儿像从单体应用到SOA、微服务的演变，看起来零件化了，灵活性上升了，但通信、维护也变复杂了，企业级效果的积极方面可能也要随着时间才能逐渐显现。这会产生对企业级的怀疑，尤其是在项目刚结束的一段时间内，大家都期盼着出现跟以往迥然不同的“大转变”，但是，往往需要“让子弹飞一会儿”。所以，要管理好企业的预期，不需要给企业级项目戴上太多的“高帽”，而忽视了真正该戴的“高帽”——完成一次企业文化的建设，实现整体转型，如果这个目标没实现，那才是真正该失望的，不要只用系统去检验企业级。

第四难，架构的权责定位。在组织中，一件事情能做好，其前提就是做事的人权责匹配，无论是临时事项还是长期事项，否则，成功就是侥幸而不可复制的。企业级转型期间，作为临时性项目组织，架构可以有较大权力去保证项目落地，但是转型期结束，转入常态开发时，架构如何定位呢？我之前给出的机制是一种解决办法，毕竟架构就是架构，不是企业的管理者。但是，架构定位的困难在于，权力太小，不足以维护企业级，甚至让企业级随着时间的流逝而“名存实亡”；权力过大，又会发展成新的部门化组织，一旦开始以架构“卫道士”自居，就会导致对架构创新的阻碍。这种说法可能科技公司不太容易理解，但是对传统大型企业而言，是很正常的，因为这些企业中本就有强烈的“官本位”思想。企业级建设实际上是要让这些习惯了业务管理的企业去正视技术，定位好自身的科技基因，如何对科技中很重要的一股力量——架构师（既包括业务架构师也包括其他架构师）做出合理定位，就成了对企业的一个大考。

第五难，志贵有恒。企业级的长期坚持是件难事儿，大家可能会觉得，业务架构有了、模型有了、地图有了、机制有了，还会很难吗？当然会的，爱美之心，人皆有之，都知道体型好又漂亮又健康，花钱、花时间减肥的大有人在，但是真正坚持到底、不反弹的有多少？企业和个人都是一样的道理，水会自然流向阻力最小的地方，所以，企业级的放弃和崩坏，未必是把架构组织撤销、机制停掉这么激烈的动作，而是各种“畏难情绪”、“客观原因”导致的缓慢的无序，跟减肥、忌烟失败差不多。

说了一堆难处，读者也能体会到，传统企业，尤其是大型企业谈企业级，跟那些互联网科技公司是不大相同的。对于后者，虽然也有管理方面的因素，但更多还是技术规划、技术栈建设的问题；而对于前者，自始至终，非技术因素的作用与技术因素相比，至少是等量齐观的。但是时代已经进入了数字化时代，正如某次交流会上，一位嘉宾豪言，“未来已来，你爱来不来”。随着国家开放程度的不断提高，民营领域创新能力的不断提升，大型传统企业已经进入了被动的数字化转型之中，是否会迎面走上、顺利走通企业级转型这条举步维艰之路，我们拭目以待吧。

相关文章：
中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”
中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？
中台之上（三）：战略和组织结构，业务架构设计中不应被忽视的关键因素
中台之上（四）：面对复杂的流程和数据，我们总结出了一个分析套路
中台之上（五）：业务架构和中台的难点，都是需要反复锤炼出标准模型
中台之上（六）：如何为一个商业银行设计业务架构？
中台之上（七）：不神秘但很麻烦的业务架构落地过程
中台之上（八）：企业级业务架构的实现需要不断沟通和调整
中台之上（九）：如何基于企业级业务架构管理业务需求？
中台之上（十）：业务架构设计“笨重”，它能跟敏捷沾边吗？

作者介绍：付晓岩，原国有大行资深业务架构师，负责业务架构设计、项目管理，热衷新技术探索与实践，具有丰富的银行业务经验和企业级项目业务架构设计经验，曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。公众号：晓谈岩说。