在这里阅读我们的更新计划。

意图性解决方案会随着时间的推移立即提供业务价值。意图架构以战略性的方式规划和交付，可以有效维护，并且易于人类阅读和理解。

功能和修复的优先级以对业务和技术利益相关者透明的方式提供。工程选择创建易于交付和维护团队使用的实施，无需添加功能或复杂化。意图性架构更容易拥有、维护和随业务发展，因为它们遵循明确一致的实施模式。生成器可以解释和实施新功能的设计，维护团队可以理解实施内容的文档。

您可以通过关注三个关键领域来创建更具针对性的系统：策略、可维护性和可读性。

架构中的策略意味着系统经过深思熟虑的规划和交付。这意味着交付和维护团队清楚地了解今天和将来要完成的工作，每个人都围绕要完成的工作的“原因”保持一致。这意味着紧急请求可以有效分类，利益相关者可以清楚地了解请求的影响和权衡。

通过关注预先测试、路线图和治理，您可以将更清晰的策略构建到您的架构中。

优先级意味着计划您将交付的工作的顺序和范围。优先级包括了解交付品对业务的真正影响，根据其他工作请求和产品或计划的整体路线图评估这些影响。

评估给定工作项目影响的一种方式是查看业务的实际成本或收益。在您确定了自动化的 KPI 后，您可以使用业务影响计算工作表来评估实施的总体成本或收益。这些计算可以帮助您从利益相关者那里获得关于构建什么自动化以及以什么顺序构建的一致和支持。它们还可以帮助您确定要推迟或避免的自动化。有关识别有效工作的更多信息，请查看流程设计。

为交付建立优先级框架也有助于您和您的维护团队管理用户期望，并与路线图保持一致。

可用于确定优先级的一些注意事项包括：

• 交付品的业务影响（成本/效益）
• 交付品所需的新工作量
• 维护交付件所需的工作量

以下模式和反模式列表显示了 Salesforce 工作时正确(和糟糕)的优先级。您可以使用这些来验证您的实施计划，或者在构建之前确定您需要更好地确定优先级的地方。

要了解有关 Salesforce 工具的更多信息，以帮助确定优先级，请参见工具相关意图。

路线图是确定优先级、经过验证、定义明确的待办事项视图。有效的路线图清楚地描述了未来工作的业务影响和技术影响。让业务和技术利益相关者参与进来是路线图的关键部分。路线图使您能够在任何工作开始前获得关于方法和结果的反馈和支持。归根结底，路线图让每个利益相关者了解未来工作的“原因”。

如果您的团队使用待办事项，重要的是要了解您的路线图不是待办事项中的汇总或项目列表。关系相反：只有当项目能够明确和可靠地与路线图上的交付品联系起来时，它们才会进入待办事项。通过利益相关者的参与创建的高质量路线图，使交付和维护团队能够清楚地看到他们应该关注什么以及如何确定请求的优先级，从而更容易理清冲突的请求和管理利益相关者的期望。

不良或不存在路线图会导致：

• 不清楚新特性和功能何时可用
• 利益相关者之间的优先事项冲突
• 交付的解决方案与整体组织愿景脱节
• 难以理解正在进行的工作
• 团队之间的工作负荷不均衡
• 对工作项目之间的关系和依赖性缺乏可见性
• 由于依赖关系管理不善，实施暂停

利益相关者通常需要与其角色相符的信息来做出决策。创建有效的路线图需要清楚地了解您的受众以及他们需要的信息类型。路线图分为两种风格，以支持业务和技术受众。每个样式包含两个级别的粒度，以支持不同类型的信息。

业务路线图帮助利益相关者规划组织变革，利用增长机会，并与公司目标保持一致。业务路线图还提供了一种方式来确保 IT 支出与整体业务愿景保持一致。

• 创建业务能力路线图，向主管利益相关者展示将启用的功能。这种类型的路线图包含有关功能本身以及如何与业务目标保持一致的高级详细信息，例如提高运营效率或推出新产品线。
• 创建业务功能路线图，以深入了解特定功能，并在您需要帮助业务利益相关者进行资源规划、预算编制和变更管理时显示支持特性和功能。

技术路线图帮助技术利益相关者进行预算和资源分配规划。它们还帮助实施团队了解他们的项目适合作为更大整体的一部分的位置，并确定任何跨团队的依赖关系。

• 创建技术系统路线图，以显示将实施的特定系统，以及任何系统级依赖性。这种类型的路线图显示了高级系统信息，以及系统和业务功能之间的协调。
• 创建技术组件路线图，深入了解将部署以帮助满足资源规划和支持要求的系统的特定组件。这种类型的路线图显示了组件级信息和实施要求（例如，声明性开发、专业代码等）。

请确保路线图包含现实的时间表。一个常见的错误是只包括实施系统所需的时间，而不考虑完成相关活动所需的时间。这会导致过度分配实施团队成员，并比预期的延迟更长。在创建路线图时，请考虑完成以下内容所需的时间：

• 所有新功能和更新功能的文档
• 维护支持新功能所需的现有功能
• 支持集成所需的相关系统的更新
• 上线后项目团队的支持率提高
• 测试、培训和变更管理

高度一致的业务和技术路线图传达了功能何时上线以及落后技术的整体视图。下面的模式和反模式列表显示了 Salesforce 组织的正确(和糟糕)路线图。您可以使用这些来验证或改进您的路线图策略。

要了解有关可以帮助您绘制路线图的 Salesforce 工具的更多信息，请参见工具相关意图。

治理是您用来与利益相关者一起处理优先级、决策和变更管理的结构。治理明确了如何做出和传达决策。它为反馈和请求进入决策过程以及所有利益相关者了解维护和开发工作的状态提供了一致的方式。治理有助于发布清晰一致的管理流程，并帮助所有团队成员了解他们的角色和职责。

如果没有适当的治理，团队会遇到各种问题，包括：

• 对重叠特性和功能的请求是临时的
• 实施团队优先考虑“更容易”的努力或来自更具影响力的利益相关者的请求，而没有适当考虑业务价值、权衡或整体组织目标
• 缺乏一致的审批和审查流程
• 发布节奏和质量不一致
• 开发工作中的高缺陷率、覆盖、冲突和冗余工作

也许系统没有有效治理的最明显的迹象是发布缓慢和繁琐。认识到治理体系的规模不是衡量其有效性的标准非常重要。事实上，精心设计的治理系统（就像许多大型企业的系统一样）可以限制发布的速度和频率。

良好的治理是让糟糕的自定义很难通过早期开发阶段，让好的自定义可以预测和一致地投入生产。

治理工作往往具有反作用。当问题（例如过多的技术债务）开始成为业务问题时，就会启动或加倍它们。在许多情况下,不幸的回应是企业“锁定”开发工作和版本，而不是创建有效的设计标准和构建自动化来在开发人员工具链和源控制系统中强制执行这些标准。

在构建 Salesforce 治理系统的框架时，请包含以下元素，并考虑这些需要回答的关键问题：

• **工作请求。**用户如何询问功能或特性？如何报告错误？
• **优先级和工作规划。**谁决定什么工作请求重要？如何确定工作范围、确定优先级、接受或签署？
• **环境和发布计划。**开发、测试和发布的环境漏斗是什么？谁负责配置、刷新和提供访问权限？谁负责部署和验证？如何及何时发布更改？如何在 Salesforce 发布周期内处理部署或环境？（有关更多信息，请查看应用程序生命周期管理。）
• **服务所有权和生产支持。**谁支持什么？谁处理“热修复”生产问题？如何测试和发布这些项目？谁负责组织的整体安全标准？

以下模式和反模式列表显示了 Salesforce 组织的正确(和糟糕)治理。您可以使用这些来验证或改进您的治理策略。

要了解有关适用于治理的 Salesforce 工具的更多信息，请参见工具相关意图。

下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。

✨ 在模式和反模式探索器中，发现更多策略模式。

可维护性意味着系统可以保持健康状态，新功能进入系统，技术债务定期、可预测地移出系统。可维护的系统使您的团队能够以可预测的速度和质量为业务提供价值。系统的可维护性取决于几个因素，包括可读性、松耦合性以及测试策略的彻底性。

最重要的是，系统的可维护性取决于其设计的简单性。本节介绍如何创建更直接的解决方案设计，并提高可维护性。

您可以通过关注两个关键来构建更容易维护的解决方案：使用标准功能而不是自定义功能，以及处理技术债务。

Salesforce 提供一系列预构建的解决方案 — Sales Cloud、Service Cloud 和许多 Salesforce 行业解决方案，以及创建您自己的自定义解决方案的灵活性。支持 Salesforce 自有云解决方案的基础服务也适用于构建于 Salesforce Customer 360 平台的任何自定义解决方案。将 Salesforce 的预构建服务和解决方案用作尽可能多的解决方案的可信基础。

使用预构建平台服务有两个明显的优势。首先，您的应用程序自然会受益于每个版本的最新 Salesforce 创新。其次，您的开发团队可以专注于扩展和深化您的 Salesforce 解决方案提供的业务功能，而不是处理基本的架构繁重的工作。

从架构的角度来看，正确选择何时使用标准功能以及何时构建自定义功能并不具有挑战性。密钥是：

• **自定义平台意味着修改和扩展，而不是复制。**当您设计或评估您的架构时，您应该问：这是否已经存在于 Salesforce 平台的某个地方？如果答案是“是,但是...[插入业务利益相关者想要的更改...]”,那么在平台中使用预构建功能。要完成的架构工作是确定配置预构建 Salesforce 功能的最有用的方式，以满足业务预期。
• 没有自定义是小事。随着时间的推移，每个变化都会产生影响。如果您需要实施自定义解决方案，您可以通过尽可能选择使用低代码技术并在实施中创建可组成单元来减轻系统不可避免的技术债务。
• 考虑构建-购买频谱。Salesforce AppExchange是扩展 Salesforce 的应用程序和解决方案市场。AppExchange 应用程序可以提供功能，而无需在构建和维护自定义解决方案时涉及的开销。评估 AppExchange 解决方案时，请考虑以下事项：
  • 确定解决方案功能和差距。理想情况下，您会找到满足所有业务需求的应用程序。实际上，您可能找不到完美匹配。在您评估解决方案时，将潜在解决方案中的功能映射到业务需求的优先级列表。这将帮助您找到最能满足您最关键要求的解决方案。
  • 使用 Sandbox 和免费试用。使用免费试用期来评估 Sandbox 环境中的应用程序，并确定最合适的应用程序。确定应用程序是否需要您进行与现有配置冲突的配置更改。
  • 考虑短期和长期成本。根据基于订阅的应用程序的经常性成本，评估长期应用程序维护的节省。避免出现以下情况：您必须为业务利益相关者永远不会使用的很多功能支付经常性费用。
• **使用 Salesforce 中的预构建数据模型。**Salesforce 为销售、服务和各种行业垂直行业提供预构建的数据模型。使用 Salesforce 提供的数据模型可确保系统中的功能仅被定义一次（消除冗余和孤岛），在整个系统中建立单一的真实来源，更容易使用分析来理解应用程序数据，更容易使用 Salesforce 的预构建人工智能服务，降低维护成本（通过减少您需要支持的自定义），并减少技术债务。

就这么简单。从下面的模式和反模式中可以看出,反模式可以归结为在自定义解决方案中复制标准功能，或者使用更复杂的技术来提供自定义。

在实践中，您可能会遇到这样的情况，即业务利益相关者将自定义功能反模式视为最佳或唯一可行的前进道路。在这些情况下，您必须向利益相关者解释选择这条道路所涉及的权衡，然后彻底记录决定、其理由和实施。在这一领域，尽早交付核心价值并随着时间的推移进行调整，可帮助利益相关者更好地了解最佳前进方向。

要了解有关 Salesforce 工具的更多信息，以帮助您提高可维护性，请参阅工具相关意图。

技术债务是任何系统的自然组成部分。当技术或业务需求发生变化时，昨天的合理设计可能会成为反模式。也许，为了填补 Salesforce 平台功能中的空白而构建的东西会随着新的 Salesforce 版本或产品发布而突然变得多余。也许性能更好或更灵活的技术取代了您已经实施的技术。技术债务可以通过多种方式产生。

使用 Salesforce Customer 360 平台构建应用程序的一个关键好处是平台内置向后兼容性。这意味着新的平台创新可能会改变您未来应使用的解决方案的模式，但您基于以前的 Salesforce 技术构建的解决方案的日常功能将继续有效。随着时间的推移，任何基于旧技术的解决方案都会开始为您的应用程序添加新功能带来风险或瓶颈，并降低整体解决方案的运行状况。

规划和执行定期工作以解决技术债务问题对于在 Salesforce 解决方案中保持健康、简单的设计至关重要。不规划、审计和补救技术债务是创建架构不佳的系统的一种肯定方法。

最小化技术债务的一个方法是尽可能避免引入它,避免快捷方式,并优先使用标准功能而不是自定义功能。快捷方式，例如硬编码值，可能会节省时间，但从长远来看，它们会产生必须偿还的债务。

从架构角度解决技术债务问题的关键包括：

• 确定作为或不作为的实际成本或收益
• 正确的路线图
• 构建可组合解决方案

困难可能是让利益相关者与采取行动保持一致。一些利益相关者可能会将日常维护视为解决“昨天的错误”或剥夺他们希望预算支持的功能。

显示作为和不作为的实际业务影响，以及明确界定的交付品和时间表，可以帮助您的利益相关者了解解决技术债务的价值和相对优先级。坚持不懈地开展工作，将技术债务与业务影响联系起来，不仅有助于您的利益相关者更好地理解要完成的工作。它还将帮助您确保以真正有利于用户的方式识别和解决技术债务。

以下模式和反模式列表显示了 Salesforce 组织正确(和糟糕)的技术债务管理。

要了解有关可帮您解决技术债务问题的 Salesforce 工具的更多信息，请参阅工具相关意图。

下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。

✨ 在模式和反模式探索器中，发现更多可维护性模式。

可读性的核心概念是创造一致性,使人们容易理解事物的工作方式。构建可读的系统会使交付和维护团队保持一致，并帮助不熟悉系统的人员快速了解零件如何组合在一起。这意味着您的团队可以更少地依赖具有机构或历史 Knowledge 的个人来有效地引导供应商或新的团队成员。这意味着团队中的熟练人员可以专注于正在做出的选择的质量和权衡，因为系统的配置和代码易于人类阅读和理解。可读性可以加快治理和质量保证流程，并帮助团队更好地识别何时创建冗余自定义。它还可以提高系统以可重用和可测试的方式运行的可能性。

您可以通过有效的设计标准和文档来提高可读性。

设计标准提供了保持所有自定义一致的指导，即使在开发的早期阶段。设计标准就像护栏一样，使所有从事系统工作的交付团队和维护团队在如何处理和实施自定义方面保持一致。定义设计标准有助于提高交付和维护团队的效率，使代码和架构审查更容易进行，并为更好的文档提供基础。

如果没有设计标准，团队更有可能在竖井中工作。如果没有设计标准提供的一致性，企业将发现自己很难做到：

• 供应商和开发团队跨解决方案使用临时模式和方法，可能会引入反模式并降低可重用性(请参阅关注分离)。
• 增加了解决生产问题的时间，以及培训新团队成员所需的支持团队，并帮助他们了解一组不同的模式和方法。
• 跨团队协作不佳、团队之间工作冗余、解决冲突的时间浪费，以及集成测试中发现的错误。
• 增加挫折感和更高的更替率。

设计标准的一个关键优势来自利益相关者为创建标准而必须进行的对话和决策。特别是，该流程为您的业务和技术潜在客户提供了机会，让他们能够围绕业务所需的优化设计进行调整。

在设计标准中包含以下内容

• Salesforce 元数据的命名约定为如何命名系统中的每个自定义定义一组约定。良好的命名约定不仅仅是在对象、字段、代码、流和系统的其他元素的名称之间强制执行一致性。良好的命名约定也有助于开发团队使用名称来传达有关他们正在构建的内容的目的和功能的信息。因此，其他利益相关者可以通过查看其名称来更好地理解特定的自定义。
• 批准的设计模式及其用例建立模式和反模式浏览器库，以及关于何时(和不使用)使用每个模式的关键信息。该库可能包括所需的 Apex 触发器模式，或基于您在系统中的可组成性的流编排模式。
• 开发环境和工具指导。维护开发团队用于工作的明确工具列表。这可能包括为编写代码的任何人批准的工具链和语言，或者为低代码开发批准（或未批准）的声明性功能。您的标准可能包括用于自定义和文档的源控制系统列表，以及所需的签入/签出步骤。它们可能还包括用于不同类型开发工作的环境列表。

除了定义这些标准之外，您还需要决定如何以及在哪里维护和存储它们。如果贵公司的团队找不到您的设计标准（或者甚至不知道存在），它们将不会有效。理想情况下，您的设计标准与您的文档在同一个系统中（有关更多信息，请查看下一节）。

下面的模式和反模式列表显示了 Salesforce 组织的正确(和糟糕)设计标准。您可以使用这些来验证或改进您的设计标准。

要了解有关可帮您定义设计标准的 Salesforce 工具的更多信息，请参阅工具相关意图。

文档解释了系统的内容、方式和原因。如果没有有意义和一致的文档，团队会浪费大量时间来尝试了解系统的现状（并潜在地误解功能和自定义）。

创建好的文档需要时间。虽然大多数团队都认为文档对大型项目很重要，但在进行快速更改（例如配置更新或对自动化进行小的调整）时，跳过这一步可能很有诱惑力。不记录您对系统进行的更改始终是一种反模式。跳过文档可能会节省少量前期时间，但排除未正确记录的组织故障所需的时间将不仅仅是抵消这些节省时间。请始终在所有预估中包含足够的时间来创建文档，而不论您计划进行的更新需要付出多大的努力。

缺乏清晰的文档会导致各种问题，包括：

• 用于返工现有实施的开发周期
• 重复讨论重新讨论或对先前的决定感到困惑
• 新团队成员或供应商入职时间更长
• 过度依赖拥有机构或历史 Knowledge 的个人
• 冗余架构支持整个业务中相同或类似的功能
• 难以向关键利益相关者传达解决方案的目的和价值

对于 Salesforce 解决方案，维护文档：

• 解决方案概述。通过图表，您和利益相关者能够以各种详细信息级别可视化解决方案。Salesforce 图表框架帮助您创建图表，显示解决方案的业务功能以及技术实施详细信息。
• 决策记录。将考虑的选项、权衡、最终决策和推理记录在一个所有团队成员都可以访问的中心位置，以备将来参考。
• 代码。代码格式本身是文档的关键部分，它可以(并且应该)与您的设计标准保持一致。您还需要记录关键信息，并在每次修改代码时进行更新。对于所有类、触发器和组件，请记录以下内容：
  • 代码的作者
  • 编写代码的时间
  • 代码应该做什么
  • 关键依赖性
  • 所有更改
• 声明性自定义。对于贵组织中元数据的每种自定义，Salesforce 会为团队提供内置属性，以提供有关元数据目的和意图的帮助信息。作为设计标准的一部分，包括团队如何使用这些内置功能，以及如何命名声明性自定义。还要维护与您用于代码的信息相同的关键信息日志。

制定一套文档标准，以确保所有当前和未来团队成员能够以同样的方式解释文档。 (设计标准可以帮助做到这一点。)考虑用户如何搜索文档以查找相关部分或术语也很重要。随着系统的老化和复杂性的增加，您的文档也会增加。文档中信息的用途将与用户搜索和查找相关项目的频率、速度和容易程度直接相关。

下面的模式和反模式列表显示了 Salesforce 组织的正确(和糟糕)文档。您可以使用这些来验证或改进您的文档策略。

要了解有关适用于文档的 Salesforce 工具的更多信息，请参见工具相关意图。

下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。

✨ 在模式和反模式浏览器中，发现更多可读模式。

帮助我们保持 Salesforce 架构合理与您相关；参加我们的调查，以提供有关此内容的反馈，并告诉我们您接下来想要看到的内容。