本文内容主要来自Clean core extensibility白皮书
SAP发现企业在实施定制化拓展时往往遇到很多问题，包括但不限于：标准功能是否满足需求，有哪些拓展方式是可选的，不同方式可以达成什么样的效果，未来该如何维护这些拓展才能保证持续的创新能力等等。
所以SAP推出了Clean Core方法论，为组织在拓展核心IT系统时提供指导意见，帮助组织打造一个清洁的核心。
清洁核心方法论下又包含了五个维度的清洁，分别是业务流程/拓展/数据/集成/运营 维度的清洁性，本白皮书主要关注拓展层面的清洁核心原则
如果您对BTP感兴趣，BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容
白皮书内容较多，章节1，2的内容见Link，章节3的内容见Link
本文包含了章节4的内容，主要介绍如何实现清洁的扩展，提供实用的、分步的治理、测量和实施清洁扩展的框架。涵盖工具、方法论（如SAP应用扩展方法论）和监控和执行Clean Core遵循的KPI。
4 如何实现扩展性的Clean Core？
4.1 Clean Core测量框架
Clean Core测量框架将成熟度评估与定量KPI相结合，推动持续改进：
4.1.1 治理与成熟度—— 评估Clean Core的方法
评估方法旨在批判性地评估和加强组织内的治理流程，使其与Clean Core最佳实践保持一致。它通过提供更深入、更注重实践的Clean Core治理视角来补充RISE with SAP方法论。
虽然这种方法涵盖了所有五个洁净核心维度，但本白皮书重点关注可扩展性。为此，评估框架围绕12个关键方面构建：7个方面评估治理成熟度，5个方面评估底层系统的就绪程度。
每个方面都代表了维护Clean Core所必需的独特治理领域。治理成熟度通过详细的评估标准进行衡量——按照从0（未开始）到5（专家级）的成熟度量表进行评分。这种评分使组织能够将其当前状态与目标成熟度水平进行基准对比。
通过识别每个实践当前得分与期望得分之间的差距，企业可以精确定位需要改进的领域。由此产生的洞察有助于定义有针对性的行动，然后可以在结构化路线图中对这些行动进行优先排序和调度。这确保了改进动作既实用又可在规定时间内实现，推动向强大的Clean Core扩展性框架持续进步。
4.1.2 可测量性：扩展性KPI
这些KPI用于衡量Clean Core原则的遵循情况。它们来源于从客户系统收集和分析的数据。此外，我们还将解释如何计算这些KPI，以及可以利用哪些工具让不同层级获得洞察。
下表提供了可扩展性相关KPI的高层次概述
KPI描述行动价值Clean Core份额根据Clean Core等级概念对自开发拓展进行分类记录最需要改进的地方，例如，通过减少等级D对象的份额来提高评分可视化自定义代码分布；识别需要立即关注的领域；跟踪随时间的变化； 衡量进展 • 支持战略决策制定；确保长期可维护性技术债务评分对于开发对象的评分，评估相关技术债务。允许基于各种标准（如开发包）进行聚合识别技术债务负担高的对象清晰客观地衡量影响系统可维护性的因素；确定每个对象与理想A级拓展的距离未使用代码份额即未被使用的自定义对象占所有自定义对象的比例突出潜在可清理和优化的对象维护精益高效的系统架构业务修改程度系统中业务修改的数量识别业务修改的程度，这将导致升级的风险和工作量识别对更清洁扩展实践的需要
在以下内容中，将为每个KPI解释目的、测量方法和相关数据源。
4.1.2.1 Clean Core份额
4.1.2.1.1 为什么测量Clean Core份额？
该KPI提供自定义代码对象如何在不同Clean Core等级中分布的全面概述。它帮助识别可能需要立即关注的领域以及可以期待改进的地方，例如，减少等级D对象的比例。
4.1.2.1.2 Clean Core份额的洞察是什么？
Clean Core份额根据Clean Core等级概念，基于其最差参考等级，对每个自定义代码对象进行分类。
4.1.2.1.3 如何测量Clean Core份额？
Clean Core份额通过根据其最差/最低参考等级对每个对象进行分类来计算。
例如，如果某自开发对象甲引用了内部对象，则被归类为等级C，而ABAP Cloud模式下的自开发对象被归类为等级A。份额计算为所有自开发对象在各等级的分布，例如，等级A：10%（100个自开发对象属于等级A），等级B：50%（500个自开发对象属于等级B），等级C：35%（350个对象），等级D：5%（50个对象）。
4.1.2.2 技术债务评分
4.1.2.2.1 为什么要测量技术债务评分？
虽然Clean Core份额提供总体概览，但技术债务评分更具可操作性。它量化每个自定义代码对象中技术债务的程度，提供影响系统可维护性因素的清晰客观衡量。
4.1.2.2.2 技术债务评分的见解是什么？
技术债务评分按对象计算，可以按各种标准（如开发包）聚合。它通过衡量每个对象与理想Clean Core等级A的偏差，突出扩展中最大技术债务的位置。当与扩展对象的大小结合时，技术债务评分有助于确定债务的相对规模。
4.1.2.2.3 如何测量技术债务评分？
技术债务评分是基于对SAP对象引用严重性的加权评分。例如 ABAP测试驾驶舱 test cockpit中报错的权重因子分分布为：每个错误10分，每个警告5分，每个信息消息1分。评分是这些加权值的总和。示例：5个错误、20个警告和10个信息消息导致评分为5*10 + 20*5 + 10*1 = 160分。
4.1.2.3 未使用代码份额
4.1.2.3.1 为什么测量未使用代码份额？
每个自定义代码对象都代表潜在的技术债务。识别和移除未使用的代码对象对于维护清洁高效的系统至关重要。
4.1.2.3.2 未使用代码份额的见解是什么？
自定义对象是SAP标准之外的客户创建扩展。Clean Core的一个关键目标是最小化未使用自定义对象的数量。未使用代码份额测量未被使用的自定义对象比例，突出潜在清理和优化领域。
4.1.2.3.3 如何测量未使用代码份额？
测量未使用代码份额需要激活使用数据测量。推荐使用ABAP调用监控器（SCMON）收集此数据，以及事务SUSG用于随时间聚合使用数据。
基于系统中自定义对象的总数，可以确定未使用对象的份额。例如，如果1,000个自定义对象中有300个未被使用，则未使用代码份额为30%。
4.1.2.4 业务修改（在RISE with SAP方法论仪表板中可用）
4.1.2.4.1 为什么测量业务修改数量？
修改涉及对扩展点之外的SAP标准代码的更改。因此，它们通常构成升级风险并可能导致额外的维护工作。
4.1.2.4.2 业务修改数量的见解是什么？
业务修改是经典扩展性的子集，记录在SMODILOG表中。它们解决SAP标准中的功能差距，但不符合Clean Core原则且不升级稳定。测量此KPI有助于识别此类修改的程度，突出对更清洁扩展实践的需要。
4.1.2.4.3 如何测量业务修改数量？
修改分析解释了如何使用模式从SAP表SMODILOG提取数据，以识别非有意创建为业务修改的技术修改。结果可以在自定义代码分析仪表板或RISE with SAP方法论仪表板中查看（参见第4.4.1章的示例）。
4.2 通过”保持清洁”和”获得清洁”达到Clean Core
在SAP扩展性中实现Clean Core需要一个结构化的、持续的治理过程，引导每个扩展朝着最小化技术债务同时最大化业务价值的方向发展。两个互补的模式指导如何实施这种方法：保持清洁和获得清洁。
保持清洁专注于防止每个新扩展积累不必要的复杂性。它首先严格评估功能需求。任何提议的扩展必须有清晰的业务案例，不能通过标准SAP功能解决，并应与流程差异化策略保持一致（反映Clean Core流程原则）。
接下来，扩展架构步骤确保通过治理化、结构化的框架（如SAP应用扩展方法论）选择最佳适配的架构方法，并具有透明度和可重复性的适当文档。在扩展实施期间，开发人员接受集中支持和控制——如授权检查和自动化质量工具（如ABAP测试驾驶舱）——以确保他们遵循架构标准，同时对任何偏差进行彻底文档记录和治理。最后，扩展部署通过强制只有合规和质量检查的代码进入生产，与运营Clean Core原则相结合。自动化代码验证和严格控制的豁免流程保证与整体治理的一致性。
获得清洁通过解决现有技术债务来补充这种预防性方法。它涉及测量相关KPI以精确定位改进领域，采用“童子军原则“，鼓励开发人员在任何修改期间使代码比发现时更清洁（纳入项目估算），并为遗留代码库中的技术债务减少设定现实但雄心勃勃的目标。这些模式共同建立了一个整体、迭代的治理框架，维护扩展性的Clean Core基础，平衡创新速度与长期系统可维护性。
以下章节将探讨基于这种方法实现Clean Core所涉及的步骤。
4.3 保持清洁：如何创建清洁扩展
4.3.1 功能需求
功能需求是标准SAP解决方案未满足的业务需要。它们通常在适配标准研讨会期间识别，并在SAP Cloud ALM中管理，后者将它们直接链接到业务流程。虽然功能需求很常见，但数据隐私、安全性和可扩展性等非功能方面也是扩展设计的关键驱动因素。
4.3.1.1 需求收集
适配标准研讨会的关键目标之一是确保在适当的业务环境中收集需求。SAP Cloud ALM（RISE with SAP方法论的组成部分）通过提供允许用户以最简单的格式在正确业务环境中创建需求的功能来简化需求收集过程。识别需求和定义扩展与Clean Core”流程“原则密切相关。需求不仅可以在流程层面创建和链接，还可以在几乎每个包含的图表元素上创建和链接，无论流程是SAP标准流程还是客户流程。有关基于行业标准构建韧性业务流程和评估差异化扩展需要的更多指导，请参考SAP S/4HANA CloudClean Core业务流程白皮书。该资源还更详细地涵盖了适配标准方法。
需求可以分解为更小的用户故事，但业务用户的初始关注点只是陈述需要；专家顾问稍后确定最佳解决方案，无论是通过配置还是扩展。
当功能差距需要扩展时，必须以Clean Core合规的方式开发。这意味着扩展必须与SAP S/4HANA Cloud代码解耦，以确保它不会破坏升级（例如由于数据损坏或系统故障），并且升级不会破坏扩展。Clean Core扩展性模型旨在实现这种分离，允许客户从SAP接收持续创新而不受干扰。
至关重要的是，扩展必须提供切实的业务价值。即使技术上合理，如果扩展不能解决差异化业务需要或相同功能可以通过SAP标准功能或认证合作伙伴解决方案实现，则被视为“不清洁“。因此，每个潜在扩展必须经过明确定义的治理过程。
4.3.1.2 治理：建立并遵循Clean Core指导原则
强大的治理框架对于维护Clean Core至关重要。主要目标是尽可能接近SAP标准，确保任何偏差提供清晰的增值差异化。这涉及建立优先级和分段的业务流程层次结构，将业务流程分类为标准、差异化（增强和自定义开发）和创新层，以优化资源分配并将开发重点放在高影响领域。
图9展示了当前和目标流程类别分布之间的示例比较，强调标准和创新流程的增加。
一旦业务流程符合Clean Core要求，就更容易确定需要偏离标准的地方。清晰的治理过程确保在SAP S/4HANA扩展性模型中利用最佳可用选项。
如前所述，重要的是最小化扩展的使用以降低ERP系统的复杂性和维护开销。根据这一目标，扩展的批准应该由明确定义的治理结构管理。组织必须为评估和证明扩展设定高标准。每个扩展的理由必须清楚记录，以及它提供的预期业务价值。
图10概述了在SAP系统内评估和实施新业务需求或差距的结构化决策过程，支持制造或购买决策。
如果用例不能被标准解决方案覆盖且足够有益以证明创建自定义扩展的合理性，流程将继续进行扩展架构方法以进行实施
根据功能需求定义和文档期间概述的设计，将应用SAP应用扩展方法论（参见下一章）来定义扩展架构。
通过建立中央权威机构或团队（如解决方案标准化委员会）来监督SAP ERP中业务流程的设计和实施，验证扩展的必要性并确保首先考虑SAP标准选项，可以实现对待开发流程、业务需求和设计批准的集中治理。这使组织能够：
在满足业务需求的同时使所有流程与最佳实践保持一致根据个人需要强制执行“清洁“开发要求对选定的扩展域进行清晰文档记录和证明确保所有偏差以标准化和一致的方式得到批准
4.3.1.3 使用SAP Cloud ALM支持Clean Core治理
SAP Cloud ALM对于建立Clean Core至关重要。通过利用SAP Cloud ALM，组织可以采用SAP的最佳实践内容，管理适配标准研讨会，并简化其需求管理流程。这有助于限制定制，降低复杂性并维护核心系统的完整性。集成的分析和可追溯性功能提供Clean Core合规性的清晰视图，使企业能够有效跟踪和管理其项目。
为了根据既定的Clean Core治理对SAP Cloud ALM实体进行分类，可以为流程、需求、用户故事和功能创建标签（例如“清洁“和“不清洁“）。
这些标签可以应用在SAP Cloud ALM的解决方案流程可追溯性分析页面上。它们允许评估计划或实施的解决方案流程以及分配的需求、用户故事和功能是否被分类为“清洁“或“不清洁“。从此视图，用户还可以导航到相关的可追溯性和概述页面（例如需求可追溯性）以检查更多详细信息。
4.3.2 扩展架构
SAP应用扩展方法论为客户和合作伙伴定义组织特定扩展策略提供结构化、技术无关的方法。
遵循此方法论确保所有项目利益相关者使用相同术语，并快速达成对业务用例和未来解决方案的共同理解。它提供可用技术扩展构建块的概述，实现对未来扩展架构的明智决策。它还支持创建扩展框架，以指导组织内的架构师和开发人员。
阶段1专注于基于定义区域内的业务环境和需求定义扩展用例。它涉及理解系统环境并相应记录扩展应用程序用例。
阶段2引入关键概念，如扩展样式、扩展任务和扩展域。它提供称为技术扩展构建块的各种扩展技术概述。结合扩展任务，它们帮助将业务需求转化为技术需求。
阶段3基于整体需求以及前一阶段扩展任务和构建块之间的技术映射，支持对目标解决方案使用哪些技术扩展构建块的明智决策。各种决策指导资产——如扩展架构指南、SAP Discovery Center和SAP架构中心——在塑造和完善目标解决方案方面提供进一步支持。
为了进行彻底分析，组织应该使用扩展任务指导模板和扩展任务技术映射模板，在选择技术扩展构建块之前记录自定义指导。
此过程支持开发清晰的设计指导，以确保考虑最佳Clean Core等级。SAP应用扩展方法论模板还协助设定排序和评估标准，以选择最合适的技术构建块。
开发人员可能偏好熟悉的工具而非最优解决方案，特别是当他们不熟悉ABAP Cloud或SAP BTP功能时。这种结构化方法有助于指导架构决策。
完成方法论后，产生几个交付成果：应用程序扩展用例描述（来自阶段1）、技术扩展构建块决策（来自阶段3）和扩展目标解决方案（来自阶段3）。这些交付成果可用作SAP Cloud ALM用户故事的输入。
有关SAP应用扩展方法论的更多信息和访问模板，请访问SAP帮助门户。
4.3.3 扩展实施
建立Clean Core思维
良好的开发实践涉及编写不仅解决即时需求，还考虑大局的代码：清洁架构、系统稳定性、长期可维护性以及与组织未来策略的一致性。一个实际例子：基于ABAP列表查看器网格创建报告在系统升级期间可能不会造成问题，但当组织计划迁移到SAP S/4HANA公有云时，它就成为技术债务。
代码不仅仅是技术性的——它是战略性的。
然而，采用Clean Core思维超越了编写代码。它还涉及花时间考虑重用，退后一步专注于技能提升，并重新评估开发方法而不是匆忙实施。Clean Core思维塑造了扩展的规划和执行方式。
开发指导原则
为了将Clean Core思维转化为日常实践，建立清晰的开发指导原则很重要。这些指导原则有助于确保一致的实践，无论是关于使用正确的API、避免某些增强还是遵循命名约定和编码标准。
当规则清晰时，开发人员可以专注于构建高质量、面向未来的解决方案，而无需猜测允许或期望的内容。
明确定义和记录的标准也使新开发人员更容易入职，并在不同项目中保持团队一致。这些指导原则应该易于访问、定期更新，并通过自动化代码检查和同行评审等工具得到加强。有了这样的结构，团队将有坚实的基础。虽然这些指导原则可能总是个性化的，但在开发指导原则方面有很好的起点可以考虑和参考：
“在云端和本地使用基于ABAP的扩展扩展SAP S/4HANA”指南清洁ABAP指南和备忘单ABAP备忘单
技能发展
在建立开发规则后，重要的是根据员工的角色和技能启用workforce：开发人员需要学习如何为SAP S/4HANA构建现代业务应用程序，并从经典ABAP开发人员发展为ABAP Cloud开发人员。
SAP Learning提供几个免费学习路径，如：
获得核心ABAP技能管理SAP S/4HANA Cloud的Clean Core实践S/4HANA Cloud的Clean Core扩展性
这些路径有助于准备获得SAP认证助理——后端开发人员——ABAP Cloud认证。
此外，首席开发人员和解决方案架构师应该扩展其知识以保持扩展开发的全面视图。这可以通过成为SAP BTP解决方案架构师的学习路径实现，该路径也提供认证。
这个启用过程需要时间和管理承诺。为相关主题建立一个或多个卓越中心可以支持推广并有助于推动整个组织的Clean Core采用。
开发清洁扩展
在实施开始时，识别与SAP标准的所有接触点至关重要，如用户界面（应用程序、表单、报告）、集成（集成流、事件）、业务逻辑（业务附加组件）、API（CDS视图、业务对象接口、BAPI）以及持久性（表）。这种方法有助于澄清与SAP标准和核心的所有潜在依赖关系，并显示扩展的耦合程度。
有了这些信息，应该使用自顶向下的方法规划开发，从Clean Core等级A到Clean Core等级D，从紧密耦合过渡到松散或完全解耦的扩展。
对于紧密耦合的扩展，起点是SAP S/4HANA关键用户扩展性选项（等级A）和搜索合适的发布扩展点。发布的扩展点可能是，例如，业务环境中的字段扩展或业务逻辑扩展。识别这些发布扩展点的方法可能因特定SAP ERP部署模型（SAP S/4HANA公有云、SAP S/4HANA私有云或SAP S/4HANA）和版本而异。
在较旧的SAP S/4HANA版本上，可能需要直接在目标应用程序的文档中检查扩展性选项。可以通过在SAP Fiori应用程序参考库中搜索相应系统版本的应用程序、导航到实施信息选项卡并找到扩展性部分来访问。那里链接的应用程序扩展性文档提供有关扩展性选项的详细信息，如用于此应用程序的业务上下文。对于其他对象，可以使用事务SCFD_REGISTRY查找系统中注册的每个扩展点。
当需求过于复杂而无法通过关键用户扩展性实现时，需要使用开发人员扩展性（等级A）的扩展。在”体外Side by Side”或混合扩展域中，流程通常从探索SAP Business Accelerator Hub上的远程公共API开始，如OData服务、REST服务或可以从核心系统公开的事件。SAP Business Accelerator Hub为使用这些API提供全面资源，包括业务文档和扩展选项详细信息。对于”体内On Stack”扩展，可以使用Eclipse的ABAP开发工具通过基于API状态过滤对象来识别发布的公共API，如CDS视图、业务对象接口或业务附加组件。
注意：必须查看每个API的引用业务文档，因为某些API可能不合适——例如，如果业务功能未实现。如果适用，检查是否存在前身经典API。
当已知经典ABAP对象时，用户可以通过检查API状态属性或咨询云化存储库来识别后续对象。
云化存储库还提供对发布API未来的一瞥。通过选择所需的系统版本，可以检查API是否将在即将发布的版本中变得可用。如果不存在发布的本地公共API，下一步是在云化存储库中探索经典API（等级B）。
要识别合适的扩展技术或框架，请参考SAP注释3578329，它将遗留技术分类为Clean Core等级并提供推荐使用的清晰指导。
当超出等级A的边界时，开发人员应该在应用程序开发期间实施额外的保护措施。由于内部对象可能不稳定，监控SAP对象变更日志以接收有关不兼容变更的早期警告并在使用此类对象时格外小心是至关重要的。为了验证预期行为，应该创建单元测试并在每次系统升级后运行，特别是使用内部或不推荐对象时。
SAP强烈建议在等级A（ABAP Cloud）内最大化开发，以减少对等级B到D对象的依赖。一个有效策略是在包装器内封装经典API、内部对象或不推荐对象，然后可以使用API合同为ABAP Cloud公开。详细信息可在ABAP Cloud API启用指导原则中找到。
4.3.4 扩展部署
一旦扩展按照Clean Core方法设计和实施，下一个关键步骤是通过结构化治理和技术控制来强制执行这些原则。即使是最严格的开发策略也可能被单个未审查的传输或管理不当的豁免所破坏。
为了确保长期可持续性、代码质量和系统稳定性，必须将自动化执行和问责机制直接嵌入到开发和部署流程中。
图14显示了不同的Clean Core治理选项，在以下段落中解释。
在非ABAP环境中，使用静态代码分析工具（例如，CAP的CDS Lint）来确保代码遵循定义的编码规则。SAP S/4HANA系统内运营Clean Core治理的核心依赖于使用ABAP测试驾驶舱的自动化检查。这些检查应该紧密集成到传输释放流程中。SAP提供预交付的ABAP测试驾驶舱变体，作为强制执行Clean Core规则的可靠基准。鼓励组织定制这些变体以与其内部政策保持一致。
将这些变体纳入传输释放流程确保每当开发人员释放传输时检查自动运行。当识别出高优先级问题（通常是优先级1或2）时，应该阻止传输，直到违规得到解决或通过定义的治理流程明确豁免。
要为经典ABAP开发模型设置治理，请参考ABAP扩展性指南。
然而，没有结构化的豁免流程，任何执行策略都是不完整的。虽然Clean Core政策应该严格应用，但可能出现合法的例外情况。这些必须被有意识地承认和治理，以防止开发标准的逐渐退化。应该建立正式的豁免程序，由指定的质量经理（理想情况下是高级开发人员或架构师）负责审查并批准或拒绝请求。每个豁免请求必须包括清晰的理由、对正在放弃的具体发现的引用以及涉及的开发对象列表。所有决策必须记录在ABAP测试驾驶舱内，以确保完全可追溯性和问责制。应该为每个豁免定义时间限制，并且应该避免在对象或包级别的广泛或通用豁免。现有豁免的定期审查，通常涵盖10-20%的案例，有助于验证持续相关性并支持开发指导原则的持续完善。
为了在结构上强制执行Clean Core开发，最有效的措施之一是将ABAP语言版本限制为ABAP Cloud。这种限制可以通过分配S_ABAPLNVS授权对象和/或创建仅支持ABAP Cloud的专用软件组件来实现。建立这样的组件引入了清晰的架构边界，并允许开发人员角色的分离。
标准ABAP Cloud开发人员可以与具有提升权限的受信任开发人员区分开来，使管理谁被允许使用遗留或无限制对象变得更容易。这种分离增强了透明度，简化了维护，并降低了引入不合规代码的风险。
除了管理语言版本限制外，组织应该激活监控API使用和增强技术的ABAP测试驾驶舱检查。这些检查在SAP注释3565942中提供，通过基于稳定性和升级安全性对API和技术进行分类来引入Clean Core等级。有关设置详细信息，请参考ABAP扩展性指南中的“为经典ABAP开发模型设置治理“章节。
当使用等级B、C或D对象时，开发人员本质上使用标准ABAP语言版本，这是包括ABAP Cloud和关键用户ABAP的超集。虽然使用ABAP Cloud就绪检查变体是可选的，但强烈推荐。激活此变体有助于减少对标准ABAP语句的不必要依赖，并促进等级A中云就绪和升级稳定代码的开发。
为了支持等级A对象的采用并进一步增加其份额，组织应该为非发布SAP对象创建封装包装器。这些包装器然后可以发布供ABAP Cloud使用，有效地弥合不合规遗留代码和现代合规开发实践之间的差距。
自动化ABAP单元测试在维护代码稳定性方面发挥重要作用，特别是在处理经典API（等级B）、不确定稳定性的对象（等级C）或缺乏正式API的开发（等级D）时。虽然结构性变更（例如，重命名字段）通常可以在编译时检测到，但行为变更，如改变的逻辑或计算，通常不会被注意到。ABAP单元测试充当此类回归的保护措施，确保即使底层实现发生演变，预期的代码行为也得到维护。
SAP在SAP对象变更日志中持续发布经典API和内部对象的更新。通过定期审查此变更日志，开发团队可以主动识别潜在的破坏性变更，进一步加强系统稳定性。
最后，培养透明度和持续改进的文化至关重要。从ABAP测试驾驶舱扫描和豁免审查中获得的见解应该与更广泛的开发团队分享。这种开放性建立了维护高质量、合规代码的共同责任感，并鼓励持续学习和完善。通过将治理深度集成到工具和文化中，组织可以确保其SAP环境保持稳定、可扩展，并为未来创新做好准备。
4.4 获得清洁：如何测量Clean Core的当前状态？
4.4.1 RISE with SAP方法论仪表板
RISE with SAP是来自SAP的综合之旅，将几个元素捆绑在一起，支持客户的数字化转型，用SAP Business Suite替换遗留系统。它以RISE with SAP方法论为基础，沿着个人云转型路径全面引导客户，降低复杂性并为各种规模的企业促进更平滑的过渡。它帮助本地客户在云中现代化其业务流程，基于Clean Core原则，以实现持续创新。
该方法论在一系列定义阶段中提供结构化指导和推荐步骤。它由SAP专家和合作伙伴支持，并通过工具和服务实施。该方法论基于Clean Core策略，所有服务和工具协同工作，在整个生命周期中支持客户。
RISE with SAP方法论遵循标准化框架，帮助公司更快地采用SAP Business Suite应用程序，并提供与其特定业务需求一致的定制转型路线图。它利用集成工具链进行简化协作和高效项目执行，确保整个过程中的内聚、高效工作流。该方法论通过端到端参与模型由SAP和合格合作伙伴的专家指导。
当客户踏上转型之旅时，他们需要提供当前状态可见性、关键项目进展以及指导下一步和策略的见解的工具。这就是SAP Cloud ALM中的RISE with SAP方法论仪表板变得必要的地方，帮助组织保持其ERP系统敏捷、创新，并为持续改进而优化，以释放SAP解决方案的全部价值。
RISE with SAP方法论仪表板对于采用Clean Core方法的企业发挥关键作用。通过专注于韧性流程和高效运营，组织可以实现无缝集成。采用标准流程增强了整体一致性，而创建独特扩展的能力促进了差异化。这种方法确保业务关键系统保持敏捷、成本效益，并为创新做好准备。
RISE with SAP方法论仪表板支持客户的转型之旅。拥有RISE with SAP合同的客户可以访问SAP Cloud ALM启动板上的RISE with SAP选项卡，从中可以打开系统视图仪表板。此仪表板提供系统Clean Core合规状态的清晰概述。
在系统视图中，客户可以验证安装在其系统上的当前SAP S/4HANA产品版本是否最新，并确保收集Clean Core相关数据所需的工具处于活动状态且按预期运行。最后，他们可以审查当前扩展，以评估和准备下次升级中的任何潜在问题。
以下是系统视图功能的高级摘要。系统视图及其各个部分在SAP帮助门户中有详细描述。
一般来说，RISE with SAP方法论仪表板中的系统视图包括以下选项卡：
软件堆栈
为您提供系统软件堆栈的概述，并提供为您的系统运行的最新SAP S/4HANA升级就绪检查的关键结果。
Clean Core工具状态
此部分显示收集Clean Core相关数据所需工具的状态。这里提到的每个工具都提供测量系统Clean Core合规性所必需的数据。
扩展性
此部分提供不同扩展性相关KPI的概述（另见“可测量性：扩展性KPI”章节）。系统视图中RISE with SAP方法论仪表板当前提供的KPI包括：
– ABAP Cloud开发设置
显示您是否遵循创建ABAP Cloud软件组件的建议。
– 未使用的客户对象（另见可测量性：KPI章节）
– 客户对象执行
显示可执行客户对象在您的系统中运行的频率，与系统中所有可执行对象（包括SAP、合作伙伴和客户对象）的总执行次数相比较
– ABAP Cloud：等级A客户对象
代表有限的Clean Core份额视图（另见可测量性：KPI章节），因为只考虑等级A对象
– ABAP经典：业务修改
属于不推荐扩展组，因为业务修改既不升级稳定也不云就绪
注意：
客户已经可以使用ABAP测试驾驶舱测量新扩展性概念中定义的等级。
然而，这些等级尚未在RISE with SAP方法论仪表板中可视化。计划在未来版本中进行完整的仪表板集成。
4.4.2 单独评估Clean Core KPI
虽然SAP通过RISE with SAP方法论仪表板提供了跟踪KPI的强大框架，但某些场景可能需要比标准仪表板中当前或未来版本可用的更细粒度的见解。一个常见需求是应用个别过滤和分析标准，最常见的是将包和命名空间映射到业务单位，允许不仅在系统级别而且跨组织边界分析Clean CoreKPI。
虽然第4.4.1章讨论了通过RISE with SAP方法论仪表板提供的标准方法，但也可以手动提取底层KPI数据，特别是对于第4.1.2章中描述的KPI。特别是，Clean Core份额和技术债务评分等指标可以通过利用基于其引用元素和ABAP测试驾驶舱检查结果对自定义代码对象进行分类的SAP工具来计算。
为了进一步定制并使技术债务评分与特定环境和治理流程保持一致，SAP推广开源自定义ABAP测试驾驶舱检查项目Kernseife。它支持集成SAP对象的自定义分类模型，以导出适合独特组织需求的技术债务评分。这种方法产生更可操作的见解，并增强了在减少技术债务方面优先干预的能力。
4.5 如何实现Clean Core
每个Clean Core之旅都是独特的。
本白皮书概述了一般策略和原则，但您自己的方法将由您的起点和未来几年设定的战略目标塑造。无论您是已经在SAP S/4HANA上严格的Clean Core规则下产品化运营、准备带有遗留扩展的系统转换，还是启动绿地实施，您的路径都会有所不同。
无论从哪里开始，Clean Core都是一种可以——且需要——根据特定需求定制的方法。一些组织可能已经接近其理想状态，而其他组织需要管理通过多年或数十年自定义开发积累的技术债务。无论您的出发点如何，两个关键目标是普遍有效的：
A) 保持清洁
对于所有新开发，您的目标应该是严格遵循Clean Core原则。这意味着通过确保每个扩展遵循明确指导原则来避免任何不必要的技术债务。如“保持清洁：如何创建清洁扩展“章节中强调的，这需要强大的治理、最新的指导原则，并通过持续培训和技能提升来启用您的开发团队。即使您的组织尚未使用SAP S/4HANA 2022或仍在运行SAP ECC，您也可以通过应用尽可能多的Clean Core模型开始。例如，基于SAP BTP构建的扩展已经可以实施。通过现在建立这些习惯，您为未来在当前SAP S/4HANA版本上向“清洁“ABAP Cloud扩展的过渡奠定了基础。
B) 获得清洁
接下来，专注于您现有的环境——或您正在构建的环境。首先使用RISE with SAP方法论仪表板或ABAP测试驾驶舱等工具测量技术债务。使用此基准推动您的长期减少策略：识别未使用或过时的代码，优先处理灯塔扩展（当您需要重新工作时用清洁技术重建这些），并设定现实但雄心勃勃的目标——如初始减少目标10%。记住，未检查的技术债务将继续增长，但持续的增量改进，如采用“童子军原则“（总是让代码比发现时更清洁），会随着时间的推移累积。
Clean Core是一个持续的旅程，不是一次性努力。进展不仅通过技术衡量，还通过流程、治理的成熟度，最重要的是——您的人员。根据您的业务优先级调整您的方法，始终平衡有针对性的改进与它们为业务增加的价值。
4.5.1 Clean Core之旅的关键步骤和建议
虽然每个Clean Core之旅会因目标、当前情况和系统历史而不同，但以下摘要像指南针一样指导您的旅程：
建立清晰的治理：定义清洁扩展指导原则，确保它们涵盖所有相关的SAP S/4HANA或SAP ECC开发。赋能您的治理：涉及业务和技术团队——都由高层管理的明确承诺支持。评估您的起点：清楚了解您当前的技术债务和Clean Core采用情况。使用工具测量并创造透明度。提升和赋能您的开发人员：定期培训您的团队Clean Core原则和新功能（如SAP Build中的ABAP Cloud）。为转换场景调整：如果您正在迁移，与SAP S/4HANA功能变更保持一致，并在可行的情况下减少范围或复杂性。设定增量、可实现的目标：制定雄心勃勃但现实的技术债务减少目标（例如，每年10%）。优先考虑业务价值：将修复工作重点放在具有切实业务影响的代码和定制上。持续监控和改进：将Clean Core测量和改进纳入常规开发周期和审查中。采用“童子军原则“：鼓励在每次变更时增量清理代码的文化。为未来做准备：利用当前机会（如SAP BTP扩展）并为随着环境演变的进一步Clean Core采用奠定基础。
通过一致地按照这些原则行动，您的组织可以限制技术债务，提升敏捷性，并构建准备好持续创新的韧性SAP环境
关于本文内容有任何问题或见解，欢迎在评论区留下你的想法，如果时间紧迫，也可以直接联系到我 arthuryang1996@foxmail.com，感谢你的时间
本文内容主要来自Clean core extensibility白皮书SAP发现企业在实施定制化拓展时往往遇到很多问题，包括但不限于：标准功能是否满足需求，有哪些拓展方式是可选的，不同方式可以达成什么样的效果，未来该如何维护这些拓展才能保证持续的创新能力等等。所以SAP推出了Clean Core方法论，为组织在拓展核心IT系统时提供指导意见，帮助组织打造一个清洁的核心。清洁核心方法论下又包含了五个维度的清洁，分别是业务流程/拓展/数据/集成/运营 维度的清洁性，本白皮书主要关注拓展层面的清洁核心原则 如果您对BTP感兴趣，BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容 白皮书内容较多，章节1，2的内容见Link，章节3的内容见Link本文包含了章节4的内容，主要介绍如何实现清洁的扩展，提供实用的、分步的治理、测量和实施清洁扩展的框架。涵盖工具、方法论（如SAP应用扩展方法论）和监控和执行Clean Core遵循的KPI。 4 如何实现扩展性的Clean Core？ 4.1 Clean Core测量框架Clean Core测量框架将成熟度评估与定量KPI相结合，推动持续改进：4.1.1 治理与成熟度—— 评估Clean Core的方法评估方法旨在批判性地评估和加强组织内的治理流程，使其与Clean Core最佳实践保持一致。它通过提供更深入、更注重实践的Clean Core治理视角来补充RISE with SAP方法论。虽然这种方法涵盖了所有五个洁净核心维度，但本白皮书重点关注可扩展性。为此，评估框架围绕12个关键方面构建：7个方面评估治理成熟度，5个方面评估底层系统的就绪程度。每个方面都代表了维护Clean Core所必需的独特治理领域。治理成熟度通过详细的评估标准进行衡量——按照从0（未开始）到5（专家级）的成熟度量表进行评分。这种评分使组织能够将其当前状态与目标成熟度水平进行基准对比。通过识别每个实践当前得分与期望得分之间的差距，企业可以精确定位需要改进的领域。由此产生的洞察有助于定义有针对性的行动，然后可以在结构化路线图中对这些行动进行优先排序和调度。这确保了改进动作既实用又可在规定时间内实现，推动向强大的Clean Core扩展性框架持续进步。 4.1.2 可测量性：扩展性KPI这些KPI用于衡量Clean Core原则的遵循情况。它们来源于从客户系统收集和分析的数据。此外，我们还将解释如何计算这些KPI，以及可以利用哪些工具让不同层级获得洞察。下表提供了可扩展性相关KPI的高层次概述 KPI描述行动价值Clean Core份额根据Clean Core等级概念对自开发拓展进行分类记录最需要改进的地方，例如，通过减少等级D对象的份额来提高评分可视化自定义代码分布；识别需要立即关注的领域；跟踪随时间的变化； 衡量进展 • 支持战略决策制定；确保长期可维护性技术债务评分对于开发对象的评分，评估相关技术债务。允许基于各种标准（如开发包）进行聚合识别技术债务负担高的对象清晰客观地衡量影响系统可维护性的因素；确定每个对象与理想A级拓展的距离未使用代码份额即未被使用的自定义对象占所有自定义对象的比例突出潜在可清理和优化的对象维护精益高效的系统架构业务修改程度系统中业务修改的数量识别业务修改的程度，这将导致升级的风险和工作量识别对更清洁扩展实践的需要在以下内容中，将为每个KPI解释目的、测量方法和相关数据源。 4.1.2.1 Clean Core份额 4.1.2.1.1 为什么测量Clean Core份额？该KPI提供自定义代码对象如何在不同Clean Core等级中分布的全面概述。它帮助识别可能需要立即关注的领域以及可以期待改进的地方，例如，减少等级D对象的比例。4.1.2.1.2 Clean Core份额的洞察是什么？ Clean Core份额根据Clean Core等级概念，基于其最差参考等级，对每个自定义代码对象进行分类。4.1.2.1.3 如何测量Clean Core份额？ Clean Core份额通过根据其最差/最低参考等级对每个对象进行分类来计算。例如，如果某自开发对象甲引用了内部对象，则被归类为等级C，而ABAP Cloud模式下的自开发对象被归类为等级A。份额计算为所有自开发对象在各等级的分布，例如，等级A：10%（100个自开发对象属于等级A），等级B：50%（500个自开发对象属于等级B），等级C：35%（350个对象），等级D：5%（50个对象）。4.1.2.2 技术债务评分4.1.2.2.1 为什么要测量技术债务评分？虽然Clean Core份额提供总体概览，但技术债务评分更具可操作性。它量化每个自定义代码对象中技术债务的程度，提供影响系统可维护性因素的清晰客观衡量。4.1.2.2.2 技术债务评分的见解是什么？ 技术债务评分按对象计算，可以按各种标准（如开发包）聚合。它通过衡量每个对象与理想Clean Core等级A的偏差，突出扩展中最大技术债务的位置。当与扩展对象的大小结合时，技术债务评分有助于确定债务的相对规模。4.1.2.2.3 如何测量技术债务评分？ 技术债务评分是基于对SAP对象引用严重性的加权评分。例如 ABAP测试驾驶舱 test cockpit中报错的权重因子分分布为：每个错误10分，每个警告5分，每个信息消息1分。评分是这些加权值的总和。示例：5个错误、20个警告和10个信息消息导致评分为5*10 + 20*5 + 10*1 = 160分。4.1.2.3 未使用代码份额 4.1.2.3.1 为什么测量未使用代码份额？每个自定义代码对象都代表潜在的技术债务。识别和移除未使用的代码对象对于维护清洁高效的系统至关重要。4.1.2.3.2 未使用代码份额的见解是什么？ 自定义对象是SAP标准之外的客户创建扩展。Clean Core的一个关键目标是最小化未使用自定义对象的数量。未使用代码份额测量未被使用的自定义对象比例，突出潜在清理和优化领域。4.1.2.3.3 如何测量未使用代码份额？ 测量未使用代码份额需要激活使用数据测量。推荐使用ABAP调用监控器（SCMON）收集此数据，以及事务SUSG用于随时间聚合使用数据。基于系统中自定义对象的总数，可以确定未使用对象的份额。例如，如果1,000个自定义对象中有300个未被使用，则未使用代码份额为30%。4.1.2.4 业务修改（在RISE with SAP方法论仪表板中可用） 4.1.2.4.1 为什么测量业务修改数量？ 修改涉及对扩展点之外的SAP标准代码的更改。因此，它们通常构成升级风险并可能导致额外的维护工作。4.1.2.4.2 业务修改数量的见解是什么？ 业务修改是经典扩展性的子集，记录在SMODILOG表中。它们解决SAP标准中的功能差距，但不符合Clean Core原则且不升级稳定。测量此KPI有助于识别此类修改的程度，突出对更清洁扩展实践的需要。4.1.2.4.3 如何测量业务修改数量？修改分析解释了如何使用模式从SAP表SMODILOG提取数据，以识别非有意创建为业务修改的技术修改。结果可以在自定义代码分析仪表板或RISE with SAP方法论仪表板中查看（参见第4.4.1章的示例）。4.2 通过”保持清洁”和”获得清洁”达到Clean Core在SAP扩展性中实现Clean Core需要一个结构化的、持续的治理过程，引导每个扩展朝着最小化技术债务同时最大化业务价值的方向发展。两个互补的模式指导如何实施这种方法：保持清洁和获得清洁。保持清洁专注于防止每个新扩展积累不必要的复杂性。它首先严格评估功能需求。任何提议的扩展必须有清晰的业务案例，不能通过标准SAP功能解决，并应与流程差异化策略保持一致（反映Clean Core流程原则）。接下来，扩展架构步骤确保通过治理化、结构化的框架（如SAP应用扩展方法论）选择最佳适配的架构方法，并具有透明度和可重复性的适当文档。在扩展实施期间，开发人员接受集中支持和控制——如授权检查和自动化质量工具（如ABAP测试驾驶舱）——以确保他们遵循架构标准，同时对任何偏差进行彻底文档记录和治理。最后，扩展部署通过强制只有合规和质量检查的代码进入生产，与运营Clean Core原则相结合。自动化代码验证和严格控制的豁免流程保证与整体治理的一致性。获得清洁通过解决现有技术债务来补充这种预防性方法。它涉及测量相关KPI以精确定位改进领域，采用”童子军原则”，鼓励开发人员在任何修改期间使代码比发现时更清洁（纳入项目估算），并为遗留代码库中的技术债务减少设定现实但雄心勃勃的目标。这些模式共同建立了一个整体、迭代的治理框架，维护扩展性的Clean Core基础，平衡创新速度与长期系统可维护性。以下章节将探讨基于这种方法实现Clean Core所涉及的步骤。 4.3 保持清洁：如何创建清洁扩展4.3.1 功能需求功能需求是标准SAP解决方案未满足的业务需要。它们通常在适配标准研讨会期间识别，并在SAP Cloud ALM中管理，后者将它们直接链接到业务流程。虽然功能需求很常见，但数据隐私、安全性和可扩展性等非功能方面也是扩展设计的关键驱动因素。4.3.1.1 需求收集 适配标准研讨会的关键目标之一是确保在适当的业务环境中收集需求。SAP Cloud ALM（RISE with SAP方法论的组成部分）通过提供允许用户以最简单的格式在正确业务环境中创建需求的功能来简化需求收集过程。识别需求和定义扩展与Clean Core”流程”原则密切相关。需求不仅可以在流程层面创建和链接，还可以在几乎每个包含的图表元素上创建和链接，无论流程是SAP标准流程还是客户流程。有关基于行业标准构建韧性业务流程和评估差异化扩展需要的更多指导，请参考SAP S/4HANA CloudClean Core业务流程白皮书。该资源还更详细地涵盖了适配标准方法。需求可以分解为更小的用户故事，但业务用户的初始关注点只是陈述需要；专家顾问稍后确定最佳解决方案，无论是通过配置还是扩展。当功能差距需要扩展时，必须以Clean Core合规的方式开发。这意味着扩展必须与SAP S/4HANA Cloud代码解耦，以确保它不会破坏升级（例如由于数据损坏或系统故障），并且升级不会破坏扩展。Clean Core扩展性模型旨在实现这种分离，允许客户从SAP接收持续创新而不受干扰。至关重要的是，扩展必须提供切实的业务价值。即使技术上合理，如果扩展不能解决差异化业务需要或相同功能可以通过SAP标准功能或认证合作伙伴解决方案实现，则被视为”不清洁”。因此，每个潜在扩展必须经过明确定义的治理过程。4.3.1.2 治理：建立并遵循Clean Core指导原则 强大的治理框架对于维护Clean Core至关重要。主要目标是尽可能接近SAP标准，确保任何偏差提供清晰的增值差异化。这涉及建立优先级和分段的业务流程层次结构，将业务流程分类为标准、差异化（增强和自定义开发）和创新层，以优化资源分配并将开发重点放在高影响领域。图9展示了当前和目标流程类别分布之间的示例比较，强调标准和创新流程的增加。一旦业务流程符合Clean Core要求，就更容易确定需要偏离标准的地方。清晰的治理过程确保在SAP S/4HANA扩展性模型中利用最佳可用选项。如前所述，重要的是最小化扩展的使用以降低ERP系统的复杂性和维护开销。根据这一目标，扩展的批准应该由明确定义的治理结构管理。组织必须为评估和证明扩展设定高标准。每个扩展的理由必须清楚记录，以及它提供的预期业务价值。图10概述了在SAP系统内评估和实施新业务需求或差距的结构化决策过程，支持制造或购买决策。 如果用例不能被标准解决方案覆盖且足够有益以证明创建自定义扩展的合理性，流程将继续进行扩展架构方法以进行实施 根据功能需求定义和文档期间概述的设计，将应用SAP应用扩展方法论（参见下一章）来定义扩展架构。通过建立中央权威机构或团队（如解决方案标准化委员会）来监督SAP ERP中业务流程的设计和实施，验证扩展的必要性并确保首先考虑SAP标准选项，可以实现对待开发流程、业务需求和设计批准的集中治理。这使组织能够：在满足业务需求的同时使所有流程与最佳实践保持一致根据个人需要强制执行”清洁”开发要求对选定的扩展域进行清晰文档记录和证明确保所有偏差以标准化和一致的方式得到批准4.3.1.3 使用SAP Cloud ALM支持Clean Core治理SAP Cloud ALM对于建立Clean Core至关重要。通过利用SAP Cloud ALM，组织可以采用SAP的最佳实践内容，管理适配标准研讨会，并简化其需求管理流程。这有助于限制定制，降低复杂性并维护核心系统的完整性。集成的分析和可追溯性功能提供Clean Core合规性的清晰视图，使企业能够有效跟踪和管理其项目。为了根据既定的Clean Core治理对SAP Cloud ALM实体进行分类，可以为流程、需求、用户故事和功能创建标签（例如”清洁”和”不清洁”）。这些标签可以应用在SAP Cloud ALM的解决方案流程可追溯性分析页面上。它们允许评估计划或实施的解决方案流程以及分配的需求、用户故事和功能是否被分类为”清洁”或”不清洁”。从此视图，用户还可以导航到相关的可追溯性和概述页面（例如需求可追溯性）以检查更多详细信息。 4.3.2 扩展架构SAP应用扩展方法论为客户和合作伙伴定义组织特定扩展策略提供结构化、技术无关的方法。 遵循此方法论确保所有项目利益相关者使用相同术语，并快速达成对业务用例和未来解决方案的共同理解。它提供可用技术扩展构建块的概述，实现对未来扩展架构的明智决策。它还支持创建扩展框架，以指导组织内的架构师和开发人员。阶段1专注于基于定义区域内的业务环境和需求定义扩展用例。它涉及理解系统环境并相应记录扩展应用程序用例。阶段2引入关键概念，如扩展样式、扩展任务和扩展域。它提供称为技术扩展构建块的各种扩展技术概述。结合扩展任务，它们帮助将业务需求转化为技术需求。阶段3基于整体需求以及前一阶段扩展任务和构建块之间的技术映射，支持对目标解决方案使用哪些技术扩展构建块的明智决策。各种决策指导资产——如扩展架构指南、SAP Discovery Center和SAP架构中心——在塑造和完善目标解决方案方面提供进一步支持。为了进行彻底分析，组织应该使用扩展任务指导模板和扩展任务技术映射模板，在选择技术扩展构建块之前记录自定义指导。此过程支持开发清晰的设计指导，以确保考虑最佳Clean Core等级。SAP应用扩展方法论模板还协助设定排序和评估标准，以选择最合适的技术构建块。开发人员可能偏好熟悉的工具而非最优解决方案，特别是当他们不熟悉ABAP Cloud或SAP BTP功能时。这种结构化方法有助于指导架构决策。完成方法论后，产生几个交付成果：应用程序扩展用例描述（来自阶段1）、技术扩展构建块决策（来自阶段3）和扩展目标解决方案（来自阶段3）。这些交付成果可用作SAP Cloud ALM用户故事的输入。有关SAP应用扩展方法论的更多信息和访问模板，请访问SAP帮助门户。 4.3.3 扩展实施建立Clean Core思维良好的开发实践涉及编写不仅解决即时需求，还考虑大局的代码：清洁架构、系统稳定性、长期可维护性以及与组织未来策略的一致性。一个实际例子：基于ABAP列表查看器网格创建报告在系统升级期间可能不会造成问题，但当组织计划迁移到SAP S/4HANA公有云时，它就成为技术债务。代码不仅仅是技术性的——它是战略性的。然而，采用Clean Core思维超越了编写代码。它还涉及花时间考虑重用，退后一步专注于技能提升，并重新评估开发方法而不是匆忙实施。Clean Core思维塑造了扩展的规划和执行方式。开发指导原则为了将Clean Core思维转化为日常实践，建立清晰的开发指导原则很重要。这些指导原则有助于确保一致的实践，无论是关于使用正确的API、避免某些增强还是遵循命名约定和编码标准。当规则清晰时，开发人员可以专注于构建高质量、面向未来的解决方案，而无需猜测允许或期望的内容。明确定义和记录的标准也使新开发人员更容易入职，并在不同项目中保持团队一致。这些指导原则应该易于访问、定期更新，并通过自动化代码检查和同行评审等工具得到加强。有了这样的结构，团队将有坚实的基础。虽然这些指导原则可能总是个性化的，但在开发指导原则方面有很好的起点可以考虑和参考：”在云端和本地使用基于ABAP的扩展扩展SAP S/4HANA”指南清洁ABAP指南和备忘单ABAP备忘单 技能发展在建立开发规则后，重要的是根据员工的角色和技能启用workforce：开发人员需要学习如何为SAP S/4HANA构建现代业务应用程序，并从经典ABAP开发人员发展为ABAP Cloud开发人员。SAP Learning提供几个免费学习路径，如：获得核心ABAP技能管理SAP S/4HANA Cloud的Clean Core实践S/4HANA Cloud的Clean Core扩展性 这些路径有助于准备获得SAP认证助理——后端开发人员——ABAP Cloud认证。此外，首席开发人员和解决方案架构师应该扩展其知识以保持扩展开发的全面视图。这可以通过成为SAP BTP解决方案架构师的学习路径实现，该路径也提供认证。这个启用过程需要时间和管理承诺。为相关主题建立一个或多个卓越中心可以支持推广并有助于推动整个组织的Clean Core采用。开发清洁扩展在实施开始时，识别与SAP标准的所有接触点至关重要，如用户界面（应用程序、表单、报告）、集成（集成流、事件）、业务逻辑（业务附加组件）、API（CDS视图、业务对象接口、BAPI）以及持久性（表）。这种方法有助于澄清与SAP标准和核心的所有潜在依赖关系，并显示扩展的耦合程度。有了这些信息，应该使用自顶向下的方法规划开发，从Clean Core等级A到Clean Core等级D，从紧密耦合过渡到松散或完全解耦的扩展。对于紧密耦合的扩展，起点是SAP S/4HANA关键用户扩展性选项（等级A）和搜索合适的发布扩展点。发布的扩展点可能是，例如，业务环境中的字段扩展或业务逻辑扩展。识别这些发布扩展点的方法可能因特定SAP ERP部署模型（SAP S/4HANA公有云、SAP S/4HANA私有云或SAP S/4HANA）和版本而异。在较旧的SAP S/4HANA版本上，可能需要直接在目标应用程序的文档中检查扩展性选项。可以通过在SAP Fiori应用程序参考库中搜索相应系统版本的应用程序、导航到实施信息选项卡并找到扩展性部分来访问。那里链接的应用程序扩展性文档提供有关扩展性选项的详细信息，如用于此应用程序的业务上下文。对于其他对象，可以使用事务SCFD_REGISTRY查找系统中注册的每个扩展点。当需求过于复杂而无法通过关键用户扩展性实现时，需要使用开发人员扩展性（等级A）的扩展。在”体外Side by Side”或混合扩展域中，流程通常从探索SAP Business Accelerator Hub上的远程公共API开始，如OData服务、REST服务或可以从核心系统公开的事件。SAP Business Accelerator Hub为使用这些API提供全面资源，包括业务文档和扩展选项详细信息。对于”体内On Stack”扩展，可以使用Eclipse的ABAP开发工具通过基于API状态过滤对象来识别发布的公共API，如CDS视图、业务对象接口或业务附加组件。注意：必须查看每个API的引用业务文档，因为某些API可能不合适——例如，如果业务功能未实现。如果适用，检查是否存在前身经典API。当已知经典ABAP对象时，用户可以通过检查API状态属性或咨询云化存储库来识别后续对象。云化存储库还提供对发布API未来的一瞥。通过选择所需的系统版本，可以检查API是否将在即将发布的版本中变得可用。如果不存在发布的本地公共API，下一步是在云化存储库中探索经典API（等级B）。要识别合适的扩展技术或框架，请参考SAP注释3578329，它将遗留技术分类为Clean Core等级并提供推荐使用的清晰指导。当超出等级A的边界时，开发人员应该在应用程序开发期间实施额外的保护措施。由于内部对象可能不稳定，监控SAP对象变更日志以接收有关不兼容变更的早期警告并在使用此类对象时格外小心是至关重要的。为了验证预期行为，应该创建单元测试并在每次系统升级后运行，特别是使用内部或不推荐对象时。SAP强烈建议在等级A（ABAP Cloud）内最大化开发，以减少对等级B到D对象的依赖。一个有效策略是在包装器内封装经典API、内部对象或不推荐对象，然后可以使用API合同为ABAP Cloud公开。详细信息可在ABAP Cloud API启用指导原则中找到。 4.3.4 扩展部署 一旦扩展按照Clean Core方法设计和实施，下一个关键步骤是通过结构化治理和技术控制来强制执行这些原则。即使是最严格的开发策略也可能被单个未审查的传输或管理不当的豁免所破坏。为了确保长期可持续性、代码质量和系统稳定性，必须将自动化执行和问责机制直接嵌入到开发和部署流程中。 图14显示了不同的Clean Core治理选项，在以下段落中解释。 在非ABAP环境中，使用静态代码分析工具（例如，CAP的CDS Lint）来确保代码遵循定义的编码规则。SAP S/4HANA系统内运营Clean Core治理的核心依赖于使用ABAP测试驾驶舱的自动化检查。这些检查应该紧密集成到传输释放流程中。SAP提供预交付的ABAP测试驾驶舱变体，作为强制执行Clean Core规则的可靠基准。鼓励组织定制这些变体以与其内部政策保持一致。将这些变体纳入传输释放流程确保每当开发人员释放传输时检查自动运行。当识别出高优先级问题（通常是优先级1或2）时，应该阻止传输，直到违规得到解决或通过定义的治理流程明确豁免。要为经典ABAP开发模型设置治理，请参考ABAP扩展性指南。然而，没有结构化的豁免流程，任何执行策略都是不完整的。虽然Clean Core政策应该严格应用，但可能出现合法的例外情况。这些必须被有意识地承认和治理，以防止开发标准的逐渐退化。应该建立正式的豁免程序，由指定的质量经理（理想情况下是高级开发人员或架构师）负责审查并批准或拒绝请求。每个豁免请求必须包括清晰的理由、对正在放弃的具体发现的引用以及涉及的开发对象列表。所有决策必须记录在ABAP测试驾驶舱内，以确保完全可追溯性和问责制。应该为每个豁免定义时间限制，并且应该避免在对象或包级别的广泛或通用豁免。现有豁免的定期审查，通常涵盖10-20%的案例，有助于验证持续相关性并支持开发指导原则的持续完善。 为了在结构上强制执行Clean Core开发，最有效的措施之一是将ABAP语言版本限制为ABAP Cloud。这种限制可以通过分配S_ABAPLNVS授权对象和/或创建仅支持ABAP Cloud的专用软件组件来实现。建立这样的组件引入了清晰的架构边界，并允许开发人员角色的分离。标准ABAP Cloud开发人员可以与具有提升权限的受信任开发人员区分开来，使管理谁被允许使用遗留或无限制对象变得更容易。这种分离增强了透明度，简化了维护，并降低了引入不合规代码的风险。除了管理语言版本限制外，组织应该激活监控API使用和增强技术的ABAP测试驾驶舱检查。这些检查在SAP注释3565942中提供，通过基于稳定性和升级安全性对API和技术进行分类来引入Clean Core等级。有关设置详细信息，请参考ABAP扩展性指南中的”为经典ABAP开发模型设置治理”章节。当使用等级B、C或D对象时，开发人员本质上使用标准ABAP语言版本，这是包括ABAP Cloud和关键用户ABAP的超集。虽然使用ABAP Cloud就绪检查变体是可选的，但强烈推荐。激活此变体有助于减少对标准ABAP语句的不必要依赖，并促进等级A中云就绪和升级稳定代码的开发。为了支持等级A对象的采用并进一步增加其份额，组织应该为非发布SAP对象创建封装包装器。这些包装器然后可以发布供ABAP Cloud使用，有效地弥合不合规遗留代码和现代合规开发实践之间的差距。自动化ABAP单元测试在维护代码稳定性方面发挥重要作用，特别是在处理经典API（等级B）、不确定稳定性的对象（等级C）或缺乏正式API的开发（等级D）时。虽然结构性变更（例如，重命名字段）通常可以在编译时检测到，但行为变更，如改变的逻辑或计算，通常不会被注意到。ABAP单元测试充当此类回归的保护措施，确保即使底层实现发生演变，预期的代码行为也得到维护。SAP在SAP对象变更日志中持续发布经典API和内部对象的更新。通过定期审查此变更日志，开发团队可以主动识别潜在的破坏性变更，进一步加强系统稳定性。最后，培养透明度和持续改进的文化至关重要。从ABAP测试驾驶舱扫描和豁免审查中获得的见解应该与更广泛的开发团队分享。这种开放性建立了维护高质量、合规代码的共同责任感，并鼓励持续学习和完善。通过将治理深度集成到工具和文化中，组织可以确保其SAP环境保持稳定、可扩展，并为未来创新做好准备。 4.4 获得清洁：如何测量Clean Core的当前状态？ 4.4.1 RISE with SAP方法论仪表板RISE with SAP是来自SAP的综合之旅，将几个元素捆绑在一起，支持客户的数字化转型，用SAP Business Suite替换遗留系统。它以RISE with SAP方法论为基础，沿着个人云转型路径全面引导客户，降低复杂性并为各种规模的企业促进更平滑的过渡。它帮助本地客户在云中现代化其业务流程，基于Clean Core原则，以实现持续创新。该方法论在一系列定义阶段中提供结构化指导和推荐步骤。它由SAP专家和合作伙伴支持，并通过工具和服务实施。该方法论基于Clean Core策略，所有服务和工具协同工作，在整个生命周期中支持客户。RISE with SAP方法论遵循标准化框架，帮助公司更快地采用SAP Business Suite应用程序，并提供与其特定业务需求一致的定制转型路线图。它利用集成工具链进行简化协作和高效项目执行，确保整个过程中的内聚、高效工作流。该方法论通过端到端参与模型由SAP和合格合作伙伴的专家指导。当客户踏上转型之旅时，他们需要提供当前状态可见性、关键项目进展以及指导下一步和策略的见解的工具。这就是SAP Cloud ALM中的RISE with SAP方法论仪表板变得必要的地方，帮助组织保持其ERP系统敏捷、创新，并为持续改进而优化，以释放SAP解决方案的全部价值。RISE with SAP方法论仪表板对于采用Clean Core方法的企业发挥关键作用。通过专注于韧性流程和高效运营，组织可以实现无缝集成。采用标准流程增强了整体一致性，而创建独特扩展的能力促进了差异化。这种方法确保业务关键系统保持敏捷、成本效益，并为创新做好准备。RISE with SAP方法论仪表板支持客户的转型之旅。拥有RISE with SAP合同的客户可以访问SAP Cloud ALM启动板上的RISE with SAP选项卡，从中可以打开系统视图仪表板。此仪表板提供系统Clean Core合规状态的清晰概述。在系统视图中，客户可以验证安装在其系统上的当前SAP S/4HANA产品版本是否最新，并确保收集Clean Core相关数据所需的工具处于活动状态且按预期运行。最后，他们可以审查当前扩展，以评估和准备下次升级中的任何潜在问题。以下是系统视图功能的高级摘要。系统视图及其各个部分在SAP帮助门户中有详细描述。 一般来说，RISE with SAP方法论仪表板中的系统视图包括以下选项卡：软件堆栈为您提供系统软件堆栈的概述，并提供为您的系统运行的最新SAP S/4HANA升级就绪检查的关键结果。Clean Core工具状态此部分显示收集Clean Core相关数据所需工具的状态。这里提到的每个工具都提供测量系统Clean Core合规性所必需的数据。扩展性此部分提供不同扩展性相关KPI的概述（另见”可测量性：扩展性KPI”章节）。系统视图中RISE with SAP方法论仪表板当前提供的KPI包括：– ABAP Cloud开发设置显示您是否遵循创建ABAP Cloud软件组件的建议。– 未使用的客户对象（另见可测量性：KPI章节）– 客户对象执行显示可执行客户对象在您的系统中运行的频率，与系统中所有可执行对象（包括SAP、合作伙伴和客户对象）的总执行次数相比较– ABAP Cloud：等级A客户对象代表有限的Clean Core份额视图（另见可测量性：KPI章节），因为只考虑等级A对象– ABAP经典：业务修改属于不推荐扩展组，因为业务修改既不升级稳定也不云就绪注意：客户已经可以使用ABAP测试驾驶舱测量新扩展性概念中定义的等级。然而，这些等级尚未在RISE with SAP方法论仪表板中可视化。计划在未来版本中进行完整的仪表板集成。 4.4.2 单独评估Clean Core KPI虽然SAP通过RISE with SAP方法论仪表板提供了跟踪KPI的强大框架，但某些场景可能需要比标准仪表板中当前或未来版本可用的更细粒度的见解。一个常见需求是应用个别过滤和分析标准，最常见的是将包和命名空间映射到业务单位，允许不仅在系统级别而且跨组织边界分析Clean CoreKPI。虽然第4.4.1章讨论了通过RISE with SAP方法论仪表板提供的标准方法，但也可以手动提取底层KPI数据，特别是对于第4.1.2章中描述的KPI。特别是，Clean Core份额和技术债务评分等指标可以通过利用基于其引用元素和ABAP测试驾驶舱检查结果对自定义代码对象进行分类的SAP工具来计算。为了进一步定制并使技术债务评分与特定环境和治理流程保持一致，SAP推广开源自定义ABAP测试驾驶舱检查项目Kernseife。它支持集成SAP对象的自定义分类模型，以导出适合独特组织需求的技术债务评分。这种方法产生更可操作的见解，并增强了在减少技术债务方面优先干预的能力。4.5 如何实现Clean Core 每个Clean Core之旅都是独特的。本白皮书概述了一般策略和原则，但您自己的方法将由您的起点和未来几年设定的战略目标塑造。无论您是已经在SAP S/4HANA上严格的Clean Core规则下产品化运营、准备带有遗留扩展的系统转换，还是启动绿地实施，您的路径都会有所不同。无论从哪里开始，Clean Core都是一种可以——且需要——根据特定需求定制的方法。一些组织可能已经接近其理想状态，而其他组织需要管理通过多年或数十年自定义开发积累的技术债务。无论您的出发点如何，两个关键目标是普遍有效的：A) 保持清洁对于所有新开发，您的目标应该是严格遵循Clean Core原则。这意味着通过确保每个扩展遵循明确指导原则来避免任何不必要的技术债务。如”保持清洁：如何创建清洁扩展”章节中强调的，这需要强大的治理、最新的指导原则，并通过持续培训和技能提升来启用您的开发团队。即使您的组织尚未使用SAP S/4HANA 2022或仍在运行SAP ECC，您也可以通过应用尽可能多的Clean Core模型开始。例如，基于SAP BTP构建的扩展已经可以实施。通过现在建立这些习惯，您为未来在当前SAP S/4HANA版本上向”清洁”ABAP Cloud扩展的过渡奠定了基础。B) 获得清洁接下来，专注于您现有的环境——或您正在构建的环境。首先使用RISE with SAP方法论仪表板或ABAP测试驾驶舱等工具测量技术债务。使用此基准推动您的长期减少策略：识别未使用或过时的代码，优先处理灯塔扩展（当您需要重新工作时用清洁技术重建这些），并设定现实但雄心勃勃的目标——如初始减少目标10%。记住，未检查的技术债务将继续增长，但持续的增量改进，如采用”童子军原则”（总是让代码比发现时更清洁），会随着时间的推移累积。Clean Core是一个持续的旅程，不是一次性努力。进展不仅通过技术衡量，还通过流程、治理的成熟度，最重要的是——您的人员。根据您的业务优先级调整您的方法，始终平衡有针对性的改进与它们为业务增加的价值。 4.5.1 Clean Core之旅的关键步骤和建议虽然每个Clean Core之旅会因目标、当前情况和系统历史而不同，但以下摘要像指南针一样指导您的旅程：建立清晰的治理：定义清洁扩展指导原则，确保它们涵盖所有相关的SAP S/4HANA或SAP ECC开发。赋能您的治理：涉及业务和技术团队——都由高层管理的明确承诺支持。评估您的起点：清楚了解您当前的技术债务和Clean Core采用情况。使用工具测量并创造透明度。提升和赋能您的开发人员：定期培训您的团队Clean Core原则和新功能（如SAP Build中的ABAP Cloud）。为转换场景调整：如果您正在迁移，与SAP S/4HANA功能变更保持一致，并在可行的情况下减少范围或复杂性。设定增量、可实现的目标：制定雄心勃勃但现实的技术债务减少目标（例如，每年10%）。优先考虑业务价值：将修复工作重点放在具有切实业务影响的代码和定制上。持续监控和改进：将Clean Core测量和改进纳入常规开发周期和审查中。采用”童子军原则”：鼓励在每次变更时增量清理代码的文化。为未来做准备：利用当前机会（如SAP BTP扩展）并为随着环境演变的进一步Clean Core采用奠定基础。通过一致地按照这些原则行动，您的组织可以限制技术债务，提升敏捷性，并构建准备好持续创新的韧性SAP环境 关于本文内容有任何问题或见解，欢迎在评论区留下你的想法，如果时间紧迫，也可以直接联系到我 arthuryang1996@foxmail.com，感谢你的时间 Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
