“中台”是架构的捷径吗?

由于“中台”概念的推动,关心业务架构的读者越来越多,很多企业也对实施“中台”、“中台”方法论趋之若鹜 。历史总是相似的,之前无论 SOA、微服务、DDD,还是敏捷开发、双模开发等热门技术概念出现时,都曾经给大家燃起“捷径”的希望 。然而,最终还是证明了软件领域没有“银弹”,很多时候,反倒是应了北欧的一句民谚:捷径是迷路的最快方法 。
架构没有捷径,无论从架构的设计、架构的落地还是架构的学习方面来讲,都是如此 。
架构设计没有捷径架构设计如同求医问诊,必须对症下药 。盲目相信任何已有架构设计成果都是很危险且极不负责任的 。每个人的身体都各有特点,企业也是如此,而企业级转型、企业级工程是对企业现有能力的最大调整,需要企业在认清自己的基础上进行,任何忽略“向内看”过程的架构设计,都是为今后的混乱,甚至失败埋下伏笔 。
对于复杂手术,不经过详细的诊断,不经过对术式反复揣摩,医生不会轻易为患者开刀,否则,不啻于用生命做试验 。软件工程虽然少有“人命关天”的事情,但是,浪费时间也等同于浪费生命 。
没有为企业做过深入“体检”而轻易相信“领先实践”,很容易把在架构设计上节省的时间和精力,加倍“奉还”到实施过程中去 。
企业级架构设计往往给人以过于漫长、难以响应变化的印象,但是,人们恰恰忽略了由此带来的架构认知的积累,以及由量变到质变的过程 。
当人们感慨一次“传统”的企业级业务架构设计方式可能耗时一到两年,而互联网时代非常追逐“快”时,其实并没有充分意识到,互联网企业的架构,比如阿里的“中台”也经历了十余年的积淀,而且十余年的积淀也还只是理清了一个方向,不然也不会有今日对“中台”概念的众说纷纭 。
互联网架构并不代表架构设计上有“捷径”,反而证明了,任何“快”都来自于自身的积累,是充分“向内看”才有了外在的“快” 。“快”源自对业务的深刻理解,“中台”对公共能力的沉淀正是来自于对业务能力的归纳和提炼,所以阿里才十分重视业务架构师的培养,而对“中台”的探索绝不仅限于对公共能力的沉淀,最终会上升到对企业整体、对何为业务经营的认识,这是一个自然的过程 。
笔者在最近与原阿里中台核心架构师毗卢老师的交流中了解到,他们在进行中台设计时也在反复思考技术要努力支持业务经营的快速变化 。
那业务经营到底是什么?其实,大家关注的问题从领域级逐步上升到企业级之后,是一定会思考到底企业是什么、企业如何运转这些问题的 。
互联网架构并非简单地快速试错,这种试错是对业务选择能力的支持,而从技术视角看,则是对架构能力的不断提炼,是架构的强大才有了快速设计的可能 。
所以,架构设计没有捷径,唯有积累,通过积累提高了对企业自身的了解、对架构设计的驾驭能力,才有了可以快的“资本” 。
此处,还得再说一次前边提到的北欧民谚:捷径是迷路的最快方法,无论是企业还是个人,切换架构设计方法前,都要对学习曲线有深刻的认识,否则,当别人在原来的方向上越走越远时,你可能还是在原地打转,只不过为别人提供了案例 。
笔者 2019 年在公司负责搭建风险管理体系,而该项工作再次让我认识到,架构不是可以“抄”的 。
风险管理是个很成熟的领域了,三道防线的体系设计方式,无论是金融企业还是科技企业、无论是国内企业还是国外企业都在使用,但是,你却无法直接把其他企业的防线设计简单套用过来,必须一个工作事项一个工作事项地分析自己企业的流程,确认风险点,确认工作事项的负责团队,落实具体的风控职责,之后,再考虑风控措施是否可以实现“机控”,而这一切又取决于该工作事项是否已经线上化 。
这样才能形成一个与实际工作环境相符,并融合数字化风控方向的全面风险管理体系 。这种深入细节的体系建设无法通过照搬任何现成经验来获得,否则会出现“削足适履”的情况 。没有“捷径”,只有“路径” 。
架构落地没有捷径经常有读者好奇企业级业务架构设计如何落地,笔者在书中、在 2019 年 12 月南京的中台大会上都直言,企业级业务架构设计的落地过程没有任何神秘和特殊,也不该有,今天笔者认为企业级业务架构日益重要,并不是因为它有什么落地的捷径,任何架构设计的落地过程都是靠一个逻辑一个逻辑、一个模块一个模块地实现的 。


推荐阅读