Use case lifecycle（用例生命周期）

A use case is a time-bound effort by a dedicated team to deliver new capabilities on the platform for a set of users.

A use case is not “integrate source system X” or “apply ML technique Y”. Instead, a use case focuses on the capabilities we need to provide to our users, rather than the implementation details along the way. Framing development work as a use case forces us to confront the value proposition of our project immediately. Whose work life will improve as a result of this new capability? And what can we measure to know if we’ve succeeded?

Along the way to building our use case, we’ll unlock many of the compounding features of Foundry, such as:

• enriching data through integration, data science techniques, and business logic;
• structuring a flexible, re-usable data asset as a digital twin of our organization and business processes;
• and creating re-usable user interfaces that close the operational loop by capturing decisions as data.

Holding our use case(s) and their outcomes as guides, we stay connected to real-world value, even as we get into the complexity of specific implementations throughout Foundry.

Starting a use case

The craft of developing a use case on Foundry involves decomposing the functional requirements of the outcomes and choosing the implementation pattern(s) for each component.

The solution design process described below is an approach to this challenge. It focuses on distilling the use case requirements into a format that informs decisions about interface implementation and data enrichment. These decisions in turn inform the ontology design, which acts as the use case API and abstracts pipeline implementation details from the end user interactions.

In this way, the solution design framework encourages a holistic approach as depicted in the image below:

Breaking the solution design into buckets around transforming, structuring, and interacting with use case data pivots the development process from purely user-centric requirements into platform-centric components. With this framework, we can then look at:

• Blueprints for commonly encountered patterns,
• Flags that indicate additional development complexity, and
• The default choice between available options and considerations for choosing alternatives.

We can also judge tradeoffs between development complexity and strict adherence to business requirements. Working through the solution design framework should make it possible to reevaluate priorities.

For example, suppose the original business requirement is to render a specific chart and include some specific form input, which may require odd ontology configurations and significant development effort in Slate. If instead we created these functionally-equivalent visualizations and Actions (meet the functional requirement), then we can use Workshop at 1/10th the investment in front-end development and keep a cleaner ontology data structure.

In the next section we’ll look at capturing a use case description and distilling these functional requirements.

---

中文翻译

用例生命周期

用例（use case）是由专门团队在限定时间内为特定用户群体在平台上交付新功能所付出的努力。

用例不是"集成源系统X"或"应用机器学习技术Y"。相反，用例关注的是我们需要为用户提供的功能，而非实现过程中的技术细节。将开发工作定义为用例，迫使我们立即直面项目的价值主张：这项新功能将改善谁的工作？我们又能通过什么指标来衡量是否成功？

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

• 通过集成、数据科学技术和业务逻辑丰富数据；
• 将灵活、可复用的数据资产构建为组织和业务流程的数字孪生（digital twin）；
• 创建可复用的用户界面，通过将决策捕获为数据来形成运营闭环。

以用例及其成果为指引，即使我们深入Foundry中特定实现的复杂性，也能始终与现实世界的价值保持联系。

启动用例

在Foundry上开发用例的技巧包括：分解成果的功能需求，并为每个组件选择合适的实现模式。

下面描述的解决方案设计流程正是应对这一挑战的方法。它专注于将用例需求提炼为可指导界面实现和数据丰富决策的格式。这些决策进而影响本体（ontology）设计——本体充当用例的API，将管道实现细节与最终用户交互隔离开来。

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

将解决方案设计划分为转换、结构化和交互三大板块，使开发过程从纯粹以用户为中心的需求转向以平台为中心的组件。借助这一框架，我们可以审视：

• 常见模式的蓝图（blueprint），
• 表明额外开发复杂度的标志（flag），
• 以及可用选项之间的默认选择及选择替代方案的考量因素。

我们还可以权衡开发复杂度与严格遵循业务需求之间的取舍。通过解决方案设计框架的梳理，应该能够重新评估优先级。

例如，假设原始业务需求是渲染特定图表并包含某些表单输入，这可能需要特殊的本体配置和在Slate中投入大量开发工作。如果我们转而创建功能等效的可视化界面和操作（Action），就能以十分之一的前端开发投入使用Workshop，同时保持更清晰的本体数据结构。

下一节我们将探讨如何捕获用例描述并提炼这些功能需求。