##企业中台理解学习笔记
建设之前考虑的四个问题
中台建设的愿景是什么？
- 中台只是解决方案而已，并不是问题。
- 建设之前明确建设的目标，对企业战略规划，对业务的价值
- 如何判断赶时髦的建设
用户群体？
用户是谁，相关利益干系人有哪些
- 如何平衡组织重构，利益职责分配的问题
- 如何兼顾各方利益和解决企业管理层对公司长期生存与可持续反正的恐慌与焦虑问题。
成本问题
- 谁来成本建设成本，业务部门众筹还是战略部门投资建设
如何判断建设的结果
- 考核指标问题，参考其他公司，结合具体的业务
中台落地的方法论D4模型
第一个阶段是Discovery，企业战略分解及现状调研
回答要不要建中台、建哪些中台、谁先建谁后建这些问题
由外到内：行业与竞争对手分析，常见方法：五力模型，SWOT，商业模式画布，竞争对手产品线分析
自上而下：企业战略分解
企业战略就可以简化理解成：结合企业自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢？
而企业战略分解就可以简化理解成：结合企业各部门自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢？
建立从愿景、目标到投资举措自上而下的对齐
自下而上：现状调研与分析
充分尊重过去遇到的所有问题，收集汇总痛点
跳出过去的限制，重新从业务出发，从用户出发，去重新探索基于新技术、新架构下的一些新的可能性。
工具和实践：高层访谈、干系人地图、组织架构分析、战略设计思维、业务架构现状梳理、用户旅程、服务蓝图、领域驱动设计、应用系统现状梳理、技术架构现状梳理等等。
建议
- 先完成自上而下的企业战略分解，再开展自下而上的现状调研。因为做完战略分解，我们已经对于公司的行业、业务、愿景、战略已经有了一些了解，再开展调研的时候就会有个全局的把控，对于粒度和深度都更容易拿捏。
- 做好充分的准备，能够提前通过阅读资料和小范围调研完成的内容就提前完成。
- 制定详细的计划，可以按照现状调研的总时间倒推梳理的范围和粒度。如果时间足够，可以用两天的时间梳理一条业务线的业务架构，这样梳理就可以深入一些。但如果只有半天，则粒度可以适当放粗，先保证有一个全局业务视图。
- 在判断不好的时候，可以先粗一些，如果最后还有时间，也可以再做一轮调研向下再展开一层。
- 建议刚开始做的时候，可以粒度粗一些，不要过早陷入细节，不过粒度到底如何控制确实需要对于公司战略以及业务有深入理解，也是最见功夫的地方。在判断不好的时候，可以先粗一些，如果最后还有时间，也可以再做一轮调研向下再展开一层。
第二个阶段是Define 企业数字化全景规划
结合自上而下企业战略分解的举措和自下而上现有业务架构梳理和分析的问题及痛点，重新设计新的业务架构，并进一步推导出其它的相关的架构设计。
引入了事件风暴、DDD工作坊等协作互动形式整个过程各个关键角色充分讨论，协作共创，力争在过程的轻量前提下，还能保证结果的准确与一致。
难点，如何从企业整体的视角，更准确地识别出多业务线之间的共性业务元素
中台复用的能力类型到底有几种？
四类共性能力：业务数据、业务功能、业务流程以及通用的技术能力
透过业务流程识别出有哪些类似的能力复用场景：领域驱动设计
领域驱动设计结合事件风暴（EventStorming）这两个工具，通过工作坊的形式来对业务流程背后的问题空间和解空间做进一步的分析，识别出关键聚合，再通过跨业务线的问题域叠加投影，找出大家共同关注的问题空间和聚合，从而继续扩展来做共性场景和能力识别。
中台和微服务的区别与联系
- 中台解决的是业务领域的业务（数据、功能、流程）复用的问题，而微服务架构作为一种轻量级分布式技术架构，解决的是技术领域的“组件编译时依赖”造成的问题。
- 微服务的核心关键点是，能独立被交付部署。
- 业务中台和微服务抽象的层次完全不同
- 微服务架构运行时依赖的低耦合特性，通常被用于实现业务中台中不同能力单元的团队分离、技术分离、交付周期分离等特性而已。
回顾平台型企业架构的规划过程
- 首先通过各条业务线的现有业务架构分析，再结合识别的痛点做的根因分析，做业务架构上的改进与设计，从而对于现有的业务架构进行改进，设计出新的改进后的业务架构，解决现在痛点背后的问题。
- 同时还要参考战略分解后对于各条业务线的目标和举措，融入To-Be 业务架构的设计当中，使新的业务架构设计同时匹配企业战略要求以及解决短期战术痛点。
- 对于改进后的业务架构，做跨业务线的比对和分析，就能帮助我们发现不同业务线的业务功能及业务流程的重叠情况，为后续中台建设的必要性判断提供业务层面上的支撑和输入。
- 使用领域驱动设计（DDD）的战略部分，针对于每条业务线，做问题域和限界上下文分析，以及关键聚合的识别，从而试图穿越流程，从领域的角度深入一层审视业务的本质，到底是在解决哪些问题空间的问题，并通过问题域的划分（核心、通用、支撑），区分问题空间对于企业的重要性。
- 类似于业务架构，同样对于各条业务线分析出来的领域分析视图，做横向比对和投影，从领域层识别不同的业务线中的问题域、限界上下文以及聚合的重合度。这么可能比较抽象，你可以理解成类似于将几张半透明的画摞在一起，来找相交部分一样。帮助我们识别业务数据以及业务模式（功能 + 流程）上的深层次共性能力。
- 结合现有的业务架构及应用架构，做各条线的应用架构设计改进，并通过 As-is 和 To-Be 的应用架构做 Gap 分析，产出 IT 建设的具体机会点，这样的机会点就类似于新建一个 CRM 系统之类的。
- 再基于跨域的业务架构分析和跨域的领域分析，讨论判断多条业务线的业务重合度，并详细识别重合更多是在业务模式级别的重合（出行、电商）、业务功能级别的重合（登录，购物车）、还是业务领域（用户数据打通）级别的重合。基于讨论结果，决定是否有必要引入中台层建设，以及根据重合情况，详细展开规划中台层的应用架构。
最后再分析当前现状与 To-Be 的最终规划之间的差距，产出具体的机会点列表，并且基于多维度（常见的例如战略重要性、紧急程度、成本、资源就绪情况、技术就绪情况、风险、痛点 Mapping 等）做优先级排序，产生最终的路线图。
第三个阶段是Design中台的规划与设计
确定中台产品愿景
用电梯演讲的方式来发散和收敛产品的愿景
愿景的价值和难点就在于充分收敛，后期遇事不决看愿景
确定业务梳理范围，中台产品的愿景确定后，下一步就需要进行细粒度的业务架构梳理，抽取共性，识别中台产品的具体需求了。
细粒度业务梳理，小心因为历史原因导致的避免伪需求。
业务梳理过程中大量地采用了基于设计思维，结合用户体验地图（User Journey Map）和服务蓝图（Service Map）的方式。回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理。
业务中台需求梳理后，确定 MVP（Minimum Viable Product，最小可用品）
开始中台建设之前需要明确的两点:运营计划和度量指标。
运营前置：制定迭代计划及接入计划
度量前置：定义验证指标,
第四个阶段是Delivery中台的建设与接入
中台人员能力模型
精益产品研发流程结合敏捷开发流程，小批量快速开发产品，快速引入度量，基于测量的数据快速对于之前的需求假设进行验证和认知，并基于此做快速的调整。
中台的运营、治理与演进
中台产品的用户划分
资料总结
书籍
- 中台概念
- 《企业 IT 架构转型之道 阿里巴巴中台战略思想与架构实战》
- 《中台战略：中台建设与数字商业》
- 战略与变革
- 《论大战略》
- 《战略的本质》
- 《领导变革》
- 《商业模式新生代》
- 《系统思考》
- 平台型组织
- 《释放潜能：平台型组织的进化路线图》
- 《重塑海尔：可复制的组织进化路径》
- 《赋能：打造应对不确定性的敏捷团队》
- 企业架构方法
- 《TOGAF 标准 9.1 版》
- 《企业级业务架构设计：方法论与实践》
- 《决胜 B 端：产品经理升级之路》
- 设计思维（DesignThinking）
- 《战略设计思维》
- 《创新设计思维》
- 领域驱动设计
- 《领域驱动设计：软件核心复杂性应对之道》
- 《实现领域驱动设计》
- 《领域驱动设计模式、原理与实践》
- 敏捷 & 精益
- 《精益思想》
- 《精益创业》
- 《精益企业：高效能组织如何规模化创新》
- 《看板方法：科技企业渐进变革成功之道》
- 《持续交付：发布可靠软件的系统方法》
- 架构演进
- 《演进式架构》
- 《架构整洁之道》
- 《微服务设计》
- 中台概念