软件领域没有“银弹”，架构领域也没有捷径！由于“中台”概念的推广，越来越多的读者关注业务架构，许多企业也争先恐后地实施“中台”和“中台”方法论。历史总是相似的。之前流行的SOA、微服务、DDD，或者敏捷开发、双模开发等技术概念出现时，都让大家看到了“捷径”的希望。但最终证明，软件领域没有“银弹”。很多时候，这是一句北欧谚语：走捷径是最快迷路的方法。架构没有捷径，无论是架构设计、架构实现还是架构学习。1、架构设计没有捷径可走。架构设计就像求医，必须对症下药。盲目相信任何现有的建筑设计成果是危险的，也是极不负责任的。每个人的身体都有自己的特点，企业也是如此。企业级改造、企业级工程化，是对企业现有能力的最大调整。它们需要在对自己有清醒认识的基础上进行。架构设计都在为未来的混乱甚至失败埋下伏笔。对于复杂的手术，在没有详细诊断和反复推敲手术步骤的情况下，医生是不会轻易给患者动手术的，否则无异于拿生命做实验。虽然在软件工程中很少有“要命”的事情，但是浪费时间就等于浪费生命。不对企业做深入的“体检”，轻易相信“领先实践”，很容易将架构设计节省的时间和精力“返还”到实施过程中。企业级架构设计往往给人的印象是时间太长，难以响应变化。然而，人们恰恰忽略了建筑认知由此产生的积累和从量变到质变的过程。当人们觉得“传统”的企业级业务架构设计可能需要一到两年时间，而互联网时代非常追“快”的时候，却没有充分意识到互联网企业的架构，比如阿里的“中台”也经历了十几年的积累，十几年的积累只是明确了一个方向，否则也不会有今天“中台”这个概念的众说纷纭。互联网架构并不意味着架构设计有“捷径”，而是证明任何“牢”都来自于自身的积累，只有充分“向内找”才能有外在的“牢”。“快”源于对业务的深刻理解，“中台”公共能力的沉淀源于对业务能力的归纳和提炼。这就是为什么阿里非常重视业务架构师的培养。探索绝不仅限于公共能力的沉淀，最终会上升到对企业整体的理解，以及企业运营是什么。这是一个自然过程。笔者从近期与阿里中台原核心架构师皮鲁老师的交流中了解到，他们在设计中台时，也在反复思考技术，力图支撑业务运营的快速变化。业务运作到底是什么？其实大家的关注点从领域层面逐渐上升到企业层面之后，肯定会思考什么是企业，企业是如何运作的。Internet体系结构不仅仅是快速试验和错误。这种试错支持业务选择能力。从技术角度来说，就是架构能力的不断完善。正是架构的力量使快速设计成为可能。所以，架构设计没有捷径，只有积累，通过积累提高对企业自身的认识和对架构设计的把控能力，才能拥有可以快的“本钱”。在这里，不得不再说一遍上面提到的那句北欧谚语：捷径是迷路的最快途径。无论是企业还是个人，在切换架构设计方法之前，都必须对学习曲线有深刻的认识。否则，当别人在原来的方向上越走越远的时候，你可能还在原地打转，只是给别人提供了一个案例。笔者在2019年负责公司风险管理体系的建设，这项工作让我再次认识到架构是无法“复制”的。风险管理是一个非常成熟的领域。三道防线的系统设计方法无论是金融公司还是科技公司，无论是国内还是国外的公司都在使用。但是，你不能直接套用其他公司的防御设计。过去，我们要对自己公司的流程进行一一分析，确认风险点，确认工作项目的责任团队，落实具体的风险控制责任。之后还要考虑风控措施能否做到“机械控制”。这完全取决于工作项是否已在线。只有这样，才能形成符合实际工作环境、融合数字化风控方向的全面风控体系。这种深入细致的制度建设，不是照搬任何已有经验就能得到的，否则就会出现“割脚穿鞋”的情况。没有“捷径”，只有“路径”。2.架构的实现没有捷径可走。读者往往很好奇企业级业务架构设计是如何实现的。作者在书中和2019年12月南京中台大会上直言，企业级业务架构设计的实现过程并没有什么神秘和特别之处，也不应该有。今天，笔者认为企业级业务架构越来越重要，并不是因为它有什么实现的捷径。任何架构设计的实现过程都是一个逻辑一个逻辑、一个模块一个模块地实现。企业级的业务架构设计只是让业务端的组织更加结构化和集成化。不同于需求分析侧重局部细节，也不同于产品分析的领域特性，企业级业务架构侧重于企业的整体能力。规划和结构表达，但在实现层面并不意味着任何特殊性，它只是在软件过程中提供了一个“指挥棒”，通过业务架构设计形成对软件功能划分的指导。更重要的是，通过业务和技术都能理解的业务架构模型，在企业内部形成一种可以沟通，甚至跨领域沟通的“通用语言”。这根“指挥棒”对于提升企业整体诚信度至关重要。管理层一直在研究如何在企业内部形成联合管理力量。在业务架构诞生的初期，80、90年代，企业的信息化程度还没有今天这么高，业务和技术的深度融合还没有被应用所重视。然而在今天，淘宝、滴滴、美团、今日头条等跨界竞争者，给传统行业原有的企业带来了巨大的竞争压力，甚至有不少人认同，未来大部分企业都将转型为科技企业。近日，工商银行的领导也作出了这样的表态。由此可见，加强业务与技术的深度融合是非常有必要的，而业务架构正是符合这个时代要求的工具，让企业对能力有清晰的认识，对架构的清晰，对演化的演进有清晰的认识。体系结构，这可能会继续提高体系结构的灵活性。企业管理往往追求韧性。人们常说，企业可以像毛巾一样拧起来，越拧越紧，不会断。未来，企业都是科技型的，这种“韧性”可能来自架构的“弹性”。提高企业的诚信度，就像马拉松的训练，虽然业务架构提供了有力的工具，马拉松还是要靠教员一步步跑完马拉松，成绩的提升完全靠教员自身的能力和毅力。回到软件工程，即使架构的实施采用敏捷过程，也并不意味着依赖任何“捷径”，而只是工程组织方式的改进和对效率的追求。笔者最近看了一本书《敏捷革命》。相比广为流传的“敏捷价值观”，敏捷方法的最初创造者其实更关心如何充分获取和共享信息，良好的思维模式，用短周期的方式快速提供核心价值，从而降低因项目周期长导致项目失败的风险，用多轮短周期可控的“冲刺”代替长期不可控的过程。原创者非常推崇OODA原则，即飞行员训练中使用的“观察-导向-决策-行动”模型。事实上，这种思想在每一次敏捷Scrum中都有体现。“观察”代表对全面信息的快速获取；“导”是依靠心智模型进行快速分析，即快速设计过程；“决”是毫不犹豫地确定结论，“行”是将决定付诸实施。原作者在书中也强调，在Scrum中，需求确定后，要尽可能做到不动。这和飞行员的“决定”和“行动”模式是一样的，因为空战时间太短了，几乎没有再后悔的机会。敏捷方法的鼻祖对丰田的生产方式推崇备至，笔者最近刚读完《新乡重夫谈丰田生产方式》一书。丰田的生产方式，又称“精益生产”、“Just-in-time”，是拒绝“浪费”的终极追求。这个浪费不是指原材料的浪费，而是时间和效率的浪费。例如，丰田在思考原材料在不同生产场地之间的运输所造成的浪费时，首先解决的是如何避免运输，通过这种思考来调整生产环境；又如反思如何提高打磨零件毛刺的效率，当时采用引进欧洲真空加工技术的方法，使零件完全不产生毛刺。像这样的例子还有很多，正是这种持续了近20年的对效率提升的不懈追求，最终形成了丰田生产方式。任何一种方法的形成都是一个长期积累和反思的过程，而这些方法的应用也需要使用者付出合理的努力才能掌握。架构设计的实现归根结底是一个软件工程问题。没有捷径，只有持续的效率提升。无论是激励敏捷方法创造者的丰田生产方式，还是敏捷方法创造者的实践，都是一个不断改进和提高方法熟练度的过程。在没有真正理解方法之前，根本谈不上效率。与其老是切换方法求“快”，不如把自己的功夫真正练到极致。只要解决问题的效率高，你就是“一派”。“四万八千法门”都能成佛，如果能在修炼过程中“师法他人”就更好了。事实上，敏捷方法的最初创造者就是这样创造出敏捷方法的。3.学习架构没有捷径成为架构师没有捷径，只有努力和努力。建筑学的研究需要大量的基础工作和广泛的研究。对此，笔者在文章?中进行了介绍。在架构能力、流程优化、建模技术、软件流程、编程语言、整体思维等方面，都有很多知识需要学习，也列出了一些参考资料，这里不再赘述。不管是哪种架构师，都需要深厚的积累，架构师都是从项目堆砌起来的。不可否认，互联网企业架构师的成长确实非常快。这可能是因为企业机制为合格的候选人提供了更多的测试机会，使他们能够快速进步。如果说培养架构师有什么可以勉强称为“捷径”的方法，对于企业来说，就是要认真考虑是否建立了快速发现和培养人才的机制。不然就像阿里说的，业务架构师只能靠自己培养，没有合适的人才什么都做不了。近日，在一连串的《Doctor X》中，医术精湛的女主角在一次非常艰难的手术中说了这样一段话：“就像河流在流动，重复基本技术可以创造美丽最终的手术领域是理想的手术......最重要的是，不管手术有多么困难，都不应该抛弃病人。”我想这也适用于建筑领域，建筑没有捷径，有的只是前人的肩膀，努力学习，积极实践，消化领悟，只有真正站在前人的肩膀上，才能你看到了前进的方向，前人的肩膀不局限于你从事的行业。负责业务架构设计和项目管理，热衷于新技术探索和实践，具有丰富的银行业务经验和企业级项目业务架构设计经验，曾主导客户关系等多个领域核心系统的业务架构设计，金融市场，同行，资管，养老。现就职于建信金融科技有限公司。新书《银行数字化转型》，公众号即将发布很快：萧坦言说。
