导读：
“数字化转型的必由之路是体系结构设计，在企业级体系结构设计方法论中，Togaf居首位。 理论性强的体系结构体系难免让人感到技术高超，沉默的乌龟老师《企业级业务架构设计：方法论与实践》揭示了Togaf中的阶段b业务体系结构，详细说明了如何利用价值链进行业务体系结构的设计。
那一章共分为四个部分。 第一部分介绍企业结构和业务结构，第二部分以价值链为核心说明业务结构如何设计，第三部分说明业务结构的持续落地，第四部分简述业务结构与中台关系。
现在，我在这里发表fndbmh个人解读的读书笔记，与大家分享。”
01
-
Togaf业务体系结构
在企业体系结构运行期间产生大量输出，包括业务流程、体系结构要求、项目规划和项目合规性评估。
为了能够以一致的结构化方式校准和展示工作交付件，需要一个用于配置这些工作交付件的体系结构模型框架。
这样方便了工作产品的引用和标准分类，有助于改善不同结构工作产物之间的关系。
Togaf内容模型阐述了构建的速度是如何描述的，以及如何与构建的速度相关。
其中包括动机、组织和职能。 业务体系结构需要在准备阶段制定的体系结构原则、体系结构愿景阶段的业务战略、业务原则和体系结构愿景等。
其中战略是沉默的龟老师在业务架构设计中一直强调的基础。
体系结构的工作和开发一样，也需要交货。 在Togaf的定义中，框架输出产品、交付项等。 其中Togaf业务结构输出的产品有目录、矩阵、图。
目录包括组织/执行者目录、角色目录、流程/事件/控制/产品目录等。
矩阵包括业务/交互矩阵、执行者/角色矩阵。
图形有业务足迹图、业务服务图、功能分解图、用例图、组织分解图、流程图、事件图等。
Togaf业务体系结构交付内容包括风险管理、体系结构定义文档、体系结构要求规范、业务场景、差距分析、体系结构构建速度和解决方案构建速度。
其成果与沉默的龟老师这本书的第三部分一致。
Togaf一直强调是基于能力的业务计划，其方式之一是运用价值链完成业务分析工作，沉默的龟老师和这第二部分是一致的。
02
-
企业级业务体系结构设计：方法论与实践
企业结构EA的理论框架总是很高，让人感到技术很高。
这是因为企业体系结构本身是一个高级软件开发挑战，很少有人能参与企业体系结构的设计。
另一方面，在企业结构的某些方面存在偏差，从几个行业的方法论到具体的实践层面都存在差距。 很多人可以普遍谈论这座鸿沟之上的桥的模糊形状，但具体如何建造这座桥，实际上还不清楚。
本书的整体核心是以价值链模型为理论基础，以基于价值链形成的业务流程为出发点，分析多场景下业务对象的本质，经过超越业务场景的实体抽象过程，得到企业级视角下的数据模型。
Togaf业务体系结构定义：
业务结构是将企业业务战略转化为日常业务的渠道，业务战略决定着包括业务运营模式、流程体系、组织结构、地域分布等内容在内的业务结构。
沉默的乌龟：
业务结构从企业战略出发，根据企业战略设计业务和业务过程。 业务过程要靠业务能力来支撑，从战略到业务，再到业务能力的需求，形成了支撑企业战略实现的能力布局，可以把这种布局理解为业务结构，那就是企业为顾客创造价值的设计过程。
业务体系结构设计完成后，就会产生“灵魂”。 IT体系结构根据“灵魂”的需求设计“容器”。
可以看到战略设计变革组织设计、组织设计影响战略设计、业务分析导出组件设计、组件设计优化业务分析。 战略和组织设计约束业务体系结构设计，业务体系结构设计实现战略和组织设计。
作者在书中说，商业架构的设计包括行线和知线两条线。
很多技术人员不重视企业战略，认为企业战略与技术无关，这种想法是大错特错的。
如果一个企业的战略让员工觉得与自己无关，只能说明该战略本身和战略宣传失败。
不
落到流程中的战略是无法被执行的，而与战略落地无关的流程又是在干什么呢？创造的什么价值呢？为这样的流程开发的系统又是干什么呢？
这震耳发聩的提问也反映出了现实的问题，在fndbmh从业的过程中也发现同样的问题：业务人员、技术人员，甚至是管理人员对战略的忽视，这也严重制约了企业的数字化转型。
有句话叫：未来以来，你爱来不来。
数字化转型的今天如果还抱有原始软件思路，必定要被淘汰。
迈克波特价值链模型：在波特的价值链模型中，认为企业在创造价值的过程中，所有生产经营涉及的活动可以分为两类，即支持性活动和基本活动，前者支撑价值创造过程，后者完整价值创造和增值过程。
此价值链模型是沉默的乌龟老师此书的核心方法论。
价值链代表了构建企业能力统一视图的“横向”结构，每个价值链环节中均包含了若干个业务流程；业务领域代表了构建企业能力统一视图的“纵向”结构，描述了各类业务流程应如何通过组合实现领域级的业务目标。
业务流程即业务活动，业务活动是由不同角色分别完成的若干任务组成的，任务执行过程中其必然与业务数据发生联系。数据主题域可以将关系紧密的数据进行聚类，再将与数据关系紧密的行为（也就是任务聚类），形成包含行为和数据的业务组件，组件代表了企业的某一类业务能力。
利用5w1h分析法进行业务分析。
通过When,Who,Where,Why,How,What来做分析，分析到底为什么要干这件事，这件事到底有没有价值？其实有时候我们判断价值的时候，用一个简单粗暴的方式去判断的话，就是你产生一个新活动，产生一个新任务了，有没有产生新数据，如果没有产生数据的话，那这个任务本身它的价值就没有那么高了。
单从一个领域去分析，并看不出优势，当把两个、三个领域领域叠加起来，那么就可以抽象出公共能力、公共数据，就会形成整个业务视角，从价值创造过程到每个领域的具体活动任务。
标准化最重要的是数据标准化。企业级数据模型要保证数据实体和属性的唯一性，这样就不会产生重复的概念，重复的概念会造成“同义不同名”，影响数据的使用和统计结果。
任务标准化需要将流程模型与数据模型进行语义对接，分析重复的业务动作，做出标准化的建模判断。
业务上重新审视、理清业务流程，搞清楚具体差异；数据上重新检视实体划分的颗粒度是否正确，避免过度设计。
对于大型复杂的系统而言，需要践行标准化并持续建设，形成一张标准的企业能力地图。
如果架构设计人员缺位，业务部门和项目团队沟通的结果可能会和最初建模存在差异，久而久之积累出很多“地方语言”，业务架构只能“自说自话”。
一方面培养合格的业务架构师队伍，作为业务模型的“嘴”，另外是加强项目外的宣讲，用业务模型去解释业务。
不惜血本去做企业级开发，其实最重要的是转变企业文化，打破部门壁垒，让企业融为一体。这种一体化带来的内部变化、清晰分工和高效协作才是最具价值的，是未来长期竞争力的关键，也是打造“数字化”企业的基础。
做企业级难点不在于技术，企业级真正解决的问题是业务问题、组织问题、思想问题，是超越技术之上建立一个什么样企业的问题。
时间也是架构师的“盟友”，架构师不能指望一次性说服所有人，只能像“盗梦空间”一样，先在对方头脑中“植入”一个“想法”，再逐渐引导“想法”生长。
上述架构设计方法虽然也有基于流程和数据的标准化形成的组件和功能，但其对复用的表达依然偏重流程视角，是活动、任务的复用，而IT希望看到的，更直接的复用。
业务架构师的首要责任定义为：“促进业务与技术的深度融合”。
架构落地本质是一个沟通协调的过程。
虽然架构设计二十多年的历史中不愠不火，但在阿里集团内部发展的很好，证明了业务架构设计有助于建立中台规划。
企业级业务架构设计方法并非“银弹”，更不能简单照搬其他企业的架构套在自己身上。它更像一面镜子，镜子中照出的只能是你自己，而照镜子的过程也是一个“赋能”过程，赋予你认清自己的能力，达到“自知者明”的状态。
一个普通士兵想要变成一个特种兵，不是因为给了他一身价值高昂的装备，而是经过了地狱般的训练。上至管理者，下至普通员工，若人的思维不发生转变，则不会带来企业的转变。
软件行业没有“银弹”，任何方法都需要长期坚持并灵活运用，企业级架构是不断演进和迭代的。