构建数字产品：从使用条款开始

数字产品的困境

数字产品与传统产品有着本质区别，因为客户是 里面 机器。产品 是 嵌入在活动中。客户经常在没有我们参与的情况下开展这些活动。.

想想 ServiceNow——主流的 IT 运维平台。客户用它来录入他们的配置项 (CI)，也就是他们的应用组合。如果我们不区分产品和主题，不从主题入手，就会陷入无限循环。我们也不能把主题（业务活动）应用到产品内部。.

配置项 (CI) 很容易理解。我们可以清楚地看到，ServiceNow 公司可以使用 CI 来运行产品，而这与产品内部的具体内容无关。真正的挑战在于跨越界限的数据。当客户参与我们的业务流程时——例如，当客户创建用于管理工单和访问产品的 ServiceNow ID 时，该 ID 对 ServiceNow 而言就具有了实质性意义。 安全主体, 账单主题, 客户服务主题.

当我们把数据材料用于产品运营时，我们就跨越了事件视界。跨越事件视界之后，事情会变得非常奇怪。.

简而言之，不要越过事件视界。.

明确区分产品数据架构和企业数据架构。当我们开始这项工作时，就会遇到一个显而易见却又难以启齿的问题： 数据使用条款.

你是邮局还是脸书？

将产品数据与企业数据分离，引出了一个根本性的制约因素——数据的使用条款是什么。我们在任何地方都会用到使用条款。 导航 因为它给我们提供了一个关键的架构约束。在面向服务的架构时代，我曾用'公交车测试'来解释使用条款。公交车是一种共享服务，有着严格的使用条款。一张车票只能载一位乘客。在公交车站，一张车票只能让一位乘客乘坐预定路线的公交车。这张车票、这条路线和这个站点只有在预定的时间才能使用。.

司机不会询问您的目的地、预计到达时间或是否需要搭车回家。司机也不会允许无证驾驶者使用车票。使用条款清晰明了。.

我们在文中使用了一种简单、鲜明的对比。 咨询项目. 当你开发一款数字产品时，, 我们是邮局，还是Facebook？

邮局提供一项至关重要的服务：将邮件从寄件人送到收件人手中。为此，他们需要非常有限的元数据——目的地地址、寄件人地址以及您支付的服务级别。但这里有一个绝对的限制： 他们从来不看信封里面的东西。. 他们的架构、治理和数据模型都基于这样一个假设：邮件内容与他们无关。如果邮局员工打开邮件解析你的信件，然后向你推销定向广告，这并非高明的盈利策略，而是犯罪。.

现在说说Facebook。Facebook的情况恰恰相反。没错，就像邮局一样，它们也起到沟通桥梁的作用。它们会跟踪相关的元数据。 运营该服务. 但是 您的消息内容 这是他们商业模式的主要动力。他们会打开并解析每一条信息，追踪信息接收者的行为，比较收件人、发件人、主题等等所有信息。他们甚至可以翻遍我们的袜子抽屉，将内容、品牌、类型和穿着打扮都变现。因为使用条款允许他们这样做。.

任何使用条款都可能奏效。有些使用条款，例如 WhatsApp 的条款，旨在提供高度隐私保护。有些条款则授予用户所有访问权限。请记住，这并非真正的隐私——即使是 Facebook 也并非完全如此。 宣传 你的希望、梦想和执念。但他们利用了它们。他们利用它们，是因为产品条款允许他们这样做。当你违反使用条款时，就意味着架构上的重大失败。你未能有效管理边界。.

使用条款始终由……制定 所有者. 服务负责人、产品负责人、设施负责人、业务区域负责人，都无关紧要。务实地讲，我们会找产品负责人。不是敏捷团队里随便一个无关紧要的代表——而是真正对提供给客户的产品负责的人。这个人能够平衡客户可接受的使用条款和公司可接受的条款。记住，很多乘客想要的是一位全职司机，一位耐心等候、随时准备载他们去任何想去的地方的司机。而这种服务确实存在，只是价格不同而已。.

集会作为最终的强制手段

使用条款为你设定了可控的界限。张力存在于每一个界限之中。建筑的精髓在于应对这些界限。.

苹果的"照片回忆"功能加剧了这种紧张关系。苹果在其平台上提供通用的存储和共享功能，这与Facebook的社区调解机制非常相似。然而，苹果的核心价值主张是隐私。他们极力捍卫自己的使用条款。如果他们无法保证任何人都无法查看你的照片，他们甚至会从市场撤回服务。 苹果袜子抽屉 没有你的积极参与。.

在内部，他们不会花费一分钱来处理客户数据以执行搜查令。因为他们 无法看. 他们在法庭上声称。 没有后门.

然后，他们提供一项服务，帮你浏览和整理照片——那些珍贵的回忆。 他们的使用条款保证绝对隐私.

他们以强有力的手段应对了这些硬性限制——苹果无法查看你的照片，而且你的照片会经过筛选。 应用程序架构. 就 Navigate 而言，它只是使用了 装配模型.

功能组装是应用架构师的核心任务。功能组装决定了集成边界、生命周期和依赖关系——它是应用架构面临的关键挑战。我们知道，功能可以放置在任何地方。真的是任何地方。你可以将其嵌入企业应用，将其暴露在微服务中，甚至可以将其硬编码到专用集成电路（ASIC）中。.

为了满足数据使用条款，苹果特意选择将 AI Worker 功能直接部署在边缘设备——也就是你的 iPhone 上。通过将计算和数据整合在一起，苹果实际上将自身与数据隔离开来。他们明知故犯地放弃了从用户身上获利的机会。.

忽视你的声明，负面影响就会像秃鹫一样扑来。责任问题迫使你事后采取保护措施，这会导致复杂性增加，技术债务和成本上升——外加一个藏在阴暗角落里的责任黑洞。.

如果你的数字产品有使用条款，请遵循苹果公司的惯例。创建能够满足所有要求的应用架构、技术架构和安全架构。.

结论：剪断绳结

如果你不从产品数据入手，不了解你的服务条款——比如以窥探用户隐私为生的 Facebook、被指示窥探用户隐私的邮局，或者不能窥探用户隐私的苹果——你的架构必然会走向法律责任。.

您面临的最大挑战是如何利用产品数据来改进业务运营。一个简单的例子是，利用客户在您的 SaaS 产品中维护的身份信息来支持访问控制或授权。.

你永远无法通过调整"销售"、"支持"或"IT运维"等主题来解开这个结。这就像用力拉绳子，只会让结越拉越紧。这和再开一次会讨论这个问题没什么区别。 客户的所有者.

我本周的挑战是审视一下你们的数字产品。你们的应用架构中是否清晰明确地划分了数字产品？数据架构又如何呢？还是说，你们把所有数据都混杂在一起，难以协调运作？ 你的 业务和应用支持 你的 想做生意？那就开始把你的数字产品作为主题吧。开始明确列出使用条款。 管理您的架构 按照你所得到的指示去做。.

下周，我将详细演示我们如何解决这个问题。我们将探讨如何构建边界，建立清晰的约束条件。我们首先扩展开箱即用的 DAMA 企业数据模型，并将每个数字产品视为一个 DAMA 主体。.

一如既往，欢迎大家提出意见和反馈。.

祝你有美好的一天！

问候，,

戴夫 戴夫·霍恩福德 Conexiam

PS. 如果理顺数据架构是您的关键路径，请了解一下我们的 数据架构基础研讨会. 我们将帮助您绘制主体图，定义数据契约，并确保使用条款驱动您的架构，而不是破坏它。.