数字产品架构：黄线碰撞

CDO幻觉

边界有其所有者。商业数字产品有捍卫产品的勇士。而我们内部却存在着错觉。我们臆想出客户和所有者。我们误以为组织架构图永远能告诉我们决策权归属。.

精明的商业产品负责人是重要的利益相关者。他们被赋予了特定的责任领域——产品。他们拥有非常清晰的认识。 方向——预期、约束、风险偏好. 他们能够评估变更的价值，并且通常能够提出非常明确的需求。我曾与一位数字产品负责人合作，他需要降低其平台的交易成本（95%）。不是增加功能，也不是仅仅降低成本。95% 削减了平台成本，以保持竞争力。.

像这样的产品所有者 架构治理 这是一种梦想。你拥有了一位清晰、权威的利益相关者。他/她不仅理解被赋予的权力，而且完全了解该权力的背景。.

然后是我们的内部产品。一开始，产品和数据之间的界限比较模糊。我们通常会有一些原则来指导这些原则的制定。 共享数据. 我们暗示，因为数据存在，所以 企业拥有它.

我们查看组织架构图，会发现首席数据官（CDO）或数据治理办公室。主流思维会直接去找CDO询问和解释。他们想当然地认为CDO神奇地拥有所有数据的所有权。最具破坏性的是，他们假定任何旨在"货币化"、民主化和创造"更佳决策"的工作都具有显而易见的价值。.

同时，在开发过程中，我们经常将引入 API 或运行提取操作与将数据转储到……混淆。 虚拟数据湖 随着变化 改善我们的组织.

当我们把目光转向"产品负责人"时，会发现他们不过是些被捧上神坛的业务分析师，夹在技术人员和一群不满的用户之间左右为难。他们把用户群体称为'客户'——尽管马蒂告诉我们，客户必须付费，而且随时可以离开。这些“产品负责人”忙着处理Jira工单，毫无决策权，对价值也一无所知。试想一下，如果他们知道项目的可行性取决于95%运营成本的削减，并且还试图通过数字化项目来实现这一目标，那会是怎样一番景象？.

像这样的产品所有者 架构治理 他靠呼吸机维持生命。我们必须充分利用所有资源。 架构治理 工具包，用于找出产品的限制因素、产品目标以及组织对消费者业务功能的期望。.

我们知道，我们的组织是一个错综复杂的互动网络。 导航, 为了简化复杂性，我们依赖于 SABSA的风险模型 以及在……中发现的卓越建筑理念 TOGAF.

我想要的只是与我那些精明的商业产品负责人晚上睡觉前所担忧的相同的知识和方向——市场、定位、价格、竞争。.

我只需要一个能够测试上涨空间、下跌空间、价值、成本和风险的人。.

我想要的只是良好治理的基本要素——目标、绩效预期、限制和风险承受能力。.

而且，我希望所有数字产品都能做到这一点。.

黄线碰撞

一旦我们建立了数字产品的治理结构，紧张局势就开始了。.

我们大部分时间都在内部工作。你会接触到很多来自那些不受市场约束的人的想法。这些人声称认同任何战略、举措或领导声明。他们利用这种认同来为自己的偏好或局部改进辩护。.

你肯定听说过那种致命的“结盟论”。它只关注他们如何支持某件事，却缺乏实质性的贡献。我们都知道，价值是由值得付出代价的收益构成的，尤其是在考虑到获取收益的不确定性以及成本的不确定性之后。.

在公司内部，重点会放在技术上。例如，重点会放在如何抓取运营数据库等技术细节上。成本评估可能与赶工集成项目一样低廉。.

在急于做事的浪潮中，数据质量和流程的基本要素都被忽略了。.

贵公司正在使用产品语言进行危险的驾驶行为。.

我们来看两个关键的数据产品风险。.

你不能出售你偷来的东西。

所有销售数据产品的人都在销售方法论和数据来源。.

每个人。.

如果没有明确的使用条款允许您重复使用数据，那么数据就是被盗的。.

从数据架构的角度来看，被盗数据通常缺乏可靠的来源和方法论： 数据源 和 数据流.

被盗数据并非'变现'，而是被销赃。销赃者之所以能提供巨额折扣，是因为主流市场无法使用赃物。.

在公司内部，被盗数据甚至会污染虚拟数据湖。表面上看，缺乏方法论的低质量数据与高质量数据并无二致。但实际上，它需要不断地进行提炼和后处理才能发挥作用。.

最终，被盗数据会引发合规性问题，通常涉及个人身份信息、客户机密或司法管辖区问题。届时，您不得不花费更多资金来清理原本毫无价值的昂贵数据。.

如果你想找点乐子，不妨仔细看看你的数据堆肥箱的收益。我敢打赌，就像大多数家庭堆肥一样，你会看到人们尽职尽责地把果皮扔进堆肥箱，然后去园艺商店买肥料和土壤。.

监护权限制

我们通过良好的架构来解决这些问题。.

我们开始围绕产品数据构建主题，特别是我们的数字产品收集客户信息的数据。 导航 我们使用模型属性来区分 托管数据—属于其他组织的数据，只能严格按照合同使用。.

这块地是你围栏上的第一根立柱。这些边界严重限制了区域的融合，因此需要采取安全措施。.

上周我简要提到了 ServiceNow。配置项显然是 监护, 它们被应用程序使用，但应用程序提供商永远没有理由去查看。 用户名?

是的，, 用户名. 在SaaS IT运维管理系统中，客户会设置这些功能，以便将人员添加到流程中、启用审批功能，甚至通过拨打用户个人电话发送警报。ServiceNow可以使用这些功能吗？

显然，使用它们进行访问和授权非常方便。但如果权限受到限制，你就会立即回到苹果公司的问题上，你可能需要找到一种方法来确保数据永远不会泄露到外部。 客户环境. 我们看到苹果公司很好地利用了这一点。 应用 和 基础设施架构 重点是 集会边界. 他们通过在您设备上处理记忆来保证记忆的隐私。请记住，他们承诺绝不偷窥，即使您这一次会感到高兴。.

同样的问题也应用到公司内部。哪些数据属于数字产品？需要进行哪些整合才能确保在产品内部、为产品处理数据或由产品处理数据？

那么，有哪些数据可用？企业又需要哪些数据？

我们的一位数字产品客户采用非常精简的企业财务管理模式。每个产品系列都自行负责成本核算和成本管理。流入企业财务系统的财务数据非常有限。.

这种看似效率低下的设计，实际上让不同的产品能够优化各自的业务和税务运营。首席执行官可以随时在走廊里走动，提出切中要害的问题。损益负责人必须了解情况并进行优化。没有任何借口可言。我们需要将这种严谨性运用到我们所有的数字产品中。.

建筑辩护：不合规建议

在这次对话中，我一直在强调你是如何挑战边界的。我一直在强调，数字产品只不过是一个特殊的治理问题。.

将他们视为一个主体，一个业务领域。同时，也要将他们视为一个风险或治理领域。我相信您明白，每个数据主体也是一个…… 治理领域. 这是一个目标独特、绩效预期明确、限制条件苛刻、风险承受能力也各不相同的地方。这是一个拥有坚实基础的地方。 关键利益相关者.

我说的不是某个决策者，而是…… 重要的利益相关者. 利益相关者总是成群结队地生活在一起。利益总是相互竞争，权力总是重叠，方向也总是冲突。如果事情这么简单，我们就不需要企业架构了。.

我举的例子都是我们需要保护数字产品的案例。这些案例中，我们会使用汇编语言在产品内部或通过产品进行处理。这只是其中一种情况，你需要知道这种情况何时适用。.

另一种情况同样适用，即产品负责人——作为关键利益相关者、治理领域负责人和主题负责人——被告知要融入更大的整体。他们被告知要使用共享服务财务系统。.

两种模型都正确。两种模型都可以作为您的数字产品架构。.

当人们不再遵循你为你的事业及其独特的市场策略而优化的架构时，他们就越过了黄线。迟早会面临逆行的局面。.

为了避免与黄线发生碰撞，我们， 企业架构师 走到枪林弹雨中。.

在方法方面，我们执行 实施治理 并创建一个 不合规建议. 发现问题很容易，但作用不大。建议只是告诉利益相关者他们需要做什么来挽回目标所提供的价值。他们已经知道违规行为会带来什么影响。.

所有违规行为归根结底都是：

1. 强制执行目标： 进行变更以实现预期的目标架构价值。.
2. 给予临时救济： 暂缓解决问题。.
3. 改变架构： 接受原有价值的损失，并以新的目标创造新的价值预期。.

我们精心构建选择框架，让合适的领导者——也就是利益相关者——能够做出明智的选择。如此一来，你就能拥有最佳的组织架构和最佳的变革方案。这真是一个美好的地方。.

《黄线碰撞》完结

我们常常认为，勇敢的利益相关者坚守阵地是值得称赞的， 强制执行目标. 这种情况经常发生。通常，不合规行为是为了局部优化，或者项目团队为了赶进度而偷工减料。 上线日. 或者敏捷团队宣称取得了胜利。所有这些情况都在破坏目标所带来的价值。.

我并不自负到认为自己无所不知。我知道世界在不断变化，新的方法、新的工具层出不穷。创造力的总和远远超过了我自身的能力。 优秀的咨询团队. 最重要的是，每天早上我们公司都像一家全新的公司，处于全新的位置。.

我创作 动态路线图 赋予利益相关者掌控权。我把每一次违规都视为一次充满活力的机遇。当我们发现通往更佳目标的更佳路径时，我们会立即拥抱它。然后我们庆祝！我们充分发挥了所有可用的创造力和智慧。我的架构充满活力，不断发展壮大。耶！

所以，我本周面临的挑战是：谁能权威地回答你们的数字产品问题？谁来承担每个选择的利弊？每个产品的市场定位（企业环境）和成功衡量标准（发展方向）是什么？这些产品受到哪些更优架构的限制？

利用这一点来确定黄线的位置。进一步来说，是哪种类型的线——比如山区高速公路上的双黄线和限速标志——就是一个线索。找到真正重要的限制条件。.

下周，在数据和数字产品系列的最后一部分，我们将探讨技术，也就是架构师的工具。具体来说，我们将探讨两方面内容。首先，我们将介绍逻辑文档模型，它能够跨越企业和数字产品之间的边界。其次，我们将探讨架构规范，它将数据的使用条款和组装方式转化为切实可行的指导原则。.

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

祝你有美好的一天！

问候，,

戴夫

戴夫·霍恩福德
Conexiam