我是一个非技术（嗯，非软件。硬件背景）的创始人，他聘请了一位非常优秀的开发人员，该开发人员已经建立了一个在 Rails 上使用后端和使用 CSS/HTML 进行前端的网站。我们的下一步是开发 Yodlee 集成，我们都想知道这需要多长时间。他有一个我认为合理的估计，但希望得到社区的反馈，而不会对回应产生偏见。
另外，如果有人以前做过实施，我将非常感谢您的观点和帮助！
问问题
5832 次
2 回答
35
在过去的两年里，我为一家位于洛杉矶的初创公司实施了复杂的 Yodlee 集成。他们在此基础上构建了一个社交游戏和资金管理平台。简短的回答是，这是一项艰苦而肮脏的工作。
让您的应用程序与 Yodlee API 通信的技术方面一点也不难（它几乎是一个标准的 Web 服务）。以下是突出困难的一些方面：
- 最困难的部分是处理客户数据中的未知数和可变性。
- API 实际上没有文档
- 有几种方法可以执行每个将返回不同数据的操作
我已经设计和构建系统 15 年，并且非常擅长估算项目。我们和 Yodlee 差得很远。事实上，我们仍在处理问题。为了理解它为何如此艰难，你真的需要了解 Yodlee 是什么......它是 10,000 个不同系统的聚合器。现在这些其他系统可能是大型专业系统，如美国银行、大通银行……但它们通常是小型银行（奥马哈的 Bob's Bank）。
当 Yodlee 与大公司（它们被称为内容服务）进行通信时，通常总会有一个 API 能够真正返回良好的数据。但是对于小孩子，他们正在做屏幕抓取。你可以想象它一直在中断。他们在印度有一个完整的团队，专注于这一点。
另一个问题是关于数据建模；每个内容服务在其来源都对数据进行了不同的建模（不同的名称、不同的元素、不同的关系……），但 Yodlee 却将所有 10,000 个模型组合到一个视图中。这给您留下了一个非常臃肿的模型，您永远无法知道或指望获得某个数据元素。
给你一个想法......除了标准的基类字段（余额，......）之外，还有关于信用账户的额外字段（apr，信用金额，最后付款......）。虽然您拥有这些数据听起来很棒，但实际上提供这些额外数据元素的内容服务数量非常少，以至于您无法真正依赖它们。我会说这些数据元素的保真度非常低。您真正可以依靠的是基本元素（账户名称、类型、余额）和（交易日期、描述和类型）。
说到交易……他们的交易分类系统不是很好。他们显然对此采取了广度优先的方法，而不是专注于准确性。我们建立了一个更有效的交易分类系统。
其他几件事： DAG 帐户测试系统没用；它的运作方式与真实账户不同。您最好在不同的内容服务上开设 5-10 个帐户，并为您的开发人员提供用于测试的用户名/密码。用于帐户安全的 MFA（多因素身份验证）系统一直是一个令人头疼的问题。这不是 Yodlee 的错，这是游戏的本质。银行正在做越来越多疯狂的事情来增加安全层。Yodlee 有 MFA 系统来弥补这一点。在任何给定时间，我们大约有 20% 的帐户由于某种原因出现错误。我们构建了一个完整的组件来管理它。
那么，这意味着什么？加倍你的估计，准备好弄脏。我根本不想让 Yodlee 失望（除了缺乏文档）；他们真的在解决一个难题。真的没有其他更好的选择。
于 2011-05-26T00:39:43.733 回答
5
我管理的团队负责 Yodlee API 的销售和支持，因此响应可能有点偏颇。
我见过客户在 10 天到 3 个月到 6 个月内启动并运行。实施时间取决于您正在使用的数据模型中的字段数量，以及您将如何使用数据或在将数据呈现给用户之前对其进行操作。
虽然最流行的数据字段（例如帐户余额或交易金额）始终可用，但 Craig 是对的，当您进入更广泛的数据模型时，您必须在数据不存在时对异常进行编码。Yodlee 确实提供了有关这些字段多久可用于帮助完成此过程的文档。但是，如果您只打算使用基本的帐户和交易信息，则不必担心这些复杂性，它会加快实施速度。
从 Yodlee 收到数据后，您如何使用这些数据也将在整合所需的时间中发挥重要作用。如果您要从交易描述中获取额外的数据，或者正在做一些分类工作，那么就会有更多的复杂性，并且需要更多的时间。如果您按原样使用许多字段，那么这将更容易。
Craig 提到的另一项是额外的安全问题（多因素身份验证）。虽然 API 的该部分确实增加了一些工作，但我们已经添加了围绕此的文档以使集成更容易。此外，对于出现的任何开发问题，我们都会让客户访问由我们的技术咨询团队监控的开发者论坛。
于 2011-06-13T18:48:01.357 回答