推荐语
：这是一本从实操角度探讨企业架构落地的书籍，对于高阶的软件产品设计人员，即使没有技术背景，也能够经过阅读本书，对企业级软件架构的模块化拆解设计有进一步的启发和认识。
我在《决胜B端》最后一章提到过企业架构（EA，Enterprise Architecture）的概念。
EA是经典的IT建设方法论，给出了从业务战略到IT架构推演的指导方针。
遗憾的是，EA相关的资料，彷佛除了Zachman、TOGAF等几套方法论，就不多有文章、书籍，可以深入地探讨其具体的落地过程，这也让EA的理论框架略显尴尬，总给人高高在上，术高莫用之感。
这一方面是由于，企业架构自己是一个高阶软件研发课题，可以真正有机会参与到企业架构设计的人并很少；另外一方面是由于，企业架构某些方面来说偏形而上，从几套业界的方法论，到具体实践层面，存在着一个鸿沟，不少人能够泛泛的谈论这套鸿沟上的桥梁的模糊形状，但具体如何搭建这座桥梁，其实并不清楚。
直到本书的出现，做者付晓岩老师，多年来在银行领域从事企业级业务架构设计，亲自将EA方法论应用于实际工做，对架构设计有着很是丰富的理论经验与实战经历。所以，付老师勇于突破，大胆尝试了无数人都不敢碰触的“烫手山芋”——企业应用架构话题，给出了一套通过实践得出的企业架构搭建方法论。
因此，这本书去年8月刚上市时，我就第一时间买到，并一口气读完。总体阅读下来，感受很是有收获，但理解书中的内容，确实须要必定的经验储备。
整本书的核心，是经过迈克波特的价值链模型做为理论基础，基于价值链塑造的业务流程为出发点，分析多场景下的业务对象本质，并通过超越了业务场景的实体抽象过程，获得了企业级视角下的数据模型。
以上描述，估计过于抽象。接下来，我把书中印象比较深入的一些关键内容整理分享，尽可能尝试可以把书中的核心观点呈现给你们。
首先，遵循EA的理念，书中也一样从企业战略分析、业务分析入手，做为整个架构设计的起点，以下图。
业务架构可从企业战略出发，按照企业战略设计业务及业务过程，业务过程是须要业务能力支撑的，从战略到业务再到对业务能力的须要，就造成了支持企业战略实现的能力布局，能够将这个布局理解为业务架构，它是企业为客户创造价值的设计过程。业务架构设计会尽量地追求以更为集约的能力实现更为多变的业务或服务，这其实也是中台战略追求的目标，于是，中台战略实际上也能够归结为一种业务架构设计。
业务架构设计完成后，“灵魂”就诞生了，IT架构则是根据“灵魂”的须要来设计“容器”。IT架构的分类方式并无统一的说法，一般会分为应用架构和技术架构，而近些年随着大数据的发展，数据架构的地位直线上升。此外，随着数据安全问题日益受到重视，许多企业的IT架构也将安全架构置于重要的位置上。
所谓企业架构，必须以企业全局的视角思考、设计，可是实践中，每每受到组织治理、组织结构的约束，难以按照企业级的方法论去执行。这其实也正是中台建设中每每遇到的问题。针对这个问题，做者谈到：
作业务模型，有两个原则须要注意，其中之一就是总体性。设计业务架构，咱们固然但愿可以通盘考虑整个企业，而不要由于部门利益影响组件边界的划分，影响功能设计。作出来的模型，凡是公用的部分，应该照顾到全部利益相关方的需求；凡是已实现的功能都应该对新的需求方开放并支持必要的扩展，这是企业级设计应该追求的目标，可是，实现起来经常困难重重。
企业不管大小，一旦系统的设计边界跨越了单个部门的职能范围时，都会出现部门利益问题，无非是企业规模、文化差别形成的协调难度的差异。在企业内部，部门利益是部门需求的自然边界，即使要作企业级，各方确定也是要先说清楚本身的需求，再去考虑别人的需求，“种了别人家的田，荒了自家的地”是绝对不行的。因此，各部门在参与到企业级谈判中时，都是首先要知足本身所在部门的业务诉求。
尤为是下边这段论述，我以为很是精辟，不能为了众人皆大欢喜而退而求其次的产生折中方案，若是不符合企业级的建设诉求，还不如不作，这是实践中的道德真知灼见。
这就要求，做为业务架构的设计者，拿出来的方案最好是以一种更有效的方式来知足全部相关方的需求，而不是单纯作抽象、归并，要各部门“你让一陇地，他少一棵树”的方式搞折中，这样作实际上就失去了作企业级的核心价值，由于这样的折中既没法保证系统的先进性，也没法保证用户体验，甚至还可能发生退步。部门利益是作企业级的最大障碍，跨越这个障碍是对业务架构师设计能力的最高挑战。固然，客观地说，没有更好的解决方案时，不动也是一种选择，由于，一样接受这个挑战的还有企业文化。
在探讨企业级不单纯是架构设计问题，也是业务管理问题与利益分配问题时，做者给出了一个银行体系积分平台的例子，很是有表明性的说明了工做中面临的各类复杂状况。
举个例子，银行都有积分系统，近年来各行也都作了综合积分，其实其中的实现难度很大，主要问题不在技术而在业务。理想的综合积分是企业只有一个积分系统，支持全部产品的不一样积分规则。对不一样的客户群、不一样的营销方案能够进行参数化配置，最重要的是，支持以单一积分形式统一用于奖励兑换，而不是想要换个包，还得分别花去信用卡积分、黄金交易积分、基金业务积分，这样客户体验会很是糟糕。
可是若都使用一个积分，那么又会出现这样的内部问题，信用卡部门为了促销，提升了积分发放，这样信用卡用户就在积分的获取上占了便宜，而客户的资金终归是有限的，所以黄金交易的业务量就有可能会掉下去。黄金交易的管理部门有样学样，也开始提升积分，结果就会形成积分的营销费用提早花光，反应稍慢的部门便已经没有机会进行促销了。
说到这里，读者可能已经明白了，综合积分背后的博弈多是营销费用的分配。在开展综合积分活动之前，这笔营销费用有多是提早划分到各部门的，各部门自行支配，蛋糕先分好，以后就不会再“打架”。若是综合积分设计不考虑清楚这个问题，就会动了多数人的蛋糕。
因此，若是能解决这个问题，那么综合积分的活动就能真正作到在一个组件里展开，若是解决不了，仍是各自为政，那么是否放在一个组件中就没有实际意义了，只是解决积分综合查询问题的话，有不少方法都好过功能迁移。
本书的核心部分，是推演了从业务战略到技术实现落地的企业级架构建设过程。对于企业级的业务战略分析，做者重点介绍了知名的迈克波特价值链模型，做为后续架构设计分析的起点和理论基础，以下图。
在波特的价值链模型中，认为企业在创造价值的过程当中，全部生产经营涉及的活动能够分为两类，即支持性活动和基本活动，前者支撑价值创造过程，后者完整价值创造和增值过程。
做者以价值链基本活动为出发点，推导了从价值链向业务组件的演化过程，做者写道：
价值链表明了构建企业能力统一视图的“横向”结构，每一个价值链环节中均包含了若干个业务流程；业务领域表明了构建企业能力统一视图的“纵向”结构，描述了各种业务流程应如何经过组合实现领域级的业务目标。
业务流程即业务活动，业务活动是由不一样角色分别完成的若干任务组成的，任务执行过程当中其必然与业务数据发生联系。数据主题域能够将关系紧密的数据进行聚类，再将与数据关系紧密的行为（也就是任务聚类），造成包含行为和数据的业务组件，组件表明了企业的某一类业务能力。
做者认为，基于价值链环节完成的业务组件的提炼，将完成企业级的能力服用提炼和抽象，做者写道：
若是能在设计及后续迭代过程当中多注意对任务的企业级分析和对组件能力的开放共享，避免因组件能力与主要应用部门间的关系产生对其余应用的天然壁垒，则如上图所呈现的业务架构逻辑，能够支持不一样领域的不一样活动对同一任务的自由复用，也就是常说的企业级能力复用。尽管本书以前的分析其实一直在尽可能避免出现活动层面跨价值链环节的复用，可是这并非表明排斥这种状况的出现，一切还应视实际须要而定。
接下来，做者经过一个完整的银行案例，阐述了以上理论是如何落地实操的，也是我认为本书中最精彩的部分。
做者描述了银行存款和贷款两个业务的产品设计、获客、营销过程，经过分别研究这两个不一样业务主题各自的业务环节，最终提炼、抽象、合并背后的主题设计，来实现超越了业务线的企业级的领域架构抽象。
首先来看下存款业务的产品设计、上架、获客和转化过程，注意下图中上边是价值链环节（或核心业务过程），下图是基于不一样角色，针对价值链环节抽象出的业务组件（其实有点相似于咱们总说的实体）。
咱们能够看出从上图中抽象提炼了若干组件（或叫实体），包括客户信息、帐户信息、合约、产品等。
接下来再分析贷款业务的价值链环节，也涉及到贷款产品开发、获客、转化等环节。
接下来，很重要的一部，是从企业级的角度，考虑两个业务线中，哪些组件是能够合并并进一步抽象的，从而能够为其余业务线提供复用。
通过一系列的分析，最终合并获得产品、客户、合约、帐户四个组件，关于合并的思考过程，请你们阅读原书。
上图的架构，体现了一种超越业务线的架构设计，其中最重要的就是超越了业务属性的组件的提炼，所谓组件，是技术底层最核心的数据对象，表明了对业务本质的理解和高度抽象。准确的提炼出企业级组件，表明着将来对于其余相似的新业务均可以提供企业级的能力复用。
读到这里，可能不少朋友认为这些都是技术话题，但其实对于高阶的B端产品设计，对业务的支撑、赋能是一方面，对产品、技术本质的理解、提炼是另外一方面，二者都须要有很是深入地认知，缺了某一块，都不能作出优秀的企业级软件产品。
围绕着以上企业级组件的构建过程，在书中做者还谈到了团队管理、组织架构、项目推动挑战等各方面话题，对于我我的来说，印象最深入的是以上部分。
实际上以上提到的抽象的方法论，也是目前行业内中台建设一个很重要的落地实践过程。企业级架构设计中，经过技术能力的抽象和沉淀，封装并强化了业务能力，能够从技术角度快速支持新业务开展，不正是中台的思路么？
而书中提到的组件抽象，不正是《决胜B端》中提到的在产品设计中须要作的业务建模么？
其实软件设计的本质都是相同的，你理解他的本质，并不必定须要会编程，可是这种抽象思惟和建模思惟，是必须具有的。
今年9月，有幸和付老师相聚，畅谈甚欢，被付老师的博学所折服。
↑ 扫码关注付晓岩老师公号编程
本文分享自微信公众号 - 晓谈岩说（gh_18519a945f4e）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。安全