第一篇发出后，大家看的还挺积极，有读者也发来了问题，既然客官点菜了，那东北厨子就得上灶了，必须得！
这个问题还真是个高频的常见问题，而且，如果没在工程上实际去做，真的可能就会是觉得自己明白了，但做起来还是有困难，尤其是要去给别人解释的时候。
架构的联通设计通常指的是四个架构之间的串联，也就是业务架构、数据架构、应用架构、技术架构之间的联接，这位老师描述的场景还包括：
这篇文章我就试着回答下这几个问题。
第一个问题是3A架构的拉通，也就是业务、数据、应用架构的拉通。讲这个问题前，我有一点要澄清下，对我来讲，完整的业务架构是包含流程模型和数据模型两部分的，而不是很多交付物里常见到的只以流程为主的情况，流程模型、数据模型、业务组件模型，这几个是业务架构的核心，其中流程模型可以到4级任务、5级步骤或者介于两者间的4.5级这种程度，具体建多深看需要、看资源，不是一概而论的；数据模型的核心是C级逻辑模型，也是企业级的逻辑级数据模型，这个模型是只包含基础数据，并且是纯业务数据的，也就是说，本质上C模型是业务模型而不是技术模型；业务组件就是根据数据聚类任务产生的业务能力分组，属于业务架构中的高阶元素，所以我在聚合架构中讲它是聚合而来的，业务架构中的关键元素是任务和数据实体，标准化、复用、聚合都是对着它们来的。
介绍了构成，回到拉通这件事。这个拉通其实要注意几点，首先是认识上，流程和数据是什么关系？是业务的一体两面，也就是只有同时描述了流程的关系和数据的关系，才完整描述了一个业务，这是为什么我主张流程模型和数据模型同时设计的原因，一个好的数据模型，尤其是C这一级，讲的是业务是怎么进行的，而不是单纯讲只有什么数据。并且，这讲的还是业务是怎么做的，不是系统是怎么处理的，所以它描述的又可以称为业务处理对象之间的关系，如果按照大多数项目常见的情形，把库表关系图当实体关系图，你描述的就是系统是怎么做的，而不是业务是怎么做的了，那个属于给技术用的数据视角的系统模型，而不是给业务看的业务模型。如果不理解这个，那也就不太会理解流程和数据的拉通了，之前也有其他读者问过我，为啥流程模型建完了却推导不出数据模型，这个原因可能就是你在想数据模型的时候想的还是偏库表关系而非业务对象关系，如果从业务对象的视角出发，灵活分析业务流程中涉及到的“人事物”，其实就是用业务对象作为绘图元素重新绘制了一遍流程图而已。这么理解的流程模型和数据模型才会有内在一致性。
之后就是关联，如果绘制的逻辑跟上边一样，那你就可以在流程模型的4、5级层面与数据模型的实体对接，甚至对接到属性，但是那个工作量实在太大了，对接到实体级就行，对接以CU关系为主，也就是创建和修改，这时可以检查质量，比如，有没有那个数据实体没有任务创建，那它是怎么生出来的？这是业务数据，不是技术数据，不会没有业务过程平白无故产生，哪怕是习惯自动化了，机器也是替某个业务角色执行的。这就是质量问题，有实体但是无创建、有创建无修改、有创建有修改但是无使用（Read）都是要关注的问题；反过来，有任务但是不创建或修改任何数据，这个任务的价值到底在哪里？我们最初建模时，只读数据的任务是不创建的，后来其他企业实践时放松了这个限制，也是大家还是习惯给查询留个位置吧，不过这一点并不改变我前边讲的逻辑，这就是业务架构和数据架构的互相验证与联通。切记，如果做的不是逻辑级数据模型，可能也谈不上对接了，把一堆乱七八糟的技术数据混在里边、拿库表去给业务看甚至想从库表反推逻辑模型基本都行不太通，等着GPT以后干这事儿吧，人干是够呛。
更高级的联通还反映在通过数据聚类形成业务组件上，这一点在我的书和课程里都有，就不赘述了，可见，业务架构和数据架构，尤其是在逻辑级模型的层面，关系是高度密切的，这也是我在聚合架构这本书里为啥干脆就不写数据架构的原因，它已经包含在其他架构里了，想想微服务、DDD、Datamesh、数据编织、库仓一体等概念，基础不都是这个吗？就是数据架构融入业务架构以及其他架构。
业务和数据拉通之后就是应用的拉通，这体现在两个层面，一是刚才讲到的业务组件对应用组件设计的指引，可以基于业务组件设计应用组件，这属于子系统级的对应；再深入则是根据流程和数据的映射关系，考虑在任务的范围内如何设计用例、服务，并保证串接关系的总体一致，这就是需要继承式设计，如果这个时候技术非要发挥自己的想象力再搞一套设计，那就是浪费精神头儿了，有这个时间不如在给定范围内设计更好的实现手段。这个设计过程中如果觉得业务模型有问题，那就一起商量调整，保证实施后的应用逻辑与业务架构的总体逻辑是一致的，这样以后才能继续基于业务架构驱动整体开发，让业务架构起到分解战略、标准化业务、统筹需求、拉通业务和技术的作用，如果技术只是觉得模型不对就撒手不管了，那这条通道就无从建立，所以对技术而言，核心不是业务模型做的对不对，让你做，你也没法一次做对，核心是双方如何将业务架构和应用架构的一致性建立起来，就像一个人说广东话，一个人说上海话，双方都拒绝说普通话，你也学不来对方的话，那就没法沟通了，而普通话说到底就是个共识，不接受共识，就没有能作为统一语言的普通话，提高沟通效率也就无从谈起，那就不要引入企业架构了，直到乱的都受不了那天再说，那时才有改变的动力。
单纯的一致性验证可以通过文档检查手段，深入的一致性验证就得深入项目了解了。
至于读者问的第二个问题，这是工作机制和对业务架构作用的理解了。首先，业务架构师和需求分析师、产品经理是否分开岗位设置，如果是，那么，业务架构师的核心任务是创建架构资产并基于架构资产进行需求定位、统筹，也就是说，分岗的情况下，业务架构师的职能不是详细需求的整理，而是整体架构的维持，就好像交通警察的职能。业务架构资产的核心是描述能力分布，而不是细化到按钮需求，细化也能做，但是相当于业务架构师与需求分析师、产品经理的岗位融合了，人少了会这样，但是这时的整体架构把控力是弱的，因为你大部分时间必然会花在详细需求上。如果是分岗的，想要整体工作效率提升，业务架构师可以按照敏捷团队的方式参与到项目中，跟随项目一起做架构分析，不过这对业务架构师的个人能力和对业务架构资产的熟悉程度要求都很高，但是效果会比较好，不会让人觉得多了一环。是否能实现这个，除了业务架构师能力，也取决于企业开发管理模式的设置，比如对立项是怎么管的，是否支持这种快速实施方式。总之，业务架构资产的好坏不是简单以是否支持后边拿架构资产当需求文档来看的，而是看在企业整体开发模式中对它的定位来评价的。
