中台之上-【付晓岩】-pdf整理版.pdf

付晓岩：虽然做了六年的企业级业务架构，但是总觉得业务架构不是个好讲的东西，业务架构离不开业务模型，所以讲它就会搬出一堆枯燥的模型来，甚至会让人觉得业务架构就是建模。但建模只是个手段，建模的目的是把现象总结成模式，再从模式中找到结构，将业务上看到的结构传递给技术，如果二者能够基于同一结构思考，沟通上将产生最大的便利，这就是通用语言的基础，其实说通用语言，还不如说通用结构，因为说语言，经常会把人带到语法层面，纠结于规则、概念、标准之类似是而非的东西。所以，我总结建模的原则无非是把握整体、穿透现象、保证落地，建模即不能死守规则、冥顽不化，也不能脑洞大开、信马由缰，必须从一开始就关注如何落地。建模不是建个自圆其说的乌托邦，而是传给后续过程的设计图纸。业务建模可以有前瞻性，但是所谓的前瞻性是能够看清分阶段实施路径的前瞻性。 业务架构是不断演进和迭代的，它有生命力，可以成长，如果架构管理工具本身支持历史记录和模式比对，你也可以看到企业架构的演进历史，而不是只看得到现在，只能听别人讲讲过去，过去是可以看见的。这种可视化的历史是一种宝贵的学习资源，人是从历史中学习未来的，毕竟有很多行业还是需要积淀的。 但是，业务架构的形成过程的确是在一种看起来科学的方法论下，不完全科学地操作的，这点我曾经也很纠结，后来软件架构的书看多了，再加上到项目中的观察，也逐渐释然了。软件架构其实很羡慕建筑架构，觉得建筑架构有力学基础做支持，有很多可以计算的东西，但是软件架构却没多少能算出来的。在开源思想时兴之前，行业内部交流分享较差，都比较愿意看别人的架构，而不想亮出自己的，很多研究者都抱怨这个非常需要标准的行业反倒是很隔离的。开源为架构和软件带来新的成长方式，共享让思维发展更快、普及更快，但是，软件架构本身却只是增加了大量的案例，依旧难以标准化，哪怕是同一个行业的企业，给这家做的软件也不一定能直接搬到另一家去，很多商用化了的系统软件也还是离不开个性的本地化改造过程。云计算带来的 SaaS 虽然让软件应用省去了许多部署过程，但是，依然难以改变这个行业个性化程度严重的局面。软件架构尚且如此，业务架构也就不需要纠结了。 业务架构设计可以很快，也可能很慢。快无非是两种情况，一是架构师自身炉火纯青、天生慧眼，设计能力超强；二是原有业务模型已经很清晰，可以快速分析业务变化，形成架构设计，我们可以追求的是第二种，这也意味这首次建模，尤其是首次建设企业级模型，不要过快，对模型设计方法、业务流程分析、标准化过程，都要细致点儿，基本功扎实了，才有后边的“敏捷”。企业级转型没有轻松的，不少企业是把转型仅当成一个项目，而忽视了对自身的调整。一个普通士兵变成一个特种战士，不是因为给了他一身价值 10 万的装备，而是经过了地狱般的训练。上至最高管理者，下至普通员工，人的思维不转变，哪来的企业转变呢？ 为了推动企业真正的数字化转型，业务架构设计人员永远不要忘记，业务架构最重要的职责不是传递需求，而是藉由自身的努力，推动业务和技术的深度融合，桥梁作用才是业务架构最重要的职责，如果不能实现这一目标，也就不能真正实现一个快速响应内外部变化的企业级业务系统。 其实中台并非万能，客观地讲，一个优秀的架构设计人员是不会“迷信”于任何一种架构设计方式的，也不会执着甚至偏执于方法间的争论，没有哪种设计方式是完美无缺的，软件行业没有“银弹”，任何一种方法都需要坚持与灵活的结合，都需要通过长期的实践不断总结和改良，如果一个方法没有被坚持数年以上，可能连入门都谈不上吧。我对中台认识更多还只能算个一般观察者，论述中难免有失，感谢读者朋友们能够宽容地看我一路“叨叨”下来。