前面，我们讨论了基于构件模型支持细粒度组装式开发、形成轻量级架构工具的方法，并阐述了通过产品目录建设产品信息高速公路的设想，具备这一切条件之后，是否能够进一步提升产品创新效率呢？这是很多企业都关心的问题，特别是总觉得比互联网企业跑得慢的传统企业。首先必须声明，创新是一个复杂的大问题，人、制度、内外环境缺一不可，所以我不是在兜售“灵丹妙药”，我只是从建设平台化的产品创新能力这个角度，谈谈系统建设对创新能力的提升这件事。
从之前的介绍中我们可以看到“业务信息——产品目录（标签化）——产品——模板——构件——服务——项目信息”这样一个完整的由业务延伸到技术的链条，这个链条上汇聚了对创新而言必备的主要信息，通过这个链条，关于一个产品的需求、设计、核算、反馈、改进都能汇聚起来，因此，以这些信息为基础，是可以搭建一个产品创新平台的。平台的逻辑结构如下：
平台的核心域为产品研发域，研发域包括产品目录和构件模型两部分，前者是面向业务端的高维数据实现和信息汇聚，后者是面向设计和开发端的产品实现，这两部分的内容之前的几章已经介绍过就不再重复了。
平台的支持域包括三个部分：
一、产品创意域。创意是产品的设计来源，很多企业都鼓励内部创意，也有企业将创意管理系统化，在有产品目录和构件模型的基础上，可以更好地对产品创意进行分类，比如是对模板的创意、产品的创意、构件的创意或者凭空产生的全新创意，可以通过这些标签更好地引导创意的流向。对创意的初步定位有利于创意的快速传导，也考验了整个企业对于业务模型这种通用语言贯彻的效果。如果有相当一部分业务人员都能够了解自己领域的业务模型以及对应的到构件级的系统结构，那么创新的效率一定会大幅提升。在大家倡导业务与技术深度融合之前，业务的归业务、技术的归技术，信息给到、互不干涉是开发中常见的情况，但是以后，随着融合程度的加深，互相清楚对方在干什么、怎么干，是很有必要的。此外，除了全新的创意，还有些创意可能是基于业务需求形成的，这类创意可以建立与业务需求的关联关系，以识别重复需求，这种关联关系虽然不难建立，但是操作过程中却可能由于录入者嫌操作麻烦而被忽略掉。当然，出于成本的考虑，也可以斟酌要做到什么程度。
二、产品评价域。产品评价也是大家关心的话题，不少企业为此头疼，有人搞高大上的理论结构，也有只能看看报表、读读数的。产品评价不是件容易事儿，而更不容易的就是想搞企业级的，我原来所在单位也为此头痛不已。产品评价难的是指标体系，金融机构的产品差异大，搞出一套大家都认可的企业级指标体系不大容易，就像之前介绍的，产品分类都难以达成一致意见，何况这种直接跟工作业绩挂钩的产品评价呢。这方面，个人认为，自上而下的去做企业级产品评价操作难度太大，还是 DDD 建模的理念靠谱，从单个领域出发，一个领域一个领域的构建评价模型，而领域内部则要一个产品一个产品地进行分类，归类后，再一个类别一个类别地跟业务人员去尝试建立评价模型。单产品的评价模型顺利运行后，再逐渐汇集领域视角的评价方法。评价的数据来源通常为生产系统或者数据仓库的数据，考虑到部分产品的特殊性，可以附带少量主观评价指标。
三、产品运行效率监测域。这部分主要依赖于构件模型的特殊性，构件与服务之间有明确的联系，而构件可以按照执行顺序形成设计视角的流程模型，这一点在之前有论述到。这种流程划分方法为监控每段流程的执行效率提供很好的依据，可以通过运维平台的数据汇总出每段流程的执行时间、流程间的等待时间，以更好地分析流程的改进点，这比到柜台去现场计时要有效率的多，而且可以充分利用运维信息，随时分析各地情况。
以产品研发域为核心，产品创意域导入新需求、新理念，产品评价域考核产品绩效，通过产品串联起需求、设计、评价的闭环，产品运行效率监测域则提供辅助的效率改进点。以这个抽象结构为基础的产品创新平台应该可用于传统企业的产品管理工作，但是在如何完善自身方面，还有很多需要进一步研究之处。
小结：对业务架构的再次思考
虽然做了六年的企业级业务架构，但是总觉得业务架构不是个好讲的东西，业务架构离不开业务模型，所以讲它就会搬出一堆枯燥的模型来，甚至会让人觉得业务架构就是建模。但建模只是个手段，建模的目的是把现象总结成模式，再从模式中找到结构，将业务上看到的结构传递给技术，如果二者能够基于同一结构思考，沟通上将产生最大的便利，这就是通用语言的基础，其实说通用语言，还不如说通用结构，因为说语言，经常会把人带到语法层面，纠结于规则、概念、标准之类似是而非的东西。所以，我总结建模的原则无非是把握整体、穿透现象、保证落地，建模即不能死守规则、冥顽不化，也不能脑洞大开、信马由缰，必须从一开始就关注如何落地。建模不是建个自圆其说的乌托邦，而是传给后续过程的设计图纸。业务建模可以有前瞻性，但是所谓的前瞻性是能够看清分阶段实施路径的前瞻性。
业务架构是不断演进和迭代的，它有生命力，可以成长，如果架构管理工具本身支持历史记录和模式比对，你也可以看到企业架构的演进历史，而不是只看得到现在，只能听别人讲讲过去，过去是可以看见的。这种可视化的历史是一种宝贵的学习资源，人是从历史中学习未来的，毕竟有很多行业还是需要积淀的。
但是，业务架构的形成过程的确是在一种看起来科学的方法论下，不完全科学地操作的，这点我曾经也很纠结，后来软件架构的书看多了，再加上到项目中的观察，也逐渐释然了。软件架构其实很羡慕建筑架构，觉得建筑架构有力学基础做支持，有很多可以计算的东西，但是软件架构却没多少能算出来的。在开源思想时兴之前，行业内部交流分享较差，都比较愿意看别人的架构，而不想亮出自己的，很多研究者都抱怨这个非常需要标准的行业反倒是很隔离的。开源为架构和软件带来新的成长方式，共享让思维发展更快、普及更快，但是，软件架构本身却只是增加了大量的案例，依旧难以标准化，哪怕是同一个行业的企业，给这家做的软件也不一定能直接搬到另一家去，很多商用化了的系统软件也还是离不开个性的本地化改造过程。云计算带来的 SaaS 虽然让软件应用省去了许多部署过程，但是，依然难以改变这个行业个性化程度严重的局面。软件架构尚且如此，业务架构也就不需要纠结了。
业务架构设计可以很快，也可能很慢。快无非是两种情况，一是架构师自身炉火纯青、天生慧眼，设计能力超强；二是原有业务模型已经很清晰，可以快速分析业务变化，形成架构设计，我们可以追求的是第二种，这也意味这首次建模，尤其是首次建设企业级模型，不要过快，对模型设计方法、业务流程分析、标准化过程，都要细致点儿，基本功扎实了，才有后边的“敏捷”。企业级转型没有轻松的，不少企业是把转型仅当成一个项目，而忽视了对自身的调整。一个普通士兵变成一个特种战士，不是因为给了他一身价值 10 万的装备，而是经过了地狱般的训练。上至最高管理者，下至普通员工，人的思维不转变，哪来的企业转变呢？
为了推动企业真正的数字化转型，业务架构设计人员永远不要忘记，业务架构最重要的职责不是传递需求，而是藉由自身的努力，推动业务和技术的深度融合，桥梁作用才是业务架构最重要的职责，如果不能实现这一目标，也就不能真正实现一个快速响应内外部变化的企业级业务系统。
其实中台并非万能，客观地讲，一个优秀的架构设计人员是不会“迷信”于任何一种架构设计方式的，也不会执着甚至偏执于方法间的争论，没有哪种设计方式是完美无缺的，软件行业没有“银弹”，任何一种方法都需要坚持与灵活的结合，都需要通过长期的实践不断总结和改良，如果一个方法没有被坚持数年以上，可能连入门都谈不上吧。我对中台认识更多还只能算个一般观察者，论述中难免有失，感谢读者朋友们能够宽容地看我一路“叨叨”下来。
相关文章：
中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”
中台之上（二）：为什么业务架构存在 20 多年，技术人员还觉得它有点虚？
中台之上（三）：战略和组织结构，业务架构设计中不应被忽视的关键因素
中台之上（四）：面对复杂的流程和数据，我们总结出了一个分析套路
中台之上（五）：业务架构和中台的难点，都是需要反复锤炼出标准模型
作者介绍：付晓岩，原国有大行资深业务架构师，负责业务架构设计、项目管理，热衷新技术探索与实践，具有丰富的银行业务经验和企业级项目业务架构设计经验，曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计。公众号：晓谈岩说。
企业架构理论研究者，业务架构设计倡导者
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论