FinFolio | Portfolio Management Software Blog

Our strategy for feature implementation is to take the hardest features, and those most likely to change our database/object structure, and implement those first. We recently discovered that the Portfolio/Account views were going to be difficult to implement, so we put cost accounting on hold. This is a long post because the concept is very tricky and positively impacts many areas of the software.

There are two separate "views" of the data in FinFolio, one to represent the legal system-of-record data (Account view) and one to mirror the firm's view of the client positions (Portfolio view). This lets us maintain the integrity of the system-of-record data and preserve the layout for data imports, while allowing advisors to specify a completely different reporting structure that can be used for modeling and printing client reports.

This should give advisors complete flexibility in mapping accounts, but remove complexity at report printing time. As I've been talking to advisors, I've heard several stories about having to re-print quarterly reports because you selected an incorrect option before clicking Print. With the Portfolio/Account structure you can set it once when the account is imported and keep the same structure for the life of the account.

​We just hit our first two milestones. Two major pieces of the framework are complete, our data persistence layer, and the plugin structure. We finished them a week ago but I wanted to be sure before posting it on the blog.

Our incomplete object model can now read and write from any database, including Microsoft SQL, Oracle, DB2, and MySQL. We anticipate most users simply using the Microsoft SQL database, but larger enterprise shops may prefer one of the other options. The tricky part here was finding a code library that mapped our rich object model into a database.

We were planning on using Microsoft's Entity Framework but ran into some irreconcilable speed issues. So instead, we're using NHibernate, the Dot Net port of the Java Hibernate framework. It's much more streamlined and has a lot of miles on it. It also lets us store multiple similar classes into the same underlying table, which keeps the database simple.

The second big piece is getting the plugin structure working. The software is designed so that the core project does almost nothing but define interface points, and "mash" the different modules together. All of the code modules, like Alerts, Data Access, Cost, Calculations, Reports, etc. are now in separate libraries that can be easily plugged into or out of the framework. We are developing all of our own modules exactly the same way our end users would create add-ons. In the software world, this is called "eating your own dog food", and it's essential to good software

Now we're working on the calculations, starting with Cost.