1.2 再提业务平台化，是因为深水区实践中，新的问题将业务平台化内涵向前演进

平台化是从信息化到数字化时代，每一轮 IT 建设都会提及的主题之一。而当平台沿着历史发展的趋势继续向业务的“逼近”过程中，对于平台抽象和建设的难度也成指数型增加，涌现出了一系列新问题。

对于这些问题的思考和解决方案的探索，也将赋予业务平台化这个趋势以新的内涵和意义，同时也是我们设计和发布新的企业架构框架的起心动念。这些问题的“新”意，更多的体现在“how”上，而不再仅仅是“what”，所以我们以“如何”的句式来逐一总结和简述：

1）如何抽离多业务线共享的解决方案和能力，集中管控和演进，以避免重复投资？新业务如何基于企业已有的解决方案和能力快速组装上线，以支撑业务快速迭代创新？

今天，业务发展和 IT 建设的绑定比以往任何时间都更加紧密，而当大型企业的业务涉猎已足够广泛，多条业务线、或者多个业务单元并行发展，IT 建设会随着业务边界、组织边界，不可避免的进一步分化，也加剧了 IT 部门进行统一管控的困难。

一方面，在很多场景中，这样的分化带来了双重投资甚至多重投资的浪费 ；另一方面也在加剧本就存在的用户或者客户体验的割裂、数据孤岛、IT 翻新周期长等固有问题。

同时，当业务线不断尝试新的业务模式，或对于已有模式进行更快的试验、调整与扩展。对于 IT 支撑的响应力也提出了更高的要求。固有的系统搭建或者产品部署模式，越来越不足以提供及时的响应，且在“快速试错”、“小步快跑”的创新场景应对下，成本高昂。

因此，如何抽离多业务线共享的解决方案和能力，集中管控和演进，以避免重复投资？新业务如何基于企业能力快速组装上线，以支撑业务快速迭代创新？是需要的解决问题。进一步拆解，我们认为需要回答：

• 针对不同的业务深度，如何设计模式与能力模型，以对业务进行合理的抽象，进而识别相似度，抽象与提炼可复用的业务模式；而针对不同业务的差异性，如何在模式和能力基础上进行扩展？
• 抽象并沉淀了业务能力之后，如何在新的业务场景中，识别、复用已有能力，应用、数据、技术及组织应该如何予以支撑？
• 以上的工作过程，是否有较好的工作实践和参考模型？

2）如何合理地划分 IT 系统边界，以得到随“需”而变的响应力

除了能力复用外，另一个提升 IT 支撑响应力的关键是，提升 IT 系统各组成部分的自治性，使得变更能够相对独立的，在更小的边界范围内，以小步快跑的方式发生，同时还需要保持一定的一致性，使整体架构做到“形散神聚”。

因为无论是创新也好，集中管控也好，虽然变化速率不同，但变化始终存在，既然变化不可避免，我们应将精力投入到应对变化上。而一个清晰的应用边界划分，可以对于业务能力通过对于知识边界的解耦，实现知识的黑盒复用，对于变化的响应非常有帮助。

在我们的经验中，应用边界划分不合理会对应对变化产生明显的负面作用。一般来说，边界的粒度过粗，容易产生功能、运行层面的变更冲突，而边界的粒度过细，则带来了额外的变更成本和性能开销，这里对各种负面作用暂不作展开，但它们的共同点是都会拖慢 IT 支撑的响应力或稳定性。

因此，“如何划分 IT 系统的应用边界，以合理的布局更好地应对变化”是需要解决的问题。进一步拆解，我们认为需要回答：

• 如何划分应用 构建块的逻辑边界，使其尽可能职责单一、接口规范明确，容易变更和组装？
• 如何组合应用 构建块成为合适粒度的独立可部署单元，尽可能减少功能、运行层面的变更冲突？
• 如何描述、留存以上决策的结果和依据，当变化发生时，通过溯源做出优质的新应对？

3) 如何适当拆分过于集中的分析类数据处理职责，以缓解规模化数据分析处理瓶颈？

长久以来，业界对数据架构的通用做法是：对于运行类（Operational）和分析类（Analytical）场景，应该使用不同的设计方法和技术支撑。

运行类场景以业务事务为主线，关注点在于业务事务运作证据的完整性和一致性，以及确保各类数据在各业务单元间高效、准确地传递，实现跨业务单元的事务推进以及对于业务溯源的支撑。

分析类场景则需要对内、外部数据进行收集和加工，用来度量业务运行表现、尝试分析产生偏差的原因，甚至结合机器学习等技术给出对于未来发展趋势预测和判断，尝试构建数据驱动运营的企业组织。数据想要形成分析类价值，背后需要经过 摄取（Ingest）- 加工（Process）- 能力包装（Serve）三大工序，其又可以进一步分为数据仓库、数据湖、数据与 AI 平台、数据中台等构建模式，它们都有着各自不同的适用场景和技术栈，针对这些模式的差异我们暂不作展开。

由于分析类场景所要求的方法和技术与运行类场景有着显著的不同，许多企业组建了专职的数据团队，将分析类数据处理工作和其背后的复杂性打包成为一个黑盒，提供端到端的统一的数据类企业级服务与支撑。

这个模式对于业务场景简单的企业环境工作得不错，但对于多业务线、业务平台化的企业环境已初显疲态。一方面，随着 IT 建设加速，数据源和分析类场景的数量激增，对数据类服务的响应力提出了更高要求。另一方面，想要提供高质量的数据类服务，除了分析类数据的专业技能，还要求对于业务场景、现有应用软件的深入理解。如果所有工作仍然只由专职的集中式团队一肩挑，团队带宽的限制必然会拖慢响应力。

因此，我们认为需要探索的是如何适当拆分过于集中的分析类数据处理职责，为集中式的数据团队减负，使其可以将精力投入到高价值的分析类场景中。

4）如何在富技术时代进行平台型技术架构选型及设计？

受益于云原生架构的兴起与发展，新技术的涌现和不断成熟，及技术工具的极大丰富，技术架构设计的灵活度和效率都得到了显著提升。

另一方面，在平台型技术架构的设计中，作为多业务线、多应用、多数据场景落地的技术基座，技术架构设计所需覆盖的规模、应对的复杂度今非昔比。加之“富”技术条件的加持，技术架构的设计困难度正呈现指数级增长。而一直以来，本质上是强依赖架构师的经验和能力的技术架构设计方法和过程，在这样的语境下，一系列挑战和问题再次凸显：

• 对于架构需求把握不足或者没有架构需求的分析意识，过早的进入架构设计，导致系统复杂度变高甚至过度设计，为开发落地带来额外的研发成本
• 架构设计采用的技术和工具过于超前，超出团队成员技术水平，造成落地难度高，新成员上手速度慢，进而对整体进度和实施效果造成影响
• 架构设计过程时间长，完成后团队就不再愿意对设计方案继续调整和迭代，当技术发展变化很快时，技术架构方案容易进入“完成即落伍”的困局。

因此，我们认为架构师们比以往，更需要这样一个体系：

• 系统性的分析架构需求
• 结构化的设计架构方案
• 沉淀可复用的架构经验