概述

应用案例是由一个专门团队在平台上为一组用户提供新功能的限时努力。

应用案例不是“集成来源系统X”或“应用ML技术Y”。相反，应用案例关注的是我们需要为用户提供的功能，而不是实现过程中涉及的细节。将开发工作框定为应用案例迫使我们立即面对项目的价值主张。谁的工作生活将因这一新功能而改善？我们可以测量什么来判断是否成功？

在搭建我们的应用案例过程中，我们将解锁Foundry的许多复合特性，例如：

• 通过集成、数据科学技术和业务逻辑丰富数据；
• 将一个灵活、可重用的数据资产构建为我们组织和业务流程的数字孪生；
• 创建可重用的用户界面，通过将决策捕获为数据来关闭操作循环。

以我们的应用案例及其结果为指导，即使我们深入到Foundry的具体实现复杂性中，我们也能保持与现实价值的联系。

起始应用案例

在Foundry上开发应用案例的技巧涉及分解成果的功能需求，并为每个组件选择实现模式。

下面描述的解决方案设计过程是应对此挑战的一种方法。它专注于将应用案例需求提炼为一种格式，以指导关于界面实现和数据丰富的决策。这些决策反过来又指导Ontology设计，Ontology充当应用案例API，并将管道实现细节从最终用户交互中抽象出来。

通过这种方式，解决方案设计框架鼓励采用如下图所示的整体方法：

将解决方案设计分解为围绕应用案例数据的变换、结构化和交互的部分，将开发过程从纯粹的用户中心需求转向平台中心的组件。有了这个框架，我们可以关注：

• 常见模式的蓝图，
• 指示额外开发复杂度的标志，以及
• 可用选项之间的默认选择和选择替代方案的考虑。

我们还可以判断开发复杂性与严格遵循业务需求之间的权衡。通过解决方案设计框架的工作应能使我们重新评估优先级。

例如，假设原始业务需求是渲染特定的图表并包含一些特定的表单输入，这可能需要在Slate中进行奇怪的Ontology配置和大量开发工作。如果我们创建这些功能等效的可视化和操作（满足功能需求），那么我们可以以1/10的前端开发投资在Workshop中使用，并保持更简洁的Ontology数据结构。

在下一节中，我们将探讨捕获应用案例描述并提炼这些功能需求。