实施 yodlee 需要多长时间？
我是一位非技术（好吧，非软件、硬件背景）的创始人，他聘请了一位相当优秀的开发人员，该开发人员已经构建了一个具有 Rails 后端和 CSS/HTML 前端的网站。我们的下一步是开发 Yodlee 集成，我们都想知道这需要多长时间。他有一个我认为合理的估计，但希望得到社区的反馈，而不会对反应产生偏见。
另外，如果有人以前做过实施，我将非常感谢您的观点和帮助！
I'm a non-technical (well, non-software. hardware background) founder who has hired a pretty good developer that has built a site with backend on Rails and frontend with CSS/HTML pretty capably. our next step is to develop a Yodlee integration, and we both want to know how long it takes to do this. He has an estimate which I think is reasonable, but would like feedback from the community without biasing the responses.
Also, if anybody has done an implementation before, I would really appreciate your perspective and help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在过去的两年里，我为洛杉矶的一家初创公司实施了复杂的 Yodlee 集成。他们在此基础上建立了社交游戏和资金管理平台。简而言之，这是一项艰苦而肮脏的工作。
让您的应用程序与 Yodlee API 进行通信的技术方面根本不是困难的部分（它几乎是一个标准的 Web 服务）。以下是突出困难的一些方面：
我已经设计和构建系统 15 年了，并且非常擅长估算项目。我们与约德利相差甚远。事实上我们仍在处理问题。
为了理解为什么它如此困难，您确实需要了解 Yodlee 是什么......它是 10,000 个不同系统的聚合器。现在，这些其他系统可能是大型专业系统，例如美国银行、大通银行……但它们通常是小型银行（奥马哈的鲍勃银行）。
当 Yodlee 与大公司（它们被称为内容服务）进行通信时，大多数情况下总会有一个 api 能够实际返回良好的数据。但对于小孩子来说，他们会进行屏幕抓取。你可以想象它总是会破裂。他们在印度有一整个团队专注于此。
另一个问题是关于数据建模；每个内容服务在其源头都对数据进行了不同的建模（不同的名称、不同的元素、不同的关系……），但 Yodlee 却将所有 10,000 个模型合并到一个视图中。这给您留下的是一个非常臃肿的模型，您永远无法知道或指望获得某个数据元素。
为了给您一个想法...除了标准基类字段（余额，...）之外，还有关于信用帐户的额外字段（年利率、信用金额、最后付款...）。虽然拥有这些数据听起来很棒，但实际上，提供这些额外数据元素的内容服务数量非常少，以至于您无法真正依赖它们。我想说这些数据元素的保真度非常低。您真正可以信赖的只是基本元素（账户名称、类型、余额）和（交易日期、描述和类型）。
说到交易……他们的交易分类系统不太好。他们显然采取了广度优先的方法，而不是注重准确性。我们建立了一个完整的交易分类系统，该系统更加有效。
其他一些事情：DAG 帐户测试系统没有用；它的运作方式与真实账户不同。您最好在不同的内容服务上开设 5-10 个帐户，并向开发人员提供这些帐户的用户名/密码以进行测试。用于帐户安全的MFA（多因素身份验证）系统一直是令人头痛不已的问题。这不是 Yodlee 的错，而是游戏的本质。银行正在做越来越疯狂的事情来增加安全层。 Yodlee 拥有 MFA 系统来弥补这一点。在任何特定时间，我们大约有 20% 的账户由于某种原因出现错误。我们构建了一个完整的组件来管理这个问题。
那么这一切意味着什么呢？加倍你的估计，准备好弄脏吧。我根本不想贬低 Yodlee（除了缺乏文档）；他们确实正在解决一个难题。确实没有其他更好的选择。
I have implemented a complex Yodlee integration for a LA based start-up over the last two years. They built a social game and money management platform on top of it. The short answer is that it's tough and dirty work.
The technical aspect of getting your application to communicate to the Yodlee API is not at all the hard part (its pretty much a standard web service). Following are some aspects highlighting the difficulty:
Ive been designing and building systems for 15 years and have gotten pretty good at estimating projects. We were way off with Yodlee; in fact we are still dealing with issues.
In order to understand why its so tough, you really need to understand what Yodlee is.. it is an aggregator of 10,000 different systems. Now these other systems might be big professional systems like Bank of America, Chase, ... but they are often small little banks (Bob's Bank in Omaha).
When Yodlee communicates with the big companies (they are called content services) there is most always an api that actually returns good data. But with the little ones, they are doing screen scraping. You can imagine that breaks all the time. They have an entire team in India which is just focused on that.
The other issue is about modelling the data; each of the content services at its source has modeled the data differentley (different names, different elements, different relationships,...) but Yodlee but combine all 10,000 models into one view. What this leaves you with is a very bloated model, where you can never know or count on getting a certain data element.
To give you an idea... there are extra fields about a credit account (apr, credit amount, last payment, ...) beyond the standard base'class fields (balance, ...). While this sounds great that you have this data, in practice the number of content services that provide these extra data elements is so low that you cant really depend on them. I'd say that the fidelity of those data elements is very low. All you can really count on is the base elements (account name, type, balance) and (transaction date, description and type).
Speaking of transactions... their transaction categorization system is not that good. They have clearly taken a breadth first approach to this, rather than focus on accuracy. We built an entire system for transaction categorization which is far more effective.
A couple other things: The DAG account test system is useless; it does not operate the same way real accounts do. You will be far better off opening 5-10 accounts at different content services and giving your developers the username/passwords for these for testing. The MFA (multifactor auth) system for account security has been an endless headache. This isnt Yodlee's fault, its the nature of the game. The banks are doing more and more crazy things that add security layers. Yodlee has the MFA system in place to compensate for this. At any given time about 20% of our accounts are in error for some reason. We have built an entire component just to manage this.
So what does this all mean? Double your estimate, get ready to get dirty. I dont want to put Yodlee down at all (except for the lack of documentation); they really are solving a hard problem. There really arent any other better options.
我领导的团队负责 Yodlee API 的销售和支持，因此响应可能有点偏差。
我见过客户在 10 天到 3 个月到 6 个月的时间内启动并运行。实施时间取决于您正在使用的数据模型中的字段数量以及在将数据呈现给用户之前将如何使用或操作数据。
虽然账户余额或交易金额等最常见的数据字段始终可用，但克雷格是对的，当您进入更广泛的数据模型时，您将不得不针对数据不存在时的异常情况进行编码。 Yodlee 确实提供了有关字段可用频率的文档来帮助完成此过程。但如果您仅使用基本帐户和交易信息，则不必担心这些复杂性，并且会加快实施速度。
从 Yodlee 收到数据后，您如何使用这些数据也将在整合所需的时间中发挥重要作用。如果您从交易描述中获取额外的数据或进行分类，那么就会变得更加复杂，并且需要更多的时间。如果您按原样使用许多字段，那么这会更容易。
克雷格提到的另一项是额外的安全问题（多重身份验证）。虽然 API 的这一部分确实增加了一些工作，但我们已经添加了相关文档以使集成更容易。此外，对于出现的任何开发问题，我们都会为客户提供访问由我们的技术咨询团队监控的开发人员论坛的权限。
I run the team responsible for sales and support of the Yodlee APIs so the response may be a little biased.
I have seen clients get up and running in anywhere from 10 days to 3 months to 6 months. The time to implement depends on the number of fields in the data model you are using and how you are going to use the data or manipulate it before presenting it to your users.
While the most prevalent data fields such as account balance or transaction amount will always be available, Craig is right, as you get into the broader data model you will have to code for exceptions when the data is not there. Yodlee does provide documentation on how often the fields will be available to help with this process. But if you are only going to be using basic account and transactional information, you will not have to worry about these complexities and it will speed implementation.
How you use the data once you receive it from Yodlee will also play a big part in the time it takes to get integrated. If you are deriving additional data from the transaction descriptions or are doing something with categorization then there is more complexity and it will require more time. If you are using many of the fields as-is, then this will be easier.
The other item that Craig mentioned is the extra security questions (Multi-factor Authentication). While that section of the API does add some work, we have added documentation around this to make integration easier. Also, with any development issues that come up we give clients access to a developer forum that is monitored by our Technical Consulting team.